MEXT WG S. Gundavelli Internet-Draft K. Leung Intended status: Standards Track Cisco Expires: August 20, 2008 February 17, 2008 GRE Tunnel Request Option for Mobile IPv6 draft-sgundave-mext-gre-tunnel-request-option-00.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 August 20, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies a new mobility option for use in Mobile IPv6 Binding Update and Binding Acknowledgement messages. This option can be used by a mobile node or a mobile router to request the home agent to enable GRE encapsulation mode for the datagram tunneling. The GRE encapsulation mode can be negotiated for IPv6 transport and also for the IPv4 transport when using Dual-Stack Mobile IPv6 extensions. Gundavelli & Leung Expires August 20, 2008 [Page 1] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. GRE Tunneling and Encapsulation Procedures . . . . . . . . . . 3 4. Signaling Considerations . . . . . . . . . . . . . . . . . . . 4 4.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 4 4.2. Home Agent Considerations . . . . . . . . . . . . . . . . 5 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. GRE Tunnel Request Option . . . . . . . . . . . . . . . . 5 5.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Gundavelli & Leung Expires August 20, 2008 [Page 2] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 2008 1. Introduction The base Mobile IPv6 specification requires IPv6-in-IPv6 [RFC-2473] encapsulation mode for tunneling mobile node's data traffic between the home agent and the mobile node. Additionally, the Dual-Stack Mobile IPv6 specification defines other encapsulation modes over IPv4 or IPv4-UDP-TLV delivery modes. However, there are scenarios where these encapsulation modes are not sufficient and there is a need for an encapsulation mode with richer semantics. The Generic Routing Encapsulation [RFC-2784] and coupled with the extension, Key and Sequence Number extension [RFC-2890], has the required semantics for applying additional considerations by the tunnel end-points on the carried flows. Following are some of the key uses of GRE encapsulation header: o GRE header processing support availability in most hardware o The GRE key carried in the GRE header can be used by the tunnel end points for applying differential treatment on the carried flow. Ex: A mobile router using different key for different mobile network prefix flows. o Carrying legacy protocol traffic over the GRE tunnel o Use of Sequence Number field for handling real time traffic This document defines extensions to Mobile IPv6 specification for allowing mobile node and home agent to negotiate GRE encapsulation mode and for exchanging the GRE keys that can be used for coloring the encapsulated traffic. 2. Conventions used in this document The keywords "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 [4]. All the mobility related terms used in this document are to be interpreted as defined in Mobile IPv6 specification [RFC-3775]. 3. GRE Tunneling and Encapsulation Procedures As per the base Mobile IPv6 specification [RFC-3775], the encapsulation mode that is used for tunneling the mobile node's IPv6 Gundavelli & Leung Expires August 20, 2008 [Page 3] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 2008 traffic is IPv6-In-IPv6 [RFC-2473] When using the Dual-Stack Mobile IPv6 [ID-DSMIP6] extensions for using IPv4 transport, the encapsulation modes that will be used are IPv6-In-IPv4 or IPv6-In-IPv4-UDP-TLV (for NAT traversal). And when using IPv4 home addressing, the encapsulation mode that will be used are IPv4-In-IPv4, IPv4-in-IPv6 or IPv4-in-IPv4-UDP-TLV (for NAT traversal). When GRE tunneling [RFC-2784] is negotiated as per this specification, the semantics related to the tunnel transport is not impacted, but an additional GRE header is added above the payload packet as indicated below. +---------------------------+ | Delivery Header | | | |IPv4, IPv4-UDP-TLV or IPv6 | +---------------------------+ | | | GRE Header with | | Key Sequence Number Ext | +---------------------------+ +---------------------------+ | | | | | Payload Packet | ====> | Payload Packet | | (IPv4 or IPv6) | | (IPv4 or IPv6) | +---------------------------+ +---------------------------+ Figure 1: GRE Encapsulation 4. Signaling Considerations 4.1. Mobile Node Considerations 1. The GRE Tunnel Request option MAY be used in the Binding Update messages sent by the mobile node to the home agent. The purpose of this extension is to request the home agent to enable GRE tunneling. 2. If the mobile node includes the GRE Tunnel Request option in the Binding Update message, but it receives a Binding Acknowledgement Gundavelli & Leung Expires August 20, 2008 [Page 4] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 2008 message with the Status Code value set to GRE_TUNNELING_NOT_SUPPORTED, the mobile node MUST assume the home agent does not support GRE tunneling mode. 3. If the mobile node includes the GRE Tunnel Request option in the Binding Update message, but it receives a Binding Acknowledgement message with the Status Code value to set to 0 (Binding Update Accepted), but without a GRE Tunnel Request option, the mobile node MUST assume the home agent does not support GRE tunneling. 4. The mobile node at each re-registration (when there is movement or when there is no movement) MUST include the GRE Tunnel Request extension, if it desires to keep GRE tunneling. 4.2. Home Agent Considerations 1. The GRE Tunnel Request option MUST be present in the Binding Acknowledgement message sent by the home agent to the mobile node, if the same option was present in the received Binding Update message and if the home agent has accepted the GRE tunneling request. 2. If the home agent receives a Binding Update message from the mobile node with the GRE Tunnel Request option, but if the home agent does not support GRE encapsulation mode, it MUST reject the request and send the Binding Acknowledgement message with the Status Code value set to GRE_TUNNELING_NOT_SUPPORTED. 5. Message Formats This section defines extensions to the Mobile IPv6 [RFC-3775] protocol messages. 5.1. GRE Tunnel Request Option A new option, GRE Tunnel Request option is defined for using it in the Mobile IPv6 Binding Update and Binding Acknowledgement messages exchanged between a home agent and a mobile node. This option is used for requesting GRE tunneling and optionally for specifying a GRE key that can be used in the GRE Key and Sequence number extension, if the same is enabled in the GRE header. The alignment requirement for this option is 4n. Gundavelli & Leung Expires August 20, 2008 [Page 5] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 2008 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length 8-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. The value for this field MUST be set to 6. Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. GRE Key A 32-bit field containing the GRE Key. The value of this field MUST be set to ALL_ZERO, when the GRE Key and Sequence Number extension is not going to be enabled in the GRE header. Figure 2: GRE Tunnel Request Option 5.2. Status Codes This document defines the following new Status values for use in Binding Acknowledgement message. These values are to be allocated from the same number space, as defined in Section 6.1.8 [RFC-3775]. GRE_TUNNELING_NOT_SUPPORTED: The home agent does not support GRE Tunneling Gundavelli & Leung Expires August 20, 2008 [Page 6] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 2008 6. IANA Considerations This document defines a new Mobility Header options, the GRE Tunnel Request option. This option is described in Section 4. The Type value for this option needs to be assigned from the same numbering space as allocated for the other mobility options, as defined in [RFC-3775]. 7. Security Considerations This specification allows a mobile node and a home agent to negotiate GRE encapsulation mode, by carrying the GRE Tunnel Request option in the Binding Update and Binding Acknowledgement messages. This option is carried like any other mobility header option as specified in [RFC-3775] and does not require any special security considerations. The Binding Update and Binding Acknowledgement messages carrying the GRE Tunnel Request option and the mobile node's payload packets carried with the GRE encapsulation header are to be protected as described in [RFC-4877]. This specification does not add any new vulnerability to Mobile IPv6 protocol. 8. Acknowledgements The authors would like to thank Ahmad Muhanna, Alex Petrescu, Hesham Soliman for all the discussions related to GRE tunneling support in the MIP6 mailing list. 9. References 9.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. Gundavelli & Leung Expires August 20, 2008 [Page 7] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 2008 [RFC-2784] Farinacci, D., et al., "Generic Routing Encapsulation", RFC-2784, March 2000. [RFC-2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2003. [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC-4877] V. Devarapalli and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", April 2007. [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-00.txt, July 2008. 9.2. Informative References [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [MIP4-GRE-KEY-NEGO] Yegnani, P. et.al, "GRE Key Option for Mobile IPv6", draft-yegnani-gre-key-extension-02.txt (Work in progress), September 2007. [PMIP6-GRE-KEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K., "GRE Key Option for Proxy Mobile IPv6", October 2007. Authors' Addresses Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Gundavelli & Leung Expires August 20, 2008 [Page 8] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 2008 Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: kleung@cisco.com Gundavelli & Leung Expires August 20, 2008 [Page 9] Internet-Draft GRE Tunnel Request Option for Mobile IPv6 February 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). Gundavelli & Leung Expires August 20, 2008 [Page 10]