MEXT Working Group D.Premec Internet Draft Nokia Siemens Networks Intended status: Informational March 9, 2009 Expires: September 2009 Extended Home Link Support for DSMIPv6 draft-premec-mext-extended-home-link-01.txt 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 September 9, 2009. 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Premec Expires September 9, 2009 [Page 1] Internet-Draft Extended DSMIP6 home link support March 2009 Abstract Mobile IPv6 Support for Dual Stack Hosts and Routers allows the mobile node to maintain connectivity for its IPv6 home address while attached to the IPv4-only home link. This document specifies how a mobile node can maintain connectivity for its IPv4 home address while attached to an IPv6-only home link. Conventions used in this document 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...................................................2 2. Terminology....................................................3 3. Example deployment configurations..............................3 4. Solution Overview..............................................6 4.1. Registration process on the home link.....................6 4.2. Registration process on the PMIPv6 emulated home link.....8 5. Protocol Operation............................................10 5.1. MN Considerations........................................10 5.2. HA/LMA Considerations....................................10 5.3. MAG Considerations.......................................11 6. Security Considerations.......................................11 7. IANA Considerations...........................................11 8. Acknowledgments...............................................12 9. References....................................................12 9.1. Normative References.....................................12 9.2. Informative References...................................12 Author's Addresses...............................................13 1. Introduction In some deployments of the Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIP6) [Sol2008] there may be a need for the IPv6-only home link while at the same time allowing the MN attached to its IPv6-only home link to communicate with IPv4 peers. The operator's Premec Expires September 9, 2009 [Page 2] Internet-Draft Extended DSMIP6 home link support March 2009 decision to offer only IPv6 service on the home link can be a result of the shortage of the public IPv4 addresses or because the operator wants to save the additional costs of operating a dual stack network. DSMIP6 [Sol2008] does not allow the MN to maintain a binding with the HA for its IPv4 home address while being attached to the IPv6-only home link. This document specifies protocol semantics to allow the DSMIP6 protocol to support the usage of the IPv4 home address from the IPv6-only home link. 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. In such configuration there is no tunneling overhead for the IPv6 traffic and the MN is able to tunnel IPv4 datagrams using the IPv4 home address over the IPv6 home address. Section 3 of this specification discusses the envisioned deployment scenarios in more detail. Section 4 describes how a DSMIP6-enabled MN that is attached to a foreign network returns to the IPv6-only home link while maintaining the IPv4 connectivity. Section 5 provides detailed requirements for MN and HA/LMA. 2. Terminology General mobility related terminology is defined in [RFC3775]. DSMIP6 related terminology is described in [Sol2008]. Additional PMIPv6 specific terminology can be found in [RFC5213]. DSMIP6 Dual Stack Mobile IPv6 protocol is specified in [Sol2008]. PMIPv6 domain Network providing the network based IP mobility service as defined in [RFC5213]. PMIPv6 Proxy Mobile IPv6 protocol specified in [RFC5213]. 3. Example deployment configurations This section describes some example scenarios where a MN's home link provides only IPv6 connectivity. In one scenario the HA is co-located Premec Expires September 9, 2009 [Page 3] Internet-Draft Extended DSMIP6 home link support March 2009 with the default router, and the MN's home link is configured to support only the IPv6. However, the HA has connectivity to both IPv4 and IPv6 internet on its northbound interface. Since the HA is a full fledged DSMIP6 HA, it can provide IPv4 home address and IPv4 connectivity service to the MN. In this case the IPv4 home link appears as a virtual home link to the MN and the MN tunnels the IPv4 datagrams via its on-link IPv6 address to the HA. As the MN is IPv6- wise at home, there is no tunnel overhead for the IPv6 traffic. This configuration is shown in the figure 1: IPv4/IPv6 internet | | +---+----+ | HA | +--------+ | | IPv6 link | +--+---+ | MN | +------+ Figure 1 Home link supports only IPv6 Figure 2 illustrates a configuration where the network uses PMIPv6 [RFC5213] to emulate the MN's home link. The network consists of several access networks (AN) of different types and some of the access networks are able to carry only IPv6 datagrams. Premec Expires September 9, 2009 [Page 4] Internet-Draft Extended DSMIP6 home link support March 2009 IPv4/IPv6 internet | | +--------+ | HA/LMA | +--------+ / \ / \ / \ / \ / \ --------------/-----+ +--\------------- AN1 / ) ( \ AN2 +-----+ ) ( +-----+ IPv4 & | MAG | ) ( | MAG | IPv6 IPv6 +-----+ ) ( +-----+ only \ ) ( ---------------\----+ +---------------- \ \ \ \ \ +------+ | MN | +------+ Figure 2 PMIPv6 domain with IPv6-only access networks In the figure 2 the home network consists of the access network AN1 and the HA/LMA. Home network is fully capable dual stack network. The HA/LMA located in the core network is connected to the IPv4/IPv6 internet. The complete transport path from the MN through the access network AN1 to the HA/LMA supports native IPv6 and IPv4 connectivity. In addition to the native access network AN1, there could be several other access networks that connect to the MN's core network. Some of those additional access networks may support only IPv6 on the interface facing the MN. In addition, those access networks may be interconnected to the MN's core network by means of PMIPv6 protocol [RFC5213]. In this case, PMIPv6 is used to emulate the MN's home link while the MN is attached through the non-native access network. In the figure 2 the access network AN2 provides only IPv6 connectivity. When the MN attaches through AN2, its only on-link address is its IPv6 home address emulated by PMIPv6 and any IPv4 traffic must be tunneled by the MN to the HA/LMA via a DSMIP6 tunnel. Premec Expires September 9, 2009 [Page 5] Internet-Draft Extended DSMIP6 home link support March 2009 4. Solution Overview This document enhances the DSMIP6 protocol [Sol2008] to allow a MN that is attached to its home link to register its IPv6 on-link home address as a care-of address for its IPv4 home address. As a result there is no tunnel overhead for the traffic using the MN's IPv6 on- link home address and the MN is able to obtain connectivity for its IPv4 home address by tunneling the packets via its IPv6 home address. This specification does not introduce any new protocol elements to the DSMIP6 protocol, instead it defines an additional semantics for some specific combinations of the home address and care-of address options. 4.1. 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 DSMIP6, already made a registration with the HA for both of its home addresses. When the MN returns home to an IPv6-only home network, the MN sends the following packet in order to register its on-link IPv6 address as the care-of address for the IPv4 home address. The usage of the alternate care-of address option 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) 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 Premec Expires September 9, 2009 [Page 6] Internet-Draft Extended DSMIP6 home link support March 2009 Mobility Header type = 6 (Binding Acknowledgement) 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 RFC 3775 section 9.5, the home agent when processing the binding update will determine the specified care-of address 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. Further it will determine the home address to be the source address of the IPv6 header, i.e. v6HoA. With this input, the home agent will conclude the binding update is a deregistration, even if lifetime is non-zero. When a DSMIP6 home agent detects a deregistration of the IPv6 home address, it releases the entries for both the IPv6 and IPv4 home addresses. Therefore, this draft changes the normal semantics of deletion of an entry in the binding cache as it requires that only the IPv6 entry is removed. Another point relates to the deregistration of the IPv4 home address from the IPv6-only home link. Suppose the mobile node has installed the entry v4HoA -> v6HoA in the binding cache. Assume the mobile node no longer wants IPv4 connectivity, and wants to clear the cache entry. The mobile node will clear the entry by sending, see DSMIP section 5.4.2.1, a binding update message with a lifetime of zero. This message is sent using v6HoA as source address. However, the binding cache has no v6HoA entry. This means the entry in the binding cache cannot be found and cleared. One way to resolve this is to mandate that the mobile node includes the IPv4 home address as part of the de-registration Binding Update message which is then used by the home agent to locate the corresponding binding cache entry. Another way to resolve this is to ensure the home agent maintains a dummy entry for the v6HoA, such that the binding cache reads: v6HoA -> v6HoA v4HoA -> v6HoA Premec Expires September 9, 2009 [Page 7] Internet-Draft Extended DSMIP6 home link support March 2009 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.5 of [Wak2009]. The packet exchanges above used 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 it is attached to the native dual stack home network, and discovers that the native IPv4 connectivity no longer works. When later the MN discovers that IPv4 service is again available, the MN sends a BU with lifetime set to zero. 4.2. Registration process on the PMIPv6 emulated home link Detailed description of interworking scenarios between PMIP and Mobile IPv6, related issues and solution approaches is provided in [Gia2008]. This section analyses a specific scenario where the BCE for IPv6 home address is under the control of a MAG while the BCE for the IPv4 home address is updated by the MN. Note that such scenario where the IPv4 home address is under the control of a MN while IPv6 home address is controlled by the MAG is not considered in [Gia2008]. We start with the same set of assumptions regarding the MN's current location and the registration state with the HA as in section 4.1. The difference is that the MN's home link is emulated by the PMIPv6 protocol and the LMA is collocated with the MN's HA. We assume that the link between the MAG and the LMA supports IPv6 (it could be IPv4 as well, the link type between the MAG and the LMA does not affect the discussion presented here). In addition, the MAG is configured with: v6PCoA proxy care-of address of the MAG Since the LMA is collocated with the HA, we shall use the v6HA as the addresses of the LMA. Upon the MN's attachment to the PMIPv6 emulated IPv6-only home link, the MAG sends the following packet to the LMA: IPv6 header (src=v6PCoA, dst=v6HA) Mobility header type = 5 (Binding Update, P flag set) lifetime non-zero Home Network Prefix option (::) MN Identifier option (MN-NAI) Handoff Indicator option = 1 (attach. over a new interface) Premec Expires September 9, 2009 [Page 8] Internet-Draft Extended DSMIP6 home link support March 2009 Access Technology Type option When the LMA receives the Proxy BU message it checks if there is an active binding for the MN's IPv6 home address that was created by the MN itself. If there is no such binding, the LMA processes the PBU message as per [RFC5213]. If the binding that was created by the MN is found, the HA/LMA creates a new BCE in response to the PBU and marks it as a shadow BCE. The IPv6 home address in the shadow BCE is the same as the IPv6 home address in the active BCE that was created by the MN. The LMA responds to the MAG in the same way as if it had created a regular (non-shadow) BCE. As long as there is an active BCE that was created by the MN, the shadow BCE remains inactive and is not used to deliver the packets to the MN. This results in the following binding cache entries: V4HoA -> v6CoA updated by the MN v6HoA -> v6CoA updated by the MN v6HoA -> v6PCoA shadow, crated by the MAG The LMA responds to the MAG with: IPv6 header (src=v6HA, dst=v6PCoA) Mobility header type = 6 (Binding Acknowledgement, P flag set) lifetime non-zero MN Identifier option (MN-NAI) Handoff Indicator option = 1 (attach. over a new interface) Access Technology Type option Home Network Prefix option (HNP) Having acquired the MN's home network prefix, the MAG advertises it to the MN. When the MN detects that it is IPv6-wise at its home link, it deregisters the binding for its IPv6 home address while at the same time registering the IPv6 home address as the care-of address for its IPv4 home address as described in section 4.1. Upon deregistration of the IPv6 home address by the MN the LMA activates the shadow BCE. The resulting binding cache entries look like this: V4HoA -> v6HoA updated by the MN v6HoA -> v6PCoA updated by the MAG The MN's IPv6 traffic is tunneled between the MAG and the LMA in the PMIPv6 tunnel. The MN's IPv4 traffic is double tunneled: first by the MN to its v6HoA and then via the PMIPv6 tunnel to the v6HA. Premec Expires September 9, 2009 [Page 9] Internet-Draft Extended DSMIP6 home link support March 2009 Note that different lifetimes may be associated with the binding cache entries holding the v6HoA and the v4HoA. 5. Protocol Operation This specification does not make any changes to the Mobile IP message format, but it does introduce new semantics for the BU message. If the lifetime in the BU message is non-zero, the IPv6 home address in BU message is the same as the IPv6 care-of address and the IPv4 home address option is also included, then the HA updates the BCE for the IPv4 home address to include the IPv6 home address as the care-of address. At the same time the BCE for the IPv6 home address is deprecated. 5.1. MN Considerations When a DSMIP6-enabled MN is connected to an IPv6-only home link, it MAY register its IPv6 home address as the care-of address for its IPv4 home address by including the IPv4 Home address option in the BU message and setting the care-of address in the BU message to its IPv6 home address. In this case the MN SHALL tunnel any IPv4 traffic sourced from the IPv4 home address via its IPv6 home address to the HA. If the MN registered its IPv6 home address as a care-of address for its IPv4 home address, the MN SHALL maintain a BU list entry for the IPv4 home address containing the IPv6 home address as the care-of address. 5.2. HA/LMA Considerations If the MN's current care-of address as received in the BU message equals the MN's IPv6 home address, the HA SHALL deprecate the BCE for the IPv6 home address. If the IPv4 home address was included in the same BU message and the lifetime filed is non-zero, the HA SHALL update the BCE for the IPv4 home address as per [Sol2008]. When the MN registers its IPv6 home address as a care-of address for the IPv4 home address, the HA/LMA SHALL intercept the traffic destined to the MN's IPv4 home address and tunnel it to the MN's IPv6 home address. In case when there is a Proxy BCE for the MN's IPv6 home addresses, the IPv4 traffic will be double tunneled: first to the MN's IPv6 home address and then to the proxy care-of address of the MAG. 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 Premec Expires September 9, 2009 [Page 10] Internet-Draft Extended DSMIP6 home link support March 2009 IPv6 and IPv4 BCEs. If no IPv6 BCE was found, but the BU message contains the IPv4 home address, the HA SHALL use the IPv4 home address from the BU message to locate the corresponding IPv4 BCE and release it. When the LMA receives the Proxy BU message for the MN and if there is an active binding that was created by the MN for the same home address as requested in the PBU, the HA/LMA creates a new BCE based on the PBU message and marks it as a shadow BCE. The home address in the shadow BCE is copied over from the existing BCE. The LMA responds to the MAG in the same way as if it had created a regular (non- shadow) BCE. As long as there is an active BCE that was created by the MN, the shadow BCE remains inactive. The LMA SHALL activate the shadow BCE when it deprecates the corresponding BCE that is updated by the MN. As a general consideration, the HA/LMA SHALL NOT delete the BCE immediately upon processing of a deregistration message, instead, the HA/LMA SHALL mark the BCE as deprecated and start the MinDelayBeforeBCEDelete timer as described in [RFC5213]. This allows the HA/LMA to assign the same home address (from the deprecated BCE) in cases where the deregistration message is received before the registration. The HA/LMA SHALL delete the deprecated BCE after the timer expiry. This consideration applies to both deregistration messages sent by the MAG as well as to deregistration messages sent by the MN. 5.3. MAG Considerations If MAG does not support IPv4 service on the interface facing the MN, the MAG SHALL NOT include the IPv4 home address option in the Proxy BU message. 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 None. Premec Expires September 9, 2009 [Page 11] Internet-Draft Extended DSMIP6 home link support March 2009 8. Acknowledgments The author would like to thank Christian Kaas-Petersen for a detailed review and contributions to this document. This document was prepared using 2-Word-v2.0.template.dot. 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. [Sol2008] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-09.txt, July 2008 (work in progress) [RFC3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Ed., "Proxy Mobile IPv6", RFC 5213, August 2008 9.2. Informative References [Gia2008] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip- interactions-02, November 2007, (work in progress) [Wak2009] R. Wakikawa, V. Devarapalli, T. Ernst, and K. Nagami., Multiple care-of addresses registration, draft-ietf- monami6-multiplecoa-12.txt, January 2009, (work in progress) Premec Expires September 9, 2009 [Page 12] Internet-Draft Extended DSMIP6 home link support March 2009 Author's Addresses Domagoj Premec Nokia Siemens Networks Heinzelova 70a 10000 Zagreb Croatia Email: domagoj.premec.ext@nsn.com Premec Expires September 9, 2009 [Page 13]