Network Working Group Xu Chen Internet Draft DaCheng Zhang Intended status: Standard Huawei Technologies Co., Ltd. Expires: August 2010 February 25, 2010 The IPv6 Router Advertisement Option for NTP Configuration draft-chen-ntps-ra-opt-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 25, 2010. Chen Expires August 25, 2010 [Page 1] Internet-Draft The IPv6 Router Advertisement Option February 2010 for NTP Configuration Copyright Notice Copyright (c) 2010 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a new ND option, called the NTPS option, that contains the Server location information of Network Time Protocol version 4[draft-ntpv4] or greater. Therefore, hosts can get such information in the same RA message transporting the information of IP address configuration. In this spec, both ND transport mechanisms (i.e., advertisements and solicitations) are considered. Table of Contents 1. Introduction................................................3 2. Definitions.................................................3 3. Terminologies...............................................3 4. Requirement for an NTP Server option........................4 5. Neighbor Discovery Extension................................5 6. Interworking among IPv6 NTP Configuration Approaches........5 7. Security Considerations.....................................6 8. IANA Considerations.........................................6 9. References..................................................7 9.1. Normative References...................................7 9.2. Informative References.................................7 10. Acknowledgments............................................7 Chen Expires August 25, 2010 [Page 2] Internet-Draft The IPv6 Router Advertisement Option February 2010 for NTP Configuration 1. Introduction Beside manual address assignment, several mechanisms have been developed to facilitate IPv6 address assignment. One of the most convenient methods is Stateless Address Autoconfiguration (SLAAC) [RFC2462]. SLAAC use Neighbor Discovery [RFC4861] as an underlining protocol. IPv6 host need only connect to a network with an advertisement router and periodically receive multicast Router Advertisement (RA) on the link. This RA message contains address and link information, like IPv6 prefix and link MTU, to configure a global unicast address. As a complementary method to provide necessary material for an IPv6 host connection to internet and ISP management requirement, DNS Server extension has been defined in [RFC5006]. Another address assignment is based on Dynamic Host Configuration Protocol for IPv6 (DHCPv6). It has been standardized in [RFC3315]. Necessary configuration parameters pass from DHCP Server to DHCP enabled IPv6 host. This protocol can be used in a stateful way which provides address assignment separately or in a stateless way that is combination of DHCPv6 and SLAAC. The later case has been specified in [RFC3736]. IPv6 Host first configures one or more interfaces through SLAAC and then reach stateless DHCP server for additional parameters. At the time of writing this spec, the stateless and stateful address assignment mechanisms are deployed over networks in an ad hoc way. Therefore, an extension in SLAAC normally has an analogue which provides similar functionality in DHCP. For instance, Deployment scenarios for DNS server address configuration with stateless and stateful methods have been compared in [RFC4339]. NTP server addresses, just same as DNS server addresses, are common information to all IPv6 host in a subnet. [DHCPv6-NTP-Option] proposes a DHCP based solution in order to facilitate hosts to access NTP server accessing information. The spec introduces an analogue of this solution in SLAAC. 2. Definitions 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. Chen Expires August 25, 2010 [Page 3] Internet-Draft The IPv6 Router Advertisement Option February 2010 for NTP Configuration 3. Terminologies RA: Router Advertisement RS: Router Solicitation NTP: Network Time Protocol ND: Neighbor Discovery NTPS: NTP Server SNTP: Simple Network Time Protocol 4. Requirement for an NTP Server option When newly attaching to a network, a host can get essential knowledge to configure its IP address via RA messages advertised by a local router. Typically, a router advertises RA messages periodically. Also, hosts can query RAs using Router Solicitations (RSs). Apart from the instruction of IP address configuration, RAs are also used to transport other useful information (e.g., IP addresses of DNS servers). Same as DNS servers, NTP servers are core components of the Internet infrastructure. A NTP server can provide time and synchronization services for hosts in the network, which are critical for many applications (e.g., security mechanisms). The reasons of using RAs to transport the prefix information option based on the ND protocol [RFC4861] are very similar with those of using RAs to transport the information of DNS servers [RFC5006]: 1. It is possible for a host to access the nearest NTP server so as to reduce the latency imposed by transporting packets. 2. NTPS option is an extension of RA. This does not change the base functions of existing ND/SLAAC mechanism. 3. All the information a host 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 ND and address autoconfiguration. 4. The use of a single mechanism is more reliable and easier to provide. Debugging problems when multiple protocol mechanisms are being used is harder and much more complex. Chen Expires August 25, 2010 [Page 4] Internet-Draft The IPv6 Router Advertisement Option February 2010 for NTP Configuration 5. This mechanism works over a broad range of scenarios and leverages IPv6 ND. 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 NTPS information with the other information in the RA, the host can learn all the information needed to use most Internet applications in a single packet. This not only saves bandwidth, but also minimizes the delay needed to learn the NTPS information. The following figure shows an example topology from this scenario. +------------------------------------------------+ | | | Router NTP Server | | | | | | | | +----+----+-------+--------+----+-----+ | | | | | | | | Host Host Host Host | | | | | +------------------------------------------------+ Figure 1 Topology. 5. Neighbor Discovery Extension The proposed IPv6 NTP Server configuration mechanism introduces a new ND option in Neighbor Discovery called the NTP Server (NTPS) option which serves as a container for the Server location information related to a NTP Server or a SNTP Server. The analogue of this mechanism is proposed in DHCPv6 [DHCPv6-NTP-Option]. The NTPS extension option in [DHCPv6-NTP-Option] holds the NTP server address information and performs a similar function with the NTPS option in this spec. In the future version of this draft, it will reference section 6, [DHCPv6-NTP-Option] and include detailed format of NTPS option. 6. Interworking among IPv6 NTP Configuration Approaches The NTPS (NTP Server) option and DHCP option can be used together. To order the RA and DHCP approaches, the O (Other stateful configuration) flag can be used in the RA message [RFC4861]. If no NTPS option is included in the RA messages, an IPv6 host may perform NTP configuration through DHCPv6 [DHCPv6-NTP-Config] regardless of whether the O flag is set or not. Chen Expires August 25, 2010 [Page 5] Internet-Draft The IPv6 Router Advertisement Option February 2010 for NTP Configuration 7. Security Considerations Because NTPS option does not change the base functions of existing ND/SLAAC mechanism, it can be claimed that the RA option for NTPS 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 NTPS option are automatically included in the signatures [RFC3971], so the NTPS transport is integrity-protected. 8. IANA Considerations The IANA need assign a new IPv6 Neighbor Discovery Option type for NTPS option. Chen Expires August 25, 2010 [Page 6] Internet-Draft The IPv6 Router Advertisement Option February 2010 for NTP Configuration 9. References 9.1. Normative References [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4339] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [DRAFT-NTPv4] Burbank, Kasch, Ed., Mills, Delaware, "Network Time Protocol Version 4 Protocol And Algorithms Specification", draft-ietf-ntp-ntpv4-proto-13, October 9, 2009. [DHCPv6-NTP-Option] Gayraud, Lourdelet, "Network Time Protocol (NTP) Server Option for DHCPv6", January 7, 2010 9.2. Informative References [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC5006] Jeong, Park, Beloeil, Madanapalli, " IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007. [RFC3315] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6(DHCPv6)", RFC 3315, July 2003. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Chen Expires August 25, 2010 [Page 7] Internet-Draft The IPv6 Router Advertisement Option February 2010 for NTP Configuration Authors' Addresses Xu Chen Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-82836074 Email: chenxu0128@huawei.com DaCheng Zhang Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-82836072 Email: zhangdacheng@huawei.com Chen Expires August 25, 2010 [Page 8]