draft-ietf-mext-nemo-v4traversal-02.txt   draft-ietf-mext-nemo-v4traversal-03.txt 
MEXT Working Group H. Soliman, Ed. Network Working Group H. Soliman, Ed.
Internet-Draft Elevate Technologies Internet-Draft Elevate Technologies
Intended status: Standards Track April 29, 2008 Intended status: Standards Track May 25, 2008
Expires: October 31, 2008 Expires: November 26, 2008
Mobile IPv6 Support for Dual Stack Hosts and Routers Mobile IPv6 Support for Dual Stack Hosts and Routers
draft-ietf-mext-nemo-v4travesrsal-02.txt draft-ietf-mext-nemo-v4traversal-03.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 October 31, 2008. This Internet-Draft will expire on November 26, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . 13 3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 12
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. 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. Tunnelling 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
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). If the MN is attached to an IPv6-only or dual stack System (DNS).
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 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. 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 tunnelling
formats depending on its location and the visited networ's formats depending on its location and the visited networ's
capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6
or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this
specification also supports tunnelling IPv6 in IPv6. specification also supports tunnelling IPv6 in IPv6.
This speacification allows two different types of UDP-based This speacification allows UDP-based tunnelling to be used between
tunnelling formats to be used between the mobile node and its home the mobile node and its home agent or MAP using either vanilla UDP
agent or MAP. The two formats are vanilla UDP encapsulation and TLV- encapsulation or TLV- header UDP encapsulation. A vanilla UDP
header UDP encapsulation. A vanilla UDP encapsulation format means encapsulation format means the following order of headers:
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
skipping to change at page 22, line 12 skipping to change at page 22, line 12
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 future:
1 GRE 1 GRE
In addition to the UDP-based tunnelling formats described above, this In addition to UDP-based tunnelling, this specification allows for
specification allows for standard IP in IP tunnelling. This can take standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213].
place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. However, whenever This can take place by tunnelling IPv4 in IPv6 or IPv6 in IPv4.
a NAT a detected, the mobile node will default to UDP-based However, whenever a NAT is detected, the mobile node will default to
encapsulation. The mobile node can request to always use UDP UDP-based encapsulation. The mobile node can request to always use
encapsulation by setting the F flag in the binding update. If the UDP encapsulation by setting the F flag in the binding update. If
home agent does not agree to the request, it MUST reject the binding the home agent does not agree to the request, it MUST reject the
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. 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
skipping to change at page 28, line 9 skipping to change at page 28, line 9
mobile node and the home agent, or if the home agent forced UDP mobile node and the home agent, or if the home agent forced UDP
encapsulation. encapsulation.
If the mobile node 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. These triggers would not be available in an IPv4-only triggers and Neighbor Discovery [RFC4861] information. These
network. Hence, a mobile node located in an IPv4-only network SHOULD triggers would not be available in an IPv4-only network. Hence, a
use [RFC4436] for guidance on movement detection mechanisms in IPv4- mobile node located in an IPv4-only network SHOULD use [RFC4436] for
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
acknowledgement. acknowledgement.
skipping to change at page 33, line 30 skipping to change at page 33, line 30
deregister its binding with each correspondent node by sending a deregister its binding with each correspondent node by sending a
deregistration binding update. The deregistration binding update deregistration binding update. The deregistration binding update
message is tunnelled to the home agent and onto the correspondent message is tunnelled to the home agent and onto the correspondent
node. This is done after the mobile node updates the home agent with node. This is done after the mobile node updates the home agent with
its new location as discussed below. its new location as discussed below.
The mobile node sends the binding update message to the home agent. The mobile node sends the binding update message to the home agent.
If the mobile node is in an IPv6-enabled network, the binding update If the mobile node is in an IPv6-enabled network, the binding update
is sent without IPv4/UDP encapsulation. If the mobile node is in an is sent without IPv4/UDP encapsulation. If the mobile node is in an
IPv4-only network, then after IPsec processing of the BU message, it IPv4-only network, then after IPsec processing of the BU message, it
encapsulates the BU in UDP/IPv4 as discussed in sections 4.2 and 4.4. encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4.
In order to be able to send the binding update while in an IPv4-only In order to be able to send the binding update while in an IPv4-only
network, the mobile node needs to use the new IPv4 care-of address in network, the mobile node needs to use the new IPv4 care-of address in
the outer header, which is different from the care-of address used in the outer header, which is different from the care-of address used in
the existing tunnel. This should be done without permanently the existing tunnel. This should be done without permanently
updating the tunnel within the mobile node's implementation in order updating the tunnel within the mobile node's implementation in order
to allow the mobile node to receive packets on the old care-of to allow the mobile node to receive packets on the old care-of
address until the binding acknowledgement is received. The method address until the binding acknowledgement is received. The method
used to achieve this effect is implementation dependent and is used to achieve this effect is implementation dependent and is
outside the scope of this specification. This implies that the IP outside the scope of this specification. This implies that the IP
forwarding function (which selects the interface or tunnel through forwarding function (which selects the interface or tunnel through
skipping to change at page 35, line 17 skipping to change at page 35, line 17
for encapsulating traffic to the mobile node. for encapsulating traffic to the mobile node.
After successfully processing the binding update, the home agent After successfully processing the binding update, the home agent
sends the binding acknowledgement to the mobile node's care-of sends the binding acknowledgement to the mobile node's care-of
address as received in the outer header of the packet containing the address as received in the outer header of the packet containing the
binding update. Note that if the BU was rejected, the BAck is sent binding update. Note that if the BU was rejected, the 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 home agent's tunnel header IP source address, which is the the mobile node's
address and the tunnel header IP destination, which is the mobile address and the tunnel header IP destination, which is the home
node's care-of address. The mobile node may also need to enable or agent's address. The mobile node may also need to enable or disable
disable UDP encapsulation for outgoing ESP packets for the purpose of UDP encapsulation for outgoing ESP packets for the purpose of NAT
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.
skipping to change at page 43, line 48 skipping to change at page 43, line 48
1. The IANA should allocate and permanently register new TLV-header 1. The IANA should allocate and permanently register new TLV-header
types and Status field values from IETF RFC publication. This is types and Status field values from IETF RFC publication. This is
for all RFC types including standards track, informational, and for all RFC types including standards track, informational, and
experimental status that originate from the IETF and have been experimental status that originate from the IETF and have been
approved by the IESG for publication. approved by the IESG for publication.
2. Requests for new option type value assignments from outside the 2. Requests for new option type value assignments from outside the
IETF are only made through the publication of an IETF document, IETF are only made through the publication of an IETF document,
per 1) above. Note also that documents published as "RFC Editor per 1) above. Note also that documents published as "RFC Editor
contributions" [RFC3667] are not considered to be IETF documents. contributions" [RFC3978] are not considered to be IETF documents.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
Listener Discovery (MLD) for IPv6", RFC 2710, IPv6 Specification", RFC 2473, December 1998.
October 1999.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
skipping to change at page 44, line 45 skipping to change at page 44, line 44
[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,
May 2003. April 2003.
[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
February 2004. RFC 3978, March 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005. (HMIPv6)", RFC 4140, August 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006. Network Tunneling", RFC 4459, April 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual
Stack Mobility", RFC 4977, August 2007. Stack Mobility", RFC 4977, August 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
 End of changes. 19 change blocks. 
50 lines changed or deleted 38 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/