Network Working Group A. Muhanna Internet-Draft M. Khalil Intended status: Standards Track Nortel Expires: May 25, 2009 S. Gundavelli K. Leung Cisco Systems November 21, 2008 GRE Key Option for Proxy Mobile IPv6 draft-ietf-netlmm-grekey-option-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 25, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines a new Mobility Option for allowing the mobile access gateway and the local mobility anchor to negotiate GRE encapsulation mode and exchange the downlink and uplink GRE keys which are used for marking the downlink and uplink traffic that belong to a specific mobile node session or a specific flow. Muhanna, et al. Expires May 25, 2009 [Page 1] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4 3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4 3.2. GRE Encapsulation Support . . . . . . . . . . . . . . . . 6 3.3. GRE Key Exchange Mechanism . . . . . . . . . . . . . . . . 6 3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6 3.3.2. GRE Key Exchange During Binding Re-registration . . . 6 4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 7 4.1. Extensions to the Conceptual Data Structure . . . . . . . 7 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 8 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 9 5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 9 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 10 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Muhanna, et al. Expires May 25, 2009 [Page 2] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 1. Introduction The base Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile IPv6 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4 encapsulation modes [RFC2473] , [RFC2003] for the tunneled traffic between the local mobility anchor and the mobile access gateway. There are scenarios where these encapsulation modes are not sufficient to uniquely identify the destination of packets of a specific flow. Thus, there is a need for an encapsulation mode with richer semantics. The Generic Routing Encapsulation [RFC2784] and the Key extension as defined in [RFC2890], has the required semantics to allow such distinction for use in Proxy Mobile IPv6. This document defines the GRE Key option to be used for the negotiation of GRE encapsulation mode and the exchange of the uplink and downlink GRE keys. The negotiated downlink and uplink GRE keys can be used for marking the downlink and uplink traffic for a specific mobile node session or a specific flow. 2. Conventions & Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Terminology All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 specification [RFC3775] and Proxy Mobile IPv6 specification [RFC5213]. The following terms are used in this document. Downlink Traffic The traffic in the tunnel between the local mobility anchor and the mobile access gateway, heading towards the mobile access gateway and tunneled at the local mobility anchor. This traffic is also called forward direction traffic. Uplink Traffic The traffic in the tunnel between the mobile access gateway and the local mobility anchor, heading towards the local mobility anchor and tunneled at the mobile access gateway. This traffic is also called reverse direction traffic. Muhanna, et al. Expires May 25, 2009 [Page 3] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 Downlink GRE Key The GRE key is assigned by the mobile access gateway and used by the local mobility anchor to mark the downlink traffic which belongs to a specific mobile node session or flow as described in this document. Uplink GRE Key The GRE key is assigned by the local mobility anchor and used by the mobile access gateway to mark the uplink traffic which belongs to a specific mobile node session or flow as described in this document. 3. GRE Encapsulation and Key Exchange 3.1. GRE Encapsulation Overview Using the GRE Key option defined in this specification, the mobile access gateway and the local mobility anchor can negotiate GRE encapsulation mode and exchange the GRE keys for marking the downlink and uplink traffic. Once the GRE keys have been exchanged between the mobile access gateway and the local mobility anchor, the mobile access gateway will use the uplink GRE key that is assigned by the local mobility anchor in the GRE encapsulation header of the uplink payload packet. Similarly, the local mobility anchor will use the downlink GRE key as negotiated with the mobile access gateway in the GRE encapsulation header of the downlink payload packet. The following illustration explains the use of GRE encapsulation mode and the GRE keys for supporting the usecase where overlapping IPv4 private address [RFC1918] allocation is in use. Muhanna, et al. Expires May 25, 2009 [Page 4] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 +------------+ | Operator-A | | | | 10.x.0.0/16| +------------+ / +------+ +------+ / | | ========================== | | / MN-1---| | / \ | | / Key-1 | M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic MN-2---| A |--| |--| M |- | G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2 MN-3---| | \ / | | \Traffic | | ========================== | | \ MN-4---| | Proxy Mobile IPv6 Tunnel | | \ +------+ +------+ \ \ Operator-C: Access Network +------------+ | Operator-B | | | | 10.x.0.0/16| +------------+ Figure 1: Overlapping IPv4 Private Address Space Figure 1 illustrates a local mobility anchor providing mobility service to mobile nodes that are from different operators and are assigned IPv4 addresses from overlapping private address space. In this scenario, the mobile access gateway and the local mobility anchor must be able distinguish the flows belonging to a given operator from the flows belonging to some other operator. The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and mobile nodes, MN-3 and MN-4 are visiting from Operator-B. The mobile access gateway and the local mobility anchor exchange a specific pair of downlink and uplink GRE keys and save them as part of the mobile node binding to be used for identifying the flows belonging to each mobile node. The LMA and the MAG will be able to distinguish each mobile node flow(s) based on the GRE key present in the GRE header of the tunneled packet, and route them accordingly. Muhanna, et al. Expires May 25, 2009 [Page 5] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 3.2. GRE Encapsulation Support To request GRE encapsulation support without exchanging the GRE keys, the mobile access gateway MUST include the GRE Key option in the Proxy Binding Update message sent to the local mobility anchor. The mobile access gateway MUST set the length field of the GRE Key option to 2 octets. If the local mobility anchor supports GRE encapsulation and after successfully processes the Proxy Binding Update, the LMA sends a Proxy Binding Acknowledgement and MUST include the GRE Key option with the length field set to 2 octets. 3.3. GRE Key Exchange Mechanism The following subsections describe how the mobile access gateway and the local mobility anchor exchange downlink and uplink GRE keys using proxy mobile IPv6 registration procedure. 3.3.1. Initial GRE Key Exchange When the mobile access gateway determines, based on, e.g., private IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA peer agreement, that GRE encapsulation is needed and GRE keys is required, the mobile access gateway MUST include the GRE Key option in the initial Proxy Binding Update message sent to the local mobility anchor. The mobile access gateway MUST include the downlink GRE key in the GRE Key Identifier field of the GRE Key option. After successfully processes the initial Proxy Binding Update and accepting the downlink GRE key, the LMA MUST include the GRE Key option with the uplink GRE key in the GRE Key Identifier field when sending a successful Proxy Binding Acknowledgement to the MAG. 3.3.2. GRE Key Exchange During Binding Re-registration If the MAG has successfully negotiated and exchanged the initial GRE keys with the LMA for a specific binding, the MAG SHOULD NOT include the GRE Key option with the downlink GRE key in the Proxy Binding Update which is used for requesting a Binding Lifetime Extension. However, during inter-MAG handoff and if the new mobile access gateway determines, based on, e.g., private IPv4 address support, the MAG local policy, the MAG-LMA peer agreement, or an indication during the handoff process, that GRE encapsulation and GRE key exchange is required, the new mobile access gateway MUST include the GRE key option with the downlink GRE key in the Proxy Binding Update which is used for requesting an after handoff Binding Lifetime extension. In Muhanna, et al. Expires May 25, 2009 [Page 6] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 this case, the new MAG may either pick a new downlink GRE key or use the downlink GRE key that was used by the previous MAG for the same binding. For the new MAG to know the downlink GRE key used by the previous MAG, it may require transfer of context from the previous MAG to the new MAG during a handover. Such mechanisms are out-of- scope for this document. If the LMA successfully processes a handoff-triggered Binding Lifetime Extension Proxy Binding Update message which contains a GRE key option with a downlink GRE key included, the LMA MUST return the same uplink GRE key that was exchanged with the previous MAG and is saved in the respected BCE. If the LMA receives handoff-triggered Binding Lifetime Extension Proxy Binding Update message without the GRE key option for a BCE that is using GRE keys and GRE encapsulation, the LMA MUST reject the Proxy Binding Update by sending a Proxy Binding Acknowledgement message with the status field is set to as defined in Section 6.2. If the LMA receives a no handoff Binding Lifetime extension Proxy Binding Update message with the GRE key option and the downlink GRE key included from the same MAG that is currently hosting the respected binding current pCoA, the LMA MUST NOT reject the Proxy Binding Update because of the GRE key option being included in a binding reregistration Proxy Binding Update message. In this case, the LMA processes the Proxy Binding Update normally and if the included downlink GRE key is different than the one saved in the respected BCE, the LMA MUST update the BCE with the new downlink GRE key. 4. Mobile Access Gateway Considerations 4.1. Extensions to the Conceptual Data Structure Every mobile access gateway maintains a Binding Update List entry for each currently attached mobile node, as explained in Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To support this specification, the conceptual Binding Update List entry data structure must be extended with the following three new additional fields. o A flag indicating whether GRE encapsulation is enabled for the mobile node's traffic flows. Muhanna, et al. Expires May 25, 2009 [Page 7] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 o The Downlink GRE Key used in the GRE encapsulation header of the tunneled packet from the local mobility anchor to the mobile access gateway that is destined to the mobile node. This GRE Key is generated by the MAG and communicated to the LMA in the GRE Key option in the Proxy Binding Update message. o The Uplink GRE Key used in the GRE encapsulation header of the tunneled packet from the mobile access gateway to the local mobility anchor that is originating from the mobile node. This GRE Key is obtained from the GRE Key Identifier field of the GRE Key option present in the received Proxy Binding Acknowledgement message sent by the LMA as specified in this document. 4.2. Operational Summary o If the MAG determines that GRE encapsulation and GRE key is required, the MAG MUST include the GRE Key option with the downlink GRE key in the GRE Key Identifier field in the Proxy Binding Update message that is sent by the mobile access gateway to the local mobility anchor. o After receiving a successful Proxy Binding Acknowledgment message with the GRE Key option which includes the uplink GRE key, the mobile access gateway MUST update the related three fields in the mobile node Binding Update List entry described in Section 4.1. Additionally, the MAG MUST use the assigned uplink GRE Key for tunneling all the traffic originating from the mobile node before forwarding the tunneled traffic to the LMA. o If the mobile access gateway included the GRE Key option in the Proxy Binding Update for a specific mobile node and the local mobility anchor accepts the Proxy Binding Update by sending a Proxy Binding Acknowledgement with a success status code (less than 128) other than , but without the GRE Key option, then the mobile access gateway MUST consider that the local mobility anchor does not support GRE Key option as per this specification. The mobile access gateway SHOULD NOT include the GRE Key option in any subsequent Proxy Binding Update message that is sent to that LMA. o If the mobile access gateway sent a Proxy Binding Update message without the GRE Key option, but the received Proxy Binding Acknowledgement has the Status Code , indicating that the GRE encapsulation and GRE key is required, the mobile access gateway SHOULD resend the Proxy Binding Update message with the GRE Key option. If the MAG does not support the GRE Key option, the MAG MAY log the event and possibly raise an alarm to indicate a possible misconfiguration. Muhanna, et al. Expires May 25, 2009 [Page 8] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 o If the mobile access gateway sent a Proxy Binding Update message with the GRE Key option and the downlink GRE key included and received a successful Proxy Binding Acknowledgement message with a status code , the mobile access gateway MUST consider that GRE encapsulation and GRE keys is not required for this specific binding. The MAG follows the Proxy Mobile IPv6 specification [RFC5213] for the handling of uplink and downlink traffic for this mobile node binding and MUST NOT include the GRE Key option in any subsequent Proxy Binding Update message for this specific mobile node that are sent to that LMA. o If the MAG sent a re-registration Proxy Binding Update message without the GRE Key option, but received a successful Proxy Binding Acknowledgement which includes the GRE Key option with the uplink GRE key, the MAG MUST compare the received uplink GRE key with the one saved in the respected Binding Update List entry and update it if the received uplink GRE key is different. o If the MAG has successfully negotiated and exchanged the initial GRE keys with the LMA for a specific binding, the MAG SHOULD NOT include the GRE Key option in the de-registration Proxy Binding Update. o On receiving a packet from the tunnel with the GRE encapsulation header, the mobile access gateway MUST use the GRE Key to determine the necessary special processing for the data packet, e.g., lookup the mobile node's layer-2 address, determine any special processing or treatment for the data packet flow, then remove the encapsulation header before forwarding the packet. 5. Local Mobility Anchor Considerations 5.1. Extensions to the Binding Cache Entry When the local mobility anchor and the mobile access gateway successfully negotiates GRE encapsulation and exchange downlink and uplink GRE keys, the local mobility anchor MUST maintain the downlink and uplink GRE keys as part of the mobile node BCE. This requires that the BCE described in section 5.1 of the Proxy Mobile IPv6 base specification [RFC5213] to be extended. To support this specification, the BCE must be extended with the following three additional fields. o A flag indicating whether GRE encapsulation is enabled for the mobile node's traffic flows. Muhanna, et al. Expires May 25, 2009 [Page 9] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 o The Downlink GRE Key, assigned by the MAG and used in the GRE encapsulation header of the tunneled packet from the local mobility anchor to the mobile access gateway. o The Uplink GRE Key, assigned by the LMA and used in the GRE encapsulation header of the tunneled packet from the mobile access gateway to the local mobility anchor. 5.2. Operational Summary o After successfully processes a Proxy Binding Update message with the GRE Key option which includes a downlink GRE key in the GRE Key Identifier field for Initial GRE Key exchange as in Section 3.3.1, the local mobility anchor MUST include the GRE Key option with the uplink GRE key in the GRE Key Identifier field when responding with a successful Proxy Binding Acknowledgement message. o If the GRE tunneling is negotiated and the downlink and uplink GRE keys have been exchanged between the mobile access gateway and the local mobility anchor for a specific binding, the local mobility anchor MUST use the negotiated downlink GRE key in the GRE header of every packet that is destined to the mobile node of this specific binding over the GRE tunnel to the mobile access gateway. o If the received Proxy Binding Update message does not contain the GRE Key option, and if the local mobility anchor determines that GRE encapsulation and GRE key is required, e.g., overlapping IPv4 private addressing is in use, LMA local policy or LMA-MAG peer policy, the local mobility anchor MUST reject the request and send the Proxy Binding Acknowledgement message to the mobile access gateway with the status code as defined in Section 6.2, indicating that GRE encapsulation and GRE key is required. o If after receiving Proxy Binding Update message with the GRE Key option and successfully processes the Proxy Binding Update, the local mobility anchor determines that GRE encapsulation and key exchange is not required for this specific binding, e.g., private IPv4 addressing is not in use, the LMA MUST send a Proxy Binding Acknowledgement message to the MAG with the status code . The local mobility anchor MUST NOT include the GRE Key option. o If the local mobility anchor successfully processes a deregistration Proxy Binding Update message which contains a GRE Key option with a downlink GRE key included, the LMA follows the same deregistration process as per the base Proxy Mobile IPv6 Muhanna, et al. Expires May 25, 2009 [Page 10] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 specification [RFC5213] to clean the binding cache entry and all associated resources including the downlink and uplink GRE keys. o On receiving a packet from the tunnel with the GRE encapsulation header, the local mobility anchor MUST use the GRE Key present in the GRE extension header to determine the necessary special processing for the data packet, e.g., lookup the mobile node's home gateway address, determine any special processing or treatment for the data packet flow, then remove the encapsulation header before forwarding the packet. 6. Message Formats This section defines an extension to the Mobile IPv6 [RFC3775] protocol messages. The use of GRE Key option for supporting GRE tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in this document. 6.1. GRE Key Option A new mobility option, the GRE Key option, is defined for use in the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between the mobile access gateway and the local mobility anchor. This option can be used for negotiating GRE encapsulation mode and exchanging the downlink and uplink GRE keys that can be used by the peers in all GRE encapsulated packets for marking that specific mobile node's data flow. The alignment requirement for this option is 4n. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GRE Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: GRE Key Option Type Muhanna, et al. Expires May 25, 2009 [Page 11] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 Length 8-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. If the Length field is set to 2, it indicates that the GRE key is not being carried in the option. If the length field is set to a value of 6, it means that either the downlink or the uplink GRE key is carried. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. GRE Key Identifier 32-bit field containing the Downlink or the Uplink GRE Key. This field is present in the GRE Key option only if the GRE keys are being exchanged using the Proxy Binding Update and Proxy Binding Acknowledgement messages. 6.2. Status Codes The following status code values are defined for use in the Binding Acknowledgment message when using Proxy Mobile IPv6. GRE KEY OPTION NOT REQUIRED (TBD less than 128) When the local mobility anchor receives a Proxy Binding Update with the GRE Key option while the GRE encapsulation is not required for this specific mobile node, the LMA uses this code to indicate to the mobile access gateway that the Proxy Binding Update has been processed successfully but GRE Encapsulation and GRE Key is not required. GRE KEY OPTION REQUIRED (TBD more than 128) When the local mobility anchor receives a Proxy Binding Update without the GRE Key option while the GRE encapsulation is required for this specific mobile node, the local mobility anchor uses this code to reject the Proxy Binding Update and indicate to the mobile access gateway that GRE Encapsulation and Keys is required. Muhanna, et al. Expires May 25, 2009 [Page 12] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 7. IANA Considerations This document defines a new Mobility Option, the GRE Key Option, described in Section 6.1. This option is carried in the Mobility Header. The type value for this option needs to be assigned from the same numbering space as allocated for the other mobility options defined in the Mobile IPv6 specification [RFC3775]. This document also defines two new Binding Acknowledgement status codes as described in Section 6.2 and requests that these two codes be allocated with numeric values as specified in Section 6.2 from the "Status Codes" registry of the Mobility IPv6 Parameters located at http://www.iana.org/assignments/mobility-parameters. 8. Security Considerations The GRE Key Option, defined in this document, that can be carried in Proxy Binding Update and Proxy Binding Acknowledgement messages, reveals the group affiliation of a mobile node identified by its NAI or an IP address. It may help an attacker in targeting flows belonging to a specific group. This vulnerability can be prevented, by enabling confidentiality protection on the Proxy Binding Update and Proxy Binding Acknowledgement messages where the presence of the NAI and GRE Key Options establish a mobile node's relation to a specific group. This vulnerability can also be avoided by enabling confidentiality protection on all the tunneled data packets between the mobile access gateway and the local mobility anchor, for hiding all the markings. 9. Acknowledgements The authors would like to thank Alessio Casati, Barney Barnowski, Mark Grayson and Parviz Yegani for their input on the need for this option. The authors would like to thank Charlie Perkins, Curtis Provost, Irfan Ali, Jouni Korhonen, Julien Langanier, Kuntal Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review and comments. 10. Normative References [ID-PMIP6-IPv4] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05 (work in progress), September 2008. Muhanna, et al. Expires May 25, 2009 [Page 13] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Authors' Addresses Ahmad Muhanna Nortel 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Mohamed Khalil Nortel 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: mkhalil@nortel.com Muhanna, et al. Expires May 25, 2009 [Page 14] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 Sri Gundavelli Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: kleung@cisco.com Muhanna, et al. Expires May 25, 2009 [Page 15] Internet-Draft GRE Key Option for Proxy MIPv6 November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Muhanna, et al. Expires May 25, 2009 [Page 16]