Mobility Extensions for IPv6 (MEXT) G. Hampel Internet Draft T. Klein Intended status: Standards Track Alcatel-Lucent Expires: September 27, 2011 Feb 23, 2011 Mobile IPv6 Route Optimization without Home Agent draft-hampel-mext-ro-without-ha-00 Abstract This document describes extensions to Mobile IPv6 (MIPv6), which permit hosts to conduct route optimization (RO) without home agent. These extensions add robustness and flexibility to MIPv6 since mobility can be supported when the home agent becomes temporarily unavailable or when home-agent support is not desirable. These extensions are compliant with all peer-to-peer signaling solutions that are currently supported for RO. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 27, 2011. Hampel et al. Expires September 27, 2011 [Page 1] Internet-Draft Route Optimization without Home Agent Feb 2011 Copyright Notice Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation of Route Optimizaiton without Home Agent . . . . . . 4 3.1. Operations on network layer . . . . . . . . . . . . . . . 5 3.2. Operations on higher protocol layers . . . . . . . . . . . 6 3.3. Operation during unavailability of HA . . . . . . . . . . 7 3.4. Learning about correspondent's RO support . . . . . . . . 8 4. HoA Support Mobility Option . . . . . . . . . . . . . . . . . . 8 5. Policy Changes . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7. Performance Limitations of HA-free RO . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction MIPv6 Route Optimization (RO) [1] enables hosts to move between networks during ongoing traffic connections, while permitting traffic to flow along the shortest routing path. RO hence minimizes end-to- end transport delay and it relieves the home agent (HA) from the processing-intense task of relaying payload traffic. Hampel et al. Expires September 27, 2011 [Page 2] Internet-Draft Route Optimization without Home Agent Feb 2011 During RO, the HA's relay function is still required for a variety of purposes. It supports a location service in case the mobile has to be reached while away from home. It further relays mobility headers sent by mobile correspondents. The HA also provides an alternative path for home tests when the mobile is away from home. Finally the HA's relay function is used as a fallback in case the correspondent does not support RO. While providing these benefits, the requirement for HA support comes at a certain cost: - Reliability problem: The HA is a single point of failure. When it becomes unavailable, RO is not supported anymore. - Lack of flexibility: When the mobile does not have a HA, RO is not supported at all. - Packet and processing overhead: When the mobile is away from home, it must use a home address (HoA) pertaining to its home link to enjoy RO support. This adds significant overhead to payload packets due to Type 2 Routing headers and Home Address Option headers as well as processing overhead. This overhead applies even if the mobile remains stationary. - Additional signaling traffic: Signaling handshakes have to be conducted between mobile and HA at every mobility event. In many cases, the HA's relay function is not needed during RO, or it is undesirable in case the cost outweighs the benefits: - For traffic between mobile clients and stationary servers, the HA's location service is not needed. This applies to a large fraction of mobile internet traffic. Further, location service may also be provided by other means such as dynamic DNS or on application layer (e.g. SIP registrar). - When the correspondent is mobile, it can send its mobility header messages along the shortest routing path to the mobile's CoA instead of using the detour via the mobile's HA. - The home-test requirement does not imply the need for a HA but the availability of a routable path to the mobile's HoA. Multi-homed hosts that wish to migrate connections from their home link to another simultaneously supported link can conduct the home test without HA. If RO is secured via cryptographically generated addresses (CGA) according to RFC 4866 [2], only one initial home test is necessary, which can be conducted while the mobile is Hampel et al. Expires September 27, 2011 [Page 3] Internet-Draft Route Optimization without Home Agent Feb 2011 still at home. If stronger security is used such as outlined by RFC 4449 [3], the home test can be completely avoided. - When the mobile knows about the correspondent's RO support it does not need the HA as a fallback relay. This knowledge may be available from prior connections or through means external to the standard. Based on these reasons, it makes sense to support RO without HA. Note that such an enhancement was first proposed by RFC 4651 [4]. 2. Terminology 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 [RFC 2119]. In this document, the following terms are used: Legacy Mobile IPv6 Refers to MIPv6 [1] and its extensions excluding those described in this document. HA-bound RO Refers to RO according to legacy MIPv6 HA-free RO Refers to RO where the mobile does not have a HA Permanent Home Address Home address (HoA) according to legacy MIPv6 Virtual Home Address IPv6 address that holds the equivalent function in HA-free RO as the permanent HoA in HA-bound RO. 3. Operation of Route Optimization without Home Agent Two distinct scenarios are considered. In the first scenario, the mobile desires to conduct RO without HA support even if a HA is available. This scenario is referred to as HA-free RO and described in subsection 3.1 and 3.2. In the second scenario, the mobile seeks HA-support during RO but the HA becomes unavailable prior or during RO. This scenario can be treated as a special case of HA-free RO and is discussed in subsection 3.3. Subsection 3.4 elaborates on how the mobile can identify the correspondent's support of RO. Hampel et al. Expires September 27, 2011 [Page 4] Internet-Draft Route Optimization without Home Agent Feb 2011 3.1. Operations on network layer HA-free RO implies that all traffic and all signaling messages flow on the shortest routing path between mobile and correspondent. In the absence of a HA, the mobile does not have a home network. Therefore, the mobile interprets the IPv6 address of one of its links as a "virtual" HoA as if it resided in its home network. The virtual HoA MUST be a unicast routable IPv6 address. The mobile uses the virtual HoA to start transport connections subject to the limitations discussed in 3.2. When the mobile moves to another IPv6 address, it interprets this address as a care-of-address (CoA). Consequently, it conducts a correspondent registration, which creates a binding between virtual HoA and CoA. The CoA MUST also be a unicast routable IPv6 address. If a home test is required prior to the correspondent registration, the home test MUST be based on the mobile's virtual HoA. This means that the virtual HoA must still be supported during the home test. The mobile omits the home registration. All signaling between mobile and correspondent is the same for HA-free RO as for HA-bound RO. In HA-free RO, the mobile MAY omit message exchanges with the HA. When the correspondent is also mobile, it can send its mobility header messages to either the mobile's virtual HoA or to the mobile's CoA. If the mobile's virtual HoA is not on link anymore, the correspondent MUST send its mobility header messages to the mobile's CoA. This policy is in departure from RFC 3775 [1], which requires that mobile correspondents MUST always send their mobility header messages to the mobile's permanent HoA. To provide clarification to the correspondent on where it should send its own mobility header messages, the mobile has to inform the correspondent about the on-link support of its virtual HoA. This requires introduction of a new mobility header option, referred to as HoA-Support Mobility option, which the mobile inserts into mobility header messages such as BU, Early BU, Home Test Init and Care-of Test Init [1][2]. This option holds a HoA Support flag with settings "supported" or "not supported". The mobile SHOULD insert this option only when the on-link support of the virtual HoA has changed. The HoA-Support Mobility option is defined in section 4. Hampel et al. Expires September 27, 2011 [Page 5] Internet-Draft Route Optimization without Home Agent Feb 2011 The correspondent SHOULD support an additional field in its binding cache referred to as the HoA Support field, which is updated according to the entry in the mobile's HoA-Support Mobility option. The HoA Support field is initialized with "supported". If this field is set to "not supported", the correspondent MUST send its mobility header messages to the mobile's CoA and it MUST insert the Type-2 Routing header into these messages. Otherwise the correspondent MUST proceed according to legacy MIPv6 and send its mobility header messages to the mobile's HoA (this can be the mobile's virtual or permanent HoA). When the correspondent receives a HoA-Support Mobility option in a mobility header message, it MUST attach a copy of this option in the associated response message such as Binding Acknowledgement (BA), early BA, Home Test and Care-of Test. This informs the mobile that the correspondent complies with the extensions of HA-free RO. In case the correspondent does not support the extensions for HA-free RO provided by this document, it simply ignores the new mobility option. The missing HoA-Support Mobility option in the return message is an indicator for the mobile that HA-free is not supported by the correspondent. In this case, connections make break in case both peers are mobile and the correspondent moves while the mobile's virtual HoA is not on link. Subsection 3.4 discusses on how such a situation can be avoided. 3.2. Operations on higher protocol layers Legacy MIPv6 uses the permanent HoA as an invariant on higher protocol layers (e.g. transport layer), which shuns IP mobility from these layers. For HA-free RO, the same functionality is accomplished by using the virtual HoA instead of the permanent HoA. Although the virtual HoA may have limited lifetime on the link, it is used by higher protocol layers throughout the lifetime of the connection. For new connections, higher protocol layers use one of the host's current on-link addresses as the virtual HoA unless an active BU entry exists in the BU list or binding cache. If such an entry exists, higher protocol layers should use the virtual HoA of this entry. This guarantees that temporally overlapping connections with the same correspondent use the same virtual HoA. A multi-homed host MAY start connections from different simultaneously supported IP addresses and declare each IP address as a virtual HoA for the associated connection unless the host already holds a BU entry or binding cache entry for that correspondent. This behavior is compliant with the spirit of RFC 3775 [1], which permits Hampel et al. Expires September 27, 2011 [Page 6] Internet-Draft Route Optimization without Home Agent Feb 2011 behavior is compliant with the spirit of RFC 3775 [1], which permits simultaneous support of multiple permanent HoAs pertaining to different home subnet prefixes. RFC 3755 makes no restrictions to the topological distance between the home subnet prefixes pertaining to these HoAs. It is also permissible that the mobile uses an HA for some connections and HA-free RO for others. In this case the HoA can be of permanent and virtual nature at the same time. Under all circumstances, the HoA (virtual or permanent) used for the home test MUST always match the HoA used by higher protocol layers. 3.3. Operation during unavailability of home agent The mobile determines that the HA is unavailable after it has tried to communicate with the HA and the HA hasn't responded within an adequate timeframe or after a certain number of message retransmissions. When the mobile has decided that the HA is unavailable, it switches to HA-free RO. The following scenarios have to be considered: - In case the mobile cannot obtain an ICMP HA discovery response message or an ICMP Mobile Prefix Advertisement message from the HA, the mobile MAY continue operation using HA-free RO. - In case the home registration fails while the mobile resides in its home network, the mobile MAY use its permanent HoA as a virtual HoA and continue operation using HA-free RO. It MAY also decide to use another on-link address as its virtual HoA. - In case the home registration fails while the mobile resides in a foreign network and before the first correspondent registration has successfully completed, the connection breaks since mobile and correspondent have not yet successfully engaged into RO. - In case the mobile resides in a foreign network and the home registration or the home test fails after the first correspondent registration has successfully completed, the mobile MAY use its permanent HoA as a virtual HoA and continue operation using HA-free RO. In this case, the mobile SHOULD send a BU to the correspondent rightaway and insert the HoA Support Mobility option. When the HA is unavailable and the mobile enters HA-free RO, it MAY still follow a retransmission schedule to re-engage into Hampel et al. Expires September 27, 2011 [Page 7] Internet-Draft Route Optimization without Home Agent Feb 2011 HA-bound RO. In case the HA becomes responsive again, the mobile MAY return to HA-bound RO for all those connections, whose virtual HoAs match the permanent HoA. All other connections MUST remain in HA-free RO. If HA-bound RO is resumed, the mobile SHOULD send a BU with HoA- Support Mobility option to the correspondent to update the correspondent about the availability of its HoA. 3.4. Learning about correspondent's RO Support Prior to engaging into HA-free RO, the mobile can determine if the correspondent supports HA-bound RO or HA-free RO. The mobile MAY pursue one of the following strategies: - For frequently contacted correspondents, the mobile MAY cache from prior sessions if HA-bound or HA-free RO is supported. - The mobile MAY conduct a home test prior to connection establishment and include the HoA Support Mobility Option. - The mobile MAY start the connection in HA-bound RO and switch to HA-free RO as soon as the correspondent registration has succeeded. 4. HoA Support Mobility Option The HoA Support Mobility option is inserted into a mobile header message to inform the correspondent about the on-link support of its virtual HoA. The correspondent reflects this mobility option in the response message. The HoA Support Mobility option has the following entries: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | HoA Support | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HoA Routability 8-bit unsigned integer indicating the connectivity of the virtual HoA. The following values are supported: 0 HoA is not supported 1 HoA is supported Hampel et al. Expires September 27, 2011 [Page 8] Internet-Draft Route Optimization without Home Agent Feb 2011 5. Policy Changes All mobiles that follow the extensions for HA-free RO described in this document MAY omit signaling handshakes with their HA. 6. Security Considerations HA-free RO is subject to the same security concerns as HA-bound RO. These concerns have been addressed by RFC 3775 [1] and RFC 4225 [5]. Since HA-free RO does not alter the signaling between mobile and correspondent and since the HA does not provide additional security support for RO, omission of HA-support should not negatively impact the security of HA-free RO beyond that of HA-bound RO. 7. Performance Limitations of HA-free RO HA-free RO has some principle limitations regarding operation and performance: - When a mobile uses the return routability procedure according to RFC 3775, it always has to sustain the virtual HoA on one link to conduct the home tests. - Mobile hosts may require a location service external to MIPv6 in case they support a server function and move to foreign networks. - Simultaneous movement of mobile and correspondent cannot be supported unless both nodes are multi-homed and sustain an extended "make-before-break" time period. 8. IANA Considerations The value for the HoA Support Mobility option type must be assinged by IANA. 9. References 9.1. Normative References [1] D. Johnson, C. Perkins and J. Arkko, "Mobile Support in IPv6", RFC3775, June 2004 [2] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC4866, May 2007 Hampel et al. Expires September 27, 2011 [Page 9] Internet-Draft Route Optimization without Home Agent Feb 2011 [3] C. Perkins, "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC4449, June 2006. [4] C. Vogt and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC4651, February 2007 [5] P. Nikander, J. Arkko, T. Aura, G. Montenegro and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC4225, December 2005 Authors' Addresses Georg Hampel Bell Labs, Alcatel-Lucent 600 Mountain Avenue Murray Hill, NJ 07974 USA Tel: +1 908 582 2377 Email: georg.hampel@alcatel-lucent.com Thierry Klein Bell Labs, Alcatel-Lucent 600 Mountain Avenue Murray Hill, NJ 07974 USA Tel: +1 908 582 3585 Email: thierry.klein@alcatel-lucent.com Hampel et al. Expires September 27, 2011 [Page 10]