idnits 2.17.1 draft-xia-dhc-host-gen-id-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 419. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 1, 2008) is 5652 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) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 Expires: May 5, 2009 S. Jiang 5 Huawei Technologies 6 November 1, 2008 8 Usage of Host Generating Interface Identifier in DHCPv6 9 draft-xia-dhc-host-gen-id-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 5, 2009. 36 Abstract 38 This document describes a procedure for configuring a host's IPv6 39 address which prefix is allocated from a DHCPv6 server while it's 40 interface identifier is independently generated by the host. The 41 method is applicable to Cryptographically Generated Addresses (CGA). 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Address Auto-configuration in SEND . . . . . . . . . . . . . . 4 48 4. DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . 4 49 5. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . 6 50 5.1. Identity Association for Prefix Assignment Option . . . . 6 51 5.2. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . 8 52 5.3. IA Address Option . . . . . . . . . . . . . . . . . . . . 8 53 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 54 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 57 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 59 10.2. Informative references . . . . . . . . . . . . . . . . . . 9 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 61 Intellectual Property and Copyright Statements . . . . . . . . . . 11 63 1. Introduction 65 [RFC3315] describes the operation of address assignment by a DHCP 66 server. A client uses a Solicit message to discover DHCP servers 67 configured to assign addresses. A server sends an Advertise message 68 in response to announce the availability of the server to the client. 69 The client then uses a Request message to request addresses. The 70 server then returns addresses in a Reply message. The operation 71 assumes that the server is responsible for the assignment of an 72 integral address which include prefix and interface identifier parts 73 as described in [RFC4291]. 75 [RFC3633] defines Prefix Delegation options providing a mechanism for 76 automated delegation of IPv6 prefixes using the DHCPv6. This 77 mechanism is intended for delegating a long-lived prefix from a 78 delegating router to a requesting router. The practice of separating 79 prefix assignment from interface identifier assignment is only used 80 for routers not hosts. 82 [RFC3972] describes a method for binding a public signature key to an 83 IPv6 address in the Secure Neighbor Discovery (SEND) protocol 84 [RFC3971]. The basic idea is to generate the interface identifier 85 (i.e., the rightmost 64 bits) of the IPv6 address by computing a 86 cryptographic hash of the public key. That is, the host decides it's 87 interface identifier. As for the prefix part of the CGA, it is 88 probably got through Router Advertisement message defined in 89 [RFC4861], or through DHCPv6 operations defined in this document. 91 A usage of DHCPv6 is proposed in the document to facilitate 92 separation of prefix and interface identifier assignment. A host's 93 IPv6 address prefix is allocated from a DHCPv6 server while interface 94 identifier is independently generated by the host. Even though the 95 DHCPv6 operation defined in this document also has other 96 applicability described in Section 6, only CGA scenario is 97 exemplified hereafter. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 The terminology in this document is based on the definitions in 106 [RFC3315], in addition to the ones specified in this section 107 derivative prefix: A prefix is derived from another prefix. For 108 example, a /64 prefix is derived from a /48 prefix, that is, the 109 /64 prefix has the same leftmost 48 bits with the /48 prefix. 111 authorized prefix: A specific router is given a specific set of 112 subnet prefixes to advertise; other routers have an authorization 113 to advertise other subnet prefixes. In [RFC3971],Certification 114 Path Advertisement message is used to convey authorized prefixes. 116 3. Address Auto-configuration in SEND 118 Router Advertisements in [RFC4861] allow routers to inform hosts how 119 to perform Address Auto-configuration. For example, routers can 120 specify whether hosts should use DHCPv6 and/or stateless address 121 configuration. In Router Advertisement message, M and O bits are 122 used for indication of address auto-configuration mode. 124 Whatever address auto-configuration mode a host uses, the following 125 two parts are necessary for the host to formulate it's IPv6 address: 127 o A prefix part. In [RFC3971], Certification Path Solicitation and 128 Certification Path Advertisement messages are designed for 129 verifying routers being authorized to act as routers. 130 Certification Path Advertisement message can also be used to 131 verify that routers are authorized to advertise a certain set of 132 subnet prefixes. In stateless auto-configuration mode, the 133 prefixes in Router Advertisement message should be a subset of 134 authorized prefixes, or derivative prefixes from authorized 135 prefixes. In the stateful auto-configuration mode, Section 4 136 illustrates a procedure for prefix allocation from a DHCPv6 137 server. 138 o An interface identifier. The basic idea of [RFC3972] is to 139 generate the interface identifier (i.e., the rightmost 64 bits) of 140 the IPv6 address by computing a cryptographic hash of a public key 141 of a host. The host is responsible for interface identifier 142 generation. 144 4. DHCPv6 Operation 146 Figure 1 shows the operation of separating prefix assignment and 147 interface identifier generation. 149 +------------+ +-----------+ 150 |Host(Client)| |DHCP Server| 151 +------------+ +-----------+ 152 | | 153 | | 154 | | 155 | 1 Solicit | 156 |---------------------> | 157 | | 158 | 2 Advertise | 159 |<--------------------- | 160 | | 161 | | 162 3 Combination of Prefix | 163 and Interface Identifier | 164 | | 165 | | 166 | 4 Request | 167 |---------------------> | 168 | | 169 | 5 Reply | 170 |<--------------------- | 171 | | 172 | | 174 Figure 1: DHCPv6 Operation 176 1. A host uses a Solicit message to discover DHCP servers configured 177 to assign prefixes for the host. Identity Association for Prefix 178 Delegation Option (IA_PD) is defined in [RFC3633] for prefix 179 delegation between a requesting router and delegating router. 180 Referring to the definition, we design Identity Association for 181 Prefix Assignment Option (IA-PA) in Section 5.1 for prefix 182 assignment from a DHCPv6 server to a host. The host uses hints 183 for prefix assignment preference. The hints are authorized 184 prefixes advertised by an authorized router through Certification 185 Path Advertisement defined in [RFC3971]. 186 2. Based on the hints, the DHCP server assigns one or more prefixes 187 to the host. The assigned prefixes SHOULD be a subset of the 188 authorized prefixes or derivative prefixes of the authorized 189 prefixes. Identity Association for Prefix Assignment Option in 190 Section 5.1 is used for conveying the assigned prefixes. If 191 there is not a proper prefix available, a status-code is returned 192 to the host and the procedure is terminated. 193 3. The host generates an interface identifier and formulates a 194 combined IPv6 address by concatenating the assigned prefix and 195 the self-generated interface identifier. There are many ways to 196 generate interface identifier. [RFC3972] defines a method to 197 generate the interface identifier by computing a cryptographic 198 hash of a public key of the host. 199 4. The host sends a Request message for confirming usage of the 200 combined address. An IA Address option described in Section 5.3 201 SHOULD be included to convey the combined address. 202 5. The DHCP server SHOULD verify the uniqueness of the combined IP 203 address, and send Reply with IA Address option to grant the usage 204 of the combined address. Otherwise, a status code is included to 205 deny the usage of the combined address. 207 5. DHCPv6 Options 209 In this section, one new option is defined, Identity Association for 210 Prefix Assignment Option . At the same time, we extend the usage of 211 existing options, IA_PD Prefix and IA Address option. 213 5.1. Identity Association for Prefix Assignment Option 215 The IA_PA option is used to carry a prefix assignment identity 216 association, the parameters associated with the IA_PA and the 217 prefixes associated with it. 219 The format of the IA_PA option is: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | OPTION_IA_PA | option-length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | IAID (4 octets) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | T1 | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | T2 | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 . . 233 . IA_PA-options . 234 . . 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 option-code: OPTION_IA_PA (TDB by IANA) 238 option-length: 12 + length of IA_PA-options field. 240 IAID: The unique identifier for this IA_PA; the IAID must 241 be unique among the identifiers for all of this 242 host's IA_PAs. 244 T1: The time at which the host should 245 contact the DHCPv6 server from which the 246 prefixes in the IA_PA were obtained to extend the 247 lifetimes of the prefixes assigned to the IA_PA; 248 T1 is a time duration relative to the current time 249 expressed in units of seconds. 251 T2: The time at which the host should 252 contact any available DHCPv6 server to extend 253 the lifetimes of the prefixes assigned to the 254 IA_PA; T2 is a time duration relative to the 255 current time expressed in units of seconds. 257 IA_PA-options: Options associated with this IA_PA. 259 The details of the fields are similar to the IA_PD option description 260 in [RFC3633]. The difference is here a DHCP server and a host 261 involved, while a delegating router and requesting router involved in 262 [RFC3633]. 264 5.2. IA_PD Prefix option 266 IA_PD Prefix option in [RFC3633] is reused here. Originally the 267 option is used for conveying prefix information between a delegating 268 router and a requesting router. Here the IA_PD Prefix option is used 269 to specify IPv6 address prefixes associated with an IA_PA in 270 Section 5.1. The IA_PD Prefix option must be encapsulated in the 271 IA_PA-options field of an IA_PA option. 273 5.3. IA Address Option 275 The IA Address option in [RFC3315] is reused here. It must be 276 encapsulated in the Options field of an IA_NA or IA_TA option. IA_NA 277 and IA_TA are also described in [RFC3315]. 279 A host sends a DHCPv6 message with an IA Address option to a DHCPv6 280 server for validating the usage of an address in the option. 282 6. Applicability 284 In point-to-point link model, DHCPv6 operation with host generating 285 interface identifier described in this document may be used. 286 [RFC4968] provides different IPv6 link models that are suitable for 287 802.16 based networks and a point-to-point link model is recommended. 288 Also, 3GPP and 3GPP2 have earlier adopted the point-to-point link 289 model based on the recommendations in [RFC3314]. In this model, one 290 prefix can only be assigned to one interface of a host (mobile 291 station) and different hosts (mobile stations) can't share a prefix. 292 The unique prefix can be used to identify the host. It is not 293 necessary for a DHCP server to generate an interface identifier for 294 the host. The host may generates it's interface identifier as 295 described in [RFC4941]. An interface identifier could even be 296 generated via random number generation. 298 7. IANA consideration 300 The option code OPTION_IA_PA SHOULD be assigned by IANA. 302 8. Security Considerations 304 Security considerations in DHCPv6 are described in [RFC3315]. 306 To guard against attacks through prefix assignment and address 307 confirmation, a host and a DHCPv6 server SHOULD use DHCP 308 authentication as described in section "Authentication of DHCP 309 messages" of [RFC3315]. 311 9. Acknowledgements 313 10. References 315 10.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 321 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 322 September 2007. 324 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 325 Neighbor Discovery (SEND)", RFC 3971, March 2005. 327 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 328 RFC 3972, March 2005. 330 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 331 and M. Carney, "Dynamic Host Configuration Protocol for 332 IPv6 (DHCPv6)", RFC 3315, July 2003. 334 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 335 Host Configuration Protocol (DHCP) version 6", RFC 3633, 336 December 2003. 338 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 339 Architecture", RFC 4291, February 2006. 341 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 342 Extensions for Stateless Address Autoconfiguration in 343 IPv6", RFC 4941, September 2007. 345 10.2. Informative references 347 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 348 Based Networks", RFC 4968, August 2007. 350 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 351 Generation Partnership Project (3GPP) Standards", 352 RFC 3314, September 2002. 354 Authors' Addresses 356 Frank Xia 357 Huawei Technologies 358 1700 Alma Dr. Suite 500 359 Plano, TX 75075 361 Phone: +1 972-509-5599 362 Email: xiayangsong@huawei.com 364 Behcet Sarikaya 365 Huawei Technologies 366 1700 Alma Dr. Suite 500 367 Plano, TX 75075 369 Phone: +1 972-509-5599 370 Email: sarikaya@ieee.org 372 Sheng Jiang 373 Huawei Technologies 374 KuiKe Building, No.9 Xinxi Rd., 375 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 376 P.R. China 378 Phone: +86 10-82836774 379 Email: shengjiang@huawei.com 381 Full Copyright Statement 383 Copyright (C) The IETF Trust (2008). 385 This document is subject to the rights, licenses and restrictions 386 contained in BCP 78, and except as set forth therein, the authors 387 retain all their rights. 389 This document and the information contained herein are provided on an 390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 392 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 393 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 394 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 397 Intellectual Property 399 The IETF takes no position regarding the validity or scope of any 400 Intellectual Property Rights or other rights that might be claimed to 401 pertain to the implementation or use of the technology described in 402 this document or the extent to which any license under such rights 403 might or might not be available; nor does it represent that it has 404 made any independent effort to identify any such rights. Information 405 on the procedures with respect to rights in RFC documents can be 406 found in BCP 78 and BCP 79. 408 Copies of IPR disclosures made to the IETF Secretariat and any 409 assurances of licenses to be made available, or the result of an 410 attempt made to obtain a general license or permission for the use of 411 such proprietary rights by implementers or users of this 412 specification can be obtained from the IETF on-line IPR repository at 413 http://www.ietf.org/ipr. 415 The IETF invites any interested party to bring to its attention any 416 copyrights, patents or patent applications, or other proprietary 417 rights that may cover technology that may be required to implement 418 this standard. Please address the information to the IETF at 419 ietf-ipr@ietf.org.