draft-ietf-mext-nemo-v4traversal-06.txt   draft-ietf-mext-nemo-v4traversal-07.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 November 3, 2008 Intended status: Standards Track December 13, 2008
Expires: May 7, 2009 Expires: June 16, 2009
Mobile IPv6 Support for Dual Stack Hosts and Routers Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6)
draft-ietf-mext-nemo-v4traversal-06.txt draft-ietf-mext-nemo-v4traversal-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 May 7, 2009. This Internet-Draft will expire on June 16, 2009.
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.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Motivation for Using Mobile IPv6 Only . . . . . . . . . . 5 2.1. Motivation for Using Mobile IPv6 Only . . . . . . . . . . 6
2.2. Scenarios Considered by This Specification . . . . . . . . 6 2.2. Scenarios Considered by This Specification . . . . . . . . 6
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 8 3.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 8
3.2. Mobile Prefix Solicitation and Advertisement . . . . . . . 9 3.2. Mobile Prefix Solicitation and Advertisement . . . . . . . 9
3.3. Binding Management . . . . . . . . . . . . . . . . . . . . 9 3.3. Binding Management . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Foreign Network Supports IPv6 . . . . . . . . . . . . 10 3.3.1. Foreign Network Supports IPv6 . . . . . . . . . . . . 10
3.3.2. Foreign Network Supports IPv4 Only . . . . . . . . . . 11 3.3.2. Foreign Network Supports IPv4 Only . . . . . . . . . . 11
3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 12 3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 12
3.5. Dynamic IPv4 Home Address Allocation . . . . . . . . . . . 13 3.5. Dynamic IPv4 Home Address Allocation . . . . . . . . . . . 13
4. Extensions And Modifications To Mobile IPv6 . . . . . . . . . 14 4. Extensions And Modifications To Mobile IPv6 . . . . . . . . . 14
skipping to change at page 2, line 47 skipping to change at page 2, line 47
4.2.3. Extensions to the Binding Acknowledgement Message . . 19 4.2.3. Extensions to the Binding Acknowledgement Message . . 19
5. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 20 5. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Tunelling Formats . . . . . . . . . . . . . . . . . . . . 20 5.1. Tunelling Formats . . . . . . . . . . . . . . . . . . . . 20
5.1.1. tunnelling Impacts on Transport and MTU . . . . . . . 23 5.1.1. tunnelling Impacts on Transport and MTU . . . . . . . 23
5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 23 5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 23
5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 25 5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 25
5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 26 5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 26
5.4.1. Selecting a Care-of address . . . . . . . . . . . . . 26 5.4.1. Selecting a Care-of address . . . . . . . . . . . . . 26
5.4.2. Sending Binding Updates . . . . . . . . . . . . . . . 27 5.4.2. Sending Binding Updates . . . . . . . . . . . . . . . 27
5.4.3. Sending Packets from a Visited Network . . . . . . . . 29 5.4.3. Sending Packets from a Visited Network . . . . . . . . 29
5.4.4. Movement Detection in IPv4-only Networks . . . . . . . 29 5.4.4. Movement Detection in IPv4-only Networks . . . . . . . 30
5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 30 5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 30
5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 32 5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 32
5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 33 5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 35 6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 35
6.2. IKE negotiation messages between the mobile node and 6.2. IKE negotiation messages between the mobile node and
Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 37 Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling . . . . 38 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling . . . . 38
6.2.2. IKEv2 Operation for Securing Data over IPv4 . . . . . 40 6.2.2. IKEv2 Operation for Securing Data over IPv4 . . . . . 41
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 43 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 43
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46
10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 46 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 46
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 48 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 50
skipping to change at page 5, line 10 skipping to change at page 5, line 10
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Mobile IPv6 [RFC3775] and [RFC3963] allow mobile nodes to move within Mobile IPv6 [RFC3775] and [RFC3963] allow mobile nodes to move within
the Internet while maintaining reachability and ongoing sessions, the Internet while maintaining reachability and ongoing sessions,
using an IPv6 home address or prefix. However, since IPv6 is not using an IPv6 home address or prefix. However, since IPv6 is not
widely deployed, it is unlikely that mobile nodes will use IPv6 widely deployed, it is unlikely that mobile nodes will initially use
addresses only for their connections. It is reasonable to assume IPv6 addresses only for their connections. It is reasonable to
that mobile nodes will, for a long time, need an IPv4 home address assume that mobile nodes will, for a long time, need an IPv4 home
that can be used by upper layers. It is also reasonable to assume address that can be used by upper layers. It is also reasonable to
that mobile nodes will move to networks that might not support IPv6 assume that mobile nodes will move to networks that might not support
and would therefore need the capability to support an IPv4 Care-of IPv6 and would therefore need the capability to support an IPv4
Address. Hence, this specification extends Mobile IPv6 capabilities Care-of Address. Hence, this specification extends Mobile IPv6
to allow dual stack mobile nodes to request that their home agent capabilities to allow dual stack mobile nodes to request that their
(also dual stacked) tunnel IPv4/IPv6 packets addressed to their home home agent (also dual stacked) tunnel IPv4/IPv6 packets addressed to
addresses, as well as IPv4/IPv6 care-of address(es). their home addresses, as well as IPv4/IPv6 care-of address(es).
Using this specification, mobile nodes would only need Mobile IPv6 Using this specification, mobile nodes would only need Mobile IPv6
and [RFC3963] to manage mobility while moving within the Internet; and [RFC3963] to manage mobility while moving within the Internet;
hence eliminating the need to run two mobility management protocols hence eliminating the need to run two mobility management protocols
simultaneously. This specification provides the extensions needed in simultaneously. This specification provides the extensions needed in
order to allow IPv6 mobility only to be used by dual stack mobile order to allow IPv6 mobility only to be used by dual stack mobile
nodes. nodes.
This specification will also consider cases where a mobile node moves This specification will also consider cases where a mobile node moves
into a private IPv4 network and gets configured with a private IPv4 into a private IPv4 network and gets configured with a private IPv4
Care-of Address. In these scenarios, the mobile node needs to be Care-of Address. In these scenarios, the mobile node needs to be
able to traverse the IPv4 NAT in order to communicate with the home able to traverse the IPv4 NAT in order to communicate with the home
agent. IPv4 NAT traversal for Mobile IPv6 is presented in this agent. IPv4 NAT traversal for Mobile IPv6 is presented in this
specification. specification.
In this specification, the term mobile node refers to both a mobile In this specification, the term mobile node refers to both a mobile
host and mobile router unless the discussion is specific to either host and mobile router unless the discussion is specific to either
hosts or routers. Similarly, we use the term home address to reflect hosts or routers. Similarly, we use the term home address to reflect
an address/prefix format. an address/prefix format. Note that both mobile host and router
functionality has already been defined in [RFC3775] and [RFC3963],
respectively. This specification does not change that already
defined behavior, nor does it extend the specific type of hosts and
router support already defined, except for two things: (i) allowing
the mobile node to communicate with its home agent even over IPv4
networks, and (ii) allowing the use of IPv4 home addresses and
prefixes.
In this specification, extensions are defined for the binding update In this specification, extensions are defined for the binding update
and binding acknowledgement. It should be noted that all these and binding acknowledgement. It should be noted that all these
extensions apply to cases where the mobile node communicates with a extensions apply to cases where the mobile node communicates with a
Mobility Anchor Point (MAP) as defined in [RFC5380]. The Mobility Anchor Point (MAP) as defined in [RFC5380]. The
requirements on the MAP are identical to those stated for the home requirements on the MAP are identical to those stated for the home
agent, although it is unlikely that NAT traversal would be needed agent, although it is unlikely that NAT traversal would be needed
with a MAP as it is expected to be in the same address domain. with a MAP as it is expected to be in the same address domain.
2.1. Motivation for Using Mobile IPv6 Only 2.1. Motivation for Using Mobile IPv6 Only
skipping to change at page 6, line 17 skipping to change at page 6, line 24
One of the advantages of the large address space provided by IPv6 is One of the advantages of the large address space provided by IPv6 is
that it allows mobile nodes to obtain a globally unique care-of that it allows mobile nodes to obtain a globally unique care-of
address wherever they are. Hence, there is no need for Network address wherever they are. Hence, there is no need for Network
Address Translator (NAT) traversal techniques designed for Mobile Address Translator (NAT) traversal techniques designed for Mobile
IPv4. This allows Mobile IPv6 to be a significantly simpler and more IPv4. This allows Mobile IPv6 to be a significantly simpler and more
bandwidth efficient mobility management protocol. At the same time, bandwidth efficient mobility management protocol. At the same time,
during the transition towards IPv6, NAT traversal for existing during the transition towards IPv6, NAT traversal for existing
private IPv4 networks needs to be considered. This specification private IPv4 networks needs to be considered. This specification
introduces NAT traversal for this purpose. introduces NAT traversal for this purpose.
The above benefits make the case for using Mobile IPv6 only for dual The above benefits make the case for using Mobile IPv6-only for dual
stack mobile nodes in order to allow for a long lasting mobility stack mobile nodes as it allows for a long lasting mobility solution.
solution and minimize the need to changing the mobility stack due to The use of Mobile IPv6 for dual stack mobility eliminates the need
the introduction of IPv6 within a deployed network. for changing the mobility solution due to the introduction of IPv6
within a deployed network.
2.2. Scenarios Considered by This Specification 2.2. Scenarios Considered by This Specification
There are several scenarios that illustrate potential There are several scenarios that illustrate potential
incompatibilities for mobile nodes using Mobile IPv6. Some of the incompatibilities for mobile nodes using Mobile IPv6. Some of the
problems associated with mobility and transition issues were problems associated with mobility and transition issues were
presented in [RFC4977]. This specification considers the scenarios presented in [RFC4977]. This specification considers the scenarios
that address all the problems discussed in [RFC4977]. The scenarios that address all the problems discussed in [RFC4977]. The scenarios
considered in this specification are listed below. considered in this specification are listed below.
skipping to change at page 6, line 44 skipping to change at page 7, line 4
the home agent is always reachable through a globally unique IPv4 the home agent is always reachable through a globally unique IPv4
address. Finally, it's important to note that the following address. Finally, it's important to note that the following
scenarios are not mutually exclusive. scenarios are not mutually exclusive.
Scenario 1: IPv4-only foreign network Scenario 1: IPv4-only foreign network
In this scenario, a mobile node is connected to an IPv4-only foreign In this scenario, a mobile node is connected to an IPv4-only foreign
network. The mobile node can only configure an IPv4 Care-of Address. network. The mobile node can only configure an IPv4 Care-of Address.
Scenario 2: Mobile node behind a NAT Scenario 2: Mobile node behind a NAT
In this scenario, the mobile node is in a private IPv4 foreign In this scenario, the mobile node is in a private IPv4 foreign
network that has a NAT device connecting it to the Internet. If the network that has a NAT device connecting it to the Internet. If the
home agent is located outside the NAT device, the mobile node will home agent is located outside the NAT device, the mobile node will
need a NAT traversal mechanism to communicate with the home agent. need a NAT traversal mechanism to communicate with the home agent.
Scenario 3: Home Agent behind a NAT Scenario 3: Home Agent behind a NAT
In this scenario, the communication between the mobile node and the In this scenario, the communication between the mobile node and the
home agent is further complicated by the fact that the home agent is home agent is further complicated by the fact that the home agent is
located within a private IPv4 network. However, in this scenario, we located within a private IPv4 network. However, in this scenario, we
assume that the home agent is allocated a globally unique IPv4 assume that the home agent is allocated a globally unique IPv4
address. The address might not be physically configured on the home address. The address might not be physically configured on the home
agent interface. Instead, it is associated with the home agent on agent interface. Instead, it is associated with the home agent on
the NAT device, which allows the home agent to be reachable through the NAPT device, which allows the home agent to be reachable through
address or port mapping. address or port mapping.
Scenario 4: Use Of IPv4-only applications Scenario 4: Use Of IPv4-only applications
In this scenario, the mobile node may be located in an IPv4, IPv6 or In this scenario, the mobile node may be located in an IPv4, IPv6 or
a dual network. However, the mobile node might be communicating with a dual network. However, the mobile node might be communicating with
an IPv4-only node. In this case, the mobile node would need a stable an IPv4-only node. In this case, the mobile node would need a stable
IPv4 address for its application. The alternative to using an IPv4 IPv4 address for its application. The alternative to using an IPv4
address is the use of protocol translators; however, end-to-end address is the use of protocol translators; however, end-to-end
communication with IPv4 is preferred to the use of protocol communication with IPv4 is preferred to the use of protocol
skipping to change at page 10, line 47 skipping to change at page 10, line 47
option informs the mobile node whether the binding was accepted for option informs the mobile node whether the binding was accepted for
the IPv4 home address. If this option is not included in the binding the IPv4 home address. If this option is not included in the binding
acknowledgement and the IPv4 home address option was included in the acknowledgement and the IPv4 home address option was included in the
binding update, the mobile node MUST assume that the home agent does binding update, the mobile node MUST assume that the home agent does
not support the IPv4 home address option and therefore SHOULD NOT not support the IPv4 home address option and therefore SHOULD NOT
include the option in future binding updates to that home agent include the option in future binding updates to that home agent
address. address.
When a mobile node acquires both IPv4 and IPv6 care-of addresses at When a mobile node acquires both IPv4 and IPv6 care-of addresses at
the foreign network, it SHOULD prioritize the IPv6 care-of address the foreign network, it SHOULD prioritize the IPv6 care-of address
for it MIPv6 its binding. The mobile node MUST NOT register both for its MIPv6 binding. The mobile node MUST NOT register both IPv4
IPv4 and IPv6 care-of addresses to its home agent. and IPv6 care-of addresses to its home agent.
3.3.2. Foreign Network Supports IPv4 Only 3.3.2. Foreign Network Supports IPv4 Only
If the mobile node is in a foreign network that only supports IPv4, If the mobile node is in a foreign network that only supports IPv4,
it needs to detect whether a NAT is in its communication path to the it needs to detect whether a NAT is in its communication path to the
home agent. This is done while exchanging the binding update and home agent. This is done while exchanging the binding update and
acknowledgement messages as shown later in this document. NAT acknowledgement messages as shown later in this document. NAT
detection is needed for the purposes of the signaling presented in detection is needed for the purposes of the signaling presented in
this specification. A mobile node SHOULD NOT assume that its IPv4 this specification.
address is globally unique if a NAT device was not detected.
3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses) 3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses)
In this scenario the mobile node will need to tunnel IPv6 packets In this scenario the mobile node will need to tunnel IPv6 packets
containing the binding update to the home agent's IPv4 address. The containing the binding update to the home agent's IPv4 address. The
mobile node uses the IPv4 address it gets from the foreign network as mobile node uses the IPv4 address it gets from the foreign network as
a source address in the outer header. The binding update will a source address in the outer header. The binding update will
contain the mobile node's IPv6 home address. However, since the contain the mobile node's IPv6 home address. However, since the
care-of address in this scenario is the mobile node's IPv4 address, 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 the mobile node MUST include its IPv4 care-of address in the IPv6
skipping to change at page 16, line 21 skipping to change at page 16, line 21
4.1.3. The Binding Update Message Extensions 4.1.3. The Binding Update Message Extensions
This specification extends the Binding Update message with two new This specification extends the Binding Update message with two new
flags. The flags are shown and described below. flags. The flags are shown and described below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|F|T| Reserved | Lifetime | |A|H|L|K|M|R|P|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Binding Update message Figure 3: Binding Update message
F F
When set, this flag indicates a request for forcing UDP When set, this flag indicates a request for forcing UDP
encapsulation regardless of whether a NAT is present on the path encapsulation regardless of whether a NAT is present on the path
between the mobile node and the home agent. between the mobile node and the home agent. This flag may be set
by the mobile node if it is required to use UDP encapsulation
regardless of the presence of a NAT.
T T
When set, this flag indicates that the mobile node requests the When set, this flag indicates that the mobile node requests the
use of the TLV-format for encapsulating IPv6 in IPv4. The TLV- use of the TLV-format for encapsulating IPv6 in IPv4. The TLV-
format is described later in this document. format is described later in this document.
4.2. Binding Acknowledgement Extensions 4.2. Binding Acknowledgement Extensions
4.2.1. IPv4 Address Acknowledgement Option 4.2.1. IPv4 Address Acknowledgement Option
skipping to change at page 18, line 23 skipping to change at page 18, line 23
o 131 Invalid IPv4 address o 131 Invalid IPv4 address
o 132 Dynamic IPv4 home address assignment not available o 132 Dynamic IPv4 home address assignment not available
o 133 Prefix allocation unauthorized o 133 Prefix allocation unauthorized
4.2.2. The NAT Detection Option 4.2.2. The NAT Detection Option
This option is sent from the home agent to the mobile node to This option is sent from the home agent to the mobile node to
indicate whether a NAT was in the path. This option MAY also include indicate whether a NAT was in the path. This option MAY also include
a suggested NAT binding refresh time for the mobile node. The a suggested NAT binding refresh time for the mobile node. This might
alignment requirement for this option is 4n. If a NAT is detected, be usefl for scenarios where the mobile node is known to be moving
this option MUST be sent by the home agent. within the home agent's administrative domain, and therefore the NAT
timeout is known (through configuration) to the home agent. Section
3.5 of [RFC5405] discusses issues with NAT timeout in some detail.
The alignment requirement for this option is 4n. If a NAT is
detected, this option MUST be sent by the home agent.
0 1 2 3 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 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 |F| Reserved | | Type | Length |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh time | | Refresh time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The NAT Detection Option Figure 5: The NAT Detection Option
skipping to change at page 19, line 25 skipping to change at page 19, line 29
was detected. The home agent MUST be configured with a default was detected. The home agent MUST be configured with a default
value for the refresh time. The recommended value is outlined in value for the refresh time. The recommended value is outlined in
Section 7 Section 7
4.2.3. Extensions to the Binding Acknowledgement Message 4.2.3. Extensions to the Binding Acknowledgement Message
This specification extends the binding acknowledgement message with a This specification extends the binding acknowledgement message with a
new flag. The new flag is shown and described below. new flag. The new flag is shown and described below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|T| Reserved| | Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding Acknowledgement message Figure 6: Binding Acknowledgement message
T T
This flag indicates, when set, that the sender of the binding This flag indicates, when set, that the sender of the binding
acknowledgement supports the TLV- tunnel format. acknowledgement supports the TLV- tunnel format.
skipping to change at page 22, line 32 skipping to change at page 22, line 32
described in Section 5 described in Section 5
Reserved Reserved
This field MUST be set to zero by the sender and ignored by the This field MUST be set to zero by the sender and ignored by the
receiver. receiver.
The following value is assigned to the Type field, other values may The following value is assigned to the Type field, other values may
be assigned in the future: be assigned in the future:
1 GRE 1 GRE [RFC2784]
In addition to UDP-based tunnelling, this specification allows for In addition to UDP-based tunnelling, this specification allows for
standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213]. standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213].
This can take place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. This can take place by tunnelling IPv4 in IPv6 or IPv6 in IPv4.
However, whenever a NAT is detected, the mobile node will default to However, whenever a NAT is detected, the mobile node will default to
UDP-based encapsulation. The mobile node can request to always use UDP-based encapsulation. The mobile node can request to always use
UDP encapsulation by setting the F flag in the binding update. If UDP encapsulation by setting the F flag in the binding update. If
the home agent does not agree to the request, it MUST reject the the home agent does not accept the request, it MUST reject the
binding update with the new Status code: binding update with the new Status code:
144 Cannot force UDP encapsulation 144 Cannot force UDP encapsulation
Alternatively, the home agent can force UDP encapsulation by setting Alternatively, the home agent can force UDP encapsulation by setting
the F flag in the NAT detection option included in the binding the F flag in the NAT detection option included in the binding
acknowledgement. acknowledgement.
5.1.1. tunnelling Impacts on Transport and MTU 5.1.1. tunnelling Impacts on Transport and MTU
Changing the tunnel format may occur due to movement of the mobile Changing the tunnel format may occur due to movement of the mobile
node from one network to another. This can have impacts on the link node from one network to another. This can have impacts on the link
and path MTU, which may affect the amount of bandwidth available to and path MTU, which may affect the amount of bandwidth available to
the applications. It is recommended that the mobile node use PLMTUD the applications. The mobile node may use PMTUD as specified in
as specified in [RFC4459]. [RFC4459].
To accommodate traffic that uses Explicit Congestion Notification To accommodate traffic that uses Explicit Congestion Notification
(ECN), it is RECOMMENDED that the ECN information is copied between (ECN), it is RECOMMENDED that the ECN and DSCP information is copied
the inner and outer header as defined in [RFC3168]. between the inner and outer header as defined in [RFC3168] and
[RFC2983]. It is RECOMMENDED that the full-functionality option
defined in section 9.1.1 of [RFC3168]is used to deal with ECN.
Note that some impementations may not be able to use ECN over the UDP
tunnel. This is due to the lack of access to ECN bits in the UDP API
on most platforms. However, this issue can be avoided if UDP
encapsulation is done in the kernel.
Note that when using UDP encapsulation, the TTL field must be
decremented in the same manner as when IP in IP encapsulation is
used.
5.2. NAT Detection 5.2. NAT Detection
This section deals with NAT detection for the purpose of This section deals with NAT detection for the purpose of
encapsulating packets between the mobile node and the home agent. encapsulating packets between the mobile node and the home agent.
Mobile IPv6 uses IKEv2 to establish te IPsec security association Mobile IPv6 uses IKEv2 to establish te IPsec security association
between the mobile node and the home agent. IKEv2 has its own NAT between the mobile node and the home agent. IKEv2 has its own NAT
detection mechanism. However, IKEv2's NAT detection is only used for detection mechanism. However, IKEv2's NAT detection is only used for
the purpose of setting up the IPsec SA for secure traffic. The the purpose of setting up the IPsec SA for secure traffic. The
interactions between the two NAT traversal mechanisms are described interactions between the two NAT traversal mechanisms are described
skipping to change at page 25, line 50 skipping to change at page 26, line 14
If the refresh time in the NAT detection option in the binding If the refresh time in the NAT detection option in the binding
acknowledgement is set to all 1s, the mobile node need not send acknowledgement is set to all 1s, the mobile node need not send
messages to refresh the NAT binding. However, the mobile node may messages to refresh the NAT binding. However, the mobile node may
still be required to encapsulate traffic in UDP. This scenario may still be required to encapsulate traffic in UDP. This scenario may
take place when a NAT is not detected, but the home agent still take place when a NAT is not detected, but the home agent still
requires the mobile node to use UDP encapsulation. requires the mobile node to use UDP encapsulation.
It should be noted that a mobile node that does not need to be It should be noted that a mobile node that does not need to be
reachable (i.e., only cares about the session continuity aspect of reachable (i.e., only cares about the session continuity aspect of
Mobile IP) does not need to refresh the NAT binding. In this case, Mobile IP) it does not need to refresh the NAT binding. In this
the mobile node would only be able to initiate communication with case, the mobile node would only be able to initiate communication
other nodes. However, this is likely to imply that the mobile node with other nodes. However, this is likely to imply that the mobile
will need to send a binding update before initiating communication node will need to send a binding update before initiating
after a long idle period as it is likely to be assigned a different communication after a long idle period as it is likely to be assigned
port and IPv4 address when it initiates communication. Hence, an a different port and IPv4 address by the NAT when it initiates
implementation may choose, for the sake of simplicity, to always communication. Hence, an implementation may choose, for the sake of
maintain the NAT bindings even when it does not need reachability. simplicity, to always maintain the NAT bindings even when it does not
need reachability.
5.4. Mobile Node Operation 5.4. Mobile Node Operation
In addition to the operations specified in [RFC3775] and [RFC3963], In addition to the operations specified in [RFC3775] and [RFC3963],
this specification requires mobile nodes to be able to support an this specification requires mobile nodes to be able to support an
IPv4 home address. This specification also requires the mobile node IPv4 home address. This specification also requires the mobile node
to choose an IPv4 or an IPv6 care-of address. We first discuss to choose an IPv4 or an IPv6 care-of address. We first discuss
care-of address selection, then continue with binding management and care-of address selection, then continue with binding management and
transmission of normal traffic. transmission of normal traffic.
skipping to change at page 29, line 5 skipping to change at page 29, line 15
o If an IPv4 address acknowledgement option were present and it o If an IPv4 address acknowledgement option were present and it
indicates failure for the IPv4 home address binding, the mobile indicates failure for the IPv4 home address binding, the mobile
node MUST NOT create an entry for that address in its binding node MUST NOT create an entry for that address in its binding
update list. The mobile node MAY include the IPv4 home address update list. The mobile node MAY include the IPv4 home address
option in future binding updates. option in future binding updates.
o If the T flag was set in the binding update and the binding o If the T flag was set in the binding update and the binding
acknowledgement included the T flag set, the mobile node MUST use acknowledgement included the T flag set, the mobile node MUST use
the TLV-header UDP encapsulation format. the TLV-header UDP encapsulation format.
5.4.2.1. Removing Bindings
Mobile nodes will remove bindings from the home agent's binding cache
whenever they move to the home link, or simply when mobility support
is not needed.
De-registering the IPv6 home address is described in [RFC3775]. The
same mechanism applies in this specification. Mobile nodes may
remove the binding for the IPv4 home address only, by sending a
binding update that does not include the IPv4 home address option.
Upon receiving this binding update, the home agent will replace the
existing cache entries with the content of the new message. This
ensures that the IPv4 home address binding is removed, while
maintining an IPv6 binding.
Note that the mobile node cannot remove the IPv6 home address binding
while maintaining an IPv4 home address binding.
A binding update message with a lifetime of zero, will remove all
bindings for the mobile node.
5.4.3. Sending Packets from a Visited Network 5.4.3. Sending Packets from a Visited Network
When the mobile node is located in an IPv6-enabled network it sends When the mobile node is located in an IPv6-enabled network it sends
and receives IPv6 packets as described in [RFC3775]. IPv4 traffic is and receives IPv6 packets as described in [RFC3775]. IPv4 traffic is
encapsulated in IPv6 packets to the home agent. encapsulated in IPv6 packets to the home agent.
When the mobile node is located in an IPv4 only network, it will send When the mobile node is located in an IPv4 only network, it will send
IPv6 packets to its home agent according to the following format: IPv6 packets to its home agent according to the following format:
IPv4 header (src=V4CoA, dst=HA_V4ADDR) IPv4 header (src=V4CoA, dst=HA_V4ADDR)
skipping to change at page 30, line 8 skipping to change at page 30, line 39
after the UDP header. after the UDP header.
5.4.4. Movement Detection in IPv4-only Networks 5.4.4. Movement Detection in IPv4-only Networks
[RFC3775] describes movement detection mostly based on IPv6-specific [RFC3775] describes movement detection mostly based on IPv6-specific
triggers and Neighbor Discovery [RFC4861] information. These triggers and Neighbor Discovery [RFC4861] information. These
triggers are not available in an IPv4-only network. Hence, a mobile triggers are not available in an IPv4-only network. Hence, a mobile
node located in an IPv4-only network SHOULD use [RFC4436] for node located in an IPv4-only network SHOULD use [RFC4436] for
guidance on movement detection mechanisms in IPv4-only networks. guidance on movement detection mechanisms in IPv4-only networks.
The mobile node detects that it's in an IPv4-only network when the
IPv6 movement detection algorithm fails to configure an IPv6 address.
5.5. Home agent operation 5.5. Home agent operation
In addition to the home agent specification in [RFC3775] and In addition to the home agent specification in [RFC3775] and
[RFC3963], the home agent needs to be able to process the IPv4 home [RFC3963], the home agent needs to be able to process the IPv4 home
address option and generate the IPv4 address acknowledgement option. address option and generate the IPv4 address acknowledgement option.
Both options are included in the mobility header. Furthermore, the Both options are included in the mobility header. Furthermore, the
home agent MUST be able to detect the presence of a NAT device and home agent MUST be able to detect the presence of a NAT device and
indicate that in the NAT detection option included in the binding indicate that in the NAT detection option included in the binding
acknowledgement. acknowledgement.
skipping to change at page 31, line 16 skipping to change at page 31, line 51
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
acknowledgement option. If a prefix were requested, the home acknowledgement option. If a prefix were requested, the home
agent MUST allocate a prefix with the requested length; if that agent SHOULD allocate a prefix with the requested length; if
allocation was not possible, the home agent MUST indicate failure prefix allocation (of any length) was not possible, the home agent
of the operation with the appropriate error code. MUST indicate failure of the operation with the appropriate error
code.
o If the binding update is accepted for the IPv4 home address, the o If the binding update is accepted for the IPv4 home address, the
home agent creates a binding cache entry for the IPv4 home home agent creates a binding cache entry for the IPv4 home
address/prefix. The home agent MUST include an IPv4 address/prefix. The home agent MUST include an IPv4
acknowledgement option in the mobility header containing the acknowledgement option in the mobility header containing the
binding acknowledgement. binding acknowledgement.
o If the binding update is accepted for both IPv4 and IPv6 home o If the binding update is accepted for both IPv4 and IPv6 home
addresses, the home agent creates separate binding cache entries, addresses, the home agent creates separate binding cache entries,
one for each home address. The care-of address is the one one for each home address. The care-of address is the one
skipping to change at page 34, line 28 skipping to change at page 34, line 28
associated with which IPv6 home address. Hence, the security of the associated with which IPv6 home address. Hence, the security of the
IPv4 home address binding is the same as the IPv6 binding. IPv4 home address binding is the same as the IPv6 binding.
In effect, associating the mobile node's IPv4 home address with its In effect, associating the mobile node's IPv4 home address with its
IPv6 home address moves the authorization of the binding update for IPv6 home address moves the authorization of the binding update for
the IPv4 address to the Mobile IPv6 implementation, which infers it the IPv4 address to the Mobile IPv6 implementation, which infers it
from the fact that the mobile node has an IPv6 home address and the from the fact that the mobile node has an IPv6 home address and the
right credentials for sending an authentic binding update for the right credentials for sending an authentic binding update for the
IPv6 address. IPv6 address.
This specification requires the use of IKEv2 as the default mechanism
for dynamic keying.
In cases where this specification is used for NAT traversal, it is In cases where this specification is used for NAT traversal, it is
important to note that it has the same vulnerabilities associated important to note that it has the same vulnerabilities associated
with [RFC3519]. An attacker is able to hijack the mobile node's with [RFC3519]. An attacker is able to hijack the mobile node's
session with the home agent if it can modify the contents of the session with the home agent if it can modify the contents of the
outer IPv4 header. The contents of the header are not authenticated outer IPv4 header. The contents of the header are not authenticated
and there is no way for the home agent to verify their validity. and there is no way for the home agent to verify their validity.
Hence, a man in the middle attack where a change in the contents of Hence, a man in the middle attack where a change in the contents of
the IPv4 header can cause a legitimate mobile node's traffic to be the IPv4 header can cause a legitimate mobile node's traffic to be
diverted to an illegitimate receiver independently of the diverted to an illegitimate receiver independently of the
authenticity of the binding update message. authenticity of the binding update message.
skipping to change at page 45, line 47 skipping to change at page 45, line 47
1. New TLV-header types and Status field values are allocated 1. New TLV-header types and Status field values are allocated
through IETF review. This is for all RFC types including through IETF review. This is for all RFC types including
standards track, informational, and experimental status that standards track, informational, and experimental status that
originate from the IETF and have been approved by the IESG for originate from the IETF and have been approved by the IESG for
publication. publication.
2. Requests for new option type value assignments from outside the 2. Requests for new option type value assignments from outside the
IETF are only made through the publication of an IETF document, IETF are only made through the publication of an IETF document,
per 1) above. Note also that documents published as "RFC Editor per 1) above. Note also that documents published as "RFC Editor
contributions" [RFC3978] are not considered to be IETF documents. contributions" [RFC4844] are not considered to be IETF documents.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
skipping to change at page 46, line 48 skipping to change at page 46, line 48
April 2007. April 2007.
10.2. Informative 10.2. Informative
[I-D.ietf-mip6-bootstrapping-integrated-dhc] [I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008. progress), April 2008.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519, Network Address Translation (NAT) Devices", RFC 3519,
April 2003. April 2003.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978,
RFC 3978, March 2005. March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006. Network Tunneling", RFC 4459, April 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual
Stack Mobility", RFC 4977, August 2007. Stack Mobility", RFC 4977, August 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008. Management", RFC 5380, October 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
Appendix A. Contributors Appendix A. Contributors
This document reflects discussions and contributions from several This document reflects discussions and contributions from several
people including (in alphabetical order): people including (in alphabetical order):
Vijay Devarapalli: vijay.devarapalli@azairenet.com Vijay Devarapalli: vijay.devarapalli@azairenet.com
James Kempf: kempf@docomolabs-usa.com James Kempf: kempf@docomolabs-usa.com
Henrik Levkowetz: henrik@levkowetz.com Henrik Levkowetz: henrik@levkowetz.com
 End of changes. 32 change blocks. 
55 lines changed or deleted 123 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/