MEXT Working Group D. Premec Internet-Draft Intended status: Standards Track J. Korhonen, Ed. Expires: January 14, 2010 Nokia Siemens Networks July 13, 2009 IPv4 Support for DSMIPv6 IPv6 Home Link draft-premec-mext-extended-home-link-02 Status of this Memo 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 January 14, 2010. Copyright Notice 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. Abstract Mobile IPv6 Support for Dual Stack Hosts and Routers allows the mobile node to maintain connectivity for its IPv6 home address while Premec & Korhonen Expires January 14, 2010 [Page 1] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 attached to the IPv4-only links. This document specifies how a mobile node can maintain connectivity for its IPv4 home address while attached to an IPv6 home link. Requirements Language 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Example Deployment Configuration . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 5 4.2. Binding Acknowledgment Extensions . . . . . . . . . . . . 5 4.3. Registration Process on the Home Link . . . . . . . . . . 6 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 8 5.2. Home Agent Considerations . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Premec & Korhonen Expires January 14, 2010 [Page 2] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 1. Introduction In some deployments of the Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6) [RFC5555] there may be IPv6-only access links that are also appear to a mobile nodes (MN) as their home link. A particular example is a 2G/3G GPRS [3GPP.23.060] access where it is possible to provide IPv6-only access although the MN can be dual stack and the gateway terminating the access links can also be dual stack. From now on we refer this kind of deployment as "IPv6-only home link" while we acknowledge it is not the best description of the deployment scenario. When the MN is on its "IPv6-only home link" that does not imply the IPv4 Home Address (HoA) assigned to the MN is also conceptually on MN's home link. Furthermore, there might not be other way to forward IPv4 traffic to the MN than tunnel them from the home agent (HA) over the IPv6-only access link to the MN. 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 the DSMIPv6 binding to be able to send and receive IPv4 traffic. DSMIPv6 does not allow the MN to maintain a binding with the HA for its IPv4 HoA while being attached to the home link from IPv6 point of view, as stated in Section 4.4.2.1 of [RFC5555]. This document extends the DSMIP6 protocol to allow usage of the IPv4 HoA from the IPv6-only access link that also appear as the "IPv6 home link" to the MN. A MN attached to an "IPv6-only home link" is allowed to register its IPv6 home address as a care-of address for its IPv4 home address while at the same time de-registering the IPv6 binding. In such configuration there is no tunneling overhead for the IPv6 traffic and the MN is able to tunnel IPv4 traffic using the IPv4 HoA over the IPv6 access link. Section Section 3 of this specification discusses the envisioned deployment scenarios in more detail. Section Section 4 describes how a DSMIPv6-enabled MN that is attached to a foreign network returns to the "IPv6-only home link" while maintaining the IPv4 connectivity. Section Section 5 provides detailed requirements for MN and HA. 2. Terminology General Mobile IPv6 related terminology is defined in [RFC3775]. DSMIPv6 related terminology is described in [RFC5555]. Premec & Korhonen Expires January 14, 2010 [Page 3] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 IPv6-only Home Link A deployment where a dual stack mobile node is attached to an access link that is only able to provide IPv6 transport and that access link also appear to the mobile node as its Mobile IPv6 home link. The gateway (most likely collocated with a home agent functionality) terminating the IPv6-only access link is dual stack internally and connected to the IPv4/IPv6 Internet. 3. Example Deployment Configuration 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 northbound 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. As the MN is IPv6- wise at home, there is no tunnel overhead for the IPv6 traffic. This configuration is shown in Figure 1. .--. _(. `) _( IPv4/6`)_ ( Internet `) ( ` . ) ) `--(_______)--' | | IPv4/6 (home) link | +----+----+ |DSMIP6 HA| +---------+ | | IPv6 access link | +--+--+ | MN | +-----+ Figure 1: Dual Stack Deployment with IPv6-only Home Link Premec & Korhonen Expires January 14, 2010 [Page 4] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 4. Solution Overview Following sections describe how the Binding Update (BU) and the Binding Acknowledgement (BA) messages has to be updated in order to avoid complete binding de-registration 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] and in Sections 9.5. and 11.5.4. of [RFC3775]), would cause a de-registration of the whole binding including the IPv4 HoA. 4.1. Binding Update Extensions 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] and the HA MUST retain the binding for the IPv4 HoA. 4.2. Binding Acknowledgment Extensions This specification extends the BA message with a new 'X' flag. Premec & Korhonen Expires January 14, 2010 [Page 5] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 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 BA message to indicate that the HA has created the Binding Cache Entry (BCE) for the IPv4 HoA with the IPv6 HoA as the CoA. 4.3. Registration Process on the Home Link 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] while on the home link is optional and hence it may be omitted: Premec & Korhonen Expires January 14, 2010 [Page 6] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 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 appears obvious, the packet exchange modifies the normal semantics of bindings in two ways. First, according to [RFC3775] 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. Premec & Korhonen Expires January 14, 2010 [Page 7] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 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]. The packet exchanges used above for returning to an IPv6-only home link are also used when the MN boots on an 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, for some reason, the native IPv4 connectivity no longer works. When the that IPv4 connectivity later resumes and the MN discovers that by some means, the MN MAY remove the IPv4 HoA binding and use IPv4 natively (assuming it is acceptable for applications that the used IPv4 address may change). 5. Protocol Operation This specification introduces the new 'X' flag in the BU and BA 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 BA indicates that the HA successfully created the binding between the IPv4 HoA and the IPv6 HoA. 5.1. Mobile Node Considerations 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. 5.2. Home Agent Considerations 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 Premec & Korhonen Expires January 14, 2010 [Page 8] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 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 BA 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. 6. Security Considerations 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. 7. IANA Considerations 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. 8. Acknowledgements The authors would like to thank Christian Kaas-Petersen for a detailed review and contributions to this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Premec & Korhonen Expires January 14, 2010 [Page 9] Internet-Draft IPv4 Support for DSMIPv6 IPv6 Home Link July 2009 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. 9.2. Informative References [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. Authors' Addresses Domagoj Premec Email: domagoj.premec@gmail.com Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo, FI-02600 FINLAND Email: jouni.nospam@gmail.com Premec & Korhonen Expires January 14, 2010 [Page 10]