idnits 2.17.1 draft-ietf-netlmm-grekey-option-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors 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 (January 28, 2009) is 5567 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-09 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: August 1, 2009 S. Gundavelli 6 K. Leung 7 Cisco Systems 8 January 28, 2009 10 GRE Key Option for Proxy Mobile IPv6 11 draft-ietf-netlmm-grekey-option-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 1, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This document defines a new Mobility Option for allowing the mobile 51 access gateway and the local mobility anchor to negotiate GRE 52 encapsulation mode and exchange the downlink and uplink GRE keys 53 which are used for marking the downlink and uplink traffic that 54 belong to a specific mobile node session or a specific flow. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 60 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4 63 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4 64 3.2. GRE Encapsulation Support . . . . . . . . . . . . . . . . 6 65 3.3. GRE Key Exchange Mechanism . . . . . . . . . . . . . . . . 6 66 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6 67 3.3.2. GRE Key Exchange During Binding Re-registration . . . 6 68 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 7 69 4.1. Extensions to the Conceptual Data Structure . . . . . . . 7 70 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 8 71 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 9 72 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 9 73 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 10 74 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 11 76 6.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 80 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 The base Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile 86 IPv6 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 87 encapsulation modes [RFC2473][RFC2003] for the tunneled traffic 88 between the local mobility anchor and the mobile access gateway. 89 There are scenarios where these encapsulation modes are not 90 sufficient to uniquely identify the destination of packets of a 91 specific flow. Thus, there is a need for an encapsulation mode with 92 richer semantics. The Generic Routing Encapsulation [RFC2784] and 93 the Key extension as defined in [RFC2890], has the required semantics 94 to allow such distinction for use in Proxy Mobile IPv6. 96 This document defines the GRE Key option to be used for the 97 negotiation of GRE encapsulation mode and the exchange of the uplink 98 and downlink GRE keys. The negotiated downlink and uplink GRE keys 99 can be used for marking the downlink and uplink traffic for a 100 specific mobility session or a specific flow. 102 2. Conventions & Terminology 104 2.1. Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 2.2. Terminology 112 All the general mobility related terminology and abbreviations are to 113 be interpreted as defined in Mobile IPv6 specification [RFC3775] and 114 Proxy Mobile IPv6 specification [RFC5213]. The following terms are 115 used in this document. 117 Downlink Traffic 119 The traffic in the tunnel between the local mobility anchor and 120 the mobile access gateway, heading towards the mobile access 121 gateway and tunneled at the local mobility anchor. This traffic 122 is also called forward direction traffic. 124 Uplink Traffic 126 The traffic in the tunnel between the mobile access gateway and 127 the local mobility anchor, heading towards the local mobility 128 anchor and tunneled at the mobile access gateway. This traffic is 129 also called reverse direction traffic. 131 Downlink GRE Key 133 The GRE key is assigned by the mobile access gateway and used by 134 the local mobility anchor to mark the downlink traffic which 135 belongs to a specific mobility session or flow as described in 136 this document. 138 Uplink GRE Key 140 The GRE key is assigned by the local mobility anchor and used by 141 the mobile access gateway to mark the uplink traffic which belongs 142 to a specific mobility session or flow as described in this 143 document. 145 3. GRE Encapsulation and Key Exchange 147 3.1. GRE Encapsulation Overview 149 Using the GRE Key option defined in this specification, the mobile 150 access gateway and the local mobility anchor can negotiate GRE 151 encapsulation mode and exchange the GRE keys for marking the downlink 152 and uplink traffic. 154 Once the GRE keys have been exchanged between the mobile access 155 gateway and the local mobility anchor, the mobile access gateway will 156 use the uplink GRE key that is assigned by the local mobility anchor 157 in the GRE encapsulation header of the uplink payload packet. 158 Similarly, the local mobility anchor will use the downlink GRE key as 159 negotiated with the mobile access gateway in the GRE encapsulation 160 header of the downlink payload packet. 162 The following illustration explains the use of GRE encapsulation mode 163 and the GRE keys for supporting the usecase where overlapping IPv4 164 private address [RFC1918] allocation is in use. 166 +------------+ 167 | Operator-A | 168 | | 169 | 10.x.0.0/16| 170 +------------+ 171 / 172 +------+ +------+ / 173 | | ========================== | | / 174 MN-1---| | / \ | | / Key-1 175 | M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic 176 MN-2---| A |--| |--| M |- 177 | G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2 178 MN-3---| | \ / | | \Traffic 179 | | ========================== | | \ 180 MN-4---| | Proxy Mobile IPv6 Tunnel | | \ 181 +------+ +------+ \ 182 \ 183 Operator-C: Access Network +------------+ 184 | Operator-B | 185 | | 186 | 10.x.0.0/16| 187 +------------+ 189 Figure 1: Overlapping IPv4 Private Address Space 191 Figure 1 illustrates a local mobility anchor providing mobility 192 service to mobile nodes that are from different operators and are 193 assigned IPv4 addresses from overlapping private address space. In 194 this scenario, the mobile access gateway and the local mobility 195 anchor must be able distinguish the flows belonging to a given 196 operator from the flows belonging to some other operator. 198 The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and 199 mobile nodes, MN-3 and MN-4 are visiting from Operator-B. The mobile 200 access gateway and the local mobility anchor exchange a specific pair 201 of downlink and uplink GRE keys and save them as part of the mobile 202 node binding to be used for identifying the flows belonging to each 203 mobile node. 205 The LMA and the MAG will be able to distinguish each mobile node 206 flow(s) based on the GRE key present in the GRE header of the 207 tunneled payload packet, and route them accordingly. 209 3.2. GRE Encapsulation Support 211 To request GRE encapsulation support, the mobile access gateway MUST 212 include the GRE Key option in the Proxy Binding Update message sent 213 to the local mobility anchor. In case, the mobile access gateway 214 wants to use GRE encapsulation without the GRE keys, it MUST NOT 215 include the GRE Key Identifier in the option. 217 If the local mobility anchor supports GRE encapsulation and the Proxy 218 Binding Update processing is successful, the LMA sends a Proxy 219 Binding Acknowledgement with the GRE Key option. If GRE 220 encapsulation is being used without the GRE keys, the LMA MUST NOT 221 include the GRE Key Identifier in the GRE option. 223 3.3. GRE Key Exchange Mechanism 225 The following subsections describe how the mobile access gateway and 226 the local mobility anchor exchange downlink and uplink GRE keys using 227 proxy mobile IPv6 registration procedure. 229 3.3.1. Initial GRE Key Exchange 231 When the mobile access gateway determines, based on, e.g., private 232 IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA 233 peer agreement, that GRE encapsulation is needed and GRE keys are 234 required, the mobile access gateway MUST include the GRE Key option 235 in the initial Proxy Binding Update message sent to the local 236 mobility anchor. The mobile access gateway MUST include the downlink 237 GRE key in the GRE Key Identifier field of the GRE Key option. 239 After successfully processing the initial Proxy Binding Update and 240 accepting the downlink GRE key, the LMA MUST include the GRE Key 241 option with the uplink GRE key in the GRE Key Identifier field when 242 sending a successful Proxy Binding Acknowledgement to the MAG. 244 3.3.2. GRE Key Exchange During Binding Re-registration 246 If the MAG has successfully negotiated and exchanged the initial GRE 247 keys with the LMA for a specific binding, the MAG SHOULD NOT include 248 the GRE Key option with the downlink GRE key in the Proxy Binding 249 Update which is used for requesting a Binding Lifetime Extension. 251 However, during inter-MAG handoff and if the new mobile access 252 gateway determines, based on, e.g., private IPv4 address support, the 253 MAG local policy, the MAG-LMA peer agreement, or an indication during 254 the handoff process, that GRE encapsulation and GRE key exchange is 255 required, the new mobile access gateway MUST include the GRE key 256 option with the downlink GRE key in the Proxy Binding Update which is 257 used for requesting an after handoff Binding Lifetime extension. In 258 this case, the new MAG may either pick a new downlink GRE key or use 259 the downlink GRE key that was used by the previous MAG for the same 260 binding. For the new MAG to know the downlink GRE key used by the 261 previous MAG, it may require transfer of context from the previous 262 MAG to the new MAG during a handoff. Such mechanisms are out-of- 263 scope for this document. 265 If the LMA successfully processes a handoff-triggered Binding 266 Lifetime Extension Proxy Binding Update message which contains a GRE 267 key option with a downlink GRE key included, the LMA MUST return the 268 same uplink GRE key that was exchanged with the previous MAG and is 269 saved in the respected Binding Cache Entry (BCE). 271 If the LMA receives handoff-triggered Binding Lifetime Extension 272 Proxy Binding Update message without the GRE key option for a BCE 273 that is using GRE keys and GRE encapsulation, the LMA MUST reject the 274 Proxy Binding Update by sending a Proxy Binding Acknowledgement 275 message with the status field is set to as 276 defined in Section 6.2. If the LMA is preconfigured to use a 277 different mechanism other than GRE encapsulation with the MAG which 278 sent the handoff-triggered Binding Lifetime Extension Proxy Binding 279 Update, the LMA MAY accept the PBU and if it is successfully 280 processed, the LMA returns a successful PBA without the GRE Key 281 option. In this case, mapping between the current GRE keys and the 282 other mechanism identifiers or labels is outside the scope of this 283 specification. 285 Typically, the MAG does not include the GRE Key Option in a Proxy 286 Binding Update message sent to refresh an existing binding. However, 287 if the LMA receives a Proxy Binding Update from the current MAG to 288 extend the existing binding, and the Proxy Binding Update messages 289 contains the GRE Key option and the downlink GRE Key identifier, it 290 MUST NOT reject the Proxy Binding Update message. In this case, the 291 LMA processes the Proxy Binding Update normally and if the included 292 downlink GRE key is different than the one saved in the respected 293 BCE, the LMA MUST update the BCE with the new downlink GRE key. 295 4. Mobile Access Gateway Considerations 297 4.1. Extensions to the Conceptual Data Structure 299 Every mobile access gateway maintains a Binding Update List (BUL) 300 entry for each currently attached mobile node, as explained in 301 Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To 302 support this specification, the conceptual Binding Update List entry 303 data structure must be extended with the following three new 304 additional fields. 306 o A flag indicating whether GRE encapsulation is enabled for the 307 mobile node's traffic flows. 309 o The downlink GRE key used in the GRE encapsulation header of the 310 tunneled payload packet from the local mobility anchor to the 311 mobile access gateway that is destined to the mobile node. This 312 GRE key is generated by the MAG and communicated to the LMA in the 313 GRE Key option in the Proxy Binding Update message. 315 o The uplink GRE key used in the GRE encapsulation header of the 316 tunneled payload packet from the mobile access gateway to the 317 local mobility anchor that is originating from the mobile node. 318 This GRE key is obtained from the GRE Key Identifier field of the 319 GRE Key option present in the received Proxy Binding 320 Acknowledgement message sent by the LMA as specified in this 321 document. 323 4.2. Operational Summary 325 o If the MAG determines that GRE encapsulation and GRE key is 326 required, the MAG MUST include the GRE Key option with the 327 downlink GRE key in the GRE Key Identifier field in the Proxy 328 Binding Update message that is sent by the mobile access gateway 329 to the local mobility anchor. 331 o After receiving a successful Proxy Binding Acknowledgment message 332 with the GRE Key option which includes the uplink GRE key, the 333 mobile access gateway MUST update the related three fields in the 334 mobile node Binding Update List entry described in Section 4.1. 335 Additionally, the MAG MUST use the assigned uplink GRE Key for 336 tunneling all the traffic originating from the mobile node before 337 forwarding the tunneled traffic to the LMA. 339 o If the mobile access gateway included the GRE Key option in the 340 Proxy Binding Update for a specific mobile node and the local 341 mobility anchor accepts the Proxy Binding Update by sending a 342 Proxy Binding Acknowledgement with a success status code (less 343 than 128) other than , but without 344 the GRE Key option, then the mobile access gateway MUST consider 345 that the local mobility anchor does not support GRE Key option as 346 per this specification. The mobile access gateway SHOULD NOT 347 include the GRE Key option in any subsequent Proxy Binding Update 348 message that is sent to that LMA. 350 o If the mobile access gateway sent a Proxy Binding Update message 351 without the GRE Key option, but the received Proxy Binding 352 Acknowledgement has the Status Code , 353 indicating that the GRE encapsulation and GRE key is required, the 354 mobile access gateway SHOULD resend the Proxy Binding Update 355 message with the GRE Key option. If the MAG does not support the 356 GRE Key option, the MAG MAY log the event and possibly raise an 357 alarm to indicate a possible misconfiguration. 359 o If the mobile access gateway sent a Proxy Binding Update message 360 with the GRE Key option and the downlink GRE key included and 361 received a successful Proxy Binding Acknowledgement message with a 362 status code , the mobile access 363 gateway MUST consider that GRE encapsulation and GRE keys is not 364 required for this specific binding. The MAG follows the Proxy 365 Mobile IPv6 specification [RFC5213] for the handling of uplink and 366 downlink traffic for this mobile node binding and MUST NOT include 367 the GRE Key option in any subsequent Proxy Binding Update message 368 for this specific mobile node that are sent to that LMA. 370 o If the MAG sent a re-registration Proxy Binding Update message 371 without the GRE Key option, but received a successful Proxy 372 Binding Acknowledgement which includes the GRE Key option with the 373 uplink GRE key, the MAG MUST compare the received uplink GRE key 374 with the one saved in the respected Binding Update List entry and 375 update it if the received uplink GRE key is different. 377 o If the MAG has successfully negotiated and exchanged the initial 378 GRE keys with the LMA for a specific binding, the MAG SHOULD NOT 379 include the GRE Key option in the de-registration Proxy Binding 380 Update. 382 o On receiving a packet from the tunnel with the GRE encapsulation 383 header, the mobile access gateway MUST use the GRE Key to 384 determine the necessary special processing for the data packet, 385 e.g., lookup the mobile node's layer-2 address, determine any 386 special processing or treatment for the data packet flow, then 387 remove the encapsulation header before forwarding the packet. 389 5. Local Mobility Anchor Considerations 391 5.1. Extensions to the Binding Cache Entry 393 When the local mobility anchor and the mobile access gateway 394 successfully negotiates GRE encapsulation and exchange downlink and 395 uplink GRE keys, the local mobility anchor MUST maintain the downlink 396 and uplink GRE keys as part of the mobile node BCE. This requires 397 that the BCE described in section 5.1 of the Proxy Mobile IPv6 base 398 specification [RFC5213] to be extended. To support this 399 specification, the BCE must be extended with the following three 400 additional fields. 402 o A flag indicating whether GRE encapsulation is enabled for the 403 mobile node's traffic flows. 405 o The downlink GRE Key, assigned by the MAG and used in the GRE 406 encapsulation header of the tunneled payload packet from the local 407 mobility anchor to the mobile access gateway. 409 o The Uplink GRE Key, assigned by the LMA and used in the GRE 410 encapsulation header of the tunneled payload packet from the 411 mobile access gateway to the local mobility anchor. 413 5.2. Operational Summary 415 o After successfully processing a Proxy Binding Update message with 416 the GRE Key option which includes a downlink GRE key in the GRE 417 Key Identifier field for Initial GRE Key exchange as in 418 Section 3.3.1, the local mobility anchor MUST include the GRE Key 419 option with the uplink GRE key in the GRE Key Identifier field 420 when responding with a successful Proxy Binding Acknowledgement 421 message. 423 o If the GRE tunneling is negotiated and the downlink and uplink GRE 424 keys have been exchanged between the mobile access gateway and the 425 local mobility anchor for a specific binding, the local mobility 426 anchor MUST use the negotiated downlink GRE key in the GRE header 427 of every packet that is destined to the mobile node of this 428 specific binding over the GRE tunnel to the mobile access gateway. 430 o If the received Proxy Binding Update message does not contain the 431 GRE Key option, and if the local mobility anchor determines that 432 GRE encapsulation and GRE key is required, e.g., overlapping IPv4 433 private addressing is in use, LMA local policy or LMA-MAG peer 434 policy, the local mobility anchor MUST reject the request and send 435 the Proxy Binding Acknowledgement message to the mobile access 436 gateway with the status code as defined 437 in Section 6.2, indicating that GRE encapsulation and GRE key is 438 required. 440 o If after receiving Proxy Binding Update message with the GRE Key 441 option and successfully processes the Proxy Binding Update, the 442 local mobility anchor determines that GRE encapsulation and key 443 exchange is not required for this specific binding, e.g., private 444 IPv4 addressing is not in use, the LMA MUST send a Proxy Binding 445 Acknowledgement message to the MAG with the status code . The local mobility anchor MUST NOT include 447 the GRE Key option in that Proxy Binding Acknowledgement. 449 o If the local mobility anchor successfully processes a de- 450 registration Proxy Binding Update message which contains a GRE Key 451 option with a downlink GRE key included, the LMA follows the same 452 de-registration process as per the base Proxy Mobile IPv6 453 specification [RFC5213] to clean the binding cache entry and all 454 associated resources including the downlink and uplink GRE keys. 456 o On receiving a packet from the tunnel with the GRE encapsulation 457 header, the local mobility anchor MUST use the GRE Key present in 458 the GRE extension header to determine the necessary special 459 processing for the data packet, e.g., lookup the mobile node's 460 home gateway address, determine any special processing or 461 treatment for the data packet flow, then remove the encapsulation 462 header before forwarding the packet. 464 6. Message Formats 466 This section defines an extension to the Mobile IPv6 [RFC3775] 467 protocol messages. The use of GRE Key option for supporting GRE 468 tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in 469 this document. 471 6.1. GRE Key Option 473 A new mobility option, the GRE Key option, is defined for use in the 474 Proxy Binding Update and Proxy Binding Acknowledgment messages 475 exchanged between the mobile access gateway and the local mobility 476 anchor. This option can be used for negotiating GRE encapsulation 477 mode and exchanging the downlink and uplink GRE keys that can be used 478 by the peers in all GRE encapsulated packets for marking that 479 specific mobile node's data flow. 481 The alignment requirement for this option is 4n. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type | Length | Reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | GRE Key Identifier | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 2: GRE Key Option 492 Type 494 496 Length 498 8-bit unsigned integer indicating the length in octets of the 499 option, excluding the type and length fields. If the Length field 500 is set to 2, it indicates that the GRE key is not being carried in 501 the option. If the length field is set to a value of 6, it means 502 that either the downlink or the uplink GRE key is carried. 504 Reserved 506 These fields are unused. They MUST be initialized to zero by the 507 sender and MUST be ignored by the receiver. 509 GRE Key Identifier 511 32-bit field containing the downlink or the uplink GRE key. This 512 field is present in the GRE Key option only if the GRE keys are 513 being exchanged using the Proxy Binding Update and Proxy Binding 514 Acknowledgement messages. 516 6.2. Status Codes 518 The following status code values are defined for use in the Binding 519 Acknowledgment message when using Proxy Mobile IPv6. 521 GRE KEY OPTION NOT REQUIRED (TBD less than 128) 523 When the local mobility anchor receives a Proxy Binding Update 524 with the GRE Key option while the GRE encapsulation is not 525 required for this specific mobile node, the LMA uses this code to 526 indicate to the mobile access gateway that the Proxy Binding 527 Update has been processed successfully but GRE Encapsulation and 528 GRE Key is not required. 530 GRE KEY OPTION REQUIRED (TBD more than 128) 532 When the local mobility anchor receives a Proxy Binding Update 533 without the GRE Key option while the GRE encapsulation is required 534 for this specific mobile node, the local mobility anchor uses this 535 code to reject the Proxy Binding Update and indicate to the mobile 536 access gateway that GRE Encapsulation and Keys is required. 538 7. IANA Considerations 540 This document defines a new Mobility Option, the GRE Key Option, 541 described in Section 6.1. This option is carried in the Mobility 542 Header. The type value for this option needs to be assigned from the 543 same numbering space as allocated for the other mobility options 544 defined in the Mobile IPv6 specification [RFC3775]. 546 This document also defines two new Binding Acknowledgement status 547 codes as described in Section 6.2 and requests that these two codes 548 be allocated with numeric values as specified in Section 6.2 from the 549 "Status Codes" registry of the Mobility IPv6 Parameters located at 550 http://www.iana.org/assignments/mobility-parameters. 552 8. Security Considerations 554 The GRE Key Option, defined in this document, that can be carried in 555 Proxy Binding Update and Proxy Binding Acknowledgement messages, 556 reveals the group affiliation of a mobile node identified by its NAI 557 or an IP address. It may help an attacker in targeting flows 558 belonging to a specific group. This vulnerability can be prevented, 559 by enabling confidentiality protection on the Proxy Binding Update 560 and Proxy Binding Acknowledgement messages where the presence of the 561 NAI and GRE Key Options establish a mobile node's relation to a 562 specific group. This vulnerability can also be avoided by enabling 563 confidentiality protection on all the tunneled data packets between 564 the mobile access gateway and the local mobility anchor, for hiding 565 all the markings. 567 In Proxy Mobile IPv6 [RFC5213], the use of IPsec for protecting a 568 mobile node's data traffic is optional. However, if IPsec ESP is 569 used to protect the mobile node's tunneled data traffic where GRE 570 encapsulation is used, GRE over IPsec is RECOMMENDED. 572 9. Acknowledgements 574 The authors would like to thank Alessio Casati, Barney Barnowski, 575 Mark Grayson and Parviz Yegani for their input on the need for this 576 option. The authors would like to thank Charlie Perkins, Curtis 577 Provost, Irfan Ali, Jouni Korhonen, Julien Langanier, Kuntal 578 Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review 579 and comments. 581 10. Normative References 583 [ID-PMIP6-IPv4] 584 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 585 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 586 (work in progress), January 2009. 588 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 589 E. Lear, "Address Allocation for Private Internets", 590 BCP 5, RFC 1918, February 1996. 592 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 593 October 1996. 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 599 IPv6 Specification", RFC 2473, December 1998. 601 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 602 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 603 March 2000. 605 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 606 RFC 2890, September 2000. 608 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 609 in IPv6", RFC 3775, June 2004. 611 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 612 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 614 Authors' Addresses 616 Ahmad Muhanna 617 Nortel 618 2221 Lakeside Blvd. 619 Richardson, TX 75082 620 USA 622 Email: amuhanna@nortel.com 623 Mohamed Khalil 624 Nortel 625 2221 Lakeside Blvd. 626 Richardson, TX 75082 627 USA 629 Email: mkhalil@nortel.com 631 Sri Gundavelli 632 Cisco Systems 633 170 West Tasman Drive 634 San Jose, CA 95134 635 USA 637 Email: sgundave@cisco.com 639 Kent Leung 640 Cisco Systems 641 170 West Tasman Drive 642 San Jose, CA 95134 643 USA 645 Email: kleung@cisco.com