Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
draft-mills-sntp-v4-00

The site-local addresses in question are multicast addresses, which have not been deprecated.

I'm pretty sure the time algorithms specified here are adequately described.
The document is confused about the use of anycast, multicast and unicast addresses; I recommend to the RFC Editor that competent review of these terms is applied before the document is published (and that the changes are communicated to the being-formed NTP WG).

This document has some significant issues/errors regarding IPv6
addressing and anycast.  I realize that this is only intended to be
an informational document, but I do not think that it is ready to 
be published as an RFC in its current form.

My detailed comments are included below, indicated by ">>":

2.  Operating Modes and Addressing

   Unless excepted in context, reference to broadcast address means IPv4
   broadcast address, IPv4 multicast group address or IPv6 site-local
   scope address.

>>  So, a "broadcast address" may be an IPv6 site-local (unicast)
>>  address?  This seems particularly obscure for two reasons: (1)
...snip...
>>... broadcast addresses.  Is
>>  there any reason for this, other than a lack of desire to change
>>  the text of the original document?

   Further information on the broadcast/multicast model is in RFC-1112
   [DEE89].  Details of address format, scoping rules, etc., are
   beyond the scope of this memo.  SNTPv4 can operate with either
   unicast (point to point), broadcast (point to multipoint) or
   anycast (multipoint to point) addressing modes.

>>  Anycast addresses are not "multipoint to point".  They are not
>>  easily mapped onto this terminology, since they are a special type
>>  of "point to multipoint" address that can be used to establish
>>  "point to nearest point" communication.

   Anycast is designed for use with a set of cooperating servers whose
   addresses are not known beforehand.  The anycast client sends an
   ordinary NTP client request to a designated broadcast address.

>>  An anycast address shouldn't be a broadcast address, at least not
>>  in IPv6 anycast.

   One
   or more anycast servers listen on that address.  Upon receiving a
   request, an anycast server sends an ordinary NTP server reply to the
   client.

>>  This description should indicate what source address the server
>>  uses in this reply.  Presumably one of its own normal unicast
>>  addresses?  Does it need to be the same IP version (v4 or v6) as
>>  the anycast address on which the request was received?

   The client and server addresses are assigned following the usual
   IPv4, IPv6 or OSI conventions.  For NTP multicast, the IANA has
   reserved the IPv4 group address 224.0.1.1 and the IPv6 group address
   ending :101, with prefix determined by scoping rules.  The NTP
   broadcast address for OSI has yet to be determined.  Notwithstanding
   the IANA reserved addresses, other multicast addresses can be used
   which do not conflict with others assigned in scope.  In the case of
   IPv4 multicast or IPv6 broadcast addresses, the client must implement

>>  There is no such thing as an IPv6 broadcast address.

   the Internet Group Management Protocol (IGMP) as described in RFC-
   3376 [CAIN02], in order that the local router joins the multicast

>>  A reference to MLD (RFC 3810) should be included here.

      In the case of SNTP as specified herein, there is a very real
      vulnerability that SNTP broadcast clients can be disrupted by
      misbehaving or hostile SNTP or NTP broadcast servers elsewhere in
      the Internet.

>>  It is not my understanding that broadcasts (of any type) are
>>  typically forwarded across the Internet, or even between local
>>  subnets.  Perhaps this is intended to discuss multicast servers?

      It is strongly recommended that access controls
      and/or cryptographic authentication means be provided for
      additional security in such cases.

>>  How would cryptographic authentication apply to a broadcast,
>>  mutlicast or anycast service?

      While not integral to the SNTP specification, it is intended that
      IP broadcast addresses will be used primarily in IP subnets and
      LAN segments including a fully functional NTP server with a number
      of dependent SNTP broadcast clients on the same subnet, while IP
      multicast group addresses will be used only in cases where the TTL
      is engineered specifically for each service domain.

>>  The discussion of TTL use for this purpose should either include a
>>  reference or be described in more detail in the eventual
>>  specification.

4.  Message Format

   Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
   specified in RFC-768 [POS80], which itself is a client of the
   Internet Protocol (IP) specified in RFC-791) [DAR81].

>>  s/client of/application of/  ??
>>  Also, a reference to IPv6 seems to be missing.

   The structure
   of the IP and UDP headers is described in the cited specification
   documents and will not be detailed further here.  The UDP port number
   assigned by the IANA to NTP is 123.  The SNTP client should use this
   value in the UDP Destination Port field for client request messages.
   The Source Port field of these messages can be any nonzero value
   chosen for identification or multiplexing purposes.  The server
   interchanges these fields for the corresponding reply messages.

      This differs from the RFC-2030 specifications which required both
      the source and destination ports to be 123.  The intent of this
      change is to allow the identification of particular client
      implementations (which are now allowed to use unreserved port
      numbers, including ones of their choosing)

>>  In what way does allowing the client port to be unspecified allow
>>  the "identification of particular client implementations"?  The
...snip...
>>... single system (sharing a single IP
>>  address), which seems to be missed altogether here.  Would that
>>  even apply to SNTP?

   Leap Indicator (LI): This is a two-bit code warning of an impending
   leap second to be inserted/deleted in the last minute of the current
   day.  This field is significant only in server messages, where the
   values are defined as follows:

>>  The values aren't defined until after the packet format, which is
>>  confusing.  This is probably just a formatting error?

      LI       Meaning
      ---------------------------------------------
      0        no warning
      1        last minute has 61 seconds
      2        last minute has 59 seconds)
      3        alarm condition (clock not synchronized)

>>  The alarm condition of the Leap Indicator seems important.  What
>>  are clients supposed to do if they receive this flag in a response?
>>  The later text describes when servers should set it (at start-up,
>>  before finding a time source), but doesn't say what a client should
>>  do if this flag is received.

   Mode: This is a three-bit number indicating the protocol mode.  The
   values are defined as follows:

      Mode     Meaning
      ------------------------------------
      0        reserved
      1        symmetric active
      2        symmetric passive
      3        client
      4        server
      5        broadcast
      6        reserved for NTP control message
      7        reserved for private use

   In unicast and anycast modes, the client sets this field to 3
   (client) in the request and the server sets it to 4 (server) in the
   reply.  In broadcast mode, the server sets this field to 5
   (broadcast).  The other modes are not used by SNTP servers and
   clients.

>>  What should SNTP servers and clients do if they receive messages
>>  with other modes set?  There is ambiguous/conflicting text about
>>  this later in the document.

5.  SNTP Client Operations

   A SNTP client can operate in unicast, broadcast or anycast modes.  In
   unicast mode the client sends a request (NTP mode 3) to a designated
   unicast server and expects a reply (NTP mode 4) from that server.  In
   broadcast client mode it sends no request and waits for a broadcast
   (NTP mode 5) from one or more broadcast servers.  In anycast mode,
   the client sends a request (NTP mode 3) to a designated broadcast

>>  s/broadcast/anycast

   than the selection of address in the request, the operations of
   anycast and unicast clients are identical.

>>  Will anycast clients retry using the anycast address if their
>>  initial unicast server stops responding?

   1. When the IP source and destination addresses are available for the
      client request, they should match the interchanged addresses in
      the server reply.

>>  This only applies to unicast requests, at least for the client
>>  destination address.

   2. When the UDP source and destination ports are available for the
      client request, they should match the interchanged ports in the
      server reply.

>>  I don't think that these are rational checks at the SNTP level.  If
>>  the client address or port doesn't match, the response won't go to
>>  the right host/process.  And, checking the server address and port
>>  doesn't seem to have any real benefits.

   4. The server reply should be discarded if any of the LI, Stratum, or
      Transmit Timestamp fields are 0 or the Mode field is not 4
      (unicast) or 5 (broadcast).

>>  This seems to be a section on optional checks, but the value of the
>>  mode field would seem like an important thing to check on any
>>  reply, to me.
>>
>>  Should the response also be discarded if the LI is set to 3
>>  (unsychronized)?

   the NTP header, and sends a reply (NTP mode 4), possibly using the
   same message buffer as the request.

>>  The comment about "possibly using the same message buffer" would
>>  seem to be an implementation detail.

   A anycast server listens on the
   designated broadcast address, but uses its own unicast IP address in
   the source address field of the reply.  Other than the selection of
   address in the reply, the operations of anycast and unicast servers
   are identical.  Broadcast messages are normally sent at poll
   intervals from 64 s to 1024 s, depending on the expected frequency
   tolerance of the client clocks and the required accuracy.

>>  s/poll intervals/intervals

   If the Mode field of the request is 3 (client), the reply is set to 4
   (server).  If this field is set to 1 (symmetric active), the reply is
   set to 2 (symmetric passive).

>>  Earlier, it was said that Modes 1 and 2 are not used used in SNTP
>>  and that clients should discard messages that don't have Mode set
>>  to 4 or 5.

7.  Configuration and Management

   Initial setup for SNTP servers and clients can be done using a web
   client, if available, or a serial port if not.

>>  Implementation details, IMO.

   Broadcast servers and anycast clients must be provided with the TTL
   and local broadcast or multicast group address.  Unicast and anycast
   servers and broadcast clients may be configured with a list of
   address-mask pairs for access control, so that only those clients or
   servers known to be trusted will be accepted.  Multicast servers and
   clients must implement the IGMP protocol and be provided with the

>>  s/IGMP/IGMP or MLD

   1. A client MUST NOT under any conditions use a poll interval less
      than one minute.

   2. A client SHOULD increase the poll interval using exponential
      backoff as performance permits and especially if the server does
      not respond within a reasonable time.

>>  I don't understand what this means...  Should the client increase
>>  the poll interval in normal operations?  Or only when packets are
>>  lost?

13.  Security Considerations

   Security issues are not discussed in this memo.

>>  Since timestamps are often used for security, this seems completely
>>  unacceptable.  Besides, it isn't true -- this memo discusses
>>  authentication and talks about using lists of IP addresses for
>>  access control.

  The Security Considerations section is unacceptable.  Given the 
  fact that an authentication mechanism is defined, I think it is
  straightforward to add a paragraph about the consequences of not
  using the authentication mechanism.

  The Abstract talks about a public-key based authentication scheme
  designed specifically for broadcast and anycast applications that is
  described in another (as yet unpublished) RFC.  The Abstract says
  that these extensions should be considered provisional until a
  definitive specification is published.  However, the document does
  not describe extensions for a public-key-based authentication
  mechanism.  It does describe a symmetric-key-based authentication
  scheme, further clouding the issue.

Section 13 probably needs to be more than "Security issues are not discussed in this memo", but I'll leave that to Sam and Russ.

I am very glad to read that this is intended as a snapshot and
that a working group will clean this up.  I believe the anycast
language needs serious work, as does the kiss of death.  I
fervently hope that the entire best practices section will be
re-written from the ground up, as it could now be read to imply
that backoff should stop at 1 minute poll intervals.