Network Working Group Y. El Mghazli Internet-Draft Alcatel Intended status: Standards Track October 16, 2006 Expires: April 19, 2007 MIPv4 tunneling extensions draft-yacine-mip4-tunnel-ext-00 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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). El Mghazli Expires April 19, 2007 [Page 1] Internet-Draft MIPv4 tunneling extensions October 2006 Abstract Mobile IPv4 lacks the capability to dynamically configure the tunnel type and to configure tunnel-specific options and parameters. This document describes a new MIPv4 registration extension that allows a, mobile node or a foreign agent to provide tunnel information to the home agent. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tunneling extension . . . . . . . . . . . . . . . . . . . . . 4 3. Tunneling Sub-Types . . . . . . . . . . . . . . . . . . . . . 5 3.1. GRE Tunneling . . . . . . . . . . . . . . . . . . . . . . 5 3.2. IP-in-IP Tunneling . . . . . . . . . . . . . . . . . . . . 5 3.3. Minimal Encapsulation . . . . . . . . . . . . . . . . . . 6 4. Processing of Tunneling extension . . . . . . . . . . . . . . 7 4.1. Foreign Agent considerations . . . . . . . . . . . . . . . 7 4.2. Home Agent considerations . . . . . . . . . . . . . . . . 7 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 El Mghazli Expires April 19, 2007 [Page 2] Internet-Draft MIPv4 tunneling extensions October 2006 1. Introduction When a mobile node detects that it has moved to a foreign network, it obtains a care-of address on the foreign network. The care-of address can either be determined from a foreign agent's advertisements (a foreign agent care-of address), or by some external assignment mechanism such as DHCP [RFC2131] (a co-located care-of address). The mobile node operating away from home then registers its new care-of address with its home agent through exchange of a Registration Request and Registration Reply message with it, possibly via a FA. Datagrams sent to the mobile node's home address are intercepted by its home agent, tunneled by the home agent to the mobile node's care-of address, received at the tunnel endpoint (either at a foreign agent or at the mobile node itself), and finally delivered to the mobile node. As per [RFC3344], the tunneling type is specified by the MN, using flags when sending its Registration Request. This document defines a MIPv4 registration extension that allows the MN and/or the FA to provide additional tunneling information to the HA. El Mghazli Expires April 19, 2007 [Page 3] Internet-Draft MIPv4 tunneling extensions October 2006 2. Tunneling extension This section defines the Tunneling Extension which may be used in Mobile IP Registration Request and Reply messages. The extension may be used by a mobile node or a foreign agent that wants to specify tunneling options associated to a given tunneling type. This document also defines some subtype numbers which identify the specific type of tunnel in Section 3. It is expected that other types of NAI tunnels will be defined by other documents in the future. The extension has the format shown in this section to carry configuration information. 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 | Sub-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options +-+-+-+-+-+-... Type: IPV4-TUNNEL-EXT-TYPE to be assigned by IANA (skippable) Sub-Type: indicates the particular type of tunneling. Length: indicates the length (in bytes) of the Options field within this extension. The length does NOT include the Type, Length and Sub- Type bytes. Options: contains the configuration parameters that will be used to transmit information related to sub-type value option. El Mghazli Expires April 19, 2007 [Page 4] Internet-Draft MIPv4 tunneling extensions October 2006 3. Tunneling Sub-Types 3.1. GRE Tunneling The GRE tunneling uses subtype GRE-SUB-TYPE (to be assigned by IANA) of the Tunneling Extension. This sub-type is used to request the use of GRE encapsulation [RFC1701] by the home agent. In addition, the Options field MAY be used to request the use of a particular GRE key and possibly to activate GRE sequence number usage. The GRE Tunneling Options field has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |K|S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key-Identifier (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Support (bit 2): indicates that the Key-Identifier field is present in the GRE tunneling extension. Otherwise, the Key identifier is not present. Sequence Number Support (bit 3): indicates the home agent will insert a sequence number field in each GRE packets, as per [RFC1701]. Otherwise the sequence number GRE extension will not be used by the home agent. Key-Identifier: contains a four octet number which will be inserted by the home agent in each GRE packets, as per [RFC1701]. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. 3.2. IP-in-IP Tunneling The IP-in-IP tunneling uses subtype IP-IN-IP-SUB-TYPE (to be assigned by IANA) of the Tunneling Extension. This sub-type is used to request the use of IP-in-IP encapsulation [RFC2003] by the home agent. No Options field is associated with IP-in-IP tunneling extention. El Mghazli Expires April 19, 2007 [Page 5] Internet-Draft MIPv4 tunneling extensions October 2006 3.3. Minimal Encapsulation The Min-IP tunneling uses subtype MIN-IP-SUB-TYPE (to be assigned by IANA) of the Tunneling Extension. This sub-type is used to request the use of minimal encapsulation [RFC2004] by the home agent. No Options field is associated with Minimal encapsulation extention. El Mghazli Expires April 19, 2007 [Page 6] Internet-Draft MIPv4 tunneling extensions October 2006 4. Processing of Tunneling extension 4.1. Foreign Agent considerations Mobile IP defines two different registration procedures, one directly with the mobile node's home agent, and one via a foreign agent that relays the registration to the mobile node's home agent. Indeed, if a mobile node is registering a foreign agent care-of address or if a mobile node is using a co-located care-of address, and receives an Agent Advertisement (with 'R' bit set) from a FA on the link on which it is using this care-of address, the mobile node will register via that foreign agent. In this latter case, after reception of the Registration Request from the MN, the FA MAY itself mandate the use of a specific tunneling type and specify the associated configuration options by inserting the tunneling extension in the Registration Request. In case the Registration Request already contains a tunneling extension, sent by the mobile node, the FA can replace the existing extension by a new one, hence mandating the use of another tunneling technology and/or other tunneling options. 4.2. Home Agent considerations After reception of the Registration Request, the HA must analyse the tunnel-type in order to validate or not the FA tunnel proposal. If the tunnel type is accepted, the HA should also add a tunnel option extension in the registration reply, with the same tunnel-type. If the tunnel-type is refused from the HA, it must also add a tunnel option extension in the Registration Reply, and indicating the tunnel type it has chosen. The sub-type must only be used and analysed by HA when tunnel-type is accepted by the HA. The sub-type must only be inserted in the Registration Reply, when the tunnel-type proposed by FA is accepted by HA. In case the use of 'G' or 'M' bit, set by the mobile node, in the Registration Request are inconsistent with the information contained in the Tunneling extension, the home agent MUST consider only the information contained in the extension. El Mghazli Expires April 19, 2007 [Page 7] Internet-Draft MIPv4 tunneling extensions October 2006 5. IANA considerations This draft defines the following values: IPV4-TUNNEL-EXT-TYPE: new Mobile IPv4 extension as defined in Section 2 of this document. This value MUST be assigned by IANA from the Mobile IP numbering space for skippable extensions. GRE-SUB-TYPE IP-IN-IP-SUB-TYPE MIN-IP-SUB-TYPE El Mghazli Expires April 19, 2007 [Page 8] Internet-Draft MIPv4 tunneling extensions October 2006 6. Security considerations There are no additional security aspects imposed by this document in addition to the one defined in [RFC3344]. El Mghazli Expires April 19, 2007 [Page 9] Internet-Draft MIPv4 tunneling extensions October 2006 7. Acknowledgments Jean-Pierre Rombeaut. El Mghazli Expires April 19, 2007 [Page 10] Internet-Draft MIPv4 tunneling extensions October 2006 8. References 8.1. Normative References [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. 8.2. Informative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. El Mghazli Expires April 19, 2007 [Page 11] Internet-Draft MIPv4 tunneling extensions October 2006 Author's Address Yacine El Mghazli Alcatel Route de Nozay Marcoussis 91460 France Email: yacine.el_mghazli@alcatel.fr El Mghazli Expires April 19, 2007 [Page 12] Internet-Draft MIPv4 tunneling extensions October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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). El Mghazli Expires April 19, 2007 [Page 13]