| 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 April 11, 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 a "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 a way similar to the Scenario C
from [I‑D.ietf‑netlmm‑mip‑interactions] (Giaretta, G., “Interactions between PMIPv6 and MIPv6: scenarios and related issues,” June 2009.), where the
non-PMIPv6 domain to which the MN roams can be a different PMIPv6 domain
that handles a different MN_HoA; in this case, the MN would receive 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, 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.
Figure 1 (Example of Home Links (HL) Types provided by a DSMIPv6 HA) illustrate some of these examples:
.--.
_(. `)
_( IPv4/6`)_
( Internet `)
( ` . ) )
`--(_______)--'
|
|
|
IPv6-only HL +----+----+ Dual Stack HL
---------------|DSMIP6 HA|--------------
IF1 +---------+ IF2
| GW |
| eg. GGSN|
+---------+
| IF3
|<-------------IPv6 Virtual HL
|
(--------|------)
( | )
( Radio | NW )
(--------|------)
|
|
+-------+
| DS MN |
+-------+
| Figure 1: Example of Home Links (HL) Types provided by a DSMIPv6 HA |
As seen on Figure 1 (Example of Home Links (HL) Types provided by a DSMIPv6 HA), if the attaches to its home link which is dual stack, eg interface IF2, the procedures described in [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) handle the deregistration and are sufficient. However, if the MN returns through either the IPv6-only (IF1) or IPv6 "virtual" (IF3) home links, 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 link associated with an HA, which may be physical or virtual, and is considered by an MN as its home link, which supports IPv6 only.
| 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 in the Binding Update (BU) message for the situation where the MN does need to register an IPv4 HoA with 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 HA cannot remove IPv6 binding while maintaining the IPv4 binding, the MN may or may not include the IPv4 HoA (which is optional) in the BU message. Once the HA receives this BU message and determines that it is a de-registration (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 needs 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.), one possibility is to send another BU message to register the IPv4 HoA after receiving the Binding Acknowledgement (BAck) message for the previous IPv6 de-registration event. However, this creates a gap in the provisioning of IPv4 service between the two BU messages 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. In fact, the transport layer connections would most probably be dropped due to the event of IPv6 CoA de-registration. Therefore, the registration of the IPv4 HoA after the initial BU message for de-registering the IPv6 HoA would not ensure "seamless handovers". Given that there are 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. As shown on Figure 2 (Dual Stack Deployment with IPv6-only Home Link),
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, while the HA has connectivity to
IPv4/IPv6 Internet on its outbound interface.
.--.
_(. `)
_( IPv4/6`)_
( Internet `)
( ` . ) )
`--(_______)--'
|
| IPv4/6 link
|
+----+----+
|DSMIP6 HA|
+---------+
|
| IPv6 access link
|
+--+--+
| MN |
+-----+
| Figure 2: Dual Stack Deployment with IPv6-only Home Link |
Since the HA in the example shown on Figure 2 (Dual Stack Deployment with IPv6-only Home Link) 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, from an IPv6 perspective the MN is on its home link and hence there is no tunnelling of IPv6 packets.
| TOC |
The following sections describe the solution to overcome the problem when the MN attaches to an IPv6 only home link with additional information in the Binding Update (BU) and Binding Acknowledgement (BAck) messages. 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 3: 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. The presence of the flag (X) on the BU message, independently from the Lifetime being non-zero or not, automatically causes the de-registration of the IPv6 HoA, as it is discussed later on this document (see Section 5.3 (Registration Process on the Home Link)).
| 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 4: 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.).
| 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 IPv6 home address as the CoA to the IPv4 home address. 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 |
The security aspects and implications associated with [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) are applicable to this document. This document also 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 |
This document specifies a new flag (X) in the Binding Update (BU) and Binding Acknowledgement (BAck) messages of DSMIPv6 [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.). This flag is defined in sections Section 5.1 (Binding Update Extensions) and Section 5.2 (Binding Acknowledgment Extensions). IANA is requested to allocate the 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). |
| [I-D.ietf-netlmm-mip-interactions] | Giaretta, G., “Interactions between PMIPv6 and MIPv6: scenarios and related issues,” draft-ietf-netlmm-mip-interactions-04 (work in progress), June 2009 (TXT). |
| TOC |
| Fuad Abinader (editor) | |
| Nokia Institute of Technology | |
| Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova | |
| Manaus, AM 69048-660 | |
| BRAZIL | |
| Email: | fabinader@gmail.com |
| Domagoj Premec | |
| Unaffiliated | |
| Email: | domagoj.premec@gmail.com |
| Jouni Korhonen | |
| Nokia Siemens Networks | |
| Linnoitustie 6 | |
| Espoo, FI-02600 | |
| FINLAND | |
| Email: | jouni.nospam@gmail.com |