idnits 2.17.1 draft-ietf-netlmm-grekey-option-05.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 document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 18, 2009) is 5546 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 (-10) exists of draft-ietf-mext-nemo-v4traversal-07 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-11 == 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 (~~), 5 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 22, 2009 S. Gundavelli 6 K. Leung 7 Cisco Systems 8 February 18, 2009 10 GRE Key Option for Proxy Mobile IPv6 11 draft-ietf-netlmm-grekey-option-05.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 22, 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 specification defines a new Mobility Option for allowing the 51 mobile access gateway and the local mobility anchor to negotiate GRE 52 (Generic Routing Encapsulation) encapsulation mode and exchange the 53 downlink and uplink GRE keys which are used for marking the downlink 54 and uplink traffic that belong to a specific mobility session. In 55 addition, the same mobility option is used to explicitly negotiate 56 the GRE encapsulation mode only without exchanging the GRE keys. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 62 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . . . 5 65 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 5 66 3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 7 67 3.3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . 7 68 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 7 69 3.3.2. GRE Key Exchange During Binding Re-registration . . . 8 70 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 9 71 4.1. Extensions to the Conceptual Data Structure . . . . . . . 9 72 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9 73 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 11 74 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 11 75 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11 76 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 13 78 6.2. Proxy Binding Update Message Extension . . . . . . . . . . 14 79 6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14 80 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 15 81 7. Data Packets Processing Considerations . . . . . . . . . . . . 15 82 7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 16 83 7.2. TLV-header Tunneling Negotiation . . . . . . . . . . . . . 17 84 7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18 85 7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 19 86 7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 20 87 7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 21 88 7.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 21 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile IPv6 101 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 102 encapsulation modes [RFC2473][RFC2003] for the tunneled traffic 103 between the local mobility anchor and the mobile access gateway. 104 There are scenarios where these encapsulation modes are not 105 sufficient to uniquely identify the destination of packets of a 106 specific binding. Thus, there is a need for an encapsulation mode 107 with richer semantics. The Generic Routing Encapsulation (GRE) 108 [RFC2784] and the Key extension as defined in [RFC2890], has the 109 required semantics to allow such distinction for use in Proxy Mobile 110 IPv6. 112 This specification defines the GRE Key option to be used for the 113 negotiation of GRE encapsulation mode and exchange of the uplink and 114 downlink GRE keys. The negotiated downlink and uplink GRE keys can 115 be used for marking the downlink and uplink traffic for a specific 116 mobility session. In addition, this specification enables the mobile 117 access gateway and the local mobility anchor to explicitly negotiate 118 the GRE encapsulation mode only using the GRE Key mobility option 119 while omitting the GRE Key Identifier field. . 121 2. Conventions & Terminology 123 2.1. Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 specification are to be interpreted as described in RFC 2119 128 [RFC2119]. 130 2.2. Terminology 132 All the general mobility related terminology and abbreviations are to 133 be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile 134 IPv6 [RFC5213] specifications. The following terms are used in this 135 specification. 137 Downlink Traffic 139 The traffic in the tunnel between the local mobility anchor and 140 the mobile access gateway, heading towards the mobile access 141 gateway and tunneled at the local mobility anchor. This traffic 142 is also called forward direction traffic. 144 Uplink Traffic 146 The traffic in the tunnel between the mobile access gateway and 147 the local mobility anchor, heading towards the local mobility 148 anchor and tunneled at the mobile access gateway. This traffic is 149 also called reverse direction traffic. 151 Downlink GRE Key 153 The GRE key is assigned by the mobile access gateway and used by 154 the local mobility anchor to mark the downlink traffic which 155 belongs to a specific mobility session as described in this 156 specification. 158 Uplink GRE Key 160 The GRE key is assigned by the local mobility anchor and used by 161 the mobile access gateway to mark the uplink traffic which belongs 162 to a specific mobility session as described in this specification. 164 A Policy Check 166 When LMA receives an initial, handoff-triggered Binding Lifetime 167 Extension, or Binding Lifetime Extension Proxy Binding Update for 168 a mobility session, the LMA determines if the GRE encapsulation 169 mode only or GRE encapsulation and GRE keys are required based on 170 a policy check. This policy could be a per MAG-LMA peer, a per- 171 LMA local policy, a per-MN policy, or the combination of all. 173 3. GRE Encapsulation and Keys Exchange 175 3.1. GRE Encapsulation Overview 177 Using the GRE Key option defined in this specification, the mobile 178 access gateway and the local mobility anchor can negotiate GRE 179 encapsulation mode only or GRE encapsulation mode and exchange the 180 GRE keys for marking the downlink and uplink traffics. In the case 181 when GRE encapsulation mode only is negotiated between the MAG and 182 the LMA, then no GRE keys are used. 184 However, once the GRE keys have been exchanged between the mobile 185 access gateway and the local mobility anchor as per this 186 specification, the mobile access gateway will use the uplink GRE key 187 that is assigned by the local mobility anchor in the GRE header of 188 the uplink payload packet. Similarly, the local mobility anchor will 189 use the downlink GRE key as negotiated with the mobile access gateway 190 in the GRE header of the downlink payload packet. 192 The following illustration explains the use of GRE encapsulation mode 193 and the GRE keys for supporting the usecase where overlapping IPv4 194 private address [RFC1918] allocation is in use. 196 +------------+ 197 | Operator-A | 198 | | 199 | 10.x.0.0/16| 200 +------------+ 201 / 202 +------+ +------+ / 203 | | ========================== | | / 204 MN-1---| | / \ | | / Key-1 205 | M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic 206 MN-2---| A |--| |--| M |- 207 | G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2 208 MN-3---| | \ / | | \Traffic 209 | | ========================== | | \ 210 MN-4---| | Proxy Mobile IPv6 Tunnel | | \ 211 +------+ +------+ \ 212 \ 213 Operator-C: Access Network +------------+ 214 | Operator-B | 215 | | 216 | 10.x.0.0/16| 217 +------------+ 219 Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping 221 Figure 1 illustrates a local mobility anchor providing mobility 222 service to mobile nodes that are from different operators and are 223 assigned IPv4 addresses from overlapping private address space. In 224 this scenario, the mobile access gateway and the local mobility 225 anchor must be able to distinguish the flows belonging to a given 226 operator from the flows belonging to some other operator. 228 The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and 229 mobile nodes, MN-3 and MN-4 are visiting from Operator-B. The mobile 230 access gateway and the local mobility anchor exchange a specific pair 231 of downlink and uplink GRE keys and save them as part of the mobile 232 node binding to be used for identifying the flows belonging to each 233 mobile node. 235 The LMA and the MAG will be able to distinguish each mobile node 236 flow(s) based on the GRE key present in the GRE header of the 237 tunneled payload packet, and route them accordingly. However, the 238 GRE keys as in this specification apply to the individual mobility 239 binding updated by the Proxy Binding Update but not to all bindings 240 that the mobile may have registered following procedures described in 241 [ID-MCoA]. 243 3.2. GRE Encapsulation Mode Only 245 In order for the mobile access gateway to request GRE encapsulation 246 mode only without exchanging the GRE keys, the mobile access gateway 247 MUST include the GRE Key option but omit the GRE Key Identifier field 248 in the Proxy Binding Update. 250 If the local mobility anchor supports GRE encapsulation and the 251 received Proxy Binding Update contains the GRE Key option but the GRE 252 Key Identifier field is omitted, the mobile access gateway is 253 requesting GRE encapsulation without exchanging the GRE keys 254 dynamically. If the Proxy Binding Update processing is successful, 255 the LMA sends a successful Proxy Binding Acknowledgement message with 256 the GRE Key option but the GRE Key Identifier field is omitted. 258 When the mobile access gateway and the local mobility anchor 259 successfully negotiate the GRE encapsulation mode only, then no GRE 260 keys are used. 262 3.3. GRE Encapsulation and Keys Exchange 264 The following subsections describe how the mobile access gateway and 265 the local mobility anchor negotiate GRE encapsulation and exchange 266 downlink and uplink GRE keys using proxy mobile IPv6 registration 267 procedure. 269 3.3.1. Initial GRE Key Exchange 271 When the mobile access gateway determines, based on, e.g., private 272 IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA 273 peer agreement, that GRE encapsulation is needed and GRE keys are 274 required, the mobile access gateway MUST include the GRE Key option 275 in the initial Proxy Binding Update message sent to the local 276 mobility anchor. The mobile access gateway MUST include the downlink 277 GRE key in the GRE Key Identifier field of the GRE Key option. 279 After the LMA successfully processes the initial Proxy Binding Update 280 and accepts the GRE encapsulation request and the downlink GRE key 281 based on a policy check, the LMA MUST include the GRE Key option with 282 the uplink GRE key in the GRE Key Identifier field in a successful 283 Proxy Binding Acknowledgement and send it to the MAG. 285 3.3.2. GRE Key Exchange During Binding Re-registration 287 If the MAG has successfully negotiated and exchanged the initial GRE 288 keys with the LMA for a specific mobile node binding, the MAG MUST 289 include the GRE Key option with the downlink GRE key in the Proxy 290 Binding Update which is used for requesting a Binding Lifetime 291 Extension. 293 However, during inter-MAG handoff and if the new mobile access 294 gateway determines, based on, e.g., private IPv4 address support, the 295 MAG local policy, the MAG-LMA peer agreement, or an indication during 296 the handoff process, that GRE encapsulation and GRE key exchange is 297 required, the new mobile access gateway MUST include the GRE key 298 option with the downlink GRE key in the Proxy Binding Update which is 299 used for requesting an after handoff Binding Lifetime extension. In 300 this case, the new MAG may either pick a new downlink GRE key or use 301 the downlink GRE key that was used by the previous MAG for the same 302 binding. For the new MAG to know the downlink GRE key used by the 303 previous MAG, it may require transfer of context from the previous 304 MAG to the new MAG during a handoff. Such mechanisms are out-of- 305 scope for this specification. 307 If the LMA successfully processes a handoff-triggered Binding 308 Lifetime Extension Proxy Binding Update message which contains a GRE 309 key option with a downlink GRE key included, the LMA MUST return the 310 same uplink GRE key that was exchanged with the previous MAG for the 311 same mobility session in the GRE key option in a successful Proxy 312 Binding Acknowledgement message sent to the new MAG. 314 If the LMA receives a handoff-triggered Binding Lifetime Extension 315 Proxy Binding Update message without the GRE key option for a BCE 316 that is using GRE keys and GRE encapsulation, the LMA makes a policy 317 check regarding GRE encapsulation and GRE keys exchange. If, 318 according to the policy check, GRE encapsulation and GRE Keys 319 exchange are required, the LMA MUST reject the Proxy Binding Update 320 by sending a Proxy Binding Acknowledgement message with the status 321 field is set to as defined in Section 6.4. 322 Otherwise, the LMA SHOULD accept the Proxy Binding Update and if it 323 is processed successfully, the LMA MUST return a successful Proxy 324 Binding Acknowledgement without including the GRE Key option. 326 4. Mobile Access Gateway Considerations 328 4.1. Extensions to the Conceptual Data Structure 330 Every mobile access gateway maintains a Binding Update List (BUL) 331 entry for each currently attached mobile node, as explained in 332 Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To 333 support this specification, the conceptual Binding Update List entry 334 data structure must be extended with the following three new 335 additional fields. 337 o A flag indicating whether GRE encapsulation is enabled for the 338 mobile node's traffic. 340 o The downlink GRE key used in the GRE encapsulation header of the 341 tunneled payload packet from the local mobility anchor to the 342 mobile access gateway that is destined to the mobile node. This 343 GRE key is generated by the MAG and communicated to the LMA in the 344 GRE Key option in the Proxy Binding Update message. 346 o The uplink GRE key used in the GRE encapsulation header of the 347 tunneled payload packet from the mobile access gateway to the 348 local mobility anchor that is originating from the mobile node. 349 This GRE key is obtained from the GRE Key Identifier field of the 350 GRE Key option present in the received Proxy Binding 351 Acknowledgement message sent by the LMA as specified in this 352 specification. 354 4.2. Operational Summary 356 o If the MAG determines that GRE encapsulation mode only is 357 required, the MAG MUST include the GRE Key option but omit the GRE 358 Key Identifier field in the Proxy Binding Update message that is 359 sent to the local mobility anchor. 361 o If the MAG determines that GRE encapsulation and GRE keys are 362 required, the MAG MUST include the GRE Key option with the 363 downlink GRE key in the GRE Key Identifier field in the Proxy 364 Binding Update message that is sent to the local mobility anchor. 366 o After receiving a successful Proxy Binding Acknowledgment message 367 with the GRE Key option with the GRE Key Identifier field omitted, 368 the mobile access gateway MUST update the mobile node Binding 369 Update List entry described in Section 4.1 by only setting the GRE 370 encapsulation enabled flag. 372 o After receiving a successful Proxy Binding Acknowledgment message 373 with the GRE Key option and the uplink GRE key included in the GRE 374 Key Identifier field, the mobile access gateway MUST update the 375 related three fields in the mobile node Binding Update List entry 376 described in Section 4.1. Additionally, the MAG MUST use the 377 assigned uplink GRE Key for tunneling all the traffic that belong 378 to this mobile node BUL entry and is originated from the mobile 379 node before forwarding the tunneled traffic to the LMA. 381 o If the mobile access gateway includes the GRE Key option in the 382 Proxy Binding Update for a specific mobile node and the local 383 mobility anchor accepts the Proxy Binding Update by sending a 384 Proxy Binding Acknowledgement with a success status code (less 385 than 128) other than , but without 386 the GRE Key option, then the mobile access gateway MUST consider 387 that the local mobility anchor does not support GRE Key option as 388 per this specification. The mobile access gateway SHOULD NOT 389 include the GRE Key option in any subsequent Proxy Binding Update 390 message that is sent to that LMA. 392 o If the mobile access gateway sent a Proxy Binding Update message 393 without the GRE Key option, but the received Proxy Binding 394 Acknowledgement has the Status Code , 395 indicating that the GRE encapsulation and GRE key is required, the 396 mobile access gateway SHOULD resend the Proxy Binding Update 397 message with the GRE Key option. If the MAG does not support the 398 GRE Key option, the MAG MAY log the event and possibly raise an 399 alarm to indicate a possible misconfiguration. 401 o If the mobile access gateway sent a Proxy Binding Update message 402 with the GRE Key option and the downlink GRE key included and 403 received a successful Proxy Binding Acknowledgement message with a 404 status code , the mobile access 405 gateway MUST consider that GRE encapsulation and GRE keys is not 406 required for this specific mobility binding. The MAG follows 407 procedures in Proxy Mobile IPv6 specification [RFC5213] for the 408 handling of uplink and downlink traffic for this mobility binding 409 and MUST NOT include the GRE Key option in any subsequent Proxy 410 Binding Update message that is sent to the LMA for this mobility 411 session. 413 o If the MAG has successfully negotiated GRE encapsulation and 414 exchanged the GRE keys with the LMA for a specific mobility 415 session, the MAG SHOULD NOT include the GRE Key option in the de- 416 registration Proxy Binding Update. 418 o On receiving a packet from the tunnel with the GRE header, the 419 mobile access gateway MUST use the GRE Key present in the GRE 420 extension header as an additional identifier to determine which 421 mobility session this packet belongs to. The GRE header is 422 removed before further processing takes place. 424 5. Local Mobility Anchor Considerations 426 5.1. Extensions to the Binding Cache Entry 428 When the local mobility anchor and the mobile access gateway 429 successfully negotiate GRE encapsulation and exchange downlink and 430 uplink GRE keys, the local mobility anchor MUST maintain the downlink 431 and uplink GRE keys as part of the mobile node BCE. This requires 432 that the BCE described in section 5.1 of the Proxy Mobile IPv6 433 specification [RFC5213] to be extended. To support this 434 specification, the BCE must be extended with the following three 435 additional fields. 437 o A flag indicating whether GRE encapsulation is enabled for the 438 mobile node's traffic flows. 440 o The downlink GRE Key, assigned by the MAG and used in the GRE 441 encapsulation header of the tunneled payload packet from the local 442 mobility anchor to the mobile access gateway. 444 o The Uplink GRE Key, assigned by the LMA and used in the GRE 445 encapsulation header of the tunneled payload packet from the 446 mobile access gateway to the local mobility anchor. 448 5.2. Operational Summary 450 o If local mobility anchor successfully processes a Proxy Binding 451 Update message with the GRE Key option but the GRE Key Identifier 452 field is omitted for Initial GRE Key exchange, the local mobility 453 anchor MUST include the GRE Key option but omit the GRE Key 454 Identifier field when responding with a successful Proxy Binding 455 Acknowledgement message. 457 o If the local mobility anchor successfully processes a Proxy 458 Binding Update message with the GRE Key option and the downlink 459 GRE key included in the GRE Key Identifier field for Initial GRE 460 Key exchange as in Section 3.3.1, the local mobility anchor MUST 461 include the GRE Key option with the uplink GRE key included in the 462 GRE Key Identifier field when responding with a successful Proxy 463 Binding Acknowledgement message. 465 o If the GRE tunneling is negotiated and the downlink and uplink GRE 466 keys have been exchanged between the mobile access gateway and the 467 local mobility anchor for a specific mobility binding, the local 468 mobility anchor MUST use the negotiated downlink GRE key in the 469 GRE header of every packet that is destined to the mobile node of 470 this specific binding over the GRE tunnel to the mobile access 471 gateway. 473 o If the received Proxy Binding Update message does not contain the 474 GRE Key option, and if the local mobility anchor based on a policy 475 check determines that GRE encapsulation and GRE keys are required, 476 e.g., overlapping IPv4 private addressing is in use, LMA local 477 policy or LMA-MAG peer agreement, the local mobility anchor MUST 478 reject the request and send a Proxy Binding Acknowledgement 479 message to the mobile access gateway with the status code as defined in Section 6.4, indicating that GRE 481 encapsulation and GRE keys are required. 483 o If after receiving and successfully processing a Proxy Binding 484 Update message with the GRE Key option, the local mobility anchor 485 determines based on a policy check that GRE encapsulation and GRE 486 keys are not required for this specific binding, e.g., private 487 IPv4 addressing is not in use, the LMA SHOULD send a successful 488 Proxy Binding Acknowledgement message to the MAG with the status 489 code . In this case, the local 490 mobility anchor MUST NOT include the GRE Key option in the Proxy 491 Binding Acknowledgement. 493 o If the local mobility anchor successfully processes a de- 494 registration Proxy Binding Update message, the LMA follows the 495 same de-registration process as described in Proxy Mobile IPv6 496 specification [RFC5213] to clean the binding cache entry and all 497 associated resources including the downlink and uplink GRE keys. 499 o On receiving a packet from the tunnel with the GRE header, the 500 local mobility anchor MUST use the GRE Key in the GRE extension 501 header as an additional identifier to determine which mobility 502 session this packet belongs to. The GRE header is removed before 503 further processing takes place. 505 6. Message Formats 507 This section defines an extension to the Mobile IPv6 [RFC3775] 508 protocol messages. The use of GRE Key option for supporting GRE 509 tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in 510 this specification. 512 6.1. GRE Key Option 514 A new mobility option, the GRE Key option, is defined for use in the 515 Proxy Binding Update and Proxy Binding Acknowledgment messages 516 exchanged between the mobile access gateway and the local mobility 517 anchor. This option can be used for negotiating GRE encapsulation 518 mode only or GRE encapsulation and exchanging the downlink and uplink 519 GRE keys. These GRE keys can be used by the peers in all GRE 520 encapsulated payload packets for marking that specific mobile node's 521 data traffic. 523 The alignment requirement for this option is 4n. 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Type | Length | Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | GRE Key Identifier | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 2: GRE Key Option 535 Type 537 539 Length 541 8-bit unsigned integer indicating the length in octets of the 542 option, excluding the type and length fields. If the Length field 543 is set to 2, it indicates that the GRE key Identifier field is not 544 being carried in the option. If the length field is set to a 545 value of 6, it means that either the downlink or the uplink GRE 546 key is carried. 548 Reserved 550 These fields are unused. They MUST be initialized to zero by the 551 sender and MUST be ignored by the receiver. 553 GRE Key Identifier 555 32-bit field containing the downlink or the uplink GRE key. This 556 field is present in the GRE Key option only if the GRE keys are 557 being exchanged using the Proxy Binding Update and Proxy Binding 558 Acknowledgement messages. 560 6.2. Proxy Binding Update Message Extension 562 This specification extends the Proxy Binding Update message with one 563 new flag. The flag is shown and described below. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Sequence # | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |A|H|L|K|M|R|P|F|T| Reserved | Lifetime | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Figure 3: Proxy Binding Update message 575 TLV-header Format (T) 577 When set, this flag indicates that the mobile access gateway 578 requests the use of the TLV-header for encapsulating IPv6-or-IPv4 579 in IPv4. The TLV-header format is described later in this 580 specification. 582 6.3. Proxy Binding Acknowledgement Message Extension 584 This specification extends the Proxy Binding Acknowledgement message 585 with a new flag. This new flag is shown and described below. 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Status |K|R|P|T| Res | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Sequence # | Lifetime | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Figure 4: Proxy Binding Acknowledgement Message 597 TLV-header Format (T) 599 When set, this flag indicates that the sender of the Proxy Binding 600 Acknowledgement (LMA) supports tunneling IPv6-or-IPv4 in IPv4 601 using TLV-header format. 603 6.4. Status Codes 605 The following status code values are defined for use in the Binding 606 Acknowledgment message when using Proxy Mobile IPv6. 608 GRE KEY OPTION NOT REQUIRED (TBD less than 128) 610 When the local mobility anchor receives a Proxy Binding Update 611 with the GRE Key option while based on a policy check the LMA 612 determines that the GRE encapsulation is not required for this 613 specific mobility session, the LMA uses this code to indicate to 614 the mobile access gateway that the Proxy Binding Update has been 615 processed successfully but GRE Encapsulation and GRE Key is not 616 required. 618 GRE KEY OPTION REQUIRED (TBD more than 128) 620 When the local mobility anchor receives a Proxy Binding Update 621 without the GRE Key option while based on a policy check the local 622 mobility anchor determines that GRE encapsulation is required for 623 this specific mobility session, the local mobility anchor uses 624 this code to reject the Proxy Binding Update and indicate to the 625 mobile access gateway that GRE Encapsulation and GRE Keys are 626 required. 628 GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED (TBD less than 128) 630 If local mobility anchor receives a Proxy Binding Update with the 631 GRE Key option and TLV-header Format (T) flag set, the local 632 mobility anchor uses this code to indicate to the mobile access 633 gateway that GRE Encapsulation has successfully been negotiated 634 but TLV-header format is NOT supported. 636 7. Data Packets Processing Considerations 638 This section describes how the local mobility anchor and mobile 639 access gateway encapsulate and decapsulate data packets when GRE 640 encapsulation and GRE Keys are used for tunneling mobile nodes data 641 traffic between these two mobility nodes. 643 7.1. Tunneling Format 645 When GRE encapsulation mode only or GRE encapsulation and GRE keys 646 have been negotiated between the mobile access gateway and the local 647 mobility anchor for a specific mobility session, the mobile access 648 gateway is allowed to use various tunneling formats depending on the 649 mobile access gateway location and the networks's capabilities 650 between the MAG and the LMA. While using GRE encapsulation, the 651 mobile access gateway can tunnel IPv6-or-IPv4 in IPv6 and IPv6-or- 652 IPv4 in IPv4 using vanilla GRE tunneling based on what described in 653 [RFC5213] and [ID-PMIP6-IPv4], or use UDP-based encapsulation to 654 tunnel IPv6-or-IPv4 in IPv4. 656 If UDP-based tunneling is used between the mobile access gateway and 657 the local mobility anchor after NAT has been detected in the path 658 between the MAG and the LMA while GRE encapsulation is required, the 659 TLV-header UDP tunneling format as shown in Figure 5 and described in 660 this specification MUST be used. 662 [IPv4 Header] 664 [UDP Header] 666 [TLV Header] 668 [GRE Header] 670 [payload - IPv6-or-IPv4 Header] 672 Upper Layer protocols 674 Figure 5: TLV-header UDP Based Encapsulation Headers Order 676 When UDP based tunneling format is used between the mobile access 677 gateway and the local mobility anchor, the use of the TLV-header is 678 negotiated during the Proxy Binding Update/Acknowledgement exchange 679 as described in Section 7.3 and Section 7.4. If the TLV-header 680 format is agreed upon between the mobile access gateway and local 681 mobility anchor, the LMA expects the TLV-header to follow the UDP 682 header as shown in Figure 5. The TLV header contains the type of the 683 following payload packet and its length. The Type field in the TLV- 684 header is limited to the values of 0 and 1 to ensure that the 685 receiver can differentiate whether what after the UDP header is a 686 TLV-header Type field or an IP version field of an IP header. Hence, 687 the TLV-header can carry traffic other than IP. The distinction 688 between IP and TLV encapsulation is needed, because the Proxy Binding 689 Update (IP Packet) and the data packets (GRE packets) can be sent 690 over the same UDP tunnel. 692 7.2. TLV-header Tunneling Negotiation 694 The mobile access gateway negotiates the format for tunneling payload 695 traffic during Proxy Mobile IPv6 registration procedure. If the 696 mobile access gateway is required to use the TLV-header UDP 697 encapsulation format, the mobile access gateway MUST set the TLV- 698 header Format (T) flag in the Proxy Binding Update message sent to 699 the local mobility anchor. If the local mobility anchor supports the 700 TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header 701 Format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the 702 TLV-header Format (T) flag is cleared. The setting of the TLV-header 703 Format (T) flag in the Proxy Binding Acknowledgement indicates to the 704 mobile access gateway that it MUST use the TLV-header UDP 705 encapsulation format for all packets tunneled to the LMA for the 706 entire duration the mobile node is attached to the mobile access 707 gateway. The TLV-header UDP tunneling format SHOULD NOT change 708 during a Binding Lifetime Extension Proxy Binding Update (re- 709 registration) from the same mobile access gateway. 711 Any Proxy Binding Update message triggered by a handoff (Section 712 5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore, 713 in order to avoid interoperability issues, the local mobility anchor 714 MUST NOT set the TLV-header Format (T) flag unless it was set in the 715 Proxy Binding Update received from the mobile access gateway. 717 The TLV-header format is as shown below in Figure 6. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Type | Length | Reserved | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 Figure 6: TLV-header Format 727 Type 729 4-bit unsigned integer indicates the type of the payload following 730 this header. The following are the only defined values as per 731 this specification. 733 0 Reserved 734 1 Generic Routing Encapsulation (GRE) [RFC2784] 736 Length 738 16-bit unsigned integer indicating the length in octets of the 739 payload following this header, excluding the TLV-header itself. 741 Reserved 743 These fields are unused. They MUST be initialized to zero by the 744 sender and MUST be ignored by the receiver. 746 7.3. Mobile Access Gateway Operation 748 When sending an IPv6 packet containing a Proxy Binding Update while 749 the network between the mobile access gateway and local mobility 750 anchor is an IPv4-only network, the mobile access gateway follows the 751 procedures specified in [ID-PMIP6-IPv4] and [ID-DSMIP6] if vanilla 752 UDP encapsulation format is used. However, if GRE encapsulation is 753 required and UDP based encapsulation is used, the mobile access 754 gateway MUST set the TLV-header Format (T) flag in the Proxy Binding 755 Update and follow this specification for GRE encapsulation 756 negotiation. If the received Proxy Binding Acknowledgement is 757 successful and the TLV-header Format (T) flag set and the GRE Key 758 option included, the MAG MUST use the TLV-header UDP based 759 encapsulation format as shown in Figure 5. 761 If the mobile access gateway sent a Proxy Binding Update with the GRE 762 key option included and the TLV-header Format (T) flag set and 763 received a successful Proxy Binding Acknowledgement with the GRE key 764 option included, the TLV-header Format (T) flag cleared, and the 765 status code , the mobile 766 access gateway MUST NOT use GRE encapsulation for this mobility 767 session with UDP-based tunneling. The mobile access gateway may 768 resend the Proxy Binding Update to negotiate different tunneling 769 options, e.g., using UDP based tunneling without GRE encapsulation if 770 possible or de-register the the mobile node mobility session. 772 7.3.1. Sending and Receiving Data Packets 774 When the mobile access gateway is located in an IPv6-enabled network, 775 the mobile access gateway encapsulates and decapsulates IPv6 packets 776 as described in [RFC5213]. In this case, IPv4 payload traffic is 777 encapsulated in IPv6 packets before being sent to the local mobility 778 anchor as described in [ID-PMIP6-IPv4]. In addition, if the mobile 779 access gateway is located in an IPv4-only network and no UDP 780 tunneling format is used, the mobile access gateway encapsulates and 781 decapsulates IPv4 packets as described in [ID-PMIP6-IPv4]. IPv6 782 traffic is encapsulated in IPv4 packets following the procedure in 783 [ID-PMIP6-IPv4] before being sent to the local mobility anchor. 785 If the mobile access gateway have successfully negotiated GRE 786 encapsulation mode only or GRE encapsulation and GRE Keys as 787 described in this specification for any of the above cases, the 788 mobile access gateway encapsulates or decapsulates data packets 789 following the same procedure while ensuring that the GRE header is 790 present as shown in Figure 7. 792 [IPv6-or-IPv4 Header] 794 [GRE Header] 796 [payload - IPv6-or-IPv4 Header] 798 Upper Layer protocols 800 Figure 7: IPv6-or-IPv4 over IPv4 Using Vanilla GRE Encapsulation 802 On the other hand, if the mobile access gateway is located in an 803 IPv4-only network where NAT has been detected on the path between the 804 MAG and the LMA and successfully negotiated GRE encapsulation and the 805 TLV-header format, the mobile access gateway MUST use UDP TLV-header 806 tunneling format when sending an IPv6 or IPv4 payload packet to the 807 LMA according to the format described in Figure 8. 809 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 811 [UDP Header] 813 [TLV Header] 815 [GRE Header] 817 IPv6/v4 header (src=V6/V4HoA, dst=V6/V4CN) 819 Upper Layer protocols 821 Figure 8: IPv6-or-IPv4 over IPv4 Using TLV-header UDP Tunneling 823 7.4. Local Mobility Anchor Operation 825 When the local mobility anchor receives a Proxy Binding Update 826 encapsulated in UDP and containing the IPv4 home address option, it 827 needs to follow all the steps in [RFC5213] and [ID-PMIP6-IPv4]. In 828 addition, if the TLV-header Format (T) flag is set in the Proxy 829 Binding Update, the local mobility anchor needs to determine whether 830 it can accept the TLV-header UDP based encapsulation format. If it 831 does, it SHOULD set the TLV-header Format (T) flag in the Proxy 832 Binding Acknowledgement. Otherwise, the LMA MUST NOT set the TLV- 833 header Format (T) flag in the Proxy Binding Acknowledgement. 835 If the local mobility anchor receives a Proxy Binding Update with the 836 GRE Key option and TLV-header Format (T) flag set and based on a 837 policy check, the local mobility anchor determines that GRE 838 encapsulation is required BUT the LMA does NOT support TLV-header 839 tunneling and if Proxy Binding Update has been successfully 840 processed, the LMA MUST send a successful Proxy Binding 841 Acknowledgement with the status code . This way, the local mobility anchor indicates to the 843 mobile access gateway that GRE encapsulation has been successfully 844 negotiated BUT TLV-header UDP based tunneling format is not 845 supported. 847 If the local mobility anchor and the mobile access gateway have 848 successfully negotiated the TLV-header UDP based tunneling format and 849 the GRE encapsulation for a specific mobility session, the local 850 mobility anchor processes data packets as described in the following 851 subsection. 853 7.4.1. Sending and Receiving Data Packets 855 The local mobility anchor follows the rules specified in [RFC5213] 856 for sending IPv6 payload packets to mobile nodes located in IPv6 857 network through the mobile access gateway. When sending IPv4 858 packets, destined to a mobile node, to the mobile access gateway that 859 is in an IPv6 network, the local mobility anchor encapsulates the 860 IPv4 packets in IPv6 following the rules as described in 861 [ID-PMIP6-IPv4]. Similarly, when sending IPv6 packets, destined to a 862 mobile node, to the mobile access gateway that is located in an IPv4 863 network, the local mobility anchor follows the format negotiated in 864 the Proxy Binding Update/Acknowledgement exchange as described in 865 [ID-PMIP6-IPv4]. 867 In the case when TLV-tunneling format and the GRE encapsulation for a 868 specific mobility session have been successfully negotiated between 869 the local mobility anchor and the mobile access gateway, the local 870 mobility anchor follows the TLV-header UDP based headers tunneling 871 order as shown in Figure 8 to encapsulate IPv4 or IPv6 payload 872 packets in IPv4 before sending the IPv4 packet to the mobile access 873 gateway. On the other hand, the local mobility anchor follows the 874 same TLV-header UDP based headers order when it decapsulates received 875 IPv4 packets from the mobile access gateway for the same mobility 876 session. 878 7.5. Mobile Node Operation 880 This specification has no impact on IPv4 or IPv6 mobile nodes. 882 8. IANA Considerations 884 This specification defines a new Mobility Option, the GRE Key Option, 885 described in Section 6.1. This option is carried in the Mobility 886 Header. The type value for this option needs to be assigned from the 887 same numbering space as allocated for the other mobility options 888 defined in the Mobile IPv6 specification [RFC3775]. 890 This specification also defines three new Binding Acknowledgement 891 status codes as described in Section 6.4 and requests that these 892 three codes be allocated with numeric values as specified in 893 Section 6.4 from the "Status Codes" registry of the Mobility IPv6 894 Parameters located at 895 http://www.iana.org/assignments/mobility-parameters. 897 9. Security Considerations 899 The GRE Key Option, defined in this specification, that can be 900 carried in Proxy Binding Update and Proxy Binding Acknowledgement 901 messages, reveals the group affiliation of a mobile node identified 902 by its NAI or an IP address. It may help an attacker in targeting 903 flows belonging to a specific group. This vulnerability can be 904 prevented, by enabling confidentiality protection on the Proxy 905 Binding Update and Proxy Binding Acknowledgement messages where the 906 presence of the NAI and GRE Key Options establish a mobile node's 907 relation to a specific group. This vulnerability can also be avoided 908 by enabling confidentiality protection on all the tunneled data 909 packets between the mobile access gateway and the local mobility 910 anchor, for hiding all the markings. 912 In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for 913 protecting a mobile node's data traffic is optional. Additionally, 914 Proxy Mobile IPv6 recommends the use of ESP in tunnel mode when using 915 ESP in protecting the mobile node's data traffic. However, when GRE 916 encapsulation is used, both IPsec tunnel mode and transport mode can 917 be used to protect the GRE header. The IPsec traffic selectors will 918 contain the protocol number for GRE, and there is currently no 919 mechanism to use the GRE key as a traffic selector. 921 10. Acknowledgements 923 The authors would like to thank Alessio Casati, Barney Barnowski, 924 Mark Grayson and Parviz Yegani for their input on the need for this 925 option. The authors would like to thank Charlie Perkins, Curtis 926 Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal 927 Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review 928 and comments. 930 11. References 932 11.1. Normative References 934 [ID-DSMIP6] 935 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 936 Routers", draft-ietf-mext-nemo-v4traversal-07 (work in 937 progress), December 2008. 939 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 940 "Multiple Care-of Addresses Registration", 941 draft-ietf-monami6-multiplecoa-11 (work in progress), 942 January 2009. 944 [ID-PMIP6-IPv4] 945 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 946 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 947 (work in progress), January 2009. 949 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 950 E. Lear, "Address Allocation for Private Internets", 951 BCP 5, RFC 1918, February 1996. 953 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 954 October 1996. 956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 957 Requirement Levels", BCP 14, RFC 2119, March 1997. 959 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 960 IPv6 Specification", RFC 2473, December 1998. 962 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 963 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 964 March 2000. 966 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 967 RFC 2890, September 2000. 969 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 970 in IPv6", RFC 3775, June 2004. 972 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 973 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 975 11.2. Informative References 977 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 978 Internet Protocol", RFC 4301, December 2005. 980 Authors' Addresses 982 Ahmad Muhanna 983 Nortel 984 2221 Lakeside Blvd. 985 Richardson, TX 75082 986 USA 988 Email: amuhanna@nortel.com 989 Mohamed Khalil 990 Nortel 991 2221 Lakeside Blvd. 992 Richardson, TX 75082 993 USA 995 Email: mkhalil@nortel.com 997 Sri Gundavelli 998 Cisco Systems 999 170 West Tasman Drive 1000 San Jose, CA 95134 1001 USA 1003 Email: sgundave@cisco.com 1005 Kent Leung 1006 Cisco Systems 1007 170 West Tasman Drive 1008 San Jose, CA 95134 1009 USA 1011 Email: kleung@cisco.com