idnits 2.17.00 (12 Aug 2021) /tmp/idnits30479/draft-jiang-sendcgaext-cga-config-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.3 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 633. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 are 2 instances 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3972' is mentioned on line 127, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Unexpected draft version: The latest known version of draft-kempf-cgaext-ringsig-ndproxy is -00, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. 'MCGA' == Outdated reference: draft-ietf-6man-reserved-iids has been published as RFC 5453 == Outdated reference: draft-ietf-shim6-proto has been published as RFC 5533 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sheng Jiang 2 Internet Draft Sam(Zhongqi) Xia 3 Expires: January 2009 Huawei Technologies Co., Ltd 4 Alberto Garcia-Martinez 5 UC3M 6 July 11th, 2008 8 Requirements for configuring Cryptographically Generated Addresses (CGA) 9 and overview on RA and DHCPv6-based approaches 10 draft-jiang-sendcgaext-cga-config-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 This document may only be posted in an Internet-Draft. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on January 10, 2009. 38 Abstract 40 This document analyzes the requirements for the configuration 41 Cryptographically Generated Addresses and Multi-key CGAs. The 42 applicability of Router Advertisement and DHCPv6 for this 43 configuration is also discussed. 45 Table of Contents 47 1. Introduction................................................2 48 2. Terminology.................................................3 49 3. Requirements................................................3 50 3.1. Configuration of the parameters required for the generation 51 of CGA......................................................3 52 3.1.1. Offloading the large computational burden...........4 53 3.1.2. Certificate information dissemination..............5 54 3.2. CGA granting and registration...........................5 55 3.3. Configuration the parameters in order to enable the CGA proxy 56 ............................................................5 57 4. Approaches overview.........................................6 58 4.1. Node requests CGA-related configuration parameters to the 59 DHCPv6 server...............................................7 60 4.2. Node requests to the DHCPv6 server the computation of the 61 Modifier....................................................7 62 4.3. Node requests DHCPv6 server to grant the CGA............8 63 4.4. Node sends MCGA-specific information to the DHCPv6 server8 64 5. Security Considerations......................................8 65 5.1. Threat Analysis of the Configuration Requirements........8 66 5.1.1. Threats faced by the end hosts.....................8 67 5.1.2. Threats faced by the configuration servers and proxies10 68 5.2. Threat Analysis of the Approaches Proposed.............10 69 5.2.1. Router Advertisement with SEND support............11 70 5.2.2. Router Advertisement without SEND support..........11 71 5.2.3. DHCPv6...........................................11 72 6. IANA Considerations........................................12 73 7. Conclusions................................................12 74 8. Acknowledgments............................................12 75 9. References.................................................12 76 9.1. Normative References...................................12 77 9.2. Informative References.................................13 78 Author's Addresses............................................14 79 Intellectual Property Statement................................14 80 Disclaimer of Validity........................................15 81 Copyright Statement...........................................15 83 1. Introduction 85 Cryptographically Generated Addresses (CGA, [RFC3972]) provide means 86 to verify the ownership of IPv6 addresses without requiring any 87 security infrastructure such as a certification authority. As an 88 extension to enable SEure Neighbor Discovery (SEND, [RFC3971]) proxy 89 support, multi-key CGAs [MCGA] have been introduced. The use of both 90 types of addresses has been proposed for allowing identity 91 verification in different protocols, such as SEND, Enhanced Route 92 Optimization for MIPv6 [RFC4866] or SHIM6 [SHIM6-proto]. 94 In the current specifications, there is a lack of procedures to 95 enable proper management of CGA generation, in particular, in the 96 configuration of the parameters that define the security properties 97 of the addresses. Additionally, there is a lack of tools for 98 informing the hosts about the availability of SEND proxies, and 99 exchanging the required information with the proxies. Finally, there 100 are no means to delegate the computation of the Modifier, a CPU 101 intensive operation, to faster or non battery-dependant resources. 103 This draft analyses the configuration requirements raised by CGA and 104 MCGA generation. Additionally, the applicability of Router 105 Advertisement and Dynamic Host Configuration Protocol for IPv6 106 (DHCPv6 [RFC3315]) for performing this configuration is discussed. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC2119 [RFC2119]. 114 3. Requirements 116 The CGA specifications [RFC3972, MCGA] define the procedure to 117 generate a CGA. However, these procedures do not allow the 118 enforcement of a given configuration to a group of hosts, nor address 119 the interactions between end hosts and proxies required for proxy 120 configuration. It does also not consider the delegation of CPU- 121 intensive operations to other nodes. In this section, we analyze the 122 scenarios in which these operations are required. 124 3.1. Configuration of the parameters required for the generation of CGA 126 The CGA associated Parameters used to generate a CGA includes several 127 parameters [RFC 3972]: 129 - a Public Key, 131 - a Subnet Prefix, 133 - a 3-bit security parameter Sec, 134 - a Modifier that is selected so that the result of a hash to 135 comply with the requirements introduced by the value of a security 136 parameter Sec in order to provide protection against brute-force 137 attacks, 139 - a Collision Count value, increased each time the address 140 generated results in a collision in the subnet considered, 142 - any Extension Fields that could be used. 144 Additionally, it should be noted that the hash algorithm to be used 145 in the generation of the CGA is also defined by the Sec value 146 [RFC4982]. 148 Currently, there are convenient mechanisms for allowing an 149 administrator to configure the subnet prefix for a host. Other 150 parameters used for generating the CGA could also benefit from the 151 possibility of being configured by the administrator. For instance, 152 the administrator can determine, according to the type of 153 infrastructure and the security needs, the Sec value that should be 154 used by the hosts to generate the CGA. 156 When appropriate, the Extension Fields could also be mandated by the 157 administrator. 159 Upon reception of this information, the end hosts SHOULD generate 160 addresses compliant with the received parameters. If the parameters 161 change, the end hosts SHOULD generate new addresses compliant with 162 the parameters propagated. 164 3.1.1. Offloading the large computational burden 166 An important case to consider is the large computational consumption 167 of the generation of the Modifier field. The Modifier is a 128 168 unsigned integer that is selected so that the Hash2 operation defined 169 in RFC 3972 results in the required number of leftmost 0 bits. The 170 higher the number of bits required being 0, the more secure a CGA is 171 against brute-force attacks. However, high number of bits also 172 results in additional computational cost for the generation process, 173 cost that could be deemed excessive in certain environments, such as 174 mobile terminals with low computing power. As an example, consider a 175 Sec value equals 2, requesting the leftmost 32 bits of a SHA-1 Hash2 176 to be zero. For assuring this, a system has to generate in mean 2^32 177 different modifiers, and perform the Hash2 operation to check the 178 bits required to be 0. An estimation of the CPU power required to do 179 this can be obtained as following: openSSL can perform in an Intel 180 Core2-6300 on an Asus p5b-w motherboard close to 0.87 million of SHA- 181 1 operations on 16 byte blocks per second. Since the input data of 182 Hash2 operation is larger than 16 bytes, this value is an upper bound 183 for the number of hash operations that can be performed for 184 generating the modifier. Checking 2^32 different modifiers requires 185 around 5000 seconds. The high number of required operations can 186 represent a problem for end hosts (i.e. mobile devices) with much 187 lower computing power than considered in the example, and/or with 188 restrictions in battery resources. For these cases, a mechanism for 189 delegating the computation of the modifier should be provided. 191 3.1.2. Certificate information dissemination 193 CGAs enable the verification of the relationship between a 194 public/private key pair (certificate) and an address. However, it 195 does not verify the identity of a sender. In most of scenarios, it is 196 necessary to know which certificates or certificate chains are 197 trustworthy. Mechanisms are required to disseminate such information 198 to CGA receivers. 200 3.2. CGA granting and registration 202 The usage of self-generated CGAs may need to be granted by the 203 networking management plate. Only granted CGAs are allowed to be used 204 to access the network. It is also validated whether the CGAs do not 205 use the reserved range of interface identifier [RIID]. 207 As described in RFC 3972, the modifier can be reused when the prefix 208 of the CGA changes and this is the only change. However, when a 209 mobile node moves from a network to another, not only the prefix 210 changes, but also other CGA relevant parameters may change. Therefore, 211 any CGAs generated by the node itself should also be granted by the 212 networking management plate. 214 A node that has generated a CGA could register the resulting address 215 so that a central administration could manage this information. The 216 node could be requested to perform this registration. 218 3.3. Configuration the parameters in order to enable the CGA proxy 220 In order to preserve location privacy of CGAs, the CGA proxy 221 solutions, such as Multi-Key Cryptographically Generated Addresses 222 (MCGAs), are introduced. These CGA proxy solutions require that 223 certain information/parameters of proxy are configured. 225 First of all, end hosts should be notified that their SEND validation 226 could be proxied, and therefore that they should generate MCGA 227 addresses. In order to generate the MCGA, and in addition to the Sec 228 parameter and Extension Fields required for CGA bootstrapping, the 229 node must know the node's own public key and the public key(s) from 230 its proxy(s), which are certified router public keys. RFC 3971 231 describe a mechanism that allows the node to obtain the public keys 232 of the router(s), although other protocols could be used for this 233 purpose. 235 Upon reception of this information, the end hosts SHOULD generate 236 MCGAs compliant with the received parameters. If the parameters 237 change, the end hosts SHOULD generate new MCGAs compliant with the 238 parameters propagated. 240 Additionally, the proxy(s) should be notified the new MCGA and its 241 associated CGA Parameters Data Structure, so that the proxy could 242 securely proxy the MCGA by signing the message with its own private 243 key. Consequently, a mechanism for making proxy(s) aware of the keys 244 used by each end host should be provided. 246 4. Approaches overview 248 Among the mechanisms in which configuration parameters could be 249 pushed to the end hosts and/or CGA related information sent back to a 250 central administration, we discuss two mechanisms: the stateless 251 address configuration mechanism based in Router Advertisement, and 252 the stateful configuration mechanism based in DCHPv6. 254 On one hand, Router Advertisement could be extended with an option 255 that could convey parameters related with CGA configuration, such as 256 the value of the Sec or the values of future Extension Fields, etc. 257 In this way, a router could distribute these parameters to all the 258 hosts of the subnet through Router Advertisement, in the same message 259 in which prefix information is conveyed. 261 On the other hand, DHCPv6 can be extended to: 263 - propagate to the end hosts the values of the basic parameters 264 required to configure CGAs, 266 - request the node to propagate to the server the resulting CGA 267 address, 269 - grant the node to use its self-generated CGA address, 271 - obtain from the end host CGA information to update any database 272 with the addresses being used, 274 - inform the end hosts about the convenience for generating MCGA, 275 - obtain from the end hosts the MCGA information required to 276 configure the proxy(s), 278 - receive requests for generating a Modifier according to a given 279 security configuration, and returning the result to the end host. 281 Finally, both Router Advertisement and DCHPv6 could be combined in 282 the following cases: 284 - when the node is requested by Router Advertisement to register 285 the resulting CGA, DHCPv6 could be used to inform the DHCPv6 server 286 about the resulting address, 288 - when MCGA address are generated, Router Advertisement could be 289 used to propagate the basic CGA parameters, and a notification that 290 the end host should generate MCGA, and use DHCPv6 to inform the 291 DHCPv6 server about the public key material used for MCGA 292 generation, 294 - when the node solicits the computation of the Modifier, after 295 receiving a Router Advertisement with the Sec parameters and 296 Extension Fields, it can issue the request through a DHCPv6 297 exchange. 299 We next describe in more detail the interactions foresee for DHCPv6. 301 4.1. Node requests CGA-related configuration parameters to the DHCPv6 302 server 304 A node may initiate a request for the relevant CGA configuration 305 information needed to the DHCPv6 server. The server responds with the 306 configuration information for the node. The server also sends its 307 known certification information for the node. If registration of the 308 resulting address is required, the server can include such 309 requirement in the message sent. If SEND proxies are available, the 310 server informs the node that an MCGA should be generated. The public 311 keys for the routers, along with their certificates, could be 312 included in the response. 314 After receiving the configuration information, the node generates a 315 CGA (or a MCGA) based on its public key and the configuration 316 information. 318 4.2. Node requests to the DHCPv6 server the computation of the Modifier 320 A node may initiate a request for the computation of the Modifier for 321 a certain security configuration to the DHCPv6 server. The node 322 includes the values selected for the CGA associated parameters, such 323 as its public key, the value of the Sec parameter, etc. The server 324 either computes the Modifier value, or redirects the computation to 325 other node using a mechanism that is out of the scope of this draft. 326 Once the server obtains the modifier, it computes the CGA or MCGA 327 according to the process described in RFC 3972, and it responds to 328 the node with the resulting address and the CGA Parameters Data 329 Structure. 331 4.3. Node requests DHCPv6 server to grant the CGA 333 A node requests DHCPv6 server to grant a CGA generated by the node 334 itself, listing the CGA addresses in IA options [RFC3315]. According 335 to whether the CGA matches the CGA-related configuration parameters 336 of the network, the DHCPv6 server sends an acknowledgement to the 337 node, grant the usage of the CGA or indicate the node that it must 338 generate a new CGA with the CGA-related configuration parameters of 339 the network. In the meantime, the DHCPv6 server has had the 340 opportunity to log the address/host combination. 342 4.4. Node sends MCGA-specific information to the DHCPv6 server 344 A node that has generated its MCGA informs the DHCPv6 server about 345 the MCGA and its associated CGA Parameters Data Structure. The DHCPv6 346 server sends an acknowledgement to the node. The server or the node 347 also needs to notify this information to the routers acting as SEND 348 proxies, in a way that is out of the scope of this document. 350 5. Security Considerations 352 5.1. Threat Analysis of the Configuration Requirements 354 5.1.1. Threats faced by the end hosts 356 We first discuss the threats that the clients may face as a result of 357 the operations described in this document. 359 Regarding to the configuration of the Sec parameter, one risk is that 360 a malicious node could propagate a Sec value providing less 361 protection than intended by the network administrator, facilitating a 362 brute force attack against the hash, or the selection of the weakest 363 hash algorithm available for CGA definition. Even in the worst case, 364 if the hash algorithm cannot be inverted, the expected number of 365 iterations required for a brute force attack is O(2^59) in order to 366 find a CGA Parameters Data Structure that matches with a given node. 368 Another risk is the use of a Sec, higher than intended by the 369 administrator, which would require a large number of resources of the 370 client to compute the modifier, requiring a long time until the 371 device can communicate. This can be considered a kind of DOS attack. 372 A variation of this attack is the propagation of different Sec values 373 could force the nodes to generate different addresses, requiring the 374 generation of a new modifier, etc. The end host SHOULD store the 375 addresses that were generated in the past according to different Sec 376 values. 378 The disclosure of the Sec value to any party does not represent any 379 threat. 381 The analysis of the threats for the configuration of CGA Extension 382 Fields should be performed in a case-by-case basis. 384 Regarding to the propagation of MCGA-related information, an attacker 385 could generate a key pair, and propagate the public key to the end 386 host, so the MCGA generated were associated with the public key of 387 the attacker, In this way, the attacker would be able to impersonate 388 the end host for all the protocols for which MCGA were used, such as 389 SEND. Note that the privacy features included in the MCGA design 390 prevents correspondent nodes from realizing that the end host 391 identity has been stolen. 393 In addition, an attacker could propagate different public keys at a 394 high frequency, forcing the end host to generate new MCGAs, resulting 395 if repeated in a DOS attack. 397 The disclosure of the public keys of the proxy(s) or end host(s) used 398 to build the MCGA does not represent any threat. 400 Finally, we consider the delegation of the Modifier computation. The 401 configuration at a given end host of a Modifier not compliant with 402 the Sec requirement could break any identity validation performed at 403 other hosts, and consequently, could prevent any communication. 404 However, this event can be easily detected at the end host by a 405 performing the Hash2 computation and certifying that results in the 406 required number of 0 bits. If it were impossible to obtain a valid 407 Modifier, the end host would be forced to compute by itself the 408 modifier, falling back to the current standard procedure. 410 It is worth to note that the proposed operations do not exchange 411 private keys. An operation requiring such exchange would be the 412 generation of a CGA/MCGA in a different location than the final end 413 host to which it is assigned. The benefits do not outweigh the risks. 414 On one hand, the gain would be small, since a CGA-enabled host is 415 expected to dynamically sign and validate signatures, and the cost of 416 generating a key pair is not much higher. On the other hand, there 417 are significant risks, associated to the fact that the compromise of 418 the node generating the keys results in the compromise of the 419 identities of many other systems, and the need for assuring private 420 communications among the parties involved (possibly requiring 421 cryptographic tools, key distribution, etc.) 423 5.1.2. Threats faced by the configuration servers and proxies 425 In general, the threats that the configuration servers may face are 426 related with DOS. 428 An attacker could generate CGA registration requests in order to 429 exhaust the server resources (or to impact on any other operation 430 that depend on the registration of the CGAs). The considerations for 431 MCGAs are similar, although in this case the impact is extended to 432 proxies. 434 However, the most dangerous attack is bound to malicious requests to 435 compute the Modifier, since the CPU cost for the server can be high, 436 especially considering that the attacker could select a Sec value 437 requiring the highest number of computations for the server. 439 We also consider the threats involved in the delivery of the 440 information used to build a MCGA to a SEND proxy. In this case, an 441 attacker could generate fake information in order to exhaust the 442 resources at the proxy. While computing resources are not compromised, 443 since the only check required at the proxy is that its own certified 444 key is included, the state associated to the proxy operation could be 445 exhausted, or proxy operation slowed down. 447 5.2. Threat Analysis of the Approaches Proposed 449 Now we discuss the security implications of the use of Router 450 Advertisement and DHCPv6 for performing the proposed operations. To 451 analyze the different scenarios regarding to security in which they 452 can be applied, it is worth to note that the use of CGAs and MCGAs is 453 not bound to SEND enabled networks, since they could be used for 454 identity protection in other protocols such as MIPv6 or SHIM6. 455 Therefore, we can consider different scenarios regarding to security: 456 Router Advertisement with SEND support, Router Advertisement without 457 SEND support, and DHCPv6. For Router Advertisement approaches, only 458 parameter propagation and SEND proxy public key distribution are to 459 be considered. 461 5.2.1. Router Advertisement with SEND support 463 Since the integrity of the RA messages and the identity of their 464 sender are protected by the SEND protocol, protection against 465 malicious nodes generating inappropriate values for the Sec parameter 466 or the Extension Fields is provided. The same protection is provided 467 for the distribution of the public keys of the proxies required for 468 MCGA generation. In this case, a trust anchor must have been 469 configured in the client previously to the reception of the RA 470 messages. 472 5.2.2. Router Advertisement without SEND support 474 In this case there is no protection against the generation of 475 different Sec values, so an attacker could force the generation of 476 CGA with the lowest protection allowed by the standard. It could also 477 force the generation of up to 8 CGA addresses in the end host, 478 wasting resources from the end host. Another attack is related with 479 the association of the public key of an attacker to the MCGA of the 480 end host. DOS attacks based on the request of multiple MCGAs could be 481 issued, although in this case a rate limit set in the client could 482 mitigate the impact. 484 However, it should be noted that an attacker being able to generate 485 Router Advertisements could also perform Man-In-The-Middle or DOS 486 attacks, by registering itself as a default router for the subnet. 488 5.2.3. DHCPv6 490 All the configuration operations proposed in this document are 491 initiated by the end host. From the point of view of the end host, 492 the difficulty of generating fake responses that were accepted by the 493 end host with the same transaction-id at the precise time is 494 outstanding. However, attacks can be generated by nodes placed in 495 path between the requesting end host and the DHCPv6 server. In 496 particular, non-SEND enabled subnets are more prone to this type of 497 attacks, although SEND does not provide full protection against MITM 498 attacks. In this case, the Sec parameter could be forced to be the 499 lowest, the node could be forced to compute up to 8 CGA addresses, or 500 to compute MCGAs associated with the attacker. 502 The mechanism based on DHCPv6 is also vulnerable to DOS attacks to 503 the server, such as registration of large number of CGA, or request 504 for Modifier computation. 506 Proper use of DHCPv6 autoconfiguration facilities [RFC3315], such as 507 AUTH option, can prevent these threats, provided that a configuration 508 token is known to both the client and the server. 510 Note that, as expected, it is not possible to provide secure 511 configuration of CGA or MCGA without a previous configuration of 512 security information at the client (either a trust anchor, a DHCPv6 513 configuration token...). However, considering that the values of 514 these elements could be shared by the nodes in the network segment, 515 these security elements can be configured more easily in the end 516 nodes than its addresses. 518 6. IANA Considerations 520 This document defines only the interaction models that involve the 521 Router Advertisement and the DHCPv6 protocol in the CGA generation 522 procedure. The actual DHCPv6 and Router Advertisement extensions are 523 defined in other documents. 525 7. Conclusions 527 This document analyses the requirements for the configuration 528 Cryptographically Generated Addresses (CGA) and Multi-key CGAs. A 529 central administration could configure some parameters such as Sec or 530 Extension Fields to be used by the end hosts in CGA generation. The 531 central administration could notify the availability of CGA proxies, 532 requesting the generation of MCGAs, and propagating the keying 533 material required for MCGAs, and obtaining the end host specific 534 material resulting from this address generation. The computation of 535 the Modifier could also be delegated by an end host to a more 536 appropriate system. 538 The tools discussed for this performing these interactions are Router 539 Advertisement and the DHCPv6 protocol. 541 8. Acknowledgments 543 The authors would like to thank Marcelo Bagnulo Braun for been 544 involved in the early requirement identification. 546 9. References 548 9.1. Normative References 550 [RFC3315] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6", 551 RFC3315, July 2003. 553 [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor 554 Discovery (SEND) ", RFC 3971, March 2005. 556 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 557 March 2005. 559 [RFC4982] M. Bagnulo, "Support for Multiple Hash Algorithms in 560 Cryptographically Generated Addresses (CGAs) ", RFC4982, 561 July 2007. 563 [MCGA] J. Kempf, "Secure IPv6 Address Proxying using Multi-Key 564 Cryptographically Generated Address", draft-kempf-cgaext- 565 ringsig-ndproxy-02 (work in progress), August 2007. 567 [RIID] S. Krishnan, "Reserved IPv6 Interface Identifiers", draft- 568 ietf-6man-reserved-iids-00.txt (work in progress), February 569 2008. 571 9.2. Informative References 573 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 574 Requirement Levels", RFC2119, March 1997. 576 [RFC4866] J. Arkko, C. Vogt, W. Haddad, "Enhanced Route Optimization 577 for Mobile IPv6", RFC4866, May 2007. 579 [SHIM6-proto] E. Nordmark, M. Bagnulo, "Shim6: Level 3 Multihoming 580 Shim Protocol for IPv6", draft-ietf-shim6-proto-10.txt 581 (work in progress), February 2008. 583 Author's Addresses 585 Sheng Jiang 586 Huawei Technologies Co., Ltd 587 QuiKe Building, No.9 Xinxi Rd., 588 Shang-Di Information Industry Base, 589 Hai-Dian District, Beijing, P.R. China 590 100085 591 Phone: 86-10-82836774 592 Email: shengjiang@huawei.com 594 Sam (Zhongqi) Xia 595 Huawei Technologies Co., Ltd 596 QuiKe Building, No.9 Xinxi Rd., 597 Shang-Di Information Industry Base, 598 Hai-Dian District, Beijing, P.R. China 599 100085 600 Phone: 86-10-82836864 601 Email: xiazhongqi@huawei.com 603 Alberto Garcia-Martinez 604 Universidad Carlos III de Madrid 605 Av. Universidad 30 606 Leganes, Madrid 28911 607 SPAIN 608 Phone: 34-91-6249500 609 Email: alberto@it.uc3m.es 611 Intellectual Property Statement 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; nor does it represent that it has 618 made any independent effort to identify any such rights. Information 619 on the procedures with respect to rights in RFC documents can be 620 found in BCP 78 and BCP 79. 622 Copies of IPR disclosures made to the IETF Secretariat and any 623 assurances of licenses to be made available, or the result of an 624 attempt made to obtain a general license or permission for the use of 625 such proprietary rights by implementers or users of this 626 specification can be obtained from the IETF on-line IPR repository at 627 http://www.ietf.org/ipr. 629 The IETF invites any interested party to bring to its attention any 630 copyrights, patents or patent applications, or other proprietary 631 rights that may cover technology that may be required to implement 632 this standard. Please address the information to the IETF at 633 ietf-ipr@ietf.org. 635 Disclaimer of Validity 637 This document and the information contained herein are provided on an 638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 640 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 641 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 642 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Copyright Statement 647 Copyright (C) The IETF Trust (2008). 649 This document is subject to the rights, licenses and restrictions 650 contained in BCP 78, and except as set forth therein, the authors 651 retain all their rights.