Internet DRAFT - draft-mip4-nemov4-fa
draft-mip4-nemov4-fa
Network Working Group G. Tsirtsis
Internet-Draft V. Park
Intended status: Standards Track V. Narayanan
Expires: September 20, 2007 Qualcomm
K. Leung
Cisco
March 19, 2007
FA extensions to NEMOv4 Base
draft-mip4-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 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 September 20, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Tsirtsis, et al. Expires September 20, 2007 [Page 1]
Internet-Draft FA extensions to NEMOv4 Base March 2007
Abstract
The base NEMOv4 specification defines extensions to Mobile IPv4 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.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Extension Formats . . . . . . . . . . . . . . . . . . . . . . 6
4.1. NEMOv4 Tunneling Extension . . . . . . . . . . . . . . . . 6
5. Mobile IP registrations . . . . . . . . . . . . . . . . . . . 7
5.1. Registration Requests . . . . . . . . . . . . . . . . . . 7
5.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 7
5.3. Home Agent Considerations . . . . . . . . . . . . . . . . 7
5.4. Foreign Agent Considerations . . . . . . . . . . . . . . . 8
5.5. Mobile Client Considerations . . . . . . . . . . . . . . . 9
5.6. Disparate Address Space Support . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Tsirtsis, et al. Expires September 20, 2007 [Page 2]
Internet-Draft FA extensions to NEMOv4 Base March 2007
1. Requirements notation
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 [RFC2119].
Tsirtsis, et al. Expires September 20, 2007 [Page 3]
Internet-Draft FA extensions to NEMOv4 Base March 2007
2. Acknowledgments
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.
Tsirtsis, et al. Expires September 20, 2007 [Page 4]
Internet-Draft FA extensions to NEMOv4 Base March 2007
3. Introduction
3.1. Background
The base NEMOv4 specification [I-D.ietf-mip4-nemo-v4-base] defines
extensions to MIPv4 [RFC3344] 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 [I-D.ietf-mip4-nemo-v4-base] 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.
Tsirtsis, et al. Expires September 20, 2007 [Page 5]
Internet-Draft FA extensions to NEMOv4 Base March 2007
4. Extension Formats
The following extension is defined according to this specification.
4.1. NEMOv4 Tunneling Extension
A new skippable extension to the Mobile IPv4 header in accordance to
the short extension format of MIPv4 [RFC3344] 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 [I-D.ietf-mip4-nemo-v4-base]
Length
4
Sub-Type
TBA (NEMOv4 Tunneling Extension)
Reserved
Set to 0 by the sender and ignored by the receiver.
Tsirtsis, et al. Expires September 20, 2007 [Page 6]
Internet-Draft FA extensions to NEMOv4 Base March 2007
5. Mobile IP registrations
5.1. Registration Requests
A mobile node that supports [I-D.ietf-mip4-nemo-v4-base] 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
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.
5.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.
5.3. Home Agent Considerations
A home agent that supports the extensions in this specification MUST
act as in [I-D.ietf-mip4-nemo-v4-base] 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 [I-D.ietf-mip4-nemo-v4-base]. A NEMOv4 tunneling
extension is NOT included.
Tsirtsis, et al. Expires September 20, 2007 [Page 7]
Internet-Draft FA extensions to NEMOv4 Base March 2007
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.
2) Registration request is received with one or more Mobile Network
Extensions [I-D.ietf-mip4-nemo-v4-base]. 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 [I-D.ietf-mip4-nemo-v4-base], 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.
5.4. Foreign Agent Considerations
When a foreign agent receives a registration request with
[I-D.ietf-mip4-nemo-v4-base] extensions it has the following options:
Ignore the [I-D.ietf-mip4-nemo-v4-base] 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 [RFC3344] 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 [RFC3344]. In addition to that and
according to this specification the foreign agent SHOULD check for a
NEMOv4 Tunnel extension.
Tsirtsis, et al. Expires September 20, 2007 [Page 8]
Internet-Draft FA extensions to NEMOv4 Base March 2007
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 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 [RFC3344] and
[I-D.ietf-mip4-nemo-v4-base].
5.5. Mobile Client Considerations
A mobile router that supports the [I-D.ietf-mip4-nemo-v4-base]
extensions may use these extensions to register its mobile networks
as defined in [I-D.ietf-mip4-nemo-v4-base].
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
[I-D.ietf-mip4-nemo-v4-base], the home agent MAY tunnel mobile
network packets to the mobile client's home address.
[I-D.ietf-mip4-nemo-v4-base] also defines the mobile client
processing when a registration reply is received. In addition that
what is defined in [I-D.ietf-mip4-nemo-v4-base], 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 [I-D.ietf-mip4-nemo-v4-base]
If NEMOv4 Tunnel extension is included then the mobile client MUST
act as follows:
Tsirtsis, et al. Expires September 20, 2007 [Page 9]
Internet-Draft FA extensions to NEMOv4 Base March 2007
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].
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.
5.6. Disparate Address Space Support
MIPv4 [RFC3344] 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 [I-D.ietf-mip4-nemo-v4-base]
and this specification are treated in the same way [REVTUN] treats
the home address of the mobile node.
Tsirtsis, et al. Expires September 20, 2007 [Page 10]
Internet-Draft FA extensions to NEMOv4 Base March 2007
6. Security Considerations
This specification operates in the security constraints and
requirements of MIPv4 [RFC3344] and [I-D.ietf-mip4-nemo-v4-base].
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, et al. Expires September 20, 2007 [Page 11]
Internet-Draft FA extensions to NEMOv4 Base March 2007
7. Normative References
[I-D.ietf-mip4-nemo-v4-base]
Leung, K., "IPv4 Network Mobility (NEMO) Protocol",
draft-ietf-mip4-nemo-v4-base-00 (work in progress),
March 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
Tsirtsis, et al. Expires September 20, 2007 [Page 12]
Internet-Draft FA extensions to NEMOv4 Base March 2007
Authors' Addresses
George Tsirtsis
Qualcomm
Phone: +908-443-8174
Email: tsirtsis@qualcomm.com
Vincent Park
Qualcomm
Phone: +908-947-7084
Email: vpark@qualcomm.com
Vidya Narayana
Qualcomm
Phone: +858-845-2483
Email: vidyan@qualcomm.com
Kent Leung
Cisco
Phone: +408-526-5030
Email: kleung@cisco.com
Tsirtsis, et al. Expires September 20, 2007 [Page 13]
Internet-Draft FA extensions to NEMOv4 Base March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Tsirtsis, et al. Expires September 20, 2007 [Page 14]
