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

Versions: 00 01 02 03 RFC 4068

Mobile IP Working Group                            Rajeev Koodli, Editor
INTERNET DRAFT                                     Nokia Research Center
10 October 2003


                     Fast Handovers for Mobile IPv6
                 draft-ietf-mipshop-fast-mipv6-00.txt


   Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.


   Abstract

   Mobile IPv6 enables a Mobile Node to maintain its connectivity to
   the Internet when moving from an Access Router to another, a process
   referred to as handover.  During handover, there is a period when
   the Mobile Node is unable to send or receive packets both due to
   link switching delay and IP protocol operations.  This ``handover
   latency'' resulting from standard Mobile IPv6 procedures, namely
   movement detection, new Care of Address configuration and Binding
   Update, is often unacceptable to real-time traffic such as Voice
   over IP. Reducing the handover latency could be beneficial to non
   real-time, throughput-sensitive applications as well.  This document
   specifies enhancements to reduce the handover latency due to standard
   Mobile IPv6 procedures.  This document does not address improving the
   link switching latency.




Koodli (Editor)              Expires 10 April 2004              [Page i]

Internet Draft              Fast Handovers               10 October 2003




                                 Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       2

 2. Terminology                                                        2

 3. Protocol Overview                                                  3
     3.1. Addressing the Handover Latency . . . . . . . . . . . . .    3
     3.2. Protocol Operation  . . . . . . . . . . . . . . . . . . .    6
     3.3. Protocol Operation of Network-initiated Handover  . . . .    8

 4. Protocol Details                                                   9

 5. Other Considerations                                              13
     5.1. Handover Capability Exchange  . . . . . . . . . . . . . .   13
     5.2. Determining New Care of Address . . . . . . . . . . . . .   13
     5.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . .   13
     5.4. DAD Handling  . . . . . . . . . . . . . . . . . . . . . .   14
     5.5. Fast or Erroneous Movement  . . . . . . . . . . . . . . .   14

 6. Message Formats                                                   15
     6.1. New Neighbor Discovery Messages . . . . . . . . . . . . .   15
           6.1.1. Router Solicitation for Proxy . . . . . . . . . .   15
           6.1.2. Proxy Router Advertisement (PrRtAdv)  . . . . . .   17
     6.2. Inter-Access Router Messages  . . . . . . . . . . . . . .   20
           6.2.1. Handover Initiate (HI)  . . . . . . . . . . . . .   20
           6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . .   22
     6.3. New Mobility Header Messages  . . . . . . . . . . . . . .   24
           6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . .   24
           6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . .   25
           6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . .   27
     6.4. New ICMP Options  . . . . . . . . . . . . . . . . . . . .   28
           6.4.1. IP Address Option . . . . . . . . . . . . . . . .   28
           6.4.2. New Router Prefix Information Option  . . . . . .   29
           6.4.3. Link-layer Address (LLA)  . . . . . . . . . . . .   30
           6.4.4. Neighbor Advertisement Acknowledgment (NAACK) . .   31

 7. Configurable Parameters                                           32

 8. Security Considerations                                           32

 9. Contributors                                                      33



Koodli (Editor)             Expires 10 April 2004              [Page ii]

Internet Draft              Fast Handovers               10 October 2003


10. Acknowledgments                                                   33

 A. Change Log                                                        34

 B. Contact Information                                               34















































Koodli (Editor)              Expires 10 April 2004              [Page 1]

Internet Draft              Fast Handovers               10 October 2003


   1. Introduction

   Mobile IPv6 [3] describes the protocol operations for a mobile node
   to maintain connectivity to the Internet during its handover from one
   access router to another.  These operations broadly involve movement
   detection, IP address configuration, and location update phases.
   The combined handover latency could be (especially) appreciable
   for real-time applications.  Throughput-sensitive applications can
   also benefit from reducing this latency.  This document describes a
   protocol to reduce the handover latency.

   This specification addresses the following problem:  how to allow
   a mobile node to send packets as soon as it detects a new subnet
   link, and how to deliver packets to a mobile node as soon as its
   attachment is detected by the new access router.  The protocol
   defines IP protocol messages necessary for its operation on any link
   technology.  It does this without depending on specific link-layer
   features while allowing link-specific customizations.  By definition,
   this specification considers handovers that inter-work with Mobile
   IP: once attached to its new access router, a MN engages in Mobile
   IP operations including Return Routability [3].  Hence, there are no
   special requirements for a mobile node to behave differently with
   respect to its standard Mobile IP operations.


   2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
   "silently ignore" in this document are to be interpreted as described
   in RFC 2119 [1].

   The following terminology and abbreviations are used in this
   document.  The reference handover scenario is illustrated in
   Figure 1.

      Mobile Node (MN)
               A Mobile IPv6 host

      Access Point (AP)
               A Layer 2 device connected to a subnet that offers
               wireless connectivity to a MN.

      Access Router (AR)
               The MN's default router

      Previous Access Router (PAR)
               The MN's default router prior to its handover




Koodli (Editor)              Expires 10 April 2004              [Page 2]

Internet Draft              Fast Handovers               10 October 2003


      New Access Router (NAR)
               The MN's anticipated default router subsequent to its
               handover

      Previous CoA (PCoA)
               The MN's Care of Address valid on PAR. The MN may reuse
               this address while attached to NAR until it finishes
               Mobile IP operations.

      New CoA (NCoA)
               The MN's Care of Address valid on NAR

      Handover
               A process of terminating existing connectivity and
               obtaining new IP connectivity.

      Router Solicitation for Proxy (RtSolPr)
               A message from the MN to the PAR requesting information
               for a potential handover

      Proxy Router Advertisement (PrRtAdv)
               A message from the PAR indicating a MN to undergo
               handover

      Fast Binding Update (FBU)
               A message from the MN instructing its PAR to redirect its
               traffic (towards NAR)

      Fast Binding Acknowledgment (FBACK)
               A message from the PAR in response to FBU

      Fast Neighbor Advertisement (FNA)
               A message from the MN to the NAR to announce attachment
               and to confirm use of NCoA when the MN has not received
               FBACK

      Handover Initiate (HI)
               A message from the PAR to the NAR to initiate handover

      Handover Acknowledge (HACK)
               A message from the NAR to the PAR as a response to HI


   3. Protocol Overview

   3.1. Addressing the Handover Latency

   The ability to quickly send packets from a new subnet link depends
   on the ``IP connectivity'' latency, which in turn depends on the



Koodli (Editor)              Expires 10 April 2004              [Page 3]

Internet Draft              Fast Handovers               10 October 2003




             v            +------------+
           +-+            |  Previous  |        <
           | | ---------- |   Access   | ------ > ----\
           +-+            |   Router   |        <      \
               MN         |   (PAR)    |                \
            |             +------------+            +---------------+
            |                   ^            IP     | Correspondent |
            |                   |         Network   |  Node         |
            V                   |                   +---------------+
                                v                        /
             v            +------------+                /
           +-+            |    New     |        <      /
           | | ---------- |   Access   | ------ > ----/
           +-+            |   Router   |        <
              MN          |   (NAR)    |
                          +------------+



               Figure 1: Reference Scenario for Handover



   movement detection latency and the new CoA configuration latency.
   Once a MN is IP-capable on the new subnet link, it can send Binding
   Update to its Home Agent and one or more correspondents.  Once
   its correspondents successfully process the Binding Update, which
   involves the Return Routability procedure, the MN can receive packets
   at new CoA. So, the ability to receive packets from correspondents
   directly at its new CoA depends on the Binding Update latency.

   The protocol enables a MN to quickly detect that it has moved to
   a new subnet by providing the new access point and the associated
   subnet prefix information when the MN is still connected to its
   current subnet (i.e., PAR in Figure 1).  For instance, a MN may
   discover available access points using link-layer specific mechanisms
   (e.g., a ``scan'' in WLAN) and then request subnet information
   corresponding to one or more of those discovered access points.
   The MN may do this after performing router discovery.  The MN may
   also do this at any time during its sojourn on its current point of
   attachment.  The result of resolving an identifier associated with
   an access point is a [AP-ID, AR-Info] tuple, which a MN can use in
   readily detecting movement:  when attachment to an access point
   with AP-ID takes place, the MN knows the corresponding new router's
   co-ordinates including its prefix, IP address and MAC address.  The
   ``Router Solicitation for Proxy (RtSolPr)'' and ``Proxy Router




Koodli (Editor)              Expires 10 April 2004              [Page 4]

Internet Draft              Fast Handovers               10 October 2003


   Advertisement (PrRtAdv)'' messages are used for aiding in movement
   detection.

   Through the RtSolPr and PrRtAdv messages, the MN also formulates
   a prospective new CoA (NCoA), again when still present on PAR's
   link.  Hence, the latency due to new prefix discovery subsequent to
   handover is eliminated.  Furthermore, this prospective address can
   be used immediately after attaching to the new subnet link (i.e.,
   NAR's link) when the MN has received a ``Fast Binding Acknowledgment
   (FBack)'' message prior to its movement.  In the event it moves
   without receiving an FBack, the MN can still start using NCoA after
   announcing its attachment through a ``Fast Neighbor Advertisement
   (FNA)'' message; NAR responds to FNA in case the tentative address
   is already in use.  In this way, NCoA configuration latency is
   reduced.  Under some limited conditions where the probability of
   address collision is considered insignificant, it may be possible
   to use NCoA immediately after attaching to the new link.  Even so,
   all implementations MUST implement the mechanism specified in this
   document to avoid potential address conflicts and SHOULD support
   them.

   In order to reduce the Binding Update latency, the protocol specifies
   a tunnel establishment typically between the Previous CoA (PCoA) and
   NCoA. A MN sends a ``Fast Binding Update'' message to its Previous
   Access Router to establish this tunnel.  When feasible, the MN SHOULD
   send FBU from PAR's link.  Otherwise, it should send it immediately
   after detecting attachment to NAR. Subsequent sections describe
   the protocol mechanics.  In any case, the net result is that PAR
   begins tunneling packets arriving for PCoA to NCoA. Such a tunnel
   would remain active until the MN completes Binding Update with its
   correspondents.  In the opposite direction, the MN SHOULD reverse
   tunnel packets to PAR, again until it completes Binding Update.  And,
   PAR SHOULD forward the inner packet in the tunnel to its destination
   (i.e., to the MN's correspondent).  Such a reverse tunnel ensures
   that packets containing PCoA as source IP addres are not dropped
   due to ingress filtering.  Readers may observe that even though the
   MN is IP-capable on the new link, it cannot use NCoA directly with
   its correspondents without the correspondents first establishing a
   binding cache entry (for NCoA).

   Setting up a tunnel alone does not ensure that the MN receives
   packets as soon as attaching to a new subnet link, unless NAR can
   detect the MN's presence.  Neighbor discovery operation involving
   a neighbor's address resolution (i.e., Neighbor Solicitation and
   Neighbor Advertisement) typically result in considerable delay,
   sometimes lasting multiple seconds.  For instance, when arriving
   packets trigger NAR to send Neighbor Solicitation before the MN
   attaches, subsequent re-transmissions of address resolution are
   separated by a default time of one second each.  In order to



Koodli (Editor)              Expires 10 April 2004              [Page 5]

Internet Draft              Fast Handovers               10 October 2003


   circumvent this delay, a MN announces its attachment through the FNA
   message that allows NAR to consider MN to be reachable.  If there
   is no existing entry, FNA allows NAR to create one.  If NAR already
   has an entry, FNA updates the entry while taking potential address
   conflicts into consideration.  Through tunnel establishment for PCoA
   and fast advertisement, the protocol provides expeditious forwarding
   of packets to the MN.

   The protocol also provides the following important functionalities.
   The access routers can exchange messages to confirm that a proposed
   NCoA is acceptable.  For instance, when a MN sends FBU from PAR's
   link, FBack can be delivered after NAR considers NCoA acceptable to
   use.  This is especially useful when stateful address configuration
   is used.  The NAR can also rely on its trust relationship with PAR
   before providing forwarding support for the MN. That is, it may
   create a forwarding entry for NCoA subject to ``approval'' from
   PAR which it trusts.  Finally, the access routers could transfer
   network-resident contexts, such as access control, QoS, header
   compression, in conjunction with handover.  For all these operations,
   the protocol provides ``Handover Initiate (HI)'' and ``Handover
   Acknowledge (HAck)'' messages.  Both of these messages MUST be
   implemented and SHOULD be supported.


   3.2. Protocol Operation

   The protocol begins when a MN sends RtSolPr to its access router
   to resolve one or more Access Point Identifiers to subnet-specific
   information.  In response, the access router (e.g., PAR in Figure 1)
   sends a PrRtAdv message which contains one or more [AP-ID, AR-Info]
   tuples.  The MN may send RtSolPr at any convenient time, for instance
   as a response to some link-specific event (a ``trigger'') or simply
   after performing router discovery.  However, the expectation is that
   prior to sending RtSolPr, the MN has discovered the available APs
   by link-specific methods.  The RtSolPr and PrRtAdv messages do not
   establish any state at the access router, and their packet formats
   are defined in Section 6.1.

   With the information provided in the PrRtAdv message, the MN
   formulates a prospective NCoA and sends an FBU message.  The purpose
   of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving
   packets can be tunneled to the new location.  The FBU SHOULD be
   sent from PAR's link whenever feasible.  For instance, an internal
   link-specific trigger could enable FBU transmission from the previous
   link.  When it is not feasible, FBU is sent from the new link.  Care
   must be taken to ensure that NCoA used in FBU does not conflict with
   an address already in use by some other node on link.  For this, FBU
   encapsulation within FNA MUST be implemented and SHOULD be used (See
   below).



Koodli (Editor)              Expires 10 April 2004              [Page 6]

Internet Draft              Fast Handovers               10 October 2003


   The format and semantics of FBU processing are specified in
   Section 6.3.1.

   Depending on whether an FBack is received or not on the previous
   link, which clearly depends on whether FBU was sent in the first
   place, there are two modes of operation.

    1. The MN receives FBack on the previous link.  This means that
       packet tunneling would already be in progress by the time the
       MN handovers to NAR. The MN SHOULD send FNA immediately after
       attaching to NAR, so that arriving as well as buffered packets
       can be forwarded to the MN right away.

       Before sending FBack to MN, PAR can verify if NCoA is acceptable
       to NAR through the exchange of HI and HAck messages.  When
       stateful assignment is used, the proposed NCoA in FBU is carried
       in HI, and NAR MAY consider assigning the proposed NCoA. In any
       case, the assigned NCoA MUST be returned in HAck, and PAR MUST in
       turn provide the assigned NCoA in FBack.  If there is an assigned
       NCoA returned in FBack, the MN MUST use the assigned address
       (and not the proposed address in FBU) upon attaching to NAR.
       The HI and HAck protocol exchange to verify NCoA acceptability,
       among others noted in Section 3.1, can be used even when stateful
       assignment is not used.

    2. The MN does not receive FBack on the previous link.  One obvious
       reason for this is that the MN has not sent the FBU. The other
       reason is that the MN has left the link after sending the FBU
       (which may be lost) but before receiving an FBack.  Without
       receiving an FBack in the latter case, the MN cannot ascertain
       whether PAR has successfully processed the FBU. Hence, it
       (re)sends an FBU as soon as it attaches to NAR. In order to
       enable NAR to forward packets immediately (when FBU has been
       processed) and to allow NAR to verify if NCoA is acceptable, the
       MN SHOULD encapsulate FBU in FNA. If NAR detects that NCoA is in
       use when processing FNA, for instance while creating a neighbor
       entry, it MUST discard the inner FBU packet and send a Router
       Advertisement with ``Neighbor Advertisement Acknowledge (NAACK)''
       option in which NAR MAY include an alternate IP address for the
       MN to use.  This discarding avoids the undesirable outcome of
       address collision, even though the chances of such a collision
       are extremely low.  Detailed FNA processing rules are specified
       in Section 6.3.3.

   The scenario in which a MN sends FBU and receives FBack on PAR's link
   is illustrated in Figure 2.  For convenience, this scenario may be
   characterized as ``predictive'' mode of operation.  The scenario in
   which the MN sends FBU from NAR's link is illustrated in Figure 3.
   For convenience, this scenario may be characterized as ``reactive''



Koodli (Editor)              Expires 10 April 2004              [Page 7]

Internet Draft              Fast Handovers               10 October 2003


   mode of operation.  Note however that the reactive mode includes the
   case when FBU has been sent from PAR's link but FBack has not been
   received yet.

   Finally, the PrRtAdv message may be sent gratuitously, i.e., without
   the MN first sending RtSolPr.




              MN                    PAR                  NAR
               |                     |                    |
               |------RtSolPr------->|                    |
               |<-----PrRtAdv--------|                    |
               |                     |                    |
               |------FBU----------->|--------HI--------->|
               |                     |<------HAck---------|
               |          <--FBack---|--FBack--->         |
               |                     |                    |
            disconnect             forward                |
               |                   packets===============>|
               |                     |                    |
               |                     |                    |
           connect                   |                    |
               |                     |                    |
               |--------- FNA --------------------------->|
               |<=================================== deliver packets
               |                                          |




                 Figure 2: ``Predictive'' Fast Handover



   3.3. Protocol Operation of Network-initiated Handover

   In some wireless technologies, the handover control may reside in
   the network even though the decision to undergo handover may be
   co-operatingly arrived at between the MN and the network.  On such
   network, it is possible for the PAR to send an unsolicited PrRtAdv
   containing the link address, IP address and subnet prefixes of the
   NAR when the network decides that a handover is imminent.  The MN
   MUST process this PrRtAdv to configure a new care of address on the
   new subnet, and MUST send an FBU to PAR prior to switching to the new
   link.  After transmitting the FBU, the PAR MUST continue to forward
   packets to the MN on its current link until the FBU is received.  The
   rest of the operation is the same as that described in Section 3.2.



Koodli (Editor)              Expires 10 April 2004              [Page 8]

Internet Draft              Fast Handovers               10 October 2003




              MN                    PAR                  NAR
               |                     |                    |
               |------RtSolPr------->|                    |
               |<-----PrRtAdv--------|                    |
               |                     |                    |
            disconnect               |                    |
               |                     |                    |
               |                     |                    |
            connect                  |                    |
               |------FNA[FBU]-------|------------------->|
               |                     |<-----FBU-----------|
               |                     |------FBack-------->|
               |                   forward                |
               |                   packets===============>|
               |                     |                    |
               |<=================================== deliver packets
               |                                          |




                  Figure 3: ``Reactive'' Fast Handover



   An alternative use of the unsolicited PrRtAdv is to allow the network
   to inform the MN about geographically adjacent subnets without the
   MN having to explicitly request that information.  This can reduce
   the amount of wireless traffic required for the MN to obtain a
   neighborhood links and subnet topology map.  Such usage of PrRtAdv is
   decoupled from the actual handover.  Exactly how to reconcile this
   function with the use of PrRtAdv as a handover trigger is a topic for
   future experimental work.


   4. Protocol Details

   All description makes use of Figure 1 as the reference.

   After discovering nearby access points, the MN sends RtSolPr in order
   to resolve access point identifiers to subnet router information.
   A convenient time to do this is after performing router discovery.
   However, the MN MAY send RtSolPr at any time during its attachment to
   PAR. The trigger for sending RtSolPr can emanate from a link-specific
   event, such as the promise of better signal strength from another
   access point coupled with fading signal quality with the current
   access point.  Such events, often broadly called as ``L2 triggers'',



Koodli (Editor)              Expires 10 April 2004              [Page 9]

Internet Draft              Fast Handovers               10 October 2003


   are outside the scope of this document.  Nevertheless, they serve
   as important events that invoke the protocol.  For instance, when
   a ``link up'' indication is obtained on the new link, the protocol
   messages (e.g., FNA) can be immediately transmitted.  Implementations
   SHOULD make use of such triggers whenever available.

   The RtSolPr message may contain one or more AP-IDs.  A wildcard
   requests all available tuples.  When the MN has knowledge of an
   impending handover, it MAY set the `U' bit in RtSolPr to request PAR
   to start buffering its packets.

   As a response to RtSolPr, PAR sends a PrRtAdv message which indicates
   one of the following possible conditions.

    1. If the PAR does not have an entry corresponding to the new
       attachment point, it MUST respond indicating that the new
       point of attachment is unknown.  The MN MUST stop fast handover
       protocol operations on the current link.  The MN MAY send an FBU
       from its new link.

    2. If the new point of attachment is connected to the PAR itself,
       PAR MUST respond indicating that the point of attachment is known
       but is connected to itself.  This could happen, for example, when
       the wireless access points are bridged into a wired network.  No
       further protocol action is necessary.

    3. If the new point of attachment is known and the PAR has
       information about it, then PAR MUST respond indicating that the
       point of attachment is known.  The message MUST contain the NCoA
       that the MN should use or the network prefix that should be used
       to form NCoA. If the new point of attachment is known, but does
       not support fast handover, the PAR MUST indicate this with Code 3
       (See Section 6.1.2).

    4. If a wildcard is supplied as an identifier for the new point of
       attachment, the PAR SHOULD supply neighborhood [AP, AR] tuples
       subject to path MTU restrictions (i.e., provide any `n' tuples
       without exceeding the link MTU).

   If the `U' bit is set in RtSolPr, PAR MAY buffer incoming packets
   in FIFO order but MUST continue forwarding packets to PCoA on
   PAR's link.  It SHOULD stop buffering after processing the FBU
   message.  The size of the buffer and the duration of buffering
   are implementation-specific considerations.  If the new point of
   attachment belongs to itself, PAR MAY chose to ignore buffering.

   The method by which Access Routers exchange information about
   their neighbors and thereby allow construction of PrRtAdvs with
   information about the new subnet is outside the scope of this



Koodli (Editor)             Expires 10 April 2004              [Page 10]

Internet Draft              Fast Handovers               10 October 2003


   document.  Furthermore, this document assumes that the access routers
   share necessary security association established by means outside the
   scope of this document.

   The RtSolPr and PrRtAdv messages MUST be implemented by a MN and
   an access router that supports fast handovers.  However, when
   the parameters necessary for the MN to send packets immediately
   upon attaching to the NAR are supplied by the link layer handover
   mechanism itself, the above messages are optional on such link
   layers.

   Sometime after PrRtAdv is received, the MN sends FBU in which it
   includes the proposed NCoA. The MN SHOULD send FBU from PAR's link
   whenever feasible, i.e., whenever ``anticipation'' of handover is
   feasible.  When anticipation is not feasible or if has not received
   an FBack yet, the MN sends FBU immediately after attaching to NAR's
   link.  In addition, this FBU SHOULD be encapsulated in a FNA message
   in order to allow NAR to first verify if NCoA is in use already
   before it can forward the (inner) FBU packet to PAR. In response to
   FBU, PAR establishes a binding between PCoA (``Home Address'') and
   NCoA, and sends FBack to MN. Prior to establishing this binding, PAR
   SHOULD send a HI message to NAR, and receive HAck in response.

   The HI message contains the PCoA, link-layer address and the NCoA of
   the MN. In response to processing the HI message, the NAR

    1. verifies if NCoA supplied in the HI message is a valid address
       for use, and if it is, starts proxying the address.

    2. allocates NCoA for the MN when stateful address configuration is
       used, creates a proxy neighbor cache entry and begins defending
       it.  The NAR MAY consider NCoA proposed in HI for allocation.

    3. MAY create a host route entry for PCoA in case NCoA cannot be
       accepted or assigned such that the entry allows it to forward
       packets to the MN. This host route entry SHOULD be implemented
       such that until the MN's presence is detected, either through
       explicit announcement by the MN or by other means, arriving
       packets do not invoke neighbor discovery.  The NAR MAY also set
       up a reverse tunnel to PAR in this case.

    4. SHOULD start buffering packets if the `U' bit is set.

    5. provides the status of handover request in Handover Acknowledge
       (HAck) message.

   If HAck contains an assigned NCoA, such as in stateful allocation,
   FBack MUST include it, and the MN MUST use the address provided in
   FBack.  The PAR SHOULD send FBack to previous link as well.  The



Koodli (Editor)             Expires 10 April 2004              [Page 11]

Internet Draft              Fast Handovers               10 October 2003


   result of FBU and FBack processing is that PAR begins tunneling MN's
   packets to NCoA. If the MN does not receive an FBack message even
   after re-transmitting FBU for FBU_RETRIES, it must assume that fast
   handover support is not available and stop the protocol operation.

   As soon as the MN establishes link connectivity with the NAR, it
   SHOULD send a Fast Neighbor Advertisement (FNA) message (See 6.3.3).
   If the MN has not received an FBack by the time FNA is being sent, it
   SHOULD encapsulate the FBU in FNA and send them together.

   When it is acceptable to use NCoA corresponding to the FNA message,
   the NAR MUST

    1. delete the proxy neighbor cache entry, if any is present.

    2. create a neighbor cache entry and set its state to REACHABLE
       without over-writing an existing entry for a different layer 2
       address.

    3. forward any buffered packets

    4. enable the host route entry, if any is present, for PCoA.

   If NAR detects that NCoA is in use by another node while processing
   the FNA, it MUST

    1. discard the inner (FBU) packet.

    2. send a Router Advertisement with the NAACK option, and NAR MAY
       include an alternate NCoA for use

   If the MN receives a Router Advertisement with a NAACK option, it
   MUST revert to configuring a new address, and SHOULD use the address,
   if any is, provided in the NAACK option.  Subsequently, the MN
   SHOULD send an FBU using the new CoA. As a special case, the address
   supplied in NAACK could be PCoA itself, in which case the MN MUST not
   send any more FBUs.  If no address is present in NAACK option, the MN
   MUST follow [5] in order to configure a new CoA and SHOULD still send
   FBU to PAR.

   Once the MN has confirmed its NCoA, it SHOULD send a Neighbor
   Advertisement message.  This message updates its neighbor's cache
   entries with the MN's link-layer address.









Koodli (Editor)             Expires 10 April 2004              [Page 12]

Internet Draft              Fast Handovers               10 October 2003


   5. Other Considerations

   5.1. Handover Capability Exchange

   The MN expects a PrRtAdv in response to its RtSolPr message.  If the
   MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it
   must assume that PAR does not support the fast handover protocol.
   Similarly, if PAR sends PrRtAdv gratuitously to a MN, but does not
   receive an FBU even after GR_PRRTADV_RETRIES, it must assume that the
   MN does not support the fast handover protocol.

   Even if a MN's current access router is capable of fast handover,
   the access router into which the MN is handing over to may not
   be capable of fast handover.  This is indicated to the MN during
   ``runtime'', through the PrRtAdv message with a Code value of 3.  See
   Section 6.1.2.


   5.2. Determining New Care of Address

   Typically, the MN formulates its prospective NCoA using the
   information provided in a PrRtAdv message, and sends FBU. The PAR
   MUST use the NCoA present in FBU in its HI message.  The NAR SHOULD
   verify if NCoA present in HI is already in use.  In any case, NAR
   MUST respond to HI in the form of a HAck in which it may include a
   different NCoA to use, especially when stateful address configuration
   is used.  If there is an address present in HAck, PAR MUST convey it
   to the MN in the FBack message.

   If PrRtAdv message carries a NCoA, the MN MUST use it as its
   prospective NCoA.


   5.3. Packet Loss

   Handover involves link switching.  It is understandably difficult
   to exactly co-ordinate fast handover signaling with link switching.
   Furthermore, arrival pattern of packets is dependent on many factors,
   including application characteristics, network queuing behavior etc.
   Hence, packets may arrive at NAR before the MN is able to attach to
   it.  These packets will be lost unless they are buffered by the NAR.
   Similarly, if the MN attaches to NAR and then sends an FBU message,
   packets arriving at PAR will be lost unless they are buffered.  This
   protocol provides an option to indicate request for buffering at the
   NAR in the HI message.  When the PAR does request this feature, it
   SHOULD also provide its own support for buffering.






Koodli (Editor)             Expires 10 April 2004              [Page 13]

Internet Draft              Fast Handovers               10 October 2003


   5.4. DAD Handling

   Duplicate Address Detection (DAD) was defined in [5] to avoid address
   duplication on links when stateless address auto- configuration is
   used.  The use of DAD to verify the uniqueness of an IPv6 address
   configured through stateless autoconfiguration adds delays to a MIPv6
   handover.

   The probability of an interface identifier duplication on the
   same subnet is very low, however it can not be ignored.  In this
   draft certain precautions are proposed to minimize the effects of
   a duplicate address occurrence.  On links wherein the uniqueness
   of the interface identifier is ensured within the subnet (by means
   beyond the scope of this document), DAD handling procedures SHOULD be
   avoided.

   In some cases the NAR may already have the knowledge required to
   assess whether the MN's address is a duplicate or not before the MN
   moves to the new subnet.  For example, the NAR can have a list of all
   nodes on its subnet, perhaps for access control, and by searching
   this list, it can confirm whether the MN's address is a duplicate
   or not.  The result of this search is sent back to the PAR in the
   HACK message.  If such knowledge is not available at the NAR, it
   may indicate this by not confirming NCoA in the HACK message.  The
   NAR may also indicate this in the NAACK option as a response to the
   FNA message.  In such cases, the MN would have to follow stateless
   address configuration rules after attaching to the NAR.


   5.5. Fast or Erroneous Movement

   Although this specification is for fast handover, the protocol has
   its limits in terms of how fast a MN can move.  A special case
   of fast movement is ping-pong, where a MN moves between the same
   two access points rapidly.  Another instance of the same problem
   is erroneous movement i.e., the MN receives information prior to
   a handover that it is moving to a new access point and but it is
   either moved to a different one or it aborts movement altogether.
   All of the above behaviors are usually the result of link layer
   idiosyncrasies and thus are often tackled at the link layer itself.

   IP layer mobility, however, introduces its own limits.  IP layer
   handovers should be in a frequency that allows enough time for the
   MN to update the binding of, at least, its HA and preferably that
   of every CN with which it is in communication.  A MN that moves
   faster than necessary for this signaling to complete, which may be
   of the order of few seconds, may start losing packets and ultimately
   connectivity.  The signaling overhead over the air and in the network
   may increase significantly, especially in the case of rapid movement



Koodli (Editor)             Expires 10 April 2004              [Page 14]

Internet Draft              Fast Handovers               10 October 2003


   between two access routers.  To avoid the signaling overhead, the
   following measures are suggested.

   A MN returning to the PAR before updating the necessary bindings when
   present on NAR MUST send a Fast Binding Update with Home Address
   equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN
   should have a security association with the PAR since it performed
   a fast handover from it to the NAR. The PAR, on receiving this Fast
   Binding Update, will check its set of outgoing (temporary fast
   handover) tunnels and if it finds a match it SHOULD drop that tunnel;
   i.e., stop forwarding packets for this MN and start delivering
   packets directly to the node instead.  The MN SHOULD NOT make any
   attempt to use any of the fast handover mechanisms described in this
   specification and SHOULD revert back to standard Mobile IPv6.

   Temporary tunnels for the purposes of fast handovers should use short
   lifetimes (in the order of a small number of seconds or less).  The
   lifetime of such tunnels should be enough to allow a MN to update all
   its active bindings.

   Erroneous movement is not likely to damage the network but it may
   cause loss of packets since routing can change and the PAR may
   forward packets towards another AR before the MN actually connects
   to that AR. If the MN discovers itself on an unanticipated AR, a
   Fast Binding Update to the PAR SHOULD be sent.  Since Fast Binding
   Updates are authenticated, they MUST supersede the existing binding
   and packets SHOULD be redirected to the new confirmed location of the
   MN. No attempt should be made to recover packets from the AR the MN
   was supposed to connect to.


   6. Message Formats

   6.1. New Neighbor Discovery Messages

   6.1.1. Router Solicitation for Proxy

   Mobile Nodes send Router Solicitation for Proxy in order to prompt
   routers for Proxy Router Advertisements.  For all the ICMP messages,
   the checksum is defined in [2].


 IP Fields:

   Source Address
                  An IP address assigned to the sending interface

   Destination Address
                  The address of the Access Router or the all routers



Koodli (Editor)             Expires 10 April 2004              [Page 15]

Internet Draft              Fast Handovers               10 October 2003



   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |          Checksum             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Identifier           |U|         Reserved            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
  +-+-+-+-+-+-+-+-+-+-+-+-




       Figure 4: Router Solicitation for Proxy (RtSolPr) Message



                  multicast address.

   Hop Limit      255

   Authentication Header
                  If a Security Association for the IP Authentication
                  Header exists between the sender and the
                  destination address, then the sender SHOULD include
                  this header.

 ICMP Fields:

   Type           TBA

   Code           0

   Checksum       The ICMP checksum.

   Identifier     MUST be set by the sender so that replies can be
                  matched to this Solicitation.

   `U' bit        If set, requests access router to also buffer
                  arriving packets

   Reserved       MUST be set to zero by the sender and ignored by
                  the receiver.

 Valid Options:

   Source link-layer address
                  The link-layer address of the sender, if known.



Koodli (Editor)             Expires 10 April 2004              [Page 16]

Internet Draft              Fast Handovers               10 October 2003


                  It SHOULD be included on link layers that have
                  addresses.

   New Attachment Point Link-Layer Address
                  The link-layer address or identification of the
                  attachment point for which the MN requests routing
                  advertisement information. It MUST be included
                  in all RtSolPr messages. More than one such address
                  or identifier can be present. This field can also
                  be a wildcard address with all bits set to zero.

   Future versions of this protocol may define new option types.
   Receivers MUST silently ignore any options that they do not recognize
   and continue processing the rest of the message.

   A MN sends this message if it wishes to initiate fast handover.  It
   indicates its destination with the New Attachment Point Link-Layer
   Address.  A Proxy Router Advertisement message should be received in
   response.  If such a message is not received in a short time period
   but no less than twice the typical round trip time (RTT) over the
   access link or 100 ms if RTT is not known, it SHOULD resend RtSolPr
   message at most RTSOLPR_RETRIES, waiting for the same time during
   each instance of retransmission.  If Proxy Router Advertisement is
   not received by the time the MN disconnects from the PAR, the MN
   SHOULD send FBU immediately after configuring a new CoA.


   6.1.2. Proxy Router Advertisement (PrRtAdv)

   Access routers send out Proxy Router Advertisement message
   gratuitously if the handover is network-initiated or as a response
   to RtSolPr message from a MN, providing the link-layer address, IP
   address and subnet prefixes of neighboring routers.  This avoids the
   MN having to solicit Router Advertisement when it connects to the new
   subnet.


 IP Fields:

   Source Address
                  MUST be the link-local address assigned to the
                  interface from which this message is sent.

   Destination Address
                  The Source Address of an invoking Router
                  Solicitation for Proxy or the address of the node
                  the Access Router is instructing to handover.

   Hop Limit      255



Koodli (Editor)             Expires 10 April 2004              [Page 17]

Internet Draft              Fast Handovers               10 October 2003



   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |          Checksum             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Identifier           |           Reserved            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
  +-+-+-+-+-+-+-+-+-+-+-+-



         Figure 5: Proxy Router Advertisement (PrRtAdv) Message




   Authentication Header
                  If a Security Association for the IP Authentication
                  Header exists between the sender and the
                  destination address, then the sender SHOULD include
                  this header.

 ICMP Fields:

   Type           TBA

   Code           0, 1, or 2

   Checksum       The ICMP checksum.

   Identifier     Copied from Router Solicitation for Proxy or set to
                  Zero if unsolicited.


   Reserved       MUST be set to zero by the sender and ignored by
                  the receiver.


 Valid Options:

   Source link-layer address
                  The link-layer address of the sender, if known.
                  It SHOULD be included on link layers that have
                  addresses.

   Link-layer address of proxied originator (i.e., NAR)
                  The link-layer address of the Access Router for



Koodli (Editor)             Expires 10 April 2004              [Page 18]

Internet Draft              Fast Handovers               10 October 2003


                  which this message is proxied for. This option MUST
                  be included when Code is 0.

   New Router Prefix Information Option.
                  These options specify the prefixes of the Access
                  Router the message is proxied for and are used
                  for address autoconfiguration. This option SHOULD be
                  included when Code is 0.

   New CoA Option
                  When PrRtAdv is sent gratuitously, this option MUST
                  be included. Otherwise, this option MAY be present.


   Future versions of this protocol may define new option types.
   Receivers MUST silently ignore any options they do not recognize and
   continue processing the message.

   A Proxy Router Advertisement with Code 0 but without a New CoA Option
   means that the MN SHOULD construct a NCoA out of its Interface ID
   (used in the Destination Address in this Proxy Router Advertisement)
   and the Prefix in the New Router Prefix Information Option (See
   Section 6.4.2.  A Proxy Router Advertisement with Code 0 and a New
   CoA Option means that the MN SHOULD use the supplied NCoA or else
   stand to loose service.

   A Proxy Router Advertisement with Code 1 is sent if handover to the
   New Attachment Point, as indicated by the New Attachment Point Link
   Layer address in the corresponding RtSolPr message, does not require
   change of CoA. No options are required in this case.

   A Proxy Router Advertisement with Code 2 means that the PAR is not
   aware of the Prefix Information requested.  The MN SHOULD attempt to
   send FBU as soon as it regains connectivity with the NAR. No options
   are required in this case.

   A Proxy Router Advertisement with Code 3 means that the NAR does
   not support fast handover.  The MN MUST stop fast handover protocol
   operations.  No options are required in this case.

   When a wildcard AP identifier is supplied in the RtSolPr message,
   the PrRtAdv message should include any 'n' [Access Point Identifier,
   Link-layer address option, Prefix Information Option] tuples
   corresponding to the PAR's neighborhood.








Koodli (Editor)             Expires 10 April 2004              [Page 19]

Internet Draft              Fast Handovers               10 October 2003


   6.2. Inter-Access Router Messages

   6.2.1. Handover Initiate (HI)

   The Handover Initiate (HI) is a new ICMPv6 message sent by an Access
   Router (typically PAR) to another Access Router (typically NAR) to
   initiate the process of a MN's handover.




    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Code       |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Identifier             |S|U|       Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



                Figure 6: Handover Initiate (HI) Message



 IP Fields:

   Source Address
                  The IP address of the PAR

   Destination Address
                  The IP address of the NAR

   Hop Limit      255

   Authentication Header
                  A Security Association MUST exist between the
                  sender and the receiver of this message. This
                  message MUST be authenticated and so the authentication
                  header MUST be used when this message is sent.

 ICMP Fields:

   Type           TBA

   Code           0




Koodli (Editor)             Expires 10 April 2004              [Page 20]

Internet Draft              Fast Handovers               10 October 2003


   Checksum       The ICMP checksum.

   Identifier     MUST be set by the sender so replies can be matched
                  to this message.

   S              Stateful address configuration flag. When set, this
                  message requests a new CoA to be returned by the
                  destination.

   U              Buffer flag. When set, the destination SHOULD buffer
                  any packets towards the node indicated in the options
                  of this message.

  Reserved       MUST be set to zero by the sender and ignored by
                 the receiver.


 Valid Options:

   Link-layer address of MN
                  The link-layer address of the MN that is
                  undergoing handover to the destination. This option
                  SHOULD be included to help the destination
                  recognize the MN when it connects to the
                  destination.

   Previous Care of Address
                  The IP address used by the MN while
                  attached to the originating router. This option
                  SHOULD be included so that host route can be
                  established in case necessary.

   New Care of Address
                  The IP address the MN wishes to use when
                  connected to the destination. When the `S' bit is
                  set, NAR MAY use this address in its stateful
                  assignment.

   If Handover Acknowledge (HAck) message is not received as a response,
   the Handover Initiate SHOULD be re-sent up to HI_RETRIES times using
   a short retransmission timer with a value no less than twice the
   round trip time between source and destination or 100 ms if RTT is
   not known.









Koodli (Editor)             Expires 10 April 2004              [Page 21]

Internet Draft              Fast Handovers               10 October 2003


   6.2.2. Handover Acknowledge (HAck)

   The Handover Acknowledgment message is a new ICMPv6 message that MUST
   be sent (typically by NAR to PAR) as a reply to the Handover Initiate
   message.



    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Code       |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Identifier             |H|T|R|      Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Options...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



             Figure 7: Handover Acknowledge (HAck) Message




 IP Fields:

   Source Address
                Copied from the destination address of the Handover
                Initiate Message to which this message is a
                response.

   Destination Address
                Copied from the source address of the Handover
                Initiate Message to which this message is a
                response.

   Hop Limit      255

   Authentication Header
                  A Security Association MUST exist between the
                  sender and the receiver of this message. This message
                  MUST be authenticated and so the authentication
                  header MUST be used when this message is sent.

 ICMP Fields:

   Type          TBA




Koodli (Editor)             Expires 10 April 2004              [Page 22]

Internet Draft              Fast Handovers               10 October 2003


   Code
                0: Handover Accepted, NCoA valid
                1: Handover Accepted, NCoA not valid
                2: Handover Accepted, NCoA in use
                3: Handover Accepted, NCoA assigned (Stateful)
                4: Handover Accepted, NCoA not assigned (Stateful)
              128: Handover Not Accepted, reason unspecified
              129: Administratively prohibited
              130: Insufficient resources

   Checksum       The ICMP checksum.

   Identifier     Copied from the corresponding field in the Handover
                  Initiate message this message is in response to.

   Reserved       MUST be set to zero by the sender and ignored by
                  the receiver.

 Valid Options:

   New Care of Address
        If the S flag in the Handover Initiate message is set,
        this option MUST be used to provide NCoA the MN should
        use when connected to this router. This option MAY be
        included even when `S' bit is not set, e.g., Code 2
        above.

   Upon receiving the HI message, the NAR MUST respond with a Handover
   Acknowledge message.  If the `S' flag is set in the HI message, the
   NAR SHOULD include the New Care of Address option and a Code of 3.

   If the `S' flag is not set in the HI message, the NAR MUST check the
   validity of the NCoA when sent with HI, and reply with appropriate
   Code values enumerated above.  If NCoA is valid, the NAR SHOULD
   insert NCoA in its Proxy Neighbor Cache and defend NCoA for
   PROXY_ND_LIFETIME period of time during which the MN is expected to
   connect to NAR. If the NCoA is not valid or not assigned, the NAR
   MUST respond with an appropriate Code value.

   The NAR MAY provide support for PCoA (instead of accepting or
   assigning NCoA) and establish a host route entry for PCoA, and set up
   a tunnel to the PAR to forward MN's packets sent with PCoA as source
   IP address.  This host route entry SHOULD be used to forward packets
   once the NAR detects that the particular MN is attached to its link.

   Finally, the new access router can always refuse handover, in which
   case it should indicate the reason in one of the available Code
   values.




Koodli (Editor)             Expires 10 April 2004              [Page 23]

Internet Draft              Fast Handovers               10 October 2003


   6.3. New Mobility Header Messages

   Mobile IPv6 uses a new IPv6 header type called Mobility Header [3].
   The Fast Binding Update, Fast Binding Acknowledgment and Fast
   Neighbor Advertisement messages use the Mobility Header.


   6.3.1. Fast Binding Update (FBU)

   The Fast Binding Update message is identical to the Mobile IPv6
   Binding Update (BU) message.  However, the processing rules are
   slightly different.  The Mobility Header Type value for FBU is 8.



                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |          Sequence #           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|H|L|K|        Reserved       |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                        Mobility options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





              Figure 8: Fast Binding Update (FBU) Message

      IP fields:

         Source address      The PCoA or NCoA

         Destination Address
                             The IP address of the Previous Access
                             Router

      `A' flag        MUST be set to one to request PAR to send a Fast
                      Binding Acknowledgement message.

      `H' flag        MUST be set to one.  See [3].

      `L' flag        See [3].

      `K' flag        See [3].



Koodli (Editor)             Expires 10 April 2004              [Page 24]

Internet Draft              Fast Handovers               10 October 2003


      Reserved        This field is unused.  MUST be set zero.

      Sequence Number See [3].

      Lifetime        See [3].

      Mobility Options
                      MUST contain alternate CoA option set to NCoAIP
                      address when sent FBU is sent from PAR's link.
                      MAY contain alternate CoA option set to NCoA when
                      FBU is sent from NAR's link.

   The MN sends FBU message any time after receiving a PrRtAdv message.
   If the MN moves prior to receiving a PrRtAdv message, it SHOULD send
   a FBU to the PAR after configuring a new CoA on the NAR.

   The source IP address is PCoA when FBU is sent from PAR's link, and
   the source IP address is NCoA when sent from NAR's link.  When FBU is
   sent from NAR's link, it SHOULD be encapsulated within FNA.

   The FBU MUST also include the Home Address Option and the Home
   Address is PCoA. A FBU message MUST be protected in a way appropriate
   for MN and PAR communication.  That is, PAR MUST be able to determine
   that the FBU message is sent by a genuine MN.


   6.3.2. Fast Binding Acknowledgment (FBack)

   The Fast Binding Acknowledgment message is sent by the PAR to
   acknowledge receipt of a Fast Binding Update message in which the `A'
   bit is set.  The Fast Binding Acknowledgment message SHOULD NOT be
   sent to the MN before the PAR receives a HAck message from the NAR.
   The Fast Binding Acknowledgment MAY also be sent to the MN on the old
   link.  The Mobility Header Type value for FBACK is 9.

      IP fields:

         Source address      The IP address of the Previous Access
                             Router

         Destination Address The NCoA

      Status
                        8-bit unsigned integer indicating the
                        disposition of the Fast Binding Update.  Values
                        of the Status field less than 128 indicate that
                        the Binding Update was accepted by the receiving
                        node.  The following such Status values are
                        currently defined:



Koodli (Editor)             Expires 10 April 2004              [Page 25]

Internet Draft              Fast Handovers               10 October 2003



                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |    Status     |K|  Reserved   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Sequence #          |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                        Mobility options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





         Figure 9: Fast Binding Acknowledgment (FBack) Message



                        0 Fast Binding Update accepted
                        1 Fast Binding Update accepted but NCoA is
                        invalid.  Use NCoA supplied in ``alternate''
                        (e.g., stateful) CoA


                        Values of the Status field greater than or equal
                        to 128 indicate that the Binding Update was
                        rejected by the receiving node.  The following
                        such Status values are currently defined:

                        128 Reason unspecified
                        129 Administratively prohibited
                        130 Insufficient resources
                        131 Incorrect interface identifier length


      `K' flag          See [3].

      Reserved          An unused field.  MUST be set to zero.

      Sequence Number   Copied from FBU message for use by the MN in
                        matching this acknowledgment with an outstanding
                        FBU.

      Lifetime
                        The granted lifetime in seconds for which the




Koodli (Editor)             Expires 10 April 2004              [Page 26]

Internet Draft              Fast Handovers               10 October 2003


                        sender of this message will retain a binding for
                        traffic redirection.

      Mobility Options  MUST contain ``alternate'' CoA if Status is 1.


   6.3.3. Fast Neighbor Advertisement (FNA)

   A MN sends a Fast Neighbor Advertisement to announce itself to the
   NAR. The Mobility Header Type value for FBACK is 10.  When the
   Mobility Header Type is FNA, the Payload Proto field may be set to
   IPv6 in order to assist FBU encapsulation.



                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                        Mobility Options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





          Figure 10: Fast Neighbor Advertisement (FNA) Message

      IP fields:

         Source address      NCoA

         Destination Address NAR's IP address

      Mobility Options  MUST contain the Link-Layer Address

   The MN sends Fast Neighbor Advertisement to the NAR, as soon as it
   regains connectivity on the new link to announce its attachment so
   that arriving or buffered packets can be immediately forwarded.  If
   NAR is proxying NCoA, it creates a neighbor cache entry in REACHABLE
   state.  If there is no entry at all, it creates one and sets it
   to REACHABLE. If there is an entry in INCOMPLETE state without a
   link-layer address, it sets it to REACHABLE. During the process of
   creating a neighbor cache entry, NAR can also detect if NCoA is in
   use, thus avoiding address collisions.  Since FBU is encapsulated
   within FNA when sent from NAR's link, NAR drops FBU in case it
   detects any collision.



Koodli (Editor)             Expires 10 April 2004              [Page 27]

Internet Draft              Fast Handovers               10 October 2003


   The combination of NCoA (present in source IP address) and the
   Link-Layer Address (present as a Mobility Option) SHOULD be used to
   distinguish the MN from other nodes.


   6.4. New ICMP Options

   6.4.1. IP Address Option

   This option is sent in the Proxy Router Advertisement, the Handover
   Initiate, and Handover Acknowledge messages.  The Proxy Router
   Advertisement and Handover Acknowledgment messages only contain the
   NCoA while the Handover Initiate message may include both NCoA and
   PCoA. The format is based on [4].


   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length     |   Sub-Type    | Prefix Length |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Reserved                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                          IPv6 Address                         +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                     Figure 11: IPv6 Address Option




   Type
        TBA

   Length
        size of this option units of 8 octets (i.e., 3)

   Sub-Type
        1   Old Care-of Address
        2   New Care-of Address




Koodli (Editor)             Expires 10 April 2004              [Page 28]

Internet Draft              Fast Handovers               10 October 2003


   Prefix Length
        The Length of the IPv6 Address Prefix

   IPv6 address
        The IP address for the unit defined by the Type field.



   6.4.2. New Router Prefix Information Option

   This option is sent in the PrRtAdv message in order to provide the
   prefix information valid on the NAR.



  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length     |    Sub-Type   | Prefix Length |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                            Prefix                             +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



            Figure 12: New Router Prefix Information Option



   Type
        TBA

   Length
        The length of the option (including the type, sub-type and
        length fields) in units of 8 octets.

   Sub-Type
        0

   Prefix Length
        8-bit unsigned integer.  The number of leading bits in the
        Prefix that are valid.  The value ranges from 0 to 128.




Koodli (Editor)             Expires 10 April 2004              [Page 29]

Internet Draft              Fast Handovers               10 October 2003


   Prefix
        An IP address or a prefix of an IP address.  The Prefix Length
        field contains the number of valid leading bits in the prefix.
        The bits in the prefix after the prefix length are reserved
        and MUST be initialized to zero by the sender and ignored by
        the receiver.


   6.4.3. Link-layer Address (LLA)



   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length     |   Sub-Type    |     LLA ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  Figure 13: Link-Layer Address Option



   Type
        TBA

   Length
        The length of the option (including the type, sub-type and
        length fields) in units of 8 octets.

   Sub-Type
        0 wildcard requesting resolution for all nearby access points
        1 Link-layer Address of the new Attachment Point.
        2 Link-layer Address of the MN.
        3 Link-layer Address of the Proxied Originator

   LLA
        The variable length link-layer address.

   The New Attachment Point Link Layer address contains the link-layer
   address of the attachment point for which handover is about to
   be attempted.  This is used in the Router Solicitation for Proxy
   message.

   The MN Link-Layer address option contains the link-layer address of a
   MN. It is used in the Handover Initiate message.





Koodli (Editor)             Expires 10 April 2004              [Page 30]

Internet Draft              Fast Handovers               10 October 2003


   The Proxied Originator Link-Layer address option contains the
   Link Layer address of the Access Router for which the Proxy Router
   Solicitation message refers to.

   These options MUST be silently ignored when used with other Neighbor
   Discovery messages.


   6.4.4. Neighbor Advertisement Acknowledgment (NAACK)



   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length     |   Sub-Type    |     Status    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




        Figure 14: Neighbor Advertisement Acknowledgment Option


   Type
        TBA

   Length
        8-bit unsigned integer.  Length of the option, in 8 octets,
        excluding the Option Type and Option Length fields.

   Sub-Type
        0

   Status
        8-bit unsigned integer indicating the disposition of the Fast
        Binding Update.  Values of the Status field less than 128
        indicate that the Binding Update was accepted by the receiving
        node.  The following such Status values are currently defined:

           0   The New CoA is valid
           1   The New CoA is invalid
           2   The New CoA is invalid, use the supplied CoA
         128   Link Layer Address unrecognized

   The NAR responds to FNA with the NAACK option to notify the MN
   to use a different NCoA when there is address collision.  If the
   NCoA is invalid, the Router Advertisement MUST use the PCoA as the
   destination address, available from the HI message.  The MN SHOULD



Koodli (Editor)             Expires 10 April 2004              [Page 31]

Internet Draft              Fast Handovers               10 October 2003


   use the NCoA supplied along with the NAACK option.  If the NAACK
   indicates that the Link Layer Address is unrecognized the MN MUST NOT
   use the NCoA or the PCoA and SHOULD start immediately the process of
   acquiring a NCoA at the NAR.

   In the future, new option types may be defined.


   7. Configurable Parameters

      Parameter Name       Default Value            Definition
      -------------------  ----------------------   -------
      RTSOLPR_RETRIES      2
      GR_PRRTADV_RETRIES   2
      FBU_RETRIES          3                        Section 4
      PROXY_ND_LIFETIME    1 second                 Section 6.2.2
      HI_RETRIES           4                        Section 6.2.1




   8. Security Considerations

   The following security vulnerabilities are identified, and suggested
   solutions mentioned.

    1. Insecure FBU: in this case, packets meant for one address could
       be stolen, or redirected to some unsuspecting node.  This concern
       is the same as that in a MN and Home Agent relationship.

       Hence, the PAR MUST ensure that the FBU packet arrived from a
       node that legitimately owns the PCoA. The access router and its
       hosts may use any available mechanism to establish a security
       association which MUST be used to secure FBU. The current version
       of this protocol does not specify how this security association
       is established.  However, the future work, either as part of this
       document or in a separate document, may specify this security
       establishment.

       If an access router can ensure that the source IP address in
       an arriving packet could only have originated from the node
       whose link-layer address is in the router's neighbor cache, then
       a bogus node cannot use a victim's IP address for malicious
       redirection of traffic.  Such an operation is recommended at
       least on neighbor discovery messages including the RtSolPr
       message.

    2. Secure FBU, malicious or inadvertant redirection:  in this case,
       the FBU is secured, but the target of binding happens to be an



Koodli (Editor)             Expires 10 April 2004              [Page 32]

Internet Draft              Fast Handovers               10 October 2003


       unsuspecting node either due to inadvertant operation or due
       to malicious intent.  This vulnerability can lead to a MN with
       genuine security association with its access router redirecting
       traffic to an incorrect address.

       However, the target of malicious traffic redirection is limited
       to an interface on an access router with which the PAR has a
       security association.  The PAR MUST verify that the NCoA to
       which PCoA is being bound actually belongs to NAR's prefix.
       In order to do this, HI and HAck message exchanges are to be
       used.  When NAR accepts NCoA in HI, it proxies NCoA so that
       any arriving packets are not sent on the link until the MN
       attaches and announces itself through FNA. So, any inadvertant or
       malicious redirection to a host is avoided.  It is still possible
       to jam NAR's buffer with redirected traffic.  However, since
       NAR's handover state corresponding to NCoA has a finite (and
       short) lifetime corresponding to a small multiple of anticipated
       handover latency, this loophole is not significant.

    3. Sending FBU from NAR's link:  a malicious node may send FBU from
       NAR's link providing an unsuspecting node's address as NCoA.
       Since FBU is encapsulated in FNA, NAR should detect the collision
       with an address in use when processing FNA, and it then drops
       FBU. When NAR is unable to detect address collisions, there is a
       vulnerability that redirection can affect an unsuspecting node.


   9. Contributors

   This document originated from the fast handover design team effort.
   The members of this design team in alphabetical order were; Gopal
   Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham
   Soliman, George Tsirtsis and Alper Yegin.


   10. Acknowledgments

   The editor would like to thank all the interested folks who have
   provided feedback on this specification.  The editor would like
   to acknowledge the contribution from James Kempf to improve this
   specification.  And, the working group chairs have been very
   supportive.


   References

   [1] S. Bradner.  Key words for use in RFCs to Indicate Requirement
       Levels.  Request for Comments (Best Current Practice) 2119,
       Internet Engineering Task Force, March 1997.



Koodli (Editor)             Expires 10 April 2004              [Page 33]

Internet Draft              Fast Handovers               10 October 2003


   [2] A. Conta and S. Deering.  Internet Control Message Protocol
       (ICMPv6) for the Internet Protocol Version 6 (IPv6)
       Specification.  Request for Comments (Draft Standard) 2463,
       Internet Engineering Task Force, December 1998.

   [3] D. Johnson, C. Perkins, and J. Arkko.  Mobility Support in IPv6
       (work in progress).  Internet Draft, Internet Engineering Task
       Force, 2002.

   [4] M. Khalil, R. Narayanan, H. Akhtar, and E. Qaddoura.  Mobile IP
       Extensions Rationalization (MIER) (work in progress).  Internet
       Draft, Internet Engineering Task Force.
       draft-ietf-mobileip-mier-05.txt, February 2000.

   [5] S. Thomson and T. Narten.  IPv6 Stateless Address
       Autoconfiguration.  Request for Comments (Draft Standard)
       2462, Internet Engineering Task Force, December 1998.


   A. Change Log

   The following changes have taken place since the previous version.
   The Section numbers refer to version 06.

    -  Revised the security considerations section in v07

    -  Refined and added a section on network-initiated handover v07

    -  Section 3 format change

    -  Section 4 format change (i.e., no subsections).

    -  Description in Section 4.4 merged with ``Fast or Erroneous
       Movement''

    -  Section 4.5 deprecated

    -  Section 4.6 deprecated

    -  Revision of some message formats in Section 6


   B. Contact Information

   The design team member's contact information:


     Gopal Dommety
     Cisco Systems, Inc.



Koodli (Editor)             Expires 10 April 2004              [Page 34]

Internet Draft              Fast Handovers               10 October 2003


     170 West Tasman Drive
     San Jose, CA 95134
     Phone:+1 408 525 1404
     E-Mail: gdommety@cisco.com

     Karim El Malki
     Ericsson Radio Systems AB
     LM Ericssons Vag. 8
     126 25 Stockholm
     SWEDEN
     Phone:  +46 8 7195803
     Fax:    +46 8 7190170
     E-mail: Karim.El-Malki@era.ericsson.se

     Mohamed Khalil
     Nortel Networks
     E-Mail: mkhalil@nortelnetworks.com

     Charles E. Perkins
     Communications Systems Lab
     Nokia Research Center
     313 Fairchild Drive
     Mountain View, California 94043
     USA
     Phone:  +1-650 625-2986
     E-Mail:  charliep@iprg.nokia.com
     Fax:  +1 650 625-2502

     Hesham Soliman
     Flarion Technologies
     E-mail: H.Soliman@flarion.com

     George Tsirtsis
     Flarion Technologies
     E-Mail: G.Tsirtsis@flarion.com

     Alper E. Yegin
     NTT DoCoMo Labs USA
     E-mail: alper@docomolabs-usa.com


   The editor's contact information:

     Rajeev Koodli
     Nokia Research Center
     313 Fairchild Drive
     Mountain View, CA 94043 USA
     Phone: +1 650 625 2359
     Fax: +1 650 625 2502



Koodli (Editor)             Expires 10 April 2004              [Page 35]

Internet Draft              Fast Handovers               10 October 2003


     E-Mail: Rajeev.Koodli@nokia.com



















































Koodli (Editor)             Expires 10 April 2004              [Page 36]


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