Network Working Group R. Gayraud Internet-Draft B. Lourdelet Intended status: Standards Track Cisco Systems, Inc. Expires: May 10, 2008 November 7, 2007 Network Time Protocol (NTP) Options for DHCPv6 draft-gayraud-dhcpv6-ntp-opt-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 May 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes two new DHCPv6 options for passing Network Time Protocol (NTP) configuration parameters to a DHCP client. Table of Contents 1. Requirements notation 2. Introduction 2.1. Related Work and Usage Model 3. NTP Server Option for DHCPv6 4. NTP Multicast Group Option for DHCPv6 5. Appearance of These Options 6. Security Considerations 7. IANA Considerations 8. References 8.1. Normative References 8.2. Informative References Authors' Addresses Intellectual Property and Copyright Statements 1. Requirements notation 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 [RFC2119]. 2. Introduction This document defines two new DHCPv6 options to pass NTP version 4 [draft-ntpv4] configuration to client devices. 2.1. Related Work and Usage Model "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6" [RFC4075] provides some degree of automatic time server configuration for IPv6, as it specify how to transmit SNTP servers addresses through DHCPv6. However, it does not specify how general purpose NTP servers addresses can be configured. The majority of time servers used by hosts to synchronize their clocks over a LAN are full- featured NTP servers, not SNTP. In addition to servers addresses, the NTPv4 specification defines a comprehensive set of configuration parameters. Some of these parameters are relevant in the context of DHCPv6. The capability to transmit some of the well-known NTP configutation parameters over DHCPv6 will enable more versatile NTP deployments. Clients wont be tied to a pre-loaded NTP configuration. An obvious application is to configure the clients in a way that greatly reduces NTP traffic. 3. NTP Server Option for DHCPv6 This option specifies an NTP server address available to the client, as well as some additional configuration parameters for this server. A client receiveing this option SHOULD use this NTP server address to synchronize its own clock. This option can appear multiple times in a DHCPv6 message. Each instance specifies one available NTP server. The format of this 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NTP_SERVER | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NTP server (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxPoll | MinPoll |I|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_NTP_SERVER (TBD_IANA_1) option-len: 20 bytes. NTP server: IPv6 address of the NTP server. MaxPoll(MinPoll): Maximum(Minimum) polling interval to use when talking to this server, as a power of 2. Acceptable values for this parameter are in the [4-16] interval. 0 (zero) is also acceptable: it informs the client that it can ignore this parameter and use any value of its choice for MaxPoll(MinPoll). When this parameter is set, the client SHOULD use this value for MAXPOLL(MINPOLL), as defined in [draft-ntpv4]. The intend of MaxPoll and MinPoll as DHCP option parameters is to control the tradeoff between the amount of traffic generated by NTP, and clock quality. I: When this flag is set, the client SHOULD perform the 'I-burst' procedure as described in [draft-ntpv4] section 13. B: When this flag is set, the client SHOULD perform the 'burst' procedure as described in [draft-ntpv4] section 13. 4. NTP Multicast Group Option for DHCPv6 This option specifies an IPv6 multicast group address available for clients to join, in order to receive NTP multicast messages, as well as an optionnal delay to be used by the client for multicast messages. This option can appear multiple times in a DHCPv6 message. Each instance specifies one available IPv6 multicast group. A client that receives this options SHOULD use the specified multicast group to synchronize its clock. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_NTP_MULTICAST | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NTP multicast group (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay (nanoseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_NTP_MULTICAST (TBD_IANA_2) option-len: 20 bytes. NTP multicast group: IPv6 multicast group address to be used by the client. The client receiving this option SHOULD join this multicast group as a listener and use NTP messages received on this group to form NTP multicast client associations as described in [draft-ntpv4]. Delay: The amount of time (in nanoseconds) the client should assume as the delay introduced by the network on the path of NTP multicast messages send to this address. A client receiving this option SHOULD NOT send an initial volley of NTP messages when first synchronizing its clock with this Multicast address. If this value is 0 (zero), the client may use any other mechanism to compute the network delay, including the initial volley described in [draft-ntpv4]. 5. Appearance of These Options The NTP Servers Option and NTP Multicast Group Option can appear a multiple number of times in a DHCPv6 message. The order in which these options appear in a message is not relevant. The client use its usual algorithms to determine which server(s) or multicast group(s) should be prefered to synchronize its clock. The NTP Servers Option and NTP Multicast Group Option MUST NOT appear in messages other than the following: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply. If this option appears in messages other than those specified above, the receiver SHOULD ignore it. The option number for these options MAY appear in the "Option Request" Option [RFC3315] in the following messages: Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure. If this option number appears in the "Option Request" Option in messages other than those specified above, the receiver SHOULD ignore it. 6. Security Considerations These options could be used by an intruder to adversely affect the time of a client. The consequences of such an attack are described in [RFC4075] section 6. To prevent such an attack, it is strongly advisable to use authenticated DHCP as described in [RFC3315] section 21. 7. IANA Considerations When this document is published, the IANA is requested to assign an option code from the "DHCPv6 Options Codes" registry for OPTION_NTP_SERVER and OPTION_NTP_MULTICAST. 8. References 8.1. Normative 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. [draft-ntpv4] Burbank, J., Kasch, W., Martin, J., and D. Mills, "Network Time Protocol Version 4 Protocol And Algorithms Specification", draft-ietf-ntp-ntpv4-proto-07 (work in progress), May 2007. 8.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6", RFC 4075, May 2005. Authors' Addresses Richard Gayraud Cisco Systems, Inc. Village ent. GreenSide, Bat T3, 400, Av de Roumanille, 06410 BIOT - Sophia-Antipolis Cedex France Phone: +33 4 97 23 26 49 Email: rgayraud@cisco.com Benoit Lourdelet Cisco Systems, Inc. Village ent. GreenSide, Bat T3, 400, Av de Roumanille, 06410 BIOT - Sophia-Antipolis Cedex France Phone: +33 4 97 23 26 23 Email: blourdel@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).