draft-ietf-mext-nemo-v4traversal-07.txt   draft-ietf-mext-nemo-v4traversal-08.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 December 13, 2008 Intended status: Standards Track February 23, 2009
Expires: June 16, 2009 Expires: August 27, 2009
Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6) Mobile IPv6 Support for Dual Stack Hosts and Routers
draft-ietf-mext-nemo-v4traversal-07.txt draft-ietf-mext-nemo-v4traversal-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 16, 2009. This Internet-Draft will expire on August 27, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 2, line 26 skipping to change at page 2, line 26
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Motivation for Using Mobile IPv6 Only . . . . . . . . . . 6 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 . . . . . . . . . . 10
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
4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 14 4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 14
4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 14 4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 14
4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 15 4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 15
4.1.3. The Binding Update Message Extensions . . . . . . . . 16 4.1.3. The Binding Update Message Extensions . . . . . . . . 16
4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 16 4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 16
4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 16 4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 16
4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 18 4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 18
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 . . . . . . . 21
5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 23 5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 21
5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 25 5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 26 5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 24
5.4.1. Selecting a Care-of address . . . . . . . . . . . . . 26 5.4.1. Selecting a Care-of address . . . . . . . . . . . . . 24
5.4.2. Sending Binding Updates . . . . . . . . . . . . . . . 27 5.4.2. Sending Binding Updates . . . . . . . . . . . . . . . 25
5.4.3. Sending Packets from a Visited Network . . . . . . . . 29 5.4.3. Sending Packets from a Visited Network . . . . . . . . 27
5.4.4. Movement Detection in IPv4-only Networks . . . . . . . 30 5.4.4. Movement Detection in IPv4-only Networks . . . . . . . 28
5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 30 5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 28
5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 32 5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 30
5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 33 5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 35 6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 33
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 . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling . . . . 38 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling . . . . 36
6.2.2. IKEv2 Operation for Securing Data over IPv4 . . . . . 41 6.2.2. IKEv2 Operation for Securing Data over IPv4 . . . . . 39
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 43 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 41
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . . 44
10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 46 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 48 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 46
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 50
1. Requirements notation 1. Requirements notation
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
skipping to change at page 8, line 5 skipping to change at page 7, line 40
The mobile node may also be communicating with an IPv4-only The mobile node may also be communicating with an IPv4-only
application that requires an IPv4 address. application that requires an IPv4 address.
The cases above illustrate the need for the allocation of a stable The cases above illustrate the need for the allocation of a stable
IPv4 home address to the mobile node. This is done using an IPv4 IPv4 home address to the mobile node. This is done using an IPv4
home address. Since running Mobile IPv4 and Mobile IPv6 home address. Since running Mobile IPv4 and Mobile IPv6
simultaneously is problematic (as illustrated in [RFC4977]), this simultaneously is problematic (as illustrated in [RFC4977]), this
scenario adds a requirement on Mobile IPv6 to support IPv4 home scenario adds a requirement on Mobile IPv6 to support IPv4 home
addresses. addresses.
Scenario 5: IPv6 and IPv4-enabled networks
In this scenario, the mobile node should prefer the use of an IPv6
care-of address for either its IPv6 or IPv4 home address. Nomral IP
in IP tunnelling should be used in this scenario as described in
[RFC3775]. Under rare exceptions, where IP in IP tunnelling for IPv6
does not allow the mobile node to reach the home agent, the mobile
node follows the sending algorithm described in Section 5.4.1. UDP
tunnelling in IPv6 networks is proposed in this document as a last
resort mechanism when reachability cannot be achieved through normal
IP in IP tunnelling. It should not be viewed as a normal mode of
operation and should not be used as a first resort.
3. Solution Overview 3. Solution Overview
In order to allow Mobile IPv6 to be used by dual stack mobile nodes, In order to allow Mobile IPv6 to be used by dual stack mobile nodes,
the following needs to be done: the following needs to be done:
o Mobile nodes should be able to use an IPv4 and IPv6 home or o Mobile nodes should be able to use an IPv4 and IPv6 home or
care-of address simultaneously and update their home agents care-of address simultaneously and update their home agents
accordingly. accordingly.
o Mobile nodes need to be able to know the IPv4 address of the home o Mobile nodes need to be able to know the IPv4 address of the home
skipping to change at page 8, line 40 skipping to change at page 8, line 40
well-known anycast interface identifier to their home link's prefix. well-known anycast interface identifier to their home link's prefix.
However, this mechanism is based on IPv6-anycast routing. If a However, this mechanism is based on IPv6-anycast routing. If a
mobile node is located in an IPv4-only foreign network, it cannot mobile node is located in an IPv4-only foreign network, it cannot
rely on native IPv6 routing. In this scenario, the solution for rely on native IPv6 routing. In this scenario, the solution for
discovering the home agent's IPv4 address is through the Domain Name discovering the home agent's IPv4 address is through the Domain Name
System (DNS). If the MN is attached to an IPv6-only or dual stack System (DNS). If the MN is attached to an IPv6-only or dual stack
network, it may also use procedures defined in network, it may also use procedures defined in
[I-D.ietf-mip6-bootstrapping-integrated-dhc] to discover home agent [I-D.ietf-mip6-bootstrapping-integrated-dhc] to discover home agent
information. Note that the use of information. Note that the use of
[I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile
node information that allows it to continue to communicate with the node information that allows it to communicate with the home agent if
home agent if, for example, the mobile node moved from an IPv6- the mobile node is located in an IPv4-only network. In this
enabled network to an IPv4-only network. In this scenario, the scenario, the mobile node needs to discover the IPv4 address of its
mobile node would need to discover the IPv4 address of its home agent home agent through the DNS.
through the DNS.
For DNS lookup by name, the mobile node should be configured with the For DNS lookup by name, the mobile node should be configured with the
name of the home agent. When the mobile node needs to discover a name of the home agent. When the mobile node needs to discover a
home agent, it sends a DNS request with QNAME set to the configured home agent, it sends a DNS request with QNAME set to the configured
name. An example is "ha1.example.com". If a home agent has an IPv4 name. An example is "ha1.example.com". If a home agent has an IPv4
and IPv6 address, the corresponding DNS record should be configured and IPv6 address, the corresponding DNS record should be configured
with both 'AAAA' and 'A' records. Accordingly, the DNS reply will with both 'AAAA' and 'A' records. Accordingly, the DNS reply will
contain 'AAAA' and 'A' records. contain 'AAAA' and 'A' records.
For DNS lookup by service, the SRV record defined in [RFC5026] is For DNS lookup by service, the SRV record defined in [RFC5026] is
skipping to change at page 9, line 26 skipping to change at page 9, line 26
3.2. Mobile Prefix Solicitation and Advertisement 3.2. Mobile Prefix Solicitation and Advertisement
According to [RFC3775], the mobile node can send a Mobile Prefix According to [RFC3775], the mobile node can send a Mobile Prefix
Solicitation and receive a Mobile Prefix Advertisement containing all Solicitation and receive a Mobile Prefix Advertisement containing all
prefixes advertised on the home link. prefixes advertised on the home link.
A dual stack mobile node MAY send a Mobile Prefix Solicitation A dual stack mobile node MAY send a Mobile Prefix Solicitation
message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where 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. the mobile node has no access to IPv6 within the local network.
Securing these messages requires the mobile node to have a security Securing these messages requires the mobile node to have a security
association with the home agent, using IPsec (AH or ESP) and based on association with the home agent, using IPsec and based on the mobile
the mobile node's IPv4 care-of address as described in [RFC3775]. node's IPv4 care-of address as described in [RFC3775], and [RFC4877].
Since the mobile node needs to encapsulate all IPv6 traffic sent to
the home agent into IPv4 while located in an IPv4-only visited [RFC3775] requires the mobile node to include the home address option
network, this SA would match all packets if the selectors were based in the solicitation message sent to the home agent. If the mobile
on the information in the outer header. That is, the SA selectors node is located in an IPv4 network, it will not be assigned an IPv6
being the protocol number (protocol is always IP in IP), as well as, address to include in the source address. In this case, the mobile
source and destination addresses are all common to all packets. If node MUST use its home address in the source address field of the
this effect is not desired, the mobile node can base the SA on the IPv6 packet, in addition to using the home address option as expected
information in the inner header (i.e., using the home agent's IPv6 by [RFC3775].
address, the mobile node's home address and the ICMP protocol
number). This security association would use transport mode ESP
protection.
3.3. Binding Management 3.3. Binding Management
A dual stack mobile node will need to update its home agent with its 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 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, it will need to create a binding cache entry for each
address. The format of the IP packet carrying the binding update and address. The format of the IP packet carrying the binding update and
acknowledgement messages will vary depending on whether the mobile acknowledgement messages will vary depending on whether the mobile
node has access to IPv6 in the visited network. There are three node has access to IPv6 in the visited network. There are three
different scenarios to consider with respect to the visited network: different scenarios to consider with respect to the visited network:
skipping to change at page 10, line 28 skipping to change at page 10, line 25
two binding cache entries, one for the mobile node's IPv4 home two binding cache entries, one for the mobile node's IPv4 home
address, and another for the mobile node's IPv6 home address. Both 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, 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 whenever a packet is addressed to the mobile node's IPv4 or IPv6 home
addresses, the home agent will tunnel it in IPv6 to the mobile node's addresses, the home agent will tunnel it in IPv6 to the mobile node's
IPv6 care-of address included in the binding update. Effectively, IPv6 care-of address included in the binding update. Effectively,
the mobile node establishes two different tunnels, one for its IPv4 the mobile node establishes two different tunnels, one for its IPv4
traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6)
with a single binding update. with a single binding update.
In this scenario, the only addition to [RFC3775] is the inclusion of In this scenario, this document extends [RFC3775] by including the
the IPv4 home address option in the binding update message. IPv4 home address option in the binding update message. Furthermore,
if the network supports both IP v4 and IPv6, or if the mobile node is
experiencing problems with IP in IP tunnelling, this document
proposes some mitigating actions as described in Section 5.4.1
After accepting the binding update and creating the corresponding After accepting the binding update and creating the corresponding
binding cache entries, the home agent MUST send a binding binding cache entries, the home agent MUST send a binding
acknowledgement to the mobile node as defined in [RFC3775]. In acknowledgement to the mobile node as defined in [RFC3775]. In
addition, if the binding update included an IPv4 home address option, addition, if the binding update included an IPv4 home address option,
the binding acknowledgement MUST include the IPv4 address the binding acknowledgement MUST include the IPv4 address
acknowledgment option as described later in this specification. This acknowledgment option as described later in this specification. This
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 its MIPv6 binding. The mobile node MUST NOT register both IPv4 for its MIPv6 binding as described in Section 5.4.1.
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. this specification.
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|P|F|T| Reserved | Lifetime | |A|H|L|K|M|R|P|F| 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. This flag may be set 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 by the mobile node if it is required to use UDP encapsulation
regardless of the presence of a NAT. regardless of the presence of a NAT. This flag SHOULD NOT be set
when the mobile node is configured with an IPv6 care-of address;
T with the exception for the scenario mentioned in Section 5.4.1
When set, this flag indicates that the mobile node requests the
use of the TLV-format for encapsulating IPv6 in IPv4. The TLV-
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
This option is included in the Mobility Header including the binding This option is included in the Mobility Header including the binding
acknowledgement message sent from the home agent or Mobility Anchor acknowledgement message sent from the home agent or Mobility Anchor
Point to the mobile node. This option indicates whether a binding Point to the mobile node. This option indicates whether a binding
cache entry was created for the mobile node's IPv4 address. cache entry was created for the mobile node's IPv4 address.
Additionally, this option includes an IPv4 home address in the case Additionally, this option includes an IPv4 home address in the case
skipping to change at page 19, line 7 skipping to change at page 19, line 7
TBD TBD
Length Length
6 6
F F
This flag indicates to the mobile node that UDP encapsulation is This flag indicates to the mobile node that UDP encapsulation is
required. When set, this flag indicates that the mobile node MUST required. When set, this flag indicates that the mobile node MUST
use UDP encapsulation even if a NAT is not located between the use UDP encapsulation even if a NAT is not located between the
mobile node and home agent. mobile node and home agent. This flag SHOULD NOT be set when the
mobile node is assigned an IPv6 care-of address; with the
exception for accomodating the scenarios discussed in
Section 5.4.1.
Reserved Reserved
This field is reserved for future use. It MUST be set to zero by This field is reserved for future use. It MUST be set to zero by
the sender and ignored by the receiver. the sender and ignored by the receiver.
Refresh Time Refresh Time
A suggested time (in seconds) for the mobile node to refresh the A suggested time (in seconds) for the mobile node to refresh the
NAT binding. If set to zero, it is ignored. If this field is set NAT binding. If set to zero, it is ignored. If this field is set
to all 1s it means that keepalives are not needed, i.e., no NAT to all 1s it means that keepalives are not needed, i.e., no NAT
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
This specification extends the binding acknowledgement message with a
new flag. The new flag is shown and described below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding Acknowledgement message
T
This flag indicates, when set, that the sender of the binding
acknowledgement supports the TLV- tunnel format.
5. Protocol operation 5. Protocol operation
This section presents the protocol operation and processing for the This section presents the protocol operation and processing for the
messages presented above. In addition, this section introduces the messages presented above. In addition, this section introduces the
NAT detection and traversal mechanism used by this specification. NAT detection and traversal mechanism used by this specification.
5.1. Tunelling Formats 5.1. Tunelling Formats
This specification allows the mobile node to use various tunnelling This specification allows the mobile node to use various tunnelling
formats depending on its location and the visited network's formats depending on its location and the visited network's
capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6
or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this
specification also supports tunnelling IPv6 in IPv6. specification also supports tunnelling IPv6 in IPv6.
This specification allows UDP-based tunnelling to be used between the This specification allows UDP-based tunnelling to be used between the
mobile node and its home agent or MAP using either vanilla UDP mobile node and its home agent or MAP. A UDP encapsulation format
encapsulation or TLV-header UDP encapsulation. A vanilla UDP means the following order of headers:
encapsulation format means the following order of headers:
IPv4 IPv4/v6
UDP UDP
IP (v4 or v6) IP (v4 or v6)
Other headers Other headers
Note that the ue of UDP encapsulation for IPv6 care-of addresses
SHOULD NOT be done except in the circumstances highlighted in
Section 5.4.1.
When using this format the receiver would parse the version field When using this format the receiver would parse the version field
following the UDP header in order to determine whether the following following the UDP header in order to determine whether the following
header is IPv4 or IPv6. The rest of the headers are processed header is IPv4 or IPv6. The rest of the headers are processed
normally. The above order of headers does not take IPsec headers normally. The above order of headers does not take IPsec headers
into account as they may be placed in different parts of the packet. into account as they may be placed in different parts of the packet.
The above format MUST be supported by all implementations of this The above format MUST be supported by all implementations of this
specification and MUST always be used to send the binding update specification and MUST always be used to send the binding update
message. message.
Vanilla UDP Tunnelling can also encapsulate an ESP header as shown UDP Tunnelling can also encapsulate an ESP header as shown below.
below.
IPv4 IPv4/v6
UDP UDP
ESP ESP
IP (v4 or v6) IP (v4 or v6)
Other headers
The negotiation of the secure tunnel format described above is
discussed in Section 6.2. The receiver of a vanilla UDP tunnel
detects whether an ESP header is present or not based on the UDP port
used.
TLV-header UDP encapsulation is represented by the following order of
headers:
IP (v4 or v6)
UDP
TLV-header
Other headers Other headers
The use of the TLV-header is negotiated during the binding update/ The negotiation of the secure tunnel format described above is
acknowledgement exchange. If the TLV-header is agreed upon, the discussed in Section 6.2. The receiver of a UDP tunnel detects
receiver of the TLV-header UDP encapsulated packet expects the TLV whether an ESP header is present or not based on the UDP port used.
header to follow UDP. The TLV header contains the type of the
following message and its length. The Type field is limited to
values of 0 and 1 to make sure that the receiver can tell the
difference between the Type field and the IP version field in a
packet that contains an IP header after UDP. Hence, the TLV header
can carry traffic other than IP. Distinction between IP and TLV
encapsulation is needed because the binding update will never be sent
in TLV-tunnel format.
The mobile node negotiates the format for tunnelling payload traffic
during the binding exchange. If a mobile node prefers to use the
TLV- header UDP encapsulation, it sets the T flag in the binding
update sent to the home agent or MAP. If the receiver of the binding
update supports the TLV-header format, it SHOULD set the T flag in
the binding acknowledgement message. Otherwise, the T flag is
cleared. The setting of the T flag in the binding acknowledgement
indicates to the mobile node that it must use the TLV-header UDP
encapsulation format for all packets sent for the duration of the
binding or until a new binding update is sent. Each binding update
may renegotiate the tunnelling format. To avoid interoperability
issues, the sender of the binding acknowledgement MUST NOT set the T
flag unless it was set in the binding update sent from the mobile
node.
The TLV-header format is shown below.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: TLV-header format
Type
This field indicates the type of the payload following this
header.
Length
This field indicates the length of the payload following the
header, excluding the TLV-header itself. The use of this flag is
described in Section 5
Reserved
This field MUST be set to zero by the sender and ignored by the
receiver.
The following value is assigned to the Type field, other values may
be assigned in the future:
1 GRE [RFC2784]
In addition to UDP-based tunnelling, this specification allows for
standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213].
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
UDP-based encapsulation. The mobile node can request to always use
UDP encapsulation by setting the F flag in the binding update. If
the home agent does not accept the request, it MUST reject the
binding update with the new Status code:
144 Cannot force UDP encapsulation
Alternatively, the home agent can force UDP encapsulation by setting
the F flag in the NAT detection option included in the binding
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. The mobile node may use PMTUD as specified in the applications. The mobile node may use PMTUD as specified in
[RFC4459]. [RFC4459].
To accommodate traffic that uses Explicit Congestion Notification To accommodate traffic that uses Explicit Congestion Notification
skipping to change at page 23, line 31 skipping to change at page 21, line 38
on most platforms. However, this issue can be avoided if UDP on most platforms. However, this issue can be avoided if UDP
encapsulation is done in the kernel. encapsulation is done in the kernel.
Note that when using UDP encapsulation, the TTL field must be Note that when using UDP encapsulation, the TTL field must be
decremented in the same manner as when IP in IP encapsulation is decremented in the same manner as when IP in IP encapsulation is
used. 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 when
Mobile IPv6 uses IKEv2 to establish te IPsec security association the mobile node is present in a private IPv4 network. Mobile IPv6
between the mobile node and the home agent. IKEv2 has its own NAT uses IKEv2 to establish te IPsec security association between the
detection mechanism. However, IKEv2's NAT detection is only used for mobile node and the home agent. IKEv2 has its own NAT detection
the purpose of setting up the IPsec SA for secure traffic. The mechanism. However, IKEv2's NAT detection is only used for 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
in Section 6 in Section 6
NAT detection is done when the initial binding update message is sent NAT detection is done when the initial binding update message is sent
from the mobile node to the home agent. When located in an IPv4-only from the mobile node to the home agent. When located in an IPv4-only
foreign link, the mobile node sends the binding update message foreign link, the mobile node sends the binding update message
encapsulated in UDP and IPv4. The source address of the IPv6 packet encapsulated in UDP and IPv4. The source address of the IPv6 packet
is the mobile node's IPv6 home address. The destination address is is the mobile node's IPv6 home address. The destination address is
the IPv6 address of the home agent. The IPv4 header contains the the IPv6 address of the home agent. The IPv4 header contains the
IPv4 care-of address in the source address field and the IPv4 address IPv4 care-of address in the source address field and the IPv4 address
of the home agent in the destination address field. of the home agent in the destination address field.
When the home agent receives the encapsulated binding update, it When the home agent receives the encapsulated binding update, it
compares the IPv4 address of the source address field in the IPv4 compares the IPv4 address of the source address field in the IPv4
header with the IPv4 address included in the IPv4 care-of address header with the IPv4 address included in the IPv4 care-of address
option. If the two addresses match, no NAT device was in the path. option. If the two addresses match, no NAT device was in the path.
Otherwise, a NAT device was in the path and the NAT detection option Otherwise, a NAT was in the path and the NAT detection option is
is included in the binding acknowledgement. The binding included in the binding acknowledgement. The binding
acknowledgement, and all future packets, are then encapsulated in UDP acknowledgement, and all future packets, are then encapsulated in UDP
and IPv4. The source address in the IPv4 header is the IPv4 address and IPv4. The source address in the IPv4 header is the IPv4 address
of the home agent. The destination address is the IPv4 address of the home agent. The destination address is the IPv4 address
received in the IPv4 header encapsulating the binding update (this received in the IPv4 header encapsulating the binding update (this
address will be different from the IPv4 care-of address when a NAT is address will be different from the IPv4 care-of address when a NAT is
in the path). The source port in the packet is the home agent's in the path). The source port in the packet is the home agent's
source port. The destination port is the source port received in the source port. The destination port is the source port received in the
binding update message. Note that the home agent stores the port binding update message. Note that the home agent stores the port
numbers and associates them with the mobile node's tunnel in order to numbers and associates them with the mobile node's tunnel in order to
forward future packets. forward future packets.
skipping to change at page 26, line 24 skipping to change at page 24, line 32
Mobile IP) it does not need to refresh the NAT binding. In this Mobile IP) it does not need to refresh the NAT binding. In this
case, the mobile node would only be able to initiate communication case, the mobile node would only be able to initiate communication
with other nodes. However, this is likely to imply that the mobile with other nodes. However, this is likely to imply that the mobile
node will need to send a binding update before initiating node will need to send a binding update before initiating
communication after a long idle period as it is likely to be assigned communication after a long idle period as it is likely to be assigned
a different port and IPv4 address by the NAT when it initiates a different port and IPv4 address by the NAT when it initiates
communication. Hence, an implementation may choose, for the sake of communication. Hence, an implementation may choose, for the sake of
simplicity, to always maintain the NAT bindings even when it does not simplicity, to always maintain the NAT bindings even when it does not
need reachability. need reachability.
Note that keepalives are also needed by IKEv2 over UDP port 4500.
This is needed for IKE dead peer detection, which is not handled by
DSMIPv6 keepalives.
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.
5.4.1. Selecting a Care-of address 5.4.1. Selecting a Care-of address
skipping to change at page 27, line 18 skipping to change at page 25, line 31
the IP address family chosen for the previous binding update unless the IP address family chosen for the previous binding update unless
the mobile node is aware that it has moved to a different the mobile node is aware that it has moved to a different
administrative domain where previous problems with IPv6 routing may administrative domain where previous problems with IPv6 routing may
not be present. Repeating the above procedure upon every movement not be present. Repeating the above procedure upon every movement
can cause significant degradation of the mobile node's applications' can cause significant degradation of the mobile node's applications'
performace due to extended periods of packet losses after handover if performace due to extended periods of packet losses after handover if
the routing outage is still in effect. the routing outage is still in effect.
When using an IPv4 care-of address and IP in IP encapsulation, if the When using an IPv4 care-of address and IP in IP encapsulation, if the
mobile node implementation is made aware by upper layers of mobile node implementation is made aware by upper layers of
persistent packet losses , it may attempt to resend the binding persistent packet losses, it may attempt to resend the binding update
update with the F flag set, requesting UDP encapsulation for all with the F flag set, requesting UDP encapsulation for all packets.
packets. This may avoid packet losses due to situations where local This may avoid packet losses due to situations where local
firewalling policies prevent the use of IP in IP encapsulation. firewalling policies prevent the use of IP in IP encapsulation.
The effect of these address selection mechanism is to allow the The effect of these address selection mechanism is to allow the
follwing preferences: follwing preferences in the absence of NAT:
1. IPv6 1. IPv6
2. IPv4 (using IP in IP or UDP encapsulation if a NAT is detected) 2. IPv4 (using IP in IP or UDP encapsulation if a NAT is detected)
3. UDP encapsulation when no NAT is detected but IP in IP is not 3. UDP encapsulation when IP in IP is not allowed by the local
allowed by the local domain. domain.
5.4.2. Sending Binding Updates 5.4.2. Sending Binding Updates
When sending an IPv6 packet containing a binding update while When sending an IPv6 packet containing a binding update while
connected to an IPv4-only access network, mobile nodes MUST ensure connected to an IPv4-only access network, mobile nodes MUST ensure
the following: the following:
o The IPv6 packet is encapsulated in the vanilla UDP encapsulation o The IPv6 packet is encapsulated in UDP.
format.
o The source address in the IPv4 header is the mobile node's IPv4 o The source address in the IPv4 header is the mobile node's IPv4
care-of address. care-of address.
o The destination address in the IPv4 header is the home agent's o The destination address in the IPv4 header is the home agent's
IPv4 address. IPv4 address.
o The source address in the IPv6 header is the mobile node's IPv6 o The source address in the IPv6 header is the mobile node's IPv6
home address. home address.
skipping to change at page 28, line 16 skipping to change at page 26, line 27
header. This option contains the IPv4 home address. If the header. This option contains the IPv4 home address. If the
mobile node did not have a static home address it MAY include 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 unspecified IPv4 address, which acts as a request for a dynamic
IPv4 home address. Alternatively, one or more IPv4 home address IPv4 home address. Alternatively, one or more IPv4 home address
options may be included with requests for IPv4 prefixes (i.e., options may be included with requests for IPv4 prefixes (i.e.,
with the P flag set). with the P flag set).
o If the mobile node wishes to use UDP encapsulation only, it should o If the mobile node wishes to use UDP encapsulation only, it should
set the F flag in the binding update message. set the F flag in the binding update message.
o If the mobile node prefers to use the TLV-header format, it should
set the T flag in the binding update.
o The IPv6 packet MUST be authenticated as per [RFC3775], based on o The IPv6 packet MUST be authenticated as per [RFC3775], based on
the mobile node's IPv6 home address. the mobile node's IPv6 home address.
When sending a binding update from a visited network that supports When sending a binding update from a visited network that supports
IPv6, the mobile node MUST follow the rules specified in [RFC3775]. IPv6, the mobile node MUST follow the rules specified in [RFC3775].
In addition, if the mobile node has an IPv4 home address or needs In addition, if the mobile node has an IPv4 home address or needs
one, it MUST include the IPv4 home address option in the mobility one, it MUST include the IPv4 home address option in the mobility
header. If the mobile node already has a static IPv4 home address, header. If the mobile node already has a static IPv4 home address,
this address MUST be included in the IPv4 home address option. this address MUST be included in the IPv4 home address option.
Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST
include the IPv4 0.0.0.0 address in the IPv4 home address option. include the IPv4 0.0.0.0 address in the IPv4 home address option.
In addition to the rules in [RFC3775], the mobile node should follow
the care-of address selection guidelines in Section 5.4.1.
When the mobile node receives a binding acknowledgement from the home When the mobile node receives a binding acknowledgement from the home
agent, it follows the rules in [RFC3775] and [RFC3963]. In addition, agent, it follows the rules in [RFC3775] and [RFC3963]. In addition,
the following actions MUST be made: the following actions MUST be made:
o If the status field indicated failure with error code 144, the o If the status field indicated failure with error code 144, the
mobile node MAY resend the binding update without setting the F mobile node MAY resend the binding update without setting the F
flag. flag.
o If the mobility header includes an IPv4 address acknowledgement o If the mobility header includes an IPv4 address acknowledgement
option indicating success, the mobile node should create two option indicating success, the mobile node should create two
skipping to change at page 29, line 11 skipping to change at page 27, line 22
mobile node MUST only create one binding update list entry for its mobile node MUST only create one binding update list entry for its
IPv6 home address. The mobile node MAY include the IPv4 home IPv6 home address. The mobile node MAY include the IPv4 home
address option in future binding updates. address option in future binding updates.
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
acknowledgement included the T flag set, the mobile node MUST use
the TLV-header UDP encapsulation format.
5.4.2.1. Removing Bindings 5.4.2.1. Removing Bindings
Mobile nodes will remove bindings from the home agent's binding cache Mobile nodes will remove bindings from the home agent's binding cache
whenever they move to the home link, or simply when mobility support whenever they move to the home link, or simply when mobility support
is not needed. is not needed.
De-registering the IPv6 home address is described in [RFC3775]. The De-registering the IPv6 home address is described in [RFC3775]. The
same mechanism applies in this specification. Mobile nodes may same mechanism applies in this specification. Mobile nodes may
remove the binding for the IPv4 home address only, by sending a remove the binding for the IPv4 home address only, by sending a
binding update that does not include the IPv4 home address option. binding update that does not include the IPv4 home address option.
skipping to change at page 29, line 39 skipping to change at page 27, line 46
Note that the mobile node cannot remove the IPv6 home address binding Note that the mobile node cannot remove the IPv6 home address binding
while maintaining an IPv4 home address binding. while maintaining an IPv4 home address binding.
A binding update message with a lifetime of zero, will remove all A binding update message with a lifetime of zero, will remove all
bindings for the mobile node. 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]. In cases where
encapsulated in IPv6 packets to the home agent. IP in IP encapsulation is not providing connectivity to the home
agent, the mobile node may choose to encapsulate in UDP as suggested
in Section 5.4.1. However, this encapsulation of IPv6 traffic should
be used as a last resort as described. IPv4 traffic is 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)
[UDP Header] [UDP Header]
[TLV Header]
IPv6 header (src=V6HoA, dst=CN) IPv6 header (src=V6HoA, dst=CN)
Upper Layer protocols Upper Layer protocols
Here the UDP header is only used if a NAT has been detected between Here the UDP header is only used if a NAT has been detected between
the mobile node and the home agent, or if the home agent forced UDP the mobile node and the home agent, or if the home agent forced UDP
encapsulation. V4CoA is the IPv4 care-of address configured by the encapsulation. V4CoA is the IPv4 care-of address configured by the
mobile node in the visited network. mobile node in the visited network.
Similarly, IPv4 packets are sent according to the following format: Similarly, IPv4 packets are sent 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 17 skipping to change at page 28, line 27
the mobile node and the home agent, or if the home agent forced UDP the mobile node and the home agent, or if the home agent forced UDP
encapsulation. V4CoA is the IPv4 care-of address configured by the encapsulation. V4CoA is the IPv4 care-of address configured by the
mobile node in the visited network. mobile node in the visited network.
Similarly, IPv4 packets are sent according to the following format: Similarly, IPv4 packets are sent according to the following format:
IPv4 header (src=V4CoA, dst=HA_V4ADDR) IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP Header] [UDP Header]
[TLV Header]
IPv4 header (src=V4HoA, dst=V4CN) IPv4 header (src=V4HoA, dst=V4CN)
Upper Layer protocols Upper Layer protocols
Here the UDP header is only used if a NAT has been detected between Here the UDP header is only used if a NAT has been detected between
the mobile node and the home agent, or if the home agent forced UDP the mobile node and the home agent, or if the home agent forced UDP
encapsulation. encapsulation.
If the mobile node and the home agent negotiated the use of the TLV-
header UDP encapsulation format, then the TLV-header would be used
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 The mobile node detects that it's in an IPv4-only network when the
IPv6 movement detection algorithm fails to configure an IPv6 address. IPv6 movement detection algorithm fails to configure an IPv6 address.
skipping to change at page 31, line 35 skipping to change at page 29, line 37
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 MUST NOT be used when the mobile node is located
in an IPv6-enabled link. in an IPv6-enabled link.
o If the T flag was set in the binding update, the home agent needs
to determine whether it can accept the TLV-header encapsulation
format. If it does, it should set the T flag in the binding
acknowledgement. Otherwise, the home agent MUST NOT set the T
flag in the binding acknowledgement.
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
skipping to change at page 40, line 31 skipping to change at page 38, line 31
IPv6 header (src=HAADDR, dst=V6HOA) IPv6 header (src=HAADDR, dst=V6HOA)
Mobility Header Mobility Header
BA ([IPv4 ACK], NAT DET) BA ([IPv4 ACK], NAT DET)
(+ other as needed) (+ other as needed)
In addition, V4ADDR, the sport from the BU (Z), and an indication In addition, V4ADDR, the sport from the BU (Z), and an indication
that vanilla UDP encapsulation must be used, need to be passed with that UDP encapsulation must be used, need to be passed with the
the packet to ensure correct processing. packet to ensure correct processing.
The binding acknowledgement sent by the home agent to the mobile node The binding acknowledgement sent by the home agent to the mobile node
is as follows: is as follows:
IPv4 header (src= HA_V4ADDR, dst=V4ADDR) IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
UDP Header (sport=DSMIPv6, dport=Z) UDP Header (sport=DSMIPv6, dport=Z)
IPv6 header (src=HAADDR, dst=V6HOA) IPv6 header (src=HAADDR, dst=V6HOA)
skipping to change at page 44, line 13 skipping to change at page 42, line 13
NATKATIMEOUT 110 seconds NATKATIMEOUT 110 seconds
8. Acknowledgements 8. Acknowledgements
Thanks to the following members (in alphabetical order) of the MIP6 Thanks to the following members (in alphabetical order) of the MIP6
and NEMO Working Groups for their contributions, discussion, and and NEMO Working Groups for their contributions, discussion, and
review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson,
Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and
Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian
Kaas-Petersen for raising the issue of IKEv2 interactions and Kaas-Petersen for raising the issue of IKEv2 interactions and
proposing the solution included in this document. proposing the solution included in this document. Thanks to Pasi
Eronen for the many thorough reviews of this document.
9. IANA Considerations 9. IANA Considerations
The specification requires the following allocations from IANA: The specification requires the following allocations from IANA:
A UDP port is needed for the NAT traversal mechanism described in A UDP port is needed for the NAT traversal mechanism described in
section 4.1. section 4.1.
The IPv4 home address option described in section 3.1.1 requires The IPv4 home address option described in section 3.1.1 requires
an option type. This option is included in the Mobility header an option type. This option is included in the Mobility header
skipping to change at page 45, line 27 skipping to change at page 43, line 27
requires a new option type. This option is included in the requires a new option type. This option is included in the
Mobility header described in [RFC3775]. Mobility header described in [RFC3775].
The NAT detection option described in section 3.2.2 requires a new The NAT detection option described in section 3.2.2 requires a new
option type. This option is included in the Mobility header option type. This option is included in the Mobility header
described in [RFC3775]. described in [RFC3775].
The IPv4 Care-of address option described in section 3.1.2 The IPv4 Care-of address option described in section 3.1.2
requires a new option type allocation [RFC3775]. requires a new option type allocation [RFC3775].
This specification introduces a new TLV-header to be used with UDP
encapsulation. The Types of the TLV-header should be allocated by
IANA under a new registry: "DSMIPv6 TLV-header Types".
The Status field in the IPv4 home address option should be allocated The Status field in the IPv4 home address option should be allocated
by IANA under the new registry: "DSMIPv6 IPv4 home address option by IANA under the new registry: "DSMIPv6 IPv4 home address option
status codes". status codes".
The TLV-header types and status field values are allocated using the The status field values are allocated using the following procedure:
following procedure:
1. New TLV-header types and Status field values are allocated 1. New Status field values are allocated through IETF review. This
through IETF review. This is for all RFC types including is for all RFC types including standards track, informational,
standards track, informational, and experimental status that and experimental status that originate from the IETF and have
originate from the IETF and have been approved by the IESG for 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" [RFC4844] 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
skipping to change at page 50, line 4 skipping to change at line 1892
George Tsirtsis: G.Tsirtsis@Qualcomm.com George Tsirtsis: G.Tsirtsis@Qualcomm.com
Wakikawa Ryuji: ryuji@sfc.wide.ad.jp Wakikawa Ryuji: ryuji@sfc.wide.ad.jp
Author's Address Author's Address
Hesham Soliman (editor) Hesham Soliman (editor)
Elevate Technologies Elevate Technologies
Email: hesham@elevatemobile.com Email: hesham@elevatemobile.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 47 change blocks. 
232 lines changed or deleted 135 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/