idnits 2.17.1 draft-xia-dhc-host-gen-id-04.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 25, 2011) is 4750 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) == Unused Reference: 'I-D.ietf-csi-dhcpv6-cga-ps' is defined on line 366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-09) exists of draft-ietf-csi-dhcpv6-cga-ps-06 == Outdated reference: A later version (-07) exists of draft-ietf-dhc-secure-dhcpv6-02 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Intended status: Standards Track S. Jiang 5 Expires: October 27, 2011 Huawei Technologies 6 April 25, 2011 8 Prefix Assignment in DHCPv6 9 draft-xia-dhc-host-gen-id-04.txt 11 Abstract 13 This document describes a procedure for configuring hosts' IPv6 14 address which the prefix is assigned from a DHCPv6 server through 15 DHCPv6 protocol while the interface identifiers are independently 16 generated by the hosts. The method is applicable to 17 Cryptographically Generated Addresses (CGA), and other host-generated 18 IPv6 addresses. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 27, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Address Auto-configuration . . . . . . . . . . . . . . . . . . 4 57 4. DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. DHCPv6 IA_PA Option . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. Identity Association for Prefix Assignment Option . . . . . 6 60 5.2. IA_PA Prefix Option . . . . . . . . . . . . . . . . . . . . 7 61 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 10.2. Informative references . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 [RFC3315] describes the operation of address assignment by a DHCPv6 73 server. A client uses a Solicit message to discover DHCPv6 servers 74 configured to assign addresses. A server sends an Advertise message 75 in response to announce the availability of the server to the client. 76 The client then uses a Request message to request addresses. The 77 server then returns addresses in a Reply message. The operation 78 assumes that the server is responsible for the assignment of an 79 integral address which include prefix and interface identifier parts 80 as described in [RFC4291]. 82 [RFC3633] defines Prefix Delegation options providing a mechanism for 83 automated delegation of IPv6 prefixes using the DHCPv6. This 84 mechanism is intended for delegating a long-lived prefix from a 85 delegating router to a requesting router. The practice of separating 86 prefix assignment from interface identifier assignment is only used 87 for routers not hosts. 89 [RFC3972] describes a method for binding a public signature key to an 90 IPv6 address in the Secure Neighbor Discovery (SEND) protocol 91 [RFC3971]. The basic idea is to generate the interface identifier 92 (i.e., the rightmost 64 bits) of the IPv6 address by computing a 93 cryptographic hash of the public key. That is, the host decides its 94 interface identifier. As for the prefix part of the CGA, it is 95 probably got through Router Advertisement message defined in 96 [RFC4861], or through DHCPv6 operations defined in this document. 98 [I-D.ietf-csi-dhcpv6-cga-ps]describes potential issues in the 99 interaction between DHCPv6 and CGA. The usage of DHCPv6 for 100 generating CGA is proposed in the document to facilitate separation 101 of prefix and interface identifier assignment. A host's IPv6 address 102 prefix is allocated from a DHCPv6 server while interface identifier 103 is independently generated by the host. 105 There are also other host-generated IPv6 addresses. Modified EUI-64 106 interface identifier [EUI-64] is typically generated by hosts. The 107 DHCPv6 operations defined in this document also supports such address 108 methods. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 The terminology in this document is based on the definitions in 118 [RFC3315], in addition to the ones specified in this section 120 derivative prefix: A prefix is derived from another prefix. For 121 example, a /64 prefix is derived from a /48 prefix, that is, the 122 /64 prefix has the same leftmost 48 bits with the /48 prefix. 123 authorized prefix: A specific router is given a specific set of 124 subnet prefixes to advertise; other routers have an authorization 125 to advertise other subnet prefixes. In [RFC3971],Certification 126 Path Advertisement message is used to convey authorized prefixes. 128 3. Address Auto-configuration 130 Router Advertisements in [RFC4861] allow routers to inform hosts how 131 to perform Address Auto-configuration. For example, routers can 132 specify whether hosts should use DHCPv6 and/or stateless address 133 configuration. In Router Advertisement message, M and O bits are 134 used for indication of address auto-configuration mode. 136 Whatever address auto-configuration mode a host uses, the following 137 two parts are necessary for the host to formulate it's IPv6 address: 139 o A prefix. In [RFC3971], Certification Path Solicitation and 140 Certification Path Advertisement messages are designed for 141 verifying routers being authorized to act as routers. 142 Certification Path Advertisement message can also be used to 143 verify that routers are authorized to advertise a certain set of 144 subnet prefixes. In the stateless auto-configuration address 145 mode, the prefixes in Router Advertisement message should be a 146 subset of authorized prefixes, or derivative prefixes from 147 authorized prefixes. In the stateful auto-configuration address 148 mode, prefix assignment from a DHCPv6 server is not currently 149 support. 150 o An interface identifier. Modified EUI-64 interface identifier 151 [EUI-64] is a widely-used host generated interface identifier. It 152 generates interface identifier from the host MAC address. The 153 interface identifier of [RFC3972] is generated by computing a 154 cryptographic hash of a public key of a host. The host is 155 responsible for interface identifier generation. 157 In the ND-managed environment, RA is used to assign the prefix. 159 So far, there is no mechanism to support the scenario that prefixes 160 are managed by a DHCPv6 server. The DHCPv6 operation defined in this 161 document enables the DHCPv6 server to assign a prefix, rather than a 162 integral address, to the host, so that the host can obtain an IPv6 163 address by combining the prefix with its own generated interface 164 identifier. It actually enables the auto address configuration 165 through DHCPv6. 167 4. DHCPv6 Operation 169 Figure 1 shows the operation of separating prefix assignment and 170 interface identifier generation in the DHCPv6. 171 +------------+ +-------------+ 172 |Host(Client)| |DHCPv6 Server| 173 +------------+ +-------------+ 174 | 1 Solicit | 175 |---------------------> | 176 | 2 Advertise | 177 |<--------------------- | 178 3 Combination of Prefix | 179 and Interface Identifier | 180 | | 182 Figure 1: DHCPv6 Operation 184 1. A host uses a Solicit message to discover DHCPv6 servers that 185 have been configured to assign prefixes for the host. Identity 186 Association for Prefix Delegation Option (IA_PD) is defined in 187 [RFC3633] for prefix delegation between a requesting router and 188 delegating router. Referring to the definition, a new Identity 189 Association for Prefix Assignment (IA-PA) option is defined in 190 Section 5.1 to enable the prefix assignment from a DHCPv6 server 191 to a host. 192 2. The DHCPv6 server assigns one or more prefixes to the host in 193 Advertise messages or in the Reply messages to the prefix 194 requests from the hosts. The assigned prefixes SHOULD be a 195 subset of the authorized prefixes or derivative prefixes of the 196 authorized prefixes. Identity Association for Prefix Assignment 197 Option in Section 5.1 is used for conveying the assigned 198 prefixes. If there is not a proper prefix available, a status- 199 code is returned to the host and the procedure is terminated. 200 When receiving multiple prefixes, the host may use pre-configured 201 hints for prefix assignment preference. The hints are authorized 202 prefixes advertised by an authorized router through Certification 203 Path Advertisement defined in [RFC3971]. 204 3. The host generates an interface identifier and formulates a 205 combined IPv6 address by concatenating the assigned prefix and 206 the self-generated interface identifier. There are many ways to 207 generate interface identifier. [RFC3972] defines a method to 208 generate the interface identifier by computing a cryptographic 209 hash of a public key of the host. Modified EUI-64 interface 210 identifier [EUI-64] is generated based on the host MAC address. 212 After the host generates an IPv6 address using the above procedure, 213 the host may send a Request message to the DHCPv6 server in order to 214 confirm the usage of the new address. The confirmation procedure may 215 be completed together with the address registration procedure. 216 However, the confirmation procedure is out of scope. 218 5. DHCPv6 IA_PA Option 220 In this section, one new option is defined, Identity Association for 221 Prefix Assignment Option . At the same time, we extend the usage of 222 existing options, IA_PD Prefix and IA Address option. 224 5.1. Identity Association for Prefix Assignment Option 226 The IA_PA option is used to carry a prefix assignment identity 227 association, the parameters associated with the IA_PA and the 228 prefixes associated with it. 230 The format of the IA_PA option is: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | OPTION_IA_PA | option-length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | IAID (4 octets) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | T1 | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | T2 | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 . . 244 . IA_PA-options . 245 . . 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 option-code: OPTION_IA_PA (TBA1) 250 option-length: 12 + length of IA_PA-options field. 252 IAID: The unique identifier for this IA_PA; the IAID must 253 be unique among the identifiers for all of this 254 host's IA_PAs. 256 T1: The time at which the host should 257 contact the DHCPv6 server from which the 258 prefixes in the IA_PA were obtained to extend the 259 lifetimes of the prefixes assigned to the IA_PA; 260 T1 is a time duration relative to the current time 261 expressed in units of seconds. 263 T2: The time at which the host should 264 contact any available DHCPv6 server to extend 265 the lifetimes of the prefixes assigned to the 266 IA_PA; T2 is a time duration relative to the 267 current time expressed in units of seconds. 269 IA_PA-options: Options associated with this IA_PA. 271 The details of the fields are similar to the IA_PD option description 272 in [RFC3633]. The difference is here a DHCPv6 server and a host 273 involved, while a delegating router and requesting router involved in 274 [RFC3633]. 276 5.2. IA_PA Prefix Option 278 OPTION_IAPREFIX (26) "IA_PD Prefix Option" defined in Section 10 of 279 [RFC3633] is reused. 281 Originally, the option is used for conveying prefix information 282 between a delegating router and a requesting router. Here the IA_PD 283 Prefix option is used to specify IPv6 address prefixes associated 284 with an IA_PA in Section 5.1. The IA_PD Prefix option must be 285 encapsulated in the IA_PA-options field of an IA_PA option. 287 6. Applicability 289 In point-to-point link model, DHCPv6 operation with host-generated 290 interface identifier, described in this document, may be used. 291 [RFC4968] provides different IPv6 link models that are suitable for 292 802.16 based networks and a point-to-point link model is recommended. 293 Also, 3GPP and 3GPP2 have earlier adopted the point-to-point link 294 model based on the recommendations in [RFC3314]. In this model, one 295 prefix can only be assigned to one interface of a host (mobile 296 station) and different hosts (mobile stations) can't share a prefix. 297 The unique prefix can be used to identify the host. It is not 298 necessary for a DHCPv6 server to generate an interface identifier for 299 the host. The host may generate its interface identifier as 300 described in [RFC4941]. An interface identifier could even be 301 generated via random number generation. 303 7. IANA consideration 305 This document defines a new DHCPv6 [RFC3315] option, which must be 306 assigned Option Type values within the option numbering space for 307 DHCPv6 messages: 309 The OPTION_IA_PA Option (TBA1), described in Section 5.1. 311 8. Security Considerations 313 Security considerations in DHCPv6 are described in [RFC3315]. 315 To guard against attacks through prefix assignment, a host and a 316 DHCPv6 server SHOULD use DHCPv6 authentication as described in 317 Section 21, "Authentication of DHCP messages" of [RFC3315] or Secure 318 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] . 320 9. Acknowledgements 322 The authors would like to thanks Suresh Krishnan and other members of 323 DHC WG for their valuable comments. 325 10. References 327 10.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 333 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 334 September 2007. 336 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 337 Neighbor Discovery (SEND)", RFC 3971, March 2005. 339 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 340 RFC 3972, March 2005. 342 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 343 and M. Carney, "Dynamic Host Configuration Protocol for 344 IPv6 (DHCPv6)", RFC 3315, July 2003. 346 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 347 Host Configuration Protocol (DHCP) version 6", RFC 3633, 348 December 2003. 350 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 351 Architecture", RFC 4291, February 2006. 353 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 354 Extensions for Stateless Address Autoconfiguration in 355 IPv6", RFC 4941, September 2007. 357 10.2. Informative references 359 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 360 Based Networks", RFC 4968, August 2007. 362 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 363 Generation Partnership Project (3GPP) Standards", 364 RFC 3314, September 2002. 366 [I-D.ietf-csi-dhcpv6-cga-ps] 367 Jiang, S., "DHCPv6 and CGA Interaction: Problem 368 Statement", draft-ietf-csi-dhcpv6-cga-ps-06 (work in 369 progress), October 2010. 371 [I-D.ietf-dhc-secure-dhcpv6] 372 Jiang, S., "Secure DHCPv6 Using CGAs", 373 draft-ietf-dhc-secure-dhcpv6-02 (work in progress), 374 December 2010. 376 [EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64) 377 Registration Authority", http://standards.ieee.org/ 378 regauth/oui/tutorials/EUI64.html", March 1997. 380 Authors' Addresses 382 Frank Xia 383 Huawei Technologies 384 1700 Alma Dr. Suite 500 385 Plano, TX 75075 387 Email: xiayangsong@huawei.com 389 Behcet Sarikaya 390 Huawei Technologies 391 1700 Alma Dr. Suite 500 392 Plano, TX 75075 394 Email: sarikaya@ieee.org 396 Sheng Jiang 397 Huawei Technologies 398 KuiKe Building, No.9 Xinxi Rd., 399 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 400 P.R. China 402 Email: jiangsheng@huawei.com