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