idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- 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 30, 2012) is 4250 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, Ed. 3 Internet-Draft F. Xia 4 Intended status: Standards Track B. Sarikaya 5 Expires: March 3, 2013 Huawei Technologies 6 August 30, 2012 8 Prefix Assignment in DHCPv6 9 draft-ietf-dhc-host-gen-id-04 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. 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 March 3, 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. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Address Auto-configuration . . . . . . . . . . . . . . . . . . 5 59 5. DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. DHCPv6 IA_PA Option . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Identity Association for Prefix Assignment Option . . . . 7 62 6.2. IA_PA Prefix Option . . . . . . . . . . . . . . . . . . . 9 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 applicable user 88 cases include CGA [RFC3972], modified EUI-64 interface identifier 89 [EUI-64], 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 host-oriented prefix assignment 106 in DHCPv6. [RFC3633] defines Prefix Delegation options providing a 107 mechanism for automated delegation of IPv6 prefixes using the DHCPv6. 108 This mechanism is intended for delegating a long-lived prefix from a 109 delegating router to a requesting router. This mechanism "is not 110 bound to the assignment of IP addresses or other configuration 111 information to hosts" [RFC3633]. It delegates prefixes to a routable 112 device for itself use only. It does not support the host-generated 113 interface identifiers model, in which prefix(es) need to be 114 propagated to hosts. 116 This document introduces a generic prefix assignment mechanism using 117 DHCPv6. In this new address configuration procedure, the prefix is 118 propagated from a DHCPv6 server to hosts through DHCPv6 message 119 exchanging while the interface identifiers are independently 120 generated by the hosts. It enables both integral address assignment 121 and self-generated addresses in one single mechanism, DHCPv6. Note, 122 in many scenarios, Neighbor Discovery [RFC4861] is still needed for 123 routing and reachability. In other scenarios, this mechanism enables 124 stateless address configuration while RA absents. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 The terminology in this document is mainly based on the definitions 133 in [RFC3315] and [RFC3633]. 135 Prefix assignment: a DHCPv6 server propagates prefix information to 136 hosts in unicast model. 138 3. Applicability 140 In point-to-point link model, DHCPv6 operation with host-generated 141 interface identifier, described in this document, may be used. 142 [RFC4968] provides different IPv6 link models that are suitable for 143 802.16 based networks and a point-to-point link model is recommended. 144 Also, 3GPP and 3GPP2 have earlier adopted the point-to-point link 145 model based on the recommendations in [RFC3314]. In this model, one 146 prefix can only be assigned to one interface of a host (mobile 147 station) and different hosts (mobile stations) can't share a prefix. 148 The unique prefix can be used to identify the host. It is not 149 necessary for a DHCPv6 server to generate an interface identifier for 150 the host. The host may generate its interface identifier as 151 described in [RFC4941]. An interface identifier could even be 152 generated via random number generation. 154 [RFC3972] defines Cryptographically Generated Addresses (CGA), which 155 is generated from a giving prefix and a public signature key. For 156 security reasons, it is only proper to be generated the user, the 157 host itself. It requests a prefix before the interface identifier 158 can be computed. 160 Modified EUI-64 interface identifier [EUI-64] is also typically 161 generated by hosts. [RFC4941] has defined temporary addresses for 162 privacy purposes. The temporary addresses is also generated by hosts 163 using random algorithm. 165 The DHCPv6 operations defined in this document supports 166 abovementioned address methods, and the host-generated addresses that 167 may defined in the future. 169 4. Address Auto-configuration 171 Router Advertisements in ND [RFC4861] allow routers to inform hosts 172 how to perform Address Auto-configuration. For example, routers can 173 specify whether hosts should use DHCPv6 and/or stateless address 174 configuration. In Router Advertisement message, M and O bits are 175 used for indication of address auto-configuration mode. 177 Whatever address auto-configuration mode a host uses, the following 178 two parts are necessary for the host to formulate it's IPv6 address: 180 o A prefix. "A bit string that consists of some number of initial 181 bits of an address" [RFC4861]. The prefixes can be announced 182 through Router Advertisement message. Prefix assignment from a 183 DHCPv6 server is not currently support. 184 o An interface identifier. "From address autoconfiguration's 185 perspective, an interface identifier is a bit string of known 186 length" [RFC4862]. Modified EUI-64 interface identifier [EUI-64] 187 is a widely-used host generated interface identifier. It 188 generates interface identifier from the host MAC address. The 189 interface identifier of CGA [RFC3972] is generated by computing a 190 preifx that will be used to form the CGA and a cryptographic hash 191 of a public key of a host. The host is responsible for interface 192 identifier generation. 194 In the ND-managed environment, RA is used to assign the prefix. 196 So far, there is no mechanism to support the scenario that prefixes 197 are managed by a DHCPv6 server. This document targets to meet this 198 gap. The DHCPv6 operation defined in this document enables the 199 DHCPv6 server to assign a prefix, rather than a integral address, to 200 the host, so that the host can obtain an IPv6 address by combining 201 the prefix with its own generated interface identifier. It enables 202 the auto address configuration through DHCPv6. 204 5. DHCPv6 Operation 206 Figure 1 shows the operation of separating prefix assignment and 207 interface identifier generation in the DHCPv6. 209 +------------+ +-------------+ 210 |Host(Client)| |DHCPv6 Server| 211 +------------+ +-------------+ 212 | 1 Solicit/Request | 213 |---------------------> | 214 | 2 Reply with IA_PA | 215 |<--------------------- | 216 3 Combination of Prefix | 217 and Interface Identifier | 218 | | 220 Figure 1: DHCPv6 Operation 222 1. A host uses a Solicit message to discover DHCPv6 servers. 223 Indications of information requests can be included in the 224 Solicit message or a Request message after discovery procedure. 225 If a host that wants to use host generated addresses, it SHOULD 226 request prefix assignment explicitly by including an IA_PA in a 227 Solicit or a Request message, in which an IAID is provided by the 228 host. 229 2. The DHCPv6 server assigns one or more prefixes to the host in the 230 Reply messages responding to the prefix requests from the hosts. 231 A server MUST return the same set of prefixes for the same IA_PA 232 (as identified by the IAID) as long as those prefixes are still 233 valid. After the lifetimes of the prefixes in an IA_TA have 234 expired, the IAID may be reused to identify a new IA_PA with new 235 prefix. If there is not a proper prefix available, a 236 NoPrefixAvail (defined in [RFC3633]) status-code is returned to 237 the host and the procedure is terminated. 238 3. The host generates an interface identifier and formulates a 239 combined IPv6 address by concatenating the assigned prefix and 240 the self-generated interface identifier. 242 After the host generates an IPv6 address using the above procedure, 243 the host may send a Request message to the DHCPv6 server in order to 244 confirm the usage of the new address. The confirmation procedure may 245 be completed together with the address registration procedure 246 [I-D.ietf-dhc-addr-registration]. However, the confirmation 247 procedure is out of scope. 249 When the host reaches T1 or T2 defined in Section 6.1, it SHOULD use 250 the same message exchanges, as described in section 18, "DHCP Client- 251 Initiated Configuration Exchange" of [RFC3315], to obtain or update 252 prefix(es) from a DHCPv6 server. 254 A DHCPv6 server MAY initiatively send a reconfiguration message to 255 the host, as described in section 19, "DHCP Server-Initiated 256 Configuration Exchange" of [RFC3315], to cause prefix(es) information 257 update. 259 If an IA_PA capable client connects to a network, and the DHCPv6 260 server is not IA_PA capable, the Solicit or Request message with 261 IA_PA Option will result in no Reply, Reply without IA_PAs, or Reply 262 with a Status Code containing UnspecFail. The client MAY decide the 263 network does not support IA_PA immediately or after a period of 264 soliciting (with limited retransmissions times). Then, it MAY 265 "failover" to IA_NA/IA_TA requests. 267 6. DHCPv6 IA_PA Option 269 In this section, one new option is defined, Identity Association for 270 Prefix Assignment Option . The format of this new DHCPv6 IA_PA 271 Option has been deliberately designed to be the same with IA_PD 272 option[RFC3633]. The IA_PD Prefix and IA Address sub-options from 273 IA_PD option are also reused. However, the two options are different 274 on the semantics and usage models. 276 Comparing with Prefix Information Option in ND, Section 4.6.2 of 277 [RFC4861], the IA_PA option does not provide L flag and A flag. The 278 A (autonomous address-configuration flag) isn't need obviously 279 because the IA_PA is implicit for stateless address configuration. 280 Because the IA_PA is only address relevant, it does not relevant to 281 reachability or routing and the DHCPv6 server may not sure the on- 282 link state. So L (on-Link) flag is not include. The DHCPv6 client 283 should treat the prefix as same as L flag not set, which makes no 284 statement about on-link or off-link properties of the prefix. 286 6.1. Identity Association for Prefix Assignment Option 288 The IA_PA option is used to carry a prefix assignment identity 289 association, the parameters associated with the IA_PA and the 290 prefixes associated with it. 292 The format of the IA_PA option is: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | OPTION_IA_PA | option-length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | IAID (4 octets) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | T1 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | T2 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 . . 306 . IA_PA-options . 307 . . 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 option-code: OPTION_IA_PA (TBA1) 311 option-length: 12 + length of IA_PA-options field. 313 IAID: The unique identifier for this IA_PA; the IAID must 314 be unique among the identifiers for all of this 315 host's IA_PAs. The number space for IA_PA IAIDs is 316 separate from the number spaces for IA_TA and IA_NA 317 IAIDs 319 T1: The time at which the host should 320 contact the DHCPv6 server from which the 321 prefixes in the IA_PA were obtained to extend the 322 lifetimes of the prefixes assigned to the IA_PA; 323 T1 is a time duration relative to the current time 324 expressed in units of seconds. 326 T2: The time at which the host should 327 contact any available DHCPv6 server to extend 328 the lifetimes of the prefixes assigned to the 329 IA_PA; T2 is a time duration relative to the 330 current time expressed in units of seconds. 332 IA_PA-options: Options associated with this IA_PA. 334 The details of the fields are similar to the IA_PD option description 335 in [RFC3633]. The difference is here a DHCPv6 server and a host 336 involved, while a delegating router and requesting router involved in 337 [RFC3633]. 339 6.2. IA_PA Prefix Option 341 OPTION_IAPREFIX (26) "IA_PD Prefix Option" defined in Section 10 of 342 [RFC3633] is reused. 344 Originally, the option is used for conveying prefix information 345 between a delegating router and a requesting router. Here the IA_PD 346 Prefix option is used to specify IPv6 address prefixes associated 347 with an IA_PA in Section 6.1. The IA_PD Prefix option must be 348 encapsulated in the IA_PA-options field of an IA_PA option. 350 Note, the PD_EXCLUDE option [RFC6603] SHOULD NOT be encapsulated in 351 the IAPREFIX options that are encapsulated in an IA_PA. 353 7. IANA consideration 355 This document defines a new DHCPv6 [RFC3315] option, which must be 356 assigned Option Type values within the option numbering space for 357 DHCPv6 messages: 359 The OPTION_IA_PA Option (TBA1), described in Section 6.1. 361 8. Security Considerations 363 Security considerations in DHCPv6 are described in [RFC3315]. 365 To guard against attacks through prefix assignment, a host and a 366 DHCPv6 server SHOULD use DHCPv6 authentication as described in 367 Section 21, "Authentication of DHCP messages" of [RFC3315] or Secure 368 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] . 370 9. Acknowledgements 372 The authors would like to thanks Suresh Krishnan, Ted Lemon, Bing 373 Liu, Andre Kostur, Gaurav Halwasia, Bernie Volz and other members of 374 DHC WG for their valuable comments. 376 10. References 378 10.1. Normative References 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 384 and M. Carney, "Dynamic Host Configuration Protocol for 385 IPv6 (DHCPv6)", RFC 3315, July 2003. 387 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 388 Host Configuration Protocol (DHCP) version 6", RFC 3633, 389 December 2003. 391 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 392 RFC 3972, March 2005. 394 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 395 Architecture", RFC 4291, February 2006. 397 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 398 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 399 September 2007. 401 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 402 Address Autoconfiguration", RFC 4862, September 2007. 404 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 405 Extensions for Stateless Address Autoconfiguration in 406 IPv6", RFC 4941, September 2007. 408 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 409 "Prefix Exclude Option for DHCPv6-based Prefix 410 Delegation", RFC 6603, May 2012. 412 10.2. Informative references 414 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 415 Generation Partnership Project (3GPP) Standards", 416 RFC 3314, September 2002. 418 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 419 Based Networks", RFC 4968, August 2007. 421 [I-D.ietf-dhc-secure-dhcpv6] 422 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 423 draft-ietf-dhc-secure-dhcpv6-06 (work in progress), 424 March 2012. 426 [I-D.ietf-dhc-addr-registration] 427 Jiang, S. and G. Chen, "A Generic IPv6 Addresses 428 Registration Solution Using DHCPv6", 429 draft-ietf-dhc-addr-registration-00 (work in progress), 430 May 2012. 432 [EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64) 433 Registration Authority", http://standards.ieee.org/ 434 regauth/oui/tutorials/EUI64.html", March 1997. 436 Authors' Addresses 438 Sheng Jiang (editor) 439 Huawei Technologies 440 Q14, Huawei Campus, No.156, BeiQing Road 441 Hai-Dian District, Beijing 100095 442 P.R. China 444 Email: jiangsheng@huawei.com 446 Frank Xia 447 Huawei Technologies 448 1700 Alma Dr. Suite 500 449 Plano, TX 75075 451 Email: xiayangsong@huawei.com 453 Behcet Sarikaya 454 Huawei Technologies 455 1700 Alma Dr. Suite 500 456 Plano, TX 75075 458 Email: sarikaya@ieee.org