Internet DRAFT - draft-bcd-6man-ntp-server-ra-opt
draft-bcd-6man-ntp-server-ra-opt
Network Working Group M. Bhatia
Internet-Draft Alcatel-Lucent
Intended status: Standards Track X. Chen
Expires: June 22, 2012 D. Zhang
Huawei
December 20, 2011
IPv6 Router Advertisement Option for NTP Server Configuration
draft-bcd-6man-ntp-server-ra-opt-00
Abstract
This document specifies a new IPv6 Router Advertisement option to
allow IPv6 routers to advertise Network Time Protocol version 4 or
greater server location information to IPv6 hosts.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 22, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Bhatia, et al. Expires June 22, 2012 [Page 1]
Internet-Draft IPv6 Router Advertisement Support for NTP December 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 4
3.1. NTP Server Unicast Address Suboption . . . . . . . . . . . 5
3.2. NTP Server Multicast Address Suboption . . . . . . . . . . 6
3.3. NTP Server FQDN Suboption . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Bhatia, et al. Expires June 22, 2012 [Page 2]
Internet-Draft IPv6 Router Advertisement Support for NTP December 2011
1. Introduction
NTP [RFC5905] 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 [RFC4861], IP address of
the DNS servers [RFC5006], 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
Bhatia, et al. Expires June 22, 2012 [Page 3]
Internet-Draft IPv6 Router Advertisement Support for NTP December 2011
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.
2. Overview
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).
3. Neighbor Discovery Extension
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) [RFC4330]
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
Bhatia, et al. Expires June 22, 2012 [Page 4]
Internet-Draft IPv6 Router Advertisement Support for NTP December 2011
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 ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NTP Server Option in the RA
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.
3.1. NTP Server Unicast Address Suboption
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.
Bhatia, et al. Expires June 22, 2012 [Page 5]
Internet-Draft IPv6 Router Advertisement Support for NTP December 2011
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NTP Server Unicast Address Suboption
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
3.2. NTP Server Multicast Address Suboption
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Figure 2: NTP Server Multicast Address Suboption
Fields:
Type: 8 bit identifier of the NTP Server Multicast Address Suboption
- To be assigned by IANA.
Bhatia, et al. Expires June 22, 2012 [Page 6]
Internet-Draft IPv6 Router Advertisement Support for NTP December 2011
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
3.3. NTP Server FQDN Suboption
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Figure 2: NTP Server FQDN Suboption
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 [RFC3315].
Internationalized domain names are not allowed in this field.
4. Security Considerations
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 [RFC3971],
and the NTPS transport is integrity-protected.
Bhatia, et al. Expires June 22, 2012 [Page 7]
Internet-Draft IPv6 Router Advertisement Support for NTP December 2011
5. IANA Considerations
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 [RFC5226].
6. Acknowledgements
This document is built upon draft-chen-ntps-ra-opt-00 which expired
eons ago.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
7.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Option for DNS Configuration",
RFC 5006, September 2007.
Bhatia, et al. Expires June 22, 2012 [Page 8]
Internet-Draft IPv6 Router Advertisement Support for NTP December 2011
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses
Manav Bhatia
Alcatel-Lucent
Email: manav.bhatia@alcatel-lucent.com
Xu Chen
Huawei
Email: zhangdacheng@huawei.com
Dacheng Zhang
Huawei
Email: zhangdacheng@huawei.com
Bhatia, et al. Expires June 22, 2012 [Page 9]
