idnits 2.17.00 (12 Aug 2021) /tmp/idnits21687/draft-ietf-dhc-host-gen-id-05.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 (February 25, 2013) is 3365 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-addr-registration-01 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, Ed. 3 Internet-Draft F. Xia 4 Intended status: Standards Track B. Sarikaya 5 Expires: August 29, 2013 Huawei Technologies 6 February 25, 2013 8 Prefix Assignment in DHCPv6 9 draft-ietf-dhc-host-gen-id-05 11 Abstract 13 This document introduces a generic host-oriented prefix assignment 14 mechanism using DHCPv6. In this new address configuration procedure, 15 the prefix is assigned 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. 20 The technique described in this document can be used in networks 21 which assign IPv6 addresses using DHCPv6, e.g. WiMAX. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 29, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Address Auto-configuration . . . . . . . . . . . . . . . . . . 5 61 5. DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. DHCPv6 IA_PA Option . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Identity Association for Prefix Assignment Option . . . . 7 64 6.2. IA_PA Prefix Option . . . . . . . . . . . . . . . . . . . 9 65 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 10.2. Informative references . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 A host IPv6 address is combined by a prefix and an interface 76 identifier. Currently, there are two mechanisms to configure a host 77 IPv6 address. [RFC3315] describes the operation of address 78 assignment by a DHCPv6 server. The operation assumes that the server 79 is responsible for the assignment of an integral address which 80 includes both prefix and interface identifier parts as described in 81 [RFC4291]. In the Stateless Address Autoconfiguration (SLACC, 82 [RFC4862]) model, the interface Identifier is generated by the host 83 itself while the prefix is configured through Router Advertisement 84 message defined in [RFC4861]. 86 However, in a DHCPv6-managed network, assigning 128-bit address is 87 insufficient. Some hosts may want to use self-generated address, 88 which are combined by prefixes obtained from network configuration 89 and interface identifiers generated by hosts. The applicable user 90 cases include CGA [RFC3972], modified EUI-64 interface identifier 91 [EUI-64], temporary addresses for privacy [RFC4941] and etc. 93 In these scenarios, the address configuration precedure has to be 94 splitted in two motheds: integral address assignment through DHCPv6 95 and prefix announcement by RA advertisement. Some ISPs desire to 96 manage address configuration using one set of protocol, rather than 97 mixture of DHCPv6 and Neighbor Discovery. 99 There are also some network environments in that perfix annoucement 100 through RAs may not be the best choice. For example, hosts may 101 connect through tunnels, either layer 2 tunnels or layer 3 tunnels. 103 While a RA is only able to announce prefix on a single link, DHCPv6 104 configuration can be used to manage multiple links by setup DHCPv6 105 relay. 107 Up to now, there is no mechanism for host-oriented prefix assignment 108 in DHCPv6. [RFC3633] defines Prefix Delegation options providing a 109 mechanism for automated delegation of IPv6 prefixes using the DHCPv6. 110 This mechanism is intended for delegating a long-lived prefix from a 111 delegating router to a requesting router. This mechanism "is not 112 bound to the assignment of IP addresses or other configuration 113 information to hosts" [RFC3633]. It delegates prefixes to a routable 114 device for itself use only. It does not support the host-generated 115 interface identifiers model, in which prefix(es) need to be 116 propagated to hosts. 118 This document introduces a generic prefix assignment mechanism using 119 DHCPv6. In this new address configuration procedure, the prefix is 120 propagated from a DHCPv6 server to hosts through DHCPv6 message 121 exchanging while the interface identifiers are independently 122 generated by the hosts. It enables both integral address assignment 123 and self-generated addresses in one single mechanism, DHCPv6. Note, 124 in many scenarios, Neighbor Discovery [RFC4861] is still needed for 125 routing and reachability. In other scenarios, this mechanism enables 126 stateless address configuration while RA absents. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 The terminology in this document is mainly based on the definitions 135 in [RFC3315] and [RFC3633]. 137 Prefix assignment: a DHCPv6 server propagates prefix information to 138 hosts in unicast model. 140 3. Applicability 142 In point-to-point link model, DHCPv6 operation with host-generated 143 interface identifier, described in this document, may be used. 144 [RFC4968] provides different IPv6 link models that are suitable for 145 802.16 based networks and a point-to-point link model is recommended. 146 Also, 3GPP and 3GPP2 have earlier adopted the point-to-point link 147 model based on the recommendations in [RFC3314]. In this model, one 148 prefix can only be assigned to one interface of a host (mobile 149 station) and different hosts (mobile stations) can't share a prefix. 150 The unique prefix can be used to identify the host. It is not 151 necessary for a DHCPv6 server to generate an interface identifier for 152 the host. The host may generate its interface identifier as 153 described in [RFC4941]. An interface identifier could even be 154 generated via random number generation. 156 [RFC3972] defines Cryptographically Generated Addresses (CGA), which 157 is generated from a giving prefix and a public signature key. For 158 security reasons, it is only proper to be generated the user, the 159 host itself. It requests a prefix before the interface identifier 160 can be computed. 162 Modified EUI-64 interface identifier [EUI-64] is also typically 163 generated by hosts. [RFC4941] has defined temporary addresses for 164 privacy purposes. The temporary addresses is also generated by hosts 165 using random algorithm. 167 The DHCPv6 operations defined in this document supports 168 abovementioned address methods, and the host-generated addresses that 169 may defined in the future. 171 4. Address Auto-configuration 173 Router Advertisements in ND [RFC4861] allow routers to inform hosts 174 how to perform Address Auto-configuration. For example, routers can 175 specify whether hosts should use DHCPv6 and/or stateless address 176 configuration. In Router Advertisement message, M and O bits are 177 used for indication of address auto-configuration mode. 179 Whatever address auto-configuration mode a host uses, the following 180 two parts are necessary for the host to formulate it's IPv6 address: 182 o A prefix. "A bit string that consists of some number of initial 183 bits of an address" [RFC4861]. The prefixes can be announced 184 through Router Advertisement message. Prefix assignment from a 185 DHCPv6 server is not currently support. 186 o An interface identifier. "From address autoconfiguration's 187 perspective, an interface identifier is a bit string of known 188 length" [RFC4862]. Modified EUI-64 interface identifier [EUI-64] 189 is a widely-used host generated interface identifier. It 190 generates interface identifier from the host MAC address. The 191 interface identifier of CGA [RFC3972] is generated by computing a 192 preifx that will be used to form the CGA and a cryptographic hash 193 of a public key of a host. The host is responsible for interface 194 identifier generation. 196 In the ND-managed environment, RA is used to assign the prefix. 198 So far, there is no mechanism to support the scenario that prefixes 199 are managed by a DHCPv6 server. This document targets to meet this 200 gap. The DHCPv6 operation defined in this document enables the 201 DHCPv6 server to assign a prefix, rather than a integral address, to 202 the host, so that the host can obtain an IPv6 address by combining 203 the prefix with its own generated interface identifier. It enables 204 the auto address configuration through DHCPv6. 206 5. DHCPv6 Operation 208 Figure 1 shows the operation of separating prefix assignment and 209 interface identifier generation in the DHCPv6. 211 +------------+ +-------------+ 212 |Host(Client)| |DHCPv6 Server| 213 +------------+ +-------------+ 214 | 1 Solicit/Request | 215 |---------------------> | 216 | 2 Reply with IA_PA | 217 |<--------------------- | 218 3 Combination of Prefix | 219 and Interface Identifier | 220 | | 222 Figure 1: DHCPv6 Operation 224 1. A host uses a Solicit message to discover DHCPv6 servers. 225 Indications of information requests can be included in the 226 Solicit message or a Request message after discovery procedure. 227 If a host that wants to use host generated addresses, it SHOULD 228 request prefix assignment explicitly by including an IA_PA in a 229 Solicit or a Request message, in which an IAID is provided by the 230 host. 231 2. The DHCPv6 server assigns one or more prefixes to the host in the 232 Reply messages responding to the prefix requests from the hosts. 233 A server MUST return the same set of prefixes for the same IA_PA 234 (as identified by the IAID) as long as those prefixes are still 235 valid. After the lifetimes of the prefixes in an IA_TA have 236 expired, the IAID may be reused to identify a new IA_PA with new 237 prefix. If there is not a proper prefix available, a 238 NoPrefixAvail (defined in [RFC3633]) status-code is returned to 239 the host and the procedure is terminated. 240 3. The host generates an interface identifier and formulates a 241 combined IPv6 address by concatenating the assigned prefix and 242 the self-generated interface identifier. 244 After the host generates an IPv6 address using the above procedure, 245 the host may send a Request message to the DHCPv6 server in order to 246 confirm the usage of the new address. The confirmation procedure may 247 be completed together with the address registration procedure 248 [I-D.ietf-dhc-addr-registration]. However, the confirmation 249 procedure is out of scope. 251 When the host reaches T1 or T2 defined in Section 6.1, it SHOULD use 252 the same message exchanges, as described in section 18, "DHCP Client- 253 Initiated Configuration Exchange" of [RFC3315], to obtain or update 254 prefix(es) from a DHCPv6 server. 256 A DHCPv6 server MAY initiatively send a reconfiguration message to 257 the host, as described in section 19, "DHCP Server-Initiated 258 Configuration Exchange" of [RFC3315], to cause prefix(es) information 259 update. 261 If an IA_PA capable client connects to a network, and the DHCPv6 262 server is not IA_PA capable, the Solicit or Request message with 263 IA_PA Option will result in no Reply, Reply without IA_PAs, or Reply 264 with a Status Code containing UnspecFail. The client MAY decide the 265 network does not support IA_PA immediately or after a period of 266 soliciting (with limited retransmissions times). Then, it MAY 267 "failover" to IA_NA/IA_TA requests. 269 6. DHCPv6 IA_PA Option 271 In this section, one new option is defined, Identity Association for 272 Prefix Assignment Option . The format of this new DHCPv6 IA_PA 273 Option has been deliberately designed to be the same with IA_PD 274 option[RFC3633]. The IA_PD Prefix and IA Address sub-options from 275 IA_PD option are also reused. However, the two options are different 276 on the semantics and usage models. 278 Comparing with Prefix Information Option in ND, Section 4.6.2 of 279 [RFC4861], the IA_PA option does not provide L flag and A flag. The 280 A (autonomous address-configuration flag) isn't need obviously 281 because the IA_PA is implicit for stateless address configuration. 282 Because the IA_PA is only address relevant, it does not relevant to 283 reachability or routing and the DHCPv6 server may not sure the on- 284 link state. So L (on-Link) flag is not include. The DHCPv6 client 285 should treat the prefix as same as L flag not set, which makes no 286 statement about on-link or off-link properties of the prefix. 288 6.1. Identity Association for Prefix Assignment Option 290 The IA_PA option is used to carry a prefix assignment identity 291 association, the parameters associated with the IA_PA and the 292 prefixes associated with it. 294 The format of the IA_PA option is: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | OPTION_IA_PA | option-length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | IAID (4 octets) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | T1 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | T2 | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 . . 308 . IA_PA-options . 309 . . 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 option-code: OPTION_IA_PA (TBA1) 313 option-length: 12 + length of IA_PA-options field. 315 IAID: The unique identifier for this IA_PA; the IAID must 316 be unique among the identifiers for all of this 317 host's IA_PAs. The number space for IA_PA IAIDs is 318 separate from the number spaces for IA_TA and IA_NA 319 IAIDs 321 T1: The time at which the host should 322 contact the DHCPv6 server from which the 323 prefixes in the IA_PA were obtained to extend the 324 lifetimes of the prefixes assigned to the IA_PA; 325 T1 is a time duration relative to the current time 326 expressed in units of seconds. 328 T2: The time at which the host should 329 contact any available DHCPv6 server to extend 330 the lifetimes of the prefixes assigned to the 331 IA_PA; T2 is a time duration relative to the 332 current time expressed in units of seconds. 334 IA_PA-options: Options associated with this IA_PA. 336 The details of the fields are similar to the IA_PD option description 337 in [RFC3633]. The difference is here a DHCPv6 server and a host 338 involved, while a delegating router and requesting router involved in 339 [RFC3633]. 341 6.2. IA_PA Prefix Option 343 OPTION_IAPREFIX (26) "IA_PD Prefix Option" defined in Section 10 of 344 [RFC3633] is reused. 346 Originally, the option is used for conveying prefix information 347 between a delegating router and a requesting router. Here the IA_PD 348 Prefix option is used to specify IPv6 address prefixes associated 349 with an IA_PA in Section 6.1. The IA_PD Prefix option must be 350 encapsulated in the IA_PA-options field of an IA_PA option. 352 Note, the PD_EXCLUDE option [RFC6603] SHOULD NOT be encapsulated in 353 the IAPREFIX options that are encapsulated in an IA_PA. 355 7. IANA consideration 357 This document defines a new DHCPv6 [RFC3315] option, which must be 358 assigned Option Type values within the option numbering space for 359 DHCPv6 messages: 361 The OPTION_IA_PA Option (TBA1), described in Section 6.1. 363 8. Security Considerations 365 Security considerations in DHCPv6 are described in [RFC3315]. 367 To guard against attacks through prefix assignment, a host and a 368 DHCPv6 server SHOULD use DHCPv6 authentication as described in 369 Section 21, "Authentication of DHCP messages" of [RFC3315] or Secure 370 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] . 372 9. Acknowledgements 374 The authors would like to thanks Suresh Krishnan, Ted Lemon, Bing 375 Liu, Andre Kostur, Gaurav Halwasia, Bernie Volz and other members of 376 DHC WG for their valuable comments. 378 10. References 380 10.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 386 and M. Carney, "Dynamic Host Configuration Protocol for 387 IPv6 (DHCPv6)", RFC 3315, July 2003. 389 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 390 Host Configuration Protocol (DHCP) version 6", RFC 3633, 391 December 2003. 393 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 394 RFC 3972, March 2005. 396 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 397 Architecture", RFC 4291, February 2006. 399 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 400 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 401 September 2007. 403 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 404 Address Autoconfiguration", RFC 4862, September 2007. 406 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 407 Extensions for Stateless Address Autoconfiguration in 408 IPv6", RFC 4941, September 2007. 410 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 411 "Prefix Exclude Option for DHCPv6-based Prefix 412 Delegation", RFC 6603, May 2012. 414 10.2. Informative references 416 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 417 Generation Partnership Project (3GPP) Standards", 418 RFC 3314, September 2002. 420 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 421 Based Networks", RFC 4968, August 2007. 423 [I-D.ietf-dhc-secure-dhcpv6] 424 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 425 draft-ietf-dhc-secure-dhcpv6-07 (work in progress), 426 September 2012. 428 [I-D.ietf-dhc-addr-registration] 429 Jiang, S., Chen, G., and S. Krishnan, "A Generic IPv6 430 Addresses Registration Solution Using DHCPv6", 431 draft-ietf-dhc-addr-registration-01 (work in progress), 432 October 2012. 434 [EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64) 435 Registration Authority", http://standards.ieee.org/ 436 regauth/oui/tutorials/EUI64.html", March 1997. 438 Authors' Addresses 440 Sheng Jiang (editor) 441 Huawei Technologies 442 Q14, Huawei Campus, No.156, BeiQing Road 443 Hai-Dian District, Beijing 100095 444 P.R. China 446 Email: jiangsheng@huawei.com 448 Frank Xia 449 Huawei Technologies 450 1700 Alma Dr. Suite 500 451 Plano, TX 75075 453 Email: xiayangsong@huawei.com 455 Behcet Sarikaya 456 Huawei Technologies 457 1700 Alma Dr. Suite 500 458 Plano, TX 75075 460 Email: sarikaya@ieee.org