Internet DRAFT - draft-goel-mip4-encapext
draft-goel-mip4-encapext
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
<To Be Assigned by IANA>
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]
