idnits 2.17.1 draft-ietf-dhc-host-gen-id-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 : ---------------------------------------------------------------------------- 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 16, 2011) is 4721 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 (-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: 3 errors (**), 0 flaws (~~), 3 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 17, 2011 Huawei Technologies 6 May 16, 2011 8 Prefix Assignment in DHCPv6 9 draft-ietf-dhc-host-gen-id-00.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 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 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 [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 includes prefix and interface identifier parts 80 as described in [RFC4291]. 82 This document introduces a new DHCPv6 procedure to configure hosts' 83 IPv6 addresses. In this new procedure, the prefix is advertised from 84 a DHCPv6 server through DHCPv6 protocol while the interface 85 identifiers are independently generated by the hosts. 87 [RFC3633] defines Prefix Delegation options providing a mechanism for 88 automated delegation of IPv6 prefixes using the DHCPv6. This 89 mechanism is intended for delegating a long-lived prefix from a 90 delegating router to a requesting router. This mechanism "is not 91 bound to the assignment of IP addresses or other configuration 92 information to hosts" [RFC3633]. It delegates prefixes to a routable 93 device for itself use only. It does not support the host-genarated 94 interface identifiers model, in which prefix(es) need to be 95 advertised or assigned to hosts. 97 [RFC3972] describes a method for binding a public signature key to an 98 IPv6 address in the Secure Neighbor Discovery (SEND) protocol 99 [RFC3971]. The basic idea is to generate the interface identifier 100 (i.e., the rightmost 64 bits) of the IPv6 address by computing a 101 cryptographic hash of the public key. That is, the host decides its 102 interface identifier. As for the prefix part of the CGA, it is 103 probably got through Router Advertisement message defined in 104 [RFC4861], or through DHCPv6 operations defined in this document. 105 [I-D.ietf-csi-dhcpv6-cga-ps] describes potential issues in the 106 interaction between DHCPv6 and CGA. In that document , the usage of 107 DHCPv6 for assigning prefixes is proposed to facilitate separation of 108 prefix assignment and interface identifier generation. 110 There are also other host-generated IPv6 addresses, which are 111 combined by prefixes obtained from network configuration and 112 ingerface identifiers generated by hosts, such as modified EUI-64 113 interface identifier [EUI-64], etc. The DHCPv6 operations defined in 114 this document also supports such address methods. 116 The DHCPv6 operations defined in this document also supports the 117 assigned prefix to be shared across multiple hosts. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 The terminology in this document is based on the definitions in 126 [RFC3315], in addition to the ones specified in this section 128 derivative prefix: A prefix is derived from another prefix. For 129 example, a /64 prefix is derived from a /48 prefix, that is, the 130 /64 prefix has the same leftmost 48 bits with the /48 prefix. 131 authorized prefix: A specific router is given a specific set of 132 subnet prefixes to advertise; other routers have an authorization 133 to advertise other subnet prefixes. In [RFC3971],Certification 134 Path Advertisement message is used to convey authorized prefixes. 136 3. Address Auto-configuration 138 Router Advertisements in [RFC4861] allow routers to inform hosts how 139 to perform Address Auto-configuration. For example, routers can 140 specify whether hosts should use DHCPv6 and/or stateless address 141 configuration. In Router Advertisement message, M and O bits are 142 used for indication of address auto-configuration mode. 144 Whatever address auto-configuration mode a host uses, the following 145 two parts are necessary for the host to formulate it's IPv6 address: 147 o A prefix. In [RFC3971], Certification Path Solicitation and 148 Certification Path Advertisement messages are designed for 149 verifying routers being authorized to act as routers. 150 Certification Path Advertisement message can also be used to 151 verify that routers are authorized to advertise a certain set of 152 subnet prefixes. In the stateless auto-configuration address 153 mode, the prefixes in Router Advertisement message should be a 154 subset of authorized prefixes, or derivative prefixes from 155 authorized prefixes. In the stateful auto-configuration address 156 mode, prefix assignment from a DHCPv6 server is not currently 157 support. 158 o An interface identifier. Modified EUI-64 interface identifier 159 [EUI-64] is a widely-used host generated interface identifier. It 160 generates interface identifier from the host MAC address. The 161 interface identifier of [RFC3972] is generated by computing a 162 cryptographic hash of a public key of a host. The host is 163 responsible for interface identifier generation. 165 In the ND-managed environment, RA is used to assign the prefix. 167 So far, there is no mechanism to support the scenario that prefixes 168 are managed by a DHCPv6 server. The DHCPv6 operation defined in this 169 document enables the DHCPv6 server to assign a prefix, rather than a 170 integral address, to the host, so that the host can obtain an IPv6 171 address by combining the prefix with its own generated interface 172 identifier. It actually enables the auto address configuration 173 through DHCPv6. 175 This document targets to meet this gap. 177 4. DHCPv6 Operation 179 Figure 1 shows the operation of separating prefix assignment and 180 interface identifier generation in the DHCPv6. 181 +------------+ +-------------+ 182 |Host(Client)| |DHCPv6 Server| 183 +------------+ +-------------+ 184 | 1 Solicit | 185 |---------------------> | 186 | 2 Advertise | 187 |<--------------------- | 188 3 Combination of Prefix | 189 and Interface Identifier | 190 | | 192 Figure 1: DHCPv6 Operation 194 1. A host uses a Solicit message to discover DHCPv6 servers that 195 have been configured to assign prefixes for the host. Identity 196 Association for Prefix Delegation Option (IA_PD) is defined in 197 [RFC3633] for prefix delegation between a requesting router and 198 delegating router. Referring to the definition, a new Identity 199 Association for Prefix Assignment (IA-PA) option is defined in 200 Section 5.1 to enable the prefix assignment from a DHCPv6 server 201 to a host. 202 2. The DHCPv6 server assigns one or more prefixes to the host in 203 Advertise messages or in the Reply messages to the prefix 204 requests from the hosts. The assigned prefixes SHOULD be a 205 subset of the authorized prefixes or derivative prefixes of the 206 authorized prefixes. Identity Association for Prefix Assignment 207 Option in Section 5.1 is used for conveying the assigned 208 prefixes. If there is not a proper prefix available, a status- 209 code is returned to the host and the procedure is terminated. 210 When receiving multiple prefixes, the host may use pre-configured 211 hints for prefix assignment preference. The hints are authorized 212 prefixes advertised by an authorized router through Certification 213 Path Advertisement defined in [RFC3971]. 215 3. The host generates an interface identifier and formulates a 216 combined IPv6 address by concatenating the assigned prefix and 217 the self-generated interface identifier. There are many ways to 218 generate interface identifier. [RFC3972] defines a method to 219 generate the interface identifier by computing a cryptographic 220 hash of a public key of the host. Modified EUI-64 interface 221 identifier [EUI-64] is generated based on the host MAC address. 223 After the host generates an IPv6 address using the above procedure, 224 the host may send a Request message to the DHCPv6 server in order to 225 confirm the usage of the new address. The confirmation procedure may 226 be completed together with the address registration procedure. 227 However, the confirmation procedure is out of scope. 229 5. DHCPv6 IA_PA Option 231 In this section, one new option is defined, Identity Association for 232 Prefix Assignment Option . The format of this new DHCPv6 IA_PA 233 Option has been deliberately designed to be the same with IA_PD 234 option[RFC3633]. The IA_PD Prefix and IA Address sub-options from 235 IA_PD option are also reused. However, the two options are different 236 on the semantics and usage models. 238 The prefixed assigned through this DHCPv6 IA_PA option could be 239 shared accross multiple hosts. 241 5.1. Identity Association for Prefix Assignment Option 243 The IA_PA option is used to carry a prefix assignment identity 244 association, the parameters associated with the IA_PA and the 245 prefixes associated with it. 247 The format of the IA_PA option is: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | OPTION_IA_PA | option-length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | IAID (4 octets) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | T1 | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | T2 | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 . . 261 . IA_PA-options . 262 . . 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 option-code: OPTION_IA_PA (TBA1) 266 option-length: 12 + length of IA_PA-options field. 268 IAID: The unique identifier for this IA_PA; the IAID must 269 be unique among the identifiers for all of this 270 host's IA_PAs. 272 T1: The time at which the host should 273 contact the DHCPv6 server from which the 274 prefixes in the IA_PA were obtained to extend the 275 lifetimes of the prefixes assigned to the IA_PA; 276 T1 is a time duration relative to the current time 277 expressed in units of seconds. 279 T2: The time at which the host should 280 contact any available DHCPv6 server to extend 281 the lifetimes of the prefixes assigned to the 282 IA_PA; T2 is a time duration relative to the 283 current time expressed in units of seconds. 285 IA_PA-options: Options associated with this IA_PA. 287 The details of the fields are similar to the IA_PD option description 288 in [RFC3633]. The difference is here a DHCPv6 server and a host 289 involved, while a delegating router and requesting router involved in 290 [RFC3633]. 292 5.2. IA_PA Prefix Option 294 OPTION_IAPREFIX (26) "IA_PD Prefix Option" defined in Section 10 of 295 [RFC3633] is reused. 297 Originally, the option is used for conveying prefix information 298 between a delegating router and a requesting router. Here the IA_PD 299 Prefix option is used to specify IPv6 address prefixes associated 300 with an IA_PA in Section 5.1. The IA_PD Prefix option must be 301 encapsulated in the IA_PA-options field of an IA_PA option. 303 6. Applicability 305 In point-to-point link model, DHCPv6 operation with host-generated 306 interface identifier, described in this document, may be used. 307 [RFC4968] provides different IPv6 link models that are suitable for 308 802.16 based networks and a point-to-point link model is recommended. 309 Also, 3GPP and 3GPP2 have earlier adopted the point-to-point link 310 model based on the recommendations in [RFC3314]. In this model, one 311 prefix can only be assigned to one interface of a host (mobile 312 station) and different hosts (mobile stations) can't share a prefix. 313 The unique prefix can be used to identify the host. It is not 314 necessary for a DHCPv6 server to generate an interface identifier for 315 the host. The host may generate its interface identifier as 316 described in [RFC4941]. An interface identifier could even be 317 generated via random number generation. 319 Modified EUI-64 interface identifier [EUI-64] is also typically 320 generated by hosts. The DHCPv6 operations defined in this document 321 also supports such address methods. 323 7. IANA consideration 325 This document defines a new DHCPv6 [RFC3315] option, which must be 326 assigned Option Type values within the option numbering space for 327 DHCPv6 messages: 329 The OPTION_IA_PA Option (TBA1), described in Section 5.1. 331 8. Security Considerations 333 Security considerations in DHCPv6 are described in [RFC3315]. 335 To guard against attacks through prefix assignment, a host and a 336 DHCPv6 server SHOULD use DHCPv6 authentication as described in 337 Section 21, "Authentication of DHCP messages" of [RFC3315] or Secure 338 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] . 340 9. Acknowledgements 342 The authors would like to thanks Suresh Krishnan and other members of 343 DHC WG for their valuable comments. 345 10. References 347 10.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 353 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 354 September 2007. 356 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 357 Neighbor Discovery (SEND)", RFC 3971, March 2005. 359 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 360 RFC 3972, March 2005. 362 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 363 and M. Carney, "Dynamic Host Configuration Protocol for 364 IPv6 (DHCPv6)", RFC 3315, July 2003. 366 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 367 Host Configuration Protocol (DHCP) version 6", RFC 3633, 368 December 2003. 370 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 371 Architecture", RFC 4291, February 2006. 373 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 374 Extensions for Stateless Address Autoconfiguration in 375 IPv6", RFC 4941, September 2007. 377 10.2. Informative references 379 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 380 Based Networks", RFC 4968, August 2007. 382 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 383 Generation Partnership Project (3GPP) Standards", 384 RFC 3314, September 2002. 386 [I-D.ietf-csi-dhcpv6-cga-ps] 387 Jiang, S., "DHCPv6 and CGA Interaction: Problem 388 Statement", draft-ietf-csi-dhcpv6-cga-ps-06 (work in 389 progress), October 2010. 391 [I-D.ietf-dhc-secure-dhcpv6] 392 Jiang, S., "Secure DHCPv6 Using CGAs", 393 draft-ietf-dhc-secure-dhcpv6-02 (work in progress), 394 December 2010. 396 [EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64) 397 Registration Authority", http://standards.ieee.org/ 398 regauth/oui/tutorials/EUI64.html", March 1997. 400 Authors' Addresses 402 Sheng Jiang 403 Huawei Technologies 404 Huawei Building, No.3 Xinxi Rd., 405 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 406 P.R. China 408 Email: jiangsheng@huawei.com 410 Frank Xia 411 Huawei Technologies 412 1700 Alma Dr. Suite 500 413 Plano, TX 75075 415 Email: xiayangsong@huawei.com 417 Behcet Sarikaya 418 Huawei Technologies 419 1700 Alma Dr. Suite 500 420 Plano, TX 75075 422 Email: sarikaya@ieee.org