draft-ietf-mext-nemo-v4traversal-00.txt   draft-ietf-mext-nemo-v4traversal-01.txt 
MIP6 Working Group Hesham Soliman (Ed.) MEXT Working Group Hesham Soliman (Ed.)
INTERNET-DRAFT Elevate Technologies INTERNET-DRAFT Elevate Technologies
January, 2008 Intended status: Standards Track
Expires: August 2008
February, 2008
Mobile IPv6 support for dual stack Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6) Hosts and Routers (DSMIPv6)
draft-ietf-mext-nemo-v4traversal-00.txt draft-ietf-mext-nemo-v4traversal-01.txt
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This document is a submission of the IETF MIP6 WG. Comments should be
directed to the IPv6 WG mailing list, mip6@ietf.org.
Abstract Abstract
The current Mobile IPv6 and NEMO specifications support IPv6 only. The current Mobile IPv6 and NEMO specifications support IPv6 only.
This specification extends those standards to allow the registration This specification extends those standards to allow the registration
of IPv4 addresses and prefixes, respectively, and the transport of of IPv4 addresses and prefixes, respectively, and the transport of
both IPv4 and IPv6 packets over the tunnel to the HA. This both IPv4 and IPv6 packets over the tunnel to the home agent. This
specification also allows the Mobile Node to roam over both IPv6 and specification also allows the Mobile Node to roam over both IPv6 and
IPv4, including the case where Network Address Translation is present IPv4, including the case where Network Address Translation is present
on the path between the mobile node and its home agent. on the path between the mobile node and its home agent.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.....................................................3
1.1 Motivation for using Mobile IPv6 only...........................3 1.1 Motivation for using Mobile IPv6 only...........................3
1.2 Scenarios considered by this specification...................4 1.2 Scenarios considered by this specification...................4
1.3 Terminology.................................................5
2. Solution overview................................................5 2. Solution overview................................................5
2.1. Home Agent Address Discovery...................................5 2.1. Home Agent Address Discovery...................................6
2.2. Mobile Prefix Solicitations and Advertisements..............6 2.2. Mobile Prefix Solicitations and Advertisements..............7
2.3. Binding management.............................................7 2.3. Binding management.............................................7
2.3.1 Foreign network supports IPv6.................................7 2.3.1 Foreign network supports IPv6.................................7
2.3.2 Foreign network supports IPv4 only............................8 2.3.2 Foreign network supports IPv4 only............................8
2.3.2.2 Visited network supports IPv4 only (private addresses)......9 2.3.2.2 Visited network supports IPv4 only (private addresses)......9
2.4. Route optimization............................................10 2.4. Route optimization............................................10
2.5. Dynamic IPv4 home address allocation..........................10 2.5. Dynamic IPv4 home address allocation..........................10
3. Extensions and modifications to Mobile IPv6.....................10 3. Extensions and modifications to Mobile IPv6.....................10
3.1. Binding update extensions.....................................10 3.1. Binding update extensions.....................................11
3.1.1 IPv4 home address option.....................................10 3.1.1 IPv4 home address option.....................................11
3.1.2 The IPv4 Care-of Address option........................11 3.1.2 The IPv4 Care-of Address option........................12
3.1.3 The Binding Update Message extensions..................12 3.1.3 The Binding Update Message extensions..................12
3.2. Binding Acknowledgement extensions............................12 3.2. Binding Acknowledgement extensions............................13
3.2.1 IPv4 address acknowledgement option..........................12 3.2.1 IPv4 address acknowledgement option..........................13
3.2.2 The NAT detection option...............................14 3.2.2 The NAT detection option...............................14
3.2.3 Extensions to the Binding Acknowledgement message......14 3.2.3 Extensions to the Binding Acknowledgement message......15
4. Protocol operation..............................................15 4. Protocol operation..............................................15
4.1. Tunnelling formats.........................................15 4.1. Tunnelling formats.........................................15
4.2. NAT detection and traversal................................16 4.2. NAT detection and traversal................................17
4.3. NAT Keepalives.............................................18 4.3. NAT Keepalives.............................................18
4.4. Mobile node operation.........................................19 4.4. Mobile node operation.........................................19
4.4.1 Sending packets from a visited network.................20 4.4.1 Sending packets from a visited network.................20
4.4.2 Movement detection in IPv4-only networks...............21 4.4.2 Movement detection in IPv4-only networks...............21
4.5. Home agent operations.........................................21 4.5. Home agent operations.........................................21
4.5.1 Sending packets to the mobile node.....................23 4.5.1 Sending packets to the mobile node.....................23
4.6. Correspondent node operations.................................23 4.6. Correspondent node operations.................................24
5. Security considerations.........................................23 5. Security considerations.........................................24
5.1 Handover interactions for IPsec and IKE.....................24 5.1 Handover interactions for IPsec and IKE.....................25
6. Protocol constants..............................................26 6. Protocol constants..............................................28
7. Acknowledgements................................................26 7. Acknowledgements................................................28
8. IANA considerations.............................................26 8. IANA considerations.............................................28
9. References......................................................26 9. References......................................................29
10. Contributors...................................................27 10. Contributors...................................................30
Author's Address...................................................28 Author's Address...................................................30
1. Introduction 1. Introduction
Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the
Internet while maintaining reachability and ongoing sessions, using Internet while maintaining reachability and ongoing sessions, using
an IPv6 home address or prefix. However, since IPv6 is not widely an IPv6 home address or prefix. However, since IPv6 is not widely
deployed, it is unlikely that mobile nodes will use IPv6 addresses deployed, it is unlikely that mobile nodes will use IPv6 addresses
only for their connections. It is reasonable to assume that mobile only for their connections. It is reasonable to assume that mobile
nodes will, for a long time, need an IPv4 home address that can be nodes will, for a long time, need an IPv4 home address that can be
used by upper layers. It is also reasonable to assume that mobile used by upper layers. It is also reasonable to assume that mobile
skipping to change at page 3, line 21 skipping to change at page 3, line 30
Using this specification, mobile nodes would only need Mobile IPv6 Using this specification, mobile nodes would only need Mobile IPv6
and [NEMO] to manage mobility while moving within the Internet; hence and [NEMO] to manage mobility while moving within the Internet; hence
eliminating the need to run two mobility management protocols eliminating the need to run two mobility management protocols
simultaneously. This specification provides the extensions needed in simultaneously. This specification provides the extensions needed in
order to allow IPv6 mobility only to be used by dual stack mobile order to allow IPv6 mobility only to be used by dual stack mobile
nodes. nodes.
This specification will also consider cases where a mobile node moves This specification will also consider cases where a mobile node moves
into a private IPv4 network and gets configured with a private IPv4 into a private IPv4 network and gets configured with a private IPv4
Care-of Address. In those scenarios, the mobile node needs to be able 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 Agent. to traverse the IPv4 NAT in order to communicate with the home agent.
IPv4 NAT traversal for Mobile IPv6 is presented in this IPv4 NAT traversal for Mobile IPv6 is presented in this
specification. specification.
In this specification, the term mobile node refers to both a mobile In this specification, the term mobile node refers to both a mobile
host and mobile router unless the discussion is specific to either host and mobile router unless the discussion is specific to either
hosts or routers. Similarly, we use the term home address to reflect hosts or routers. Similarly, we use the term home address to reflect
an address/prefix format. an address/prefix format.
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 [HMIPv6]. The requirements Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements
on the MAP are identical to those stated for the home agent, although on the MAP are identical to those stated for the home agent, although
it is unlikely that NAT traversal would be needed with a MAP as it is it is unlikely that NAT traversal would be needed with a MAP as it is
expected to be in the same address domain. expected to be in the same address domain.
1.1 Motivation for using Mobile IPv6 only 1.1 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, mainly due to capabilities inherited improvements over Mobile IPv4 [MIPv4], mainly due to capabilities
from IPv6. For instance, route optimization and Dynamic home agent inherited from IPv6. For instance, route optimization and dynamic
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.
skipping to change at page 4, line 23 skipping to change at page 4, line 31
In [SNRIO] several scenarios that illustrate potential In [SNRIO] several scenarios that illustrate potential
incompatibilities for mobile nodes using Mobile IPv6 were discussed. incompatibilities for mobile nodes using Mobile IPv6 were discussed.
Some of the problems associated with mobility and transition issues Some of the problems associated with mobility and transition issues
were presented in [MIP-PB]. This specification considers a subset of were presented in [MIP-PB]. This specification considers a subset of
the scenarios in [SNRIO], which address all the problems discussed in the scenarios in [SNRIO], which address all the problems discussed in
[MIP-PB]. The scenarios considered in this specification are listed [MIP-PB]. The scenarios considered in this specification are listed
below. 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 is
used between the mobile node and the Home Agent. We also assume that used between the mobile node and the home agent. We also assume that
the Home Agent is always reachable through a globally unique IPv4 the home agent is always reachable through a globally unique IPv4
address. Finally, it's important to note that the following scenarios address. Finally, it's important to note that the following scenarios
are not mutually exclusive. are not mutually exclusive.
Scenario 1: IPv4-only foreign network Scenario 1: IPv4-only foreign network
In this scenario, a mobile node is connected to an IPv4-only foreign In this scenario, a mobile node is connected to an IPv4-only foreign
network. The mobile node can only configure an IPv4 Care-of Address. network. The mobile node can only configure an IPv4 Care-of Address.
Scenario 2: Mobile node behind a NAT Scenario 2: Mobile node behind a NAT
In this scenario, the mobile node is in a private IPv4 foreign In this scenario, the mobile node is in a private IPv4 foreign
network that has a NAT device connecting it to the Internet. If the network that has a NAT device connecting it to the Internet. If the
Home Agent is located outside the NAT device, the mobile node will home agent is located outside the NAT device, the mobile node will
need a NAT traversal mechanism to communicate with the Home Agent. need a NAT traversal mechanism to communicate with the home agent.
Scenario 3: Home Agent behind a NAT Scenario 3: Home Agent behind a NAT
In this scenario, the communication between the mobile node and the In this scenario, the communication between the mobile node and the
Home Agent is further complicated by the fact that the Home Agent is home agent is further complicated by the fact that the home agent is
located within a private IPv4 network. However, in this scenario, we located within a private IPv4 network. However, in this scenario, we
assume that the Home Agent is allocated a globally unique IPv4 assume that the home agent is allocated a globally unique IPv4
address. Such 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 the agent interface. Instead, it is associated with the home agent on the
NAT device, which allows the Home Agent to be reachable through NAT device, which allows the home agent to be reachable through
address or port mapping. address or port mapping.
Scenario 4: Use Of IPv4-only applications Scenario 4: Use Of IPv4-only applications
In this scenario, the mobile node may be located in an IPv4, IPv6 or In this scenario, the mobile node may be located in an IPv4, IPv6 or
a dual network. However, the mobile node might be communicating with a dual network. However, the mobile node might be communicating with
an IPv4-only node. In this case, the mobile node would need a stable an IPv4-only node. In this case, the mobile node would need a stable
IPv4 address for its application. The alternative to using an IPv4 IPv4 address for its application. The alternative to using an IPv4
address is the use of protocol translators; however, end-to-end address is the use of protocol translators; however, end-to-end
communication with IPv4 is preferred to the use of protocol communication with IPv4 is preferred to the use of protocol
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 a stable IPv4 home address to The cases above illustrate the need for the allocation of a stable
be allocated to the mobile node. This is done using an IPv4 home IPv4 home address to the mobile node. This is done using an IPv4 home
address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is
problematic (as illustrated in [MIP-PB]), this scenario adds a problematic (as illustrated in [MIP-PB]), this scenario adds a
requirement on Mobile IPv6 to support IPv4 home addresses. requirement on Mobile IPv6 to support IPv4 home addresses.
1.3 Terminology
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 [KEYWORDS].
2. 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:
- Mobile nodes should be able to use an IPv4 and IPv6 home or care-of - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of
address simultaneously and update their home agents accordingly. address simultaneously and update their home agents accordingly.
- Mobile nodes need to be able to know the IPv4 address of the home - Mobile nodes need to be able to know the IPv4 address of the home
agent as well as its IPv6 address. There is no need for IPv4 prefix agent as well as its IPv6 address. There is no need for IPv4 prefix
discovery however. discovery however.
- Mobile nodes need to be able to detect the presence of a NAT device - Mobile nodes need to be able to detect the presence of a NAT device
and traverse such device in order to communicate with the Home Agent and traverse it in order to communicate with the home agent.
in a secure manner.
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 Mobile IPv6 only for IP mobility
management. management.
2.1. Home Agent Address Discovery 2.1. Home Agent Address Discovery
Dynamic Home Agent Address Discovery (DHAAD) was defined in [MIPv6] Dynamic home agent Address Discovery (DHAAD) was defined in [MIPv6]
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 mobile However, this mechanism is based on IPv6-anycast routing. If a mobile
node is located in an IPv4-only foreign network, it cannot rely on node is located in an IPv4-only foreign network, it cannot rely on
native IPv6 routing. In this scenario, the solution for discovering native IPv6 routing. In this scenario, the solution for discovering
the home agent's IPv4 address is through the Domain Name System the home agent's IPv4 address is through the Domain Name System
(DNS). If the MN is attached to an IPv6-only or dual stack network, (DNS). If the MN is attached to an IPv6-only or dual stack network,
it may also use procedures defined in [INTBOOT] to discover Home it may also use procedures defined in [INTBOOT] to discover home
Agent information. Note that the use of [INTBOOT] cannot give the agent information. Note that the use of [INTBOOT] cannot give the
mobile node information that allows it to continue to communicate mobile node information that allows it to continue to communicate
with the Home Agent if, for example, the mobile node moved from an with the home agent if, for example, the mobile node moved from an
IPv6-enabled network to an IPv4-only network. In such scenario, the IPv6-enabled network to an IPv4-only network. In this scenario, the
mobile node would need to discover the IPv4 address of its home agent mobile node would need to discover the IPv4 address of its home agent
through the DNS. through the DNS.
For DNS lookup by name, the mobile node should be configured with the For DNS lookup by name, the mobile node should be configured with the
name of the home agent. When the mobile node needs to discover a name of the home agent. When the mobile node needs to discover a
home agent, it sends a DNS request with QNAME set to the configured home agent, it sends a DNS request with QNAME set to the configured
name. An example is "ha1.example.com". If a home agent has an IPv4 name. An example is "ha1.example.com". If a home agent has an IPv4
and IPv6 address, the corresponding DNS record should be configured and IPv6 address, the corresponding DNS record should be configured
with both 'AAAA' and 'A' records. Accordingly the DNS reply will with both 'AAAA' and 'A' records. Accordingly, the DNS reply will
contain 'AAAA' and 'A' records. contain 'AAAA' and 'A' records.
For DNS lookup by service, the SRV record defined in [BOOT] is For DNS lookup by service, the SRV record defined in [BOOT] is
reused. For instance, if the service name is "mip6ha" and the reused. For instance, if the service name is "mip6" and the protocol
protocol name is "ipv6" for the SRV record, the mobile node SHOULD name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS
send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". request with the QNAME set to "_mip6ha._ipv6.example.com". The
The response should contain the home agent's FQDN(s) and may have the response should contain the home agent's FQDN(s) and may include the
corresponding 'AAAA' and 'A' records enclosed 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 addresses, then the operation above applies. In case a public IPv4 address, then the operation above applies. In case the
the home agents are behind a NAT box, there are two options, 1) home agents are behind a NAT box, there are two options, 1) configure
configure a public IPv4 address for each home agent on the NAT box, a public IPv4 address for each home agent on the NAT box, 2)
2) configure one public address and make the home agents share the configure one public address and make the home agents share the
public address. In either case, the correct DNS entries can be public address. In either case, the correct DNS entries can be
configured. Another possible solution is to designate one home agent configured. Another possible solution is to designate one home agent
on the home link for v4 traversal. The NAT device should associate on the home link for IPv4 traversal. The NAT device should associate
that home agent with the public IPv4 address configured on it for v4 that home agent with the public IPv4 address configured on it for v4
traversal. In all cases above, both the 'AAAA' and 'A' records traversal. In all cases above, both the 'AAAA' and 'A' records
returned for a particular name MUST correspond to the same physical returned for a particular name MUST correspond to the same physical
home agent; otherwise the mobile node will not be able to bind its home agent; otherwise the mobile node will not be able to bind its
addresses correctly. addresses correctly.
2.2. Mobile Prefix Solicitations and Advertisements 2.2. Mobile Prefix Solicitations and Advertisements
According to [MIPv6], the mobile node can send a Mobile Prefix According to [MIPv6], 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 such messages would require the mobile node to have security Securing these messages requires the mobile node to have a security
association with the home agent, using IPsec (AH or ESP) and based on association with the home agent, using IPsec (AH or ESP) and based on
the mobile node's IPv4 care-of address as described in [MIPv6]. Since the mobile node's IPv4 care-of address as described in [MIPv6]. Since
the mobile node needs to encapsulate all IPv6 traffic sent to the the mobile node needs to encapsulate all IPv6 traffic sent to the
home agent into IPv4 while located in an IPv4-only visited network, home agent into IPv4 while located in an IPv4-only visited network,
such SA would affect all packets if the selectors were based on the this SA would match all packets if the selectors were based on the
information in the outer header. That is, the SA selectors being the information in the outer header. That is, the SA selectors being the
protocol number (protocol is always IP in IP), as well as, source and protocol number (protocol is always IP in IP), as well as, source and
destination addresses are all common to all packets. If this effect destination addresses are all common to all packets. If this effect
is not desired, the mobile node can base the SA on the information in is not desired, the mobile node can base the SA on the information in
the inner header (i.e. using the home agent's IPv6 address, the the inner header (i.e., using the home agent's IPv6 address, the
mobile node's home address and the ICMP protocol number). Such mobile node's home address and the ICMP protocol number). This
security association would use transport mode ESP protection. security association would use transport mode ESP protection.
2.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:
A. The visited network has IPv6 connectivity and provides the mobile A. 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).
B. The mobile node can only configure a globally unique IPv4 address B. The mobile node can only configure a globally unique IPv4 address
in the visited network. in the visited network.
skipping to change at page 7, line 40 skipping to change at page 8, line 5
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 [MIPv6]. The binding update address of its home agent, as defined in [MIPv6]. The binding update
MAY include the IPv4 home address option introduced in this document. MAY include the IPv4 home address option introduced in this document.
After receiving the binding update, the home agent creates two After receiving the binding update, the home agent creates two
binding cache entries, one for the mobile node's IPv4 home address, binding cache entries, one for the mobile node's IPv4 home address,
and another for the mobile node's IPv6 home address. Both entries and another for the mobile node's IPv6 home address. Both entries
will point to the mobile node's IPv6 care-of address. Hence, whenever 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 a packet is addressed to the mobile node's IPv4 or IPv6 home
addresses, it will be tunneled in IPv6 to the mobile node's IPv6 addresses, the home agent will tunnel it in IPv6 to the mobile node's
care-of address included in the binding update. Effectively, the IPv6 care-of address included in the binding update. Effectively, the
mobile node establishes two different tunnels, one for its IPv4 mobile node establishes two different tunnels, one for its IPv4
traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6)
with a single binding update. The security implications of this with a single binding update. The security implications of this
mechanism are discussed in the security considerations section. mechanism are discussed in the security considerations section.
In this scenario, the only addition to [MIPv6] is the inclusion of In this scenario, the only addition to [MIPv6] is the inclusion of
the IPv4 home address option in the binding update message. the IPv4 home address option in the binding update message.
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
skipping to change at page 8, line 13 skipping to change at page 8, line 29
the binding acknowledgement MUST include the IPv4 address the binding acknowledgement MUST include the IPv4 address
acknowledgment option as described later in this specification. This acknowledgment option as described later in this specification. This
option informs the mobile node whether the binding was accepted for option informs the mobile node whether the binding was accepted for
the IPv4 home address. If this option is not included in the binding the IPv4 home address. If this option is not included in the binding
acknowledgement and the IPv4 home address option was included in the acknowledgement and the IPv4 home address option was included in the
binding update, the mobile node MUST assume that the home agent does binding update, the mobile node MUST assume that the home agent does
not support the IPv4 home address option and therefore SHOULD NOT not support the IPv4 home address option and therefore SHOULD NOT
include the option in future binding updates to that home agent include the option in future binding updates to that home agent
address. address.
The routing header in the binding update MUST include the mobile
node's IPv6 home address as specified in [MIPv6].
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
foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 foreign network, it SHOULD prioritize IPv6 care-of address for MIP6
binding registration. The mobile node MUST NOT register both IPv4 and binding registration. The mobile node MUST NOT register both IPv4 and
IPv6 care-of addresses to its home agent. IPv6 care-of addresses to its home agent.
2.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
skipping to change at page 9, line 15 skipping to change at page 9, line 28
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 [MIPv6]. In addition, if the binding update included an specified in [MIPv6]. In addition, if the binding update included an
IPv4 home address option, the binding acknowledgement MUST include 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 to the specification. The binding acknowledgement is encapsulated to the
IPv4 care-of address. IPv4 care-of address, which was included in the source address field
of the IPv4 header encapsulating the binding update.
2.3.2.2 Visited network supports IPv4 only (private addresses) 2.3.2.2 Visited 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 UDP and order to traverse the NAT device, IPv6 packets are tunneled UDP and
IPv4. The UDP port allocated for the home agent is TBD. IPv4. The UDP port allocated for the home agent is TBA.
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 were 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 binding update message. node's IPv4 care-of address included in the source address of the
In addition, the tunnel used MUST indicate UDP encapsulation for NAT IPv4 header that encapsulated the binding update message. In
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 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. of address in 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 [MIPv6]. In addition, if the binding update included an specified in [MIPv6]. In addition, if the binding update included an
IPv4 home address option, the binding acknowledgement MUST include IPv4 home address option, the binding acknowledgement MUST include
skipping to change at page 10, line 51 skipping to change at page 11, line 16
3.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 |Pref |P| Reserved | | Type | Length |Prefix-len |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 6 Length 6
Pref The length of the prefix allocated to the mobile Prefix-len The length of the prefix allocated to the mobile
node. If only a single address is allocated, node. If only a single address is allocated,
this field MUST be set to 32. In the first this field MUST be set to 32. In the first
binding update requesting a prefix, the field binding update requesting a prefix, the field
contains the prefix length requested. However, contains the prefix length requested. However,
in the following binding updates, this field in the following binding updates, this field
must contain the length of the prefix allocated. must contain the length of the prefix allocated.
A value of zero is invalid and MUST be A value of zero is invalid and MUST be
considered an error. considered an error.
P A flag indicating, when set, that the mobile P A flag indicating, when set, that the mobile
skipping to change at page 13, line 6 skipping to change at page 13, line 16
3.2. Binding Acknowledgement extensions 3.2. Binding Acknowledgement extensions
3.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 can include an IPv4 home address in the Additionally, this option can include an IPv4 home address in the
case of Dynamic IPv4 home address configuration (i.e. if the case of Dynamic IPv4 home address configuration (i.e., if the
unspecified IPv4 address was included in the binding update). The unspecified IPv4 address was included in the binding update). The
alignment requirement for this option is 4n. 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 | Status | Pref | Res | | Type | Length | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD Type TBD
Length 6 Length 6
Status Indicates success or failure for the IPv4 home Status Indicates success or failure for the IPv4 home
address binding. Values from 0 to 127 indicate address binding. Values from 0 to 127 indicate
skipping to change at page 13, line 35 skipping to change at page 13, line 45
following values are reserved: following values are reserved:
0 Success 0 Success
128 Failure, reason unspecified 128 Failure, reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Incorrect IPv4 home address 130 Incorrect IPv4 home address
131 Invalid IPv4 address 131 Invalid IPv4 address
132 Dynamic IPv4 home address 132 Dynamic IPv4 home address
assignment not available assignment not available
133 Prefix allocation unauthorized 133 Prefix allocation unauthorized
Pref The prefix length of the address allocated. This Pref-len The prefix length of the address allocated. This
field is only valid in case of success and MUST field is only valid in case of success and MUST
be set to zero and ignored in case of failure. be set to zero and ignored in case of failure.
This field overrides what the mobile node This field overrides what the mobile node
requested (if not equal to the requested requested (if not equal to the requested
length). length).
Res This field is reserved for future use. It MUST Res This field is reserved for future use. It MUST
be set to zero by the sender and ignored by the be set to zero by the sender and ignored by the
receiver. receiver.
skipping to change at page 14, line 40 skipping to change at page 14, line 50
encapsulation even if a NAT is not located encapsulation even if a NAT is not located
between the mobile node and home agent. between the mobile node and home agent.
Reserved This field is reserved for future use. It MUST Reserved This field is reserved for future use. It MUST
be set to zero by the sender and ignored by the be set to zero by the sender and ignored by the
receiver. receiver.
Refresh time A suggested time (in seconds) for the mobile Refresh time A suggested time (in seconds) for the mobile
node to refresh the NAT binding. If set to zero, node to refresh the NAT binding. If set to zero,
it is ignored. If this field is set to the all it is ignored. If this field is set to the all
1s it means that keepalives are not needed, i.e. 1s it means that keepalives are not needed,
i.e.,
no NAT was detected. no NAT was detected.
3.2.3 Extensions to the Binding Acknowledgement message 3.2.3 Extensions to the Binding Acknowledgement message
This specification extends the binding acknowledgement message with a This specification extends the binding acknowledgement message with a
new flag. The new flag is shown and described below. new flag. The new flag is shown and described below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|T| Reserved| | Status |K|R|T| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 20 skipping to change at page 15, line 33
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.
4.1. Tunnelling formats 4.1. Tunnelling formats
This speacification allows two different types of UDP-based This speacification allows two different types of UDP-based
tunnelling formats to be used between the mobile node and its home tunnelling formats to be used between the mobile node and its home
agent or MAP. The two formats are vanilla UDP encapsulation and TLV- agent or MAP. The two formats are vanilla UDP encapsulation and TLV-
header UDP encapsulation. A vanilla UDP encapsulation format means header UDP encapsulation. A vanilla UDP encapsulation format means
the following order of headers: the following order of headers:
IP (v4 or v6) IPv4
UDP UDP
IP (v4 or v6) IP (v4 or v6)
Other headers Other headers
When using this format the receiver would parse the version field When using this format the receiver would parse the version field
following the UDP header in order to determine whether the following following the UDP header in order to determine whether the following
header is IPv4 or IPv6. The rest of the headers are processed header is IPv4 or IPv6. The rest of the headers are processed
normally. The above order of headers does not take IPsec headers into normally. The above order of headers does not take IPsec headers into
account as they may be placed in different parts of the packet. The account as they may be placed in different parts of the packet. The
above format MUST be supported by all implementations of this above format MUST be supported by all implementations of this
skipping to change at page 16, line 6 skipping to change at page 16, line 18
during the binding exchange. If a mobile node prefers to use the TLV- during the binding exchange. If a mobile node prefers to use the TLV-
header UDP encapsulation, it sets the T flag in the binding update header UDP encapsulation, it sets the T flag in the binding update
sent to the home agent or MAP. If the receiver of the binding update sent to the home agent or MAP. If the receiver of the binding update
supports the TLV-header format, it SHOULD set the T flag in the supports the TLV-header format, it SHOULD set the T flag in the
binding acknowledgement message. Otherwise, the T flag is cleared. binding acknowledgement message. Otherwise, the T flag is cleared.
The setting of the T flag in the binding acknowledgement indicates to The setting of the T flag in the binding acknowledgement indicates to
the mobile node that it must use the TLV-header UDP encapsulation the mobile node that it must use the TLV-header UDP encapsulation
format for all packets sent for the duration of the binding or until format for all packets sent for the duration of the binding or until
a new binding update is sent. Each binding update may renegotiate the a new binding update is sent. Each binding update may renegotiate the
tunnelling format. To avoid interoperability issues, the sender of tunnelling format. To avoid interoperability issues, the sender of
the binding acknowledgement MUST not set the T flag unless it was set the binding acknowledgement MUST NOT set the T flag unless it was set
in the binding update sent from the mobile node. in the binding update sent from the mobile node.
The TLV-header format is shown below. The TLV-header format is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 37 skipping to change at page 16, line 49
The following values are assigned to the Type field, other values may The following values are assigned to the Type field, other values may
be assigned in future: be assigned in future:
1 IPv4 1 IPv4
2 IPv6 2 IPv6
3 IPsec 3 IPsec
4 GRE 4 GRE
In addition to the UDP-based tunnelling formats described above, this In addition to the UDP-based tunnelling formats described above, this
specification allows for standard IP in IP tunnelling. This can take specification allows for standard IP in IP tunnelling. This can take
place by tunnelling IPv4 in IPv6 or IP v6 in IPv4. However, whenever place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. However, whenever a
a NAT a detected, the mobile node will default to UDP-based NAT a detected, the mobile node will default to UDP-based
encapsulation. The mobile node can request to always use UDP encapsulation. The mobile node can request to always use UDP
encapsulation by setting the F flag in the binding update. If the encapsulation by setting the F flag in the binding update. If the
home agent does not agree to such request, it MUST reject the binding home agent does not agree to the request, it MUST reject the binding
update with the new Status code: update with the new Status code:
144 Cannot force UDP encapsulation 144 Cannot force UDP encapsulation
Alternatively, the home agent can force UDP encapsulation by setting Alternatively, the home agent can force UDP encapsulation by setting
the F flag in the NAT detection option included in the binding the F flag in the NAT detection option included in the binding
acknowledgement. acknowledgement.
4.2. NAT detection and traversal 4.2. NAT detection and traversal
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
skipping to change at page 17, line 10 skipping to change at page 17, line 23
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 IPv4 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 of care-of address in the source address field and the IPv4 address of
the home agent in the destination address field. 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 in the source address of the IPv6 header with the IPv4 address included in the IPv4 care-of address
header. If the two addresses match, no NAT device was in the path. option. If the two addresses match, no NAT device was in the path.
Otherwise, a NAT device was in the path and the NAT detection option Otherwise, a NAT device was in the path and the NAT detection option
is included in the binding acknowledgement. The binding is included in the binding acknowledgement. The binding
acknowledgement, and all future packets, are then encapsulated in UDP acknowledgement, and all future packets, are then encapsulated in UDP
and IPv4. The source address in the IPv4 header is the IPv4 address and IPv4. The source address in the IPv4 header is the IPv4 address
of the home agent. The destination address is the IPv4 address of the home agent. The destination address is the IPv4 address
received in the IPv4 header encapsulating the binding update (this received in the IPv4 header encapsulating the binding update (this
address will be different from the IPv4 care-of address when a NAT is address will be different from the IPv4 care-of address when a NAT is
in the path). The source port in the packet is the home agent's in the path). The source port in the packet is the home agent's
source port. The destination port is the source port received in the source port. The destination port is the source port received in the
binding update message. Note that the home agent stores the port binding update message. Note that the home agent stores the port
skipping to change at page 18, line 20 skipping to change at page 18, line 33
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.
B. Binding acknowledgement sent by the home agent: B. 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)
V6HOA (IPv6 home address) 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 IPv6 home address of the mobile node. The IPv4 ACK is
the IPv4 address acknowledgement option, which is only included if the IPv4 address acknowledgement option, which is only included if
the IPv4 home address option were present in the BU. The NAT DET is the IPv4 home address option were present in the BU. The NAT DET is
the NAT detection option, which MUST be present in the binding the NAT detection option, which MUST be present in the binding
acknowledgement message if the binding update was encapsulated in acknowledgement message if the binding update was encapsulated in
UDP. UDP.
skipping to change at page 18, line 54 skipping to change at page 19, line 15
the mobile node SHOULD use the value suggested by the home agent. 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 the all 1s, the mobile node need not send acknowledgement is set to the all 1s, the mobile node need not send
messages to refresh the NAT binding. However, the mobile node may messages to refresh the NAT binding. However, the mobile node may
still be required to encapsulate traffic in UDP. This scenario may still be required to encapsulate traffic in UDP. This scenario may
take place when a NAT is not detected, but the home agent still take place when a NAT is not detected, but the home agent still
requires the mobile node to use UDP encapsulation. requires the mobile node to use UDP encapsulation.
It should be noted that a mobile node that does not need to be It should be noted that a mobile node that does not need to be
reachable (i.e. only cares about the session continuity aspect of reachable (i.e., only cares about the session continuity aspect of
Mobile IP) does not need to refresh NAT binding. In this case, the Mobile IP) does not need to refresh NAT binding. In this case, the
mobile node would only be able to initiate communication with other mobile node would only be able to initiate communication with other
nodes. nodes. However, this is likely to imply that the mobile node will
need to send a binding update before initiating communication after a
long idle period as it is likely to be assigned a different port and
IPv4 address when it initiates communication. Hence, an
implementation may choose, for the sake of simplicity, to always
maintain the NAT bindings even when it does not need reachability.
4.4. Mobile node operation 4.4. Mobile node operation
In addition to the operations specified in [MIPv6] and [NEMO], this In addition to the operations specified in [MIPv6] and [NEMO], this
specification requires mobile nodes to be able to support an IPv4 specification requires mobile nodes to be able to support an IPv4
home address. home address.
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:
skipping to change at page 19, line 31 skipping to change at page 19, line 48
care-of address care-of address
- The destination address in the IPv4 header is the home agent's - The destination address in the IPv4 header is the home agent's
IPv4 address. IPv4 address.
- The source address in the IPv6 header is the mobile node's IPv6 - The source address in the IPv6 header is the mobile node's IPv6
home address. home address.
- The IPv4 home address option MAY be included in the mobility - The IPv4 home address option MAY be included in the mobility
header. This option contains the IPv4 home address. If the mobile header. This option contains the IPv4 home address. If the mobile
node did not have a static home address it MAY include the 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. with options may be included with requests for IPv4 prefixes (i.e., with
the P flag set.). the P flag set.).
- If the mobile node wishes to use UDP encapsulation only, it should - If the mobile node wishes to use UDP encapsulation only, it should
set the F flag in the binding update message. set the F flag in the binding update message.
- If the mobile node prefers to use the TLV-header format, it should - If the mobile node prefers to use the TLV-header format, it should
set the T flag in the binding update. set the T flag in the binding update.
- The IPv6 packet MUST be authenticated as per [MIPv6], based on the - The IPv6 packet MUST be authenticated as per [MIPv6], based on the
mobile node's IPv6 home address. 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 [MIPv6]. In IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In
addition, if the mobile node has an IPv4 home address or needs one, addition, if the mobile node has an IPv4 home address or needs one,
it MUST include the IPv4 home address option in the mobility header. it MUST include the IPv4 home address option in the mobility header.
If the mobile node already has a static IPv4 home address, such If the mobile node already has a static IPv4 home address, this
address MUST be included in the IPv4 home address option. Otherwise, address MUST be included in the IPv4 home address option. Otherwise,
if the mobile node needs a dynamic IPv4 address, it MUST include the if the mobile node needs a dynamic IPv4 address, it MUST include the
IPv4 unspecified address in the IPv4 home address option. IPv4 0.0.0.0 address in the IPv4 home address option.
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 [MIPv6] and [NEMO]. In addition, the agent, it follows the rules in [MIPv6] and [NEMO]. In addition, the
following actions MUST be made: following actions MUST be made:
- If the status field indicated failure with error code 144, the - 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.
- If the mobility header includes an IPv4 address acknowledgement - If the mobility header includes an IPv4 address acknowledgement
option indicating success, the mobile node should create two option indicating success, the mobile node should create two
skipping to change at page 20, line 23 skipping to change at page 20, line 40
IPv4 home address option was present in the binding update, the IPv4 home address option was present in the binding update, the
mobile node MUST only create one binding update list entry for its mobile node MUST only create one binding update list entry for its
IPv6 home address. The mobile node MAY include the IPv4 home IPv6 home address. The mobile node MAY include the IPv4 home
address option in future binding updates. address option in future binding updates.
- If an IPv4 address acknowledgement option were present and it - If an IPv4 address acknowledgement option were present and it
indicates failure for the IPv4 home address binding, the mobile indicates failure for the IPv4 home address binding, the mobile
node MUST NOT create an entry for that address in its binding node MUST NOT create an entry for that address in its binding
update list. The mobile node MAY include the IPv4 home address update list. The mobile node MAY include the IPv4 home address
option in future binding updates. option in future binding updates.
- If the T flag was set in the binding update and the binding - If the T flag was set in the binding update and the binding
acknowledgement included a T flag set, the mobile node MUST use the acknowledgement included the T flag set, the mobile node MUST use
TLV-header UDP encapsulation format. the TLV-header UDP encapsulation format.
4.4.1 Sending packets from a visited network. 4.4.1 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 [MIPv6]. IPv4 traffic is and receives IPv6 packets as described in [MIPv6]. IPv4 traffic is
encapsulated in IPv6 packets to the home agent. encapsulated in IPv6 packets to the home agent.
When the mobile node is located in an IPv4 only network, it will send When the mobile node is located in an IPv4 only network, it will send
IPv6 packets to its home agent according to the following format: IPv6 packets to its home agent according to the following format:
IPv4 header (src=V4CoA, dst=HA_V4ADDR) IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP header] [UDP header]
[TLV-header]
IPv6 header (src=V6HoA, dst=CN) IPv6 header (src=V6HoA, dst=CN)
Upper layer protocols Upper layer protocols
Where the UDP header is only used if a NAT were detected between the Where the UDP header is only used if a NAT were detected between the
mobile node and the home agent, or if the home agent forced UDP mobile node and the home agent, or if the home agent forced UDP
encapsulation. V4CoA is the IPv4 care-of address configured by the encapsulation. V4CoA is the IPv4 care-of address configured by the
mobile node in the visited network. mobile node in the visited network.
Similarly, IPv4 packets are sent according to the following format: Similarly, IPv4 packets are sent according to the following format:
IPv4 header (src=V4CoA, dst=HA_V4ADDR) IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP header] [UDP header]
[TLV-header]
IPv4 header (src=V4HoA, dst=V4CN) IPv4 header (src=V4HoA, dst=V4CN)
Upper layer protocols Upper layer protocols
Where the UDP header is only used if a NAT were detected between the Where the UDP header is only used if a NAT were detected between the
mobile node and the home agent, or if the home agent forced UDP mobile node and the home agent, or if the home agent forced UDP
encapsulation. encapsulation.
If the mobile node requested, and the home agent agreed, to use the If the mobile node and the home agent negotiated the use of the TLV-
TLV-header UDP encapsulation format, then the TLV-header would be header UDP encapsulation format, then the TLV-header would be used
used after the UDP header. after the UDP header.
4.4.2 Movement detection in IPv4-only networks 4.4.2 Movement detection in IPv4-only networks
[MIPv6] describes movement detection mostly based on IPv6-specific [MIPv6] describes movement detection mostly based on IPv6-specific
triggers. Such triggers would not be available in an IPv4-only triggers. These triggers would not be available in an IPv4-only
network. Hence, a mobile node located in an IPv4-only network SHOULD network. Hence, a mobile node located in an IPv4-only network SHOULD
use [DNAv4] for guidance on movement detection mechanisms in IPv4- use [DNAv4] for guidance on movement detection mechanisms in IPv4-
only networks. only networks.
4.5. Home agent operations 4.5. Home agent operations
In addition to the home agent specification in [MIPv6] and [NEMO], In addition to the home agent specification in [MIPv6] and [NEMO],
the home agent needs to be able to process the IPv4 home address the home agent needs to be able to process the IPv4 home address
option and generate the IPv4 address acknowledgement option. Both option and generate the IPv4 address acknowledgement option. Both
options are included in the mobility header. Furthermore, the home options are included in the mobility header. Furthermore, the home
skipping to change at page 23, line 7 skipping to change at page 23, line 26
the home agent MUST then encapsulate the packet in UDP and an IPv4 the home agent MUST then encapsulate the packet in UDP and an IPv4
header. The source address is set to the home agent's IPv4 address header. The source address is set to the home agent's IPv4 address
and the destination address is set to the address received in the and the destination address is set to the address received in the
source address of the IPv4 header encapsulating the binding update. source address of the IPv4 header encapsulating the binding 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 a 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. NAT were 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 were
detected, packets are encapsulated in an IPv4 header. detected, packets are encapsulated in an IPv4 header unless UDP
encapsulation is forced by the home agent.
4.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 [MIPv6] for sending The home agent follows the rules specified in [MIPv6] 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 When mobile nodes in an IPv6 network, the home agent IPv4 packets to When mobile nodes in an IPv6 network, the home agent
must encapsulate the IPv4 packets in IPv6. must 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 must follow the format negotiated in the
skipping to change at page 24, line 20 skipping to change at page 24, line 40
Therefore, it is sufficient for the home agent to know that the IPsec Therefore, it is sufficient for the home agent to know that the IPsec
verification for the packet containing the binding update was valid verification for the packet containing the binding update was valid
provided that it knows which IPv4 home address is associated with provided that it knows which IPv4 home address is associated with
which IPv6 home address. Hence, the security of the IPv4 home address which IPv6 home address. Hence, the security of the IPv4 home address
binding is the same as the IPv6 binding. 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 mobile node has an IPv6 home address and the right from the fact that mobile node has an IPv6 home address and the right
credentials for sending an authentic binding update for such address. credentials for sending an authentic binding update for the IPv6
address.
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 UNSAF vulnerabilities important to note that it has the same vulnerabilities associated
associated with RFC 3519. An attacker is able to hijack the mobile with RFC 3519 [TRAV]. An attacker is able to hijack the mobile node's
node's session with the home agent if it can modify the contents of session with the home agent if it can modify the contents of the
the outer IPv4 header. The contents of the header are not outer IPv4 header. The contents of the header are not authenticated
authenticated and there is no way for the home agent to verify their and there is no way for the home agent to verify their validity.
validity. Hence, a man in the middle attack where a change in the Hence, a man in the middle attack where a change in the contents of
contents of the IPv4 header can cause a legitimate mobile node's the IPv4 header can cause a legitimate mobile node's traffic to be
traffic to be diverted to an illegitimate receiver independently of diverted to an illegitimate receiver independently of the
the authenticity of the binding update message. authenticity of the binding update message.
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 IPv4- using ESP transport mode. When the mobile node is located in an IPv4-
only network, the binding update message is encapsulated in UDP as only network, the binding update message is encapsulated in UDP as
described earlier. However, UDP MUST NOT be used to encapsulate the described earlier. However, UDP MUST NOT be used to encapsulate the
binding update message when the mobile node is located in an IPv6- binding update message when the mobile node is located in an IPv6-
enabled network. If protection of payload traffic is needed when the enabled network. If protection of payload traffic is needed when the
mobile node is located in an IPv4-only network, encapsulation is done mobile node is located in an IPv4-only network, encapsulation is done
using tunnel mode ESP over port 4500 as described in [TUNSEC]. using tunnel mode ESP over port 4500 as described in [TUNSEC]. When
negotiating the security association with the home agent, while
located in an IPv4-only network, if the mobile node and home agent
support the use of port 4500, the mobile node MUST establish the
security association over port 4500, regardless of the presence of a
NAT. This is done to avoid the switching between ports 500 and 4500
and the potential traffic disruption resulting from this switch.
When located in an IPv4-only network, the mobile node MUST NOT
negotiate a security association that uses the following tunnel
formats: IPv4/IP(v4 or v6) and IPv4/ESP/IP(v4 or v6). These formats
will not work in the presence of a NAT. There is no restriction on
the tunnel format when the mobile node is located in an IPv6-enabled
network.
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 have impacts on the security association between the mobile node
and the home agent. The following section presents the expected and the home agent. The following section presents the expected
behaviour of the mobile node and home agent in those situations. behaviour of the mobile node and home agent in those situations.
5.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. In addition, the mobile node updates its local Security address. If the mobile node is in an IPv4-only network, it removes
Association information to include its IPv4 address and the home binding update list entries for correspondent nodes since route
agent's IPv4 address. The mobile node also removes binding update optimisation cannot be supported. This may cause inbound packet
list entries for correspondent nodes since route optimisation cannot losses as remote correspondent node are unaware of such movement. To
be supported while the mobile node is in an IPv4-only network. This avoid confusion in the correspondent node, the mobile node SHOULD
may cause inbound packet losses as remote correspondent node are deregister its binding with each correspondent node by sending a
unaware of such movement. Following this, the mobile node sends the deregistration binding update. The deregistration binding update
binding update message to the home agent. In order to be able to send message is tunnelled to the home agent and onto the correspondent
the binding update, the mobile node needs to use the new care-of node. This is done after the mobile node updates the home agent with
address, which is different from the care-of address used in the its new location as discussed below.
existing tunnel. This should be done without permanently updating the
tunnel with the home address to allow the mobile node to receive
packets on the old care-of address until the binding acknowledgement
is received. The method used to achieve this effect is implementation
dependent and is outside the scope of this specification.
Upon receiving the binding update message, the home agent updates its The mobile node sends the binding update message to the home agent.
security association to include the mobile node's address as the If the mobile node is in an IPv6-enabled network, the binding update
tunnel header IP source address and the new port number. When the is sent without IPv4/UDP encapsulation. If the mobile node is in an
mobile node is located in a private IPv4 network (which is detected IPv4-only network, then after IPsec processing of the BU message, it
as described above), the new address and port number are allocated by encapsulates the BU in UDP/IPv4 as discussed in sections 4.2 and 4.4.
the NAT. Based on the setting of the K flag in the binding update, In order to be able to send the binding update while in an IPv4-only
the home agent updates its IKE security association to include the network, the mobile node needs to use the new IPv4 care-of address in
tunnel header IP address as that received in the outer header of the the outer header, which is different from the care-of address used in
binding update message. The home agent may also need to change NAT the existing tunnel. This should be done without permanently updating
traversal fields in the IKE_SA. The home agent will also enable or the tunnel within the mobile node's implementation in order to allow
disable UDP encapsulation for outgoing ESP packets for the purpose the mobile node to receive packets on the old care-of address until
of NAT traversal. If the mobile node were located in a private IPv4 the binding acknowledgement is received. The method used to achieve
network the address and port number are likely to be wrong as the NAT this effect is implementation dependent and is outside the scope of
would likely allocate a different address and port number to the IKE this specification. This implies that the IP forwarding function
messages. Hence, the mobile node updates the IKE SA in one of two (which selects the interface or tunnel through which a packet is
ways. If the K flag was set, the mobile node SHOULD send an empty sent) is not based solely on the destination address: some IPv6
informational message, which results in the IKE module in the home packets destined to the home agent are sent via the existing tunnel,
agent to dynamically update the SA information. The IKE while BUs are sent using the new care-of address. Since BUs are
implementation in the home agent is REQUIRED to support this feature. protected by IPsec, the forwarding function cannot necessarily
Alternatively, the IKE SA should be re-negotiated. Note that updating determine the correct treatment from the packet headers. Thus, the
the IKE SA MUST take place after the mobile node has sent the binding DSMIPv6 implementation has to attach additional information to BUs,
update and received the acknowledgement from the home agent. and this information has to be preserved after IPsec processing and
made available to the forwarding function, or additional DSMIP
processing added to the forwarding function. Depending on the mobile
node's implementation, meeting this requirement may require changes
to the IPsec implementation.
Upon receiving the binding update message encapsulated in UDP/IPv4,
the home agent processes it as follows. In order to allow the 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 IPv4
source address with the IPv4 address in the IPv4 care-of address
option. This implies that the information in the outer header will be
preserved after IPsec processing and made available to the DSMIPv6
implementation in the home agent. Depending on the home agent's
implementation, meeting this requirement may require changes to the
IPsec implementation.
The home agent updates its tunnel mode security association to
include the mobile node's care-of address as the remote tunnel header
address, and 4500 as the port number. If the mobile node were located
in a private IPv4 network the address and port number are likely to
be wrong as the NAT would likely allocate a different address and
port number to traffic encapsulated in IPsec tunnels or to IKE
messages; the mobile node provides the correct information in a
separate exchange as described below. When the mobile node is located
in a private IPv4 network (which is detected as described above), the
new address and port number are allocated by the NAT. The home agent
will also enable or disable UDP encapsulation for outgoing ESP
packets for the purpose of NAT traversal.
If the Key Management Mobility Capability (K) bit was set in the
binding update, and the home agent supports this feature, the home
agent updates its IKE security associations to include the mobile
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
in the IKE_SA to enable the dyanmic update of the IP address and port
number based on the reception of authenticated IKE messages, or
authenticated packets using tunnel mode ESP. The dynamic updates are
described in section 2.23 of RFC 4306. As described above, when the
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
home agent at this point.
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
SHOULD send an empty informational message, which results in the IKE
module in the home agent to dynamically update the SA information.
The IKE implementation in the home agent is REQUIRED to support this
feature. Alternatively, the IKE SA should be re-negotiated. Note that
updating the IKE SA MUST take place after the mobile node has sent
the binding update and received the acknowledgement from the home
agent.
It is important to note that if the mobile node is located behind a
NAT, its IPv4 care-of address seen by the DSMIPv6 module in the home
agent upon receiving the binding update will differ from the IPv4
care-of address seen by the IKE module and the care-of address used
for forwarding IPsec tunnel mode traffic. This is due to the fact
that the NAT will probably allocate a different IP address and port
number to each traffic stream. Hence, it is probable that different
modules in the home agent will have a different care-of address that
should be used for encapsulating traffic to the mobile node.
After successfully processing the binding update, the home agent
sends the binding acknowledgement to the mobile node's care-of
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 to
the same address where the BU was received from. This may require
special treatment in IP forwarding and/or IPsec processing which
resembles 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 Security Association information to include the tunnel its local tunnel mode Security Association information to include the
header IP source address, which is the the home agent's address. The tunnel header IP source address, which is the the home agent's
mobile node may also need to enable or disable UDP encapsulation for address and the tunnel header IP destination, which is the mobile
outgoing ESP packets for the purpose of NAT traversal. node's care-of address. The mobile node may also need to enable or
disable UDP encapsulation for outgoing ESP packets for the purpose
of NAT traversal and the sending of keep alives.
The mobile node MAY use [MOBIKE] to update its IKE SA with the home The mobile node MAY use [MOBIKE] to update its IKE SA with the home
agent. Using MOBIKE requires negotiating this capability with the agent. Using MOBIKE requires negotiating this capability with the
home agent when establishing the SA. In this case, the mobile node home agent when establishing the SA. In this case, the mobile node
and the home agent need not update their IPsec SAs locally as this and the home agent MUST NOT update their IPsec SAs locally as this
step is performed by MOBIKE. Furthermore, the use of MOBIKE allows step is performed by MOBIKE. Furthermore, the use of MOBIKE allows
the mobile node to update the SA independently of the binding update the mobile node to update the SA independently of the binding update
exchange. Hence, there is no need for the mobile node to wait for a exchange. Hence, there is no need for the mobile node to wait for a
binding acknowledgement before performing MOBIKE. The use of MOBIKE binding acknowledgement before performing MOBIKE. The use of MOBIKE
is OPTIONAL in this specification. is OPTIONAL in this specification.
6. Protocol constants 6. Protocol constants
NATKATIMEOUT 110 seconds NATKATIMEOUT 110 seconds
7. 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, discussion, and
review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson,
Ahmad Muhanna, Vidya Narayanan, Karen Neilsen and Keiichi Shima. Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and
Thanks to Karen Neilsen, Pasi Eronen and Christian Kaas-Petersen for Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian
raising the issue of IKEv2 interactions and proposing the solution Kaas-Petersen for raising the issue of IKEv2 interactions and
included in this document. proposing the solution included in this document.
8. IANA considerations 8. IANA considerations
The specification requires the following allocations from IANA: The specification requires the following allocations from IANA:
- A UDP port is needed for the NAT traversal mechanism described in - A UDP port is needed for the NAT traversal mechanism described in
section 4.1. section 4.1.
- The IPv4 home address option described in section 3.1.1 requires an - The IPv4 home address option described in section 3.1.1 requires an
option type. This option is included in the Mobility header option type. This option is included in the Mobility header
described in [MIPv6]. described in [MIPv6].
- 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 Mobility requires a new option type. This option is included in the Mobility
header described in [MIPv6]. header described in [MIPv6].
- The NAT detection option described in section 3.2.2 requires a new - The NAT detection option described in section 3.2.2 requires a new
option type. This option is included in the Mobility header option type. This option is included in the Mobility header
described in [MIPv6]. described in [MIPv6].
- The IPv4 Care-of address option described in section 3.1.2 requires - The IPv4 Care-of address option described in section 3.1.2 requires
an option type. This option is included in the Mobility header an option type. This option is included in the Mobility header
described in [MIPv6]. described in [MIPv6].
This specification introduces a new TLV-header to be used with UDP
encapsulation. The Types of the TLV-header should be allocated by
IANA under a new registry: "DSMIPv6 TLV-header Types".
The Status field in the IPv4 home address option should be allocated
by IANA under the new registry: "DSMIPv6 IPv4 home address option
status codes".
The TLV-header types and status field values are allocated using the
following procedure:
1. The IANA should allocate and permanently register new TLV-header
types and Status field values from IETF RFC publication. This is for
all RFC types including standards track, informational, and
experimental status that originate from the IETF and have been
approved by the IESG for
publication.
2. Requests for new option type value assignments from outside the
IETF are only made through the publication of an IETF document, per
1) above. Note also that documents published as "RFC Editor
contributions" [RFC3667] are not considered to be IETF documents.
9. References 9. References
NORMATIVE NORMATIVE
[IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) [DNAv4] Aboba, B., Carlsson, J., and S. Cheshire, "Detecting Network
specification", RFC 2460 Attachment for IPv4 (DNAv4)", RFC 4436, March 2006.
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in [MIPv6] D. Johnson, Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support protocol", RFC 3963, "Network Mobility (NEMO) Basic Support protocol", RFC 3963,
January 2005. January 2005.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] 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.
[SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[TUNSEC] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. [TUNSEC] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M.
Stenberg, "UPD Encapsulation for IPsec ESP Packets", RFC Stenberg, "UDP Encapsulation for IPsec ESP Packets", RFC
3948, January 2005. 3948, January 2005.
INFORMATIVE INFORMATIVE
[BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile [BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile
IPv6 bootstrapping in split scenario", draft-ietf-mip6- IPv6 bootstrapping in split scenario", RFC 5026, October 2007.
bootstrapping-split, June 2005, work in progress.
[HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
Draftietf-mipshop-4140bis-04 November 2007. Draftietf-mipshop-4140bis-04 November 2007.
[INTBOOT] K. Chowdhury and A. Yegin, "MIP6-bootstrapping for the [INTBOOT] K. Chowdhury and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", draft-ietf-mip6-bootstrapping- Integrated Scenario", draft-ietf-mip6-bootstrapping-
integrated-dhc-02, Work in Progress. integrated-dhc-02, Work in Progress.
[MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for
skipping to change at page 27, line 38 skipping to change at page 30, line 5
[MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344
[MOBIKE] P. Eronen,"IKEv2 Mobility and Multihoming Protocol (MOBIKE)" [MOBIKE] P. Eronen,"IKEv2 Mobility and Multihoming Protocol (MOBIKE)"
, RFC 4555, June 2006. , RFC 4555, June 2006.
[SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6
in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops-
mip-scenarios-01.txt, February 2004. mip-scenarios-01.txt, February 2004.
[TRAV] H. Levkowetz and S. Vaarala, "Mobile IP Traversal for Network
Address Translation (NAT) Devices", RFC 3519, April 2003.
10. 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
E-mail: vijay.devarapalli@azairenet.com E-mail: vijay.devarapalli@azairenet.com
James Kempf James Kempf
E-mail: kempf@docomolabs-usa.com E-mail: kempf@docomolabs-usa.com
skipping to change at page 28, line 25 skipping to change at page 30, line 46
E-mail: Hesham@elevatemobile.com E-mail: Hesham@elevatemobile.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires July, 2008. This Internet-Draft expires August, 2008.
 End of changes. 86 change blocks. 
179 lines changed or deleted 296 lines changed or added

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