draft-ietf-mext-nemo-v4traversal-10.txt   rfc5555.txt 
Network Working Group H. Soliman, Ed. Network Working Group H. Soliman, Ed.
Internet-Draft Elevate Technologies Request for Comments: 5555 Elevate Technologies
Intended status: Standards Track April 7, 2009
Expires: October 9, 2009
Mobile IPv6 Support for Dual Stack Hosts and Routers Mobile IPv6 Support for Dual Stack Hosts and Routers
draft-ietf-mext-nemo-v4traversal-10.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 9, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
The current Mobile IPv6 and NEMO specifications support IPv6 only. The current Mobile IPv6 and Network Mobility (NEMO) specifications
This specification extends those standards to allow the registration support IPv6 only. This specification extends those standards to
of IPv4 addresses and prefixes, respectively, and the transport of allow the registration of IPv4 addresses and prefixes, respectively,
both IPv4 and IPv6 packets over the tunnel to the home agent. This and the transport of both IPv4 and IPv6 packets over the tunnel to
specification also allows the Mobile Node to roam over both IPv6 and the home agent. This specification also allows the mobile node to
IPv4, including the case where Network Address Translation is present roam over both IPv6 and IPv4, including the case where Network
on the path between the mobile node and its home agent. Address Translation is present on the path between the mobile node
and its home agent.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation ......................................4
2.1. Motivation for Using Mobile IPv6 Only . . . . . . . . . . 6 1.2. Motivation for Using Mobile IPv6 Only ......................4
2.2. Scenarios Considered by This Specification . . . . . . . . 6 1.3. Scenarios Considered by This Specification .................4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 2. Solution Overview ...............................................6
3.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 9 2.1. Home Agent Address Discovery ...............................6
3.2. Mobile Prefix Solicitation and Advertisement . . . . . . . 10 2.2. Mobile Prefix Solicitation and Advertisement ...............7
3.3. Binding Management . . . . . . . . . . . . . . . . . . . . 10 2.3. Binding Management .........................................8
3.3.1. Foreign Network Supports IPv6 . . . . . . . . . . . . 11 2.3.1. Foreign Network Supports IPv6 .......................8
3.3.2. Foreign Network Supports IPv4 Only . . . . . . . . . . 11 2.3.2. Foreign Network Supports IPv4 Only ..................9
3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 13 2.4. Route Optimization ........................................11
3.5. Dynamic IPv4 Home Address Allocation . . . . . . . . . . . 14 2.5. Dynamic IPv4 Home Address Allocation ......................11
4. Extensions And Modifications To Mobile IPv6 . . . . . . . . . 15 3. Extensions and Modifications to Mobile IPv6 ....................11
4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 15 3.1. Binding Update Extensions .................................11
4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 15 3.1.1. IPv4 Home Address Option ...........................11
4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 16 3.1.2. The IPv4 Care-of Address Option ....................13
4.1.3. The Binding Update Message Extensions . . . . . . . . 17 3.1.3. The Binding Update Message Extensions ..............13
4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 17 3.2. Binding Acknowledgement Extensions ........................14
4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 17 3.2.1. IPv4 Address Acknowledgement Option ................14
4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 19 3.2.2. The NAT Detection Option ...........................16
5. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 21 4. Protocol Operation .............................................17
5.1. Tunelling Formats . . . . . . . . . . . . . . . . . . . . 21 4.1. Tunnelling Formats ........................................17
5.1.1. tunnelling Impacts on Transport and MTU . . . . . . . 22 4.1.1. Tunnelling Impacts on Transport and MTU ............18
5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 22 4.2. NAT Detection .............................................19
5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 24 4.3. NAT Keepalives ............................................21
5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 25 4.4. Mobile Node Operation .....................................22
5.4.1. Selecting a Care-of address . . . . . . . . . . . . . 25 4.4.1. Selecting a Care-of Address ........................22
5.4.2. Sending Binding Updates . . . . . . . . . . . . . . . 26 4.4.2. Sending Binding Updates ............................23
5.4.3. Sending Packets from a Visited Network . . . . . . . . 28 4.4.3. Sending Packets from a Visited Network .............25
5.4.4. Movement Detection in IPv4-only Networks . . . . . . . 29 4.4.4. Movement Detection in IPv4-Only Networks ...........26
5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 29 4.5. Home Agent Operation ......................................26
5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 31 4.5.1. Sending Packets to the Mobile Node .................28
5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 32 4.6. Correspondent Node Operation ..............................29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 5. Security Considerations ........................................29
6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 34 5.1. Handover Interactions for IPsec and IKE ...................30
6.2. IKE negotiation messages between the mobile node and 5.2. IKE Negotiation Messages between the Mobile Node
Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 36 and Home Agent ............................................33
6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling . . . . 37 5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling .....33
6.2.2. IKEv2 Operation for Securing Data over IPv4 . . . . . 40 5.2.2. IKEv2 Operation for Securing Data over IPv4 ........36
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 42 6. Protocol Constants .............................................38
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 7. Acknowledgements ...............................................38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations ............................................38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 9. References .....................................................39
10.1. Normative References . . . . . . . . . . . . . . . . . . . 45 9.1. Normative References ......................................39
10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 46 9.2. Informative References ....................................40
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 47 10. Contributors ..................................................41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction 1. Introduction
Mobile IPv6 [RFC3775] and [RFC3963] allow mobile nodes to move within Mobile IPv6 [RFC3775] and NEMO [RFC3963] allow mobile nodes to move
the Internet while maintaining reachability and ongoing sessions, within the Internet while maintaining reachability and ongoing
using an IPv6 home address or prefix. However, since IPv6 is not sessions, using an IPv6 home address or prefix. However, since IPv6
widely deployed, it is unlikely that mobile nodes will initially use is not widely deployed, it is unlikely that mobile nodes will
IPv6 addresses only for their connections. It is reasonable to initially use only IPv6 addresses for their connections. It is
assume that mobile nodes will, for a long time, need an IPv4 home reasonable to assume that mobile nodes will, for a long time, need an
address that can be used by upper layers. It is also reasonable to IPv4 home address that can be used by upper layers. It is also
assume that mobile nodes will move to networks that might not support reasonable to assume that mobile nodes will move to networks that
IPv6 and would therefore need the capability to support an IPv4 might not support IPv6 and would therefore need the capability to
Care-of Address. Hence, this specification extends Mobile IPv6 support an IPv4 care-of address. Hence, this specification extends
capabilities to allow dual stack mobile nodes to request that their Mobile IPv6 capabilities to allow dual stack mobile nodes to request
home agent (also dual stacked) tunnel IPv4/IPv6 packets addressed to that their home agent (also dual stacked) tunnel IPv4/IPv6 packets
their home addresses, as well as IPv4/IPv6 care-of address(es). addressed to 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 dual stack mobile nodes to use IPv6 mobility only.
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 a 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
an address/prefix format. Note that both mobile host and router reflect an address/prefix format. Note that both mobile host and
functionality has already been defined in [RFC3775] and [RFC3963], router functionality have already been defined in [RFC3775] and
respectively. This specification does not change that already [RFC3963], respectively. This specification does not change those
defined behavior, nor does it extend the specific type of hosts and already defined behaviors, nor does it extend the specific types of
router support already defined, except for two things: (i) allowing hosts and router support already defined, with the following two
the mobile node to communicate with its home agent even over IPv4 exceptions: (i) allowing the mobile node to communicate with its home
networks, and (ii) allowing the use of IPv4 home addresses and agent even over IPv4 networks, and (ii) allowing the use of IPv4 home
prefixes. 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; however, 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 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Motivation for Using Mobile IPv6 Only
IPv6 offers a number of improvements over today's IPv4, primarily due IPv6 offers a number of improvements over today's IPv4, primarily due
to its large address space. Mobile IPv6 offers a number of to its large address space. Mobile IPv6 offers a number of
improvements over Mobile IPv4 [RFC3344], mainly due to capabilities improvements over Mobile IPv4 [RFC3344], mainly due to capabilities
inherited from IPv6. For instance, route optimization and dynamic inherited from IPv6. For instance, route optimization and dynamic
home agent discovery can only be achieved with Mobile IPv6. home agent discovery can only be achieved with Mobile IPv6.
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 only Mobile IPv6 for dual
stack mobile nodes as it allows for a long lasting mobility solution. stack mobile nodes, as it allows for a long-lasting mobility
The use of Mobile IPv6 for dual stack mobility eliminates the need solution. The use of Mobile IPv6 for dual stack mobility eliminates
for changing the mobility solution due to the introduction of IPv6 the need for changing the mobility solution due to the introduction
within a deployed network. of IPv6 within a deployed network.
2.2. Scenarios Considered by This Specification 1.3. 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.
All of the following scenarios assume that both the mobile node and All of the following scenarios assume that both the mobile node and
the home agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is the home agent are IPv4- and IPv6-enabled and that only Mobile IPv6
used between the mobile node and the home agent. We also assume that is used between the mobile node and the home agent. We also assume
the home agent is always reachable through a globally unique IPv4 that the home agent is always reachable through a globally unique
address. Finally, it's important to note that the following IPv4 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.
It should be noted that [RFC5389] highlights issues with some types It should be noted that [RFC5389] highlights issues with some types
of NATs that act as generic ALGs and rewrite any 32-bit field of NATs that act as generic Application Level Gateways (ALGs) and
containing the NAT's public IP addresses. This specification will rewrite any 32-bit field containing the NAT's public IP addresses.
not support such NATs. This specification will not support such NATs.
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 NAPT device, which allows the home agent to be reachable through the Network Address Port Translation (NAPT) device, which allows the
address or port mapping. home agent to be reachable through 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 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 to use 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
translators. translators.
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 Scenario 5: IPv6 and IPv4-enabled networks
In this scenario, the mobile node should prefer the use of an IPv6 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 care-of address for either its IPv6 or IPv4 home address. Normal
in IP tunnelling should be used in this scenario as described in IP-in-IP tunnelling should be used in this scenario as described in
[RFC3775]. Under rare exceptions, where IP in IP tunnelling for IPv6 [RFC3775]. Under rare exceptions, where IP-in-IP tunnelling for IPv6
does not allow the mobile node to reach the home agent, the mobile 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 node follows the sending algorithm described in Section 4.4.1. UDP
tunnelling in IPv6 networks is proposed in this document as a last tunnelling in IPv6 networks is proposed in this document as a last-
resort mechanism when reachability cannot be achieved through normal resort mechanism when reachability cannot be achieved through normal
IP in IP tunnelling. It should not be viewed as a normal mode of IP-in-IP tunnelling. It should not be viewed as a normal mode of
operation and should not be used as a first resort. operation and should not be used as a first resort.
3. Solution Overview 2. 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 IPv4 and IPv6 home or care-of
care-of address simultaneously and update their home agents addresses simultaneously and to 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
agent as well as its IPv6 address. There is no need for IPv4 agent as well as its IPv6 address. There is no need for IPv4
prefix discovery however. prefix discovery, however.
o Mobile nodes need to be able to detect the presence of a NAT o Mobile nodes need to be able to detect the presence of a NAT
device and traverse it in order to communicate with the home device and traverse it in order to communicate with the home
agent. agent.
This section presents an overview of the extensions required in order This section presents an overview of the extensions required in order
to allow mobile nodes to use Mobile IPv6 only for IP mobility to allow mobile nodes to use only Mobile IPv6 for IP mobility
management management.
3.1. Home Agent Address Discovery 2.1. Home Agent Address Discovery
Dynamic home agent Address Discovery (DHAAD) was defined in [RFC3775] Dynamic Home Agent Address Discovery (DHAAD) is defined in [RFC3775]
to allow mobile nodes to discover their home agents by appending a to allow mobile nodes to discover their home agents by appending a
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 (MN) is located in an IPv4-only foreign network, it
rely on native IPv6 routing. In this scenario, the solution for cannot rely on native IPv6 routing. In this scenario, the solution
discovering the home agent's IPv4 address is through the Domain Name for discovering the home agent's IPv4 address is through the Domain
System (DNS). If the MN is attached to an IPv6-only or dual stack Name System (DNS). If the MN is attached to an IPv6-only or dual
network, it may also use procedures defined in stack network, it may also use procedures defined in [CHOWDHURY] to
[I-D.ietf-mip6-bootstrapping-integrated-dhc] to discover home agent discover home agent information. Note that the use of [CHOWDHURY]
information. Note that the use of cannot give the mobile node information that allows it to communicate
[I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile with the home agent if the mobile node is located in an IPv4-only
node information that allows it to communicate with the home agent if network. In this scenario, the mobile node needs to discover the
the mobile node is located in an IPv4-only network. In this IPv4 address of its home agent through the DNS.
scenario, the mobile node needs to discover the IPv4 address of its
home agent 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
reused. For instance, if the service name is "mip6" and the protocol reused. For instance, if the service name is "mip6" and the protocol
name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS
request with the QNAME set to "_mip6._ipv6.example.com". The request with the QNAME set to "_mip6._ipv6.example.com". The
response should contain the home agent's FQDN(s) and may include the response should contain the home agent's FQDN(s) and may include the
corresponding 'AAAA' and 'A' records as well. corresponding 'AAAA' and 'A' records as well.
If multiple home agents reside on the home link, each configured with If multiple home agents reside on the home link, each configured with
a public IPv4 address, then the operation above applies. The correct a public IPv4 address, then the operation above applies. The correct
DNS entries can be configured accordingly. DNS entries can be configured accordingly.
3.2. Mobile Prefix Solicitation and Advertisement 2.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 and based on the mobile association with the home agent, using IPsec and based on the mobile
node's IPv4 care-of address as described in [RFC3775], and [RFC4877]. node's IPv4 care-of address as described in [RFC3775] and [RFC4877].
[RFC3775] requires the mobile node to include the home address option [RFC3775] requires the mobile node to include the home address option
in the solicitation message sent to the home agent. If the mobile in the solicitation message sent to the home agent. If the mobile
node is located in an IPv4 network, it will not be assigned an IPv6 node is located in an IPv4 network, it will not be assigned an IPv6
address to include in the source address. In this case, the mobile address to include in the source address. In this case, the mobile
node MUST use its home address in the source address field of the node MUST use its home address in the source address field of the
IPv6 packet, in addition to using the home address option as expected IPv6 packet, in addition to using the home address option as expected
by [RFC3775]. by [RFC3775].
3.3. Binding Management 2.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:
o The visited network has IPv6 connectivity and provides the mobile o The visited network has IPv6 connectivity and provides the mobile
node with a care-of address (in a stateful or stateless manner). node with a care-of address (in a stateful or stateless manner).
o The mobile node can only configure a globally unique IPv4 address o The mobile node can only configure a globally unique IPv4 address
in the visited network. in the visited network.
o The mobile node can only configure a private IPv4 address in the o The mobile node can only configure a private IPv4 address in the
visited network. visited network.
3.3.1. Foreign Network Supports IPv6 2.3.1. Foreign Network Supports IPv6
In this case, the mobile node is able to configure a globally unique In this case, the mobile node is able to configure a globally unique
IPv6 address. The mobile node will send a binding update to the IPv6 IPv6 address. The mobile node will send a binding update to the IPv6
address of its home agent, as defined in [RFC3775]. The binding address of its home agent, as defined in [RFC3775]. The binding
update MAY include the IPv4 home address option introduced in this update MAY include the IPv4 home address option introduced in this
document. After receiving the binding update, the home agent creates document. After receiving the binding update, the home agent creates
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 address, 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 that is included in the binding update.
the mobile node establishes two different tunnels, one for its IPv4 Effectively, the mobile node establishes two different tunnels, one
traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic
with a single binding update. (IPv6 in IPv6), with a single binding update.
In this scenario, this document extends [RFC3775] by including the In this scenario, this document extends [RFC3775] by including the
IPv4 home address option in the binding update message. Furthermore, 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 if the network supports both IP v4 and IPv6, or if the mobile node is
experiencing problems with IP in IP tunnelling, this document experiencing problems with IP-in-IP tunnelling, this document
proposes some mitigating actions as described in Section 5.4.1 proposes some mitigating actions as described in Section 4.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 in Section 3.2.1. This option
option informs the mobile node whether the binding was accepted for informs the mobile node whether the binding was accepted for the IPv4
the IPv4 home address. If this option is not included in the binding 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 as described in Section 5.4.1. for its MIPv6 binding as described in Section 4.4.1.
3.3.2. Foreign Network Supports IPv4 Only 2.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.
3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses) 2.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
packet. The IPv4 address is represented in the IPv4 Care-of address packet. The IPv4 address is represented in the IPv4 care-of address
option defined in this specification. If the mobile node had an IPv4 option defined in this specification. If the mobile node had an IPv4
home address, it MUST also include the IPv4 home address option home address, it MUST also include the IPv4 home address option
described in this specification. described in this specification.
After accepting the binding update, the home agent MUST create a new After accepting the binding update, the home agent MUST create a new
binding cache entry for the mobile node's IPv6 home address. If an binding cache entry for the mobile node's IPv6 home address. If an
IPv4 home address option were included, the home agent MUST create IPv4 home address option is included, the home agent MUST create
another entry for that address. All entries MUST point to the mobile another entry for that address. All entries MUST point to the mobile
node's IPv4 care-of address. Hence, all packets addressed to the node's IPv4 care-of address. Hence, all packets addressed to the
mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in
an IPv4 header that includes the home agent's IPv4 address in the an IPv4 header that includes the home agent's IPv4 address in the
source address field and the mobile node's IPv4 care-of address in source address field and the mobile node's IPv4 care-of address in
the destination address field. the destination address field.
After accepting the binding updates and creating the corresponding After accepting the binding updates and creating the corresponding
entries, the home agent MUST send a binding acknowledgement as entries, the home agent MUST send a binding acknowledgement as
specified in [RFC3775]. In addition, if the binding update included specified in [RFC3775]. In addition, if the binding update included
an IPv4 home address option, the binding acknowledgement MUST include an IPv4 home address option, the binding acknowledgement MUST include
the IPv4 address acknowledgment option as described later in this the IPv4 address acknowledgment option as described in Section 3.2.1.
specification. The binding acknowledgement is encapsulated to the The binding acknowledgement is encapsulated to the IPv4 care-of
IPv4 care-of address, which was included in the source address field address, which was included in the source address field of the IPv4
of the IPv4 header encapsulating the binding update. header encapsulating the binding update.
3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses) 2.3.2.2. Foreign Network Supports IPv4 Only (Private 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. In containing the binding update to the home agent's IPv4 address. In
order to traverse the NAT device, IPv6 packets are tunneled using UDP order to traverse the NAT device, IPv6 packets are tunneled using UDP
and IPv4. The UDP port allocated for the home agent is TBD_DSMIPv6. and IPv4. The UDP port allocated for the home agent is 4191
(dsmipv6).
The mobile node uses the IPv4 address it gets from the visited The mobile node uses the IPv4 address it gets from the visited
network as a source address in the IPv4 header. The binding update network as a source address in the IPv4 header. The binding update
will contain the mobile node's IPv6 home address. will contain the mobile node's IPv6 home address.
After accepting the binding update, the home agent MUST create a new After accepting the binding update, the home agent MUST create a new
binding cache entry for the mobile node's IPv6 home address. If an binding cache entry for the mobile node's IPv6 home address. If an
IPv4 home address option were included, the home agent MUST create IPv4 home address option is included, the home agent MUST create
another entry for that address. All entries MUST point to the mobile another entry for that address. All entries MUST point to the mobile
node's IPv4 care-of address included in the source address of the node's IPv4 care-of address included in the source address of the
IPv4 header that encapsulated the binding update message. In IPv4 header that encapsulated the binding update message. In
addition, the tunnel used MUST indicate UDP encapsulation for NAT addition, the tunnel used MUST indicate UDP encapsulation for NAT
traversal. Hence, all packets addressed to the mobile node's home traversal. Hence, all packets addressed to the mobile node's home
address(es) (IPv4 or IPv6) will be encapsulated in UDP then address(es) (IPv4 or IPv6) will be encapsulated in UDP and then
encapsulated in an IPv4 header that includes the home agent's IPv4 encapsulated in an IPv4 header that includes the home agent's IPv4
address in the source address field and the mobile node's IPv4 care- address in the source address field and the mobile node's IPv4 care-
of address in the destination address field. Note that the home of address in the destination address field. Note that the home
agent MUST store the source UDP port numbers contained in the packet agent MUST store the source UDP port numbers contained in the packet
carrying the binding update in order to be able to forward packets to carrying the binding update in order to be able to forward packets to
the mobile node. the mobile node.
After accepting the binding updates and creating the corresponding After accepting the binding updates and creating the corresponding
entries, the home agent MUST send a binding acknowledgement as entries, the home agent MUST send a binding acknowledgement as
specified in [RFC3775]. In addition, if the binding update included specified in [RFC3775]. In addition, if the binding update included
an IPv4 home address option, the binding acknowledgement MUST include an IPv4 home address option, the binding acknowledgement MUST include
the IPv4 address acknowledgment option as described later in this the IPv4 address acknowledgment option as described later in this
specification. The binding acknowledgement is encapsulated in UDP specification. The binding acknowledgement is encapsulated in UDP
then IPv4 with the home agent's IPv4 address in the source address and then in IPv4 with the home agent's IPv4 address in the source
field and the mobile node's IPv4 care-of address in the destination address field and the mobile node's IPv4 care-of address in the
field. The IPv4 address in the destination field of the IPv4 packet destination field. The IPv4 address in the destination field of the
is the source address received in the IPv4 header containing the IPv4 packet is the source address that was received in the IPv4
binding update message. The inner IPv6 packet will contain the home header containing the binding update message. The inner IPv6 packet
agent's IPv6 address as a source address and the mobile node's IPv6 will contain the home agent's IPv6 address as a source address and
home address in the destination address field. the mobile node's IPv6 home address in the destination address field.
The mobile node needs to maintain the NAT bindings for its current The mobile node needs to maintain the NAT bindings for its current
IPv4 care-of address. This is done through sending the binding IPv4 care-of address. This is done through sending the binding
update regularly to the home agent. update regularly to the home agent.
3.4. Route Optimization 2.4. Route Optimization
Route optimization, as specified in [RFC3775] will operate in an Route optimization, as specified in [RFC3775], will operate in an
identical manner for dual stack mobile nodes when they are located in identical manner for dual stack mobile nodes when they are located in
a visited network that provides IPv6 addresses to the mobile node and a visited network that provides IPv6 addresses to the mobile node and
while communicating with an IPv6-enabled correspondent node. while communicating with an IPv6-enabled correspondent node.
However, when located in an IPv4-only network, or when using the IPv4 However, when located in an IPv4-only network, or when using the IPv4
home address to communicate with an IPv4 correspondent node, route home address to communicate with an IPv4 correspondent node, route
optimization will not be possible due to the difficulty of performing optimization will not be possible due to the difficulty of performing
the return routability test. In this specification, UDP the return-routability test. In this specification, UDP
encapsulation is only used between the mobile node and its home encapsulation is only used between the mobile node and its home
agent. Therefore, mobile nodes will need to communicate through the agent. Therefore, mobile nodes will need to communicate through the
home agent. home agent.
Route optimization will not be possible for IPv4 traffic. That is, Route optimization will not be possible for IPv4 traffic -- that is,
traffic addressed to the mobile node's IPv4 home address. This is traffic addressed to the mobile node's IPv4 home address. This is
similar to using Mobile IPv4, therefore there is no reduction of similar to using Mobile IPv4; therefore, there is no reduction of
features resulting from using this specification. features resulting from using this specification.
3.5. Dynamic IPv4 Home Address Allocation 2.5. Dynamic IPv4 Home Address Allocation
It is possible to allow for the mobile node's IPv4 home address to be It is possible to allow for the mobile node's IPv4 home address to be
allocated dynamically. This is done by including 0.0.0.0 in the IPv4 allocated dynamically. This is done by including 0.0.0.0 in the IPv4
home address option included in the binding update. The home agent home address option that is included in the binding update. The home
SHOULD allocate an IPv4 address to the mobile node and include it in agent SHOULD allocate an IPv4 address to the mobile node and include
the IPv4 address acknowledgement option sent to the mobile node. In it in the IPv4 address acknowledgement option sent to the mobile
this case, the lifetime of the binding is bound to the minimum of the node. In this case, the lifetime of the binding is bound to the
lifetimes of the IPv6 binding and the lease time of the IPv4 home minimum of the lifetimes of the IPv6 binding and the lease time of
address. the IPv4 home address.
4. Extensions And Modifications To Mobile IPv6 3. Extensions and Modifications to Mobile IPv6
This section highlights the protocol and implementation additions This section highlights the protocol and implementation additions
required to support this specification. required to support this specification.
4.1. Binding Update Extensions 3.1. Binding Update Extensions
4.1.1. IPv4 Home Address Option 3.1.1. IPv4 Home Address Option
This option is included in the Mobility Header including the binding This option is included in the mobility header, including the binding
update message sent from the mobile node to a home agent or Mobility update message sent from the mobile node to a home agent or Mobility
Anchor Point. The alignment requirement for this option is 4n. Anchor Point. The alignment requirement for this option is 4n.
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 |Prefix-len |P| Reserved | | Type | Length |Prefix-len |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv4 Home Address Option Figure 1: IPv4 Home Address Option
Type Type
TBD 29
Length Length
6 6
Prefix-len Prefix-len
The length of the prefix allocated to the mobile node. If only a The length of the prefix allocated to the mobile node. If only a
single address is allocated, this field MUST be set to 32. In the single address is allocated, this field MUST be set to 32. In the
first binding update requesting a prefix, the field contains the first binding update requesting a prefix, the field contains the
skipping to change at page 16, line 17 skipping to change at page 12, line 51
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.
IPv4 Home Address IPv4 Home Address
The mobile node's IPv4 home address that should be defended by the The mobile node's IPv4 home address that should be defended by the
home agent. This field could contain any unicast IPv4 address home agent. This field could contain any unicast IPv4 address
(public or private) that was assigned to the mobile node. The (public or private) that was assigned to the mobile node. The
value 0.0.0.0 is used to request an IPv4 home address from the value 0.0.0.0 is used to request an IPv4 home address from the
home agent. A mobile node may choose to use this option to home agent. A mobile node may choose to use this option to
request a prefix by setting the address to the All Zeroes and request a prefix by setting the address to All Zeroes and setting
setting the P flag. The mobile node could then form an IPv4 home the P flag. The mobile node could then form an IPv4 home address
address based on the allocated prefix. Alternatively, the mobile based on the allocated prefix. Alternatively, the mobile node may
node may use two different options, one for requesting an address use two different options, one for requesting an address (static
(Static or Dynamic) and another for requesting a prefix. or dynamic) and another for requesting a prefix.
4.1.2. The IPv4 Care-of Address Option 3.1.2. The IPv4 Care-of Address Option
This option is included in the Mobility Header including the binding This option is included in the mobility header, including the binding
update message sent from the mobile node to a home agent or Mobility update message sent from the mobile node to a home agent or Mobility
Anchor Point. The alignment requirement for this option is 4n. Anchor Point. The alignment requirement for this option is 4n.
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 | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Care-of address | | IPv4 Care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The IPv4 CoA Option Figure 2: The IPv4 CoA Option
Type Type
TBD 32
Length Length
6 6
Reserved Reserved
This field is set to zero by the sender and ignored by the This field is set to zero by the sender and ignored by the
receiver. receiver.
IPv4 Care-of Address IPv4 Care-of Address
This field contains the mobile node's IPv4 care- of address. The This field contains the mobile node's IPv4 care- of address. The
IPv4 care-of address is used when the mobile node is located in an IPv4 care-of address is used when the mobile node is located in an
IPv4-only network. IPv4-only network.
4.1.3. The Binding Update Message Extensions 3.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 one new
flags. The flags are shown and described below. flag. The flag is 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| 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. This flag SHOULD NOT be set 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; when the mobile node is configured with an IPv6 care-of address --
with the exception for the scenario mentioned in Section 5.4.1 with the exception of the scenario mentioned in Section 4.4.1.
4.2. Binding Acknowledgement Extensions 3.2. Binding Acknowledgement Extensions
4.2.1. IPv4 Address Acknowledgement Option 3.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
of Dynamic IPv4 home address configuration (i.e., if the unspecified of dynamic IPv4 home address configuration (i.e., if the unspecified
IPv4 address was included in the binding update). The alignment IPv4 address was included in the binding update). The alignment
requirement for this option is 4n. requirement for this option is 4n.
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 | Status |Pref-len |Res| | Type | Length | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 14 skipping to change at page 15, line 4
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 | Status |Pref-len |Res| | Type | Length | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Address Acknowledgement Option Figure 4: IPv4 Address Acknowledgement Option
Type Type
TBD 30
Length Length
6 6
Status Status
Indicates success or failure for the IPv4 home address binding. Indicates success or failure for the IPv4 home address binding.
Values from 0 to 127 indicate success. Higher values indicate Values from 0 to 127 indicate success. Higher values indicate
failure. failure.
skipping to change at page 18, line 46 skipping to change at page 15, line 35
Res Res
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
IPv4 Home Address IPv4 Home Address
The IPv4 home address that the home agent will use in the binding The IPv4 home address that the home agent will use in the binding
cache entry. This could be a public or private address. This cache entry. This could be a public or private address. This
field MUST contain the mobile node's IPv4 home address. If the field MUST contain the mobile node's IPv4 home address. If the
address were dynamically allocated the home agent will add the address were dynamically allocated, the home agent will add the
address to inform the mobile node. Otherwise, if the address were address to inform the mobile node. Otherwise, if the address is
statically allocated to the mobile node, the home agent will copy statically allocated to the mobile node, the home agent will copy
it from the binding update message. it from the binding update message.
The following values are allocated for the Status field: The following values are allocated for the status field:
o 0 Success o 0 Success
o 128 Failure, reason unspecified o 128 Failure, reason unspecified
o 129 Administratively prohibited o 129 Administratively prohibited
o 130 Incorrect IPv4 home address o 130 Incorrect IPv4 home address
o 131 Invalid IPv4 address o 131 Invalid IPv4 address
skipping to change at page 19, line 14 skipping to change at page 16, line 4
o 0 Success o 0 Success
o 128 Failure, reason unspecified o 128 Failure, reason unspecified
o 129 Administratively prohibited o 129 Administratively prohibited
o 130 Incorrect IPv4 home address o 130 Incorrect IPv4 home address
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 3.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. This might a suggested NAT binding refresh time for the mobile node. This might
be usefl for scenarios where the mobile node is known to be moving be useful for scenarios where the mobile node is known to be moving
within the home agent's administrative domain, and therefore the NAT within the home agent's administrative domain and, therefore, the NAT
timeout is known (through configuration) to the home agent. Section timeout is known (through configuration) to the home agent. Section
3.5 of [RFC5405] discusses issues with NAT timeout in some detail. 3.5 of [RFC5405] discusses issues with NAT timeout in some detail.
The alignment requirement for this option is 4n. If a NAT is The alignment requirement for this option is 4n. If a NAT is
detected, this option MUST be sent by the home agent. 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
Type Type
TBD 31
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. This flag SHOULD NOT be set when the mobile node and home agent. This flag SHOULD NOT be set when the
mobile node is assigned an IPv6 care-of address; with the mobile node is assigned an IPv6 care-of address -- with the
exception for accomodating the scenarios discussed in exception of accommodating the scenarios discussed in
Section 5.4.1. Section 4.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 6.
5. Protocol operation 4. 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 4.1. Tunnelling 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 [RFC2473].
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. A UDP encapsulation format mobile node and its home agent or MAP. A UDP encapsulation format
means the following order of headers: means the following order of headers:
IPv4/v6 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 Note that the use of UDP encapsulation for IPv6 care-of addresses
SHOULD NOT be done except in the circumstances highlighted in SHOULD NOT be done except in the circumstances highlighted in Section
Section 5.4.1. 4.4.1.
When using this format the receiver would parse the version field When using this format, the receiver parses 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.
UDP Tunnelling can also encapsulate an ESP header as shown below. UDP tunnelling can also encapsulate an Encapsulating Security Payload
(ESP) header as shown below:
IPv4/v6 IPv4/v6
UDP UDP
ESP ESP
IP (v4 or v6) IP (v4 or v6)
Other headers Other headers
The negotiation of the secure tunnel format described above is The negotiation of the secure tunnel format described above is
discussed in Section 6.2. The receiver of a UDP tunnel detects discussed in Section 5.2. The receiver of a UDP tunnel detects
whether an ESP header is present or not based on the UDP port used. whether or not an ESP header is present based on the UDP port used.
5.1.1. tunnelling Impacts on Transport and MTU 4.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 impact the link and path
and path MTU, which may affect the amount of bandwidth available to MTU, which may affect the amount of bandwidth available to the
the applications. The mobile node may use PMTUD as specified in applications. The mobile node may use Path MTU Discovery (PMTUD) as
[RFC4459]. specified in [RFC4459].
To accommodate traffic that uses Explicit Congestion Notification To accommodate traffic that uses Explicit Congestion Notification
(ECN), it is RECOMMENDED that the ECN and DSCP information is copied (ECN), it is RECOMMENDED that the ECN and Differentiated Services
between the inner and outer header as defined in [RFC3168] and Code Point (DSCP) information be copied between the inner and outer
[RFC2983]. It is RECOMMENDED that the full-functionality option header as defined in [RFC3168] and [RFC2983]. It is RECOMMENDED that
defined in section 9.1.1 of [RFC3168]is used to deal with ECN. the full-functionality option defined in Section 9.1.1 of [RFC3168]
be used to deal with ECN.
Note that some impementations may not be able to use ECN over the UDP Note that some implementations may not be able to use ECN over the
tunnel. This is due to the lack of access to ECN bits in the UDP API UDP tunnel. This is due to the lack of access to ECN bits in the UDP
on most platforms. However, this issue can be avoided if UDP API 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 Time to Live (TTL) field
decremented in the same manner as when IP in IP encapsulation is must be decremented in the same manner as when IP-in-IP encapsulation
used. is used.
5.2. NAT Detection 4.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 when encapsulating packets between the mobile node and the home agent when
the mobile node is present in a private IPv4 network. Mobile IPv6 the mobile node is present in a private IPv4 network. Mobile IPv6
uses IKEv2 to establish te IPsec security association between the uses IKEv2 to establish the IPsec security association (SA) between
mobile node and the home agent. IKEv2 has its own NAT detection the mobile node and the home agent. IKEv2 has its own NAT detection
mechanism. However, IKEv2's NAT detection is only used for the mechanism. However, IKEv2's NAT detection is only used for the
purpose of setting up the IPsec SA for secure traffic. 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 5.
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 was in the path and the NAT detection option is Otherwise, a NAT was in the path and the NAT detection option is
included in the binding acknowledgement. The binding included in the binding acknowledgement. The binding acknowledgement
acknowledgement, and all future packets, are then encapsulated in UDP and all future packets are then encapsulated in UDP and IPv4. The
and IPv4. The source address in the IPv4 header is the IPv4 address source address in the IPv4 header is the IPv4 address of the home
of the home agent. The destination address is the IPv4 address agent. The destination address is the IPv4 address received in the
received in the IPv4 header encapsulating the binding update (this IPv4 header encapsulating the binding update (this address will be
address will be different from the IPv4 care-of address when a NAT is different from the IPv4 care-of address when a NAT is in the path).
in the path). The source port in the packet is the home agent's The source port in the packet is the home agent's source port. The
source port. The destination port is the source port received in the destination port is the source port received in the binding update
binding update message. Note that the home agent stores the port message. Note that the home agent stores the port numbers and
numbers and associates them with the mobile node's tunnel in order to associates them with the mobile node's tunnel in order to forward
forward future packets. future packets.
Upon receiving the binding acknowledgement with the NAT detection Upon receiving the binding acknowledgement with the NAT detection
option, the mobile node sets the tunnel to the home agent to UDP option, the mobile node sets the tunnel to the home agent to UDP
encapsulation. Hence, all future packets to the home agent are encapsulation. Hence, all future packets to the home agent are
tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source
address in the IPv6 header is the mobile node's IPv6 home address and address in the IPv6 header is the mobile node's IPv6 home address and
the destination address is the correspondent node's IPv6 address. the destination address is the correspondent node's IPv6 address.
All tunneled IPv4 packets will contain the mobile node's IPv4 home All tunneled IPv4 packets will contain the mobile node's IPv4 home
address in the source address field of the inner IPv4 packet and the address in the source address field of the inner IPv4 packet and the
correspondent node's IPv4 address in the destination address field. correspondent node's IPv4 address in the destination address field.
The outer IPv4 header is the same whether the inner packet is IPv4 or The outer IPv4 header is the same whether the inner packet is IPv4 or
IPv6. IPv6.
If no NAT device was detected in the path between the mobile node and If no NAT device was detected in the path between the mobile node and
the home agent then IPv6 packets are tunneled in an IPv4 header, the home agent, then IPv6 packets are tunneled in an IPv4 header
unless the home agent forces UDP encapsulation using the F flag. The unless the home agent forces UDP encapsulation using the F flag. The
content of the inner and outer headers are identical to the UDP content of the inner and outer headers are identical to the UDP
encapsulation case. encapsulation case.
A mobile node MUST always tunnel binding updates in UDP when located A mobile node MUST always tunnel binding updates in UDP when located
in an IPv4-only network. Essentially, this process allows for in an IPv4-only network. Essentially, this process allows for
perpetual NAT detection. Similarly, the home agent MUST encapsulate perpetual NAT detection. Similarly, the home agent MUST encapsulate
binding acknowledgements in a UDP header whenever the binding update binding acknowledgements in a UDP header whenever the binding update
is encapsulated in UDP. is encapsulated in UDP.
skipping to change at page 24, line 13 skipping to change at page 20, line 31
acknowledgement messages are shown below: acknowledgement messages are shown below:
Binding update received by the home agent: Binding update received by the home agent:
IPv4 header (src=V4ADDR, dst=HA_V4ADDR) IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header UDP header
IPv6 header (src=V6HOA, dst=HAADDR) IPv6 header (src=V6HOA, dst=HAADDR)
ESP Header ESP header
Mobility header Mobility header
BU [IPv4 HAO] BU [IPv4 HAO]
IPv4 CoA option IPv4 CoA option
Where V4ADDR is either the IPv4 care-of address or the address Where V4ADDR is either the IPv4 care-of address or the address
provided by the NAT device. V6HOA is the IPv6 home address of the provided by the NAT device. V6HOA is the IPv6 home address of the
mobile node. The binding update MAY also contain the IPv4 home mobile node. The binding update MAY also contain the IPv4 home
address option IPv4 HAO. address option, IPv4 HAO.
Binding acknowledgement sent by the home agent: Binding acknowledgement sent by the home agent:
IPv4 header (src= HA_V4ADDR, dst=V4ADDR) IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
UDP Header UDP header
IPv6 header (src=HAADDR, dst=V6HOA) IPv6 header (src=HAADDR, dst=V6HOA)
ESP header
ESP Header Mobility header
Mobility Header
BA ([IPv4 ACK], NAT DET) BA ([IPv4 ACK], NAT DET)
Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is Where V6HOA is the IPv6 home address of the mobile node. The IPv4
the IPv4 address acknowledgement option, which is only included if ACK is the IPv4 address acknowledgement option, which is only
the IPv4 home address option were present in the BU. The NAT DET is included if the IPv4 home address option is present in the BU. The
the NAT detection option, which MUST be present in the binding NAT DET is the NAT detection option, which MUST be present in the
acknowledgement message if the binding update was encapsulated in binding acknowledgement message if the binding update was
UDP. encapsulated in UDP.
5.3. NAT Keepalives 4.3. NAT Keepalives
If a NAT is detected, the mobile node will need to refresh the NAT If a NAT is detected, the mobile node will need to refresh the NAT
bindings in order to be reachable from the home agent. NAT bindings bindings in order to be reachable from the home agent. NAT bindings
can be refreshed through sending and receiving traffic encapsulated can be refreshed through sending and receiving traffic encapsulated
in UDP. However, if the mobile node is not active, it will need to in UDP. However, if the mobile node is not active, it will need to
periodically send a message to the home agent in order to refresh the periodically send a message to the home agent in order to refresh the
NAT binding. This can be done using the binding update message. The NAT binding. This can be done using the binding update message. The
binding update/acknowledgement pair will ensure that the NAT bindings binding update/acknowledgement pair will ensure that the NAT bindings
are refreshed in a reliable manner. There is no way for the mobile are refreshed in a reliable manner. There is no way for the mobile
node to know the exact time of the NAT binding. The default time node to know the exact time of the NAT binding. The default time
suggested in this specification is NATKATIMEOUT. If the home agent suggested in this specification is NATKATIMEOUT (see Section 6). If
suggests a different refresh period in the binding acknowledgement, the home agent suggests a different refresh period in the binding
the mobile node SHOULD use the value suggested by the home agent. acknowledgement, the mobile node SHOULD use the value suggested by
the home agent.
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., one that only cares about the session continuity
Mobile IP) it does not need to refresh the NAT binding. In this aspect of Mobile IP) does not need to refresh the NAT binding. In
case, the mobile node would only be able to initiate communication this case, the mobile node would only be able to initiate
with other nodes. However, this is likely to imply that the mobile communication with other nodes. However, this is likely to imply
node will need to send a binding update before initiating that the mobile node will need to send a binding update before
communication after a long idle period as it is likely to be assigned initiating communication after a long idle period as it is likely to
a different port and IPv4 address by the NAT when it initiates be assigned a different port and IPv4 address by the NAT when it
communication. Hence, an implementation may choose, for the sake of initiates communication. Hence, an implementation may choose, for
simplicity, to always maintain the NAT bindings even when it does not the sake of simplicity, to always maintain the NAT bindings even when
need reachability. it does not need reachability.
Note that keepalives are also needed by IKEv2 over UDP port 4500. 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 This is needed for IKE (Internet Key Exchange Protocol) dead-peer
DSMIPv6 keepalives. detection, which is not handled by DSMIPv6 keepalives.
5.4. Mobile Node Operation 4.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 4.4.1. Selecting a Care-of Address
When a mobile node is in a dual stacked visited network, it will have When a mobile node is in a dual stacked, visited network, it will
a choice between an IPv4 and an IPv6 care-of address. The mobile have a choice between an IPv4 and an IPv6 care-of address. The
node SHOULD prefer the IPv6 care-of address and bind it to its home mobile node SHOULD prefer the IPv6 care-of address and bind it to its
address(es). If a mobile node attempted to bind the IPv6 care-of home address(es). If a mobile node attempted to bind the IPv6 care-
address to its home address(es) and the binding update timed out, the of address to its home address(es) and the binding update timed out,
mobile node SHOULD: the mobile node SHOULD:
o Resend the binding update using the exponential back-off algorithm o Resend the binding update using the exponential back-off algorithm
described in [RFC3775]. described in [RFC3775].
o If after three attempts in total a binding acknowledgement was not o If after three attempts, in total, a binding acknowledgement was
received, the mobile node SHOULD send a new binding update using not received, the mobile node SHOULD send a new binding update
the IPv4 care-of address. The exponential backoff algorithm using the IPv4 care-of address. The exponential backoff algorithm
described in [RFC3775] should be used for re-transmission of the described in [RFC3775] should be used for re-transmission of the
binding update if needed. binding update if needed.
This procedure should be used to avoid scenarios where IPv6 This procedure should be used to avoid scenarios where IPv6
connectivity may not be as reliable as IPv4. This may take place connectivity may not be as reliable as IPv4. This unreliability may
during early deployments of IPv6, or simply due to temporary outages take place during early deployments of IPv6 or may simply be due to
affecting IPv6 routing. temporary outages affecting IPv6 routing.
It is RECOMMENDED that upon movement the mobile node does not change It is RECOMMENDED that upon movement, the mobile node not change the
the IP address family chosen for the previous binding update unless IP address family chosen for the previous binding update unless the
the mobile node is aware that it has moved to a different mobile node is aware that it has moved to a different administrative
administrative domain where previous problems with IPv6 routing may domain where previous problems with IPv6 routing may not be present.
not be present. Repeating the above procedure upon every movement Repeating the above procedure upon every movement can cause
can cause significant degradation of the mobile node's applications' significant degradation of the mobile node's applications'
performace due to extended periods of packet losses after handover if performance due to extended periods of packet losses after handover,
the routing outage is still in effect. if 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 update persistent packet losses, it may attempt to resend the binding update
with the F flag set, requesting UDP encapsulation for all packets. with the F flag set, requesting UDP encapsulation for all 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 this address selection mechanism is to allow the
follwing preferences in the absence of NAT: following 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 IP in IP is not allowed by the local 3. UDP encapsulation when IP-in-IP is not allowed by the local
domain. domain.
5.4.2. Sending Binding Updates 4.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 UDP. o The IPv6 packet is encapsulated in UDP.
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.
o The IPv4 home address option MAY be included in the mobility o The IPv4 home address option MAY be included in the mobility
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 must
set the F flag in the binding update message. set the F flag in the binding update message.
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 In addition to the rules in [RFC3775], the mobile node should follow
the care-of address selection guidelines in Section 5.4.1. the care-of address selection guidelines in Section 4.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
entries in its binding update list, one for the IPv6 home address entries in its binding update list: one for the IPv6 home address
and another for the IPv4 home address. and another for the IPv4 home address.
o If the NAT detection option were present, the mobile node MUST o If the NAT detection option is present, the mobile node MUST
tunnel future packets in UDP and IPv4. This MUST be indicated in tunnel future packets in UDP and IPv4. This MUST be indicated in
the binding update list. the binding update list.
o If no IPv4 address acknowledgement option were present, and an o If no IPv4 address acknowledgement option is present, and an IPv4
IPv4 home address option was present in the binding update, the home address option was present in the binding update, the mobile
mobile node MUST only create one binding update list entry for its node MUST only create one binding update list entry for its IPv6
IPv6 home address. The mobile node MAY include the IPv4 home home address. The mobile node MAY include the IPv4 home address
address option in future binding updates. option in future binding updates.
o If an IPv4 address acknowledgement option were present and it o If an IPv4 address acknowledgement option is 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.
5.4.2.1. Removing Bindings 4.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 Deregistering 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 only the IPv4 home address 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.
Upon receiving this binding update, the home agent will replace the Upon receiving this binding update, the home agent will replace the
existing cache entries with the content of the new message. This existing cache entries with the content of the new message. This
ensures that the IPv4 home address binding is removed, while ensures that the IPv4 home address binding is removed while
maintining an IPv6 binding. maintaining an IPv6 binding.
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 4.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]. In cases where and receives IPv6 packets as described in [RFC3775]. In cases where
IP in IP encapsulation is not providing connectivity to the home IP-in-IP encapsulation is not providing connectivity to the home
agent, the mobile node may choose to encapsulate in UDP as suggested agent, the mobile node may choose to encapsulate in UDP as suggested
in Section 5.4.1. However, this encapsulation of IPv6 traffic should in Section 4.4.1. However, this encapsulation of IPv6 traffic should
be used as a last resort as described. IPv4 traffic is encapsulated be used as a last resort, as described. IPv4 traffic is encapsulated
in IPv6 packets to the home agent. 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]
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)
[UDP Header] [UDP 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.
5.4.4. Movement Detection in IPv4-only Networks 4.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.
5.5. Home agent operation This specification does not support mobile nodes returning home while
using IPv4. That is, the IPv4 support is only defined for mobile
nodes that are in a visited network.
4.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 presence in the NAT detection option included in the
acknowledgement. binding acknowledgement.
A home agent must also act as a proxy for address resolution in IPv4 A home agent must also act as a proxy for address resolution in IPv4
for the registered IPv4 home addresses of mobile nodes it is serving. for the registered IPv4 home addresses of mobile nodes it is serving.
Moreover, the administrative domain of the home agent is responsible Moreover, the administrative domain of the home agent is responsible
for advertising the routing information of registered IPv4 mobile for advertising the routing information of registered IPv4 mobile-
network prefixes of the mobile nodes. network prefixes of the mobile nodes.
In order to comply with this specification, the home agent MUST be In order to comply with this specification, the home agent MUST be
able to find the IPv4 home address of a mobile node when given the able to find the IPv4 home address of a mobile node when given the
IPv6 home address. That is, given an IPv6 home address, the home IPv6 home address. That is, given an IPv6 home address, the home
agent MUST store the corresponding IPv4 home address if a static one agent MUST store the corresponding IPv4 home address if a static one
is present. If a dynamic address were requested by the mobile node, is present. If a dynamic address is requested by the mobile node,
the home agent MUST store that address (associated with the IPv6 home the home agent MUST store that address (associated with the IPv6 home
address) after it's allocated to the mobile node. address) after it's allocated to the mobile node.
When the home agent receives a binding update encapsulated in UDP and When the home agent receives a binding update encapsulated in UDP and
containing the IPv4 home address option, it needs to follow all the containing the IPv4 home address option, it needs to follow all the
steps in [RFC3775] and [RFC3963]. In addition, the following checks steps in [RFC3775] and [RFC3963]. In addition, the following checks
MUST be done: MUST be done:
o If the IPv4 care-of address in the IPv4 CoA option is not the same o If the IPv4 care-of address in the IPv4 CoA option is not the same
as the IPv4 address in the source address in the IPv4 header then as the IPv4 address in the source address in the IPv4 header, then
a NAT was in the path. This information should be flagged for the a NAT was in the path. This information should be flagged for the
binding acknowledgement. binding acknowledgement.
o If the F flag in the binding update were set, the home agent needs o If the F flag in the binding update is 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 SHOULD NOT be used when the mobile node is UDP encapsulation SHOULD NOT be used when the mobile node is
located in an IPv6-enabled link, with the exception of the located in an IPv6-enabled link, with the exception of the
scenarios outlined in Section 5.4.1. scenarios outlined in Section 4.4.1.
o If the IPv4 home address option contains a valid unicast IPv4 o If the IPv4 home address option contains a valid unicast IPv4
address, the home agent MUST check that this address is allocated address, the home agent MUST check that this address is allocated
to the mobile node that has the IPv6 home address included in the to the mobile node that has the IPv6 home address included in the
home address option. The same MUST be done for an IPv4 prefix. home address option. The same MUST be done for an IPv4 prefix.
o If the IPv4 home address option contained the unspecified IPv4 o If the IPv4 home address option contained the unspecified IPv4
address, the home agent SHOULD dynamically allocate an IPv4 home address, the home agent SHOULD dynamically allocate an IPv4 home
address to the mobile node. If none is available, the home agent address to the mobile node. If none is available, the home agent
MUST return error code 132 in the status field of the IPv4 address MUST return error code 132 in the status field of the IPv4 address
acknowledgement option. If a prefix were requested, the home acknowledgement option. If a prefix is requested, the home agent
agent SHOULD allocate a prefix with the requested length; if SHOULD allocate a prefix with the requested length; if prefix
prefix allocation (of any length) was not possible, the home agent allocation (of any length) is not possible, the home agent MUST
MUST indicate failure of the operation with the appropriate error indicate failure of the operation with the appropriate error code.
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
included in the binding update. If the care-of address is an IPv4 included in the binding update. If the care-of address is an IPv4
address, the home agent MUST setup a tunnel to the IPv4 care-of address, the home agent MUST setup a tunnel to the IPv4 care-of
address of the mobile node. address of the mobile node.
When sending a binding acknowledgement to the mobile node, the home When sending a binding acknowledgement to the mobile node, the home
agent constructs the message according to [RFC3775] and [RFC3963]. agent constructs the message according to [RFC3775] and [RFC3963].
Note that the routing header MUST always contain the IPv6 home Note that the routing header MUST always contain the IPv6 home
address as specified in [RFC3775]. address as specified in [RFC3775].
If the care-of address of the mobile node were an IPv4 address, the If the care-of address of the mobile node is an IPv4 address, the
home agent includes the mobile node's IPv6 home address in the home agent includes the mobile node's IPv6 home address in the
destination address field in the IPv6 header. If a NAT were destination address field in the IPv6 header. If a NAT is detected,
detected, the home agent MUST then encapsulate the packet in UDP and the home agent MUST then encapsulate the packet in UDP and in an IPv4
an IPv4 header. The source address is set to the home agent's IPv4 header. The source address is set to the home agent's IPv4 address
address and the destination address is set to the address received in and the destination address is set to the address received in the
the source address of the IPv4 header encapsulating the binding source address of the IPv4 header encapsulating the binding update.
update.
After creating a binding cache entry for the mobile node's home After creating a binding cache entry for the mobile node's home
addresses, all packets sent to the mobile node's home addresses are addresses, all packets sent to the mobile node's home addresses are
tunneled by the home agent to the mobile node's care-of address. If tunneled by the home agent to the mobile node's care-of address. If
a NAT were detected, packets are encapsulated in UDP and IPv4. a NAT is detected, packets are encapsulated in UDP and IPv4.
Otherwise, if the care-of address is an IPv4 address, and no NAT were Otherwise, if the care-of address is an IPv4 address and no NAT is
detected, packets are encapsulated in an IPv4 header unless UDP detected, packets are encapsulated in an IPv4 header unless UDP
encapsulation is forced by the home agent. encapsulation is forced by the home agent.
5.5.1. Sending Packets to the Mobile Node 4.5.1. Sending Packets to the Mobile Node
The home agent follows the rules specified in [RFC3775] for sending The home agent follows the rules specified in [RFC3775] for sending
IPv6 packets to mobile nodes located in IPv6 networks. When sending IPv6 packets to mobile nodes located in IPv6 networks. When sending
IPv4 packets to mobile nodes in an IPv6 network, the home agent must IPv4 packets to mobile nodes in an IPv6 network, the home agent must
encapsulate the IPv4 packets in IPv6. encapsulate the IPv4 packets in IPv6.
When sending IPv6 packets to a mobile node located in an IPv4 When sending IPv6 packets to a mobile node located in an IPv4
network, the home agent must follow the format negotiated in the network, the home agent uses the following format:
binding update/acknowledgement exchange. In the absence of a
negotiated format, the default format that MUST be supported by all
implementations is:
IPv4 header (src= HA_V4ADDR, dst= V4ADDR) IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
UDP Header [UDP header]
IPv6 header (src=CN, dst= V6HoA) IPv6 header (src=CN, dst= V6HoA)
Upper layer protocols Upper layer protocols
Where the UDP header is only included if a NAT were detected between Where the UDP header is only included if a NAT is 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. V4ADDR is the IPv4 address received in the source encapsulation. V4ADDR is the IPv4 address received in the source
address field of the IPv4 packet containing the binding update. address field of the IPv4 packet containing the binding update.
When sending IPv4 packets to a mobile node located in an IPv4 When sending IPv4 packets to a mobile node located in an IPv4
network, the home agent must follow the format negotiated in the network, the home agent must follow the format negotiated in the
binding update/acknowledgement exchange. In the absence of a binding update/acknowledgement exchange. In the absence of a
negotiated format, the default format that MUST be supported by all negotiated format, the default format that MUST be supported by all
implementations is: implementations is:
IPv4 header (src= HA_V4ADDR, dst= V4ADDR) IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
[UDP Header] [UDP header]
IPv4 header (src=V4CN, dst= V4HoA) IPv4 header (src=V4CN, dst= V4HoA)
Upper layer protocols Upper layer protocols
Where the UDP header is only included if a NAT is detected between
Where the UDP header is only included if a NAT were detected between the mobile node and home agent or if the home agent forced UDP
the mobile node and home agent, or if the home agent forced UDP
encapsulation. encapsulation.
5.6. Correspondent Node Operation 4.6. Correspondent Node Operation
This specification has no impact on IPv4 or IPv6 correspondent nodes. This specification has no impact on IPv4 or IPv6 correspondent nodes.
6. Security Considerations 5. Security Considerations
This specification allows a mobile node to send one binding update This specification allows a mobile node to send one binding update
for its IPv6 and IPv4 home addresses. This is a slight deviation for its IPv6 and IPv4 home addresses. This is a slight deviation
from [RFC3775] which requires one binding update per home address. from [RFC3775], which requires one binding update per home address.
However, like [RFC3775], the IPsec security association needed to However, like [RFC3775], the IPsec security association needed to
authenticate the binding update is still based on the mobile node's authenticate the binding update is still based on the mobile node's
IPv6 home address. Therefore, in order to authorize the mobile IPv6 home address. Therefore, in order to authorize the mobile
node's IPv4 home address binding, the home agent MUST store the IPv4 node's IPv4 home address binding, the home agent MUST store the IPv4
address corresponding to the IPv6 address that is allocated to a address corresponding to the IPv6 address that is allocated to a
mobile node. Therefore, it is sufficient for the home agent to know mobile node. Therefore, it is sufficient for the home agent to know
that the IPsec verification for the packet containing the binding that the IPsec verification for the packet containing the binding
update was valid provided that it knows which IPv4 home address is update was valid, provided that it knows which IPv4 home address is
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 This specification requires the use of IKEv2 as the default mechanism
for dynamic keying. 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, is possible.
In this specification, the binding update message MUST be protected In this specification, the binding update message MUST be protected
using ESP transport mode. When the mobile node is located in an using ESP transport mode. When the mobile node is located in an
IPv4-only network, the binding update message is encapsulated in UDP IPv4-only network, the binding update message is encapsulated in UDP
as described earlier. However, UDP SHOULD NOT be used to encapsulate as described earlier in Section 4.2. However, UDP SHOULD NOT be used
the binding update message when the mobile node is located in an to encapsulate the binding update message when the mobile node is
IPv6-enabled network. If protection of payload traffic is needed located in an IPv6-enabled network. If protection of payload traffic
when the mobile node is located in an IPv4-only network, is needed when the mobile node is located in an IPv4-only network,
encapsulation is done using tunnel mode ESP over port 4500 as encapsulation is done using tunnel mode ESP over port 4500 as
described in [RFC3948]. During the IKE negotiation with the home described in [RFC3948]. During the IKE negotiation with the home
agent, if the mobile node and home agent support the use of port agent, if the mobile node and home agent support the use of port
4500, the mobile node MUST establish the security association over 4500, the mobile node MUST establish the security association over
port 4500, regardless of the presence of a NAT. This is done to port 4500, regardless of the presence of a NAT. This is done to
avoid the switching between ports 500 and 4500 and the potential avoid switching between ports 500 and 4500 and the potential traffic
traffic disruption resulting from this switch. disruption resulting from this switch.
Handovers within private IPv4 networks or from IPv6 to IPv4 networks Handovers within private IPv4 networks or from IPv6 to IPv4 networks
will have impacts on the security association between the mobile node will impact the security association between the mobile node and the
and the home agent. The following section presents the expected home agent. The following section presents the expected behaviour of
behaviour of the mobile node and home agent in those situations. The the mobile node and home agent in those situations. The details of
details of the IKE negotiations and messages are illustrated in the IKE negotiations and messages are illustrated in Section 5.2.
Section 6.2
6.1. Handover Interactions for IPsec and IKE 5.1. Handover Interactions for IPsec and IKE
After the mobile node detects movement it configures a new care-of After the mobile node detects movement, it configures a new care-of
address. If the mobile node is in an IPv4-only network, it removes address. If the mobile node is in an IPv4-only network, it removes
binding update list entries for correspondent nodes since route binding update list entries for correspondent nodes, since route
optimisation cannot be supported. This may cause inbound packet optimisation cannot be supported. This may cause inbound packet
losses as remote correspondent nodes are unaware of such movement. losses, as remote correspondent nodes are unaware of such movement.
To avoid confusion in the correspondent node, the mobile node SHOULD To avoid confusion in the correspondent node, the mobile node SHOULD
deregister its binding with each correspondent node by sending a deregister its binding with each correspondent node by sending a
deregistration binding update. The deregistration binding update deregistration binding update. The deregistration binding update
message is tunnelled to the home agent and onto the correspondent message is tunnelled to the home agent and onto the correspondent
node. This is done after the mobile node updates the home agent with node. This is done after the mobile node updates the home agent with
its new location as discussed below. its new location as discussed below.
The mobile node sends the binding update message to the home agent. The mobile node sends the binding update message to the home agent.
If the mobile node is in an IPv6-enabled network, the binding update If the mobile node is in an IPv6-enabled network, the binding update
SHOULD be sent without IPv4/UDP encapsulation, unless UDP SHOULD be sent without IPv4/UDP encapsulation, unless UDP
encapsulation is needed as described in Section 5.4.1. If the mobile encapsulation is needed as described in Section 4.4.1. If the mobile
node is in an IPv4-only network, then after IPsec processing of the node is in an IPv4-only network, then -- after IPsec processing of
BU message, it encapsulates the BU in UDP/IPv4 as discussed in the binding update (BU) message -- it encapsulates the BU in UDP/IPv4
sections 5.2 and 5.4. In order to be able to send the binding update as discussed in Sections 4.2 and 4.4. In order to be able to send
while in an IPv4-only network, the mobile node needs to use the new the binding update while in an IPv4-only network, the mobile node
IPv4 care-of address in the outer header, which is different from the needs to use the new IPv4 care-of address in the outer header, which
care-of address used in the existing tunnel. This should be done is different from the care-of address used in the existing tunnel.
without permanently updating the tunnel within the mobile node's This should be done without permanently updating the tunnel within
implementation in order to allow the mobile node to receive packets the mobile node's implementation in order to allow the mobile node to
on the old care-of address until the binding acknowledgement is receive packets on the old care-of address until the binding
received. The method used to achieve this effect is implementation acknowledgement is received. The method used to achieve this effect
dependent and is outside the scope of this specification. This is implementation dependent and is outside the scope of this
implies that the IP forwarding function (which selects the interface specification. This implies that the IP forwarding function (which
or tunnel through which a packet is sent) is not based solely on the selects the interface or tunnel through which a packet is sent) is
destination address: some IPv6 packets destined to the home agent are not based solely on the destination address: some IPv6 packets
sent via the existing tunnel, while BUs are sent using the new destined to the home agent are sent via the existing tunnel, while
care-of address. Since BUs are protected by IPsec, the forwarding BUs are sent using the new care-of address. Since BUs are protected
function cannot necessarily determine the correct treatment from the by IPsec, the forwarding function cannot necessarily determine the
packet headers. Thus, the DSMIPv6 implementation has to attach correct treatment from the packet headers. Thus, the DSMIPv6
additional information to BUs, and this information has to be implementation has to attach additional information to BUs, and this
preserved after IPsec processing and made available to the forwarding information has to be preserved after IPsec processing and made
function, or additional DSMIP processing added to the forwarding available to the forwarding function or to DSMIP extensions included
function. Depending on the mobile node's implementation, meeting in the forwarding function. Depending on the mobile node's
this requirement may require changes to the IPsec implementation. implementation, meeting this requirement may require changes to the
IPsec implementation.
Upon receiving the binding update message encapsulated in UDP/IPv4, Upon receiving the binding update message encapsulated in UDP/IPv4,
the home agent processes it as follows. In order to allow the the home agent processes it as follows. In order to allow the
DSMIPv6 implementation in the home agent to detect the presence of a DSMIPv6 implementation in the home agent to detect the presence of a
NAT on the path to the mobile node, it needs to compare the outer NAT on the path to the mobile node, it needs to compare the outer
IPv4 source address with the IPv4 address in the IPv4 care-of address IPv4 source address with the IPv4 address in the IPv4 care-of address
option. This implies that the information in the outer header will option. This implies that the information in the outer header will
be preserved after IPsec processing and made available to the DSMIPv6 be preserved after IPsec processing and made available to the DSMIPv6
implementation in the home agent. Depending on the home agent's implementation in the home agent. Depending on the home agent's
implementation, meeting this requirement may require changes to the implementation, meeting this requirement may require changes to the
IPsec implementation. IPsec implementation.
The home agent updates its tunnel mode security association to The home agent updates its tunnel mode security association to
include the mobile node's care-of address as the remote tunnel header include the mobile node's care-of address as the remote-tunnel header
address, and 4500 as the port number. The IPv4 address and port address and 4500 as the port number. The IPv4 address and port
number are likely to be wrong; the mobile node provides the correct number are likely to be wrong; the mobile node provides the correct
information in a separate exchange as described below. When the information in a separate exchange as described below. When the
mobile node is located in a private IPv4 network (which is detected mobile node is located in a private IPv4 network (which is detected
as described above), the new address and port number are allocated by as described above), the new address and port number are allocated by
the NAT. The home agent will also enable or disable UDP the NAT. The home agent will also enable or disable UDP
encapsulation for outgoing ESP packets for the purpose of NAT encapsulation for outgoing ESP packets for the purpose of NAT
traversal. traversal.
If the Key Management Mobility Capability (K) bit was set in the If the Key Management Mobility Capability (K) bit was set in the
binding update, and the home agent supports this feature, the home binding update, and the home agent supports this feature, the home
agent updates its IKE security associations to include the mobile agent updates its IKE security associations to include the mobile
node's care-of address as the peer address and 4500 as the port node's care-of address as the peer address and 4500 as the port
number. The home agent may also need to change NAT traversal fields number. The home agent may also need to change NAT traversal fields
in the IKE_SA to enable the dynamic update of the IP address and port in the IKE_SA to enable the dynamic update of the IP address and port
number based on the reception of authenticated IKE messages, or number, based on the reception of authenticated IKE messages or
authenticated packets using tunnel mode ESP. The dynamic updates are authenticated packets using tunnel mode ESP. The dynamic updates are
described in section 2.23 of RFC 4306. As described above, when the described in Section 2.23 of [RFC4306]. As described above, when the
mobile node is located in a private IPv4 network, the address and mobile node is located in a private IPv4 network, the address and
port number used for IPsec and IKE traffic is not yet known by the port number used for IPsec and IKE traffic is not yet known by the
home agent at this point. home agent at this point.
The mobile node updates the IKE SA in one of two ways. If the K flag The mobile node updates the IKE SA in one of two ways. If the K flag
was set in the binding acknowledgement message, the mobile node was set in the binding acknowledgement message, the mobile node
SHOULD send an empty informational message, which results in the IKE SHOULD send an empty informational message, which results in the IKE
module in the home agent to dynamically update the SA information. module in the home agent dynamically updating the SA information.
The IKE implementation in the home agent is REQUIRED to support this The IKE implementation in the home agent is REQUIRED to support this
feature. Alternatively, the IKE SA should be re-negotiated. Note feature. Alternatively, the IKE SA should be re-negotiated. Note
that updating the IKE SA MUST take place after the mobile node has that updating the IKE SA MUST take place after the mobile node has
sent the binding update and received the acknowledgement from the sent the binding update and received the acknowledgement from the
home agent. home agent.
It is important to note that the mobile node's IPv4 care-of address It is important to note that the mobile node's IPv4 care-of address
seen by the DSMIPv6 module in the home agent upon receiving the seen by the DSMIPv6 module in the home agent upon receiving the
binding update may differ from the IPv4 care-of address seen by the binding update may differ from the IPv4 care-of address seen by the
IKE module and the care-of address used for forwarding IPsec tunnel IKE module and the care-of address used for forwarding IPsec tunnel
mode traffic. Hence, it is probable that different modules in the mode traffic. Hence, it is probable that different modules in the
home agent will have a different care-of address that should be used home agent will have a different care-of address that should be used
for encapsulating traffic to the mobile node. for encapsulating traffic to the mobile node.
After successfully processing the binding update, the home agent After successfully processing the binding update, the home agent
sends the binding acknowledgement to the mobile node's care-of sends the binding acknowledgement to the mobile node's care-of
address as received in the outer header of the packet containing the address as received in the outer header of the packet containing the
binding update. Note that if the BU was rejected, the BAck is sent binding update. Note that if the BU was rejected, the binding
to the same address where the BU was received from. This may require acknowledgement (BAck) is sent to the same address from which the BU
special treatment in IP forwarding and/or IPsec processing which was received. This may require special treatment in IP forwarding
resembles sending of BUs in the mobile node (described above). and/or IPsec processing that resembles the sending of BUs in the
mobile node (described above).
Upon receiving the binding acknowledgement, the mobile node updates Upon receiving the binding acknowledgement, the mobile node updates
its local tunnel mode Security Association information to include the its local tunnel mode security association information to include the
tunnel header IP source address, which is the mobile node's address tunnel header IP source address, which is the mobile node's address,
and the tunnel header IP destination, which is the home agent's and the tunnel header IP destination, which is the home agent's
address. The mobile node may also need to enable or disable UDP address. The mobile node may also need to enable or disable UDP
encapsulation for outgoing ESP packets for the purpose of NAT encapsulation for outgoing ESP packets for the purpose of NAT
traversal and the sending of keep alives. traversal and the sending of keep alives.
The mobile node MAY use [RFC4555] to update its IKE SA with the home The mobile node MAY use MOBIKE [RFC4555] to update its IKE SA with
agent. Using MOBIKE requires negotiating this capability with the the home agent. Using MOBIKE requires negotiating this capability
home agent when establishing the SA. In this case, the mobile node with the home agent when establishing the SA. In this case, the
and the home agent MUST NOT update their IPsec SAs locally as this mobile node and the home agent MUST NOT update their IPsec SAs
step is performed by MOBIKE. Furthermore, the use of MOBIKE allows locally, as this step is performed by MOBIKE. Furthermore, the use
the mobile node to update the SA independently of the binding update of MOBIKE allows the mobile node to update the SA independently of
exchange. Hence, there is no need for the mobile node to wait for a the binding update exchange. Hence, there is no need for the mobile
binding acknowledgement before performing MOBIKE. The use of MOBIKE node to wait for a binding acknowledgement before performing MOBIKE.
is OPTIONAL in this specification. The use of MOBIKE is OPTIONAL in this specification.
6.2. IKE negotiation messages between the mobile node and Home Agent 5.2. IKE Negotiation Messages between the Mobile Node and Home Agent
This specification defines a number of possible data encapsulation This specification defines a number of possible data encapsulation
formats depending on the mobile node's connectivity to the visited formats, depending on the mobile node's connectivity to the visited
network. When connected to an IPv6-enabled network, the tunnelling network. When connected to an IPv6-enabled network, the tunnelling
formats are clear. However, when connected to an IPv4-only network, formats are clear. However, when connected to an IPv4-only network,
care should be taken when negotiating the IKE association and the care should be taken when negotiating the IKE association and the
consequential tunnelling formats used for secure and insecure consequential tunnelling formats used for secure and insecure
traffic. This section illustrates the IKE message exchange between traffic. This section illustrates the IKE message exchange between
the mobile node and home agent when the mobile node is located in an the mobile node and home agent when the mobile node is located in an
IPv4-only network. Two different IKE negotiations are considered: IPv4-only network. Two different IKE negotiations are considered:
o IKEv2 operation for securing DSMIPv6 Signaling. o IKEv2 operation for securing DSMIPv6 signaling.
o IKEv2 operation for securing Data over IPv4 o IKEv2 operation for securing data over IPv4
6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling 5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling
A mobile node connected to an IPv4-only network SHOULD follow the A mobile node connected to an IPv4-only network SHOULD follow the
procedures described below in order to establish an SA for the procedures described below in order to establish an SA for the
protection of binding update and binding acknowledgement messages. protection of binding update and binding acknowledgement messages.
Note that V4ADDR refers to either the mobile node's care-of address
in the visited link or the public address allocated to the mobile
node by the NAT.
Mobile Node Home Agent Mobile Node Home Agent
----------- ---------- ----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR) IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (500, 500) HDR, SAi1, KEi, Ni UDP (500, 500) HDR, SAi1, KEi, Ni
NAT-D, NAT-D --> NAT-D, NAT-D -->
<- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ]
NAT-D, NAT-D NAT-D, NAT-D
skipping to change at page 37, line 35 skipping to change at page 34, line 4
IPv4(source_addr=V4ADDR, dest_addr=HAADDR) IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) <non-ESP Marker > HDR, SK UDP (4500,4500) <non-ESP Marker > HDR, SK
{IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE),
SAi2, TSi, TSr} SAi2, TSi, TSr}
--> -->
<-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) <non-ESP Marker > HDR, SK UDP (4500,Y) <non-ESP Marker > HDR, SK
{IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE),
SAr2, TSi, TSr} SAr2, TSi, TSr}
The corresponding Security Policy Database (SPD) entries are shown
The corresponding SPD entries are shown below. below.
Mobile node SPD-S: Mobile node SPD-S:
IF local_address = home_address_1 & IF local_address = home_address_1 &
remote_address = home_agent_1 & remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use proto = MH & local_mh_type = BU &
SA ESP transport mode
remote_mh_type = BAck
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1 Initiate using IDi = user_1 to address home_agent_1
Home Agent SPD-S: Home Agent SPD-S:
IF local_address = home_agent_1 & IF local_address = home_agent_1 &
remote_address = home_address_1 & remote_address = home_address_1 &
proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use proto = MH &
SA ESP transport mode
where home_address_1 is the mobile node's registered IPv6 home local_mh_type = BAck &
address and home_agent_1 is the IP address of the home agent
remote_mh_type = BU
Then use SA ESP transport mode
Where home_address_1 is the mobile node's registered IPv6 home
address and home_agent_1 is the IP address of the home agent.
The above should result in BU/BA messages with the following BU The above should result in BU/BA messages with the following BU
received by the home agent. received by the home agent:
IPv4 header (src=V4ADDR, dst=HA_V4ADDR) IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (sport=Z, dport=DSMIPv6) UDP header (sport=Z, dport=DSMIPv6)
IPv6 header (src=V6HOA, dst=HAADDR) IPv6 header (src=V6HOA, dst=HAADDR)
ESP Header in Transport Mode ESP header in transport mode
Mobility header Mobility header
BU [IPv4 HAO] BU [IPv4 HAO]
IPv4 CoA option IPv4 CoA option
(+ other as needed) (and others as needed)
At the home agent, following UDP de-capsulation, the binding update At the home agent, following UDP de-capsulation, the binding update
is delivered to the IPsec module as shown below: is delivered to the IPsec module as shown below:
IPv6 header (src=V6HOA, dst=HAADDR) IPv6 header (src=V6HOA, dst=HAADDR)
ESP Header in Transport Mode ESP header in transport mode
Mobility header Mobility header
BU [IPv4 HAO] BU [IPv4 HAO]
IPv4 CoA option IPv4 CoA option
(+other as needed) (and others as needed)
In addition, V4ADDR and the sport (Z) need to be passed with the In addition, V4ADDR and the sport (Z) need to be passed with the
packet to ensure correct processing. packet to ensure correct processing.
Following IPsec processing, the binding update is delivered to the Following IPsec processing, the binding update is delivered to the
DSMIPv6 home agent module as follows: DSMIPv6 home agent module as follows:
IPv6 header (src=V6HOA, dst=HAADDR) IPv6 header (src=V6HOA, dst=HAADDR)
Mobility Header Mobility header
BU [IPv4 HAO] BU [IPv4 HAO]
IPv4 CoA option IPv4 CoA option
(+other as needed) (and others as needed)
In addition, V4ADDR and the sport (Z) need to be passed with the In addition, V4ADDR and the sport (Z) need to be passed with the
packet to ensure correct processing. packet to ensure correct processing.
The binding acknowledgement sent by the home agent module to the The binding acknowledgement sent by the home agent module to the
IPsec module is as follows: IPsec module is as follows:
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) (and others 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 UDP encapsulation must be used, need to be passed with the that UDP encapsulation must be used need to be passed with the packet
packet to ensure correct processing. 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)
ESP Header in Transport Mode ESP header in transport mode
Mobility Header Mobility header
BA ([IPv4 ACK], NAT DET) BA ([IPv4 ACK], NAT DET)
6.2.2. IKEv2 Operation for Securing Data over IPv4 5.2.2. IKEv2 Operation for Securing Data over IPv4
To secure data traffic when the mobile node is located in an IPv4- To secure data traffic when the mobile node is located in an IPv4-
only network, the mobile node MUST establish a child_SA for that only network, the mobile node MUST establish a child_SA for that
purpose. The procedure is as follows: purpose. Note that V4ADDR refers to either the mobile node's care-of
address in the visited link or the public address allocated to the
mobile node by the NAT. The procedure is as follows:
Mobile Node Home Agent Mobile Node Home Agent
----------- ---------- ----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR) IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) < non-ESP Marker > HDR, SK UDP (4500,4500) < non-ESP Marker > HDR, SK
{[N], SA, Ni, [KEi], TSi, TSr} --> {[N], SA, Ni, [KEi], TSi, TSr} -->
<--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) < non-ESP Marker > HDR, SK UDP (4500,Y) < non-ESP Marker > HDR, SK
SA, Nr, [KEr], TSi, TSr} SA, Nr, [KEr], TSi, TSr}
If no NAT is detected, the encapsulation used will be: If no NAT is detected, the encapsulation used will be:
IPv4 (source_addr=v4CoA, dest_addr=HAAddr) IPv4 (source_addr=v4CoA, dest_addr=HAAddr)
ESP ESP
IP (source_addr=HoA, set_addr=CNAddr) IP (source_addr=HoA, set_addr=CNAddr)
Upper_layer_HDR Upper_layer_HDR
Where IP is either IPv4 or IPv6 and HoA is either the IPv4 HoA or the
IPv6 HoA.
where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA If a NAT is detected, the encapsulation used will be:
If a NAT were detected, the encapsulation used will be:
IPv4 (source_addr=v4Addr, dest_addr=HAAddr) IPv4 (source_addr=v4Addr, dest_addr=HAAddr)
UDP (sport=Y, dport=4500) UDP (sport=Y, dport=4500)
ESP ESP
IP (source_addr=HoA, set_addr=CNAddr) IP (source_addr=HoA, set_addr=CNAddr)
Upper_layer_HDR Upper_layer_HDR
Where v4CoA may be the external IPv4 address of the NAT, IP is either Where v4CoA may be the external IPv4 address of the NAT, IP is either
an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. an IPv4 or IPv6 header, and HoA is either the IPv4 or the IPv6 HoA.
The above format shows the packet as seen by the home agent. The above format shows the packet as seen by the home agent.
The SPD, whether a NAT were detected or not, is set as follows. Note The SPD, whether a NAT is detected or not, is set as follows. Note
that this rule is designed to match all data from the MN to nodes that this rule is designed to match all data from the MN to nodes
other than the home agent. This is done so that this rule does not other than the home agent. This is done so that this rule does not
overlap with the earlier rule securing BU/BA signaling between the MN overlap with the earlier rule securing BU/BA signaling between the MN
and the HA. and the HA.
Mobile Node SPD-S: Mobile Node SPD-S:
IF local_address = home_address & IF local_address = home_address &
remote_address != home_agent & remote_address != home_agent &
proto=any, then use SA ESP tunnel mode proto=any
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1 Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S: home agent SPD-S:
IF local_address != home_agent & IF local_address != home_agent &
remote_address = home_address & remote_address = home_address &
proto=any, then use SA ESP tunnel mode proto=any
Then use SA ESP tunnel mode
Where home_address is the MN's registered IPv6 or IPv4 home address Where home_address is the MN's registered IPv6 or IPv4 home address
and home_agent is the IPv6 or the IPv4 address of the home agent. and home_agent is the IPv6 or the IPv4 address of the home agent.
7. Protocol Constants 6. Protocol Constants
NATKATIMEOUT 110 seconds NATKATIMEOUT = 110 seconds.
8. Acknowledgements 7. 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, discussions, and
review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, reviews: Jari Arkko, Sri Gundavelli, Wassim Haddad, Alfred Hoenes,
Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and Conny Larsson, Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen
Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian Nielsen, and Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen,
Kaas-Petersen for raising the issue of IKEv2 interactions and and Christian Kaas-Petersen for raising the issue of IKEv2
proposing the solution included in this document. Thanks to Pasi interactions and proposing the solution included in this document.
Eronen for the many thorough reviews of this document. Thanks to Pasi Eronen for many thorough reviews of this document.
9. IANA Considerations 8. IANA Considerations
The specification requires the following allocations from IANA: IANA has made the following allocations according to this
specification:
A UDP port is needed for the NAT traversal mechanism described in A UDP port (4191) has been assigned for the NAT traversal
section 4.1. mechanism described in Section 4.2.
The IPv4 home address option described in section 3.1.1 requires The IPv4 home address option described in Section 3.1.1 has been
an option type. This option is included in the Mobility header assigned value 29. This option is included in the mobility header
described in [RFC3775]. described in [RFC3775].
The IPv4 address acknowledgement option described in section 3.2.1 The IPv4 address acknowledgement option described in Section 3.2.1
requires a new option type. This option is included in the has been assigned value 29. 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 has been
option type. This option is included in the Mobility header assigned a value 31. This option is included in the mobility
described in [RFC3775]. header 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 has
requires a new option type allocation [RFC3775]. been assigned value 32. This option is included in the mobility
header described in [RFC3775].
The Status field in the IPv4 home address option should be allocated The status field in the IPv4 home address option has been 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 status field values are allocated using the following procedure: The status field values are allocated using the following procedure:
1. New Status field values are allocated through IETF review. This 1. New status field values are allocated through IETF review. This
is for all RFC types including standards track, informational, is for all RFC types including standards track, informational, and
and experimental status that originate from the IETF and have experimental status that originate from the IETF and have been
been approved by the IESG for publication. approved by the IESG for 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 Independent
contributions" [RFC4844] are not considered to be IETF documents. "RFC Editor contributions" [RFC4844] are not considered to be IETF
documents.
10. References 9. References
10.1. Normative References 9.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.
[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
RFC 3168, September 2001. 3168, September 2001.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
RFC 3948, January 2005. 3948, January 2005.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support
RFC 3963, January 2005. Protocol", RFC 3963, January 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
RFC 4306, December 2005. Protocol", RFC 4306, December 2005.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. Network Attachment in IPv4 (DNAv4)", RFC 4436, March
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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation
IKEv2 and the Revised IPsec Architecture", RFC 4877, with IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007. April 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed.,
Bootstrapping in Split Scenario", RFC 5026, October 2007. "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026,
October 2007.
10.2. Informative 9.2. Informative References
[I-D.ietf-mip6-bootstrapping-integrated-dhc] [CHOWDHURY] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
RFC 2983, October 2000. 2983, October 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
August 2002. 3344, 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", RFC 3978,
March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
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.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The
Series and RFC Editor", RFC 4844, July 2007. 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.
[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.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
for Application Designers", BCP 145, RFC 5405, Guidelines for Application Designers", BCP 145, RFC 5405,
November 2008. November 2008.
Appendix A. Contributors 10. 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
Pascal Thubert: pthubert@cisco.com Pascal Thubert: pthubert@cisco.com
George Tsirtsis: G.Tsirtsis@Qualcomm.com George Tsirtsis: G.Tsirtsis@Qualcomm.com
Wakikawa Ryuji: ryuji@sfc.wide.ad.jp Ryuji Wakikawa: 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
 End of changes. 264 change blocks. 
592 lines changed or deleted 584 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/