[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/