Personal G. Tsirtsis
V. Park
V. Narayanan
Internet Draft Qualcomm
K. Leung
Cisco
Document: draft-tsirtsis-nemov4-fa-00.txt
Expires: December 2006 June 2006
FA extensions to NEMOv4 Base
draft-tsirtsis-nemov4-fa-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 max 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 October 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
<Tsirtsis, Park, Narayanan, Leung> `1
<FA Extensions to NEMOv4 base> <June> <2006>
Abstract
The base NEMOv4 specification [NEMOv4] defines extensions to Mobile
IPv4 [MIPv4] for mobile networks. NEMOv4 extensions are defined for
use only by the mobile node and the home agent. This specification
introduces extensions for NEMO support on the foreign agent.
Acknowledgements
Alexandru Petrescu co-authored with Vidya (one of the co-authors of
this I-D) an older document which included some of the mechanisms
described herein.
INDEX
1. Introduction.......................................................3
2. Extension Formats..................................................3
2.1. NEMOv4 Tunneling Extension.......................................4
3. Mobile IP Registrations............................................4
3.1. Registration Requests............................................4
3.2. Registration Reply...............................................5
3.3. Home Agent Considerations........................................5
3.4. Foreign Agent Considerations.....................................6
3.5. Mobile Client Considerations.....................................7
3.6. Disparate Address Space Support..................................8
4. Security Considerations............................................8
5. References.........................................................9
Author's Addresses....................................................9
Intellectual Property Statement......................................10
<Tsirtsis, Park, Narayanan, Kent> 2
<FA Extensions to NEMOv4 base> <June> <2006>
1. Introduction
The base NEMOv4 specification [NEMOv4] defines extensions to Mobile
IPv4 [MIPv4] for mobile networks. NEMOv4 extensions are defined for
use only by the mobile node and the home agent so there are no
extensions defined for NEMOv4 support by foreign agent.
NEMOv4 solution [NEMOv4] defines:
- When the co-located care-of address model is used, traffic
to/from the mobile network prefixes can be sent over a
bidirectional tunnel between the mobile node's care-of
address and the home agent address.
- When the care-of address model is used, traffic to/from the
mobile network prefixes must be sent over a bidirectional
tunnel between the mobile's home address and the home agent
address. This results in double tunneling since traffic to
the mobile's home address is encapsulated inside the tunnel
between the mobile node's care-of address and home agent
address.
Extensions defined in this document allow the mobile node and/or a
foreign agent to indicate to the home agent what address should be
used for tunneling traffic to the mobile network prefixes during
registration. Thus, this specification removes the need for double
encapsulation when a foreign agent is used.
2. Extension Formats
The following extension is defined according to this specification.
<Tsirtsis, Park, Narayanan, Kent> 3
<FA Extensions to NEMOv4 base> <June> <2006>
2.1. NEMOv4 Tunneling Extension
A new skippable extension to the Mobile IPv4 header in accordance to
the short extension format of [MIPv4] is defined here.
The presence of this extension indicates that the sender
supports the NEMOv4 and the tunnel selection extensions defined
in this specification.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
NEMOv4 Type [NEMOv4]
Length
4
Sub-Type
TBA (NEMOv4 Tunneling Extension)
Reserved
Set to 0 by the sender and ignored by the receiver.
3. Mobile IP Registrations
3.1. Registration Requests
A mobile node that supports [NEMOv4] and this specification MAY
include exactly one NEMOv4 tunneling extension when it uses the co-
located care-of address mode.
When the NEMOv4 tunneling extension is used by the mobile node, it
MUST be placed after the registration request header and before the
<Tsirtsis, Park, Narayanan, Kent> 4
<FA Extensions to NEMOv4 base> <June> <2006>
mobile - home authentication extension so, it MUST be included in
the computation of any authentication extension.
A foreign agent that supports this specification MAY include a
NEMOv4 tunneling extension defined in the specification in a
registration request when the care-of address mode of operation is
used.
When the NEMOv4 tunneling extension is used by a foreign agent it
MUST be placed after the mobile - home authentication extensions and
before the foreign - home authentication extension so it MUST be
included in the computation of the foreign - home authentication
extension when one exists.
3.2. Registration Reply
A foreign agent that supports this specification MAY include a
NEMOv4 tunneling extension defined in the specification in a
registration reply message
When a NEMOv4 tunneling extension is used by a home agent it MUST be
placed after the registration reply header and before the mobile -
home authentication extension so, it must be included in the
calculation of any authentication extension.
3.3. Home Agent Considerations
A home agent that supports the extensions in this specification MUST
act as in [NEMOv4] with the addition to the tunneling mode selection
defined below.
Tunneling mode selection, for mobile network traffic, depends on the
following parameters in a valid registration request:
1) Registration request is received with one or more Mobile Network
Extensions [NEMOv4]. A NEMOv4 tunneling extension is NOT included.
All mobile network traffic MUST be tunneled by the home agent
to the registered home address of the mobile. The home agent
MUST NOT include a NEMOv4 tunneling extension in the
registration reply and it MUST be prepared to accept reverse
tunneled packets from the IPv4 home address of the mobile
encapsulating packets sent by the mobile node.
<Tsirtsis, Park, Narayanan, Kent> 5
<FA Extensions to NEMOv4 base> <June> <2006>
2) Registration request is received with one or more Mobile Network
Extensions [NEMOv4]. A NEMOv4 tunneling extension is included.
All mobile network traffic SHOULD be tunneled by the home agent
to the registered care-of address of the mobile. In that case,
the home agent SHOULD include the NEMOv4 Tunneling extension in
the registration reply message and it MUST be prepared to
accept reverse tunneled packets from the care-of address of the
mobile encapsulating packets sent by the mobile network.
Alternatively, the home agent MAY ignore the presence of the
NEMOv4 Tunneling extension and act as in case (1) above.
As defined in [NEMOv4], for each mobile network extension included
in a valid registration request, a home agent that supports this
specification includes a corresponding mobile network
acknowledgement extension.
3.4. Foreign Agent Considerations
When a foreign agent receives a registration request with [NEMOv4]
extensions it has the following options:
Ignore the [NEMOv4] extension(s). The registration request is
forwarded as is with no NEMOv4 Tunneling extension to the home
agent.
Attach a NEMOv4 tunneling extension to the registration request
sent to the home agent.
If the foreign agent sets the R flag included in the mobility agent
advertisement [MIPv4] and a mobile client uses the co-located
address model, the foreign agent MUST NOT include a NEMOv4 tunneling
extension in the registration request messages sent from that mobile
client.
When a successful Registration Reply is received the foreign agent
MUST act as defined by [MIPv4]. In addition to that and according to
this specification the foreign agent SHOULD check for a NEMOv4
Tunnel extension.
If the NEMOv4 Tunnel extension is included then the foreign
agent MUST establish a bidirectional tunnel. The tunnel
endpoints are the care-of address of the foreign agent and the
address of the home agent. In addition to setting up a bi-
directional tunnel with the home agent, the foreign agent
<Tsirtsis, Park, Narayanan, Kent> 6
<FA Extensions to NEMOv4 base> <June> <2006>
locally establishes forwarding information such that all
packets originated by the clients in the mobile network, or
originated by the mobile router itself (i.e., packets with
source address any address under the registered prefixes for
that mobile router) and destined to any correspondent node
whose address is topologically correct outside the mobile
network are encapsulated through the bi-directional tunnel.
Note that registered prefixes are only the prefixes accepted by
Mobile Network Acknowledgement Extensions, with Code field set
to "0", included in the Registration Reply message.
If the NEMOv4 Tunnel extension is not included then the foreign
agent SHOULD operate as defined in [MIPv4] and [NEMOv4].
3.5. Mobile Client Considerations
A mobile router that supports the [NEMOv4] extensions may use these
extensions to register its mobile networks as defined in [NEMOv4].
The mobile client MAY include exactly one NEMOv4 tunneling extension
if it uses the co-located care-of address model, if it wants to
specifically request that packets to the mobile network are tunneled
to its co-located care-of address. Note that if the mobile client
uses the co-located care-of address model but it does not include
the NEMOv4 tunneling extension, according to [NEMOv4], the home
agent MAY tunnel mobile network packets to the mobile client's home
address.
[NEMOv4] also defines the mobile client processing when a
registration reply is received. In addition that what is defined in
[NEMOv4], the following processing MUST be done by the mobile client
according to this specification.
If NEMOv4 Tunnel extension is not included, the mobile client
MUST act as defined by [NEMOv4]
If NEMOv4 Tunnel extension is included then the mobile client
MUST act as follows:
If the care-of address mode is used, the mobile client
MUST be prepared to send/receive traffic from/to the
mobile network on its interface natively, unless reverse
tunnel has been negotiated in which case all traffic
MUST be reverse tunneled according to [REVTUN].
<Tsirtsis, Park, Narayanan, Kent> 7
<FA Extensions to NEMOv4 base> <June> <2006>
If the co-located care-of address mode is used, the
mobile client MUST be prepared to send/receive packets
from/to the mobile network over the bidirectional tunnel
between the home agent address and its co-located care-
of address.
3.6. Disparate Address Space Support
Mobile IP [MIPv4] assumes that all the entities involved have
addresses within the same globally unique space. In many deployment
scenarios this is not the case, either because of the use of private
address space or because of the use of public address space that is
only advertised in not advertised globally. The analysis and
suggestions on how to deal with such deployments included in
Appendix A of [REVTUN] apply in this specification if the prefixes
that a mobile node successfully registers according to [NEMOv4] and
this specification are treated in the same way [REVTUN] treats the
home address of the mobile node.
4. Security Considerations
This specification operates in the security constraints and
requirements of [MIPv4] and [NEMOv4].
A foreign agent that supports this specification SHOULD perform
ingress filtering on all the packets received from the mobile router
prior to reverse tunneling them to the Home Agent. The foreign
agent SHOULD drop any packets that do not have a source address
belonging to one of the registered prefixes. For traffic coming
from the home agent and if the foreign agent has included a NEMOv4
Tunneling extension in the registration request, the foreign agent
MUST be prepared to accept encapsulated packets to the home address
of the a registered mobile router as well as to any address under
any of the registered prefixes for the same mobile router.
<Tsirtsis, Park, Narayanan, Kent> 8
<FA Extensions to NEMOv4 base> <June> <2006>
5. References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344
[NAI] P.Calhoun, C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC2794
[NEMOv4] K. Leung, et al,, "IPv4 Network Mobility (NEMO) Basic
Support Protocol", Feb 06
[REVTUN] G. Montenegro, "Reverse Tunneling for Mobile IP,
revised", RFC3024
Author's Addresses
George Tsirtsis
Qualcomm Inc
Phone: +908-947-7059
Email1: tsirtsis@qualcomm.com
Email2: tsirtsisg@yahoo.com
Vincent Park
Qualcomm Inc
Phone: +908-947-7084
E-mail: vpark@qualcomm.com
Vidya Narayanan
Qualcomm Inc
Phone:
E-mail:vidyan@qualcomm.com
Kent Leung
Cisco Systems
Phone: 408-526-5030
E-mail:kleung@cisco.com
<Tsirtsis, Park, Narayanan, Kent> 9
<FA Extensions to NEMOv4 base> <June> <2006>
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
<Tsirtsis, Park, Narayanan, Kent> 10