idnits 2.17.1 draft-krishnan-csi-proxy-send-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. 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 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 (June 6, 2008) is 5765 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) == Outdated reference: A later version (-03) exists of draft-krishnan-cgaext-send-cert-eku-00 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4389 -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Laganier 5 Expires: December 8, 2008 DoCoMo Euro-Labs 6 M. Bonola 7 Rome Tor Vergata University 8 June 6, 2008 10 Secure Proxy ND Support for SEND 11 draft-krishnan-csi-proxy-send-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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 December 8, 2008. 38 Abstract 40 Secure Neighbor Discovery (SEND) specifies a method for securing 41 Neighbor Discovery (ND) signaling against specific threats. As 42 specified today, SEND assumes that the node advertising an address is 43 the owner of the address and is in possession of the private key used 44 to generate the digital signature on the message. This means that 45 the Proxy ND signaling initiated by nodes that do not possess 46 knowledge of the address owner's private key cannot be secured using 47 SEND. This document extends the current SEND specification with 48 support for Proxy ND, the Secure Proxy ND Support for SEND. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Scenario 1: RFC 4389 Neighbor Discovery Proxy . . . . . . 6 57 4.2. Scenario 2: Mobile IPv6 . . . . . . . . . . . . . . . . . 7 58 4.3. Scenario 3: Proxy Mobile IPv6 . . . . . . . . . . . . . . 9 59 5. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 11 60 6. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 13 61 6.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 13 62 6.2. Modified SEND processing rules . . . . . . . . . . . . . . 15 63 6.2.1. Processing rules for senders . . . . . . . . . . . . . 15 64 6.2.2. Processing rules for receivers . . . . . . . . . . . . 16 65 7. Backward Compatibility with legacy SEND nodes . . . . . . . . 17 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 68 10. Normative References . . . . . . . . . . . . . . . . . . . . . 20 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 70 Intellectual Property and Copyright Statements . . . . . . . . . . 22 72 1. Requirements notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Introduction 80 Secure Neighbor Discovery [RFC3971] specifies a method for securing 81 neighbor discovery signaling [RFC4861] against specific threats. As 82 specified today, SEND assumes that the node advertising an address is 83 the owner of the address and is in possession of the private key used 84 to generate the digital signature on the message. This means that 85 the Proxy ND signaling initiated by nodes that do not possess 86 knowledge of the address owner's private key cannot be secured using 87 SEND. 89 This document extends the current SEND specification with support for 90 Proxy ND. From this point on we refer to such extension as "Secure 91 Proxy ND Support for SEND". 93 3. Terminology 95 Secure Proxy ND 97 A node authorized to either modify or generate a SEND message 98 without knowing the private key related to the source address of 99 the ICMPv6 ND message. 101 Proxied IPv6 address 103 An IPv6 address that doesn't belong to the Secure Proxy ND and for 104 which the Secure Proxy ND is advertising. 106 4. Application Scenarios 108 In this section we provide three different application scenarios for 109 which the ICMPv6 Neighbor Discovery signaling cannot be secured by 110 using the current SEND specification. 112 Either of the entities described in the following three scenarios, 113 (i.e.: ND Proxy, MIPv6 Home Agent, PMIPv6 Mobile Access Gateway) can 114 be consider as a Secure Proxy ND. 116 4.1. Scenario 1: RFC 4389 Neighbor Discovery Proxy 118 Link 1 Link 2 120 Host A ND Proxy (P) Host B 121 | | | 122 | SRC = A | | 123 | DST = solicited_node(B) | | 124 | ICMPv6 NS | | 125 | TARGET = B | | 126 | SLLAO = B_LL | | 127 |------------------------->| | 128 | | SRC = A | 129 | | DST = solicited_node(B) | 130 | | ICMPv6 NS | 131 | | TARGET = B | 132 | | SLLAO = P_LL | 133 | |------------------------->| 134 | | | 135 | | SRC = B | 136 | | DST = A | 137 | | ICMPv6 NA | 138 | | TARGET = B | 139 | | TLLAO = B_LL | 140 | |<-------------------------| 141 | SRC = B | | 142 | DST = A | | 143 | ICMPv6 NA | | 144 | TARGET = B | | 145 | TLLAO = B_LL | | 146 |<-------------------------| | 147 | | | 149 Figure 1: Proxy ND operations 151 The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a 152 method by which multiple link layer segments are bridged into a 153 single segment and specifies the IP-layer support that enables 154 bridging under these circumstances. 156 A ND Proxy shall parse any IPv6 packet it receives on a proxy 157 interface to check whether it contains one of the following ICMPv6 158 messages: Neighbor Solicitation (NS), Neighbor Advertisement (NA), 159 Router Advertisement, or Redirect. Since each of these messages 160 contains a link-layer address which might not be valid on another 161 segment, the ND Proxy proxies these packets as follows, and as 162 illustrated in Figure 1: 164 1. The source link layer address will be the address of the outgoing 165 interface. 167 2. The destination link layer address will be the address in the 168 neighbor entry corresponding to the destination IPv6 address. 170 3. A link layer address within the payload (that is, in a Source 171 Local Link Address option - SLLAO, or a Target Local Link Address 172 option - TLLAO) is substituted with the link-layer address of the 173 outgoing interface. 175 Moreover, when any other IPv6 unicast packet is received on a proxy 176 interface, if it is not locally destined then it is forwarded 177 unchanged (other than using a new link-layer header) to the proxy 178 interface for which the next hop address appears in the neighbor 179 cache. If no neighbor cache entry is present, the ND proxy should 180 queue the packet and initiate a Neighbor Discovery signalling as if 181 the ICMPv6 NS message were locally generated. 183 A ND proxy cannot protect proxied ND messages since protection of an 184 ND message as per the current SEND specification requires knowledge 185 of the private key of each node for which it is generating or 186 forwarding a ND message on the bridged link layer segments. 188 4.2. Scenario 2: Mobile IPv6 190 The Mobile IPv6 protocol [RFC3775] allows a mobile node (MN) to move 191 from one link to another while maintaining reachability at a stable 192 address, the so-called MN's home address (HoA.) When a mobile node 193 attaches to a foreign network, all the packets sent to the MN's HoA 194 and forwarded on the home link by a correspondent node (CN) or a 195 router are intercepted by the home agent (HA) on that home link, 196 encapsulated and tunneled to the mobile node's registered care-of 197 address (CoA.) 198 The HA intercepts these packets by being a Neighbor Discovery proxy 199 for this MN. When a Neighbor Solicitation (NS) is intercepted on the 200 home link, the home agent checks if the Target address within the NS 201 matches with any of the MN's Home Address in the Binding Cache and if 202 so, it replies with a Neighbor Advertisement (NA) containing its own 203 link layer address (HA_LL) as the Target Link Layer Address Option 204 (TLLAO), as illustrated in Figure 2. 206 Node (N) Home Agent (HA) Mobile Node (MN) 207 on Home Link on Home Link on Foreign Link 208 | | | 209 | SRC = N | | 210 | DST = solicited_node(MN) | | 211 | ICMPv6 NS | | 212 | TARGET = MN | | 213 | SLLAO = N_LL | | 214 |------------------------->| | 215 | | | 216 | SRC = MN | | 217 | DST = N | | 218 | ICMPv6 NA | | 219 | TARGET = MN | | 220 | TLLAO = HA_LL | | 221 |<-------------------------| | 222 | | | 223 | traffic | | 224 | dest= MN HoA | | 225 |------------------------->| | 226 | | | 227 | | tunnelled traffic | 228 | | dest= MN CoA | 229 | |------------------------->| 230 | | | 232 Figure 2: Proxy ND role of the Home agent in MIPv6 234 It is not possible to apply the current SEND specification to protect 235 the NA message issued by the HA. To generate an ICMPv6 NA with a 236 valid CGA option and the corresponding RSA Signature option, the HA 237 needs knowledge of the private key related to the MN's 238 Cryptographically Generated Address (CGA.) Any ICMPv6 NA without a 239 valid CGA and RSA signature option is to be treated as insecure by a 240 SEND receiver. 242 4.3. Scenario 3: Proxy Mobile IPv6 244 MN new MAG LMA 245 | | | 246 MN Attached | | 247 | | | 248 | MN Attached Event from MN/Network | 249 | | | 250 |--- ICMPv6 RS ------->| | 251 | | | 252 | |--- PBU ------------->| 253 | | | 254 | | Accept PBU 255 | | | 256 | |<------------- PBA ---| 257 | | | 258 | Accept PBA | 259 | | | 260 | |==== Bi-Dir Tunnel ===| 261 | | | 262 |<------ ICMPv6 RA ----| | 263 | | | 264 | | | 265 | | | 267 Figure 3: Mobile node's handover in PMIPv6 269 Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based 270 mobility management protocol that provides an IP mobility management 271 support for MNs without requiring MNs being involved in the mobility 272 related signaling. The IP mobility management is totally hidden to 273 the MN in a Proxy Mobile IPv6 domain and is performed by two 274 functional entities: the Local Mobility Anchor (LMA) and the Mobile 275 Access Gateway (MAG.) 277 When the MN connects to a new access link it will send a multicast 278 ICMPv6 Router Solicitation (RS.) The MAG on the new access link, 279 upon detecting the MN's attachment, will signal the LMA for updating 280 the binding state of the MN (Proxy Binding Update - PBU) and once the 281 signaling is complete (Proxy Binding Ack - PBA - received), it will 282 reply to the MN with a ICMPv6 Router Advertisement (RA) containing 283 its home network prefix(es) that were assigned to that mobility 284 session, making the MN believe it is still on the same link and not 285 triggering the IPv6 address reconfiguration (figure Figure 3.) 286 To avoid potential link-local address collisions between the MAG and 287 the MN after a handoff to a new link, the Proxy Mobile IPv6 288 specification requires the MAG's link-local address configured on the 289 link to which the MN is attached to be generated once by the LMA when 290 the MN first attach to a PMIPv6 domain, and to be provided to the new 291 MN's serving MAG after each handoff. Thus, from the MN's point of 292 view, the MAG's link-local address remains constant for the duration 293 of that MN's session. 295 The approach described above and the current SEND specification are 296 incompatible since: 298 Sharing the same link-local address on different MAGs would 299 require all MAGs of a PMIPv6 domain to construct the CGA and the 300 RSA Signature option with the same public-private key pair, which 301 is not acceptable from a security point of view. 303 Using different public-private key pairs on different MAGs would 304 mean different MAGs use different CGAs as link-local address. 305 Thus the serving MAG's link-local address changes after each 306 handoff of the MN which is contradiction with the way MAG link- 307 local address assignment occurs in a PMIPv6 domain. 309 5. Secure Proxy ND Overview 311 The original SEND specification [RFC3971] has implicitly assumed that 312 the owner of the address was the one who was advertising the prefix. 313 This assumption does not allow proxying of a CGA based address as the 314 receiver requires the advertiser to generate a valid CGA and RSA 315 Signature option, which in turns requires possession of the public- 316 private key pair that was used to generate the CGA. 318 This specification explicitly separates the roles of ownership and 319 advertiser by extending the SEND protocol as follows: 321 o A certificate authorizing an entity to act as an ND proxy is 322 introduced. This is achieved via specifying explicitly in the 323 X509v3 certificate the purpose for which the certificate is 324 issued, as described in a companion document 325 [I-D.krishnan-cgaext-send-cert-eku]. Briefly, two KeyPurposeID 326 values are defined: one for authorizing routers, and one for 327 authorizing proxies. The inclusion of the proxy authorization 328 value allows the certificate owner to perform proxying of SEND 329 messages for a set of prefixes indicated in the same certificate. 331 o A new option called Proxy Signature option (PSO) is defined. This 332 option contains the key hash value of the Secure Proxy ND's public 333 key and the digital signature computed over the SEND message. The 334 key has value is computed over the public key within the Secure 335 Proxy ND's certificate. 337 o The SEND processing rules are modified for all Neighbor Discovery 338 messages: NA, NS, RS, RA, and Redirect. When any of these 339 messages is received with a valid Proxy Signature option, it is 340 considered as secure even if it doesn't contain a CGA option. 342 The Secure Proxy ND becomes part of the trusted infrastructure just 343 like a SEND router. The Secure Proxy ND is granted a certificate 344 that specifies the range of addresses for which it is allowed to 345 perform proxying of SEND messages. Hosts can use the same process to 346 discover the certification path between a proxy and one of the host's 347 trust anchors as the one defined for routers in Section 6 of SEND 348 specification [RFC3971]. 350 The proposed approach resolves the incompatibilities between the 351 current SEND specification and the application scenarios described in 352 Section 4. Since SEND messages containing a Proxy Signature option 353 are not required to carry a CGA option, the IPv6 source address is no 354 longer cryptographically bound to the signature, and the sender of a 355 Neighbor Discovery message is not required to be the owner of the 356 claimed address. Thus, the Secure Proxy ND is able to either forward 357 and generate SEND messages for a proxied address within the set of 358 prefixes for which it is authorized. 360 6. Secure Proxy ND Specification 362 A Secure ND Proxy performs all the operation described in the SEND 363 specification [RFC3971] with the addition of new processing rules to 364 ensure that the receiving node can differentiate between an 365 authorized proxy generating or forwarding a SEND message for a 366 proxied address, and a malicious node doing the same. 368 This is accomplished by signing the message with the public key of 369 the authorized Secure Proxy ND. The signature of the neighbor 370 discovery proxy is included in a new option called Proxy Signature 371 option (PSO.) The signature is performed over all the NDP options 372 present in the message and the PSO is appended as the last option in 373 the message. 375 6.1. Proxy Signature Option 377 The Proxy Signature option allows public key-based signatures to be 378 attached to NDP messages. The format of the PSO is described in the 379 following diagram: 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type | Length | Reserved | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 | Key Hash | 388 | | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 . . 393 . Digital Signature . 394 . . 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 . . 399 . Padding . 400 . . 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 4: PSO layout 406 Type 408 TBA 410 Length 412 The length of the option (including the Type, Length, Reserved, 413 Key Hash, Digital Signature, and Padding fields) in units of 8 414 octets. 416 Reserved 418 A 16-bit field reserved for future use. The value MUST be 419 initialized to zero by the sender, and MUST be ignored by the 420 receiver. 422 Key Hash 424 A 128-bit field containing the most significant (leftmost) 128 425 bits of a SHA-1 [SHA1] hash of the public key used for 426 constructing the signature. Its purpose is to associate the 427 signature to a particular key known by the receiver. Such a key 428 MUST be the same one within the Secure Proxy ND's certificate. 430 Digital Signature 432 A variable-length field containing a PKCS#1 v1.5 signature, 433 constructed by using the sender's private key over the following 434 sequence of octets: 436 1. The 128-bit CGA Message Type tag [RFC3972] value for Secure 437 Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (The tag 438 value has been generated randomly by the editor of this 439 specification.) 441 2. The 128-bit Source Address field from the IP header. 443 3. The 128-bit Destination Address field from the IP header. 445 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from 446 the ICMP header. 448 5. The NDP message header, starting from the octet after the ICMP 449 Checksum field and continuing up to but not including NDP 450 options. 452 6. All NDP options preceding the Proxy Signature option. 454 The signature value is computed with the RSASSA-PKCS1-v1_5 455 algorithm and SHA-1 hash, as defined in [RSA]. 457 This field starts after the Key Hash field. The length of the 458 Digital Signature field is determined by the length of the RSA 459 Signature option minus the length of the other fields (including 460 the variable length Pad field.) 462 Padding 464 This variable-length field contains padding, as many bytes long as 465 remain after the end of the signature. 467 6.2. Modified SEND processing rules 469 The modifications described in the following section applies when a 470 SEND message contains the Proxy Signature option (PSO), i.e. the 471 message was sent by a Secure Proxy ND. 473 This specification modifies the sender and receiver processing rules 474 for the following options defined in the SEND specification 475 [RFC3971]: CGA option, RSA option. 477 6.2.1. Processing rules for senders 479 A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST 480 contain a Proxy Signature option (PSO) and MUST NOT contain CGA and 481 RSA Signature options. 483 A Secure Proxy ND sending a SEND message with the PSO Signature 484 option MUST construct the message as follows: 486 1. The SEND message is constructed without the PSO as follow: 488 A. If the Secure Proxy ND is locally generating the SEND message 489 for a proxied address, the message is constructed as 490 described in Neighbor Discovery for IP version 6 491 specification [RFC4861]. 493 B. If the Secure Proxy ND is forwarding a SEND message, first 494 the authenticity of the intercepted message is verified as 495 specified in SEND specification [RFC3971] Section 5. If the 496 SEND message is valid, any CGA or RSA option MUST be removed 497 from the message. The intercepted message is finally 498 modified as described in Section 4 of the ND Proxy 499 specification [RFC4389]. 501 2. The Proxy Signature option is added as the last option in the 502 message. 504 3. The data is signed as explained in Section 6.1. 506 6.2.2. Processing rules for receivers 508 Any SEND message without a Proxy Signature option MUST be treated as 509 specified in the SEND specification [RFC3971]. 511 A SEND message including a Proxy Signature option MUST be processed 512 as specified below: 514 1. The receiver MUST ignore any RSA and CGA options, as well as any 515 options that might come after the first PSO. The options are 516 ignored for both signature verification and NDP processing 517 purposes. 519 2. The Key Hash field MUST indicate the use of a known public key. 520 A valid certification path (see [RFC3971] Section 6.3) between 521 the receiver's trust anchor and the sender's public key MUST be 522 known. The Secure Proxy ND's X509v3 certificate MUST contain a 523 extended key usage extension including the KeyPurposeId value for 524 the proxy authorization. 526 3. The Digital Signature field MUST have correct encoding and MUST 527 NOT exceed the length of the Proxy Signature option minus the 528 Padding. 530 4. The Digital Signature verification MUST show that the signature 531 has been calculated as specified in Section 6.1. 533 Messages that do not pass all the above tests MUST be silently 534 discarded if the host has been configured to accept only secured ND 535 messages. 537 7. Backward Compatibility with legacy SEND nodes 539 The PSO added by a Secure Proxy ND will be ignored by nodes 540 implementing the original SEND specification and hence will not cause 541 any interoperability problems. Since the Secure Proxy ND also 542 removes the original RSA option, these messages will be treated as 543 "unsecured" message as described in Section 8 "Transitions Issues" of 544 the SEND specification [RFC3971]. Thus, this specification does not 545 introduce any new transition issue compared to the original SEND 546 specification. 548 8. Security Considerations 550 The mechanism described in this document introduce a new Proxy 551 Signature Option (PSO) allowing a Secure Proxy ND to generate or 552 modify a SEND message for a proxied address. A node will only accept 553 such a message if it includes a valid PSO generated by an authorized 554 Secure Proxy ND. 556 If, on the other hand, a message does not include a PSO, then the 557 Secure Proxy ND support doens't introduce any further security issues 558 since this specification does not modify the SEND processing rules if 559 an ICMPv6 ND message does not contain a PSO. Thus, the same security 560 considerations than that of SEND applies (cf. Section 9 of the SEND 561 specification [RFC3971].) 563 9. IANA Considerations 565 IANA is requested to allocate: 567 A new IPv6 Neighbor Discovery Option types for the PSO, as TBA. 568 The value need to be allocated from the namespace specified in the 569 IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at 570 http://www.iana.org/assignments/icmpv6-parameters. 572 A new 128-bit value under the CGA Message Type [RFC3972] 573 namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. 575 10. Normative References 577 [I-D.ietf-netlmm-proxymip6] 578 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 579 and B. Patil, "Proxy Mobile IPv6", 580 draft-ietf-netlmm-proxymip6-18 (work in progress), 581 May 2008. 583 [I-D.krishnan-cgaext-send-cert-eku] 584 Krishnan, S., "Authorization Certificates for Routers and 585 Proxies", draft-krishnan-cgaext-send-cert-eku-00 (work in 586 progress), November 2007. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, March 1997. 591 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 592 in IPv6", RFC 3775, June 2004. 594 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 595 Neighbor Discovery (SEND)", RFC 3971, March 2005. 597 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 598 RFC 3972, March 2005. 600 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 601 Proxies (ND Proxy)", RFC 4389, April 2006. 603 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 604 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 605 September 2007. 607 [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", 608 PKCS 1 , November 2002. 610 [SHA1] National Institute of Standards and Technology, "Secure 611 Hash Standard", FIPS PUB 180-1 , April 1995. 613 Authors' Addresses 615 Suresh Krishnan 616 Ericsson 617 8400 Decarie Blvd. 618 Town of Mount Royal, QC 619 Canada 621 Phone: +1 514 345 7900 x42871 622 Email: suresh.krishnan@ericsson.com 624 Julien Laganier 625 DoCoMo Communications Laboratories Europe GmbH 626 Landsberger Strasse 312 627 Munich D-80687 628 Germany 630 Phone: +49 89 56824 231 631 Email: julien.ietf@laposte.net 632 URI: http://www.docomolab-euro.com/ 634 Marco Bonola 635 Rome Tor Vergata University 636 Via del Politecnico, 1 637 Rome I-00133 638 Italy 640 Phone: 641 Email: marco.bonola@gmail.com 643 Full Copyright Statement 645 Copyright (C) The IETF Trust (2008). 647 This document is subject to the rights, licenses and restrictions 648 contained in BCP 78, and except as set forth therein, the authors 649 retain all their rights. 651 This document and the information contained herein are provided on an 652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 654 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 655 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 656 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Intellectual Property 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; nor does it represent that it has 666 made any independent effort to identify any such rights. Information 667 on the procedures with respect to rights in RFC documents can be 668 found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use of 673 such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository at 675 http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at 681 ietf-ipr@ietf.org.