idnits 2.17.1 draft-bcd-6man-ntp-server-ra-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 35 instances of too long lines in the document, the longest one being 68 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 20, 2011) is 4482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track X. Chen 5 Expires: June 22, 2012 D. Zhang 6 Huawei 7 December 20, 2011 9 IPv6 Router Advertisement Option for NTP Server Configuration 10 draft-bcd-6man-ntp-server-ra-opt-00 12 Abstract 14 This document specifies a new IPv6 Router Advertisement option to 15 allow IPv6 routers to advertise Network Time Protocol version 4 or 16 greater server location information to IPv6 hosts. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 22, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 4 61 3.1. NTP Server Unicast Address Suboption . . . . . . . . . . . 5 62 3.2. NTP Server Multicast Address Suboption . . . . . . . . . . 6 63 3.3. NTP Server FQDN Suboption . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 NTP [RFC5905] servers form a core component of the Internet 75 infrastructure. They are used to provide time and synchronization 76 services for hosts and routers in a network, which is critical for 77 many applications (event logging, security mechanisms and other 78 services). In order to synchronize the time, all routers and hosts 79 need to be configured to point to a NTP server that will provide 80 clocking to all the devices. This ensures accurate and synchronized 81 time among all devices. Its usually recommended to choose among 82 several NTP servers in case one of the servers becomes unreachable or 83 its clock becomes unreliable. 85 Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address 86 Autoconfiguration provide ways to configure either fixed or mobile 87 nodes with one or more IPv6 addresses, default routers and some other 88 parameters like the link-layer address of the interface from which 89 the Router Advertisement is sent, link MTU [RFC4861], IP address of 90 the DNS servers [RFC5006], etc. 92 This document proposes a new mechanism which uses a new IPv6 Router 93 Advertisement (RA) option to allow IPv6 routers to advertise NTP 94 server addresses to IPv6 hosts. 96 RA-based NTP configuration is a useful, optional alternative in 97 networks where an IPv6 host's address is autoconfigured through IPv6 98 stateless address autoconfiguration, and where the delays in 99 acquiring server addresses and communicating with the servers are 100 critical. RA-based NTP configuration allows the host to acquire the 101 nearest server addresses on every link. Furthermore, it learns these 102 addresses from the same RA message that provides configuration 103 information for the link, thereby avoiding an additional protocol 104 run. This can be beneficial in some mobile environments, such as 105 with Mobile IPv6. 107 The NTP Server Option that this document proposes is an extension of 108 Router Advertisment. It does not change the basic function of the 109 existing ND/SLAAC mechanisms. 111 Information that an IPv6 host or a router needs to run the basic 112 Internet applications (such as the Clock Synchronization, Timestamp 113 Verification, Certificate Expiration check, etc.) can be obtained 114 with the addition of this option to Neighbor Discovery and address 115 autoconfiguration. 117 This mechanism works over a broad range of scenarios and leverages 118 IPv6 Neighbor Discovery. This works well on links that are high 119 performance (e.g., Ethernet LANs) and low performance (e.g., cellular 120 networks). In the latter case, by combining the NTP server 121 information (that this draft proposes) with the other information in 122 the Router Advertisement, the IPv6 devices can learn all the 123 information needed to use most Internet applications in a single 124 transaction. This not only saves bandwidth, but also minimizes the 125 delay needed to learn the NTP server information. 127 2. Overview 129 This document defines a new ND option called NTP Server option that 130 contains the addresses of the NTP servers. Existing ND transport 131 mechanisms (i.e., Advertisements and Solicitations) are used. This 132 works in the same way that hosts learn about routers and prefixes. 133 An IPv6 host can configure the IPv6 addresses of one or more NTP 134 servers via RA messages periodically sent by a router or solicited by 135 Router Solicitation (RS) messages. 137 This approach requires NTP Server information to be configured in the 138 routers sending the advertisements. The configuration of NTP server 139 addresses in the routers can be done by manual configuration. The 140 automatic configuration of NTP server addresses in routers is out of 141 scope for this document. 143 The location of the NTP service, like any other Internet service, can 144 be specified by an IP address or a Fully Qualified Domain Name 145 (FQDN). 147 3. Neighbor Discovery Extension 149 The IPv6 NTP configuration mechanism in this document defines a new 150 ND option in Neighbor Discovery - the NTP Server (NTPS) option. This 151 option serves as a container for server location information related 152 to one NTP server or Simple Network Time Protocol (SNTP) [RFC4330] 153 server. This option can appear multiple times in a RA message. Each 154 instance of this option is to be considered by the NTP client or SNTP 155 client as a server to include in its configuration. 157 The option itself does not contain any value. Instead, it contains 158 one or several suboptions that carry NTP server or SNTP server 159 location. This option MUST include one, and only one, time source 160 suboption. It carries the NTP server or SNTP server location as a 161 Unicast or Multicast IPv6 address or as an NTP server or SNTP server 162 FQDN. More time source suboptions may be defined in the future. 163 While the FQDN option offers the most deployment flexibility, 164 resiliency as well as security, the IP address options are defined to 165 cover cases where a DNS dependency is not desirable. If the NTP 166 server or SNTP server location is an IPv6 multicast address, the 167 client SHOULD use this address as an NTP multicast group address and 168 listen to messages sent to this group in order to synchronize its 169 clock. 171 The format of the NTP Server (NTPS) Option is: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type | Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 | | 180 ~ NTP Server Address Sub Options ~ 181 | | 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 184 | | 185 ~ Padding ~ 186 | | 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1: NTP Server Option in the RA 192 Fields: 194 Type: 8 bit identifier of the NTP Server option type in the RA 195 message - To be assigned by IANA. 197 Length: 8 bit unsigned integer. Total length of the included sub 198 options (including the Type and Length fields) is in units of 8 199 octets. 201 NTP Server Address Sub Options : List of NTP server addresses sub 202 options 204 Padding: It is optional and is used, if required, to preserve IPv6 205 8-octet alignment. 207 3.1. NTP Server Unicast Address Suboption 209 This suboption is intended to appear inside the NTP Server Option 210 within the RA message. It specifies the IPv6 unicast address of an 211 NTP server or SNTP server available to the client. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Length | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 | | 220 | Unicast IPv6 address of NTP server | 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 2: NTP Server Unicast Address Suboption 226 Fields: 228 Type: 8 bit identifier of the NTP Server Unicast Address Suboption - 229 To be assigned by IANA. 231 Length:8 bit unsigned integer. Total length of the sub options 232 (including the Type and Length fields) in octets. Its set to 18 234 Unicast IPv6 address of NTP server: An IPv6 Address 236 3.2. NTP Server Multicast Address Suboption 238 This suboption is intended to appear inside the NTP Server Option 239 within the RA message. It specifies the IPv6 Multicast Group address 240 of an NTP server or SNTP server available to the client. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type | Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 | | 249 | Multicast IPv6 address of NTP server | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 253 Figure 2: NTP Server Multicast Address Suboption 255 Fields: 257 Type: 8 bit identifier of the NTP Server Multicast Address Suboption 258 - To be assigned by IANA. 260 Length:8 bit unsigned integer. Total length of the sub options 261 (including the Type and Length fields) in octets. Its set to 18 263 Multicast IPv6 address of NTP server: An IPv6 Address 265 3.3. NTP Server FQDN Suboption 267 This suboption is intended to appear inside the NTP Server Option 268 within the RA message. It specifies the FQDN of an NTP server or 269 SNTP server available to the client. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 | | 278 | FQDN of NTP server | 279 | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 282 Figure 2: NTP Server FQDN Suboption 284 Fields: 286 Type: 8 bit identifier of the NTP Server FQDN Suboption - To be 287 assigned by IANA. 289 Length:8 bit unsigned integer. Total length of the FQDN field and 290 including the Type and Length fields in octets. 292 FQDN of NTP server: Fully-Qualified Domain Name of the NTP server or 293 SNTP server. This field MUST be encoded as described in [RFC3315]. 294 Internationalized domain names are not allowed in this field. 296 4. Security Considerations 298 Because NTPS option does not change the base functions of existing 299 ND/SLAAC mechanism, it can be claimed that the NTP Server option for 300 RA has vulnerabilities similar to those existing in current 301 mechanisms. If the Secure Neighbor Discovery (SEND) protocol is used 302 as a security mechanism for ND, all the ND options including the NTP 303 Server option are automatically included in the signatures [RFC3971], 304 and the NTPS transport is integrity-protected. 306 5. IANA Considerations 308 IANA needs to assign an option code for the NTP Server Option that 309 will be used in the Router Advertisments. 311 IANA is required to maintain a new number space of NTP Server 312 suboptions as defined in this document. IANA should assign future 313 NTP time source suboptions with an "IETF Consensus" policy as 314 described in [RFC5226]. 316 6. Acknowledgements 318 This document is built upon draft-chen-ntps-ra-opt-00 which expired 319 eons ago. 321 7. References 323 7.1. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 329 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 330 September 2007. 332 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 333 Time Protocol Version 4: Protocol and Algorithms 334 Specification", RFC 5905, June 2010. 336 7.2. Informative References 338 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 339 and M. Carney, "Dynamic Host Configuration Protocol for 340 IPv6 (DHCPv6)", RFC 3315, July 2003. 342 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 343 Neighbor Discovery (SEND)", RFC 3971, March 2005. 345 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 346 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 348 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 349 "IPv6 Router Advertisement Option for DNS Configuration", 350 RFC 5006, September 2007. 352 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 353 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 354 May 2008. 356 Authors' Addresses 358 Manav Bhatia 359 Alcatel-Lucent 361 Email: manav.bhatia@alcatel-lucent.com 363 Xu Chen 364 Huawei 366 Email: zhangdacheng@huawei.com 368 Dacheng Zhang 369 Huawei 371 Email: zhangdacheng@huawei.com