idnits 2.17.1 draft-ietf-dhc-host-gen-id-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2012) is 4327 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 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 (-07) exists of draft-ietf-dhc-secure-dhcpv6-06 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Jiang 3 Internet-Draft F. Xia 4 Intended status: Standards Track B. Sarikaya 5 Expires: November 24, 2012 Huawei Technologies 6 May 23, 2012 8 Prefix Assignment in DHCPv6 9 draft-ietf-dhc-host-gen-id-02 11 Abstract 13 This document introduce 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 IPv6 addresses 18 with host-generated interface identifiers. 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 November 24, 2012. 37 Copyright Notice 39 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 10.2. Informative references . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 A host IPv6 address is combined by a prefix and an interface 73 identifier. Currently, there are two mechanisms to configure a host 74 IPv6 address. [RFC3315] describes the operation of address 75 assignment by a DHCPv6 server. The operation assumes that the server 76 is responsible for the assignment of an integral address which 77 includes prefix and interface identifier parts as described in 78 [RFC4291]. In the Stateless Address Autoconfiguration (SLACC, 79 [RFC4862]) model, the interface Identifier is generated by the host 80 itself while the prefix is configured through Router Advertisement 81 message defined in [RFC4861]. 83 Up to now, there is no mechanism that allows host self-generated 84 addresses to be used in the DHCPv6-managed network. 86 [RFC3633] defines Prefix Delegation options providing a mechanism for 87 automated delegation of IPv6 prefixes using the DHCPv6. This 88 mechanism is intended for delegating a long-lived prefix from a 89 delegating router to a requesting router. This mechanism "is not 90 bound to the assignment of IP addresses or other configuration 91 information to hosts" [RFC3633]. It delegates prefixes to a routable 92 device for itself use only. It does not support the host-genarated 93 interface identifiers model, in which prefix(es) need to be 94 advertised or assigned to hosts. 96 This document introduces a new DHCPv6 procedure to configure hosts' 97 IPv6 addresses. In this new procedure, the prefix is advertised from 98 a DHCPv6 server through DHCPv6 protocol while the interface 99 identifiers are independently generated by the hosts. The usage of 100 DHCPv6 for assigning prefixes separats prefix assignment and 101 interface identifier generation. 103 [RFC3972] describes a method for binding a public signature key to an 104 IPv6 address. The basic idea is to generate the interface identifier 105 (i.e., the rightmost 64 bits) of the IPv6 address by computing a 106 cryptographic hash of the public key. That is, the host decides its 107 interface identifier. As for the prefix part of the CGA, it is 108 probably got through Router Advertisement message defined in 109 [RFC4861], or through DHCPv6 operations defined in this document. 111 There are also other host-generated IPv6 addresses, which are 112 combined by prefixes obtained from network configuration and 113 ingerface identifiers generated by hosts, such as modified EUI-64 114 interface identifier [EUI-64], temporary addresses for privacy 115 [RFC4941],etc. The DHCPv6 operations defined in this document also 116 supports such address methods. 118 The DHCPv6 operations defined in this document also supports the 119 assigned prefix to be shared across multiple hosts. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 The terminology in this document is based on the definitions in 128 [RFC3315], in addition to the ones specified in this section 130 derivative prefix: A prefix is derived from another prefix. For 131 example, a /64 prefix is derived from a /48 prefix, that is, the 132 /64 prefix has the same leftmost 48 bits with the /48 prefix. 133 authorized prefix: A specific router is given a specific set of 134 subnet prefixes to advertise; other routers have an authorization 135 to advertise other subnet prefixes. In [RFC3971],Certification 136 Path Advertisement message is used to convey authorized prefixes. 138 3. Address Auto-configuration 140 Router Advertisements in [RFC4861] allow routers to inform hosts how 141 to perform Address Auto-configuration. For example, routers can 142 specify whether hosts should use DHCPv6 and/or stateless address 143 configuration. In Router Advertisement message, M and O bits are 144 used for indication of address auto-configuration mode. 146 Whatever address auto-configuration mode a host uses, the following 147 two parts are necessary for the host to formulate it's IPv6 address: 149 o A prefix. In [RFC3971], Certification Path Solicitation and 150 Certification Path Advertisement messages are designed for 151 verifying routers being authorized to act as routers. 152 Certification Path Advertisement message can also be used to 153 verify that routers are authorized to advertise a certain set of 154 subnet prefixes. In the stateless auto-configuration address 155 mode, the prefixes in Router Advertisement message should be a 156 subset of authorized prefixes, or derivative prefixes from 157 authorized prefixes. In the stateful auto-configuration address 158 mode, prefix assignment from a DHCPv6 server is not currently 159 support. 160 o An interface identifier. Modified EUI-64 interface identifier 161 [EUI-64] is a widely-used host generated interface identifier. It 162 generates interface identifier from the host MAC address. The 163 interface identifier of [RFC3972] is generated by computing a 164 cryptographic hash of a public key of a host. The host is 165 responsible for interface identifier generation. 167 In the ND-managed environment, RA is used to assign the prefix. 169 So far, there is no mechanism to support the scenario that prefixes 170 are managed by a DHCPv6 server. The DHCPv6 operation defined in this 171 document enables the DHCPv6 server to assign a prefix, rather than a 172 integral address, to the host, so that the host can obtain an IPv6 173 address by combining the prefix with its own generated interface 174 identifier. It actually enables the auto address configuration 175 through DHCPv6. 177 This document targets to meet this gap. 179 4. DHCPv6 Operation 181 Figure 1 shows the operation of separating prefix assignment and 182 interface identifier generation in the DHCPv6. 183 +------------+ +-------------+ 184 |Host(Client)| |DHCPv6 Server| 185 +------------+ +-------------+ 186 | 1 Solicit | 187 |---------------------> | 188 | 2 Advertise | 189 |<--------------------- | 190 3 Combination of Prefix | 191 and Interface Identifier | 192 | | 194 Figure 1: DHCPv6 Operation 196 1. A host uses a Solicit message to discover DHCPv6 servers that 197 have been configured to assign prefixes for the host. Identity 198 Association for Prefix Delegation Option (IA_PD) is defined in 199 [RFC3633] for prefix delegation between a requesting router and 200 delegating router. Referring to the definition, a new Identity 201 Association for Prefix Assignment (IA-PA) option is defined in 202 Section 5.1 to enable the prefix assignment from a DHCPv6 server 203 to a host. 204 2. The DHCPv6 server assigns one or more prefixes to the host in 205 Advertise messages or in the Reply messages to the prefix 206 requests from the hosts. The assigned prefixes SHOULD be a 207 subset of the authorized prefixes or derivative prefixes of the 208 authorized prefixes. Identity Association for Prefix Assignment 209 Option in Section 5.1 is used for conveying the assigned 210 prefixes. If there is not a proper prefix available, a status- 211 code is returned to the host and the procedure is terminated. 212 When receiving multiple prefixes, the host may use pre-configured 213 hints for prefix assignment preference. The hints are authorized 214 prefixes advertised by an authorized router through Certification 215 Path Advertisement defined in [RFC3971]. 216 3. The host generates an interface identifier and formulates a 217 combined IPv6 address by concatenating the assigned prefix and 218 the self-generated interface identifier. There are many ways to 219 generate interface identifier. [RFC3972] defines a method to 220 generate the interface identifier by computing a cryptographic 221 hash of a public key of the host. Modified EUI-64 interface 222 identifier [EUI-64] is generated based on the host MAC address. 224 After the host generates an IPv6 address using the above procedure, 225 the host may send a Request message to the DHCPv6 server in order to 226 confirm the usage of the new address. The confirmation procedure may 227 be completed together with the address registration procedure. 228 However, the confirmation procedure is out of scope. 230 5. DHCPv6 IA_PA Option 232 In this section, one new option is defined, Identity Association for 233 Prefix Assignment Option . The format of this new DHCPv6 IA_PA 234 Option has been deliberately designed to be the same with IA_PD 235 option[RFC3633]. The IA_PD Prefix and IA Address sub-options from 236 IA_PD option are also reused. However, the two options are different 237 on the semantics and usage models. 239 The prefixed assigned through this DHCPv6 IA_PA option could be 240 shared accross multiple hosts. 242 5.1. Identity Association for Prefix Assignment Option 244 The IA_PA option is used to carry a prefix assignment identity 245 association, the parameters associated with the IA_PA and the 246 prefixes associated with it. 248 The format of the IA_PA option is: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | OPTION_IA_PA | option-length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | IAID (4 octets) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | T1 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | T2 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 . . 262 . IA_PA-options . 263 . . 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 option-code: OPTION_IA_PA (TBA1) 267 option-length: 12 + length of IA_PA-options field. 269 IAID: The unique identifier for this IA_PA; the IAID must 270 be unique among the identifiers for all of this 271 host's IA_PAs. 273 T1: The time at which the host should 274 contact the DHCPv6 server from which the 275 prefixes in the IA_PA were obtained to extend the 276 lifetimes of the prefixes assigned to the IA_PA; 277 T1 is a time duration relative to the current time 278 expressed in units of seconds. 280 T2: The time at which the host should 281 contact any available DHCPv6 server to extend 282 the lifetimes of the prefixes assigned to the 283 IA_PA; T2 is a time duration relative to the 284 current time expressed in units of seconds. 286 IA_PA-options: Options associated with this IA_PA. 288 The details of the fields are similar to the IA_PD option description 289 in [RFC3633]. The difference is here a DHCPv6 server and a host 290 involved, while a delegating router and requesting router involved in 291 [RFC3633]. 293 5.2. IA_PA Prefix Option 295 OPTION_IAPREFIX (26) "IA_PD Prefix Option" defined in Section 10 of 296 [RFC3633] is reused. 298 Originally, the option is used for conveying prefix information 299 between a delegating router and a requesting router. Here the IA_PD 300 Prefix option is used to specify IPv6 address prefixes associated 301 with an IA_PA in Section 5.1. The IA_PD Prefix option must be 302 encapsulated in the IA_PA-options field of an IA_PA option. 304 6. Applicability 306 In point-to-point link model, DHCPv6 operation with host-generated 307 interface identifier, described in this document, may be used. 308 [RFC4968] provides different IPv6 link models that are suitable for 309 802.16 based networks and a point-to-point link model is recommended. 310 Also, 3GPP and 3GPP2 have earlier adopted the point-to-point link 311 model based on the recommendations in [RFC3314]. In this model, one 312 prefix can only be assigned to one interface of a host (mobile 313 station) and different hosts (mobile stations) can't share a prefix. 314 The unique prefix can be used to identify the host. It is not 315 necessary for a DHCPv6 server to generate an interface identifier for 316 the host. The host may generate its interface identifier as 317 described in [RFC4941]. An interface identifier could even be 318 generated via random number generation. 320 Modified EUI-64 interface identifier [EUI-64] is also typically 321 generated by hosts. [RFC4941] has defined temporary addresses for 322 privacy purposes. The temporary addresses is also generated by hosts 323 using random algorithm. The DHCPv6 operations defined in this 324 document also supports such address methods. 326 7. IANA consideration 328 This document defines a new DHCPv6 [RFC3315] option, which must be 329 assigned Option Type values within the option numbering space for 330 DHCPv6 messages: 332 The OPTION_IA_PA Option (TBA1), described in Section 5.1. 334 8. Security Considerations 336 Security considerations in DHCPv6 are described in [RFC3315]. 338 To guard against attacks through prefix assignment, a host and a 339 DHCPv6 server SHOULD use DHCPv6 authentication as described in 340 Section 21, "Authentication of DHCP messages" of [RFC3315] or Secure 341 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] . 343 9. Acknowledgements 345 The authors would like to thanks Suresh Krishnan, Ted Lemon and other 346 members of DHC WG for their valuable comments. 348 10. References 350 10.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 356 and M. Carney, "Dynamic Host Configuration Protocol for 357 IPv6 (DHCPv6)", RFC 3315, July 2003. 359 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 360 Host Configuration Protocol (DHCP) version 6", RFC 3633, 361 December 2003. 363 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 364 Neighbor Discovery (SEND)", RFC 3971, March 2005. 366 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 367 RFC 3972, March 2005. 369 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 370 Architecture", RFC 4291, February 2006. 372 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 373 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 374 September 2007. 376 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 377 Address Autoconfiguration", RFC 4862, September 2007. 379 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 380 Extensions for Stateless Address Autoconfiguration in 381 IPv6", RFC 4941, September 2007. 383 10.2. Informative references 385 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 386 Generation Partnership Project (3GPP) Standards", 387 RFC 3314, September 2002. 389 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 390 Based Networks", RFC 4968, August 2007. 392 [I-D.ietf-dhc-secure-dhcpv6] 393 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 394 draft-ietf-dhc-secure-dhcpv6-06 (work in progress), 395 March 2012. 397 [EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64) 398 Registration Authority", http://standards.ieee.org/ 399 regauth/oui/tutorials/EUI64.html", March 1997. 401 Authors' Addresses 403 Sheng Jiang 404 Huawei Technologies 405 Q14, Huawei Campus, No.156, BeiQing Road 406 Hai-Dian District, Beijing 100095 407 P.R. China 409 Email: jiangsheng@huawei.com 411 Frank Xia 412 Huawei Technologies 413 1700 Alma Dr. Suite 500 414 Plano, TX 75075 416 Email: xiayangsong@huawei.com 418 Behcet Sarikaya 419 Huawei Technologies 420 1700 Alma Dr. Suite 500 421 Plano, TX 75075 423 Email: sarikaya@ieee.org