| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 24, 2010.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Mobile IPv6 for Dual Stack Hosts and Routers enables mobility for the mobile node's IPv6 home address or prefix as well as an IPv4 home address, irrespective of the IP version supported on the link that the mobile node is attached to. The home agent maintains binding cache entries for the IPv6 and IPv4 home addresses assigned to the mobile node when the mobile node is connected via a foreign link. The binding cache entries are deprecated when the mobile node attaches to its home link. This document addresses an issue related to the de-registration procedure and the continued connectivity for the IPv4 home address when the mobile node attaches to its IPv6-only home link.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
1.
Introduction
2.
Terminology
3.
Problem Statement
4.
Example Deployment Configuration
5.
Solution Overview
5.1.
Binding Update Extensions
5.2.
Binding Acknowledgment Extensions
5.3.
Registration Process on the Home Link
6.
Protocol Operation
6.1.
Mobile Node Considerations
6.2.
Home Agent Considerations
7.
Security Considerations
8.
IANA Considerations
9.
Acknowledgements
10.
References
10.1.
Normative References
10.2.
Informative References
§
Authors' Addresses
| TOC |
A Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) Home Agent (HA) may be deployed with some links that are considered by Mobile Nodes (MNs) as home links that are IPv6 only. A DSMIPv6 MN may attach to its home link via either a physical or virtual link. As an example, a DSMIPv6 MN may attach to a network which deploys Proxy Mobile IPv6 (PMIPv6) [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.), in which case the MN receives a Router Advertisement (RA) including the home-link prefix and hence would perceive to be connected to the home link. The DSMIPv6 MN may also be attached via a 2G/3G cellular network [3GPP.23.060] (3GPP, “General Packet Radio Service (GPRS); Service description; Stage 2,” June 2009.), in which case the link the MN is attached to can also be seen as the home link. In addition to the MN being attached to its HA via such virtual home links, the MN may also attach to its HA via a physical home link of the HA. The links in these examples may be in many cases IPv6 only. Below is an example of the types of home links provided by a DSMIPv6 HA:
.--.
_(. `)
_( IPv4/6`)_
( Internet `)
( ` . ) )
`--(_______)--'
|
|
|
IPv6 only HL +----+----+ DS HL
---------------|DSMIP6 HA|--------------
IF1 +---------+IF2
| GW |
| eg. GGSN|
+---------+
|
|<-------------IPv6 Virtual HL
|
(--------|------)
( | )
( Radio | NW )
(--------|------)
|
|
+------+
| DS MN|
+------+
In such scenarios, the provisioning of a "IPv6-only home link" for the MN does not imply that the IPv4 Home Address (HoA) assigned to the MN is also conceptually on the MN's home link. Furthermore, forwarding IPv4 traffic from the home agent (HA) to the MN might only be accomplished by tunneling it over the IPv6-only access link. This basically implies that there are situations where the MN is on its home link (from the IPv6 point of view), but must still retain a Binding Cache Entry (BCE) on the HA for the IPv4 HoA in order to be able to send and receive IPv4 traffic.
Since DSMIPv6 does not allow the MN to maintain a BCE for its IPv4 HoA while being attached to the home link from the IPv6 point of view (as stated in Section 4.4.2.1 of [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.)), this document extends the DSMIP6 protocol in order to allow the usage of the IPv4 HoA from an IPv6-only access link appearing as the "IPv6 home link" to the MN. By means of what is herein defined, a MN attached to an IPv6-only "home link" is allowed to register its own IPv6 HoA as a Care-of Address (CoA) for its IPv4 home address, while at the same time de-registering the IPv6 binding. In such scenario, there is no tunneling overhead for the IPv6 traffic, and the MN is able to tunnel IPv4 traffic using its IPv4 HoA over the IPv6-only access link.
Section 3 (Problem Statement) describes what occurs (as per the current DSMIPv6 specification [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.)) with the IPv4 HoA BCE that an MN registers on its HA while attached via a foreign network with support for IPv6, and then moves to an IPv6-only home link.
Section 4 (Example Deployment Configuration) of this specification discusses the envisioned deployment scenarios in more detail.
Section 5 (Solution Overview) describes how a DSMIPv6-enabled MN that is attached to a foreign network returns to the "IPv6-only home link" while maintaining IPv4 connectivity.
Section 6 (Protocol Operation) provides the details for the processing at the MN and HA
| TOC |
General Mobile IPv6 related terminology is defined in [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.). DSMIPv6 related terminology is described in [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.).
- IPv6-only Home Link
A deployment where a dual stack mobile node is attached to an access link that is IPv6 only and that link is viewed by the mobile node as its home link.
| TOC |
As stated in Section 4.4.2 of [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.), the presence of the IPv4 HoA Option is only mandatory on the BU message for the situation where the MN does need to register an IPv4 HoA on the HA, otherwise its presence in the BU message is optional. Section 4.4.2.1 of [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) also states that the MN cannot remove the IPv6 HoA BCE while maintaining an IPv4 HoA BCE. From these two statements, it can be concluded that the presence of the IPv4 HoA Option on the BU message that de-registers the IPv6 HoA on the HA when the MN returns to its home link is not mandatory, and that independently of the presence or absence of the IPv4 HoA in the BU message, the HA will remove all bindings (both IPv6 and IPv4) for the MN.
According to Section 2.3.1 of [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.), the HA for an MN which is attached via a foreign link and has been assigned an IPv6 HoA as well as an IPv4 HoA, contains a BCE which includes both the assigned HoAs pointing to the MN's IPv4 or IPv6 CoA, like those defined below:
v6HoA -> v6CoA
v4HoA -> v6CoA
Suppose now that the MN moves to an IPv6-only link which is viewed by the MN as its home link. After determining that it has returned to the home link, the first action the MN takes is to send a BU to its HA in order to de-register the IPv6 CoA on the HA. As the presence of the IPv4 HoA in the BU is optional, the MN may or may not include it in the BU message. Once the HA receives this BU message and determines that it is a de-regisitration (by either looking for equal source IPv6 address and IPv6 HoA Option values OR a lifetime of zero), all bindings for the mobile node will be removed. This will occur no matter if the Ipv4 HoA Option was present or not, as it was already stated that it is not allowed (by Section 4.4.2.1 of [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.)) to have an registered IPv4 HoA without a registered IPv6 HoA as well.
If for instance the MN wants to keep an IPv4 HoA BCE while at the home network, according to what is stated on [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.), the only possibility is to send another BU message to register the IPv4 HoA after receiving the Binding Acknowledgement (BAck) message for the preivous IPv6 de-registration event. This creates a gap in the provisioning of IPv4 sevice which does not allow "seamless handovers", as IPv4 packets may be discarded on the HA while in the gap period because of the lack of the BCE for the IPv4 HoA. Therefore, as there is no other mechanisms currently supported in [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) for keeping the IPv4 binding while roaming back to the IPv6-only network, there is a need for extending [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) in order to allow "seamless handovers" for IPv4.
| TOC |
This section describes an example scenario, where a MN's "home link" provides IPv6-only access. In this scenario the HA is collocated with the default router, and the MN's access link (i.e. the "home link" from the MN point of view) is configured to support only IPv6. However, the HA has connectivity to IPv4/IPv6 Internet on its outbound interface. Since the HA is a fully functional DSMIPv6 HA, it can provide IPv4 HoA and IPv4 connectivity service to the MN. In this case the IPv4 home link appears as a "virtual home link" to the MN (meaning the MN is always attached to a foreign link from the Mobile IP point of view) and the MN tunnels the IPv4 traffic via its on-link IPv6 address to the HA, and vice versa. However, as the MN is IPv6-wise at home, there is no tunnel overhead for the IPv6 traffic. This configuration is shown in Figure 1 (Dual Stack Deployment with IPv6-only Home Link).
.--.
_(. `)
_( IPv4/6`)_
( Internet `)
( ` . ) )
`--(_______)--'
|
| IPv4/6 (home) link
|
+----+----+
|DSMIP6 HA|
+---------+
|
| IPv6 access link
|
+--+--+
| MN |
+-----+
| Figure 1: Dual Stack Deployment with IPv6-only Home Link |
| TOC |
Following sections describe how the Binding Update (BU) and the Binding Acknowledgement (BAck) messages have to be updated in order to avoid complete binding de-registration of both IPv4 and IPv6 Home Addresses (HoA) when a MN attaches to an "IPv6-only home link". Currently when a MN attaches to its home link, as described in Section 4.4.2.1. of [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) and in Sections 9.5. and 11.5.4. of [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.)), this would cause a de-registration of all bindings for the Mobile Node (MN), including the IPv4 HoA.
| TOC |
This specification extends the Binding Update message with a new (X) flag.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|X| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 2: Binding Update Message |
Tunnel flag (X)
A new flag (X) is introduced in the Binding Update message to indicate a request to register the IPv6 HoA as the Care-of Address (CoA) for the IPv4 HoA. The MN MAY set this flag only when it sends a BU message from an IPv6-only link that appears as the Mobile IPv6 home link to the MN. If this flag is set, the BU message MUST also contain the IPv4 HoA option [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) and the HA MUST retain the binding for the IPv4 HoA.
| TOC |
This specification extends the BAck message with a new (X) flag.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T|X|Resv.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 3: Binding Acknowledgement Message |
Tunnel Flag (X)
A new flag (X) is included in the BAck message to indicate that the HA has created the Binding Cache Entry (BCE) for the IPv4 HoA with the IPv6 HoA as the CoA.
| TOC |
Assume a MN has been configured with the following three addresses:
v6HoA MN's IPv6 home address
v4HoA MN's IPv4 home address
v6HA HA's IPv6 address
and currently is located in an IPv6 foreign network using
v6CoA MN's IPv6 care-of address
The MN has, using DSMIPv6, already made a registration with the HA for both of its home addresses.
When the MN returns home to an IPv6-only home link, the MN sends the following packet in order to register its on-link IPv6 address as the CoA for the IPv4 HoA. The usage of the Alternate Care-of Address option [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) while on the home link is optional and hence it may be omitted:
IPv6 Header (src = v6HoA, dst = v6HA)
ESP Header
Mobility Header
type = 5 (Binding Update), X-flag=1
lifetime non-zero
[Alternate Care-of Address option (v6HoA)]
IPv4 Home Address option (v4HoA)
The HA sends the following response:
IPv6 Header (src = v6HA, dst = v6HoA)
ESP Header
Mobility Header
type = 6 (Binding Acknowledgement), X-flag=1
lifetime non-zero
IPv4 Address Acknowledgement option (v4HoA)
Although the packet exchange specified above seems obvious, the packet exchange modifies the normal semantics of bindings in two ways.
First, according to [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) Section 9.5, the HA when processing the BU will determine the specified CoA to be the address found in the Alternate Care-of Address option, i.e. v6HoA, or detect that the Alternate Care-of Address option was omitted. Furthermore, it will determine the HoA to be the source address of the IPv6 header, i.e. v6HoA. With this input, the HA will conclude the binding update is a de-registration, even if lifetime is non-zero. When a DSMIPv6 HA detects a de-registration of the IPv6 home address, it releases the entries for both the IPv6 and IPv4 HoAs. Therefore, the (X) flag introduced by this specification changes the normal semantics of deletion of a Binding Cache Entry (BCE) as it requires that only the IPv6 entry is removed.
Another point relates to the de-registration of the IPv4 HoA from the IPv6-only home link. Suppose the MN has installed the entry:
v4HoA -> v6HoA
in the Binding Cache (BE). Assume the MN no longer wants IPv4 connectivity, and wants to clear the BCE. The MN will clear the entry by sending a BU message with a lifetime of zero. This message is sent using v6HoA as source address. However, the BC has no v6HoA entry. This means the entry in the BCE cannot be found and cleared.
One way to resolve this is to mandate that the MN includes the IPv4 HoA as part of the de-registration BU message which is then used by the HA to locate the corresponding BCE.
Another way to resolve this is to ensure the HA maintains a dummy entry for the v6HoA, such that the BC reads:
v6HoA -> v6HoA
v4HoA -> v6HoA
Inserting such a dummy entry in order to bypass tunneling seems a substantial change of semantics. This is essentially the same as the concept of the home binding described in Section 5.6.3 of [I‑D.ietf‑monami6‑multiplecoa] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” May 2009.).
The packet exchanges used above for returning to an IPv6-only home link are also used when the MN boots on the IPv6-only home link, or when making a re-registration to extend the lifetime. They are also to be used when the MN is attached to the native dual stack home network, and discovers that the native IPv4 connectivity no longer works. When the MN later discovers that IPv4 service is again available, the MN sends a BU with lifetime set to zero. [ED: do not get this paragraph]
| TOC |
This specification introduces the new (X) flag in the BU and BAck messages. The (X) flag in the BU message indicates a request to bind the IPv4 home address to the IPv6 home address as the CoA. The (X) flag in BAck indicates that the HA successfully created the binding between the IPv4 HoA and the IPv6 HoA.
| TOC |
When a DSMIPv6-enabled MN is connected to an IPv6-only home link, it MAY register its IPv6 HoA as the CoA for its IPv4 HoA by setting the (X) flag in the BU message, including the IPv4 Home Address option and setting the CoA in the BU message to its IPv6 HoA. In this case the MN MUST tunnel any IPv4 traffic sourced from the IPv4 HoA via its IPv6 HoA to the HA.
If the MN registered its IPv6 HoA as the CoA for its IPv4 HoA, the MN MUST maintain a BU list entry for the IPv4 HoA containing the IPv6 HoA as the CoA.
| TOC |
If the MN's current CoA as received in the BU message equals the MN's IPv6 HoA, the HA MUST deprecate the BCE for the IPv6 HoA. If the (X) flag was set and the IPv4 HoA was included in the same BU message and the lifetime filed is non-zero, the HA MUST update the BCE for the IPv4 HoA with the IPv6 HoA as the CoA.
If the HA updated the IPv4 BCE with the IPv6 HoA as the CoA, it MUST set the (X) flag in the BAck message.
When the MN registers its IPv6 HoA as the CoA for the IPv4 HoA, the HA MUST intercept the traffic destined to the MN's IPv4 HoA and tunnel it to the MN's IPv6 HoA.
When the HA receives the BU that was sent from the "IPv6-only home link" and where the lifetime is set to zero, the HA releases both the IPv6 and IPv4 BCEs. If no IPv6 BCE was found, but the BU message contains the IPv4 HoA, the HA MUST use the IPv4 HoA from the BU message to locate the corresponding IPv4 BCE and release it.
| TOC |
This document recommends that the same level of security is applied to the packets sent natively to/from the MN's on-link home address and to the packets on the virtual home link that are tunneled to the MN's on-link home address.
| TOC |
IANA is requested to allocate a new flag (X) in the Binding Update and Binging Acknowledgement messages from the RFC3775 Binding Update Flags and the RFC3775 Binding Acknowledgment Flags registries.
| TOC |
The authors would like to thank Christian Kaas-Petersen for a detailed review and contributions to this document.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3775] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
| [RFC5213] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” RFC 5213, August 2008 (TXT). |
| [RFC5555] | Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” RFC 5555, June 2009 (TXT). |
| TOC |
| [3GPP.23.060] | 3GPP, “General Packet Radio Service (GPRS); Service description; Stage 2,” 3GPP TS 23.060 8.5.1, June 2009. |
| [I-D.ietf-monami6-multiplecoa] | Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” draft-ietf-monami6-multiplecoa-14 (work in progress), May 2009 (TXT). |
| TOC |
| Fuad Abinader (editor) | |
| Nokia Institute of Technology (INdT) | |
| Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova | |
| Manaus, AM 69048-660 | |
| BRAZIL | |
| Email: | fabinader@gmail.com |
| Domagoj Premec | |
| Email: | domagoj.premec@gmail.com |
| Jouni Korhonen | |
| Nokia Siemens Networks | |
| Linnoitustie 6 | |
| Espoo, FI-02600 | |
| FINLAND | |
| Email: | jouni.nospam@gmail.com |