Internet DRAFT - draft-soliman-v4v6-mipv4
draft-soliman-v4v6-mipv4
Network Working Group Hesham Soliman, Flarion
INTERNET-DRAFT George Tsirtsis, Flarion
Expires: January 2006
July, 2005
Dual Stack Mobile IPv6
draft-soliman-v4v6-mipv4-02.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.
By submitting this Internet-Draft, we accept the provisions of
Section 4 of RFC 3667 (BCP 78).
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This specification adds IPv4 extensions to Mobile IPv6 to allow dual
stack mobile nodes to roam within the Internet using Mobile IPv6 only
while simultaneously maintaining connections using their IPv4 and
IPv6 home addresses.
Soliman and Tsirtsis [Page 1]
INTERNET-DRAFT DSMIPv6 October, 2004
Table of Contents
1. Introduction....................................................2
1.1 Why Mobile IPv6 only?..........................................2
2. Solution overview...............................................3
2.1. Dynamic Home Agent Address Discovery..........................3
2.2. Binding management............................................4
2.2.1 Visited network supports IPv6................................4
2.2.2 Visited network supports IPv4 only (public addresses)........5
2.3. Route optimization............................................6
2.4. Dynamic IPv4 home address allocation..........................6
3. Extensions and modifications to Mobile IPv6.....................6
3.1. Binding update extensions.....................................6
3.1.1 IPv4 home address option.....................................6
3.2. Binding acknowledgement extensions............................7
3.2.1 IPv4 address acknowledgement option..........................7
3.3. Mobile node operation.........................................8
3.4. Home agent operations.........................................9
3.5. Correspondent node operations................................10
4. Security considerations........................................10
5. References.....................................................11
Author's Addresses................................................11
1. Introduction
Mobile IPv6 allows mobile nodes to move within the Internet while
maintaining reachability and ongoing sessions, using an IPv6 home
address. However, since IPv6 is not widely deployed, it is unlikely
that mobile nodes will use IPv6 addresses only for their connections.
It is reasonable to assume that mobile nodes will, for a long time,
need an IPv4 home address that can be used by upper layers. The
current Mobile IPv6 specification does not allow mobile nodes to use
an IPv4 home address. Hence, this specification extends Mobile IPv6
capabilities to allow dual stack mobile nodes to request that their
home agent (also dual stacked) tunnel IPv4/IPv6 packets addressed to
their home addresses, to their IPv4/IPv6 care-of address(es).
As a result, mobile nodes only need Mobile IPv6 to manage mobility
while moving within the Internet. This specification provides the
extensions needed in order to allow Mobile IPv6 only to be used by
dual sack mobile nodes.
1.1 Why Mobile IPv6 only?
IPv6 offers a number of improvements over today's IPv4, primarily due
to its large address space. Mobile IPv6 offers a number of
improvements over Mobile IPv4, mainly due to capabilities inherited
from IPv6. For instance, route optimization and Dynamic home agent
discovery can only be achieved with Mobile IPv6.
Soliman and Tsirtsis [Page 2]
INTERNET-DRAFT DSMIPv6 October, 2004
One of the advantages of the large address space provided by IPv6 is
that it allows mobile nodes to obtain a global care-of address
wherever they are. Hence, there is no need for NAT traversal
techniques designed for Mobile IPv4. This allows Mobile IPv6 to be a
significantly simpler and more bandwidth efficient mobility
management protocol.
All of the above benefits make the case for using Mobile IPv6 only
for dual stack mobile nodes.
2. Solution overview
In order to allow Mobile IPv6 to be used by dual stack mobile nodes,
the following needs to be done:
- Mobile nodes should be able to use an IPv4 and IPv6 home or care-of
address simultaneously and update their home agents accordingly.
- Mobile nodes need to be able to know the IPv4 address of the home
agent as well as its IPv6 address. There is no need for IPv4 prefix
discovery however.
This section presents an overview of the extensions required in order
to allow mobile nodes to use Mobile IPv6 only for IP mobility
management.
2.1. Dynamic Home Agent Address Discovery
Mobile IPv6 allows mobile nodes to discover their home agents by
appending a well-known anycast interface identifier to their home
link's prefix. The mobile node sends a Mobile Prefix solicitation and
receives a Mobile Prefix Advertisement containing all prefixes
advertised on the home link.
To allow mobile nodes to use an IPv4 home address they need to be
configured with the home agent's IPv4 address and possibly with the
IPv4 home address. A dual stack mobile node MAY send a Mobile Prefix
Solicitation message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the
case where the mobile node has no access to IPv6 within the local
network. Securing such messages would require the mobile node to have
security association with the home agent, using IPsec (AH or ESP) and
based on the mobile node's IPv4 care-of address. However, since the
mobile node needs to encapsulate all IPv6 traffic into IPv4, while
located in an IPv4-only visited network, such SA would affect all
packets. That is, the SA selectors being the protocol number
(protocol is always IP in IP), as well as, source and destination
addresses are all common to all packets. Therefore, it is RECOMMENDED
that the mobile node does not use Dynamic Home Agent Address
Discovery when located in an IPv4-only network.
Soliman and Tsirtsis [Page 3]
INTERNET-DRAFT DSMIPv6 October, 2004
From the above discussion, it is clear that the mobile node will need
to be configured with its home agent addresses (IPv4 and IPv6) and
its home addresses.
2.2. Binding management
A dual stack mobile node will need to update its home agent with its
care-of address. If a mobile node has an IPv4 and an IPv6 home
address it will need to create a binding cache entry for each
address. The format of the IP packet carrying the binding update and
acknowledgement messages will vary depending on whether the mobile
node has access to IPv6 in the visited network. There are three
different scenarios to consider with respect to the visited network:
A. The visited network has IPv6 connectivity and provides the mobile
node with a care-of address (in a stateful or stateless manner),
in addition to IPv4 addresses (public or private).
B. The mobile node can only configure a globally unique IPv4 address
in the visited network.
C. The mobile node can only configure a private IPv4 address in the
visited network.
This specification is only concerned with cases A and B. Case C is
not supported by this specification. Case C can be supported if the
visited network provided IPv6 service, e.g. by introducing an ISATAP
router that provides global IPv6 connectivity. Binding management in
cases A and B is considered in the following sections.
2.2.1 Visited network supports IPv6
In this case, the mobile node is able to configure a globally unique
IPv6 address. The mobile node will send a binding update to the IPv6
address of its home agent, as defined in [1]. The binding update will
include the IPv4 home address option introduced in this document.
After receiving the binding update, the home agent creates two
binding cache entries, one for the mobile node's IPv4 home address,
and another for the mobile node's IPv6 home address. Both entries
will point to the mobile node's IPv6 care-of address. Hence, whenever
a packet is addressed to the mobile node's IPv4 or IPv6 home
addresses, it will be tunneled in IPv6 to the mobile node's IPv6
care-of address included in the binding update. Effectively, the
mobile node establishes two different tunnels, one for its IPv4
traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6)
with a single binding update. The security implications of this
mechanism are discussed in the security considerations section.
In this scenario, the only addition to [MIPv6] is the inclusion of
the IPv4 home address option in the binding update message.
Soliman and Tsirtsis [Page 4]
INTERNET-DRAFT DSMIPv6 October, 2004
After accepting the binding update and creating the corresponding
binding cache entries, the home agent MUST send a binding
acknowledgement to the mobile node as defined in [MIPv6]. In
addition, if the binding update included an IPv4 home address option,
the binding acknowledgement MUST include the IPv4 address
acknowledgment option as described later in this specification. This
option informs the mobile node whether the binding was accepted for
the IPv4 home address. If this option is not included in the binding
acknowledgement and the IPv4 home address option was included in the
binding update, the mobile node MUST assume that the home agent does
not support the IPv4 home address option and therefore SHOULD NOT
include the option in future binding updates to that home agent
address.
The routing header in the binding update MUST include the mobile
node's IPv6 home address as specified in [MIPv6].
2.2.2 Visited network supports IPv4 only (public addresses)
In this scenario the mobile node will need to tunnel IPv6 packets
containing the binding update to the home agent's IPv4 address. The
mobile node uses the IPv4 address it gets from the visited network as
a source address in the outer header. The binding update will contain
the mobile node's IPv6 home address in the home address option.
However, since the care-of address in this scenario is the mobile
node's IPv4 address, the mobile node MUST include its IPv4 care-of
address in the IPv6 packet. The IPv4 address is represented in an
IPv4-mapped IPv6 address and is included in the source address field
of the IPv6 header.
If the mobile node had an IPv4 home address, it MUST also include the
IPv4 home address option described in this specification.
After accepting the binding update, the home agent MUST create a new
binding cache entry for the mobile node's IPv6 home address. If an
IPv4 home address option were included, the home agent MUST create
another entry for that address. All entries MUST point to the mobile
node's IPv4 care-of address. Hence, all packets addressed to the
mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in
an IPv4 header that includes the home agent's IPv4 address in the
source address field and the mobile node's IPv4 care-of address in
the destination address field.
After accepting the binding updates and creating the corresponding
entries, the home agent MUST send a binding acknowledgement as
specified in [MIPv6]. In addition, if the binding update included an
IPv4 home address option, the binding acknowledgement MUST include
the IPv4 address acknowledgment option as described later in this
specification. The binding update is encapsulated to the IPv4 care-of
address (represented as an IPv4-mapped IPv6 address in the binding
update).
Soliman and Tsirtsis [Page 5]
INTERNET-DRAFT DSMIPv6 October, 2004
2.3. Route optimization
Route optimization, as specified in [MIPv6] will operate in an
identical manner for dual stack mobile nodes when they are located in
a visited network that provides IPv6 addresses to the mobile node.
However, when located in an IPv4-only network, route optimization
will not be possible. Therefore, mobile nodes will need to
communicate through the home agent.
Route optimization will not be possible for IPv4 traffic. That is,
traffic addressed to the mobile node's IPv4 home address. This is
similar to using Mobile IPv4, therefore there is no reduction of
features resulting from using this specification.
2.4. Dynamic IPv4 home address allocation
It is possible to allow for the mobile node's IPv4 home address to be
allocated dynamically. This is done by including 0.0.0.0 in the IPv4
home address option included in the binding update. The home agent
SHOULD allocate an IPv4 address to the mobile node and include it in
the IPv4 address acknowledgement option sent to the mobile node. In
this case, the lifetime of the binding is bound to the minimum of the
lifetimes of the IPv6 binding and the lease time of the IPv4 home
address.
3. Extensions and modifications to Mobile IPv6
This section highlights the protocol and implementation additions
required to support this specification.
3.1. Binding update extensions
3.1.1 IPv4 home address option
This option is included in the Mobility Header including the binding
update message sent from the mobile node to a home agent or Mobility
Anchor Point.
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 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Length 1
Soliman and Tsirtsis [Page 6]
INTERNET-DRAFT DSMIPv6 October, 2004
IPv4 home address The mobile node's IPv4 home address that should
be defended by the home agent. This field could
contain any unicast IPv4 address (public or
private) that was assigned to the mobile node.
The value 0.0.0.0 is used to request an IPv4
home address from the home agent.
3.2. Binding acknowledgement extensions
3.2.1 IPv4 address acknowledgement option
This option is included in the Mobility Header including the binding
acknowledgement message sent from the home agent or Mobility Anchor
Point to the mobile node. This option indicates whether a binding
cache entry was created for the mobile node's IPv4 address.
Additionally, this option can include an IPv4 home address in case
the mobile node was not configured with one (i.e. if the unspecified
IPv4 address was included in the binding update).
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 | Status |Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Length 1
Status Indicates success or failure for the IPv4 home
address binding. Values from 0 to 127 indicate
success. Higher values indicate failure. The
following values are reserved:
0 Success
128 Failure, reason unspecified
129 Administratively prohibited
130 Incorrect IPv4 home address
131 Invalid IPv4 address
132 Dynamic IPv4 home address
assignment not available
IPv4 home address The IPv4 home address that the home agent will
use in the binding cache entry. This could be a
public or private address. This field MUST
always contain the mobile node's IPv4 address.
If the address were dynamically allocated the
home agent will add the address to inform the
mobile node. Otherwise, if the address were
statically allocated to the mobile node, the
Soliman and Tsirtsis [Page 7]
INTERNET-DRAFT DSMIPv6 October, 2004
home agent will copy it from the binding update
message.
3.3. Mobile node operation
In addition to the operations specified in [MIPv6], this
specification requires mobile nodes to be able to support an IPv4
home address. The IPv4 home address is never sent in the IPv4-mapped
IPv6 address format. This is primarily done to save bandwidth.
However, to simplify the mobile node's implementation, they SHOULD
store the IPv4 home address in the binding update list, using the
IPv4-mapped IPv6 format. Mobile nodes are also required to be
configured with the home agent's global IPv4 address.
When sending an IPv6 packet containing a binding update while
connected to an IPv4-only access network, mobile nodes MUST ensure
the following:
- The IPv6 packet is encapsulated in an IPv4 packet
- The source address in the IPv4 header is the mobile node's IPv4
care-of address
- The destination address in the IPv4 header is the home agent's
IPv4 address.
- The source address in the IPv6 header is the mobile node's IPv4-
mapped IPv6 address. That is, the same IPv4 address in the outer
header is placed in the IPv6 header using the mapped address
format.
- The home address option contains the IPv6 home address as
specified in [MIPv6].
- The IPv4 home address option MAY be included in the mobility
header. This option contains the IPv4 home address. If the mobile
node did not have a static home address it MAY include the
unspecified IPv4 address, which acts as a request for a dynamic
IPv4 home address.
- The IPv6 packet MUST be authenticated as per [MIPv6], based on the
mobile node's IPv6 home address.
When sending a binding update from a visited network that supports
IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In
addition, if the mobile node has an IPv4 home address or needs one,
it should include the IPv4 home address option in the mobility
header. If the mobile node already has a static IPv4 home address,
such address MUST be included in the IPv4 home address option.
Otherwise, if the mobile node needs a dynamic IPv4 address, it should
include the IPv4 unspecified address in the IPv4 home address option.
When the mobile node receives a binding acknowledgement from the home
agent, it should follow the rules in [MIPv6]. In addition, the
following actions MUST be made:
- If the mobility header includes and IPv4 address acknowledgement
Soliman and Tsirtsis [Page 8]
INTERNET-DRAFT DSMIPv6 October, 2004
option indicating success, the mobile node should create two
entries in its binding update list, one for the IPv6 home address
and another for the IPv4 home address.
- If no IPv4 address acknowledgement option were present, and an
IPv4 home address option was present in the binding update, the
mobile node MUST only create one binding update list entry for its
IPv6 home address. The mobile node MAY include the IPv4 home
address option in future binding updates.
- If an IPv4 address acknowledgement option were present and it
indicates failure for the IPv4 home address binding, the mobile
node MUST NOT create an entry for that address in its binding
update list. The mobile node MAY include the IPv4 home address
option in future binding updates.
Note that a mobile node complying with this specification MUST
configure an IPv4-mapped IPv6 address on its interface in the visited
network. This is needed in order to allow the mobile node to receive
binding acknowledgements from its home agent while located in an
IPv4-only network.
3.4. Home agent operations
In addition to the home agent specification in [MIPv6], the home
agent needs to be able to process the IPv4 home address option and
generate the IPv4 address acknowledgement option. Both options are
included in the mobility header.
In order to comply with this specification, the home agent MUST be
able to find the IPv4 home address of a mobile node when given the
IPv6 home address. That is, given an IPv6 home address, the home
agent MUST store the corresponding IPv4 home address if a static one
is present. If a dynamic address were requested by the mobile node,
the home agent MUST store that address (associated with the IPv6 home
address) after it's allocated to the mobile node.
When the home agent receives a binding update containing the IPv4
home address option, it needs to follow all the steps in [MIPv6], in
addition, the following checks MUST be done:
- If the IPv4 home address option contains a valid unicast IPv4
address, the home agent MUST check that this address is allocated
to the mobile node that has the IPv6 home address included in the
home address option.
- If the IPv4 home address option contained the unspecified IPv4
address, the home agent SHOULD dynamically allocate and IPv4 home
address to the mobile node. If none is available, the home agent
MUST return an appropriate error code in the status field of the
IPv4 address acknowledgement option.
- If the binding update is accepted for the IPv4 home address, the
Soliman and Tsirtsis [Page 9]
INTERNET-DRAFT DSMIPv6 October, 2004
home agent MUST create a binding cache entry for the IPv4 home
address. The IPv4 home address MAY be stored in the IPv4-mapped
IPv6 address format. The home agent MUST include an IPv4
acknowledgement option in the mobility header containing the
binding acknowledgement.
If the binding update is accepted for both IPv4 and IPv6 home
addresses, the home agent MUST create two separate binding cache
entries, on for each home address. The care-of address is the one
included in the binding update. If the care-of address is an IPv4-
mapped IPv6 address, the home agent MUST setup a tunnel to the IPv4
care-of address of the mobile node.
When sending a binding acknowledgement to the mobile node, the home
agent would construct the message according to [MIPv6]. Note that the
routing header MUST always contain the IPv6 home address as specified
in [MIPv6].
If the care-of address of the mobile node were an IPv4 address, the
home agent MUST include this address in the destination address in
the IPv6 header using the IPv4-mapped IPv6 format. The home agent
MUST then encapsulate the packet in an IPv4 header. The source
address is set to the home agent's IPv4 address and the destination
address is set to the mobile node's IPv4 care-of address.
After creating a binding cache entry for the mobile node's home
addresses. All packets sent to the mobile node's home addresses are
tunneled by the home agent to the mobile node's care-of address. If
the care-of address is an IPv4 address, packets are encapsulated in
an IPv4 header. Note that the mapped address format is not used to
encapsulate the mobile node's traffic. The mapped address format is
only used when sending binding acknowledgements to the mobile node.
3.5. Correspondent node operations
The specification has no impact on IPv4 or IPv6 correspondent nodes.
4. Security considerations
This specification allows a mobile node to send one binding update
for its IPv6 and its IPv4 home address. This is a slight deviation
from [MIPv6] which requires one binding update per home address.
However, like [MIPv6], the IPsec security association needed to
authenticate the binding update is till based on the mobile node's
IPv6 home address. Therefore, in order to authenticate the mobile
node's IPv4 home address binding, the home agent MUST store the IPv4
address corresponding to the IPv6 address that is allocated to a
mobile node. Therefore, it is sufficient for the home agent to know
that the IPsec verification for the packet containing the binding
update was valid provided that it knows which IPv4 home address is
Soliman and Tsirtsis [Page 10]
INTERNET-DRAFT DSMIPv6 October, 2004
associated with which IPv6 home address. Hence, the security of the
IPv4 home address binding is the same as the IPv6 binding.
In effect, associating the mobile node's IPv4 home address with its
IPv6 home address moves the authorization of the binding update for
the IPv4 address to the Mobile IPv6 implementation, which infers it
from the fact that mobile node has an IPv6 home address and the right
credentials for sending an authentic binding update for such address.
5. References
[IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6)
specification", RFC 2460
[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
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.
Author's Addresses
Hesham Soliman
Flarion Technologies
Phone: +1 908 997 9775
E-mail: H.Soliman@Flarion.com
George Tsirtsis
Flarion Technologies
Phone: +44-20-88260073
Email1: G.Tsirtsis@Flarion.com
Email2: tsirtsisg@yahoo.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 IETF's procedures with respect to rights in IETF Documents can
be found in RFC 3667 (BCP 78) and RFC 3668 (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
Soliman and Tsirtsis [Page 11]
INTERNET-DRAFT DSMIPv6 October, 2004
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.
Full 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.
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.
This Internet-Draft expires January, 2006.
Soliman and Tsirtsis [Page 12]
