draft-ietf-mext-nemo-v4traversal-04.txt   draft-ietf-mext-nemo-v4traversal-05.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 June 10, 2008 Intended status: Standards Track July 14, 2008
Expires: December 12, 2008 Expires: January 15, 2009
Mobile IPv6 Support for Dual Stack Hosts and Routers Mobile IPv6 Support for Dual Stack Hosts and Routers
draft-ietf-mext-nemo-v4traversal-04.txt draft-ietf-mext-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 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 December 12, 2008. This Internet-Draft will expire on January 15, 2009.
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.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Motivation for Using Mobile IPv6 Only . . . . . . . . . . 5 2.1. Motivation for Using Mobile IPv6 Only . . . . . . . . . . 5
2.2. Scenarios Considered by This Specification . . . . . . . . 6 2.2. Scenarios Considered by This Specification . . . . . . . . 6
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 8 3.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 8
3.2. Mobile Prefix Solicitation and Advertisement . . . . . . . 9 3.2. Mobile Prefix Solicitation and Advertisement . . . . . . . 9
3.3. Binding Management . . . . . . . . . . . . . . . . . . . . 9 3.3. Binding Management . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Foreign Network Supports IPv6 . . . . . . . . . . . . 10 3.3.1. Foreign Network Supports IPv6 . . . . . . . . . . . . 10
3.3.2. Foreign Network Supports IPv4 Only . . . . . . . . . . 11 3.3.2. Foreign Network Supports IPv4 Only . . . . . . . . . . 11
3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 12 3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 13
3.5. Dynamic IPv4 Home Address Allocation . . . . . . . . . . . 13 3.5. Dynamic IPv4 Home Address Allocation . . . . . . . . . . . 13
4. Extensions And Modifications To Mobile IPv6 . . . . . . . . . 14 4. Extensions And Modifications To Mobile IPv6 . . . . . . . . . 14
4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 14 4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 14
4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 14 4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 14
4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 15 4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 15
4.1.3. The Binding Update Message Extensions . . . . . . . . 16 4.1.3. The Binding Update Message Extensions . . . . . . . . 16
4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 16 4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 16
4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 16 4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 16
4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 18 4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 18
4.2.3. Extensions to the Binding Acknowledgement Message . . 19 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. Tunelling Formats . . . . . . . . . . . . . . . . . . . . 20
5.1.1. tuneling Impacts on Transport and MTU . . . . . . . . 22 5.1.1. tunnelling Impacts on Transport and MTU . . . . . . . 22
5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 22 5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 23
5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 24 5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 25
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
6.2. IKE negotiation messages between the mobile node and 6.2. IKE negotiation messages between the mobile node and
Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 35 Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 35
skipping to change at page 8, line 35 skipping to change at page 8, line 35
3.1. Home Agent Address Discovery 3.1. Home Agent Address Discovery
Dynamic home agent Address Discovery (DHAAD) was defined in [RFC3775] Dynamic home agent Address Discovery (DHAAD) was defined in [RFC3775]
to allow mobile nodes to discover their home agents by appending a to allow mobile nodes to discover their home agents by appending a
well-known anycast interface identifier to their home link's prefix. well-known anycast interface identifier to their home link's prefix.
However, this mechanism is based on IPv6-anycast routing. If a However, this mechanism is based on IPv6-anycast routing. If a
mobile node is located in an IPv4-only foreign network, it cannot mobile node is located in an IPv4-only foreign network, it cannot
rely on native IPv6 routing. In this scenario, the solution for rely on native IPv6 routing. In this scenario, the solution for
discovering the home agent's IPv4 address is through the Domain Name discovering the home agent's IPv4 address is through the Domain Name
System (DNS). System (DNS). If the MN is attached to an IPv6-only or dual stack
network, it may also use procedures defined in
[I-D.ietf-mip6-bootstrapping-integrated-dhc] to discover home agent
information. Note that the use of
[I-D.ietf-mip6-bootstrapping-integrated-dhc] 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 this 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 [RFC5026] is For DNS lookup by service, the SRV record defined in [RFC5026] is
skipping to change at page 20, line 11 skipping to change at page 20, line 11
This flag indicates, when set, that the sender of the binding This flag indicates, when set, that the sender of the binding
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. Tunelling Formats
This specification allows the mobile node to use various tuneling This specification allows the mobile node to use various tunnelling
formats depending on its location and the visited network's formats depending on its location and the visited network's
capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6
or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this
specification also supports tuneling IPv6 in IPv6. specification also supports tunnelling IPv6 in IPv6.
This specification allows UDP-based tuneling to be used between the This specification allows UDP-based tunnelling to be used between the
mobile node and its home agent or MAP using either vanilla UDP mobile node and its home agent or MAP 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)
skipping to change at page 20, line 41 skipping to change at page 20, line 41
When using this format the receiver would parse the version field When using this format the receiver would parse the version field
following the UDP header in order to determine whether the following following the UDP header in order to determine whether the following
header is IPv4 or IPv6. The rest of the headers are processed header is IPv4 or IPv6. The rest of the headers are processed
normally. The above order of headers does not take IPsec headers normally. The above order of headers does not take IPsec headers
into account as they may be placed in different parts of the packet. into account as they may be placed in different parts of the packet.
The above format MUST be supported by all implementations of this The above format MUST be supported by all implementations of this
specification and MUST always be used to send the binding update specification and MUST always be used to send the binding update
message. message.
Vanilla UDP Tunnelling can also encapsulate an ESP header as shown
below.
IPv4
UDP
ESP
IP (v4 or v6)
Other headers
The negotiation of the secure tunnel format described above is
discussed in Section 6.2. The receiver of a vanilla UDP tunnel
detects whether an ESP header is present or not based on the UDP port
used.
TLV-header UDP encapsulation is represented by the following order of TLV-header UDP encapsulation is represented by the following order of
headers: headers:
IP (v4 or v6) IP (v4 or v6)
UDP UDP
TLV-header TLV-header
Other headers Other headers
skipping to change at page 21, line 13 skipping to change at page 21, line 32
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 tuneling payload traffic The mobile node negotiates the format for tunnelling 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 tuneling format. To avoid interoperability may renegotiate the tunnelling 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 4 skipping to change at page 22, line 24
This field indicates the type of the payload following this This field indicates the type of the payload following this
header. header.
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 the future: be assigned in the future:
1 GRE 1 GRE
In addition to UDP-based tuneling, this specification allows for In addition to UDP-based tunnelling, this specification allows for
standard IP in IP tuneling as defined in [RFC2473] and [RFC4213]. standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213].
This can take place by tuneling IPv4 in IPv6 or IPv6 in IPv4. This can take place by tunnelling IPv4 in IPv6 or IPv6 in IPv4.
However, whenever a NAT is detected, the mobile node will default to 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. tuneling Impacts on Transport and MTU 5.1.1. tunnelling Impacts on Transport and MTU
Changing the tunnel format may occur due to movement of the mobile Changing the tunnel format may occur due to movement of the mobile
node from one network to another. This can have impacts on the link node from one network to another. This can have impacts on the link
and path MTU, which may affect the amount of bandwidth available to and path MTU, which may affect the amount of bandwidth available to
the applications. 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 accommodate 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].
skipping to change at page 35, line 39 skipping to change at page 35, line 39
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 tuneling network. When connected to an IPv6-enabled network, the tunnelling
formats are clear. However, when connected to an IPv4-only network, formats are clear. However, when connected to an IPv4-only network,
care should be taken when negotiating the IKE association and the care should be taken when negotiating the IKE association and the
consequential tuneling formats used for secure and insecure traffic. consequential tunnelling formats used for secure and insecure
This section illustrates the IKE message exchange between the mobile traffic. This section illustrates the IKE message exchange between
node and home agent when the mobile node is located in an IPv4-only the mobile node and home agent when the mobile node is located in an
network. Two different IKE negotiations are considered: IPv4-only network. Two different IKE negotiations are considered:
o IKEv2 operation for securing DSMIPv6 Signaling. o IKEv2 operation for securing DSMIPv6 Signaling.
o IKEv2 operation for securing Data over IPv4 o IKEv2 operation for securing Data over IPv4
6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling 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 44, line 35 skipping to change at page 44, line 35
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
10.2. Informative 10.2. Informative
[I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519, Network Address Translation (NAT) Devices", RFC 3519,
April 2003. April 2003.
 End of changes. 20 change blocks. 
26 lines changed or deleted 59 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/