draft-ietf-mip6-nemo-v4traversal-04.txt   draft-ietf-mip6-nemo-v4traversal-05.txt 
MIP6 Working Group Hesham Soliman (Ed.) MIP6 Working Group Hesham Soliman (Ed.)
INTERNET-DRAFT Elevate Technologies INTERNET-DRAFT Elevate Technologies
Expires: September 2007 Expires: January 2008
March, 2007 July, 2007
Mobile IPv6 support for dual stack Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6) Hosts and Routers (DSMIPv6)
draft-ietf-mip6-nemo-v4traversal-04.txt draft-ietf-mip6-nemo-v4traversal-05.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 other
skipping to change at page 1, line 39 skipping to change at page 1, line 39
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-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 This document is a submission of the IETF MIP6 WG. Comments should be
directed to the IPv6 WG mailing list, mip6@ietf.org. directed to the IPv6 WG mailing list, mip6@ietf.org.
Abstract Abstract
The current Mobile IPv6 and NEMO specification support only IPv6. The current Mobile IPv6 and NEMO specifications support IPv6 only.
Hence, this specification extends those standards to allow the This specification extends those standards to allow the registration
registration of IPv4 addresses and prefixes, respectively, and the of IPv4 addresses and prefixes, respectively, and the transport of
transport of both IPv4 and IPv6 packets over the tunnel to the HA. both IPv4 and IPv6 packets over the tunnel to the HA. This
This specification allows also the Mobile Node to roam over both IPv6 specification also allows the Mobile Node to roam over both IPv6 and
and IPv4, including the case where Network Address Translation is IPv4, including the case where Network Address Translation is present
present on the path. on the path between the mobile node and its home agent.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.....................................................2
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
2. Solution overview................................................5 2. Solution overview................................................5
2.1. Home Agent Address Discovery...................................5 2.1. Home Agent Address Discovery...................................5
2.2. Mobile Prefix Solicitations and Advertisements..............6 2.2. Mobile Prefix Solicitations and Advertisements..............6
2.3. Binding management.............................................6 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............................7 2.3.2 Foreign network supports IPv4 only............................8
2.3.2.1 Visited network supports IPv4 only (private addresses)......8 2.3.2.2 Visited network supports IPv4 only (private addresses)......9
2.4. Route optimization.............................................9 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.....................................10
3.1.1 IPv4 home address option.....................................10 3.1.1 IPv4 home address option.....................................10
3.2. Binding acknowledgement extensions............................11 3.1.2 The IPv4 Care-of Address option........................11
3.2.1 IPv4 address acknowledgement option..........................11 3.1.3 The Binding Update Message extensions..................12
3.2.2 The NAT detection option...............................12 3.2. Binding Acknowledgement extensions............................12
4. Protocol operation..............................................13 3.2.1 IPv4 address acknowledgement option..........................12
4.1. NAT detection and traversal................................13 3.2.2 The NAT detection option...............................13
4.2. NAT Keepalives.............................................15 3.2.3 Extensions to the Binding Acknowledgement message......14
4.3. Mobile node operation.........................................15 4. Protocol operation..............................................14
4.3.1 Sending packets from a visited network.................17 4.1. Tunnelling formats.........................................15
4.3.2 Movement detection in IPv4-only networks...............17 4.2. NAT detection and traversal................................16
4.4. Home agent operations.........................................17 4.3. NAT Keepalives.............................................18
4.4.1 Sending packets to the mobile node.....................19 4.4. Mobile node operation.........................................18
4.5. Correspondent node operations.................................20 4.4.1 Sending packets from a visited network.................20
5. Security considerations.........................................20 4.4.2 Movement detection in IPv4-only networks...............20
6. Protocol constants..............................................20 4.5. Home agent operations.........................................21
7. Acknowledgements................................................20 4.5.1 Sending packets to the mobile node.....................22
8. IANA considerations.............................................20 4.6. Correspondent node operations.................................23
9. References......................................................21 5. Security considerations.........................................23
Authors' Addresses.................................................21 6. Protocol constants..............................................24
7. Acknowledgements................................................24
8. IANA considerations.............................................24
9. References......................................................24
10. Contributors...................................................25
Author's Address...................................................26
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 4, line 27 skipping to change at page 4, line 32
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. Such 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.
skipping to change at page 5, line 41 skipping to change at page 5, line 44
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. The preferred solution for discovering the home native IPv6 routing. In this scenario, the solution for discovering
agent's IPv4 address is through the Domain Name System (DNS). 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,
it may also use procedures defined in [INTBOOT] to discover Home
Agent information. Note that the use of [INTBOOT] cannot give the
mobile node information that allows it to continue to communicate
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
mobile node would need to discover the IPv4 address of its home agent
through the DNS.
For DNS lookup by name, the mobile node should be configured with the For DNS lookup by name, the mobile node should be configured with the
name of the home agent. When the mobile node needs to discover a name of the home agent. When the mobile node needs to discover a
home agent, it sends a DNS request with QNAME set to the configured home agent, it sends a DNS request with QNAME set to the configured
name. An example is "ha1.example.com". If a home agent has an IPv4 name. An example is "ha1.example.com". If a home agent has an IPv4
and IPv6 address, the corresponding DNS record should be configured and IPv6 address, the corresponding DNS record should be configured
with both 'AAAA' and 'A' records. Accordingly the DNS reply will with both 'AAAA' and 'A' records. Accordingly the DNS reply will
contain 'AAAA' and 'A' records. contain 'AAAA' and 'A' records.
For DNS lookup by service, the SRV record defined in [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 "mip6ha" and the
protocol name is "_ipv6" for the SRV record, the mobile node SHOULD protocol name is "ipv6" for the SRV record, the mobile node SHOULD
send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". send a DNS request with the QNAME set to "mip6ha.ipv6.example.com".
The response should contain the home agent's FQDN(s) and may have the The response should contain the home agent's FQDN(s) and may have the
corresponding 'AAAA' and 'A' records enclosed as well. corresponding 'AAAA' and 'A' records enclosed 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 addresses, then the operation above applies. In case
the home agents are behind a NAT box, there are two options, 1) the home agents are behind a NAT box, there are two options, 1)
configure a public IPv4 address for each home agent on the NAT box, configure a public IPv4 address for each home agent on the NAT box,
2) configure one public address and make the home agents share the 2) 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
skipping to change at page 8, line 17 skipping to change at page 8, line 30
acknowledgement messages as shown later in this document. If no NAT acknowledgement messages as shown later in this document. If no NAT
is detected between the mobile node and the home agent, the mobile is detected between the mobile node and the home agent, the mobile
node assumes that it is in a foreign network that supports IPv4 node assumes that it is in a foreign network that supports IPv4
public addresses. Otherwise, the mobile node assumes that private public addresses. Otherwise, the mobile node assumes that private
addresses are used in the foreign network. Note that this assumption addresses are used in the foreign network. Note that this assumption
is only valid for the purposes of the signaling presented in this is only valid for the purposes of the signaling presented in this
specification. A mobile node SHOULD NOT assume that its IPv4 address specification. A mobile node SHOULD NOT assume that its IPv4 address
is globally unique if a NAT device was not detected. The operations is globally unique if a NAT device was not detected. The operations
of both cases are discussed below. of both cases are discussed below.
2.3.2.2 Foreign network supports IPv4 only (public addresses) 2.3.2.1 Foreign network supports IPv4 only (public addresses)
In this scenario the mobile node will need to tunnel IPv6 packets In this scenario the mobile node will need to tunnel IPv6 packets
containing the binding update to the home agent's IPv4 address. The containing the binding update to the home agent's IPv4 address. The
mobile node uses the IPv4 address it gets from the foreign network as mobile node uses the IPv4 address it gets from the foreign network as
a source address in the outer header. The binding update will contain a source address in the outer header. The binding update will contain
the mobile node's IPv6 home address in the home address option. the mobile node's IPv6 home address. However, since the care-of
However, since the care-of address in this scenario is the mobile address in this scenario is the mobile node's IPv4 address, the
node's IPv4 address, the mobile node MUST include its IPv4 care-of mobile node MUST include its IPv4 care-of address in the IPv6 packet.
address in the IPv6 packet. The IPv4 address is represented in an The IPv4 address is represented in the IPv4 Care-of address option
IPv4-mapped IPv6 address and is included in the source address field defined in this specification. If the mobile node had an IPv4 home
of the IPv6 header. address, it MUST also include the IPv4 home address option described
in this specification.
If the mobile node had an IPv4 home address, it MUST also include the
IPv4 home address option described in this specification.
After accepting the binding update, the home agent MUST create a new After accepting the binding update, the home agent MUST create a new
binding cache entry for the mobile node's IPv6 home address. If an binding cache entry for the mobile node's IPv6 home address. If an
IPv4 home address option were included, the home agent MUST create IPv4 home address option 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. Hence, all packets addressed to the node's IPv4 care-of address. Hence, all packets addressed to the
mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in
an IPv4 header that includes the home agent's IPv4 address in the an IPv4 header that includes the home agent's IPv4 address in the
source address field and the mobile node's IPv4 care-of address in source address field and the mobile node's IPv4 care-of address in
the destination address field. the destination address field.
After accepting the binding updates and creating the corresponding After accepting the binding updates and creating the corresponding
entries, the home agent MUST send a binding acknowledgement as entries, the home agent MUST send a binding acknowledgement as
specified in [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 update is encapsulated to the IPv4 care-of specification. The binding update is encapsulated to the IPv4 care-of
address (represented as an IPv4-mapped IPv6 address in the binding address (represented as an IPv4-mapped IPv6 address in the binding
update). update).
2.3.2.1 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 used to send the IPv6 packet is TBD. IPv4. The UDP port allocated for the home agent is TBD.
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 in the home address will contain the mobile node's IPv6 home address.
option. The content of the IPv6 packet is identical to the public
address scenario described above.
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 source address of the node's IPv4 care-of address included in the source address of the
IPv6 packet and represented as an IPv4-mapped IPv6 address. In IPv6 packet and represented as an IPv4-mapped IPv6 address. In
addition, the tunnel used MUST indicate UDP encapsulation for NAT addition, the tunnel used MUST indicate UDP encapsulation for NAT
traversal. Hence, all packets addressed to the mobile node's home traversal. Hence, all packets addressed to the mobile node's home
address(es) (IPv4 or IPv6) will be encapsulated in UDP then address(es) (IPv4 or IPv6) will be encapsulated in UDP then
skipping to change at page 9, line 36 skipping to change at page 9, line 46
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
the IPv4 address acknowledgment option as described later in this the IPv4 address acknowledgment option as described later in this
specification. The binding acknowledgement is encapsulated in UDP specification. The binding acknowledgement is encapsulated in UDP
then IPv4 with the home agent's IPv4 address in the source address then IPv4 with the home agent's IPv4 address in the source address
field and the mobile node's IPv4 care-of address in the destination field and the mobile node's IPv4 care-of address in the destination
field. The inner IPv6 packet will contain the home agent's IPv6 field. The IPv4 address in the destination field of the IP v4 packet
address as a source address and the mobile node's IPv4 care-of is the source address received in the IPv4 header containing the
address in the destination address field. The latter is represented binding update message. The inner IPv6 packet will contain the home
as an IPv4-mapped IPv6 address. agent's IPv6 address as a source address and the mobile node's IPv6
home address in the destination address field.
The mobile node needs to maintain the NAT bindings for its current The mobile node needs to maintain the NAT bindings for its current
IPv4 care-of address. This is done through sending the binding update IPv4 care-of address. This is done through sending the binding update
regularly to the home agent. regularly to the home agent.
2.4. Route optimization 2.4. Route optimization
Route optimization, as specified in [MIPv6] will operate in an Route optimization, as specified in [MIPv6] will operate in an
identical manner for dual stack mobile nodes when they are located in identical manner for dual stack mobile nodes when they are located in
a visited network that provides IPv6 addresses to the mobile node. a visited network that provides IPv6 addresses to the mobile node.
skipping to change at page 11, line 29 skipping to change at page 11, line 37
home address from the home agent. A mobile node home address from the home agent. A mobile node
may choose to use this option to request a may choose to use this option to request a
prefix by setting the address to the All Zeroes prefix by setting the address to the All Zeroes
and setting the P flag. The mobile node could and setting the P flag. The mobile node could
then form an IPv4 home address based on the then form an IPv4 home address based on the
allocated prefix. Alternatively, the mobile node allocated prefix. Alternatively, the mobile node
may use two different options, one for may use two different options, one for
requesting an address (Static or Dynamic) and requesting an address (Static or Dynamic) and
another for requesting a prefix. another for requesting a prefix.
3.2. Binding acknowledgement extensions 3.1.2 The IPv4 Care-of Address option
This option is included in the Mobility Header including the binding
update message sent from the mobile node to a home agent or Mobility
Anchor Point. The alignment requirement for this option is 4n.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Length 6
Reserved This field is set to zero by the sender and
ignored by the receiver.
IPv4 care-of address This field contains the mobile node's IPv4 care-
of address. The IPv4 care-of address is used
when the mobile node is located in an IPv4-only
network.
3.1.3 The Binding Update Message extensions
This specification extends the Binding Update message with two new
flags. The flags are shown and described below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F When set, this flag indicates a request for
forcing UDP encapsulation regardless of whether
a NAT is present on the path between the mobile
node and the home agent.
T When set, this flag indicates that the mobile
node requests the use of the TLV-format for
encapsulating IPv6 in IPv4. The TLV-format is
described later in this document.
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
skipping to change at page 13, line 22 skipping to change at page 14, line 33
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
This specification extends the binding acknowledgement message with a
new flag. The new flag is shown and described below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|T| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T This flag indicates, when set, that the sender
of the binding acknowledgement supports the TLV-
tunnel format.
4. Protocol operation 4. Protocol operation
This section presents the protocol operation and processing for the This section presents the protocol operation and processing for the
messages presented above. In addition, this section introduces the messages presented above. In addition, this section introduces the
NAT detection and traversal mechanism used by this specification. NAT detection and traversal mechanism used by this specification.
4.1. NAT detection and traversal 4.1. Tunnelling formats
This speacification allows two different types of UDP-based
tunnelling formats to be used between the mobile node and its home
agent or MAP. The two formats are vanilla UDP encapsulation and TLV-
header UDP encapsulation. A vanilla UDP encapsulation format means
the following order of headers:
IP (v4 or v6)
UDP
IP (v4 or v6)
Other headers
When using this format the receiver would parse the version field
following the UDP header in order to determine whether the following
header is IPv4 or IPv6. The rest of the headers are processed
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
above format MUST be supported by all implementations of this
specification and MUST always be used to send the binding update
message.
A TLV-header UDP encapsulation is represented by the following order
of headers:
IP (v4 or v6)
UDP
TLV-header
Other headers
The receiver of the TLV-header UDP encapsulated packet expects the
TLV-header to follow UDP. The TLV header contains the type of the
following message and its length. Hence, the TLV header can carry
traffic other than IP.
The mobile node negotiates the format for tunnelling payload traffic
during the binding exchange. If a mobile node prefers to use the TLV-
header UDP encapsulation, it sets the T flag in the binding update
sent to the home agent or MAP. If the receiver of the binding update
supports the TLV-header format, it SHOULD set the T flag in the
binding acknowledgement message. Otherwise, the T flag is cleared.
The setting of the T flag in the binding acknowledgement indicates to
the mobile node that it must use the TLV-header UDP encapsulation
format for all packets sent for the duration of the binding or until
a new binding update is sent. Each binding update may renegotiate the
tunnelling format. To avoid interoperability issues, the sender of
the binding acknowledgement MUST not set the T flag unless it was set
in the binding update sent from the mobile node.
The TLV-header format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type This field indicates the type of the payload
following this header.
Length This field indicates the length of the payload
following the header, excluding the TLV-header
itself.
Reserved This field MUST be set to zero by the sender and
ignored by the receiver.
The following values are assigned to the Type field, other values may
be assigned in future:
1 IPv4
2 IPv6
3 IPsec
4 GRE
In addition to the UDP-based tunnelling formats described above, this
specification allows for standard IP in IP tunnelling. This can take
place by tunnelling IPv4 in IPv6 or IP v6 in IPv4. However, whenever
a NAT a detected, the mobile node will default to UDP-based
encapsulation. The mobile node can request to always use UDP
encapsulation by setting the F flag in the binding update. If the
home agent does not agree to such request, it MUST reject the binding
update with the new Status code:
144 Cannot force UDP encapsulation
Alternatively, the home agent can force UDP encapsulation by setting
the F flag in the NAT detection option included in the binding
acknowledgement.
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
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 IPv4 care-of address represented in IPv4-mapped is the mobile node's IPv6 home address. The destination address is
IPv6 format. The destination address is the IPv6 address of the home the IPv6 address of the home agent. The IPv4 header contains the IPv4
agent. The IPv4 header contains the IPv4 care-of address in the care-of address in the source address field and the IPv4 address of
source address field and the IPv4 address of the home agent in the the home agent in the destination address field.
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 in the source address of the IPv6
header. If the two addresses match, no NAT device was in the path. header. 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). 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
binding update message. Note that the home agent stores the port
numbers and associates them with the mobile node's tunnel in order to
forward future packets.
Upon receiving the binding acknowledgement with the NAT detection Upon receiving the binding acknowledgement with the NAT detection
option, the mobile node sets the tunnel to the home agent to UDP option, the mobile node sets the tunnel to the home agent to UDP
encapsulation. Hence, all future packets to the home agent are encapsulation. Hence, all future packets to the home agent are
tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source
address in the IPv6 header is the mobile node's IPv6 home address and address in the IPv6 header is the mobile node's IPv6 home address and
the destination address is the correspondent node's IPv6 address. All the destination address is the correspondent node's IPv6 address. All
tunneled IPv4 packets will contain the mobile node's IPv4 home tunneled IPv4 packets will contain the mobile node's IPv4 home
address in the source address field of the inner IPv4 packet and the address in the source address field of the inner IPv4 packet and the
correspondent node's IPv4 address in the destination address field. correspondent node's IPv4 address in the destination address field.
skipping to change at page 14, line 36 skipping to change at page 17, line 49
binding acknowledgements in a UDP header whenever the binding update binding acknowledgements in a UDP header whenever the binding update
is encapsulated in UDP. is encapsulated in UDP.
In conclusion, the packet formats for the binding update and In conclusion, the packet formats for the binding update and
acknowledgement messages are shown below: acknowledgement messages are shown below:
A. Binding update received by the home agent: A. Binding update received by the home agent:
IPv4 header (src=V4ADDR, dst=HA_V4ADDR) IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header UDP header
IPv6 header (src=V4CoA, dst=HAADDR) IPv6 header (src=V6HOA, dst=HAADDR)
DST-OPT ESP-header
HAO (IPv6 home address)
Mobility header Mobility header
BU [IPv4 HAO] BU [IPv4 HAO]
IPv4 CoA option
Where V4ADDR is either the IPv4 care-of address or the address Where V4ADDR is either the IPv4 care-of address or the address
provided by the NAT device. V4COA is the IPv4 care-of address of the provided by the NAT device. V6HOA is the IPv6 home address of the
mobile node. HAO is the home address option and BU is the binding mobile node. The binding update MAY also contain the IPv4 home
update, which MAY contain the IPv4 home address option. address option IPv4 HAO.
B. Binding acknowledgement sent by the home agent: B. Binding acknowledgement sent by the home agent:
IPv4 header (src=V4ADDR, dst=HA_V4ADDR) IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
UDP header UDP header
IPv6 header (src=V4CoA, dst=HAADDR) IPv6 header (src=HAADDR, dst=V6HOA)
Route HDR Type 2 Route HDR Type 2
HOA (IPv6 home address) V6HOA (IPv6 home address)
Mobility header Mobility header
BA ([IPv4 ACK], NAT DET) BA ([IPv4 ACK], NAT DET)
Where HOA 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.
4.2. NAT Keepalives 4.3. NAT Keepalives
If a NAT is detected, the mobile node will need to refresh the NAT If a NAT is detected, the mobile node will need to refresh the NAT
bindings in order to be reachable from the home agent. NAT bindings bindings in order to be reachable from the home agent. NAT bindings
can be refreshed through sending and receiving traffic encapsulated can be refreshed through sending and receiving traffic encapsulated
in UDP. However, if the mobile node is not active, it will need to in UDP. However, if the mobile node is not active, it will need to
periodically send a message to the home agent in order to refresh the periodically send a message to the home agent in order to refresh the
NAT binding. This can be done using the binding update message. The NAT binding. This can be done using the binding update message. The
binding update/acknowledgement pair will ensure that the NAT bindings binding update/acknowledgement pair will ensure that the NAT bindings
are refreshed in a reliable manner. are refreshed in a reliable manner. There is no way for the mobile
There is no way for the mobile node to know the exact time of the NAT node to know the exact time of the NAT binding. The default time
binding. The default time suggested in this specification is suggested in this specification is NATKATIMEOUT. If the home agent
NATKATIMEOUT. If the home agent suggests a different refresh period suggests a different refresh period in the binding acknowledgement,
in the binding acknowledgement, the mobile node SHOULD use the value the mobile node SHOULD use the value suggested by the home agent.
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.
4.3. 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. The IPv4 home address is never sent in the IPv4-mapped home address.
IPv6 address format. This is primarily done to save bandwidth.
However, to simplify the mobile node's implementation, they may store
the IPv4 home address in the binding update list, using the IPv4-
mapped IPv6 format.
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:
- The IPv6 packet is encapsulated in UDP and an IPv4 packet. - The IPv6 packet is encapsulated in the vanilla UDP encapsulation
format.
- The source address in the IPv4 header is the mobile node's IPv4 - The source address in the IPv4 header is the mobile node's IPv4
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 IPv4- - The source address in the IPv6 header is the mobile node's IPv6
mapped IPv6 address. That is, the same IPv4 address in the outer home address.
header is placed in the IPv6 header using the mapped address
format.
- The home address option contains the IPv6 home address as
specified in [MIPv6].
- 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
set the F flag in the binding update message.
- If the mobile node prefers to use the TLV-header format, it should
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 should include the IPv4 home address option in the mobility it MUST include the IPv4 home address option in the mobility header.
header. If the mobile node already has a static IPv4 home address, If the mobile node already has a static IPv4 home address, such
such address MUST be included in the IPv4 home address option. address MUST be included in the IPv4 home address option. Otherwise,
Otherwise, if the mobile node needs a dynamic IPv4 address, it should if the mobile node needs a dynamic IPv4 address, it MUST include the
include the IPv4 unspecified address in the IPv4 home address option. IPv4 unspecified 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 should follow the rules in [MIPv6] and [NEMO]. In addition, agent, it follows the rules in [MIPv6] and [NEMO]. In addition, the
the following actions MUST be made: following actions MUST be made:
- If the status field indicated failure with error code 144, the
mobile node MAY resend the binding update without setting the F
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
entries in its binding update list, one for the IPv6 home address entries in its binding update list, one for the IPv6 home address
and another for the IPv4 home address. and another for the IPv4 home address.
- If the NAT detection option were present, the mobile node - If the NAT detection option were present, the mobile node
MUST tunnel future packets in UDP and IPv4. This MUST be indicated MUST tunnel future packets in UDP and IPv4. This MUST be indicated
in the binding update list. in the binding update list.
- If no IPv4 address acknowledgement option were present, and an - If no IPv4 address acknowledgement option were present, and an
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
acknowledgement included a T flag set, the mobile node MUST use the
TLV-header UDP encapsulation format.
4.3.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=V4ADDR, dst=HA_V4ADDR) IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP header] [UDP header]
IPv6 header (src=V6HoA, dst=CN) IPv6 header (src=V6HoA, dst=CN)
Upper layer protocols Upper layer protocols
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. V4CoA is the IPv4 care-of address configured by the
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=V4ADDR, dst=HA_V4ADDR) IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP header] [UDP header]
IPv4 header (src=V4HoA, dst=V4CN) IPv4 header (src=V4HoA, dst=V4CN)
Upper layer protocols Upper layer protocols
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.
4.3.2 Movement detection in IPv4-only networks If the mobile node requested, and the home agent agreed, to use the
TLV-header UDP encapsulation format, then the TLV-header would be
used after the UDP header.
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. Such 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.4. 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
agent MUST be able to detect the presence of a NAT device and agent MUST be able to detect the presence of a NAT device and
indicate that in the NAT detection option included in the binding indicate that in the NAT detection option included in the binding
acknowledgement. acknowledgement.
A home agent must also act as a proxy for address resolution in IPv4 A home agent must also act as a proxy for address resolution in IPv4
skipping to change at page 18, line 24 skipping to change at page 21, line 39
agent MUST store the corresponding IPv4 home address if a static one agent MUST store the corresponding IPv4 home address if a static one
is present. If a dynamic address were requested by the mobile node, is present. If a dynamic address were requested by the mobile node,
the home agent MUST store that address (associated with the IPv6 home the home agent MUST store that address (associated with the IPv6 home
address) after it's allocated to the mobile node. address) after it's allocated to the mobile node.
When the home agent receives a binding update encapsulated in UDP and When the home agent receives a binding update encapsulated in UDP and
containing the IPv4 home address option, it needs to follow all the containing the IPv4 home address option, it needs to follow all the
steps in [MIPv6] and [NEMO]. In addition, the following checks MUST steps in [MIPv6] and [NEMO]. In addition, the following checks MUST
be done: be done:
- If the IPv4 care-of address in the IPv6 header is not the same as - If the IPv4 care-of address in the IPv4 CoA option is not the same
the IPv4 address in the source address in the IPv4 header then a as the IPv4 address in the source address in the IPv4 header then
NAT was in the path. This information should be flagged for the a NAT was in the path. This information should be flagged for the
binding acknowledgement. binding acknowledgement.
- If the F flag in the binding update were set, the home agent needs
to determine whether it accepts forcing UDP encapsulation. If it
does not, the binding acknowledgement is sent with error code 144.
- If the T flag was set in the binding update, the home agent needs
to determine whether it can accept the TLV-header encapsulation
format. If it does, it should set the T flag in the binding
acknowledgement. Otherwise, the home agent MUST NOT set the T flag
in the binding acknowledgement.
- If the IPv4 home address option contains a valid unicast IPv4 - If the IPv4 home address option contains a valid unicast IPv4
address, the home agent MUST check that this address is allocated address, the home agent MUST check that this address is allocated
to the mobile node that has the IPv6 home address included in the to the mobile node that has the IPv6 home address included in the
home address option. The same MUST be done for an IPv4 prefix. home address option. The same MUST be done for an IPv4 prefix.
- If the IPv4 home address option contained the unspecified IPv4 - If the IPv4 home address option contained the unspecified IPv4
address, the home agent SHOULD dynamically allocate an IPv4 home address, the home agent SHOULD dynamically allocate an IPv4 home
address to the mobile node. If none is available, the home agent address to the mobile node. If none is available, the home agent
MUST return an appropriate error code in the status field of the MUST return error code 132 in the status field of the IPv4 address
IPv4 address acknowledgement option. If a prefix were requested, acknowledgement option. If a prefix were requested, the home agent
the home agent MUST allocate a prefix with the requested length; MUST allocate a prefix with the requested length; otherwise the
otherwise the home agent MUST indicate failure of the operation home agent MUST indicate failure of the operation with the
with the appropriate error code. appropriate error code.
- If the binding update is accepted for the IPv4 home address, the - If the binding update is accepted for the IPv4 home address, the
home agent creates a binding cache entry for the IPv4 home home agent creates a binding cache entry for the IPv4 home
address/prefix. If a single IPv4 home address were requested, it address/prefix. The home agent MUST include an IPv4 acknowledgement
MAY be stored in the IPv4-mapped IPv6 address format. The home option in the mobility header containing the binding
agent MUST include an IPv4 acknowledgement option in the mobility acknowledgement.
header containing the binding acknowledgement.
If the binding update is accepted for both IPv4 and IPv6 home If the binding update is accepted for both IPv4 and IPv6 home
addresses, the home agent creates separate binding cache entries, one addresses, the home agent creates separate binding cache entries, one
for each home address. The care-of address is the one included in the for each home address. The care-of address is the one included in the
binding update. If the care-of address is an IPv4-mapped IPv6 binding update. If the care-of address is an IPv4 address, the home
address, the home agent MUST setup a tunnel to the IPv4 care-of agent MUST setup a tunnel to the IPv4 care-of address of the mobile
address of the mobile node. node.
When sending a binding acknowledgement to the mobile node, the home When sending a binding acknowledgement to the mobile node, the home
agent would construct the message according to [MIPv6] and [NEMO]. agent constructs the message according to [MIPv6] and [NEMO]. Note
Note that the routing header MUST always contain the IPv6 home that the routing header MUST always contain the IPv6 home address as
address as specified in [MIPv6]. specified in [MIPv6].
If the care-of address of the mobile node were an IPv4 address, the If the care-of address of the mobile node were an IPv4 address, the
home agent MUST include this address in the destination address in home agent includes the mobile node's IPv6 home address in the
the IPv6 header using the IPv4-mapped IPv6 format. If a NAT were destination address field in the IPv6 header. If a NAT were detected,
detected, the home agent MUST then encapsulate the packet in UDP and the home agent MUST then encapsulate the packet in UDP and an IPv4
an IPv4 header. The source address is set to the home agent's IPv4 header. The source address is set to the home agent's IPv4 address
address and the destination address is set to the address received in and the destination address is set to the address received in the
the source address of the IPv4 header encapsulating the binding source address of the IPv4 header encapsulating the binding update.
update.
After creating a binding cache entry for the mobile node's home After creating a binding cache entry for the mobile node's home
addresses, all packets sent to the mobile node's home addresses are addresses, all packets sent to the mobile node's home addresses are
tunneled by the home agent to the mobile node's care-of address. If 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.
4.4.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 following format: network, the home agent must follow the format negotiated in the
binding update/acknowledgement exchange. In the absence of a
negotiated format, the default format that MUST be supported by all
implementations is:
IPv4 header (src= HA_V4ADDR, dst= V4CoA) IPv4 header (src= HA_V4ADDR, dst= V4CoA)
[UDP header] [UDP header]
IPv6 header (src=CN, dst= V6HoA) IPv6 header (src=CN, dst= V6HoA)
Upper layer protocols Upper layer protocols
Where the UDP header is only included if a NAT were detected between Where the UDP header is only included if a NAT were detected between
the mobile node and the home agent, or if the home agent forced UDP the mobile node and the home agent, or if the home agent forced UDP
encapsulation. encapsulation.
When sending IPv4 packets to a mobile node located in an IPv4 When sending IPv4 packets to a mobile node located in an IPv4
network, the home agent must follow the following format: network, the home agent must follow the format negotiated in the
binding update/acknowledgement exchange. In the absence of a
negotiated format, the default format that MUST be supported by all
implementations is:
IPv4 header (src= HA_V4ADDR, dst= V4CoA) IPv4 header (src= HA_V4ADDR, dst= V4CoA)
[UDP header] [UDP header]
IPv4 header (src=V4CN, dst= V4HoA) IPv4 header (src=V4CN, dst= V4HoA)
Upper layer protocols Upper layer protocols
Where the UDP header is only included if a NAT were detected between Where the UDP header is only included if a NAT were detected between
the mobile node and home agent, or if the home agent forced UDP the mobile node and home agent, or if the home agent forced UDP
encapsulation. encapsulation.
4.5. Correspondent node operations 4.6. Correspondent node operations
This specification has no impact on IPv4 or IPv6 correspondent nodes. This specification has no impact on IPv4 or IPv6 correspondent nodes.
5. Security considerations 5. Security considerations
This specification allows a mobile node to send one binding update This specification allows a mobile node to send one binding update
for its IPv6 and IPv4 home addresses. This is a slight deviation from for its IPv6 and IPv4 home addresses. This is a slight deviation from
[MIPv6] which requires one binding update per home address. However, [MIPv6] which requires one binding update per home address. However,
like [MIPv6], the IPsec security association needed to authenticate like [MIPv6], the IPsec security association needed to authenticate
the binding update is still based on the mobile node's IPv6 home the binding update is still based on the mobile node's IPv6 home
skipping to change at page 20, line 34 skipping to change at page 24, line 13
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 such address.
In cases where this specification is used for NAT traversal, it is
important to note that it has the same UNSAF vulnerabilities
associated with RFC 3519. An attacker is able to hijack the mobile
node's session with the home agent if it can modify the contents of
the outer IPv4 header. The contents of the header are not
authenticated and there is no way for the home agent to verify their
validity. Hence, a man in the middle attack where a change in the
contents of the IPv4 header can cause a legitimate mobile node's
traffic to be diverted to an illegitimate receiver independently of
the authenticity of the binding update message.
6. Protocol constants 6. Protocol constants
NATKATIMEOUT 110 seconds NATKATIMEOUT 110 seconds
7. Acknowledgements 7. Acknowledgements
Thanks to Keiichi Shima for his comments on the draft. Thanks to the following members (in alphabetical order) of the MIP6
and NEMO Working Groups for their contributions, discussion, and
review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson,
Ahmad Muhanna, Vidya Narayanan, Karen Neilsen and Keiichi Shima.
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
an option type. This option is included in the Mobility header
described in [MIPv6].
9. References 9. References
[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", draft-ietf-mip6-
bootstrapping-split, June 2005, work in progress. 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)",
RFC 4140, August 2005. RFC 4140, August 2005.
[IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6)
specification", RFC 2460 specification", RFC 2460
skipping to change at page 21, line 20 skipping to change at page 25, line 15
IPv6 bootstrapping in split scenario", draft-ietf-mip6- IPv6 bootstrapping in split scenario", draft-ietf-mip6-
bootstrapping-split, June 2005, work in progress. 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)",
RFC 4140, August 2005. RFC 4140, August 2005.
[IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6)
specification", RFC 2460 specification", RFC 2460
[INTBOOT] K. Chowdhury and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", draft-ietf-mip6-bootstrapping-
integrated-dhc-02, Work in Progress.
[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.
[MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for
Dual stack mobile nodes, A Problem Statement", Dual stack mobile nodes, A Problem Statement",
draft-ietf-mip6-dsmip-problem-01.txt, July 2005. draft-ietf-mip6-dsmip-problem-01.txt, July 2005.
[MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in
skipping to change at page 21, line 47 skipping to change at page 25, line 46
Protoect Mobile IPv6 Signaling between Mobile Nodes and Home Protoect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004. Agents", RFC 3776, June 2004.
[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.
10. Contributors 10. Contributors
This document reflects discussions and contributions from several This document reflects discussions and contributions from several
people (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
Henrik Levkowetz Henrik Levkowetz
E-mail: henrik@levkowetz.com E-mail: henrik@levkowetz.com
Pascal Thubert Pascal Thubert
E-mail: pthubert@cisco.com E-mail: pthubert@cisco.com
George Tsirtsis George Tsirtsis
E-mail1: G.Tsirtsis@Qualcomm.com E-mail1: G.Tsirtsis@Qualcomm.com
E-mail2: tsirtsisg@yahoo.com E-mail2: tsirtsisg@yahoo.com
skipping to change at page 23, line 6 skipping to change at page 27, line 4
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the Copyright (C) The IETF Trust (2007). 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 September, 2007. This Internet-Draft expires January, 2008.
 End of changes. 68 change blocks. 
145 lines changed or deleted 346 lines changed or added

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