idnits 2.17.1 draft-muhanna-netlmm-grekey-option-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 08, 2008) is 5764 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-03 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM WG A. Muhanna 3 Internet-Draft M. Khalil 4 Intended status: Standards Track Nortel 5 Expires: January 9, 2009 S. Gundavelli 6 K. Leung 7 Cisco Systems 8 July 08, 2008 10 GRE Key Option for Proxy Mobile IPv6 11 draft-muhanna-netlmm-grekey-option-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 9, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The Proxy Mobile IPv6 base specification and Proxy Mobile IPv6 45 support for IPv4 allow the mobile node's IPv4 and IPv6 traffic 46 between the local mobility anchor and the mobile access gateway to be 47 tunneled using IPv6 or IPv4 encapsulation headers. These 48 encapsulation modes do not offer the tunnel end-points the required 49 semantics to expose a service identifier that can be used to identify 50 traffic for a certain classification, such as for supporting mobile 51 nodes that are using overlapping private IPv4 addressing. The 52 extension defined in this document allow the mobile access gateway 53 and the local mobility anchor to negotiate GRE encapsulation mode and 54 exchange the GRE keys for marking the flows, so that differential 55 processing can be applied by the tunnel peers over those flows. 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 Support . . . . . . . . . . . . . . . . 6 66 3.3. GRE Keys Exchange Mechanism . . . . . . . . . . . . . . . 6 67 3.3.1. Initial GRE Keys Exchange . . . . . . . . . . . . . . 6 68 3.3.2. GRE Keys De-registration . . . . . . . . . . . . . . . 6 69 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 7 70 4.1. Extensions to the Conceptual Data Structure . . . . . . . 7 71 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 7 72 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 8 73 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 8 74 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9 75 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.1. GRE Encapsulation Option . . . . . . . . . . . . . . . . . 10 77 6.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 11 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 81 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Intellectual Property and Copyright Statements . . . . . . . . . . 14 85 1. Introduction 87 The base Proxy Mobile IPv6 specification [ID-PMIP6] and Proxy Mobile 88 IPv6 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 89 encapsulation modes [RFC2473] , [RFC2003] for the tunneled traffic 90 between the local mobility anchor and the mobile access gateway. 91 There are scenarios where these encapsulation modes are not 92 sufficient to uniquely identify the destination of packets of a 93 specific flow. Thus, there is a need for an encapsulation mode with 94 richer semantics. The Generic Routing Encapsulation [RFC2784] and 95 the Key extension as defined in [RFC2890], has the required semantics 96 to allow such distinction for use in Proxy Mobile IPv6. 98 This document defines an extension to the base Proxy Mobile IPv6 99 specification, for allowing the mobile access gateway and the local 100 mobility anchor to negotiate GRE encapsulation mode and exchange the 101 downlink and uplink GRE keys that can be used for marking the 102 downlink and uplink traffic which belong to a specific mobile node 103 session or a specific flow. 105 2. Conventions & Terminology 107 2.1. Conventions 109 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2.2. Terminology 115 All the general mobility related terminology and abbreviations are to 116 be interpreted as defined in Mobile IPv6 specification [RFC3775] and 117 Proxy Mobile IPv6 specification [ID-PMIP6]. The following terms are 118 used in this document. 120 Downlink Traffic 122 The traffic in the tunnel between the local mobility anchor and 123 the mobile access gateway, heading towards the mobile access 124 gateway and tunneled at the local mobility anchor. This traffic 125 is also referenced as forward direction traffic. 127 Uplink Traffic 129 The traffic in the tunnel between the mobile access gateway and 130 the local mobility anchor, heading towards the local mobility 131 anchor and tunneled at the mobile access gateway. This traffic is 132 also referenced as reverse direction traffic. 134 Downlink GRE Key 136 The GRE key is assigned by the mobile access gateway and used by 137 the local mobility anchor to mark the downlink traffic which 138 belongs to a specific mobile node session or flow as described in 139 this document. 141 Uplink GRE Key 143 The GRE key is assigned by the local mobility anchor and used by 144 the mobile access gateway to mark the uplink traffic which belongs 145 to a specific mobile node session or flow as described in this 146 document. 148 3. GRE Encapsulation and Keys Exchange 150 3.1. GRE Encapsulation Overview 152 Using the extension defined in this specification, the mobile access 153 gateway and the local mobility anchor can negotiate GRE encapsulation 154 mode and the exchange of GRE keys for marking the downlink and uplink 155 traffic. 157 Once the GRE keys have been exchanged between the mobile access 158 gateway and the local mobility anchor, the mobile access gateway will 159 use the uplink GRE key that is assigned by the local mobility anchor 160 in the GRE encapsulation header of the uplink payload packet. 161 Similarly, the local mobility anchor will use the downlink GRE key as 162 negotiated with the mobile access gateway in the GRE encapsulation 163 header of the downlink payload packet. 165 The following illustration explains the use of GRE encapsulation mode 166 and the use of GRE keys for supporting the scenario where overlapping 167 IPv4 private address [RFC1918] allocation is in use. 169 +------------+ 170 | Operator-A | 171 | | 172 | 10.x.0.0/16| 173 +------------+ 174 / 175 +------+ +------+ / 176 | | ========================== | | / 177 MN-1---| | / \ | | / Key-1 178 | M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic 179 MN-2---| A |--| |--| M |- 180 | G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2 181 MN-3---| | \ / | | \Traffic 182 | | ========================== | | \ 183 MN-4---| | Proxy Mobile IPv6 Tunnel | | \ 184 +------+ +------+ \ 185 \ 186 Operator-C: Access Network +------------+ 187 | Operator-B | 188 | | 189 | 10.x.0.0/16| 190 +------------+ 192 Figure 1: Overlapping IPv4 Private Address Space 194 Figure 1 illustrates a local mobility anchor providing mobility 195 service to mobile nodes that are from different operators and are 196 assigned IPv4 addresses from overlapping private address space. In 197 this scenario, the mobile access gateway and the local mobility 198 anchor must be able distinguish the flows belonging to a given 199 operator from the flows belonging to some other operator. 201 The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and 202 mobile nodes, MN-3 and MN-4 are visiting from Operator-B. The mobile 203 access gateway and the local mobility anchor exchange a specific pair 204 of downlink and uplink GRE keys and save them as part of the mobile 205 node binding to be used for identifying the flows belonging to each 206 mobile node. 208 The local mobility anchor and the mobile access gateway will be able 209 to distinguish each mobile node flow(s) based on the GRE key present 210 in the GRE header of the tunneled packet, and route them accordingly. 212 3.2. GRE Encapsulation Support 214 To request GRE encapsulation support without exchanging the GRE keys, 215 the mobile access gateway MUST include the GRE Encapsulation Option 216 in the Proxy Binding Update message sent to the local mobility 217 anchor. The mobile access gateway MUST set the length field of the 218 GRE encapsulation option to 2. 220 If the local mobility anchor supports GRE encapsulation and upon the 221 successful process of the Proxy Binding Update, the LMA sends a Proxy 222 Binding Acknowledgement and MUST include the GRE Encapsulation option 223 with the length field set to 2. 225 However, If the local mobility anchor does not support GRE 226 encapsulation, the LMA MUST reject the Proxy Binding Update by 227 sending a Proxy Binding Acknowledgement message with the status field 228 is set to TBA1 as defined in Section 6.2. 230 3.3. GRE Keys Exchange Mechanism 232 The following subsections describe how the mobile access gateway and 233 the local mobility anchor exchange downlink and uplink GRE keys using 234 proxy mobile IPv6 registration procedure. The mechanism for de- 235 registering the GRE keys pair(s) is also described. 237 3.3.1. Initial GRE Keys Exchange 239 When the mobile access gateway determines based on, e.g., private 240 IPv4 address overlapping [RFC1918] support, the MAG local policy, or 241 MAG-LMA peer agreement that GRE encapsulation is needed and a new 242 pair of GRE keys is required, the mobile access gateway MUST include 243 the GRE Encapsulation Option in the Proxy Binding Update message sent 244 to the local mobility anchor. The mobile access gateway MUST include 245 the downlink GRE key in the GRE Key Identifier field. 247 Upon the successful process of the PBU and accepting the downlink GRE 248 key, the LMA MUST include the uplink GRE key and echo the downlink 249 included in the GRE Key Identifier field of the option. In this 250 case, the first key is the downlink key while the second is the 251 uplink key. 253 3.3.2. GRE Keys De-registration 255 If the GRE key option is present in the initial PBU, it MUST always 256 be present in the re-registration or de-registration messages and 257 with the same GRE key value. 259 If the local mobility anchor successfully process a deregistration 260 PBU message which contains a GRE Encapsulation option with a downlink 261 GRE key included, the LMA follows the same session deregistration 262 process as per the base Proxy Mobile IPv6 specification [ID-PMIP6] to 263 clean the binding cache entry and the associated resources including 264 the uplink GRE key. In the case that the deregistration PBU does not 265 include the GRE encapsulation option and the corresponding mobile 266 node session has been assigned downlink and uplink GRE keys, the LMA 267 will follow the same process in cleaning the associated resources 268 including the GRE keys. The mechanism that the LMA uses for 269 reassigning the uplink GRE keys for other sessions is implementation 270 specific and out of scope. 272 4. Mobile Access Gateway Considerations 274 4.1. Extensions to the Conceptual Data Structure 276 Every mobile access gateway maintains a Binding Update List entry for 277 each currently attached mobile node, as explained in Section 6.1 of 278 the base Proxy Mobile IPv6 specification [ID-PMIP6]. To support this 279 specification, the conceptual Binding Update List entry data 280 structure must be extended with the following three new additional 281 fields. 283 o A flag indicating whether GRE encapsulation is enabled for the 284 mobile node's traffic flows. 286 o The Downlink GRE Key used in the GRE encapsulation header of the 287 tunneled packet from the local mobility anchor to the mobile 288 access gateway that is destined to the mobile node. This GRE Key 289 is generated by the MAG and communicated to the LMA in the GRE 290 Encapsulation option in the PBU message. 292 o The Uplink GRE Key used in the GRE encapsulation header of the 293 tunneled packet from the mobile access gateway to the local 294 mobility anchor that is originating from the mobile node. This 295 GRE Key is obtained from the GRE Key Identifier field of the GRE 296 Encapsulation option present in the received PBA message sent by 297 the LMA as specified in this document. 299 4.2. Operational Summary 301 o If IPv4 Home Address support is enabled for the mobile node and if 302 the IPv4 Home Address Option is included in the Proxy Binding 303 Update message that is sent by the mobile access gateway to the 304 mobile node's local mobility anchor, the GRE Encapsulation Option 305 MAY be included in the Proxy Binding Update message. In order to 306 exchange GRE keys, the MAG MUST include the downlink GRE key in 307 the GRE Key Identifier field. 309 o After receiving a Proxy Binding Acknowledgment message with the 310 status code indicating the acceptance of the Proxy Binding Update 311 message and with the GRE Encapsulation Option with both the 312 downlink and uplink GRE keys, the mobile access gateway MUST 313 update the related three fields in the mobile node Binding Update 314 List entry described in Section 4.1. Additionally, the MAG MUST 315 use the assigned uplink GRE Key for tunneling all the traffic 316 originating from the mobile node. 318 o For a given mobile node, if the local mobility anchor rejects the 319 Proxy Binding Update by sending the Proxy Binding Acknowledgement 320 with the status code TBA1 (GRE Encapsulation not supported), the 321 mobile access gateway MUST NOT include the GRE Encapsulation 322 Option in the subsequent Proxy Binding Update messages that are 323 sent to that LMA. 325 o If the mobile access gateway has sent a Proxy Binding Update 326 message without the GRE Encapsulation Option, but the received 327 Proxy Binding Acknowledgement has the Status Code TBA2, indicating 328 that the GRE encapsulation is required, the mobile access gateway 329 SHOULD resend the Proxy Binding Update message with the GRE 330 Encapsulation Option. 332 o On receiving a packet from the tunnel with the GRE encapsulation 333 header, the mobile access gateway MUST use the GRE Key to 334 determine the necessary special processing for the data packet, 335 e.g., lookup the mobile node's layer-2 address, determine any 336 special processing or treatment for the data packet flow, before 337 forwarding the packet after removing the encapsulation headers. 339 5. Local Mobility Anchor Considerations 341 5.1. Extensions to the Binding Cache Entry 343 When the local mobility anchor and the mobile access gateway 344 successfully negotiates GRE encapsulation and exchange downlink and 345 uplink GRE keys, the local mobility anchor MUST maintain the downlink 346 and uplink GRE keys as part of the mobile node BCE. This requires 347 that the BCE described in section 5.1 of the Proxy Mobile IPv6 base 348 specification [ID-PMIP6] is extended. To support this specification, 349 the BCE must be extended with the following three additional fields. 351 o A flag indicating whether GRE encapsulation is enabled for the 352 mobile node's traffic flows. 354 o The Downlink GRE Key, assigned by the MAG and used in the GRE 355 encapsulation header of the tunneled packet from the local 356 mobility anchor to the mobile access gateway. 358 o The Uplink GRE Key, assigned by the LMA and used in the GRE 359 encapsulation header of the tunneled packet from the mobile access 360 gateway to the local mobility anchor. 362 5.2. Operational Summary 364 o Upon receiving a Proxy Binding Update message with the GRE 365 Encapsulation Option, the local mobility anchor, if it does not 366 support GRE encapsulation mode, MUST send the Proxy Binding 367 Acknowledgement message to the mobile access gateway with the 368 status code TBA1 as defined in Section 6.2. 370 o Upon the successful process of a Proxy Binding Update message with 371 the GRE Encapsulation Option with the downlink GRE key included in 372 the GRE Key Identifier field, the local mobility anchor MUST 373 include the GRE Encapsulation option with the downlink and uplink 374 GRE keys in the GRE Key Identifier field when responding with a 375 successful PBA message. When GRE Key Identifier field carries the 376 downlink and uplink GRE keys, the first key is always set to the 377 downlink GRE key. 379 o If the GRE tunneling is negotiated and the downlink and uplink GRE 380 keys have been exchanged between the local mobility anchor and the 381 mobile access gateway, every packet that is destined to the mobile 382 node through the local mobility anchor MUST be encapsulated with a 383 GRE header using the negotiated downlink GRE key. 385 o If the received Proxy Binding Update message does not contain the 386 GRE Encapsulation Option, and if the local mobility anchor 387 determines that GRE encapsulation is required, e.g., overlapping 388 IPv4 private addressing is in use, LMA local policy, the local 389 mobility anchor MUST reject the request, and MUST send the Proxy 390 Binding Acknowledgement message to the mobile access gateway with 391 the status code TBA2, indicating that GRE encapsulation is 392 required. 394 o On receiving a packet from the tunnel with the GRE encapsulation 395 header, the local mobility anchor MUST use the GRE Key present in 396 the GRE extension header to determine the necessary special 397 processing for the data packet, e.g., lookup the mobile node's 398 home gateway address, determine any special processing or 399 treatment for the data packet flow, before forwarding the packet 400 after removing the encapsulation headers. 402 6. Message Formats 404 This section defines an extension to the Mobile IPv6 [RFC3775] 405 protocol messages for supporting the GRE tunneling and GRE Keys 406 exchange for Proxy Mobile IPv6. 408 6.1. GRE Encapsulation Option 410 A new option, the GRE Encapsulation Option, is defined for use in the 411 Proxy Binding Update and Proxy Binding Acknowledgment messages 412 exchanged between the mobile access gateway and the local mobility 413 anchor. This option can be used for negotiating GRE encapsulation 414 and exchanging the GRE keys to be applied by the peer on all GRE 415 encapsulated packets for the specified mobile node session or flow. 417 The alignment requirement for this option is 4n. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type | Length | Reserved | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | GRE Key Identifier | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 2: GRE Encapsulation Option 429 Type 431 433 Length 435 8-bit unsigned integer indicating the length in octets of the 436 option, excluding the type and length fields. If the Length field 437 is set to 2, it indicates that the GRE keys are not being carried 438 in the option. If the length field is set to a value of 6 or 10, 439 it means that down link GRE key or downlink and uplink GRE keys 440 are carried, respectively. 442 Reserved 444 These fields are unused. They MUST be initialized to zero by the 445 sender and MUST be ignored by the receiver. 447 GRE Key Identifier 449 32-bit field containing the Downlink GRE Key, or 64-bit field 450 containing the Downlink and Uplink GRE keys. This field is 451 present in the mobility option only if the GRE keys are being 452 exchanged using the PBU and PBA messages. 454 6.2. Status Codes 456 The following status code values are defined for using them in the 457 Binding Acknowledgment message when using Proxy Mobile IPv6 protocol. 458 The value allocation for this usage needs to be approved by the IANA 459 and must be updated in the IANA registry. 461 TBA1: GRE Encapsulation not required. 463 TBA2: GRE Encapsulation and GRE Key Identifier option required. 465 7. IANA Considerations 467 This document defines a new Option, the GRE Encapsulation Option, 468 described in Section 6.1. This option is carried in the Mobility 469 Header. The type value for this option needs to be assigned from the 470 same numbering space as allocated for the other mobility options 471 defined in the Mobile IPv6 specification [RFC3775]. 473 This document also defines two new Binding Acknowledgement status 474 codes TBA1 and TBA2 as described in Section 6.2. This document 475 requests that these two codes be allocated from the "Status Codes" 476 registry of the Mobility IPv6 Parameters located at 477 http://www.iana.org/assignments/mobility-parameters and that the 478 numeric value of these codes be greater than 128. 480 8. Security Considerations 482 The GRE Encapsulation Option, defined in this document, that can be 483 carried in Proxy Binding Update and Proxy Binding Acknowledgement 484 messages, reveals the group affiliation of a mobile node identified 485 by its NAI or an IP address. It may help an attacker in targeting 486 flows belonging to a specific group. This vulnerability can be 487 prevented, by enabling confidentiality protection on the Proxy 488 Binding Update and Acknowledgement messages where the presence of the 489 NAI and GRE Encapsulation Options establish a mobile node's relation 490 to a specific group. This vulnerability can also be avoided by 491 enabling confidentiality protection on all the tunneled data packets 492 between the mobile access gateway and the local mobility anchor, for 493 hiding all the markings. 495 9. Acknowledgements 497 The authors would like to thank Allesio Casati, Barney Barnowski, 498 Mark Grayson and Parviz Yegani for their input on the need for this 499 option. The authors would like to thank Curtis Provost, Irfan Ali, 500 Julien Langanier, Jouni Korhonen, Suresh Krishnan, Kuntal Chowdhury, 501 and Vijay Devarapalli for their review and comments. 503 10. Normative References 505 [ID-PMIP6] 506 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 507 and B. Patil, "Proxy Mobile IPv6", 508 draft-ietf-netlmm-proxymip6-18 (work in progress), 509 May 2008. 511 [ID-PMIP6-IPv4] 512 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 513 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03 514 (work in progress), May 2008. 516 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 517 E. Lear, "Address Allocation for Private Internets", 518 BCP 5, RFC 1918, February 1996. 520 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 521 October 1996. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 527 IPv6 Specification", RFC 2473, December 1998. 529 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 530 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 531 March 2000. 533 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 534 RFC 2890, September 2000. 536 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 537 in IPv6", RFC 3775, June 2004. 539 Authors' Addresses 541 Ahmad Muhanna 542 Nortel 543 2221 Lakeside Blvd. 544 Richardson, TX 75082 545 USA 547 Email: amuhanna@nortel.com 549 Mohamed Khalil 550 Nortel 551 2221 Lakeside Blvd. 552 Richardson, TX 75082 553 USA 555 Email: mkhalil@nortel.com 557 Sri Gundavelli 558 Cisco Systems 559 170 West Tasman Drive 560 San Jose, CA 95134 561 USA 563 Email: sgundave@cisco.com 565 Kent Leung 566 Cisco Systems 567 170 West Tasman Drive 568 San Jose, CA 95134 569 USA 571 Email: kleung@cisco.com 573 Full Copyright Statement 575 Copyright (C) The IETF Trust (2008). 577 This document is subject to the rights, licenses and restrictions 578 contained in BCP 78, and except as set forth therein, the authors 579 retain all their rights. 581 This document and the information contained herein are provided on an 582 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 583 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 584 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 585 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 586 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Intellectual Property 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed to 593 pertain to the implementation or use of the technology described in 594 this document or the extent to which any license under such rights 595 might or might not be available; nor does it represent that it has 596 made any independent effort to identify any such rights. Information 597 on the procedures with respect to rights in RFC documents can be 598 found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use of 603 such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository at 605 http://www.ietf.org/ipr. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights that may cover technology that may be required to implement 610 this standard. Please address the information to the IETF at 611 ietf-ipr@ietf.org. 613 Acknowledgment 615 Funding for the RFC Editor function is provided by the IETF 616 Administrative Support Activity (IASA).