IPv6 Router Advertisement Option for NTP Server Configuration

NTP servers form a core component of the Internet infrastructure. They are used to provide time and synchronization services for hosts and routers in a network, which is critical for many applications (event logging, security mechanisms and other services). In order to synchronize the time, all routers and hosts need to be configured to point to a NTP server that will provide clocking to all the devices. This ensures accurate and synchronized time among all devices. Its usually recommended to choose among several NTP servers in case one of the servers becomes unreachable or its clock becomes unreliable. Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address Autoconfiguration provide ways to configure either fixed or mobile nodes with one or more IPv6 addresses, default routers and some other parameters like the link-layer address of the interface from which the Router Advertisement is sent, link MTU , IP address of the DNS servers , etc. This document proposes a new mechanism which uses a new IPv6 Router Advertisement (RA) option to allow IPv6 routers to advertise NTP server addresses to IPv6 hosts. RA-based NTP configuration is a useful, optional alternative in networks where an IPv6 host's address is autoconfigured through IPv6 stateless address autoconfiguration, and where the delays in acquiring server addresses and communicating with the servers are critical. RA-based NTP configuration allows the host to acquire the nearest server addresses on every link. Furthermore, it learns these addresses from the same RA message that provides configuration information for the link, thereby avoiding an additional protocol run. This can be beneficial in some mobile environments, such as with Mobile IPv6. The NTP Server Option that this document proposes is an extension of Router Advertisment. It does not change the basic function of the existing ND/SLAAC mechanisms. Information that an IPv6 host or a router needs to run the basic Internet applications (such as the Clock Synchronization, Timestamp Verification, Certificate Expiration check, etc.) can be obtained with the addition of this option to Neighbor Discovery and address autoconfiguration. This mechanism works over a broad range of scenarios and leverages IPv6 Neighbor Discovery. This works well on links that are high performance (e.g., Ethernet LANs) and low performance (e.g., cellular networks). In the latter case, by combining the NTP server information (that this draft proposes) with the other information in the Router Advertisement, the IPv6 devices can learn all the information needed to use most Internet applications in a single transaction. This not only saves bandwidth, but also minimizes the delay needed to learn the NTP server information.

This document defines a new ND option called NTP Server option that contains the addresses of the NTP servers. Existing ND transport mechanisms (i.e., Advertisements and Solicitations) are used. This works in the same way that hosts learn about routers and prefixes. An IPv6 host can configure the IPv6 addresses of one or more NTP servers via RA messages periodically sent by a router or solicited by Router Solicitation (RS) messages. This approach requires NTP Server information to be configured in the routers sending the advertisements. The configuration of NTP server addresses in the routers can be done by manual configuration. The automatic configuration of NTP server addresses in routers is out of scope for this document. The location of the NTP service, like any other Internet service, can be specified by an IP address or a Fully Qualified Domain Name (FQDN).

The IPv6 NTP configuration mechanism in this document defines a new ND option in Neighbor Discovery - the NTP Server (NTPS) option. This option serves as a container for server location information related to one NTP server or Simple Network Time Protocol (SNTP) server. This option can appear multiple times in a RA message. Each instance of this option is to be considered by the NTP client or SNTP client as a server to include in its configuration. The option itself does not contain any value. Instead, it contains one or several suboptions that carry NTP server or SNTP server location. This option MUST include one, and only one, time source suboption. It carries the NTP server or SNTP server location as a Unicast or Multicast IPv6 address or as an NTP server or SNTP server FQDN. More time source suboptions may be defined in the future. While the FQDN option offers the most deployment flexibility, resiliency as well as security, the IP address options are defined to cover cases where a DNS dependency is not desirable. If the NTP server or SNTP server location is an IPv6 multicast address, the client SHOULD use this address as an NTP multicast group address and listen to messages sent to this group in order to synchronize its clock. The format of the NTP Server (NTPS) Option is:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ NTP Server Address Sub Options ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ Padding ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 8 bit identifier of the NTP Server option type in the RA message - To be assigned by IANA. Length: 8 bit unsigned integer. Total length of the included sub options (including the Type and Length fields) is in units of 8 octets. NTP Server Address Sub Options : List of NTP server addresses sub options Padding: It is optional and is used, if required, to preserve IPv6 8-octet alignment.

This suboption is intended to appear inside the NTP Server Option within the RA message. It specifies the IPv6 unicast address of an NTP server or SNTP server available to the client.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Unicast IPv6 address of NTP server | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 8 bit identifier of the NTP Server Unicast Address Suboption - To be assigned by IANA. Length:8 bit unsigned integer. Total length of the sub options (including the Type and Length fields) in octets. Its set to 18 Unicast IPv6 address of NTP server: An IPv6 Address

This suboption is intended to appear inside the NTP Server Option within the RA message. It specifies the IPv6 Multicast Group address of an NTP server or SNTP server available to the client.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Multicast IPv6 address of NTP server | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fields: Type: 8 bit identifier of the NTP Server Multicast Address Suboption - To be assigned by IANA. Length:8 bit unsigned integer. Total length of the sub options (including the Type and Length fields) in octets. Its set to 18 Multicast IPv6 address of NTP server: An IPv6 Address

This suboption is intended to appear inside the NTP Server Option within the RA message. It specifies the FQDN of an NTP server or SNTP server available to the client.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | FQDN of NTP server | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fields: Type: 8 bit identifier of the NTP Server FQDN Suboption - To be assigned by IANA. Length:8 bit unsigned integer. Total length of the FQDN field and including the Type and Length fields in octets. FQDN of NTP server: Fully-Qualified Domain Name of the NTP server or SNTP server. This field MUST be encoded as described in . Internationalized domain names are not allowed in this field.

Because NTPS option does not change the base functions of existing ND/SLAAC mechanism, it can be claimed that the NTP Server option for RA has vulnerabilities similar to those existing in current mechanisms. If the Secure Neighbor Discovery (SEND) protocol is used as a security mechanism for ND, all the ND options including the NTP Server option are automatically included in the signatures , and the NTPS transport is integrity-protected.

IANA needs to assign an option code for the NTP Server Option that will be used in the Router Advertisments. IANA is required to maintain a new number space of NTP Server suboptions as defined in this document. IANA should assign future NTP time source suboptions with an "IETF Consensus" policy as described in .

This document is built upon draft-chen-ntps-ra-opt-00 which expired eons ago.