idnits 2.17.1 draft-ietf-netlmm-grekey-option-09.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (May 6, 2009) is 5467 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-12 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-13 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: November 7, 2009 S. Gundavelli 6 K. Leung 7 Cisco Systems 8 May 6, 2009 10 GRE Key Option for Proxy Mobile IPv6 11 draft-ietf-netlmm-grekey-option-09.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 November 7, 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 in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This specification defines a new Mobility Option for allowing the 50 mobile access gateway and the local mobility anchor to negotiate GRE 51 (Generic Routing Encapsulation) encapsulation mode and exchange the 52 downlink and uplink GRE keys which are used for marking the downlink 53 and uplink traffic that belong to a specific mobility session. In 54 addition, the same mobility option can be used to negotiate the GRE 55 encapsulation mode without exchanging the GRE keys. 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 Keys Exchange . . . . . . . . . . . . . 4 64 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4 65 3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 6 66 3.3. GRE Encapsulation and Keys Exchange . . . . . . . . . . . 6 67 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6 68 3.3.2. GRE Key Exchange During Binding Re-registration . . . 7 69 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 8 70 4.1. Extensions to the Conceptual Data Structure . . . . . . . 8 71 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9 72 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 10 73 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 10 74 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11 75 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 12 77 6.2. Proxy Binding Update Message Extension . . . . . . . . . . 13 78 6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14 79 6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 15 80 7. Data Packets Processing Considerations . . . . . . . . . . . . 15 81 7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 16 82 7.2. TLV-header Tunneling Negotiation . . . . . . . . . . . . . 17 83 7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18 84 7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 19 85 7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 20 86 7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 21 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 95 1. Introduction 97 Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile IPv6 98 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 99 encapsulation modes as specified in [RFC2473] and [RFC2003] for the 100 tunneled traffic between the local mobility anchor (LMA) and the 101 mobile access gateway (MAG). There are scenarios where these 102 encapsulation modes are not sufficient to uniquely identify the 103 destination of packets of a specific mobility session. Thus, there 104 is a need for an encapsulation mode with richer semantics. The 105 Generic Routing Encapsulation (GRE) [RFC2784] and the Key extension 106 as defined in [RFC2890], has the required semantics to allow such 107 distinction for use in Proxy Mobile IPv6. 109 This specification defines the GRE Key option to be used for the 110 negotiation of GRE encapsulation mode and exchange of the uplink and 111 downlink GRE keys. The negotiated downlink and uplink GRE keys can 112 be used for marking the downlink and uplink traffic for a specific 113 mobility session. In addition, this specification enables the mobile 114 access gateway and the local mobility anchor to negotiate the use of 115 GRE encapsulation mode without exchanging the GRE keys. 117 This specification has no impact on IPv4 or IPv6 mobile nodes. 119 2. Conventions & Terminology 121 2.1. Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 specification are to be interpreted as described in RFC 2119 126 [RFC2119]. 128 2.2. Terminology 130 All the general mobility related terminology and abbreviations are to 131 be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile 132 IPv6 [RFC5213] specifications. The following terms are used in this 133 specification. 135 Downlink Traffic 137 The traffic in the tunnel between the local mobility anchor and 138 the mobile access gateway, heading towards the mobile access 139 gateway and tunneled at the local mobility anchor. This traffic 140 is also called forward direction traffic. 142 Uplink Traffic 144 The traffic in the tunnel between the mobile access gateway and 145 the local mobility anchor, heading towards the local mobility 146 anchor and tunneled at the mobile access gateway. This traffic is 147 also called reverse direction traffic. 149 Downlink GRE Key 151 The GRE key is assigned by the mobile access gateway and used by 152 the local mobility anchor to mark the downlink traffic which 153 belongs to a specific mobility session as described in this 154 specification. 156 Uplink GRE Key 158 The GRE key is assigned by the local mobility anchor and used by 159 the mobile access gateway to mark the uplink traffic which belongs 160 to a specific mobility session as described in this specification. 162 A Policy Check 164 When local mobility anchor receives an initial, handoff-triggered 165 Binding Lifetime Extension, or Binding Lifetime Extension Proxy 166 Binding Update for a mobility session, the local mobility anchor 167 determines if the GRE encapsulation mode only or GRE encapsulation 168 and GRE keys are required based on a policy check. This policy 169 could be a per MAG-LMA pair, a per-LMA local policy, a per-MN 170 policy, or the combination of any of them. 172 3. GRE Encapsulation and Keys Exchange 174 This section describes how GRE encapsulation mode is negotiated and 175 the GRE keys are dynamically exchanged while using Proxy Mobile IPv6 176 protocol [RFC5213] signaling. 178 3.1. GRE Encapsulation Overview 180 Using the GRE Key option defined in this specification, the mobile 181 access gateway and the local mobility anchor can negotiate GRE 182 encapsulation mode only or GRE encapsulation mode and exchange the 183 GRE keys for marking the downlink and uplink traffics. In the case 184 when GRE encapsulation mode only is negotiated between the mobile 185 access gateway and the local mobility anchor, then no GRE keys are 186 used. 188 However, once the GRE keys have been exchanged between the mobile 189 access gateway and the local mobility anchor as per this 190 specification, the mobile access gateway will use the uplink GRE key 191 that is assigned by the local mobility anchor in the GRE header of 192 the uplink payload packet. Similarly, the local mobility anchor will 193 use the downlink GRE key as negotiated with the mobile access gateway 194 in the GRE header of the downlink payload packet. 196 The following illustration explains the use of GRE encapsulation mode 197 and the GRE keys for supporting the usecase where overlapping IPv4 198 private address [RFC1918] allocation is in use. 200 +------------+ 201 | Operator-A | 202 | | 203 | 10.x.0.0/16| 204 +------------+ 205 / 206 +------+ +------+ / 207 | | ========================== | | / 208 MN-1---| | / \ | | / Key-1 209 | M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic 210 MN-2---| A |--| |--| M |- 211 | G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2 212 MN-3---| | \ / | | \Traffic 213 | | ========================== | | \ 214 MN-4---| | Proxy Mobile IPv6 Tunnel | | \ 215 +------+ +------+ \ 216 \ 217 Operator-C: Access Network +------------+ 218 | Operator-B | 219 | | 220 | 10.x.0.0/16| 221 +------------+ 223 Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping 225 Figure 1 illustrates a local mobility anchor providing mobility 226 service to mobile nodes that are from different operators and are 227 assigned IPv4 addresses from overlapping private address space. In 228 this scenario, the mobile access gateway and the local mobility 229 anchor must be able to distinguish the flows belonging to a given 230 operator from the flows belonging to some other operator. 232 The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and 233 mobile nodes, MN-3 and MN-4 are visiting from Operator-B. The mobile 234 access gateway and the local mobility anchor exchange a specific pair 235 of downlink and uplink GRE keys and save them as part of the mobile 236 node binding to be used for identifying the flows belonging to each 237 mobile node. 239 The LMA and the MAG will be able to distinguish each mobile node 240 flow(s) based on the GRE key present in the GRE header of the 241 tunneled payload packet, and route them accordingly. However, the 242 GRE keys as in this specification apply to the individual mobility 243 binding updated by the Proxy Binding Update but not to all bindings 244 that the mobile may have registered following procedures described in 245 [ID-MCoA]. 247 3.2. GRE Encapsulation Mode Only 249 In order for the mobile access gateway to request GRE encapsulation 250 mode only without exchanging the GRE keys, the mobile access gateway 251 MUST include the GRE Key option but omit the GRE Key Identifier field 252 in the Proxy Binding Update. 254 If the local mobility anchor supports GRE encapsulation and the 255 received Proxy Binding Update contains the GRE Key option but the GRE 256 Key Identifier field is omitted, the mobile access gateway is 257 requesting GRE encapsulation without exchanging the GRE keys 258 dynamically. If the Proxy Binding Update processing is successful, 259 the local mobility anchor sends a successful Proxy Binding 260 Acknowledgement message with the GRE Key option but the GRE Key 261 Identifier field is omitted. 263 When the mobile access gateway and the local mobility anchor 264 successfully negotiate the GRE encapsulation mode only, then no GRE 265 keys are used. 267 3.3. GRE Encapsulation and Keys Exchange 269 The following subsections describe how the mobile access gateway and 270 the local mobility anchor negotiate GRE encapsulation and exchange 271 downlink and uplink GRE keys using proxy mobile IPv6 registration 272 procedure. 274 3.3.1. Initial GRE Key Exchange 276 When the mobile access gateway determines, based on, e.g., private 277 IPv4 address support [RFC1918], the mobile access gateway local 278 policy, or the MAG-LMA peer agreement, that GRE encapsulation is 279 needed and GRE keys are required, the mobile access gateway MUST 280 include the GRE Key option in the initial Proxy Binding Update 281 message sent to the local mobility anchor. The mobile access gateway 282 MUST include the downlink GRE key in the GRE Key Identifier field of 283 the GRE Key option. 285 After the local mobility anchor successfully processes the initial 286 Proxy Binding Update and accepts the GRE encapsulation request and 287 the downlink GRE key based on a policy check, the local mobility 288 anchor MUST include the GRE Key option with the uplink GRE key in the 289 GRE Key Identifier field in a successful Proxy Binding 290 Acknowledgement and send it to the mobile access gateway. 292 3.3.2. GRE Key Exchange During Binding Re-registration 294 If the local mobility anchor has successfully negotiated and 295 exchanged the initial GRE keys with the mobile access gateway for a 296 specific mobile node binding, the local mobility anchor MUST maintain 297 the same negotiated uplink GRE key for the lifetime of the mobility 298 session. However, for administrative reasons, e.g., local mobility 299 anchor reboot, the local mobility anchor MAY change the uplink GRE 300 key for the mobility session. In that case, some packet loss may be 301 experienced. 303 If the mobile access gateway has successfully negotiated and 304 exchanged the initial GRE keys with the local mobility anchor for a 305 specific mobile node binding, the mobile access gateway MUST include 306 the GRE Key option with the downlink GRE key in the Proxy Binding 307 Update which is used for requesting a Binding Lifetime Extension. In 308 this case, if the local mobility anchor successfully processes the 309 Proxy Binding Update message, the local mobility anchor MUST return 310 the same uplink GRE key that was exchanged with the mobile access 311 gateway in the last successful Proxy Binding Update for the same 312 mobility session in the GRE key option in a successful Proxy Binding 313 Acknowledgement message. 315 However, during inter-MAG handoff and if the new mobile access 316 gateway determines, based on, e.g., private IPv4 address support, the 317 mobile access gateway local policy, the MAG-LMA peer agreement, or an 318 indication during the handoff process, that GRE encapsulation and GRE 319 keys exchange are required, the new mobile access gateway MUST 320 include the GRE key option with the downlink GRE key in the Proxy 321 Binding Update which is used for requesting an after handoff Binding 322 Lifetime extension. In this case, the new mobile access gateway may 323 either pick a new downlink GRE key or use the downlink GRE key that 324 was used by the previous mobile access gateway for the same binding. 325 For the new mobile access gateway to know the downlink GRE key used 326 by the previous mobile access gateway, it may require transfer of 327 context from the previous mobile access gateway to the new mobile 328 access gateway during a handoff. Such mechanisms are out-of-scope 329 for this specification. 331 If the local mobility anchor successfully processes a handoff- 332 triggered Binding Lifetime Extension Proxy Binding Update message 333 which contains a GRE key option with a downlink GRE key included, the 334 local mobility anchor MUST return the same uplink GRE key that was 335 exchanged with the previous mobile access gateway for the same 336 mobility session in the GRE key option in a successful Proxy Binding 337 Acknowledgement. 339 If the local mobility anchor receives a handoff-triggered Binding 340 Lifetime Extension Proxy Binding Update message without the GRE key 341 option for a Binding Cache Entry (BCE) that is using GRE keys and GRE 342 encapsulation, the local mobility anchor makes a policy check 343 regarding GRE encapsulation and GRE keys exchange. If, according to 344 the policy check, GRE encapsulation and GRE Keys exchange are 345 required, the local mobility anchor MUST reject the Proxy Binding 346 Update by sending a Proxy Binding Acknowledgement message with the 347 status field is set to as defined in 348 Section 6.4. Otherwise, the local mobility anchor SHOULD accept the 349 Proxy Binding Update and if it is processed successfully, the local 350 mobility anchor MUST return a successful Proxy Binding 351 Acknowledgement without including the GRE Key option. 353 4. Mobile Access Gateway Considerations 355 4.1. Extensions to the Conceptual Data Structure 357 Every mobile access gateway maintains a Binding Update List (BUL) 358 entry for each currently attached mobile node, as explained in 359 Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To 360 support this specification, the conceptual Binding Update List entry 361 data structure must be extended with the following three new 362 additional fields. 364 o A flag indicating whether GRE encapsulation is enabled for the 365 mobile node's traffic. 367 o The downlink GRE key used in the GRE encapsulation header of the 368 tunneled payload packet from the local mobility anchor to the 369 mobile access gateway that is destined to the mobile node. This 370 GRE key is generated by the mobile access gateway and communicated 371 to the local mobility anchor in the GRE Key option in the Proxy 372 Binding Update message. 374 o The uplink GRE key used in the GRE encapsulation header of the 375 tunneled payload packet from the mobile access gateway to the 376 local mobility anchor that is originating from the mobile node. 377 This GRE key is obtained from the GRE Key Identifier field of the 378 GRE Key option present in the received Proxy Binding 379 Acknowledgement message sent by the local mobility anchor as 380 specified in this specification. 382 o A flag indicating whether UDP based TLV-Header format Section 7.2 383 is enabled for the mobile node's traffic. This flag is TRUE only 384 when UDP tunneling as in [ID-PMIP6-IPv4] and GRE Encapsulation as 385 in this specification are both enabled for this mobility session. 387 4.2. Operational Summary 389 o If the mobile access gateway determines that GRE encapsulation 390 mode only is required, the mobile access gateway MUST include the 391 GRE Key option but omit the GRE Key Identifier field in the Proxy 392 Binding Update message that is sent to the local mobility anchor. 394 o If the mobile access gateway determines that GRE encapsulation and 395 GRE keys are required, the mobile access gateway MUST include the 396 GRE Key option with the downlink GRE key in the GRE Key Identifier 397 field in the Proxy Binding Update message that is sent to the 398 local mobility anchor. 400 o After receiving a successful Proxy Binding Acknowledgment message 401 with the GRE Key option with the GRE Key Identifier field omitted, 402 the mobile access gateway MUST update the mobile node Binding 403 Update List entry described in Section 4.1 by only setting the GRE 404 encapsulation enabled flag. 406 o After receiving a successful Proxy Binding Acknowledgment message 407 with the GRE Key option and the uplink GRE key included in the GRE 408 Key Identifier field, the mobile access gateway MUST update the 409 related three fields in the mobile node Binding Update List entry 410 described in Section 4.1. Additionally, the mobile access gateway 411 MUST use the assigned uplink GRE Key for tunneling all the traffic 412 that belong to this mobile node BUL entry and is originated from 413 the mobile node before forwarding the tunneled traffic to the 414 local mobility anchor. 416 o If the mobile access gateway includes the GRE Key option in the 417 Proxy Binding Update for a specific mobile node and the local 418 mobility anchor accepts the Proxy Binding Update by sending a 419 Proxy Binding Acknowledgement with a success status code (less 420 than 128) other than , but without 421 the GRE Key option, then the mobile access gateway MUST consider 422 that the local mobility anchor does not support GRE Key option as 423 per this specification. The mobile access gateway SHOULD NOT 424 include the GRE Key option in any subsequent Proxy Binding Update 425 message that is sent to that local mobility anchor. 427 o If the mobile access gateway sent a Proxy Binding Update message 428 without the GRE Key option, but the received Proxy Binding 429 Acknowledgement has the Status Code , 430 indicating that the GRE encapsulation and GRE key is required, the 431 mobile access gateway SHOULD resend the Proxy Binding Update 432 message with the GRE Key option. If the mobile access gateway 433 does not support the GRE Key option, it MAY log the event and 434 possibly raise an alarm to indicate a possible misconfiguration. 436 o If the mobile access gateway sent a Proxy Binding Update message 437 with the GRE Key option and the downlink GRE key included and 438 received a successful Proxy Binding Acknowledgement message with a 439 status code , the mobile access 440 gateway MUST consider that GRE encapsulation and GRE keys is not 441 required for this specific mobility session. The mobile access 442 gateway follows procedures in Proxy Mobile IPv6 specification 443 [RFC5213] for the handling of uplink and downlink traffic and MUST 444 NOT include the GRE Key option in any subsequent Proxy Binding 445 Update message that is sent to the local mobility anchor for this 446 mobility session. 448 o If the mobile access gateway has successfully negotiated GRE 449 encapsulation and exchanged the GRE keys with the local mobility 450 anchor for a specific mobility session, the mobile access gateway 451 SHOULD NOT include the GRE Key option in the de-registration Proxy 452 Binding Update. 454 o On receiving a packet from the tunnel with the GRE header, the 455 mobile access gateway MUST use the GRE Key present in the GRE 456 extension header as an additional identifier to determine which 457 mobility session this packet belongs to. The GRE header is 458 removed before further processing takes place. 460 5. Local Mobility Anchor Considerations 462 5.1. Extensions to the Binding Cache Entry 464 When the local mobility anchor and the mobile access gateway 465 successfully negotiate GRE encapsulation and exchange downlink and 466 uplink GRE keys, the local mobility anchor MUST maintain the downlink 467 and uplink GRE keys as part of the mobile node's BCE. This requires 468 that the BCE described in section 5.1 of the Proxy Mobile IPv6 469 specification [RFC5213] to be extended. To support this 470 specification, the BCE must be extended with the following three 471 additional fields. 473 o A flag indicating whether GRE encapsulation is enabled for the 474 mobile node's traffic flows. 476 o The downlink GRE Key, assigned by the mobile access gateway and 477 used in the GRE encapsulation header of the tunneled payload 478 packet from the local mobility anchor to the mobile access 479 gateway. 481 o The Uplink GRE Key, assigned by the local mobility anchor and used 482 in the GRE encapsulation header of the tunneled payload packet 483 from the mobile access gateway to the local mobility anchor. 485 o A flag indicating whether UDP based TLV-Header format Section 7.2 486 is enabled for the mobile node's traffic. This flag is TRUE only 487 when UDP tunneling as in [ID-PMIP6-IPv4] and GRE Encapsulation as 488 in this specification are both enabled for this mobility session. 490 5.2. Operational Summary 492 o If local mobility anchor successfully processes a Proxy Binding 493 Update message with the GRE Key option but the GRE Key Identifier 494 field is omitted for Initial GRE Key exchange, the local mobility 495 anchor MUST include the GRE Key option but omit the GRE Key 496 Identifier field when responding with a successful Proxy Binding 497 Acknowledgement message. 499 o If the local mobility anchor successfully processes a Proxy 500 Binding Update message with the GRE Key option and the downlink 501 GRE key included in the GRE Key Identifier field for Initial GRE 502 Key exchange as in Section 3.3.1, the local mobility anchor MUST 503 include the GRE Key option with the uplink GRE key included in the 504 GRE Key Identifier field when responding with a successful Proxy 505 Binding Acknowledgement message. 507 o If the GRE tunneling is negotiated and the downlink and uplink GRE 508 keys have been exchanged between the mobile access gateway and the 509 local mobility anchor for a specific mobility session, the local 510 mobility anchor MUST use the negotiated downlink GRE key in the 511 GRE header of every packet that is destined to the mobile node of 512 this specific mobility session over the GRE tunnel to the mobile 513 access gateway. 515 o If the received Proxy Binding Update message does not contain the 516 GRE Key option, and if the local mobility anchor based on a policy 517 check determines that GRE encapsulation and GRE keys are required, 518 e.g., overlapping IPv4 private addressing is in use, local 519 mobility anchor local policy or LMA-MAG peer agreement, the local 520 mobility anchor MUST reject the request and send a Proxy Binding 521 Acknowledgement message to the mobile access gateway with the 522 status code as defined in Section 6.4, 523 indicating that GRE encapsulation and GRE keys are required. 525 o If after receiving and successfully processing a Proxy Binding 526 Update message with the GRE Key option, the local mobility anchor 527 determines based on a policy check that GRE encapsulation and GRE 528 keys are not required for this specific binding, e.g., private 529 IPv4 addressing is not in use, the local mobility anchor SHOULD 530 send a successful Proxy Binding Acknowledgement message to the 531 mobile access gateway with the status code . In this case, the local mobility anchor MUST NOT 533 include the GRE Key option in the Proxy Binding Acknowledgement. 535 o If the local mobility anchor successfully processes a de- 536 registration Proxy Binding Update message, the local mobility 537 anchor follows the same de-registration process as described in 538 Proxy Mobile IPv6 specification [RFC5213] to clean the binding 539 cache entry and all associated resources including the downlink 540 and uplink GRE keys. 542 o On receiving a packet from the tunnel with the GRE header, the 543 local mobility anchor MUST use the GRE Key in the GRE extension 544 header as an additional identifier to determine which mobility 545 session this packet belongs to. The GRE header is removed before 546 further processing takes place. 548 6. Message Formats 550 This section defines an extension to the Mobile IPv6 [RFC3775] 551 protocol messages. The use of GRE Key option for supporting GRE 552 tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in 553 this specification. 555 6.1. GRE Key Option 557 A new mobility option, the GRE Key option, is defined for use in the 558 Proxy Binding Update and Proxy Binding Acknowledgment messages 559 exchanged between the mobile access gateway and the local mobility 560 anchor. This option can be used for negotiating GRE encapsulation 561 mode only or GRE encapsulation and exchanging the downlink and uplink 562 GRE keys. These GRE keys can be used by the peers in all GRE 563 encapsulated payload packets for marking that specific mobile node's 564 data traffic. 566 The alignment requirement for this option is 4n. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type | Length | Reserved | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | GRE Key Identifier | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 2: GRE Key Option 578 Type 580 582 Length 584 8-bit unsigned integer indicating the length in octets of the 585 option, excluding the type and length fields. If the Length field 586 is set to 2, it indicates that the GRE key Identifier field is not 587 being carried in the option. If the length field is set to a 588 value of 6, it means that either the downlink or the uplink GRE 589 key is carried. 591 Reserved 593 These fields are unused. They MUST be initialized to zero by the 594 sender and MUST be ignored by the receiver. 596 GRE Key Identifier 598 32-bit field containing the downlink or the uplink GRE key. This 599 field is present in the GRE Key option only if the GRE keys are 600 being exchanged using the Proxy Binding Update and Proxy Binding 601 Acknowledgement messages. 603 6.2. Proxy Binding Update Message Extension 605 This specification extends the Proxy Binding Update message as 606 defined in [RFC5213] with the new TLV-Header format (T) flag. The 607 new (T) flag is described below and shown as part of the Proxy 608 Binding Update message as in Figure 3. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Sequence # | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 |A|H|L|K|M|R|P|F|T| Reserved | Lifetime | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Figure 3: Proxy Binding Update message 620 TLV-header Format (T) 622 When set, this flag indicates that the mobile access gateway 623 requests the use of the TLV-header for encapsulating IPv6-or-IPv4 624 in IPv4. The TLV-header format is described later in this 625 specification. None of the other fields or flags in the Proxy 626 Binding Update is modified by this specification. 628 6.3. Proxy Binding Acknowledgement Message Extension 630 This specification extends the Proxy Binding Acknowledgement message 631 as defined in [RFC5213] with the new TLV-Header format (T) flag. The 632 new (T) flag is described below and shown as part of the Proxy 633 Binding Acknowledgement message as in Figure 4. 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Status |K|R|P|T| Res | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Sequence # | Lifetime | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Figure 4: Proxy Binding Acknowledgement Message 645 TLV-header Format (T) 647 When set, this flag indicates that the sender of the Proxy Binding 648 Acknowledgement (LMA) supports tunneling IPv6-or-IPv4 in IPv4 649 using TLV-header format. None of the other fields or flags in the 650 Proxy Binding Acknowledgement is modified by this specification. 652 6.4. Status Codes 654 The following status code values are defined for use in the Binding 655 Acknowledgment message when using Proxy Mobile IPv6. 657 GRE KEY OPTION NOT REQUIRED (TBD less than 128) 659 When the local mobility anchor receives a Proxy Binding Update 660 with the GRE Key option while based on a policy check the local 661 mobility anchor determines that the GRE encapsulation is not 662 required for this specific mobility session, the local mobility 663 anchor uses this code to indicate to the mobile access gateway 664 that the Proxy Binding Update has been processed successfully but 665 GRE Encapsulation and GRE Keys are not required. 667 GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED (TBD less than 128) 669 If local mobility anchor receives a Proxy Binding Update with the 670 GRE Key option and TLV-header Format (T) flag set, the local 671 mobility anchor uses this code to indicate to the mobile access 672 gateway that GRE Encapsulation has successfully been negotiated 673 but TLV-header format is NOT supported. 675 GRE KEY OPTION REQUIRED (TBD more than 128) 677 When the local mobility anchor receives a Proxy Binding Update 678 without the GRE Key option while based on a policy check the local 679 mobility anchor determines that GRE encapsulation is required for 680 this specific mobility session, the local mobility anchor uses 681 this code to reject the Proxy Binding Update and indicate to the 682 mobile access gateway that GRE Encapsulation and GRE Keys are 683 required. 685 7. Data Packets Processing Considerations 687 This section describes how the local mobility anchor and mobile 688 access gateway encapsulate and decapsulate data packets when GRE 689 encapsulation and GRE Keys are used for tunneling mobile nodes data 690 traffic between these two mobility nodes. 692 7.1. Tunneling Format 694 When GRE encapsulation is used, the mobile access gateway is allowed 695 to use various tunneling formats depending on the mobile access 696 gateway location and the networks's capabilities between the mobile 697 access gateway and the local mobility anchor. Using GRE 698 encapsulation, as described in [RFC2784] and [RFC2890], the mobile 699 access gateway can tunnel IPv6-or-IPv4 payload packet in IPv6 or in 700 IPv4 following the rules in [RFC5213] and [ID-PMIP6-IPv4]. 702 If UDP-based tunneling is used between the mobile access gateway and 703 the local mobility anchor after NAT has been detected in the path 704 between the mobile access gateway and the local mobility anchor while 705 GRE encapsulation is required, the TLV-header UDP tunneling format as 706 shown in Figure 5 MUST be used. 708 [IPv4 Header] 710 [UDP Header] 712 [TLV Header] 714 [GRE Header] 716 [payload - IPv6-or-IPv4 Header] 718 Upper Layer protocols 720 Figure 5: TLV-header UDP Based Encapsulation Headers Order 722 When UDP based tunneling format is used between the mobile access 723 gateway and the local mobility anchor, the use of the TLV-header is 724 negotiated during the Proxy Binding Update/Acknowledgement exchange 725 as described in Section 7.3 and Section 7.4. If the TLV-header 726 format is agreed upon between the mobile access gateway and local 727 mobility anchor, the local mobility anchor expects the TLV-header to 728 follow the UDP header as shown in Figure 5. The TLV header contains 729 the type field, the following payload packet header type and its 730 length. The Type field in the TLV-header is always set to a value of 731 0 to enhance the processing of the received packet by ensuring that 732 the receiver can differentiate whether what after the UDP header is a 733 TLV-header Type field or an IP version field of an IP header. Hence, 734 the TLV-header can carry traffic other than IP as indicated in the 735 Next Header field. The distinction between IP and TLV encapsulation 736 is needed, because the Proxy Binding Update (IP Packet) and the data 737 packets (GRE packets) can be sent over the same UDP tunnel. 739 When processing a UDP packet with the TLV-Header format, if the 740 receiving node found that the payload packet length as calculated 741 from the UDP header length field is different than its length as 742 calculated from the TLV-header length field, the receiving node MUST 743 discard the received IP packet. 745 7.2. TLV-header Tunneling Negotiation 747 The mobile access gateway negotiates the format for tunneling payload 748 traffic during Proxy Mobile IPv6 registration procedure. If the 749 mobile access gateway is required to use the TLV-header UDP 750 encapsulation format, the mobile access gateway MUST set the TLV- 751 header Format (T) flag in the Proxy Binding Update message sent to 752 the local mobility anchor. If the local mobility anchor supports the 753 TLV-header UDP tunneling format, the local mobility anchor SHOULD set 754 the TLV-header Format (T) flag in the Proxy Binding Acknowledgement. 755 Otherwise, the TLV-header Format (T) flag is cleared. The setting of 756 the TLV-header Format (T) flag in the Proxy Binding Acknowledgement 757 indicates to the mobile access gateway that it MUST use the TLV- 758 header UDP encapsulation format for all packets tunneled to the local 759 mobility anchor for the entire duration the mobile node is attached 760 to the mobile access gateway. The TLV-header UDP tunneling format 761 SHOULD NOT change during a Binding Lifetime Extension Proxy Binding 762 Update (re-registration) from the same mobile access gateway. 764 Any Proxy Binding Update message triggered by a handoff (Section 765 5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore, 766 in order to avoid interoperability issues, the local mobility anchor 767 MUST NOT set the TLV-header Format (T) flag unless it was set in the 768 Proxy Binding Update received from the mobile access gateway. 770 The TLV-header format is as shown below in Figure 6. 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Type | Res. | Next Header | Length | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Figure 6: TLV-header Format 780 Type 782 This field is always 0 (zero) and distinguishes the TLV header 783 from the IPv4 and IPv6 headers. 785 Res. 787 These fields are Reserved and unused. They MUST be initialized to 788 zero by the sender and MUST be ignored by the receiver. 790 Next Header 792 8-bit unsigned integer which indicates the protocol number of the 793 payload header following this TLV header. It is set to the 794 protocol number as assigned by IANA at the following 795 http://www.iana.org/assignments/protocol-numbers. e.g., if an IPv6 796 header follows, it should be '41'; '47' if it is a GRE header that 797 follows. 799 Length 801 16-bit unsigned integer indicating the length in octets of the 802 payload following this header, excluding the TLV-header itself. 804 7.3. Mobile Access Gateway Operation 806 When sending a Proxy Binding Update message while the network between 807 the mobile access gateway and local mobility anchor is an IPv4-only 808 network, the mobile access gateway follows the procedures specified 809 in [ID-PMIP6-IPv4] if regular UDP encapsulation format is used. 810 However, if GRE encapsulation is required and UDP based encapsulation 811 is used, the mobile access gateway MUST set the TLV-header Format (T) 812 flag in the Proxy Binding Update and follow this specification for 813 GRE encapsulation negotiation. If the received Proxy Binding 814 Acknowledgement is successful and the TLV-header Format (T) flag set 815 and the GRE Key option included, the mobile access gateway MUST 816 update the mobile node Binding Update List entry described in 817 Section 4.1 by setting the UDP based TLV-Header format flag. In this 818 case, the mobile access gateway MUST use the TLV-header UDP based 819 encapsulation format as shown in Figure 5. 821 If the mobile access gateway receives a Proxy Binding Acknowledgement 822 with the status in 823 response to a Proxy Binding Update with the GRE key option and the 824 (T) flag set, the mobile access gateway MUST use GRE encapsulation 825 without UDP encapsulation. If the mobile access gateway is allowed 826 to use GRE encapsulation without UDP tunneling, e.g., the mobile 827 access gateway is NOT behind a NAT, the mobile access gateway MUST 828 update the mobile node Binding Update List entry described in 829 Section 4.1 by setting the GRE encapsulation enabled flag and the 830 uplink and downlink GRE key fields. In this case, the mobile access 831 gateway MUST set the UDP based TLV-Header format flag to FALSE. A 832 Proxy Binding Acknowledgement message with status has the (T) flag cleared. Alternatively, 834 the mobile access gateway may resend the Proxy Binding Update to 835 negotiate different tunneling options, e.g., using UDP based 836 tunneling without GRE encapsulation if possible or de-register the 837 mobile node mobility session. 839 7.3.1. Sending and Receiving Data Packets 841 When the mobile access gateway is located in an IPv6-enabled or IPv4- 842 enabled network, it may be required to use GRE encapsulation for 843 tunneling IPv6 or IPv4 payload data packet to the local mobility 844 anchor. In this case and if the mobile access gateway has 845 successfully negotiated GRE encapsulation mode only or GRE 846 encapsulation and GRE Keys as described in this specification, the 847 mobile access gateway encapsulates or decapsulates IPv6-or-IPv4 848 payload packets following the rules described in [RFC5213] and 849 [ID-PMIP6-IPv4] while ensuring that the GRE header is present as 850 shown in Figure 7. 852 [IPv6-or-IPv4 Header] 854 [GRE Header] 856 [payload - IPv6-or-IPv4 Header] 858 Upper Layer protocols 860 Figure 7: IPv6-or-IPv4 over IPv4 Using GRE Encapsulation 862 On the other hand, if the mobile access gateway is located in an 863 IPv4-only network where NAT has been detected on the path between the 864 mobile access gateway and the local mobility anchor and successfully 865 negotiated GRE encapsulation and the TLV-header format, the mobile 866 access gateway MUST use UDP TLV-header tunneling format when sending 867 an IPv6 or IPv4 payload packet to the local mobility according to the 868 format described in Figure 5. The source and the destination of the 869 IPv4 outer header are mobile node IPv4 Proxy Care-of Address , IPv4- 870 Proxy-CoA, and the IPv4 Local Mobility Anchor Address, IPv4-LMAA, 871 respectively. In addition the source and the destination IP 872 addresses of the IPv6-or-IPv4 payload data packet are the Mobile 873 Node's IPv6 or IPv4 Home Address, IPv6/IPv4-MN-HoA, and the IPv6 or 874 IPv4 Corresponding Node's Address, IPv6/IPv4-CN-Addr, respectively. 876 7.4. Local Mobility Anchor Operation 878 When the local mobility anchor receives a Proxy Binding Update 879 encapsulated in UDP and containing the IPv4 home address option, it 880 needs to follow all the steps in [RFC5213] and [ID-PMIP6-IPv4]. In 881 addition, if the TLV-header Format (T) flag is set in the Proxy 882 Binding Update, the local mobility anchor needs to determine whether 883 it can accept the TLV-header UDP based encapsulation format. If it 884 does, it SHOULD set the TLV-header Format (T) flag in the Proxy 885 Binding Acknowledgement. Otherwise, the local mobility anchor MUST 886 NOT set the TLV-header Format (T) flag in the Proxy Binding 887 Acknowledgement. 889 If the local mobility anchor receives a Proxy Binding Update with the 890 GRE Key option and TLV-header Format (T) flag set and based on a 891 policy check, the local mobility anchor determines that GRE 892 encapsulation is required and the local mobility anchor supports TLV- 893 header tunneling and the local mobility anchor sent a successful 894 Proxy Binding Acknowledgement with the TLV-header Format (T) flag 895 set, the local mobility anchor MUST update the mobile node's Binding 896 Cache entry described in Section 5.1 by setting the GRE encapsulation 897 enabled flag and update the uplink and downlink GRE key fields. In 898 addition, the local mobility anchor MUST set the UDP based TLV-Header 899 format flag. 901 If the local mobility anchor receives a Proxy Binding Update with the 902 GRE Key option and TLV-header Format (T) flag set and based on a 903 policy check, the local mobility anchor determines that GRE 904 encapsulation is required BUT the local mobility anchor does NOT 905 support TLV-header tunneling and if Proxy Binding Update has been 906 successfully processed, the local mobility anchor MUST send a 907 successful Proxy Binding Acknowledgement with the status code . This way, the local 909 mobility anchor indicates to the mobile access gateway that GRE 910 encapsulation has been successfully negotiated BUT TLV-header UDP 911 based tunneling format is not supported. In this case, the local 912 mobility anchor MUST update the mobile node BCE described in 913 Section 5.1 by setting the GRE encapsulation enabled flag and update 914 the uplink and downlink GRE key fields. In this case, the local 915 mobility anchor MUST set the UDP based TLV-Header format flag to 916 FALSE. 918 If the local mobility anchor and the mobile access gateway have 919 successfully negotiated the TLV-header UDP based tunneling format and 920 the GRE encapsulation for a specific mobility session, the local 921 mobility anchor processes data packets as described in the following 922 subsection. 924 7.4.1. Sending and Receiving Data Packets 926 The local mobility anchor may use GRE encapsulation for tunneling 927 IPv6 or IPv4 payload data packet to the mobile access gateway. If 928 the local mobility anchor has successfully negotiated GRE 929 encapsulation with the mobile access gateway for a specific mobility 930 session, the local mobility anchor encapsulates and decapsulates 931 IPv6-or-IPv4 payload data packets following the rules described in 932 [RFC5213] and [ID-PMIP6-IPv4] while ensuring that the GRE header is 933 present as shown in Figure 7. 935 In the case when TLV-tunneling format and the GRE encapsulation for a 936 specific mobility session have been successfully negotiated between 937 the local mobility anchor and the mobile access gateway, the local 938 mobility anchor follows the TLV-header UDP based tunneling format and 939 headers order as shown in Figure 5 to encapsulate IPv4 or IPv6 940 payload packets in IPv4 before sending the IPv4 packet to the mobile 941 access gateway. In this case, the source and the destination of the 942 IPv4 outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. In 943 addition the source and the destination IP addresses of the IPv6-or- 944 IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA, 945 respectively. On the other hand, the local mobility anchor ensures 946 the same TLV-header UDP based tunneling format and headers order when 947 it decapsulates received IPv4 packets from the mobile access gateway 948 for the same mobility session. 950 8. IANA Considerations 952 This specification defines a new Mobility Option, the GRE Key Option, 953 described in Section 6.1. This option is carried in the Mobility 954 Header. The type value for this option needs to be assigned from the 955 same numbering space as allocated for the other mobility options 956 defined in the Mobile IPv6 specification [RFC3775]. 958 This specification also defines three new Binding Acknowledgement 959 status codes as described in Section 6.4 and requests that these 960 three codes be allocated with numeric values as specified in 961 Section 6.4 from the "Status Codes" registry of the Mobility IPv6 962 Parameters located at 963 http://www.iana.org/assignments/mobility-parameters. 965 9. Security Considerations 967 The GRE Key Option, defined in this specification, that can be 968 carried in Proxy Binding Update and Proxy Binding Acknowledgement 969 messages, reveals the group affiliation of a mobile node identified 970 by its Network Access Identifier (NAI) or an IP address. It may help 971 an attacker in targeting flows belonging to a specific group. This 972 vulnerability can be prevented, by enabling confidentiality 973 protection on the Proxy Binding Update and Proxy Binding 974 Acknowledgement messages where the presence of the NAI and GRE Key 975 Options establish a mobile node's relation to a specific group. This 976 vulnerability can also be avoided by enabling confidentiality 977 protection on all the tunneled data packets between the mobile access 978 gateway and the local mobility anchor, for hiding all the markings. 980 In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for 981 protecting a mobile node's data traffic is optional. Additionally, 982 Proxy Mobile IPv6 recommends the use of Encapsulating Security 983 Payload (ESP) [RFC4303] in tunnel mode when using ESP in protecting 984 the mobile node's data traffic. However, when GRE encapsulation is 985 used, both IPsec tunnel mode and transport mode can be used to 986 protect the GRE header. The IPsec traffic selectors will contain the 987 protocol number for GRE, and there is currently no mechanism to use 988 the GRE key as a traffic selector. 990 10. Acknowledgements 992 The authors would like to thank Alessio Casati, Barney Barnowski, 993 Mark Grayson and Parviz Yegani for their input on the need for this 994 option. The authors would like to thank Charlie Perkins, Curtis 995 Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal 996 Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review 997 and comments. 999 11. References 1000 11.1. Normative References 1002 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1003 E. Lear, "Address Allocation for Private Internets", 1004 BCP 5, RFC 1918, February 1996. 1006 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1007 October 1996. 1009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1010 Requirement Levels", BCP 14, RFC 2119, March 1997. 1012 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1013 IPv6 Specification", RFC 2473, December 1998. 1015 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1016 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1017 March 2000. 1019 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1020 RFC 2890, September 2000. 1022 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1023 in IPv6", RFC 3775, June 2004. 1025 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1026 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1028 [ID-PMIP6-IPv4] 1029 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1030 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12 1031 (work in progress), April 2009. 1033 11.2. Informative References 1035 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1036 Internet Protocol", RFC 4301, December 2005. 1038 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1039 RFC 4303, December 2005. 1041 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1042 "Multiple Care-of Addresses Registration", 1043 draft-ietf-monami6-multiplecoa-13 (work in progress), 1044 April 2009. 1046 Authors' Addresses 1048 Ahmad Muhanna 1049 Nortel 1050 2221 Lakeside Blvd. 1051 Richardson, TX 75082 1052 USA 1054 Email: amuhanna@nortel.com 1056 Mohamed Khalil 1057 Nortel 1058 2221 Lakeside Blvd. 1059 Richardson, TX 75082 1060 USA 1062 Email: mkhalil@nortel.com 1064 Sri Gundavelli 1065 Cisco Systems 1066 170 West Tasman Drive 1067 San Jose, CA 95134 1068 USA 1070 Email: sgundave@cisco.com 1072 Kent Leung 1073 Cisco Systems 1074 170 West Tasman Drive 1075 San Jose, CA 95134 1076 USA 1078 Email: kleung@cisco.com