idnits 2.17.1 draft-ietf-netlmm-grekey-option-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 668. 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 21, 2008) is 5632 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 (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-05 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Muhanna 3 Internet-Draft M. Khalil 4 Intended status: Standards Track Nortel 5 Expires: May 25, 2009 S. Gundavelli 6 K. Leung 7 Cisco Systems 8 November 21, 2008 10 GRE Key Option for Proxy Mobile IPv6 11 draft-ietf-netlmm-grekey-option-02.txt 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 May 25, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document defines a new Mobility Option for allowing the mobile 45 access gateway and the local mobility anchor to negotiate GRE 46 encapsulation mode and exchange the downlink and uplink GRE keys 47 which are used for marking the downlink and uplink traffic that 48 belong to a specific mobile node session or a specific flow. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 54 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4 57 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4 58 3.2. GRE Encapsulation Support . . . . . . . . . . . . . . . . 6 59 3.3. GRE Key Exchange Mechanism . . . . . . . . . . . . . . . . 6 60 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6 61 3.3.2. GRE Key Exchange During Binding Re-registration . . . 6 62 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 7 63 4.1. Extensions to the Conceptual Data Structure . . . . . . . 7 64 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 8 65 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 9 66 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 9 67 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 10 68 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 11 70 6.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . . . 16 78 1. Introduction 80 The base Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile 81 IPv6 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 82 encapsulation modes [RFC2473] , [RFC2003] for the tunneled traffic 83 between the local mobility anchor and the mobile access gateway. 84 There are scenarios where these encapsulation modes are not 85 sufficient to uniquely identify the destination of packets of a 86 specific flow. Thus, there is a need for an encapsulation mode with 87 richer semantics. The Generic Routing Encapsulation [RFC2784] and 88 the Key extension as defined in [RFC2890], has the required semantics 89 to allow such distinction for use in Proxy Mobile IPv6. 91 This document defines the GRE Key option to be used for the 92 negotiation of GRE encapsulation mode and the exchange of the uplink 93 and downlink GRE keys. The negotiated downlink and uplink GRE keys 94 can be used for marking the downlink and uplink traffic for a 95 specific mobile node session or a specific flow. 97 2. Conventions & Terminology 99 2.1. Conventions 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 RFC 2119 [RFC2119]. 105 2.2. Terminology 107 All the general mobility related terminology and abbreviations are to 108 be interpreted as defined in Mobile IPv6 specification [RFC3775] and 109 Proxy Mobile IPv6 specification [RFC5213]. The following terms are 110 used in this document. 112 Downlink Traffic 114 The traffic in the tunnel between the local mobility anchor and 115 the mobile access gateway, heading towards the mobile access 116 gateway and tunneled at the local mobility anchor. This traffic 117 is also called forward direction traffic. 119 Uplink Traffic 121 The traffic in the tunnel between the mobile access gateway and 122 the local mobility anchor, heading towards the local mobility 123 anchor and tunneled at the mobile access gateway. This traffic is 124 also called reverse direction traffic. 126 Downlink GRE Key 128 The GRE key is assigned by the mobile access gateway and used by 129 the local mobility anchor to mark the downlink traffic which 130 belongs to a specific mobile node session or flow as described in 131 this document. 133 Uplink GRE Key 135 The GRE key is assigned by the local mobility anchor and used by 136 the mobile access gateway to mark the uplink traffic which belongs 137 to a specific mobile node session or flow as described in this 138 document. 140 3. GRE Encapsulation and Key Exchange 142 3.1. GRE Encapsulation Overview 144 Using the GRE Key option defined in this specification, the mobile 145 access gateway and the local mobility anchor can negotiate GRE 146 encapsulation mode and exchange the GRE keys for marking the downlink 147 and uplink traffic. 149 Once the GRE keys have been exchanged between the mobile access 150 gateway and the local mobility anchor, the mobile access gateway will 151 use the uplink GRE key that is assigned by the local mobility anchor 152 in the GRE encapsulation header of the uplink payload packet. 153 Similarly, the local mobility anchor will use the downlink GRE key as 154 negotiated with the mobile access gateway in the GRE encapsulation 155 header of the downlink payload packet. 157 The following illustration explains the use of GRE encapsulation mode 158 and the GRE keys for supporting the usecase where overlapping IPv4 159 private address [RFC1918] allocation is in use. 161 +------------+ 162 | Operator-A | 163 | | 164 | 10.x.0.0/16| 165 +------------+ 166 / 167 +------+ +------+ / 168 | | ========================== | | / 169 MN-1---| | / \ | | / Key-1 170 | M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic 171 MN-2---| A |--| |--| M |- 172 | G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2 173 MN-3---| | \ / | | \Traffic 174 | | ========================== | | \ 175 MN-4---| | Proxy Mobile IPv6 Tunnel | | \ 176 +------+ +------+ \ 177 \ 178 Operator-C: Access Network +------------+ 179 | Operator-B | 180 | | 181 | 10.x.0.0/16| 182 +------------+ 184 Figure 1: Overlapping IPv4 Private Address Space 186 Figure 1 illustrates a local mobility anchor providing mobility 187 service to mobile nodes that are from different operators and are 188 assigned IPv4 addresses from overlapping private address space. In 189 this scenario, the mobile access gateway and the local mobility 190 anchor must be able distinguish the flows belonging to a given 191 operator from the flows belonging to some other operator. 193 The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and 194 mobile nodes, MN-3 and MN-4 are visiting from Operator-B. The mobile 195 access gateway and the local mobility anchor exchange a specific pair 196 of downlink and uplink GRE keys and save them as part of the mobile 197 node binding to be used for identifying the flows belonging to each 198 mobile node. 200 The LMA and the MAG will be able to distinguish each mobile node 201 flow(s) based on the GRE key present in the GRE header of the 202 tunneled packet, and route them accordingly. 204 3.2. GRE Encapsulation Support 206 To request GRE encapsulation support without exchanging the GRE keys, 207 the mobile access gateway MUST include the GRE Key option in the 208 Proxy Binding Update message sent to the local mobility anchor. The 209 mobile access gateway MUST set the length field of the GRE Key option 210 to 2 octets. 212 If the local mobility anchor supports GRE encapsulation and after 213 successfully processes the Proxy Binding Update, the LMA sends a 214 Proxy Binding Acknowledgement and MUST include the GRE Key option 215 with the length field set to 2 octets. 217 3.3. GRE Key Exchange Mechanism 219 The following subsections describe how the mobile access gateway and 220 the local mobility anchor exchange downlink and uplink GRE keys using 221 proxy mobile IPv6 registration procedure. 223 3.3.1. Initial GRE Key Exchange 225 When the mobile access gateway determines, based on, e.g., private 226 IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA 227 peer agreement, that GRE encapsulation is needed and GRE keys is 228 required, the mobile access gateway MUST include the GRE Key option 229 in the initial Proxy Binding Update message sent to the local 230 mobility anchor. The mobile access gateway MUST include the downlink 231 GRE key in the GRE Key Identifier field of the GRE Key option. 233 After successfully processes the initial Proxy Binding Update and 234 accepting the downlink GRE key, the LMA MUST include the GRE Key 235 option with the uplink GRE key in the GRE Key Identifier field when 236 sending a successful Proxy Binding Acknowledgement to the MAG. 238 3.3.2. GRE Key Exchange During Binding Re-registration 240 If the MAG has successfully negotiated and exchanged the initial GRE 241 keys with the LMA for a specific binding, the MAG SHOULD NOT include 242 the GRE Key option with the downlink GRE key in the Proxy Binding 243 Update which is used for requesting a Binding Lifetime Extension. 245 However, during inter-MAG handoff and if the new mobile access 246 gateway determines, based on, e.g., private IPv4 address support, the 247 MAG local policy, the MAG-LMA peer agreement, or an indication during 248 the handoff process, that GRE encapsulation and GRE key exchange is 249 required, the new mobile access gateway MUST include the GRE key 250 option with the downlink GRE key in the Proxy Binding Update which is 251 used for requesting an after handoff Binding Lifetime extension. In 252 this case, the new MAG may either pick a new downlink GRE key or use 253 the downlink GRE key that was used by the previous MAG for the same 254 binding. For the new MAG to know the downlink GRE key used by the 255 previous MAG, it may require transfer of context from the previous 256 MAG to the new MAG during a handover. Such mechanisms are out-of- 257 scope for this document. 259 If the LMA successfully processes a handoff-triggered Binding 260 Lifetime Extension Proxy Binding Update message which contains a GRE 261 key option with a downlink GRE key included, the LMA MUST return the 262 same uplink GRE key that was exchanged with the previous MAG and is 263 saved in the respected BCE. 265 If the LMA receives handoff-triggered Binding Lifetime Extension 266 Proxy Binding Update message without the GRE key option for a BCE 267 that is using GRE keys and GRE encapsulation, the LMA MUST reject the 268 Proxy Binding Update by sending a Proxy Binding Acknowledgement 269 message with the status field is set to as 270 defined in Section 6.2. 272 If the LMA receives a no handoff Binding Lifetime extension Proxy 273 Binding Update message with the GRE key option and the downlink GRE 274 key included from the same MAG that is currently hosting the 275 respected binding current pCoA, the LMA MUST NOT reject the Proxy 276 Binding Update because of the GRE key option being included in a 277 binding reregistration Proxy Binding Update message. In this case, 278 the LMA processes the Proxy Binding Update normally and if the 279 included downlink GRE key is different than the one saved in the 280 respected BCE, the LMA MUST update the BCE with the new downlink GRE 281 key. 283 4. Mobile Access Gateway Considerations 285 4.1. Extensions to the Conceptual Data Structure 287 Every mobile access gateway maintains a Binding Update List entry for 288 each currently attached mobile node, as explained in Section 6.1 of 289 the Proxy Mobile IPv6 specification [RFC5213]. To support this 290 specification, the conceptual Binding Update List entry data 291 structure must be extended with the following three new additional 292 fields. 294 o A flag indicating whether GRE encapsulation is enabled for the 295 mobile node's traffic flows. 297 o The Downlink GRE Key used in the GRE encapsulation header of the 298 tunneled packet from the local mobility anchor to the mobile 299 access gateway that is destined to the mobile node. This GRE Key 300 is generated by the MAG and communicated to the LMA in the GRE Key 301 option in the Proxy Binding Update message. 303 o The Uplink GRE Key used in the GRE encapsulation header of the 304 tunneled packet from the mobile access gateway to the local 305 mobility anchor that is originating from the mobile node. This 306 GRE Key is obtained from the GRE Key Identifier field of the GRE 307 Key option present in the received Proxy Binding Acknowledgement 308 message sent by the LMA as specified in this document. 310 4.2. Operational Summary 312 o If the MAG determines that GRE encapsulation and GRE key is 313 required, the MAG MUST include the GRE Key option with the 314 downlink GRE key in the GRE Key Identifier field in the Proxy 315 Binding Update message that is sent by the mobile access gateway 316 to the local mobility anchor. 318 o After receiving a successful Proxy Binding Acknowledgment message 319 with the GRE Key option which includes the uplink GRE key, the 320 mobile access gateway MUST update the related three fields in the 321 mobile node Binding Update List entry described in Section 4.1. 322 Additionally, the MAG MUST use the assigned uplink GRE Key for 323 tunneling all the traffic originating from the mobile node before 324 forwarding the tunneled traffic to the LMA. 326 o If the mobile access gateway included the GRE Key option in the 327 Proxy Binding Update for a specific mobile node and the local 328 mobility anchor accepts the Proxy Binding Update by sending a 329 Proxy Binding Acknowledgement with a success status code (less 330 than 128) other than , but without 331 the GRE Key option, then the mobile access gateway MUST consider 332 that the local mobility anchor does not support GRE Key option as 333 per this specification. The mobile access gateway SHOULD NOT 334 include the GRE Key option in any subsequent Proxy Binding Update 335 message that is sent to that LMA. 337 o If the mobile access gateway sent a Proxy Binding Update message 338 without the GRE Key option, but the received Proxy Binding 339 Acknowledgement has the Status Code , 340 indicating that the GRE encapsulation and GRE key is required, the 341 mobile access gateway SHOULD resend the Proxy Binding Update 342 message with the GRE Key option. If the MAG does not support the 343 GRE Key option, the MAG MAY log the event and possibly raise an 344 alarm to indicate a possible misconfiguration. 346 o If the mobile access gateway sent a Proxy Binding Update message 347 with the GRE Key option and the downlink GRE key included and 348 received a successful Proxy Binding Acknowledgement message with a 349 status code , the mobile access 350 gateway MUST consider that GRE encapsulation and GRE keys is not 351 required for this specific binding. The MAG follows the Proxy 352 Mobile IPv6 specification [RFC5213] for the handling of uplink and 353 downlink traffic for this mobile node binding and MUST NOT include 354 the GRE Key option in any subsequent Proxy Binding Update message 355 for this specific mobile node that are sent to that LMA. 357 o If the MAG sent a re-registration Proxy Binding Update message 358 without the GRE Key option, but received a successful Proxy 359 Binding Acknowledgement which includes the GRE Key option with the 360 uplink GRE key, the MAG MUST compare the received uplink GRE key 361 with the one saved in the respected Binding Update List entry and 362 update it if the received uplink GRE key is different. 364 o If the MAG has successfully negotiated and exchanged the initial 365 GRE keys with the LMA for a specific binding, the MAG SHOULD NOT 366 include the GRE Key option in the de-registration Proxy Binding 367 Update. 369 o On receiving a packet from the tunnel with the GRE encapsulation 370 header, the mobile access gateway MUST use the GRE Key to 371 determine the necessary special processing for the data packet, 372 e.g., lookup the mobile node's layer-2 address, determine any 373 special processing or treatment for the data packet flow, then 374 remove the encapsulation header before forwarding the packet. 376 5. Local Mobility Anchor Considerations 378 5.1. Extensions to the Binding Cache Entry 380 When the local mobility anchor and the mobile access gateway 381 successfully negotiates GRE encapsulation and exchange downlink and 382 uplink GRE keys, the local mobility anchor MUST maintain the downlink 383 and uplink GRE keys as part of the mobile node BCE. This requires 384 that the BCE described in section 5.1 of the Proxy Mobile IPv6 base 385 specification [RFC5213] to be extended. To support this 386 specification, the BCE must be extended with the following three 387 additional fields. 389 o A flag indicating whether GRE encapsulation is enabled for the 390 mobile node's traffic flows. 392 o The Downlink GRE Key, assigned by the MAG and used in the GRE 393 encapsulation header of the tunneled packet from the local 394 mobility anchor to the mobile access gateway. 396 o The Uplink GRE Key, assigned by the LMA and used in the GRE 397 encapsulation header of the tunneled packet from the mobile access 398 gateway to the local mobility anchor. 400 5.2. Operational Summary 402 o After successfully processes a Proxy Binding Update message with 403 the GRE Key option which includes a downlink GRE key in the GRE 404 Key Identifier field for Initial GRE Key exchange as in 405 Section 3.3.1, the local mobility anchor MUST include the GRE Key 406 option with the uplink GRE key in the GRE Key Identifier field 407 when responding with a successful Proxy Binding Acknowledgement 408 message. 410 o If the GRE tunneling is negotiated and the downlink and uplink GRE 411 keys have been exchanged between the mobile access gateway and the 412 local mobility anchor for a specific binding, the local mobility 413 anchor MUST use the negotiated downlink GRE key in the GRE header 414 of every packet that is destined to the mobile node of this 415 specific binding over the GRE tunnel to the mobile access gateway. 417 o If the received Proxy Binding Update message does not contain the 418 GRE Key option, and if the local mobility anchor determines that 419 GRE encapsulation and GRE key is required, e.g., overlapping IPv4 420 private addressing is in use, LMA local policy or LMA-MAG peer 421 policy, the local mobility anchor MUST reject the request and send 422 the Proxy Binding Acknowledgement message to the mobile access 423 gateway with the status code as defined 424 in Section 6.2, indicating that GRE encapsulation and GRE key is 425 required. 427 o If after receiving Proxy Binding Update message with the GRE Key 428 option and successfully processes the Proxy Binding Update, the 429 local mobility anchor determines that GRE encapsulation and key 430 exchange is not required for this specific binding, e.g., private 431 IPv4 addressing is not in use, the LMA MUST send a Proxy Binding 432 Acknowledgement message to the MAG with the status code . The local mobility anchor MUST NOT include 434 the GRE Key option. 436 o If the local mobility anchor successfully processes a 437 deregistration Proxy Binding Update message which contains a GRE 438 Key option with a downlink GRE key included, the LMA follows the 439 same deregistration process as per the base Proxy Mobile IPv6 440 specification [RFC5213] to clean the binding cache entry and all 441 associated resources including the downlink and uplink GRE keys. 443 o On receiving a packet from the tunnel with the GRE encapsulation 444 header, the local mobility anchor MUST use the GRE Key present in 445 the GRE extension header to determine the necessary special 446 processing for the data packet, e.g., lookup the mobile node's 447 home gateway address, determine any special processing or 448 treatment for the data packet flow, then remove the encapsulation 449 header before forwarding the packet. 451 6. Message Formats 453 This section defines an extension to the Mobile IPv6 [RFC3775] 454 protocol messages. The use of GRE Key option for supporting GRE 455 tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in 456 this document. 458 6.1. GRE Key Option 460 A new mobility option, the GRE Key option, is defined for use in the 461 Proxy Binding Update and Proxy Binding Acknowledgment messages 462 exchanged between the mobile access gateway and the local mobility 463 anchor. This option can be used for negotiating GRE encapsulation 464 mode and exchanging the downlink and uplink GRE keys that can be used 465 by the peers in all GRE encapsulated packets for marking that 466 specific mobile node's data flow. 468 The alignment requirement for this option is 4n. 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Type | Length | Reserved | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | GRE Key Identifier | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 2: GRE Key Option 480 Type 482 484 Length 486 8-bit unsigned integer indicating the length in octets of the 487 option, excluding the type and length fields. If the Length field 488 is set to 2, it indicates that the GRE key is not being carried in 489 the option. If the length field is set to a value of 6, it means 490 that either the downlink or the uplink GRE key is carried. 492 Reserved 494 These fields are unused. They MUST be initialized to zero by the 495 sender and MUST be ignored by the receiver. 497 GRE Key Identifier 499 32-bit field containing the Downlink or the Uplink GRE Key. This 500 field is present in the GRE Key option only if the GRE keys are 501 being exchanged using the Proxy Binding Update and Proxy Binding 502 Acknowledgement messages. 504 6.2. Status Codes 506 The following status code values are defined for use in the Binding 507 Acknowledgment message when using Proxy Mobile IPv6. 509 GRE KEY OPTION NOT REQUIRED (TBD less than 128) 511 When the local mobility anchor receives a Proxy Binding Update 512 with the GRE Key option while the GRE encapsulation is not 513 required for this specific mobile node, the LMA uses this code to 514 indicate to the mobile access gateway that the Proxy Binding 515 Update has been processed successfully but GRE Encapsulation and 516 GRE Key is not required. 518 GRE KEY OPTION REQUIRED (TBD more than 128) 520 When the local mobility anchor receives a Proxy Binding Update 521 without the GRE Key option while the GRE encapsulation is required 522 for this specific mobile node, the local mobility anchor uses this 523 code to reject the Proxy Binding Update and indicate to the mobile 524 access gateway that GRE Encapsulation and Keys is required. 526 7. IANA Considerations 528 This document defines a new Mobility Option, the GRE Key Option, 529 described in Section 6.1. This option is carried in the Mobility 530 Header. The type value for this option needs to be assigned from the 531 same numbering space as allocated for the other mobility options 532 defined in the Mobile IPv6 specification [RFC3775]. 534 This document also defines two new Binding Acknowledgement status 535 codes as described in Section 6.2 and requests that these two codes 536 be allocated with numeric values as specified in Section 6.2 from the 537 "Status Codes" registry of the Mobility IPv6 Parameters located at 538 http://www.iana.org/assignments/mobility-parameters. 540 8. Security Considerations 542 The GRE Key Option, defined in this document, that can be carried in 543 Proxy Binding Update and Proxy Binding Acknowledgement messages, 544 reveals the group affiliation of a mobile node identified by its NAI 545 or an IP address. It may help an attacker in targeting flows 546 belonging to a specific group. This vulnerability can be prevented, 547 by enabling confidentiality protection on the Proxy Binding Update 548 and Proxy Binding Acknowledgement messages where the presence of the 549 NAI and GRE Key Options establish a mobile node's relation to a 550 specific group. This vulnerability can also be avoided by enabling 551 confidentiality protection on all the tunneled data packets between 552 the mobile access gateway and the local mobility anchor, for hiding 553 all the markings. 555 9. Acknowledgements 557 The authors would like to thank Alessio Casati, Barney Barnowski, 558 Mark Grayson and Parviz Yegani for their input on the need for this 559 option. The authors would like to thank Charlie Perkins, Curtis 560 Provost, Irfan Ali, Jouni Korhonen, Julien Langanier, Kuntal 561 Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review 562 and comments. 564 10. Normative References 566 [ID-PMIP6-IPv4] 567 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 568 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05 569 (work in progress), September 2008. 571 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 572 E. Lear, "Address Allocation for Private Internets", 573 BCP 5, RFC 1918, February 1996. 575 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 576 October 1996. 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, March 1997. 581 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 582 IPv6 Specification", RFC 2473, December 1998. 584 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 585 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 586 March 2000. 588 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 589 RFC 2890, September 2000. 591 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 592 in IPv6", RFC 3775, June 2004. 594 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 595 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 597 Authors' Addresses 599 Ahmad Muhanna 600 Nortel 601 2221 Lakeside Blvd. 602 Richardson, TX 75082 603 USA 605 Email: amuhanna@nortel.com 607 Mohamed Khalil 608 Nortel 609 2221 Lakeside Blvd. 610 Richardson, TX 75082 611 USA 613 Email: mkhalil@nortel.com 614 Sri Gundavelli 615 Cisco Systems 616 170 West Tasman Drive 617 San Jose, CA 95134 618 USA 620 Email: sgundave@cisco.com 622 Kent Leung 623 Cisco Systems 624 170 West Tasman Drive 625 San Jose, CA 95134 626 USA 628 Email: kleung@cisco.com 630 Full Copyright Statement 632 Copyright (C) The IETF Trust (2008). 634 This document is subject to the rights, licenses and restrictions 635 contained in BCP 78, and except as set forth therein, the authors 636 retain all their rights. 638 This document and the information contained herein are provided on an 639 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 640 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 641 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 642 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 643 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 644 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 646 Intellectual Property 648 The IETF takes no position regarding the validity or scope of any 649 Intellectual Property Rights or other rights that might be claimed to 650 pertain to the implementation or use of the technology described in 651 this document or the extent to which any license under such rights 652 might or might not be available; nor does it represent that it has 653 made any independent effort to identify any such rights. Information 654 on the procedures with respect to rights in RFC documents can be 655 found in BCP 78 and BCP 79. 657 Copies of IPR disclosures made to the IETF Secretariat and any 658 assurances of licenses to be made available, or the result of an 659 attempt made to obtain a general license or permission for the use of 660 such proprietary rights by implementers or users of this 661 specification can be obtained from the IETF on-line IPR repository at 662 http://www.ietf.org/ipr. 664 The IETF invites any interested party to bring to its attention any 665 copyrights, patents or patent applications, or other proprietary 666 rights that may cover technology that may be required to implement 667 this standard. Please address the information to the IETF at 668 ietf-ipr@ietf.org. 670 Acknowledgment 672 Funding for the RFC Editor function is provided by the IETF 673 Administrative Support Activity (IASA).