draft-ietf-mext-nemo-v4traversal-08.txt   draft-ietf-mext-nemo-v4traversal-09.txt 
Network Working Group H. Soliman, Ed. Network Working Group H. Soliman, Ed.
Internet-Draft Elevate Technologies Internet-Draft Elevate Technologies
Intended status: Standards Track February 23, 2009 Intended status: Standards Track February 27, 2009
Expires: August 27, 2009 Expires: August 31, 2009
Mobile IPv6 Support for Dual Stack Hosts and Routers Mobile IPv6 Support for Dual Stack Hosts and Routers
draft-ietf-mext-nemo-v4traversal-08.txt draft-ietf-mext-nemo-v4traversal-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2009. This Internet-Draft will expire on August 31, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
The current Mobile IPv6 and NEMO specifications support IPv6 only. The current Mobile IPv6 and NEMO specifications support IPv6 only.
This specification extends those standards to allow the registration This specification extends those standards to allow the registration
of IPv4 addresses and prefixes, respectively, and the transport of of IPv4 addresses and prefixes, respectively, and the transport of
both IPv4 and IPv6 packets over the tunnel to the home agent. This both IPv4 and IPv6 packets over the tunnel to the home agent. This
specification also allows the Mobile Node to roam over both IPv6 and specification also allows the Mobile Node to roam over both IPv6 and
IPv4, including the case where Network Address Translation is present IPv4, including the case where Network Address Translation is present
on the path between the mobile node and its home agent. on the path between the mobile node and its home agent.
skipping to change at page 12, line 43 skipping to change at page 12, line 43
home address in the destination address field. home address in the destination address field.
The mobile node needs to maintain the NAT bindings for its current The mobile node needs to maintain the NAT bindings for its current
IPv4 care-of address. This is done through sending the binding IPv4 care-of address. This is done through sending the binding
update regularly to the home agent. update regularly to the home agent.
3.4. Route Optimization 3.4. Route Optimization
Route optimization, as specified in [RFC3775] will operate in an Route optimization, as specified in [RFC3775] will operate in an
identical manner for dual stack mobile nodes when they are located in identical manner for dual stack mobile nodes when they are located in
a visited network that provides IPv6 addresses to the mobile node. a visited network that provides IPv6 addresses to the mobile node and
However, when located in an IPv4-only network, route optimization while communicating with an IPv6-enabled correspondent node.
will not be possible due to the difficulty of performing the care-of However, when located in an IPv4-only network, or when using the IPv4
address test. Therefore, mobile nodes will need to communicate home address to communicate with an IPv4 correspondent node, route
through the home agent. optimization will not be possible due to the difficulty of performing
the return routability test. In this specification, UDP
encapsulation is only used between the mobile node and its home
agent. Therefore, mobile nodes will need to communicate through the
home agent.
Route optimization will not be possible for IPv4 traffic. That is, Route optimization will not be possible for IPv4 traffic. That is,
traffic addressed to the mobile node's IPv4 home address. This is traffic addressed to the mobile node's IPv4 home address. This is
similar to using Mobile IPv4, therefore there is no reduction of similar to using Mobile IPv4, therefore there is no reduction of
features resulting from using this specification. features resulting from using this specification.
3.5. Dynamic IPv4 Home Address Allocation 3.5. Dynamic IPv4 Home Address Allocation
It is possible to allow for the mobile node's IPv4 home address to be 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 allocated dynamically. This is done by including 0.0.0.0 in the IPv4
skipping to change at page 29, line 34 skipping to change at page 29, line 34
MUST be done: MUST be done:
o If the IPv4 care-of address in the IPv4 CoA option is not the same o If the IPv4 care-of address in the IPv4 CoA option is not the same
as the IPv4 address in the source address in the IPv4 header then as the IPv4 address in the source address in the IPv4 header then
a NAT was in the path. This information should be flagged for the a NAT was in the path. This information should be flagged for the
binding acknowledgement. binding acknowledgement.
o If the F flag in the binding update were set, the home agent needs o If the F flag in the binding update were set, the home agent needs
to determine whether it accepts forcing UDP encapsulation. If it to determine whether it accepts forcing UDP encapsulation. If it
does not, the binding acknowledgement is sent with error code 144. does not, the binding acknowledgement is sent with error code 144.
UDP encapsulation MUST NOT be used when the mobile node is located UDP encapsulation SHOULD NOT be used when the mobile node is
in an IPv6-enabled link. located in an IPv6-enabled link, with the exception of the
scenarios outlined in Section 5.4.1.
o If the IPv4 home address option contains a valid unicast IPv4 o If the IPv4 home address option contains a valid unicast IPv4
address, the home agent MUST check that this address is allocated address, the home agent MUST check that this address is allocated
to the mobile node that has the IPv6 home address included in the to the mobile node that has the IPv6 home address included in the
home address option. The same MUST be done for an IPv4 prefix. home address option. The same MUST be done for an IPv4 prefix.
o If the IPv4 home address option contained the unspecified IPv4 o If the IPv4 home address option contained the unspecified IPv4
address, the home agent SHOULD dynamically allocate an IPv4 home address, the home agent SHOULD dynamically allocate an IPv4 home
address to the mobile node. If none is available, the home agent address to the mobile node. If none is available, the home agent
MUST return error code 132 in the status field of the IPv4 address MUST return error code 132 in the status field of the IPv4 address
skipping to change at page 33, line 31 skipping to change at page 33, line 31
losses as remote correspondent nodes are unaware of such movement. losses as remote correspondent nodes are unaware of such movement.
To avoid confusion in the correspondent node, the mobile node SHOULD To avoid confusion in the correspondent node, the mobile node SHOULD
deregister its binding with each correspondent node by sending a deregister its binding with each correspondent node by sending a
deregistration binding update. The deregistration binding update deregistration binding update. The deregistration binding update
message is tunnelled to the home agent and onto the correspondent message is tunnelled to the home agent and onto the correspondent
node. This is done after the mobile node updates the home agent with node. This is done after the mobile node updates the home agent with
its new location as discussed below. its new location as discussed below.
The mobile node sends the binding update message to the home agent. The mobile node sends the binding update message to the home agent.
If the mobile node is in an IPv6-enabled network, the binding update If the mobile node is in an IPv6-enabled network, the binding update
is sent without IPv4/UDP encapsulation. If the mobile node is in an SHOULD be sent without IPv4/UDP encapsulation, unless UDP
IPv4-only network, then after IPsec processing of the BU message, it encapsulation is needed as described in Section 5.4.1. If the mobile
encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4. node is in an IPv4-only network, then after IPsec processing of the
In order to be able to send the binding update while in an IPv4-only BU message, it encapsulates the BU in UDP/IPv4 as discussed in
network, the mobile node needs to use the new IPv4 care-of address in sections 5.2 and 5.4. In order to be able to send the binding update
the outer header, which is different from the care-of address used in while in an IPv4-only network, the mobile node needs to use the new
the existing tunnel. This should be done without permanently IPv4 care-of address in the outer header, which is different from the
updating the tunnel within the mobile node's implementation in order care-of address used in the existing tunnel. This should be done
to allow the mobile node to receive packets on the old care-of without permanently updating the tunnel within the mobile node's
address until the binding acknowledgement is received. The method implementation in order to allow the mobile node to receive packets
used to achieve this effect is implementation dependent and is on the old care-of address until the binding acknowledgement is
outside the scope of this specification. This implies that the IP received. The method used to achieve this effect is implementation
forwarding function (which selects the interface or tunnel through dependent and is outside the scope of this specification. This
which a packet is sent) is not based solely on the destination implies that the IP forwarding function (which selects the interface
address: some IPv6 packets destined to the home agent are sent via or tunnel through which a packet is sent) is not based solely on the
the existing tunnel, while BUs are sent using the new care-of destination address: some IPv6 packets destined to the home agent are
address. Since BUs are protected by IPsec, the forwarding function sent via the existing tunnel, while BUs are sent using the new
cannot necessarily determine the correct treatment from the packet care-of address. Since BUs are protected by IPsec, the forwarding
headers. Thus, the DSMIPv6 implementation has to attach additional function cannot necessarily determine the correct treatment from the
information to BUs, and this information has to be preserved after packet headers. Thus, the DSMIPv6 implementation has to attach
IPsec processing and made available to the forwarding function, or additional information to BUs, and this information has to be
additional DSMIP processing added to the forwarding function. preserved after IPsec processing and made available to the forwarding
Depending on the mobile node's implementation, meeting this function, or additional DSMIP processing added to the forwarding
requirement may require changes to the IPsec implementation. function. Depending on the mobile node's implementation, meeting
this requirement may require changes to the IPsec implementation.
Upon receiving the binding update message encapsulated in UDP/IPv4, Upon receiving the binding update message encapsulated in UDP/IPv4,
the home agent processes it as follows. In order to allow the the home agent processes it as follows. In order to allow the
DSMIPv6 implementation in the home agent to detect the presence of a DSMIPv6 implementation in the home agent to detect the presence of a
NAT on the path to the mobile node, it needs to compare the outer NAT on the path to the mobile node, it needs to compare the outer
IPv4 source address with the IPv4 address in the IPv4 care-of address IPv4 source address with the IPv4 address in the IPv4 care-of address
option. This implies that the information in the outer header will option. This implies that the information in the outer header will
be preserved after IPsec processing and made available to the DSMIPv6 be preserved after IPsec processing and made available to the DSMIPv6
implementation in the home agent. Depending on the home agent's implementation in the home agent. Depending on the home agent's
implementation, meeting this requirement may require changes to the implementation, meeting this requirement may require changes to the
 End of changes. 7 change blocks. 
40 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/