idnits 2.17.1 draft-xia-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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 04, 2011) is 4796 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 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Intended status: Standards Track S. Jiang 5 Expires: September 5, 2011 Huawei Technologies 6 March 04, 2011 8 Usage of Host Generating Interface Identifier in DHCPv6 9 draft-xia-dhc-host-gen-id-03.txt 11 Abstract 13 This document describes a procedure for configuring a host's IPv6 14 address which prefix is allocated from a DHCPv6 server while it's 15 interface identifier is independently generated by the host. The 16 method is applicable to Cryptographically Generated Addresses (CGA). 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 5, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Address Auto-configuration in SEND . . . . . . . . . . . . . . 4 55 4. DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5.1. Identity Association for Prefix Assignment Option . . . . 6 58 5.2. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . 8 59 5.3. IA Address Option . . . . . . . . . . . . . . . . . . . . 8 60 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 10.2. Informative references . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 [RFC3315] describes the operation of address assignment by a DHCP 72 server. A client uses a Solicit message to discover DHCP servers 73 configured to assign addresses. A server sends an Advertise message 74 in response to announce the availability of the server to the client. 75 The client then uses a Request message to request addresses. The 76 server then returns addresses in a Reply message. The operation 77 assumes that the server is responsible for the assignment of an 78 integral address which include prefix and interface identifier parts 79 as described in [RFC4291]. 81 [RFC3633] defines Prefix Delegation options providing a mechanism for 82 automated delegation of IPv6 prefixes using the DHCPv6. This 83 mechanism is intended for delegating a long-lived prefix from a 84 delegating router to a requesting router. The practice of separating 85 prefix assignment from interface identifier assignment is only used 86 for routers not hosts. 88 [RFC3972] describes a method for binding a public signature key to an 89 IPv6 address in the Secure Neighbor Discovery (SEND) protocol 90 [RFC3971]. The basic idea is to generate the interface identifier 91 (i.e., the rightmost 64 bits) of the IPv6 address by computing a 92 cryptographic hash of the public key. That is, the host decides its 93 interface identifier. As for the prefix part of the CGA, it is 94 probably got through Router Advertisement message defined in 95 [RFC4861], or through DHCPv6 operations defined in this document. 97 [I-D.ietf-csi-dhcpv6-cga-ps] describes potential issues in the 98 interaction between DHCPv6 and CGA. A usage of DHCPv6 for generating 99 CGA is proposed in the document to facilitate separation of prefix 100 and interface identifier assignment. A host's IPv6 address prefix is 101 allocated from a DHCPv6 server while interface identifier is 102 independently generated by the host. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 The terminology in this document is based on the definitions in 111 [RFC3315], in addition to the ones specified in this section 112 derivative prefix: A prefix is derived from another prefix. For 113 example, a /64 prefix is derived from a /48 prefix, that is, the 114 /64 prefix has the same leftmost 48 bits with the /48 prefix. 116 authorized prefix: A specific router is given a specific set of 117 subnet prefixes to advertise; other routers have an authorization 118 to advertise other subnet prefixes. In [RFC3971],Certification 119 Path Advertisement message is used to convey authorized prefixes. 121 3. Address Auto-configuration in SEND 123 Router Advertisements in [RFC4861] allow routers to inform hosts how 124 to perform Address Auto-configuration. For example, routers can 125 specify whether hosts should use DHCPv6 and/or stateless address 126 configuration. In Router Advertisement message, M and O bits are 127 used for indication of address auto-configuration mode. 129 Whatever address auto-configuration mode a host uses, the following 130 two parts are necessary for the host to formulate it's IPv6 address: 132 o A prefix part. In [RFC3971], Certification Path Solicitation and 133 Certification Path Advertisement messages are designed for 134 verifying routers being authorized to act as routers. 135 Certification Path Advertisement message can also be used to 136 verify that routers are authorized to advertise a certain set of 137 subnet prefixes. In stateless auto-configuration mode, the 138 prefixes in Router Advertisement message should be a subset of 139 authorized prefixes, or derivative prefixes from authorized 140 prefixes. In the stateful auto-configuration mode, Section 4 141 illustrates a procedure for prefix allocation from a DHCPv6 142 server. 143 o An interface identifier. The basic idea of [RFC3972] is to 144 generate the interface identifier (i.e., the rightmost 64 bits) of 145 the IPv6 address by computing a cryptographic hash of a public key 146 of a host. The host is responsible for interface identifier 147 generation. 149 4. DHCPv6 Operation 151 Figure 1 shows the operation of separating prefix assignment and 152 interface identifier generation. 154 +------------+ +-----------+ 155 |Host(Client)| |DHCP Server| 156 +------------+ +-----------+ 157 | | 158 | | 159 | | 160 | 1 Solicit | 161 |---------------------> | 162 | | 163 | 2 Advertise | 164 |<--------------------- | 165 | | 166 | | 167 3 Combination of Prefix | 168 and Interface Identifier | 169 | | 170 | | 171 | 4 Request | 172 |---------------------> | 173 | | 174 | 5 Reply | 175 |<--------------------- | 176 | | 177 | | 179 Figure 1: DHCPv6 Operation 181 1. A host uses a Solicit message to discover DHCP servers configured 182 to assign prefixes for the host. Identity Association for Prefix 183 Delegation Option (IA_PD) is defined in [RFC3633] for prefix 184 delegation between a requesting router and delegating router. 185 Referring to the definition, we design Identity Association for 186 Prefix Assignment Option (IA-PA) in Section 5.1 for prefix 187 assignment from a DHCPv6 server to a host. The host uses hints 188 for prefix assignment preference. The hints are authorized 189 prefixes advertised by an authorized router through Certification 190 Path Advertisement defined in [RFC3971]. 191 2. Based on the hints, the DHCP server assigns one or more prefixes 192 to the host. The assigned prefixes SHOULD be a subset of the 193 authorized prefixes or derivative prefixes of the authorized 194 prefixes. Identity Association for Prefix Assignment Option in 195 Section 5.1 is used for conveying the assigned prefixes. If 196 there is not a proper prefix available, a status-code is returned 197 to the host and the procedure is terminated. 198 3. The host generates an interface identifier and formulates a 199 combined IPv6 address by concatenating the assigned prefix and 200 the self-generated interface identifier. There are many ways to 201 generate interface identifier. [RFC3972] defines a method to 202 generate the interface identifier by computing a cryptographic 203 hash of a public key of the host. 204 4. The host sends a Request message for confirming usage of the 205 combined address. An IA Address option described in Section 5.3 206 SHOULD be included to convey the combined address. 207 5. The DHCP server SHOULD verify the uniqueness of the combined IP 208 address, and send Reply with IA Address option to grant the usage 209 of the combined address. Otherwise, a status code is included to 210 deny the usage of the combined address. 212 5. DHCPv6 Options 214 In this section, one new option is defined, Identity Association for 215 Prefix Assignment Option . At the same time, we extend the usage of 216 existing options, IA_PD Prefix and IA Address option. 218 5.1. Identity Association for Prefix Assignment Option 220 The IA_PA option is used to carry a prefix assignment identity 221 association, the parameters associated with the IA_PA and the 222 prefixes associated with it. 224 The format of the IA_PA option is: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | OPTION_IA_PA | option-length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | IAID (4 octets) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | T1 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | T2 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 . . 238 . IA_PA-options . 239 . . 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 option-code: OPTION_IA_PA (TBA1) 243 option-length: 12 + length of IA_PA-options field. 245 IAID: The unique identifier for this IA_PA; the IAID must 246 be unique among the identifiers for all of this 247 host's IA_PAs. 249 T1: The time at which the host should 250 contact the DHCPv6 server from which the 251 prefixes in the IA_PA were obtained to extend the 252 lifetimes of the prefixes assigned to the IA_PA; 253 T1 is a time duration relative to the current time 254 expressed in units of seconds. 256 T2: The time at which the host should 257 contact any available DHCPv6 server to extend 258 the lifetimes of the prefixes assigned to the 259 IA_PA; T2 is a time duration relative to the 260 current time expressed in units of seconds. 262 IA_PA-options: Options associated with this IA_PA. 264 The details of the fields are similar to the IA_PD option description 265 in [RFC3633]. The difference is here a DHCP server and a host 266 involved, while a delegating router and requesting router involved in 267 [RFC3633]. 269 5.2. IA_PD Prefix option 271 IA_PD Prefix option in [RFC3633] is reused here. Originally the 272 option is used for conveying prefix information between a delegating 273 router and a requesting router. Here the IA_PD Prefix option is used 274 to specify IPv6 address prefixes associated with an IA_PA in 275 Section 5.1. The IA_PD Prefix option must be encapsulated in the 276 IA_PA-options field of an IA_PA option. 278 5.3. IA Address Option 280 The IA Address option in [RFC3315] is reused here. It must be 281 encapsulated in the Options field of an IA_NA or IA_TA option. IA_NA 282 and IA_TA are also described in [RFC3315]. 284 A host sends a DHCPv6 message with an IA Address option to a DHCPv6 285 server for validating the usage of an address in the option. 287 6. Applicability 289 In point-to-point link model, DHCPv6 operation with host generating 290 interface identifier described in this document may be used. 291 [RFC4968] provides different IPv6 link models that are suitable for 292 802.16 based networks and a point-to-point link model is recommended. 293 Also, 3GPP and 3GPP2 have earlier adopted the point-to-point link 294 model based on the recommendations in [RFC3314]. In this model, one 295 prefix can only be assigned to one interface of a host (mobile 296 station) and different hosts (mobile stations) can't share a prefix. 297 The unique prefix can be used to identify the host. It is not 298 necessary for a DHCP server to generate an interface identifier for 299 the host. The host may generates it's interface identifier as 300 described in [RFC4941]. An interface identifier could even be 301 generated via random number generation. 303 7. IANA consideration 305 This document defines a new DHCPv6 [RFC3315] option, which must be 306 assigned Option Type values within the option numbering space for 307 DHCPv6 messages: 309 The OPTION_IA_PA Option (TBA1), described in Section 5.1. 311 8. Security Considerations 313 Security considerations in DHCPv6 are described in [RFC3315]. 315 To guard against attacks through prefix assignment and address 316 confirmation, a host and a DHCPv6 server SHOULD use DHCP 317 authentication as described in section "Authentication of DHCP 318 messages" of [RFC3315]. 320 9. Acknowledgements 322 10. References 324 10.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 330 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 331 September 2007. 333 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 334 Neighbor Discovery (SEND)", RFC 3971, March 2005. 336 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 337 RFC 3972, March 2005. 339 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 340 and M. Carney, "Dynamic Host Configuration Protocol for 341 IPv6 (DHCPv6)", RFC 3315, July 2003. 343 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 344 Host Configuration Protocol (DHCP) version 6", RFC 3633, 345 December 2003. 347 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 348 Architecture", RFC 4291, February 2006. 350 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 351 Extensions for Stateless Address Autoconfiguration in 352 IPv6", RFC 4941, September 2007. 354 10.2. Informative references 356 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 357 Based Networks", RFC 4968, August 2007. 359 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 360 Generation Partnership Project (3GPP) Standards", 361 RFC 3314, September 2002. 363 [I-D.ietf-csi-dhcpv6-cga-ps] 364 Jiang, S., "DHCPv6 and CGA Interaction: Problem 365 Statement", draft-ietf-csi-dhcpv6-cga-ps-06 (work in 366 progress), October 2010. 368 Authors' Addresses 370 Frank Xia 371 Huawei Technologies 372 1700 Alma Dr. Suite 500 373 Plano, TX 75075 375 Phone: +1 972-509-5599 376 Email: xiayangsong@huawei.com 378 Behcet Sarikaya 379 Huawei Technologies 380 1700 Alma Dr. Suite 500 381 Plano, TX 75075 383 Phone: +1 972-509-5599 384 Email: sarikaya@ieee.org 386 Sheng Jiang 387 Huawei Technologies 388 KuiKe Building, No.9 Xinxi Rd., 389 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 390 P.R. China 392 Phone: +86 10-82836774 393 Email: shengjiang@huawei.com