idnits 2.17.1 draft-ietf-dhc-host-gen-id-03.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 (August 21, 2012) is 4265 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 == Outdated reference: A later version (-07) exists of draft-ietf-dhc-addr-registration-00 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: February 22, 2013 Huawei Technologies 6 August 21, 2012 8 Prefix Assignment in DHCPv6 9 draft-ietf-dhc-host-gen-id-03 11 Abstract 13 This document introduces a generic prefix announcement mechanism 14 using DHCPv6. In this new address configuration procedure, the 15 prefix is propagated from a DHCPv6 server to hosts through DHCPv6 16 message exchanging while the interface identifiers are independently 17 generated by the hosts. It enables both integral address assignment 18 and self-generated addresses in one single mechanism, DHCPv6. It 19 also enables stateless address configuration without RA attendance. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 22, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Address Auto-configuration . . . . . . . . . . . . . . . . . . 4 58 4. DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. DHCPv6 IA_PA Option . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Identity Association for Prefix Assignment Option . . . . 7 61 5.2. IA_PA Prefix Option . . . . . . . . . . . . . . . . . . . 8 62 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 10.2. Informative references . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 A host IPv6 address is combined by a prefix and an interface 74 identifier. Currently, there are two mechanisms to configure a host 75 IPv6 address. [RFC3315] describes the operation of address 76 assignment by a DHCPv6 server. The operation assumes that the server 77 is responsible for the assignment of an integral address which 78 includes both prefix and interface identifier parts as described in 79 [RFC4291]. In the Stateless Address Autoconfiguration (SLACC, 80 [RFC4862]) model, the interface Identifier is generated by the host 81 itself while the prefix is configured through Router Advertisement 82 message defined in [RFC4861]. 84 However, in a DHCPv6-managed network, assigning 128-bit address is 85 insufficient. Some hosts may want to use self-generated address, 86 which are combined by prefixes obtained from network configuration 87 and interface identifiers generated by hosts. The examples include 88 CGA [RFC3972], modified EUI-64 interface identifier [EUI-64], 89 temporary addresses for privacy [RFC4941] and etc. 91 In these scenarios, the address configuration precedure has to be 92 splitted in two motheds: integral address assignment through DHCPv6 93 and prefix announcement by RA advertisement. Some ISPs desire to 94 manage address configuration using one set of protocol, rather than 95 mixture of DHCPv6 and Neighbor Discovery. 97 There are also some network environments in that perfix annoucement 98 through RAs may not be the best choice. For example, hosts may 99 connect through tunnels, either layer 2 tunnels or layer 3 tunnels. 101 While a RA is only able to announce prefix on a single link, DHCPv6 102 configuration can be used to manage multiple links by setup DHCPv6 103 relay. 105 Up to now, there is no mechanism for the prefix announcement/ 106 assignment in DHCPv6. [RFC3633] defines Prefix Delegation options 107 providing a mechanism for automated delegation of IPv6 prefixes using 108 the DHCPv6. This mechanism is intended for delegating a long-lived 109 prefix from a delegating router to a requesting router. This 110 mechanism "is not bound to the assignment of IP addresses or other 111 configuration information to hosts" [RFC3633]. It delegates prefixes 112 to a routable device for itself use only. It does not support the 113 host-generated interface identifiers model, in which prefix(es) need 114 to be advertised or assigned to hosts. 116 This document introduces a generic prefix announcement mechanism 117 using DHCPv6. In this new address configuration procedure, the 118 prefix is propagated from a DHCPv6 server to hosts through DHCPv6 119 message exchanging while the interface identifiers are independently 120 generated by the hosts. It is alternative of RA prefix assignment/ 121 announcement. It enables both integral address assignment and self- 122 generated addresses in one single mechanism, DHCPv6. Note, in many 123 scenarios, neighbor discovery is still needed for routing and 124 reachability. In other scenarios, this mechanism enables stateless 125 address configuration while RA absents. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 The terminology in this document is based on the definitions in 134 [RFC3315], in addition to the ones specified in this section 136 derivative prefix: A prefix is derived from another prefix. For 137 example, a /64 prefix is derived from a /48 prefix, that is, the 138 /64 prefix has the same leftmost 48 bits with the /48 prefix. 139 authorized prefix: A specific router is given a specific set of 140 subnet prefixes to advertise; other routers have an authorization 141 to advertise other subnet prefixes. In [RFC3971],Certification 142 Path Advertisement message is used to convey authorized prefixes. 144 3. Address Auto-configuration 146 Router Advertisements in [RFC4861] allow routers to inform hosts how 147 to perform Address Auto-configuration. For example, routers can 148 specify whether hosts should use DHCPv6 and/or stateless address 149 configuration. In Router Advertisement message, M and O bits are 150 used for indication of address auto-configuration mode. 152 Whatever address auto-configuration mode a host uses, the following 153 two parts are necessary for the host to formulate it's IPv6 address: 155 o A prefix. In [RFC3971], Certification Path Solicitation and 156 Certification Path Advertisement messages are designed for 157 verifying routers being authorized to act as routers. 158 Certification Path Advertisement message can also be used to 159 verify that routers are authorized to advertise a certain set of 160 subnet prefixes. In the stateless auto-configuration address 161 mode, the prefixes in Router Advertisement message should be a 162 subset of authorized prefixes, or derivative prefixes from 163 authorized prefixes. In the stateful auto-configuration address 164 mode, prefix assignment from a DHCPv6 server is not currently 165 support. 166 o An interface identifier. Modified EUI-64 interface identifier 167 [EUI-64] is a widely-used host generated interface identifier. It 168 generates interface identifier from the host MAC address. The 169 interface identifier of [RFC3972] is generated by computing a 170 cryptographic hash of a public key of a host. The host is 171 responsible for interface identifier generation. 173 In the ND-managed environment, RA is used to assign the prefix. 175 So far, there is no mechanism to support the scenario that prefixes 176 are managed by a DHCPv6 server. This document targets to meet this 177 gap. The DHCPv6 operation defined in this document enables the 178 DHCPv6 server to assign a prefix, rather than a integral address, to 179 the host, so that the host can obtain an IPv6 address by combining 180 the prefix with its own generated interface identifier. It actually 181 enables the auto address configuration through DHCPv6. 183 4. DHCPv6 Operation 185 Figure 1 shows the operation of separating prefix assignment and 186 interface identifier generation in the DHCPv6. 187 +------------+ +-------------+ 188 |Host(Client)| |DHCPv6 Server| 189 +------------+ +-------------+ 190 | 1 Solicit/Request | 191 |---------------------> | 192 | 2 Advertise/Reply | 193 | with IA_PA Option | 194 |<--------------------- | 195 3 Combination of Prefix | 196 and Interface Identifier | 197 | | 199 Figure 1: DHCPv6 Operation 201 1. A host uses a Solicit message to discover DHCPv6 servers that 202 have been configured to assign prefixes for the host. Identity 203 Association for Prefix Delegation Option (IA_PD) is defined in 204 [RFC3633] for prefix delegation between a requesting router and 205 delegating router. Referring to the definition, a new Identity 206 Association for Prefix Assignment (IA-PA) option is defined in 207 Section 5.1 to enable the prefix assignment from a DHCPv6 server 208 to a host. A host MAY include a Option Request Option requesting 209 IA_PA in a Solicit or a IA_PA Option in a Request message to 210 request prefix assignment explicitly. 212 2. The DHCPv6 server assigns one or more prefixes to the host in 213 Advertise messages or in the Reply messages responding to the 214 prefix requests from the hosts. When the prefix assignment in 215 advertise model, even if a host does not request, DHCPv6 server 216 can push it initiatively. The assigned prefixes SHOULD be a 217 subset of the authorized prefixes or derivative prefixes of the 218 authorized prefixes. Identity Association for Prefix Assignment 219 Option in Section 5.1 is used for conveying the assigned 220 prefixes. If there is not a proper prefix available, a 221 NoPrefixAvail (defined in [RFC3633])status-code is returned to 222 the host and the procedure is terminated. When receiving 223 multiple prefixes, the host may use pre-configured hints for 224 prefix assignment preference. The hints are authorized prefixes 225 advertised by an authorized router through Certification Path 226 Advertisement defined in [RFC3971]. 227 3. The host generates an interface identifier and formulates a 228 combined IPv6 address by concatenating the assigned prefix and 229 the self-generated interface identifier. There are many ways to 230 generate interface identifier. [RFC3972] defines a method to 231 generate the interface identifier by computing a cryptographic 232 hash of a public key of the host. Modified EUI-64 interface 233 identifier [EUI-64] is generated based on the host MAC address. 235 After the host generates an IPv6 address using the above procedure, 236 the host may send a Request message to the DHCPv6 server in order to 237 confirm the usage of the new address. The confirmation procedure may 238 be completed together with the address registration procedure 239 [I-D.ietf-dhc-addr-registration]. However, the confirmation 240 procedure is out of scope. 242 When the host reaches T1 or T2 defined in Section 5.1, it SHOULD use 243 the same message exchanges, as described in section 18, "DHCP Client- 244 Initiated Configuration Exchange" of [RFC3315], to obtain or update 245 prefix(es) from a DHCPv6 server. 247 A DHCPv6 server MAY initiatively send a reconfiguration message to 248 the host, as described in section 19, "DHCP Server-Initiated 249 Configuration Exchange" of [RFC3315], to cause prefix(es) information 250 update. 252 5. DHCPv6 IA_PA Option 254 In this section, one new option is defined, Identity Association for 255 Prefix Assignment Option . The format of this new DHCPv6 IA_PA 256 Option has been deliberately designed to be the same with IA_PD 257 option[RFC3633]. The IA_PD Prefix and IA Address sub-options from 258 IA_PD option are also reused. However, the two options are different 259 on the semantics and usage models. 261 The prefixed assigned through this DHCPv6 IA_PA option could be 262 shared accross multiple hosts. 264 5.1. Identity Association for Prefix Assignment Option 266 The IA_PA option is used to carry a prefix assignment identity 267 association, the parameters associated with the IA_PA and the 268 prefixes associated with it. 270 The format of the IA_PA option is: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | OPTION_IA_PA | option-length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | IAID (4 octets) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | T1 | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | T2 | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 . . 284 . IA_PA-options . 285 . . 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 option-code: OPTION_IA_PA (TBA1) 290 option-length: 12 + length of IA_PA-options field. 292 IAID: The unique identifier for this IA_PA; the IAID must 293 be unique among the identifiers for all of this 294 host's IA_PAs. 296 T1: The time at which the host should 297 contact the DHCPv6 server from which the 298 prefixes in the IA_PA were obtained to extend the 299 lifetimes of the prefixes assigned to the IA_PA; 300 T1 is a time duration relative to the current time 301 expressed in units of seconds. 303 T2: The time at which the host should 304 contact any available DHCPv6 server to extend 305 the lifetimes of the prefixes assigned to the 306 IA_PA; T2 is a time duration relative to the 307 current time expressed in units of seconds. 309 IA_PA-options: Options associated with this IA_PA. 311 The details of the fields are similar to the IA_PD option description 312 in [RFC3633]. The difference is here a DHCPv6 server and a host 313 involved, while a delegating router and requesting router involved in 314 [RFC3633]. 316 5.2. IA_PA Prefix Option 318 OPTION_IAPREFIX (26) "IA_PD Prefix Option" defined in Section 10 of 319 [RFC3633] is reused. 321 Originally, the option is used for conveying prefix information 322 between a delegating router and a requesting router. Here the IA_PD 323 Prefix option is used to specify IPv6 address prefixes associated 324 with an IA_PA in Section 5.1. The IA_PD Prefix option must be 325 encapsulated in the IA_PA-options field of an IA_PA option. 327 6. Applicability 329 In point-to-point link model, DHCPv6 operation with host-generated 330 interface identifier, described in this document, may be used. 331 [RFC4968] provides different IPv6 link models that are suitable for 332 802.16 based networks and a point-to-point link model is recommended. 333 Also, 3GPP and 3GPP2 have earlier adopted the point-to-point link 334 model based on the recommendations in [RFC3314]. In this model, one 335 prefix can only be assigned to one interface of a host (mobile 336 station) and different hosts (mobile stations) can't share a prefix. 337 The unique prefix can be used to identify the host. It is not 338 necessary for a DHCPv6 server to generate an interface identifier for 339 the host. The host may generate its interface identifier as 340 described in [RFC4941]. An interface identifier could even be 341 generated via random number generation. 343 Modified EUI-64 interface identifier [EUI-64] is also typically 344 generated by hosts. [RFC4941] has defined temporary addresses for 345 privacy purposes. The temporary addresses is also generated by hosts 346 using random algorithm. The DHCPv6 operations defined in this 347 document also supports such address methods. 349 7. IANA consideration 351 This document defines a new DHCPv6 [RFC3315] option, which must be 352 assigned Option Type values within the option numbering space for 353 DHCPv6 messages: 355 The OPTION_IA_PA Option (TBA1), described in Section 5.1. 357 8. Security Considerations 359 Security considerations in DHCPv6 are described in [RFC3315]. 361 To guard against attacks through prefix assignment, a host and a 362 DHCPv6 server SHOULD use DHCPv6 authentication as described in 363 Section 21, "Authentication of DHCP messages" of [RFC3315] or Secure 364 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] . 366 9. Acknowledgements 368 The authors would like to thanks Suresh Krishnan, Ted Lemon, Bing 369 Liu, Andre Kostur, Gaurav Halwasia, Bernie Volz and other members of 370 DHC WG for their valuable comments. 372 10. References 374 10.1. Normative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 380 and M. Carney, "Dynamic Host Configuration Protocol for 381 IPv6 (DHCPv6)", RFC 3315, July 2003. 383 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 384 Host Configuration Protocol (DHCP) version 6", RFC 3633, 385 December 2003. 387 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 388 Neighbor Discovery (SEND)", RFC 3971, March 2005. 390 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 391 RFC 3972, March 2005. 393 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 394 Architecture", RFC 4291, February 2006. 396 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 397 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 398 September 2007. 400 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 401 Address Autoconfiguration", RFC 4862, September 2007. 403 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 404 Extensions for Stateless Address Autoconfiguration in 405 IPv6", RFC 4941, September 2007. 407 10.2. Informative references 409 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 410 Generation Partnership Project (3GPP) Standards", 411 RFC 3314, September 2002. 413 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 414 Based Networks", RFC 4968, August 2007. 416 [I-D.ietf-dhc-secure-dhcpv6] 417 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 418 draft-ietf-dhc-secure-dhcpv6-06 (work in progress), 419 March 2012. 421 [I-D.ietf-dhc-addr-registration] 422 Jiang, S. and G. Chen, "A Generic IPv6 Addresses 423 Registration Solution Using DHCPv6", 424 draft-ietf-dhc-addr-registration-00 (work in progress), 425 May 2012. 427 [EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64) 428 Registration Authority", http://standards.ieee.org/ 429 regauth/oui/tutorials/EUI64.html", March 1997. 431 Authors' Addresses 433 Sheng Jiang 434 Huawei Technologies 435 Q14, Huawei Campus, No.156, BeiQing Road 436 Hai-Dian District, Beijing 100095 437 P.R. China 439 Email: jiangsheng@huawei.com 441 Frank Xia 442 Huawei Technologies 443 1700 Alma Dr. Suite 500 444 Plano, TX 75075 446 Email: xiayangsong@huawei.com 448 Behcet Sarikaya 449 Huawei Technologies 450 1700 Alma Dr. Suite 500 451 Plano, TX 75075 453 Email: sarikaya@ieee.org