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