Network Working Group Internet Draft Vikas Goel Archana P.V. Arun H.S. Document: draft-goel-mip4-encapext-00.txt Huawei Technologies India Expires: July 10, 2005 January 2005 Encapsulation Extension for Mobile IPv4 draft-goel-mip4-encapext-00.txt Status of this Memo This document is a submission by the IETF MIPv4 Working Group Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mip4@ietf.org mailing list. This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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. Abstract This document specifies a new extension for use by Mobility Agents operating Mobile IP for IPv4 [ii]. The new extension allows home agent to specify the kind of encapsulation type it supports currently. This extension is supplied within the Registration Reply message. The mobility agent SHOULD relay this extension to mobile node. In this way, mobile node and Foreign Agent discover the encapsulation type to be used with the home agent. Goel, et al. Expires û July 10, 2005 [Page 1] Internet-Draft Encapsulation Extension for Mobile IPv4 January 2005 Conventions used in this document 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 [i]. Other terminology is used as already defined in [ii]. Table of Contents 1. Introduction...................................................2 2. Encapsulation Type Extension Format............................2 3. Operation and Use of the Encapsulation Extension...............3 4. Home Agent Considerations......................................3 5. Foreign Agent Considerations...................................4 6. Mobile Node Considerations.....................................4 7. IANA Considerations............................................4 8. Security Considerations........................................4 References........................................................5 9. Acknowledgments................................................5 A. Encapsulation Type Selection Function..........................5 Author's Addresses................................................5 1. Introduction This document specifies a new non-skippable extension for use by Mobility Agent operating Mobile IP for IPv4 [ii]. The new extension allows home agent to specify the kind of encapsulation type it supports currently. This extension is supplied within the Registration Reply message. The mobility agent SHOULD relay this extension to mobile node. In this way, mobile node and Foreign Agent discover the encapsulation type to be used with the home agent. 2. Encapsulation Type Extension Format The format of the Encapsulation Extension conforms to the Short Extension format specified for Mobile IPv4 [ii]. The Encapsulation Extension is not skippable. 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 | Sub-Type |r|r|r|M|G|r|r|r| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Goel, et al. Expires - July 2005 [Page 2] Internet-Draft Encapsulation Extension for Mobile IPv4 January 2005 Type Length 2 Sub-Type 0 M Minimal encapsulation. The home agent supports Minimal-IP encapsulation type. G GRE encapsulation. The home agent supports GRE encapsulation type. r Reserved. SHOULD be sent as 0 and ignored on reception. 3. Operation and Use of the Encapsulation Extension The Encapsulation extension is only valid for use within Mobile IPv4 Registration Reply messages. The Encapsulation Extension is not skippable. A mobile node can request for Minimal-IP, GRE and/or IPinIP type of encapsulation during registration [ii]. The Home Agent can choose any one type of encapsulation among the above mentioned types. The algorithm to choose a particular type of encapsulation is outside the scope of this document. Home Agent SHOULD set 'M' or 'G' bit depending upon the type of encapsulation selected. If IPinIP encapsulation is selected, both 'M' and 'G' bits SHOULD be set to zero. If both 'M' and 'G' bits are set then the foreign agent SHOULD reject the registration reply message. The foreign agent MAY forward this extension in the Registration Reply to the mobile node. This extension MUST appear after the Mobile-Home Authentication extension. If the Home Agent has a security association with the Foreign Agent, it MUST appear before the Foreign-Home Authentication extension. 4. Home Agent Considerations Goel, et al. Expires - July 2005 [Page 3] Internet-Draft Encapsulation Extension for Mobile IPv4 January 2005 If a Home Agent that doesnÆt support either Minimal-IP or GRE encapsulation receives registration request with both 'M' and 'G' bit set, then it MUST choose the encapsulation it supports. It sends a successful registration reply (status code 0 or 1) to Foreign Agent with Encapsulation Extension indicating the encapsulation used by Home Agent. 5. Foreign Agent Considerations If a Foreign Agent receives a successful Registration Reply (status code 0 or 1), with an Encapsulation extension from Home Agent, the foreign agent SHOULD then use corresponding encapsulation type for creating the tunnel between Home Agent and itself, till the visitor list entry corresponding to mobile node expires. In case of co- located registration, Foreign Agent MUST relay the encapsulation extension in the registration reply message to mobile node. 6. Mobile Node Considerations If a mobile node receives a successful Registration Reply (status code 0 or 1), with an Encapsulation extension, the mobile node SHOULD then use corresponding encapsulation type for tunneling the packets, till it re-registers with the home agent. Mobile node MUST follow this if mobile node is using Co-Located care of address. 7. IANA Considerations This specification reserves one number for the Encapsulation extension (see section 3) from the space of numbers for non-skippable mobility extensions (i.e., 0-127) defined in the specification for Mobile IPv4 [ii]. This specification also creates a new number space of sub-types for the type number of this extension. Sub-type two is to be allocated from this number space for the protocol extension specified in this document. Future allocations from this number space require IETF consensus. 8. Security Considerations The extensions outlined in this document are subject to the security considerations outlined in the Mobile IP specification [ii]. No further security risks have been introduced. Goel, et al. Expires - July 2005 [Page 4] Internet-Draft Encapsulation Extension for Mobile IPv4 January 2005 References [i] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997 [ii] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 3344, Internet Engineering Task Force, August 2002. All references are normative. 9. Acknowledgments Our sincere thanks to Keshava A.K. for his guidance, support and review during the development of this specification. A. Encapsulation Type Selection Function This appendix introduces a new function named the Encapsulation Type Selection Function that can dynamically select an encapsulation type at the Home Agent. Home Agent assigns precedence to each of the encapsulation types and selects the encapsulation type with highest precedence among the requested types. Author's Addresses Vikas Goel Huawei Technologies India Pvt. Ltd. Level-3, The Leela Palace Bangalore - 560007 Phone: +91-80-25217152 Email: vikasg@huawei.com Archana P.V. Huawei Technologies India Pvt. Ltd. Level-3, The Leela Palace Bangalore - 560007 Phone: +91-80-25217152 Email: archana_p@huawei.com Goel, et al. Expires - July 2005 [Page 5] Internet-Draft Encapsulation Extension for Mobile IPv4 January 2005 Arun H.S. Huawei Technologies India Pvt. Ltd. Level-3, The Leela Palace Bangalore - 560007 Phone: +91-80-25217152 Email: hs_arun@huawei.com Disclaimer of Validity "Copyright (C) The Internet Society (year). 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." Goel, et al. Expires - July 2005 [Page 6]