Internet DRAFT - draft-irtf-mobopts-ipv4ro
draft-irtf-mobopts-ipv4ro
MobOpts Research Group Rajeev Koodli
INTERNET DRAFT Nokia Research Center
11 July 2005
Mobile IPv4 Route Optimization Using Mobile IPv6 Return Routability
draft-irtf-mobopts-ipv4ro-00.txt
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 document is a submission of the IRTF MobOpts RG. Comments should
be directed to the MobOpts RG mailing list, mobopts@irtf.org.
Abstract
The motivation for this document comes from considerations in
implementing IPv6 Return Routability in an IPv4 network, especially
where the Mobile Node and the Correspondent Nodes are capable of
performing IPv6-in-IPv4 tunneling. As a result, this document
proposes an IPv4 Address extension to Mobile IPv6 Return Routability
procedure which can provide route optimization for IPv4 traffic.
Koodli Expires 11 January 2005 [Page i]
Internet Draft Mobile IPv4 Route Optimization 11 July 2005
Contents
Abstract i
1. Introduction and Problem Description 1
2. Reference Model and Assumptions 2
3. Protocol Operation 3
4. Message Formats 4
5. IANA Considerations 5
6. Security Considerations 5
7. Author's Address 6
Intellectual Property Statement 6
Disclaimer of Validity 6
Copyright Statement 7
Acknowledgment 7
1. Introduction and Problem Description
The Return Routability (RR) mechanism for Mobile IPv6 [1] specifies
a shared secret establishment between a Mobile Node (MN) and an
arbitrary Correspondent Node (CN) node on the Internet in order to
enable route-optimized communication between them. It does this
based on the assumption that the underlying routing infrastructure
is able to correctly route packets based on their destination
addresses. In other words, if a node can demonstrate that it is able
to receive packets at an address by responding to messages sent to
that address, assigning ownership of that address to the node cannot
make the current Internet less secure. In spite of its documented
weaknesses, Return Routability (RR) is generally accepted as the
default mechanism for route optimization with Mobile IPv6.
When looking into the practical deployment of RR, some interesting
considerations arise. First, the routing infrastructure is based
predominantly on IPv4. So, the routability of an IPv6 address is
determined, at least, in part by the ability to correctly associate
Koodli Expires 11 January 2005 [Page 1]
Internet Draft Mobile IPv4 Route Optimization 11 July 2005
the IPv6 address with the IPv4 address of the tunnel end-point
that actually forwards the IPv6 packet encapsulated in an IPv4
packet. The work in progress in the [v6ops] working group in IETF
is presumably addressing this issue. Second, most terminals for
which RR is of interest are likely going to be dual-stack. For
instance, most Mobile Nodes with Mobile IPv6 are expected to be
dual-stack, and those Correspondent Nodes which are not Mobile Nodes
themselves but support route-optimized communication are likely
going to be dual-stack. In deployments where this is valid, RR
can be accomplished by the end-points themselves without the need
for additional support for IPv6 tunneling from the infrastructure
elements. The use of IPv6 when routable IPv4 addresses are available
could be questioned. However, the nodes cannot use route-optimized
path even with globally routable IPv4 addresses. Finally, even if
the end-points themselves are not able to tunnel RR messages, route
optimization for IPv4 traffic deserves consideration given that
majority of the routing is based on IPv4. This motivates the need
for a solution that allows direct, route-optimized communication
using both IPv6 and IPv4 addresses.
In this document, we investigate the following problem: How to
enable route-optimized communication for IPv4 traffic using IPv6
RR. We provide a reference model and identify the extensions to the
existing RR mechanism.
2. Reference Model and Assumptions
In our model, a Correspondent Node is assumed to be capable
of performing IP-in-IP encapsulation and de-encapsulation.
Specifically, a CN is able to perform IPv6-in-IPv4 encapsulation and
de-encapsulation. A CN is the end-point for the IPv6-in-IPv4 tunnel.
A Home Agent is also an end-point for the IPv6-in-IPv4 tunnel. Note
that the CN and the HA need not be general-purpose tunnel end-points.
A Mobile Node need not be an IPv6-in-IPv4 tunnel end-point. The
Mobile Nodes learn about a CN's IPv4 address and IPv6 address via DNS
or by other means.
A single node acts as a Home Agent for both IPv4 and IPv6. In
other words, a MN's Home Agent has access to both the IPv4 and IPv6
binding and security information. It is not clear if a protocol
is necessary to access the IPv4 bindings from an IPv6 Home Agent
and vice-versa; in any case, such a protocol is beyond the scope of
this specification. Finally, the Home Agent is able to process new
Mobility Options this document specifies.
Koodli Expires 11 January 2005 [Page 2]
Internet Draft Mobile IPv4 Route Optimization 11 July 2005
3. Protocol Operation
When a MN sends the Care of Address Test Init (COTI) message, it
includes a new IPv4 CoA Mobility Header Option and a new IPv4 CN
Address Mobility Header Option. The IPv4 CoA is what the MN uses on
the visited network for its IPv4 traffic. The IPv4 CoA acts as the
tunnel end-point for the COTI (and the ensuing COT) message. When
the address is co-located with the MN's interface, the COTI message
is encapsulated and the COT message is de-encapsulated by the MN
itself. When the IPv4 address is not co-located with the MN, the
node offering the IPv4 address service for the MN MUST be able to
perform (de)encapsulation and correctly forward the tunneled IPv4
and IPv6 packets to the MN. When the IPv4 address is not co-located,
the node hosting the IPv4 address also needs to know the CN's IPv4
address to tunnel the COTI message to. One way to do this is by
having the tunnel end-point inspect the packets for Mobility Header
type, and process the new options when present. This operation is
not necessary when the MN itself can act as a tunnel end-point. In
any case, the COTI message with the new extension is encapsulated and
sent to the CN's IPv4 address. The source address of the tunnel is
the IPv4 CoA. As might be evident, the purpose of tunneling directly
to a CN's IPv4 address is to demonstrate to the CN that the MN is
reachable at the source IPv4 address of the tunnel.
When the MN sends the Home Addess Test Init (HOTI) message, it
includes a new IPv4 Home Address (HoA) option, as well as a new
IPv4 CN Address option. There are no specific IPv4 tunneling
requirements for the HOTI message. However, if the MN is the IPv4
tunnel end-point, it MAY tunnel the HOTI message directly to the Home
Agent's IPv4 address. In such a case, avoiding reverse tunneling
of HOTI using IPv6 addresses may be considered; however this has
implications on IPSec operations for the HOTI message. Specifically,
the IPSec association needs to be based on the MN's IPv4 CoA. For
transparent operation, the MN SHOULD encapsulate the IPSec protected
HOTI message using its IPv4 CoA. When the Home Agent receives the
HOTI message, it MUST process the new extensions. Note that the
Home Agent must be able to inspect the Next Header field anyway in
order to be able to apply IPSec. The proposal here requires the Home
Agent to also look for the new extension when the Next Header type
is Mobility Header, and perform the following operations. The Home
Agent MUST act as the IPv6-in-IPv4 tunnel end-point by including the
MN's HoA as the source IP address and the CN's IPv4 address as the
destination address for the tunnel. Both the addresses are present
in the new extension to HOTI. The Home Agent MUST ensure that a valid
binding exists for the IPv4 HoA before tunneling the packet to the
CN.
When the CN processes the new extension in COTI, it first compares
whether the IPv4 CoA in the extension is the same as the source
Koodli Expires 11 January 2005 [Page 3]
Internet Draft Mobile IPv4 Route Optimization 11 July 2005
address in the IPv4 tunnel. It then compares if the IPv4 CN address
in the extension is the same as its own IPv4 address present in
the destination address of the IPv4 tunnel. If both verifications
are true, it concatenates the IPv4 CoA to the other parameters in
generating the care-of keygen token. The CN then tunnels the Care of
Test (COT) message to the MN's IPv4 CoA.
When the CN processes the new extension in HOTI, it first compares
whether the IPv4 HoA in the extension is the same as the source
address in the IPv4 tunnel. It then compares if the IPv4 CN address
in the extension is the same as its own IPv4 address present in
the destination address of the IPv4 tunnel. If both verifications
are true, it concatenates the IPv4 HoA to the other parameters in
generating the home keygen token. The CN then tunnels the Home Test
(HOT) message to the MN's IPv4 HoA.
When the Home Agent receives the tunneled HOT message, it does the
following. Since the destination address in the outer packet is
IPv4 HoA, the IPv4 portion of the Home Agent operation requires
verification of presence of a tunnel, according to RFC 3344 (Section
4.2.3). In this case, the destination addresses are the ``same'' in
the tunneled and encapsulating packets. They belong to different IP
versions however. When the inner packet is of type IPv6, the inner
packet MUST be forwarded to Mobile IPv6 processing code, which in
turn applies IPSec and returns the HOT packet back to the Mobile IPv4
processing code. The Home Agent then changes the destination address
of the outer IPv4 packet to the IPv4 CoA corresponding to the IPv4
HoA.
The MN receives both the COT and HOT messages. The MN constructs the
Binding Update message. The MAC calculation MUST include the IPv4
CoA and the CN's IPv4 addresses. The MN MUST include the IPv4 HoA
and the IPv4 CoA as new Mobility Header Options. The Binding Update
MUST be sent using an IPv4 tunnel with IPv4 CoA as the source address
and the CN's IPv4 address as the destination address just as in the
COTI message transmission.
The CN binds the IPv4 CoA to the IPv4 HoA in addition to binding
IPv6 CoA to the IPv6 HoA. The CN also binds the IPv6 CoA to IPv4 CoA
for IPv6-in-IPv4 tunneling. This allows direct, route-optimized
communication for IPv4 traffic, and allows tunneling route-optimized
IPv6 traffic using IPv4.
4. Message Formats
A new IPv4 address option is defined as a Mobility Header option.
This option is used to carry the MN's IPv4 CoA and CN's IPv4
addresses in the RR messages and the Binding Update message.
Koodli Expires 11 January 2005 [Page 4]
Internet Draft Mobile IPv4 Route Optimization 11 July 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Mobility Header IPv4 Address Option
Type New Type denoting an IPv4 Address
Length Length of the option in octets not including the
Type and Length fields. MUST be set to 4.
IPv4 Address This field can include the MN's IPv4 HoA and CoA
(in that order when both are present) and the
CN's IPv4 address.
5. IANA Considerations
The IPv4 Address Option needs a new type assignment from the Mobile
IPv6 Mobility Header Options registry.
6. Security Considerations
With IPv6-in-IPv4 tunneling, a node could potentially include any
IPv6 address inside an IPv4 packet. This document does not propose a
solution to this general problem. It does however require that the
tunnel end-points are the correspondents and mobile nodes themselves.
This consideration applies to tunneling of COTI in an IPv4 packet.
With HOTI, the Home Agent can ensure that the IPv6 HoA and the IPv4
HoA actually belong to the same MN. A correspondent node MUST ensure
that the address present in the IPv4 Mobility Header option is the
same as the source IP address of the encapsulating IPv4 packet.
References
[1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6.
Request for Comments 3775, Internet Engineering Task Force, June
2004.
Koodli Expires 11 January 2005 [Page 5]
Internet Draft Mobile IPv4 Route Optimization 11 July 2005
7. Author's Address
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043 USA
Phone: +1 650 625 2359
Fax: +1 650 625 2502
E-Mail: Rajeev.Koodli@nokia.com
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.
Koodli Expires 11 January 2005 [Page 6]
Internet Draft Mobile IPv4 Route Optimization 11 July 2005
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Koodli Expires 11 January 2005 [Page 7]
