draft-ietf-mext-nemo-v4traversal-03.txt   draft-ietf-mext-nemo-v4traversal-04.txt 
Network Working Group H. Soliman, Ed. Network Working Group H. Soliman, Ed.
Internet-Draft Elevate Technologies Internet-Draft Elevate Technologies
Intended status: Standards Track May 25, 2008 Intended status: Standards Track June 10, 2008
Expires: November 26, 2008 Expires: December 12, 2008
Mobile IPv6 Support for Dual Stack Hosts and Routers Mobile IPv6 Support for Dual Stack Hosts and Routers
draft-ietf-mext-nemo-v4traversal-03.txt draft-ietf-mext-nemo-v4traversal-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2008. This Internet-Draft will expire on December 12, 2008.
Abstract Abstract
The current Mobile IPv6 and NEMO specifications support IPv6 only. The current Mobile IPv6 and NEMO specifications support IPv6 only.
This specification extends those standards to allow the registration This specification extends those standards to allow the registration
of IPv4 addresses and prefixes, respectively, and the transport of of IPv4 addresses and prefixes, respectively, and the transport of
both IPv4 and IPv6 packets over the tunnel to the home agent. This both IPv4 and IPv6 packets over the tunnel to the home agent. This
specification also allows the Mobile Node to roam over both IPv6 and specification also allows the Mobile Node to roam over both IPv6 and
IPv4, including the case where Network Address Translation is present IPv4, including the case where Network Address Translation is present
on the path between the mobile node and its home agent. on the path between the mobile node and its home agent.
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 14 4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 14
4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 14 4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 14
4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 15 4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 15
4.1.3. The Binding Update Message Extensions . . . . . . . . 16 4.1.3. The Binding Update Message Extensions . . . . . . . . 16
4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 16 4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 16
4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 16 4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 16
4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 18 4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 18
4.2.3. Extensions to the Binding Acknowledgement Message . . 19 4.2.3. Extensions to the Binding Acknowledgement Message . . 19
5. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 20 5. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Vanilla and TLV-header UDP Tunelling Formats . . . . . . . 20 5.1. Vanilla and TLV-header UDP Tunelling Formats . . . . . . . 20
5.1.1. Tunnelling Impacts on Transport and MTU . . . . . . . 22 5.1.1. tuneling Impacts on Transport and MTU . . . . . . . . 22
5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 22 5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 22
5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 24 5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 25 5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 25
5.4.1. Sending Packets from a Visited Network . . . . . . . . 27 5.4.1. Sending Packets from a Visited Network . . . . . . . . 27
5.4.2. Movement Detection in IPv4-only Networks . . . . . . . 28 5.4.2. Movement Detection in IPv4-only Networks . . . . . . . 28
5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 28 5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 28
5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 30 5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 30
5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 31 5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 33 6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 33
skipping to change at page 6, line 25 skipping to change at page 6, line 25
introduces NAT traversal for this purpose. introduces NAT traversal for this purpose.
The above benefits make the case for using Mobile IPv6 only for dual The above benefits make the case for using Mobile IPv6 only for dual
stack mobile nodes in order to allow for a long lasting mobility stack mobile nodes in order to allow for a long lasting mobility
solution and minimize the need to changing the mobility stack due to solution and minimize the need to changing the mobility stack due to
the introduction of IPv6 within a deployed network. the introduction of IPv6 within a deployed network.
2.2. Scenarios Considered by This Specification 2.2. Scenarios Considered by This Specification
There are several scenarios that illustrate potential There are several scenarios that illustrate potential
incompatibilities for mobile nodes using Mobile. Some of the incompatibilities for mobile nodes using Mobile IPv6. Some of the
problems associated with mobility and transition issues were problems associated with mobility and transition issues were
presented in [RFC4977]. This specification considers the scenarios presented in [RFC4977]. This specification considers the scenarios
that address all the problems discussed in [RFC4977]. The scenarios that address all the problems discussed in [RFC4977]. The scenarios
considered in this specification are listed below. considered in this specification are listed below.
All of the following scenarios assume that both the mobile node and All of the following scenarios assume that both the mobile node and
the home agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is the home agent are IPv4 and IPv6-enabled and that only Mobile IPv6 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 address. Finally, it's important to note that the following
skipping to change at page 10, line 50 skipping to change at page 10, line 50
acknowledgment option as described later in this specification. This acknowledgment option as described later in this specification. This
option informs the mobile node whether the binding was accepted for option informs the mobile node whether the binding was accepted for
the IPv4 home address. If this option is not included in the binding the IPv4 home address. If this option is not included in the binding
acknowledgement and the IPv4 home address option was included in the acknowledgement and the IPv4 home address option was included in the
binding update, the mobile node MUST assume that the home agent does binding update, the mobile node MUST assume that the home agent does
not support the IPv4 home address option and therefore SHOULD NOT not support the IPv4 home address option and therefore SHOULD NOT
include the option in future binding updates to that home agent include the option in future binding updates to that home agent
address. address.
When a mobile node acquires both IPv4 and IPv6 care-of addresses at When a mobile node acquires both IPv4 and IPv6 care-of addresses at
foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 the foreign network, it SHOULD prioritize the IPv6 care-of address
binding registration. The mobile node MUST NOT register both IPv4 for MIP6 its binding registration. The mobile node MUST NOT register
and IPv6 care-of addresses to its home agent. both IPv4 and IPv6 care-of addresses to its home agent.
3.3.2. Foreign Network Supports IPv4 Only 3.3.2. Foreign Network Supports IPv4 Only
If the mobile node is in a foreign network that only supports IPv4, If the mobile node is in a foreign network that only supports IPv4,
it needs to detect whether a NAT is in its communication path to the it needs to detect whether a NAT is in its communication path to the
home agent. This is done while exchanging the binding update and home agent. This is done while exchanging the binding update and
acknowledgement messages as shown later in this document. 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.
3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses 3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses)
In this scenario the mobile node will need to tunnel IPv6 packets In this scenario the mobile node will need to tunnel IPv6 packets
containing the binding update to the home agent's IPv4 address. The containing the binding update to the home agent's IPv4 address. The
mobile node uses the IPv4 address it gets from the foreign network as mobile node uses the IPv4 address it gets from the foreign network as
a source address in the outer header. The binding update will a source address in the outer header. The binding update will
contain the mobile node's IPv6 home address. However, since the contain the mobile node's IPv6 home address. However, since the
care-of address in this scenario is the mobile node's IPv4 address, care-of address in this scenario is the mobile node's IPv4 address,
the mobile node MUST include its IPv4 care-of address in the IPv6 the mobile node MUST include its IPv4 care-of address in the IPv6
packet. The IPv4 address is represented in the IPv4 Care-of address packet. The IPv4 address is represented in the IPv4 Care-of address
option defined in this specification. If the mobile node had an IPv4 option defined in this specification. If the mobile node had an IPv4
skipping to change at page 12, line 5 skipping to change at page 12, line 5
After accepting the binding updates and creating the corresponding After accepting the binding updates and creating the corresponding
entries, the home agent MUST send a binding acknowledgement as entries, the home agent MUST send a binding acknowledgement as
specified in [RFC3775]. In addition, if the binding update included specified in [RFC3775]. In addition, if the binding update included
an IPv4 home address option, the binding acknowledgement MUST include an IPv4 home address option, the binding acknowledgement MUST include
the IPv4 address acknowledgment option as described later in this the IPv4 address acknowledgment option as described later in this
specification. The binding acknowledgement is encapsulated to the specification. The binding acknowledgement is encapsulated to the
IPv4 care-of address, which was included in the source address field IPv4 care-of address, which was included in the source address field
of the IPv4 header encapsulating the binding update. of the IPv4 header encapsulating the binding update.
3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses)
n 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 using UDP
IPv4. The UDP port allocated for the home agent is TBA. and IPv4. The UDP port allocated for the home agent is TBD_DSMIPv6.
The mobile node uses the IPv4 address it gets from the visited The mobile node uses the IPv4 address it gets from the visited
network as a source address in the IPv4 header. The binding update network as a source address in the IPv4 header. The binding update
will contain the mobile node's IPv6 home address. will contain the mobile node's IPv6 home address.
After accepting the binding update, the home agent MUST create a new After accepting the binding update, the home agent MUST create a new
binding cache entry for the mobile node's IPv6 home address. If an binding cache entry for the mobile node's IPv6 home address. If an
IPv4 home address option were included, the home agent MUST create IPv4 home address option 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
skipping to change at page 17, line 43 skipping to change at page 17, line 43
case of failure. This field overrides what the mobile node case of failure. This field overrides what the mobile node
requested (if not equal to the requested length). requested (if not equal to the requested length).
Res Res
This field is reserved for future use. It MUST be set to zero by This field is reserved for future use. It MUST be set to zero by
the sender and ignored by the receiver the sender and ignored by the receiver
IPv4 Home Address IPv4 Home Address
he IPv4 home address that the home agent will use in the binding The IPv4 home address that the home agent will use in the binding
cache entry. This could be a public or private address. This cache entry. This could be a public or private address. This
field MUST contain the mobile node's IPv4 home address. If the field MUST contain the mobile node's IPv4 home address. If the
address were dynamically allocated the home agent will add the address were dynamically allocated the home agent will add the
address to inform the mobile node. Otherwise, if the address were address to inform the mobile node. Otherwise, if the address were
statically allocated to the mobile node, the home agent will copy statically allocated to the mobile node, the home agent will copy
it from the binding update message. it from the binding update message.
The following values are allocated for the Status field: The following values are allocated for the Status field:
o 0 Success o 0 Success
skipping to change at page 19, line 14 skipping to change at page 19, line 14
Reserved Reserved
This field is reserved for future use. It MUST be set to zero by This field is reserved for future use. It MUST be set to zero by
the sender and ignored by the receiver. the sender and ignored by the receiver.
Refresh Time Refresh Time
A suggested time (in seconds) for the mobile node to refresh the A suggested time (in seconds) for the mobile node to refresh the
NAT binding. If set to zero, it is ignored. If this field is set NAT binding. If set to zero, it is ignored. If this field is set
to the all 1s it means that keepalives are not needed, i.e.,no NAT to all 1s it means that keepalives are not needed, i.e., no NAT
was detected. was detected.
4.2.3. Extensions to the Binding Acknowledgement Message 4.2.3. Extensions to the Binding Acknowledgement Message
This specification extends the binding acknowledgement message with a This specification extends the binding acknowledgement message with a
new flag. The new flag is shown and described below. new flag. The new flag is shown and described below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|T| Reserved| | Status |K|R|T| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 13 skipping to change at page 20, line 13
acknowledgement supports the TLV- tunnel format. acknowledgement supports the TLV- tunnel format.
5. Protocol operation 5. Protocol operation
This section presents the protocol operation and processing for the This section presents the protocol operation and processing for the
messages presented above. In addition, this section introduces the messages presented above. In addition, this section introduces the
NAT detection and traversal mechanism used by this specification. NAT detection and traversal mechanism used by this specification.
5.1. Vanilla and TLV-header UDP Tunelling Formats 5.1. Vanilla and TLV-header UDP Tunelling Formats
This specification allows the mobile node to use various tunnelling This specification allows the mobile node to use various tuneling
formats depending on its location and the visited networ's formats depending on its location and the visited network's
capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6
or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this
specification also supports tunnelling IPv6 in IPv6. specification also supports tuneling IPv6 in IPv6.
This speacification allows UDP-based tunnelling to be used between This specification allows UDP-based tuneling to be used between the
the mobile node and its home agent or MAP using either vanilla UDP mobile node and its home agent or MAP using either vanilla UDP
encapsulation or TLV- header UDP encapsulation. A vanilla UDP encapsulation or TLV- header UDP encapsulation. A vanilla UDP
encapsulation format means the following order of headers: encapsulation format means the following order of headers:
IPv4 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 normally. The above order of headers does not take IPsec headers
into account as they may be placed in different parts of the packet. into account as they may be placed in different parts of the packet.
The above format MUST be supported by all implementations of this The above format MUST be supported by all implementations of this
specification and MUST always be used to send the binding update specification and MUST always be used to send the binding update
message. message.
A TLV-header UDP encapsulation is represented by the following order TLV-header UDP encapsulation is represented by the following order of
of headers: headers:
IP (v4 or v6) IP (v4 or v6)
UDP UDP
TLV-header TLV-header
Other headers Other headers
The use of the TLV header is negotiated during the binding update/ The use of the TLV-header is negotiated during the binding update/
acknowledgement exchange. If the TLV header is agreed upon, the acknowledgement exchange. If the TLV-header is agreed upon, the
receiver of the TLV-header UDP encapsulated packet expects the TLV- receiver of the TLV-header UDP encapsulated packet expects the TLV
header to follow UDP. The TLV header contains the type of the header to follow UDP. The TLV header contains the type of the
following message and its length. The Type field MUST NOT be following message and its length. The Type field MUST NOT be
assigned the values 4 or 6 to make sure that the receiver can tell assigned the values 4 or 6 to make sure that the receiver can tell
the difference between the Type field and the IP version field in a the difference between the Type field and the IP version field in a
packet that contains an IP header after UDP. Hence, the TLV header packet that contains an IP header after UDP. Hence, the TLV header
can carry traffic other than IP. can carry traffic other than IP.
The mobile node negotiates the format for tunnelling payload traffic The mobile node negotiates the format for tuneling payload traffic
during the binding exchange. If a mobile node prefers to use the during the binding exchange. If a mobile node prefers to use the
TLV- header UDP encapsulation, it sets the T flag in the binding 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 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 update supports the TLV-header format, it SHOULD set the T flag in
the binding acknowledgement message. Otherwise, the T flag is the binding acknowledgement message. Otherwise, the T flag is
cleared. The setting of the T flag in the binding acknowledgement cleared. The setting of the T flag in the binding acknowledgement
indicates to the mobile node that it must use the TLV-header UDP indicates to the mobile node that it must use the TLV-header UDP
encapsulation format for all packets sent for the duration of the encapsulation format for all packets sent for the duration of the
binding or until a new binding update is sent. Each binding update binding or until a new binding update is sent. Each binding update
may renegotiate the tunnelling format. To avoid interoperability may renegotiate the tuneling format. To avoid interoperability
issues, the sender of the binding acknowledgement MUST NOT set the T 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 flag unless it was set in the binding update sent from the mobile
node. 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 22, line 8 skipping to change at page 22, line 8
Length Length
This field indicates the length of the payload following the This field indicates the length of the payload following the
header, excluding the TLV-header itself. header, excluding the TLV-header itself.
Reserved Reserved
This field MUST be set to zero by the sender and ignored by the This field MUST be set to zero by the sender and ignored by the
receiver. receiver.
The following value is assigned to the Type field, other values may The following value is assigned to the Type field, other values may
be assigned in future: be assigned in the future:
1 GRE 1 GRE
In addition to UDP-based tunnelling, this specification allows for In addition to UDP-based tuneling, this specification allows for
standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213]. standard IP in IP tuneling as defined in [RFC2473] and [RFC4213].
This can take place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. This can take place by tuneling IPv4 in IPv6 or IPv6 in IPv4.
However, whenever a NAT is detected, the mobile node will default to However, whenever a NAT is detected, the mobile node will default to
UDP-based encapsulation. The mobile node can request to always use UDP-based encapsulation. The mobile node can request to always use
UDP encapsulation by setting the F flag in the binding update. If UDP encapsulation by setting the F flag in the binding update. If
the home agent does not agree to the request, it MUST reject the the home agent does not agree to the request, it MUST reject the
binding update with the new Status code: binding update with the new Status code:
144 Cannot force UDP encapsulation 144 Cannot force UDP encapsulation
Alternatively, the home agent can force UDP encapsulation by setting Alternatively, the home agent can force UDP encapsulation by setting
the F flag in the NAT detection option included in the binding the F flag in the NAT detection option included in the binding
acknowledgement. acknowledgement.
5.1.1. Tunnelling Impacts on Transport and MTU 5.1.1. tuneling Impacts on Transport and MTU
Changing the tunnel format may occur due to movement of the mobile Changing the tunnel format may occur due to movement of the mobile
node from one network to another. This can have impacts on the link node from one network to another. This can have impacts on the link
and path MTU, which may affect the amount of bandwidth available to and path MTU, which may affect the amount of bandwidth available to
the applications. It is recommended that the mobile node use PLMTUD the applications. It is recommended that the mobile node use PLMTUD
as specified in [RFC4459]. as specified in [RFC4459].
To accomodate traffic that uses Explicit Congestion Notification To accommodate traffic that uses Explicit Congestion Notification
(ECN), it is RECOMMENDED that the ECN information is copied between (ECN), it is RECOMMENDED that the ECN information is copied between
the inner and outer header as defined in [RFC3168]. the inner and outer header as defined in [RFC3168].
5.2. NAT Detection 5.2. NAT Detection
NAT detection is done when the initial binding update message is sent NAT detection is done when the initial binding update message is sent
from the mobile node to the home agent. When located in an IPv4-only from the mobile node to the home agent. When located in an IPv4-only
foreign link, the mobile node sends the binding update message foreign link, the mobile node sends the binding update message
encapsulated in UDP and IPv4. The source address of the IPv6 packet encapsulated in UDP and IPv4. The source address of the IPv6 packet
is the mobile node's IPv6 home address. The destination address is is the mobile node's IPv6 home address. The destination address is
the IPv6 address of the home agent. The IPv4 header contains the the IPv6 address of the home agent. The IPv4 header contains the
IPv4 care-of address in the source address field and the IPv4 address IPv4 care-of address in the source address field and the IPv4 address
of the home agent in the destination address field. of the home agent in the destination address field.
When the home agent receives the encapsulated binding update it When the home agent receives the encapsulated binding update, it
compares the IPv4 address of the source address field in the IPv4 compares the IPv4 address of the source address field in the IPv4
header with the IPv4 address included in the IPv4 care-of address header with the IPv4 address included in the IPv4 care-of address
option. If the two addresses match, no NAT device was in the path. option. If the two addresses match, no NAT device was in the path.
Otherwise, a NAT device was in the path and the NAT detection option Otherwise, a NAT 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
skipping to change at page 25, line 8 skipping to change at page 25, line 8
periodically send a message to the home agent in order to refresh the periodically send a message to the home agent in order to refresh the
NAT binding. This can be done using the binding update message. The NAT binding. This can be done using the binding update message. The
binding update/acknowledgement pair will ensure that the NAT bindings binding update/acknowledgement pair will ensure that the NAT bindings
are refreshed in a reliable manner. There is no way for the mobile are refreshed in a reliable manner. There is no way for the mobile
node to know the exact time of the NAT binding. The default time node to know the exact time of the NAT binding. The default time
suggested in this specification is NATKATIMEOUT. If the home agent suggested in this specification is NATKATIMEOUT. If the home agent
suggests a different refresh period in the binding acknowledgement, suggests a different refresh period in the binding acknowledgement,
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 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 the NAT binding. In this case,
mobile node would only be able to initiate communication with other the mobile node would only be able to initiate communication with
nodes. However, this is likely to imply that the mobile node will other nodes. However, this is likely to imply that the mobile node
need to send a binding update before initiating communication after a will need to send a binding update before initiating communication
long idle period as it is likely to be assigned a different port and after a long idle period as it is likely to be assigned a different
IPv4 address when it initiates communication. Hence, an port and IPv4 address when it initiates communication. Hence, an
implementation may choose, for the sake of simplicity, to always implementation may choose, for the sake of simplicity, to always
maintain the NAT bindings even when it does not need reachability. maintain the NAT bindings even when it does not need reachability.
5.4. Mobile Node Operation 5.4. Mobile Node Operation
In addition to the operations specified in [RFC3775] and [RFC3963], In addition to the operations specified in [RFC3775] and [RFC3963],
this specification requires mobile nodes to be able to support an this specification requires mobile nodes to be able to support an
IPv4 home address. IPv4 home address.
When sending an IPv6 packet containing a binding update while When sending an IPv6 packet containing a binding update while
skipping to change at page 27, line 29 skipping to change at page 27, line 29
IPv4 header (src=V4CoA, dst=HA_V4ADDR) IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP Header] [UDP Header]
[TLV 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 Here the UDP header is only used if a NAT has been detected between
mobile node and the home agent, or if the home agent forced UDP the mobile node and the home agent, or if the home agent forced UDP
encapsulation. V4CoA is the IPv4 care-of address configured by the encapsulation. V4CoA is the IPv4 care-of address configured by the
mobile node in the visited network. mobile node in the visited network.
Similarly, IPv4 packets are sent according to the following format: Similarly, IPv4 packets are sent according to the following format:
IPv4 header (src=V4CoA, dst=HA_V4ADDR) IPv4 header (src=V4CoA, dst=HA_V4ADDR)
[UDP Header] [UDP Header]
[TLV Header] [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 Here the UDP header is only used if a NAT has been detected between
mobile node and the home agent, or if the home agent forced UDP the mobile node and the home agent, or if the home agent forced UDP
encapsulation. encapsulation.
If the mobile node and the home agent negotiated the use of the TLV- If the mobile node and the home agent negotiated the use of the TLV-
header UDP encapsulation format, then the TLV-header would be used header UDP encapsulation format, then the TLV-header would be used
after the UDP header. after the UDP header.
5.4.2. Movement Detection in IPv4-only Networks 5.4.2. Movement Detection in IPv4-only Networks
[RFC3775] describes movement detection mostly based on IPv6-specific [RFC3775] describes movement detection mostly based on IPv6-specific
triggers and Neighbor Discovery [RFC4861] information. These triggers and Neighbor Discovery [RFC4861] information. These
triggers would not be available in an IPv4-only network. Hence, a triggers are not available in an IPv4-only network. Hence, a mobile
mobile node located in an IPv4-only network SHOULD use [RFC4436] for node located in an IPv4-only network SHOULD use [RFC4436] for
guidance on movement detection mechanisms in IPv4-only networks. guidance on movement detection mechanisms in IPv4-only networks.
5.5. Home agent operation 5.5. Home agent operation
In addition to the home agent specification in [RFC3775] and In addition to the home agent specification in [RFC3775] and
[RFC3963], the home agent needs to be able to process the IPv4 home [RFC3963], the home agent needs to be able to process the IPv4 home
address option and generate the IPv4 address acknowledgement option. address option and generate the IPv4 address acknowledgement option.
Both options are included in the mobility header. Furthermore, the Both options are included in the mobility header. Furthermore, the
home agent MUST be able to detect the presence of a NAT device and home agent MUST be able to detect the presence of a NAT device and
indicate that in the NAT detection option included in the binding indicate that in the NAT detection option included in the binding
skipping to change at page 29, line 22 skipping to change at page 29, line 22
o If the IPv4 home address option contains a valid unicast IPv4 o If the IPv4 home address option contains a valid unicast IPv4
address, the home agent MUST check that this address is allocated address, the home agent MUST check that this address is allocated
to the mobile node that has the IPv6 home address included in the to the mobile node that has the IPv6 home address included in the
home address option. The same MUST be done for an IPv4 prefix. home address option. The same MUST be done for an IPv4 prefix.
o If the IPv4 home address option contained the unspecified IPv4 o If the IPv4 home address option contained the unspecified IPv4
address, the home agent SHOULD dynamically allocate an IPv4 home address, the home agent SHOULD dynamically allocate an IPv4 home
address to the mobile node. If none is available, the home agent address to the mobile node. If none is available, the home agent
MUST return error code 132 in the status field of the IPv4 address MUST return error code 132 in the status field of the IPv4 address
acknowledgement option. If a prefix were requested, the home acknowledgement option. If a prefix were requested, the home
agent MUST allocate a prefix with the requested length; otherwise agent MUST allocate a prefix with the requested length; if that
the home agent MUST indicate failure of the operation with the allocation was not possible, the home agent MUST indicate failure
appropriate error code. of the operation with the appropriate error code.
o If the binding update is accepted for the IPv4 home address, the o If the binding update is accepted for the IPv4 home address, the
home agent creates a binding cache entry for the IPv4 home home agent creates a binding cache entry for the IPv4 home
address/prefix. The home agent MUST include an IPv4 address/prefix. The home agent MUST include an IPv4
acknowledgement option in the mobility header containing the acknowledgement option in the mobility header containing the
binding acknowledgement. binding acknowledgement.
o If the binding update is accepted for both IPv4 and IPv6 home o If the binding update is accepted for both IPv4 and IPv6 home
addresses, the home agent creates separate binding cache entries, addresses, the home agent creates separate binding cache entries,
one for each home address. The care-of address is the one one for each home address. The care-of address is the one
skipping to change at page 30, line 17 skipping to change at page 30, line 17
tunneled by the home agent to the mobile node's care-of address. If tunneled by the home agent to the mobile node's care-of address. If
a NAT were detected, packets are encapsulated in UDP and IPv4. a NAT 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 unless UDP detected, packets are encapsulated in an IPv4 header unless UDP
encapsulation is forced by the home agent. encapsulation is forced by the home agent.
5.5.1. Sending Packets to the Mobile Node 5.5.1. Sending Packets to the Mobile Node
The home agent follows the rules specified in [RFC3775] for sending The home agent follows the rules specified in [RFC3775] for sending
IPv6 packets to mobile nodes located in IPv6 networks. When sending IPv6 packets to mobile nodes located in IPv6 networks. When sending
IPv4 packets to When mobile nodes in an IPv6 network, the home agent IPv4 packets to mobile nodes in an IPv6 network, the home agent must
must encapsulate the IPv4 packets in IPv6. encapsulate the IPv4 packets in IPv6.
When sending IPv6 packets to a mobile node located in an IPv4 When sending IPv6 packets to a mobile node located in an IPv4
network, the home agent must follow the format negotiated in the network, the home agent must follow the format negotiated in the
binding update/acknowledgement exchange. In the absence of a binding update/acknowledgement exchange. In the absence of a
negotiated format, the default format that MUST be supported by all negotiated format, the default format that MUST be supported by all
implementations is: implementations is:
IPv4 header (src= HA_V4ADDR, dst= V4ADDR) IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
UDP Header UDP Header
skipping to change at page 32, line 24 skipping to change at page 32, line 24
address corresponding to the IPv6 address that is allocated to a address corresponding to the IPv6 address that is allocated to a
mobile node. Therefore, it is sufficient for the home agent to know mobile node. Therefore, it is sufficient for the home agent to know
that the IPsec verification for the packet containing the binding that the IPsec verification for the packet containing the binding
update was valid provided that it knows which IPv4 home address is update was valid provided that it knows which IPv4 home address is
associated with which IPv6 home address. Hence, the security of the associated with which IPv6 home address. Hence, the security of the
IPv4 home address binding is the same as the IPv6 binding. IPv4 home address binding is the same as the IPv6 binding.
In effect, associating the mobile node's IPv4 home address with its In effect, associating the mobile node's IPv4 home address with its
IPv6 home address moves the authorization of the binding update for IPv6 home address moves the authorization of the binding update for
the IPv4 address to the Mobile IPv6 implementation, which infers it the IPv4 address to the Mobile IPv6 implementation, which infers it
from the fact that mobile node has an IPv6 home address and the right from the fact that the mobile node has an IPv6 home address and the
credentials for sending an authentic binding update for the IPv6 right credentials for sending an authentic binding update for the
address. 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 vulnerabilities associated important to note that it has the same vulnerabilities associated
with [RFC3519]. An attacker is able to hijack the mobile node's with [RFC3519]. An attacker is able to hijack the mobile node's
session with the home agent if it can modify the contents of the session with the home agent if it can modify the contents of the
outer IPv4 header. The contents of the header are not authenticated outer IPv4 header. The contents of the header are not authenticated
and there is no way for the home agent to verify their validity. and there is no way for the home agent to verify their validity.
Hence, a man in the middle attack where a change in the contents of Hence, a man in the middle attack where a change in the contents of
the IPv4 header can cause a legitimate mobile node's traffic to be the IPv4 header can cause a legitimate mobile node's traffic to be
diverted to an illegitimate receiver independently of the diverted to an illegitimate receiver independently of the
skipping to change at page 34, line 32 skipping to change at page 34, line 32
as described above), the new address and port number are allocated by as described above), the new address and port number are allocated by
the NAT. The home agent will also enable or disable UDP the NAT. The home agent will also enable or disable UDP
encapsulation for outgoing ESP packets for the purpose of NAT encapsulation for outgoing ESP packets for the purpose of NAT
traversal. traversal.
If the Key Management Mobility Capability (K) bit was set in the If the Key Management Mobility Capability (K) bit was set in the
binding update, and the home agent supports this feature, the home binding update, and the home agent supports this feature, the home
agent updates its IKE security associations to include the mobile agent updates its IKE security associations to include the mobile
node's care-of address as the peer address and 4500 as the port node's care-of address as the peer address and 4500 as the port
number. The home agent may also need to change NAT traversal fields number. The home agent may also need to change NAT traversal fields
in the IKE_SA to enable the dyanmic update of the IP address and port in the IKE_SA to enable the dynamic update of the IP address and port
number based on the reception of authenticated IKE messages, or number based on the reception of authenticated IKE messages, or
authenticated packets using tunnel mode ESP. The dynamic updates are authenticated packets using tunnel mode ESP. The dynamic updates are
described in section 2.23 of RFC 4306. As described above, when the described in section 2.23 of RFC 4306. As described above, when the
mobile node is located in a private IPv4 network, the address and mobile node is located in a private IPv4 network, the address and
port number used for IPsec and IKE traffic is not yet known by the port number used for IPsec and IKE traffic is not yet known by the
home agent at this point. home agent at this point.
The mobile node updates the IKE SA in one of two ways. If the K flag The mobile node updates the IKE SA in one of two ways. If the K flag
was set in the binding acknowledgement message, the mobile node was set in the binding acknowledgement message, the mobile node
SHOULD send an empty informational message, which results in the IKE SHOULD send an empty informational message, which results in the IKE
skipping to change at page 35, line 19 skipping to change at page 35, line 19
After successfully processing the binding update, the home agent After successfully processing the binding update, the home agent
sends the binding acknowledgement to the mobile node's care-of sends the binding acknowledgement to the mobile node's care-of
address as received in the outer header of the packet containing the address as received in the outer header of the packet containing the
binding update. Note that if the BU was rejected, the BAck is sent binding update. Note that if the BU was rejected, the BAck is sent
to the same address where the BU was received from. This may require to the same address where the BU was received from. This may require
special treatment in IP forwarding and/or IPsec processing which special treatment in IP forwarding and/or IPsec processing which
resembles sending of BUs in the mobile node (described above). 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 tunnel mode Security Association information to include the its local tunnel mode Security Association information to include the
tunnel header IP source address, which is the the mobile node's tunnel header IP source address, which is the mobile node's address
address and the tunnel header IP destination, which is the home and the tunnel header IP destination, which is the home agent's
agent's address. The mobile node may also need to enable or disable address. The mobile node may also need to enable or disable UDP
UDP encapsulation for outgoing ESP packets for the purpose of NAT encapsulation for outgoing ESP packets for the purpose of NAT
traversal and the sending of keep alives. traversal and the sending of keep alives.
The mobile node MAY use [RFC4555] to update its IKE SA with the home The mobile node MAY use [RFC4555] 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 MUST 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.2. IKE negotiation messages between the mobile node and Home Agent 6.2. IKE negotiation messages between the mobile node and Home Agent
This specification defines a number of possible data encapsulation This specification defines a number of possible data encapsulation
formats depending on the mobile node's connectivity to the visited formats depending on the mobile node's connectivity to the visited
network. When connected to an IPv6-enabled network, the tunnelling network. When connected to an IPv6-enabled network, the tuneling
formats are clear. However, when connected to an IPv4-only network, formats are clear. However, when connected to an IPv4-only network,
care should be taken when negotiationg the IKE association and the care should be taken when negotiating the IKE association and the
consequential tunnelling formats used for secure and insecure consequential tuneling formats used for secure and insecure traffic.
traffic. This section illustrates the IKE message exchange between This section illustrates the IKE message exchange between the mobile
the mobile node and home agent when the mobile node is located in an node and home agent when the mobile node is located in an IPv4-only
IPv4-only network. Two different IKE negotiations are considered: network. Two different IKE negotiations are considered:
o IKEv2 operation for securing DSMIPv6 Signaling. o IKEv2 operation for securing DSMIPv6 Signaling.
o IKEv2 operation for securing Data over IPv4 o IKEv2 operation for securing Data over IPv4
6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling
A mobile node connected to an IPv4-only network SHOULD follow the A mobile node connected to an IPv4-only network SHOULD follow the
procedures described below in order to establish an SA for the procedures described below in order to establish an SA for the
protection of binding update and binding acknowledgement messages. protection of binding update and binding acknowledgement messages.
skipping to change at page 36, line 47 skipping to change at page 36, line 47
remote_address = home_agent_1 & remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use
SA ESP transport mode SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1 Initiate using IDi = user_1 to address home_agent_1
Home Agent SPD-S: Home Agent SPD-S:
F local_address = home_agent_1 & IF local_address = home_agent_1 &
remote_address = home_address_1 & remote_address = home_address_1 &
proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use
SA ESP transport mode SA ESP transport mode
where home_address_1 is the mobile node's registered IPv6 home where home_address_1 is the mobile node's registered IPv6 home
address and home_agent_1 is the IP address of the home agent address and home_agent_1 is the IP address of the home agent
The above should result in BU/BA messages with the following BU The above should result in BU/BA messages with the following BU
received by the home agent. received by the home agent.
Pv4 header (src=V4ADDR, dst=HA_V4ADDR) IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP header (sport=Z, dport=DSMIPv6) UDP header (sport=Z, dport=DSMIPv6)
IPv6 header (src=V6HOA, dst=HAADDR) IPv6 header (src=V6HOA, dst=HAADDR)
ESP Header in Transport Mode ESP Header in Transport Mode
Mobility header Mobility header
BU [IPv4 HAO] BU [IPv4 HAO]
skipping to change at page 38, line 29 skipping to change at page 38, line 29
IPsec module is as follows: IPsec module is as follows:
IPv6 header (src=HAADDR, dst=V6HOA) IPv6 header (src=HAADDR, dst=V6HOA)
Mobility Header Mobility Header
BA ([IPv4 ACK], NAT DET) BA ([IPv4 ACK], NAT DET)
(+ other as needed) (+ other as needed)
In addition, V4ADDR, the sport from the BU (Z), and aindication that In addition, V4ADDR, the sport from the BU (Z), and an indication
vanilla UDP encapsulation must be used, need to be passed with the that vanilla UDP encapsulation must be used, need to be passed with
packet to ensure correct processing. the packet to ensure correct processing.
The binding acknowledgement sent by the home agent to the mobile node The binding acknowledgement sent by the home agent to the mobile node
is as follows: is as follows:
IPv4 header (src= HA_V4ADDR, dst=V4ADDR) IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
UDP Header (sport=DSMIPv6, dport=Z) UDP Header (sport=DSMIPv6, dport=Z)
IPv6 header (src=HAADDR, dst=V6HOA) IPv6 header (src=HAADDR, dst=V6HOA)
skipping to change at page 39, line 40 skipping to change at page 39, line 40
UDP (sport=Y, dport=4500) UDP (sport=Y, dport=4500)
ESP ESP
IP (source_addr=HoA, set_addr=CNAddr) IP (source_addr=HoA, set_addr=CNAddr)
Upper_layer_HDR Upper_layer_HDR
Where v4CoA may be the external IPv4 address of the NAT, IP is either Where v4CoA may be the external IPv4 address of the NAT, IP is either
IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. The an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA.
above format shows the packet as seen by the home agent. The above format shows the packet as seen by the home agent.
The SPD, whether a NAT were detected or not, is set as follows. Note The SPD, whether a NAT were detected or not, is set as follows. Note
that this rule is designed to match all data from the MN to nodes that this rule is designed to match all data from the MN to nodes
other than the home agent. This is done so that this rule does not other than the home agent. This is done so that this rule does not
overlap with the earlier rule securing BU/BA signaling between the MN overlap with the earlier rule securing BU/BA signaling between the MN
and the HA. and the HA.
Mobile Node SPD-S: Mobile Node SPD-S:
IF local_address = home_address & IF local_address = home_address &
 End of changes. 40 change blocks. 
74 lines changed or deleted 74 lines changed or added

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