[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Mobile IP Working Group                            Rajeev Koodli, Editor
INTERNET DRAFT                                     Nokia Research Center
30 September 2002


                     Fast Handovers for Mobile IPv6
                 draft-ietf-mobileip-fast-mipv6-05.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 describes how a Mobile Node can maintain connectivity
   to the Internet when it changes its Access Router for another, a
   process referred to as handover.  During this process, there is
   a time period when the Mobile Node is unable to send or receive
   IPv6 packets both due to link switching delay and IP protocol
   operations.  This time period is referred to as handover latency.  In
   many instances, the handover latency resulting from standard Mobile
   IPv6 handover procedures could be greater than what is acceptable
   to support real-time or delay sensitive traffic.  Furthermore,
   reducing the handover latency could be beneficial to non real-time,
   throughput-sensitive applications as well.  The intent of this
   document is to describe protocol enhancements to reduce handover
   latency due to IP protocol operations as small as possible in
   comparison to the inevitable link switching latency.



Koodli (Editor)              Expires 30 March 2003              [Page i]


Internet Draft             Fast Handovers              30 September 2002




                                 Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       2

 2. Terminology                                                        2

 3. Protocol Overview                                                  4
     3.1. Handover Initiation . . . . . . . . . . . . . . . . . . .    4
     3.2. Tunnel Establishment  . . . . . . . . . . . . . . . . . .    5
     3.3. Packet Forwarding on the Tunnel . . . . . . . . . . . . .    6

 4. Protocol Details                                                   6
     4.1. Handover Initiation . . . . . . . . . . . . . . . . . . .    7
           4.1.1. Anticipation  . . . . . . . . . . . . . . . . . .    7
           4.1.2. No Anticipation . . . . . . . . . . . . . . . . .    8
     4.2. Tunnel Establishment between the Access Routers . . . . .    9
     4.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . .   11
     4.4. Three Party Handover  . . . . . . . . . . . . . . . . . .   12
     4.5. Optimization using link-layer assisted features . . . . .   12
           4.5.1. Renewing Tunnel Lifetime  . . . . . . . . . . . .   15
     4.6. Three Party Handover with Layer 2 Trigger Support . . . .   16

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

 6. Message Formats                                                   25
     6.1. New Neighbor Discovery Messages . . . . . . . . . . . . .   25
           6.1.1. Router Solicitation for Proxy . . . . . . . . . .   25
           6.1.2. Proxy Router Advertisement (PrRtAdv)  . . . . . .   26
           6.1.3. Fast Neighbor Advertisement (FNA) . . . . . . . .   29
     6.2. Inter-Access Router Messages  . . . . . . . . . . . . . .   31
           6.2.1. Handover Initiate (HI)  . . . . . . . . . . . . .   31
           6.2.2. Handover Acknowledge (HACK) . . . . . . . . . . .   33
     6.3. Handover To Third (HTT) . . . . . . . . . . . . . . . . .   36
     6.4. New Mobility Header Messages  . . . . . . . . . . . . . .   36
           6.4.1. Fast Binding Update (FBU) . . . . . . . . . . . .   36
           6.4.2. Fast Binding Acknowledgment (FBACK) . . . . . . .   38
     6.5. New ICMP Options  . . . . . . . . . . . . . . . . . . . .   40



Koodli (Editor)             Expires 30 March 2003              [Page ii]


Internet Draft             Fast Handovers              30 September 2002


           6.5.1. IP Address Option . . . . . . . . . . . . . . . .   40
           6.5.2. New Router Prefix Information Option  . . . . . .   41
           6.5.3. Link-layer Address (LLA)  . . . . . . . . . . . .   42
           6.5.4. Neighbor Advertisement Acknowledgment (NAACK) . .   43
           6.5.5. Handover Capability Extension . . . . . . . . . .   44

 7. Configurable Parameters                                           45

 8. Security Considerations                                           45

 9. Contributors                                                      46

10. Acknowledgments                                                   46

11. Contact Information                                               47





































Koodli (Editor)              Expires 30 March 2003              [Page 1]


Internet Draft             Fast Handovers              30 September 2002


   1. Introduction

   Mobile IP 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 appreciable (especially) for
   real-time applications and throughput-sensitive applications.  This
   document describes a protocol to reduce this latency.

   This document addresses the following problem:  how to allow a MN to
   send packets as soon as it detects a new link, and how to deliver
   packets to a MN as soon as its presence is detected by the MN's new
   access router.  The solution allows a MN to keep using its Care of
   Address until it establishes itself as a Mobile IP end-point on its
   new access router.  The solution also allows a MN to expeditiously
   establish a new Care of Address.

   This 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, perhaps for even improved performance.  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 Router (AR)
               The MN's default router

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




Koodli (Editor)              Expires 30 March 2003              [Page 2]


Internet Draft             Fast Handovers              30 September 2002


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

      Anchor Access Router (AAR)
               The access router where the MN originally established
               its CoA (i.e., the CoA that is known to the HA and the
               Correspondent nodes).

      Anchor CoA (ACoA)
               The MN's Care of Address valid on AAR.

      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 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




Koodli (Editor)              Expires 30 March 2003              [Page 3]


Internet Draft             Fast Handovers              30 September 2002


      Bidirectional Tunnel (BT)
               A tunnel for both PAR and NAR to forward packets to and
               from MN's PCoA.



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



               Figure 1: Reference Scenario for Handover




   3. Protocol Overview

   The key protocol operation involves setting up a routing path between
   the two access routers to enable the MN to send and receive IP
   packets while it establishes itself as a Mobile IPv6 end-point.
   This tunnel establishment could be triggered by the MN requesting
   a handover, or by the network (i.e., PAR). Once the tunnel is
   established, packet forwarding on the tunnel to the MN begins when
   the PAR receives a Fast Binding Update message from the MN. So, there
   are three phases in the protocol operation:  handover initiation,
   tunnel establishment and packet forwarding.


   3.1. Handover Initiation

   The protocol is initiated when an event, such as a decision
   to handover the MN to a new point of attachment, occurs.  The
   ``trigger'' for protocol initiation may arrive from specific L2
   events or from policy rules that might determine the need for



Koodli (Editor)              Expires 30 March 2003              [Page 4]


Internet Draft             Fast Handovers              30 September 2002


   handover based on factors other than link connectivity alone (e.g.,
   cost, bandwidth changes, etc.).  These triggers themselves are not
   specified in this document.  Typically, it is the MN that responds to
   such a trigger by requesting its AR (i.e., PAR) to assist in handover
   by sending a Router Solicitation for a Proxy (RtSolPr) message in
   which it includes the link-layer identifier (such as a base station
   id or BSSID in IEEE 802.11 networks) of its prospective attachment
   point.  In response to RtSolPr message the PAR sends a Proxy Router
   Advertisement (PrRtAdv) message, which provides the link-layer
   address, and network prefix information about the NAR, and the NCoA
   (especially when stateful address configuration is required).  In the
   network-initiated handover, the PAR sends PrRtAdv message without the
   MN sending RtSolPr message, and provides the parameters necessary
   (i.e., link-layer address and IP address of the NAR) for the MN
   to send IP packets, as well as the network prefix for the MN to
   formulate a prospective new Care pf Address.

   The purpose of RtSolPr is to request parameters necessary for the MN
   to be able to send packets immeidately upon connecting to the NAR.
   The purpose of PrRtAdv is to supply these parameters and the network
   prefix information that would also allow the MN to formulate a NCoA.
   When the underlying link layer provides these parameters (by means
   outside the scope of this document), these messages are optional on
   such links.

   In addition, when appropriate link layer support to send RtSolPr is
   not available, the MN simply moves to a new link (without sending
   RtSolPr and receiving PrRtAdv in return) and then sends a Fast
   Binding Update to the PAR which then initiates tunnel establishment.


   3.2. Tunnel Establishment

   When the PAR receives a RtSolPr message, it transmits a Handover
   Initiate (HI) message to NAR, after looking up the IP address
   corresponding to the link-layer identifier supplied by the MN. The
   mechanism that PAR uses to resolve the IP address corresponding to
   the supplied link-layer identifier is not specified in this document.
   The HI message serves two purposes.  First, it initiates establishing
   a bidirectional tunnel between the two routers so that the MN can
   continue to use PCoA for its existing sessions.  Second, it serves to
   verify if NCoA (either supplied by the PAR or determined by the NAR
   when using stateful address configuration), when present, can be used
   on NAR's link.  In response to processing the HI message, the NAR
   sets up a host route for the MN's PCoA and responds with a Handover
   Acknowledge (HACK) message.  When the NCoA could be used, the NAR
   begins to proxy that address for a short duration.





Koodli (Editor)              Expires 30 March 2003              [Page 5]


Internet Draft             Fast Handovers              30 September 2002


   In the network-controlled handover, the PAR transmits HI message
   without receiving the RtSolPr message.


   3.3. Packet Forwarding on the Tunnel

   After it receives a PrRtAdv message, the MN sends a Fast Binding
   Update (FBU). The MN may also send an FBU after attaching to the NAR.
   This FBU message associates the MN's PCoA with NAR's IP address so
   that packets arriving at the PAR can be tunneled to the NAR.

   After it associates PCoA with NAR's IP address for forwarding
   purposes, the PAR sends a Fast Binding Acknowledgment (FBACK) message
   to the MN. The FBACK message confirms whether NCoA could be used,
   only after which the MN must use NCoA on the new link.  When the MN
   moves prior to receiving the FBACK message, it sends a Fast Neighbor
   Advertisement (FNA) message to the NAR requesting confirmation to
   use NCoA. As a response, the NAR sends a Router Advertisement with
   Neighbor Advertisement Acknowledge (NAACK) option that indicates
   whether the use of NCoA is acceptable.  When the MN moves after
   receiving the FBACK message, it simply announces its presence through
   a Neighbor Advertisement message.  In any case, it is allowed to use
   PCoA for its existing sessions with its correspondents during these
   operations.

   It is worthwhile to observe, in the light of recent Return
   Routability procedure for securing Binding Updates, that a
   correspondent node rejects packets sent with NCoA until a valid
   binding cache entry is established.  Hence, it is highly desirable to
   be able to continue using an address that exists in a correspondent's
   binding cache until the new address can be updated.  Furthermore,
   such an update, accomplished through the Binding Update procedure,
   itself should be expeditiously performed.  Thus, the combined use
   of tunneling (packets meant for PCoA) and anticipation (of NCoA) is
   likely to offer performance benefits and will be elaborated in the
   following sections.

   The overall handover protocol is illustrated in Figure 2.


   4. Protocol Details

   There are three phases in the protocol operation:  handover
   initiation, tunnel establishment and packet forwarding on the
   established tunnel.  We describe each of these phases separately.







Koodli (Editor)              Expires 30 March 2003              [Page 6]


Internet Draft             Fast Handovers              30 September 2002




              MN                    PAR                  NAR
               |                     |                    |
               |------RtSolPr------->|                    |
               |<-----PrRtAdv--------|--------HI--------->|
               |------F-BU---------->|<------HACK---------|
           Disconnect     <--F-BACK--|--F-BACK-->         |
               |                     |                    |
               |                   forward                |
               |                   packets===============>|
               |                     |                    |
               |                     |                    |
           Connect                   |                    |
               |                     |                    |
     send packets (including FNA)========================>|
               |<-----------RA (with NAACK option)--------|
               |<=================================== deliver packets
               |                                          |




               Figure 2: Fast Handover Protocol Messages



   4.1. Handover Initiation

   The handover initiation may occur while the MN is still attached to
   the PAR, or it may take place after it attaches to the NAR.


   4.1.1. Anticipation

   Either the MN or the PAR may initiate a handover by sending protocol
   messages defined in this document.  External events, such as a
   determination at link layer to undergo handover or a policy decision
   based on factors such as available bandwidth, cost etc, can cause
   handover initiation.  Such events oblige a MN to send a RtSolPr,
   and the PAR to send a PrRtAdv (either in response to RtSolPr or
   separately as a gratuitous message).

   The RtSolPr message allows a MN to initiate its handover by
   requesting the PAR to supply the IP address, link-layer address
   as well as network prefix of the NAR's interface to which the MN
   is handing over to.  In a network-controlled handover, the PAR
   may supply this information without the MN requesting it.  In




Koodli (Editor)              Expires 30 March 2003              [Page 7]


Internet Draft             Fast Handovers              30 September 2002


   either case, the PAR engages in tunnel establishment described in
   Section 4.2.

   It is possible that the PAR itself may initiate handover by
   gratuitously sending a PrRtAdv message.  When the PAR sends such a
   message without the MN sending a RtSolPr message first, the MN MUST
   be prepared to process PrRtAdv message, and send an Fast Binding
   Update message in response.

   The PrRtAdv indicates one of the three 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.  See Section 4.2.

    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.

    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
       new CoA that the MN should use or information on the network
       prefix that should be used to form a new CoA. 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).

   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
   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.  See Section 4.5.


   4.1.2. No Anticipation

   Anticipating a handover is not always possible.  Also, the interface
   between the link-layer handover mechanism and IP stack may not be



Koodli (Editor)              Expires 30 March 2003              [Page 8]


Internet Draft             Fast Handovers              30 September 2002


   well-defined or is available.  In such cases, the MN may change
   its link without engaging in protocol messages with the PAR on its
   previous link.  The MN SHOULD send a Fast Binding Update to the
   PAR as soon as it establishes connectivity with the NAR. This FBU
   message serves to establish a tunnel between the access routers.
   Establishing tunnels subsequent to regaining a new link is useful,
   for instance, in IEEE 802.11 wireless local area networks.  See
   Section 4.2.


   4.2. Tunnel Establishment between the Access Routers

   A bi-directional tunnel is established between the two access routers
   for the following purpose.  Since the MN cannot use NCoA until it
   completes Binding Update with its Home Agent and the correspondents,
   it is allowed to use PCoA until it establishes itself as a Mobile
   IPv6 end-point.  For this purpose, the NAR tunnels packets sent with
   PCoA as source IP address to the PAR. And, until the correspondent
   nodes establish a binding cache entry for NCoA, they continue to
   send packets to PCoA, which need to be forwarded to the MN. The PAR
   tunnels these packets to the NAR, which then forwards them using a
   host route entry to the MN. Since it is desirable to deliver these
   packets independent of NCoA configuration, the PAR tunnels packets to
   the NAR instead of to the NCoA. However, the MN MAY include NCoA as
   the target address for the tunnel.

   The tunnel establishment is achieved through Handover Initiate (HI)
   and Handover Acknowledge (HAck) messages.  The PAR MUST send the HI
   message to the NAR when PAR

    1. receives RtSolPr and determines that the MN needs to attach to
       NAR, or

    2. determines to send a gratuitous PrRtAdv message, or

    3. determines through link-layer specific mechanisms that the MN is
       attaching to NAR without sending PrRtAdv (See Section 4.5), or

    4. receives an FBU message from a MN for which it has not previously
       sent a HI message

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

    1. MUST create a host route for PCoA that 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




Koodli (Editor)              Expires 30 March 2003              [Page 9]


Internet Draft             Fast Handovers              30 September 2002


       explicit announcement by the MN or by other means, arriving
       packets do not invoke neighbor discovery.

    2. MUST set up a tunnel for packets arriving with PCoA as source IP
       address to be sent to PAR.

    3. MUST verify if NCoA (when) supplied in the HI message is a valid
       address for use, and if it is, it MUST also establish a proxy
       neighbor cache entry for NCoA and begin defending it.

    4. MUST allocate NCoA for the MN when stateful address configuration
       is used, create a proxy neighbor cache entry and begin defending
       it.

    5. MUST provide the status of handover request in Handover
       Acknowledge (HACK) message indicating whether the use of NCoA is
       acceptable.

   When the PAR receives HAck message, it completes the tunnel
   establishment.  In addition, the HAck message may also indicate
   whether the use of NCoA is acceptable.

   If the MN does not engage in protocol messages on its previous link
   (for whatever reason(s)), it SHOULD send an FBU, with PCoA as source
   IP address, as soon as it regains connectivity with the NAR. The NAR
   SHOULD tunnel the FBU to the PAR subject to following considerations.
   First, the ingress filtering rules allow packets sent with PAR's
   prefix in a source address to be forwarded.  Second, the destination
   IP address is that of the PAR. Note that both these conditions must
   be met for succesful completion of any HI and HAck message exchange
   in any case.

   When the PAR receives an FBU for which it has not received a RtSolPr
   message, it SHOULD send a HI message to the NAR. Upon receiving a
   corresponding HACK message, the PAR SHOULD send FBACK to the MN.
   Until the HACK is received, the PAR MAY buffer any packets arriving
   for the MN. The New Access Router MUST NOT tunnel packets from the MN
   with PCoA as source IP address destined for arbitrary correspondent
   nodes to PAR until a HI message is received, and the NAR MAY buffer
   any such packets.

   If the MN does not receive an FBACK message even after
   re-transmitting FBU for FBU_RX_TIMES, it MUST assume that
   fast handover support is not available and it MUST stop fast handover
   protocol operation.

   When the tunnel is established after the MN attaches to the NAR,
   there could be delay before packets are forwarded, and there could be




Koodli (Editor)             Expires 30 March 2003              [Page 10]


Internet Draft             Fast Handovers              30 September 2002


   packet loss unless the access routers buffer packets.  This delay and
   potential packet loss could be avoided through anticipation.


   4.3. Packet Forwarding

   When the MN receives a PrRtAdv message, it SHOULD send a Fast Binding
   Update (FBU) message preferably prior to disconnecting its link.  The
   MN MUST use PCoA as its source IP address in this message.  If the MN
   is unable to send an FBU before leaving the PAR, it SHOULD send it
   as soon as it regains connectivity with the NAR. This allows the PAR
   to actually start tunneling packets meant for the MN's PCoA. The MN
   SHOULD resend FBU if it has not received an FBACK up to a maximum of
   FBU_RETRIES.

   When the PAR receives an FBU, it MUST first verify that requested
   handover is accepted by the NAR as indicated in the HACK message
   status code.  Then, it MUST verify that the source IP address in FBU
   is PCoA for which PAR has forwarded packets previously.  And, it
   MUST create a tunnel for forwarding packets meant for PCoA to NAR.
   Finally, it MUST send a Fast Binding Acknowledgment (FBACK) message
   to the MN. This message SHOULD be sent on the old link as well.
   Reception of FBACK completes the fast handover protocol operation.

   As soon as the MN establishes link connectivity with the NAR, it

    1. MUST send a Fast Neighbor Advertisement (FNA) message (See 6.1.3)
       if it has not received a confirmation in an FBACK message to use
       NCoA. This message MUST be sent with PCoA as source IP address.
       Only after it receives a confirmation to use NCoA in a Router
       Advertisement with Neighbor Advertisement Acknowledge (NAACK)
       option (See 6.5.4), the MN MUST use NCoA. If the MN has received
       confirmation to use NCoA, it MAY send a Router Solicitation
       anyway with NCoA as source IP address.

    2. SHOULD send a Router Solicitation in order to be able to send an
       FBU when not using anticipation.  The source IP address in this
       message MUST be unspecified.

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

    1. delete the proxy neighbor cache entry.

    2. create a neighbor cache entry and set its state to REACHABLE.

    3. enable the host route entry so that any buffered packets could be
       delivered.




Koodli (Editor)             Expires 30 March 2003              [Page 11]


Internet Draft             Fast Handovers              30 September 2002


    4. send a router advertisement with Neighbor Advertisement Ack
       (NAACK) option (See Section 6.5.4) confirming the use of NCoA.

   When it is not acceptable to use NCoA, NAR MUST still send a router
   advertisement with NAACK option in which it provides the error
   code.  The NAR MUST still enable the host route entry to deliver any
   buffered packets.  The MN MUST follow [6] in order to configure a new
   IP address, and it should use the parameters supplied in the router
   advertisement.  Note that the MN is allowed to send packets using
   PCoA during the time it is involved in confirming the use of NCoA.

   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.

   Once the MN completes the Binding Update procedure with its
   correspondent node(s), it SHOULD start using NCoA as its source IP
   address.  In any case, the bidirectional tunnel between the access
   routers has a lifetime of BT_LIFETIME, after which time, packets
   using PCoA as source IP address will be discarded unless there is
   optional protocol support for tunnel lifetime renewal which will be
   specified in a subsequent revision of this document.


   4.4. Three Party Handover

   The MN may move from NAR to another AR (NAR') before completing
   its Layer 3 handover and performing binding updates to its
   correspondents.  If the MN moves before configuring a NCoA on NAR,
   PAR would still be considered its default router when it attaches
   to NAR'. Hence, the MN SHOULD send an FBU to PAR to set up a tunnel
   between PAR and NAR'. On the other hand, if the MN is able to
   configure a NCoA on NAR, but is unable to update all or a partial
   list of its correspondents, the MN MAY send an FBU to PAR. This FBU
   may be in addition to the FBU it sends to NAR. The result in this
   case is that the MN should be able to receive packets arriving at
   PCoA and NCoA through potentially different tunnels.  If the MN
   returns to PAR without completing Mobile IPv6 updates, it MUST send
   an FBU with lifetime set to zero so that PAR can disable any outgoing
   tunnels.

   The three party handover without IP signaling messages over the air
   interface is described in Section 4.6.


   4.5. Optimization using link-layer assisted features

   In this section, we describe how the tunnel between the access
   routers could be set up without IP signaling messages over



Koodli (Editor)             Expires 30 March 2003              [Page 12]


Internet Draft             Fast Handovers              30 September 2002


   the air interface when the underlying link layer provides the
   functionality of handover initiation messages defined in Section 4.1.
   Specifically, a ``Source Link Layer Trigger'' or a ``Target Link
   Layer Trigger'' could be used to initiate the HI and HAck exchange.
   Note however, that actual packet forwarding takes place after an FBU
   is processed.  The exact time when packet forwarding begins, after
   an FBU has been successfully processed, could make use of link-layer
   triggers.  The link layer triggers are described in [4].

   We denote by L2-ST a Source Trigger at PAR prior to L2 handover, by
   L2-TT a Target Trigger at NAR subsequent to L2 handover completion.
   We also denote by L2-LD a Link Down trigger at PAR that indicates
   when a link with the MN is terminated, and by L2-LU a Link Up trigger
   at NAR that indicates that a MN has (just) established a new link.

   The following diagram illustrates tunnel establishment without using
   IP messages.



      1a. L2-ST ~~~~> +------+ 2. HI    +------+ <~~~ 1b. L2-TT
                      | PAR  |<-------->| NAR  |
          4a. L2-LD~> +------+ 3. HACK  +------+ <~~~ 4b. L2-LU
                         ^                  ^
               old L2    |                  |     new L2
                         +-------+    +-----+
                                 |    |
                                 |    |
                                 V    V
                                +------+  movement
                 4c. L2-LU ---> |  MN  | --------->
                                +------+




           Figure 3: Tunnel Establishment without IP messages


   The following describes the progress of a two party handover.  The
   numbered items refer to steps in Figure 3.

  1. Either the PAR or NAR receives an L2 trigger informing it
  that a certain MN is about to be moved. The two cases are:

   a. The L2 trigger is a source trigger (L2-ST) at PAR. The
   trigger contains the MN's L2 address and an IP identifier
   (L2 address that can be mapped to an IP address or the IP
   address directly) for NAR.



Koodli (Editor)             Expires 30 March 2003              [Page 13]


Internet Draft             Fast Handovers              30 September 2002



   b. The L2 trigger is a target trigger (L2-TT) at NAR. The
   trigger contains the MN's L2 address and an IP identifier
   for PAR.

   2. The AR receiving the trigger MUST send a HI to the other AR.
   There two cases:

    a. If PAR is sending the HI, the `H' bit MUST be set, indicating
    it is based on source trigger. The HI MUST contain a
    Lifetime option, an IP address option containing the MN's
    PCoA, and an Link Layer Address (LLA) option containing the
    MN's L2 address. The Lifetime option MUST contain the
    amount of time the PAR is willing to extend tunnel service
    to the MN's packets before the NAR must renew the tunnel. If
    the lifetime is zero, the PAR is not willing to tunnel any
    packets for MN.

    b. If NAR is sending the HI, the `T' bit MUST be set, indicating
    it is based on a target trigger. The HI MUST contain a
    Lifetime option, and an LLA option containing the MN's L2.
    The Lifetime option MUST contain
    a request for the amount of time the PAR should extend
    tunnel service for the MN's packets.

  3. The AR receiving the HI MUST send a HAck to the other AR.
  There are two cases:

   a. If PAR is sending the HACK, the `T' bit MUST be set. The HAck
   MUST contain a Lifetime option, an IP address option
   containing the MN's PCoA, and an LLA containing the MN's L2
   address. The Lifetime option MUST contain the amount of
   time the oAR is willing to extend tunnel service to the
   MN's packets before NAR must renew the request. If the
   lifetime is zero, the PAR is not willing to extend tunnel
   service to the MN.

   b. If NAR is sending the HAck, the `H' bit MUST be set. No
   additional information is required, the sequence number
   identifies the reply.

  4. Start of L2 handover is signaled by an L2-LD trigger at PAR
  and MN. Completion of L2 handover is signaled by an L2-LU
  trigger at NAR and MN. Each handles the trigger in the
  following way:

   a. When the PAR receives the L2-LD trigger, it MUST begin
   forwarding MN-bound packets on the tunnel to NAR only if PAR
   has successfully processed an FBU.



Koodli (Editor)             Expires 30 March 2003              [Page 14]


Internet Draft             Fast Handovers              30 September 2002



   b. When the NAR receives the L2-LU trigger, it MUST begin
   delivering packets to the MN and MUST forward any outbound
   packets from MN through the tunnel to PAR.

   c. Subsequent to establishing a new link, the MN SHOULD configure a
   NCoA. The MN MAY defer obtaining a NCoA, however, using PCoA after the
   tunnel lifetime expires would result in packet discarding unless an
   optional protocol support for extensing the tunnel lifetime is
   implemented.

  5. The PAR becomes an AAR if MN should move again without having
  changed CoA to NAR's subnet, PCoA becomes ACoA, and NAR
  becomes PAR.

  6. Should L2 handover fail in Step 4 and a ping-pong situation
  arise, the PAR MUST cancel the tunnel by sending an HI with R
  bit set to NAR and a Lifetime option having value zero. In
  this case, the PAR simply continues delivering packets to MN
  on the old link exactly as if no handover had been pending.


   The tunnel between the access routers is terminated when BT_LIFETIME
   expires.  However, the following protocol in Section 4.5.1 can be
   used to renew the tunnel lifetime.


   4.5.1. Renewing Tunnel Lifetime

   The support for protocol described in this section is optional.

   In order to extend the lifetime of the tunnel, the NAR MUST send a
   HI message including a proposed new lifetime to PAR, and PAR MUST
   reply with a HAck indicating whether the tunnel can be extended.
   An error code of 131 is returned if extension is not possible (See
   Section 6.2.2).  In order to terminate the tunnel, either PAR or NAR
   MUST send a HI message with a lifetime of zero.  The default tunnel
   lifetime is BT_LIFETIME. NAR SHOULD send a tunnel renewal message
   prior to the expiration of BT_LIFETIME_WARNING, in order that the
   MN has sufficient time to complete NCoA configuration.  Whether or
   not the tunnel lifetime can be extended and how many times it can
   be extended is subject to network operator policy and SHOULD be
   configurable.

   When a tunnel can no longer be renewed upon the expiration of
   BT_LIFETIME_WARNING, the NAR MUST send the MN an unsolicited Router
   Advertisement in the event it must terminate the tunnel for any
   reason prior to the MN's configuring it's NCoA. The MN SHOULD




Koodli (Editor)             Expires 30 March 2003              [Page 15]


Internet Draft             Fast Handovers              30 September 2002


   initiate NCoA configuration immediately upon receipt of the RA, or
   risk losing forwarding service to PCoA.


   4.6. Three Party Handover with Layer 2 Trigger Support

   The support for protocol described in this section is optional.

   Three party handover occurs when the MN is on AAR, then moves to PAR,
   then moves to NAR before completing MIP registration at PAR. The lack
   of MIP registration may result from either a specific decision by
   the MN due to an ongoing real time media stream, or it may result
   from rapid movement between PAR and NAR that does not allow enough
   time for the registration to complete.  This situation is shown in
   Figure 4 below.  In this case, PAR must inform NAR to contact AAR
   about moving the radio directed end of the tunnel.  This is performed
   with the Handover To Third (HTT) message.



                               +------+
                          +--->| AAR  |<---+
                          |    +------+    |
             4b. HI(r)    |                | 3. HI(t)
                 HACK (r) |                |    HACK(t)
                          |                |
                          v    2a. HI      v
       1a. L2-ST ~~~> +------+     HTT  +------+ <~~~ 1b. L2-TT
                      | PAR  |<-------->| NAR  |
      4a. L2-LD ~~~>  +------+ 2b. HTT  +------+ <~~~ 5a. L2-LU
                         ^         HACK     ^
               old L2    |                  |     new L2
                         +-------+    +-----+
                                 |    |
                                 |    |
                                 V    V
                                 +------+  movement
                  5b. L2-LU ~~~> |  MN  | --------->
                                 +------+


            Figure 4: Three Party Handover with L2 Triggers


   The general idea behind the three party handover procedure is that
   the PAR supplies NAR with the same information it would have obtained
   via an L2-TT if handover had occurred with AAR, then the NAR performs
   an HI/HACK sequence with AAR in order to move the BT to NAR. When the
   L2 handover is complete, PAR sends an HI to AAR to terminate the BT.



Koodli (Editor)             Expires 30 March 2003              [Page 16]


Internet Draft             Fast Handovers              30 September 2002


   The following describes the progress of a three party handover.  The
   numbered items refer to steps in Figure 4.

  1. Either the PAR or NAR receives an L2 trigger informing it
  that a certain MN is about to be moved. The two cases are:

   a. The L2 trigger is a source trigger (L2-ST) at PAR. The
   trigger contains the MN's L2 address and an IP identifier
   (L2 address that can be mapped to an IP address or the IP
   address directly) for NAR.

   b. The L2 trigger is a target trigger (L2-TT) at NAR. The
   trigger contains the MN's L2 address and an IP identifier
   for PAR.

  2. The PAR and NAR exchange a HTT/HI or HACK/HTT pair. There are
  two cases:

   a. The L2 trigger is an L2-ST. The PAR MUST send HTT to NAR
   containing the IP address of AAR and two LLAs. The first
   LLA MUST contain the L2 address of the MN, the second MUST
   contain the L2 address of the AAR. This is enough
   information for NAR to perform a target trigger handover
   with AAR. The NAR MUST respond with a HACK.

   b. The L2 trigger is an L2-TT. The NAR MUST send a HI to PAR,
   exactly as if a two party target triggered handover were
   occurring. The PAR MUST responds with HTT containing the IP
   address of AAR and two LLAs. The first LLA MUST contain the
   L2 address of the MN, the second MUST contain the L2
   address of the AAR. This is enough information for NAR to
   perform a target trigger handover with AAR.

  3.  The NAR MUST first check its routing tables to see whether
  it is already tunneling for MN. If so, Step 6 is performed.
  If not, NAR MUST perform a target trigger handover with AAR,
  exactly as in Section 3.3, exchanging a HI/HACK pair. Because
  AAR receives no L2 trigger indicating when to start handover,
  it MAY place the BT to NAR upon transmission of the HACK, or
  alternatively it MUST wait to establish the BT with NAR
  until PAR signals that L2 handover has begun in Step 4.

  4. At the start of L2 handover, AAR and PAR exchange messages
  canceling tunnel service between AAR and PAR and allowing AAR
  to start the tunnel with NAR.

   a. The start of L2 handover is signaled at PAR by L2-LD.

   b. The PAR MUST exchange a HI/HACK pair with AAR with a



Koodli (Editor)             Expires 30 March 2003              [Page 17]


Internet Draft             Fast Handovers              30 September 2002


   Lifetime option having value zero. This cancels tunnel
   service between PAR and AAR. If AAR has not already placed
   a BT to NAR, it MUST do so immediately upon receipt of the
   HI.

  5. Completion of L2 handover is signaled by an L2-LU trigger at
  NAR and MN. The NAR and MN handle the trigger in the
  following ways:

   a. The NAR MUST begin delivering packets to the MN, and
   MUST tunnel any CN-bound packets from the MN to aFA.

   b. Based on its current movement and traffic pattern, MN MAY
   either defer obtaining a nCoA or begin the process of
   obtaining an nCoA.

  6. In the special case where NAR and AAR are the same, AAR
  recognizes that it is tunneling to PAR when it checks its
  routing tables in Step 3. In this case, there is no need for
  AAR to send the HI/HACK with itself in Step 3. Upon receipt
  of the L2-LU trigger on handover completion, the AAR MUST
  begin routing packets directly to MN and the tunnel to NAR
  MUST be torn down. The AR MUST still exchangesthe HI/HACK
  with PAR in Step 4b because PAR can't know a priori that AAR
  and NAR are the same, but AAR MUST NOT need not gate old
  tunnel tear down or delivery of MN packets on this exchange.

   Unlike two party handover, the timing of BT establishment between
   AAR and NAR cannot fully depend on the availability of L2 trigger
   information because AAR does not receive an L2 trigger when L2
   handover begins.  The two timing extremes at which AAR can place the
   BT with NAR are:

  1. At the earliest, AAR MAY establish the BT with PAR after
  sending the HACK(t) to NAR in response to the request for
  target-triggered handover,

  2. At the latest, AAR MUST establish the BT with NAR and tear
  down the BT with PAR when receiving the HI(r) from PAR
  indicating the L2 handover has begun.

   In addition, AAR MAY contine tunnel service with PAR if 1) is
   selected, until the HI is received.  If 1) is selected and the AAR
   continues to tunnel to PAR, the result may be duplicated packets at
   the MN, because the MN will receive packets through PAR on the old L2
   until L2 handover begins.  If 2) is selected, the additional latency
   of the HI added to the L2 handover latency may result in additional
   packets being dropped while the MN is not receiving L3 networking
   service.  Of course, AAR can choose to place the BT some time between



Koodli (Editor)             Expires 30 March 2003              [Page 18]


Internet Draft             Fast Handovers              30 September 2002


   1) and 2) if the network can give reasonable bounds.  The exact
   selection of when to establish the BT is likely to be influenced by
   network engineering and implementation considerations, including
   whether a handover smoothing solution is deployed, and is beyond the
   scope of this specification.

   Figure 5 and Figure 6 show timing diagrams for source trigger (L2-ST)
   and target trigger (L2-TT) three party handover, respectively in
   order to further illustrate the protocol shown in Figure 4.











































Koodli (Editor)             Expires 30 March 2003              [Page 19]


Internet Draft             Fast Handovers              30 September 2002



   MN               NAR            PAR              AAR
    |                |              |                |
    |                | L2-ST ~~~~~> |                |
    |                |              |                |
    |                |<-------------|                |
    |                |       HTT    |                |
    |                |------------->|                |
    |                |    HACK(s)   |                |
    |                |              |                |
    |                |------------------------------>|
    |                |   HI(t)      |                |
    |                |              |                |
    |                |<------------------------------|
    |                |    HACK(t)   |                |
    |                |              |                |
   ----------------------------------<~~~ L2-LD      |
                                    |--------------->|
                 L2 Handover        |     HI(r)      |
                                    |                |
                                    |<---------------|
                                    |     HACK(r)    |
                                    |                |
   ----------------------------------<~~~ L2-LU      |
    |                |              |                |
    |<-------------->|              |                |
    | MN's traffic   |              |                |
    |    on aCoA     |              |                |
    |                |              |                |



          Figure 5: Three Party Source Trigger Handover Timing



   5. Other Considerations

   5.1. Handover Capability Exchange

   A MN, when it attaches to its access router needs to know whether the
   access router supports fast handover.  Similarly, the access router
   needs to know whether the MN is capable of fast handover protocol.
   For this purpose, a new Hanodver Capability Extension is defined.
   See Section 6.5.5.  The MN MUST include this extension in a Router
   Solicitation message if it supports fast handover protocol.  The
   access router MUST include the extension in the corresponding Router
   Advertisement if it supports the fast handover protocol.




Koodli (Editor)             Expires 30 March 2003              [Page 20]


Internet Draft             Fast Handovers              30 September 2002



   MN               NAR            PAR              AAR
    |                |              |                |
    |                |<~~~ L2-TT    |                |
    |                |              |                |
    |                |------------->|                |
    |                |    HI(t)     |                |
    |                |<-------------|                |
    |                |    HTT       |                |
    |                |------------------------------>|
    |                |   HI(t)      |                |
    |                |              |                |
    |                |<------------------------------|
    |                |    HACK(t)   |                |
    |                |              |                |
   ----------------------------------<~~~ L2-LD      |
                                    |--------------->|
                 L2 Handover        |     HI(r)      |
                                    |                |
                                    |<---------------|
                                    |     HACK (r)   |
                                    |                |
   ----------------------------------<~~~ L2-LU      |
    |                |              |                |
    |<-------------->|              |                |
    | MN's traffic   |              |                |
    |    on aCoA     |              |                |



          Figure 6: Three Party Target Trigger Handover Timing



   The access router MUST NOT send a gratuitous PrRtAdv message if the
   MN does not include the Handover Capability Extension.  If the Router
   Advertisement does not include the Handover Capability Extension, the
   MN MUST not send a RtSolPr message.

   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.








Koodli (Editor)             Expires 30 March 2003              [Page 21]


Internet Draft             Fast Handovers              30 September 2002


   5.2. Determining New Care of Address

   When stateless address configuration is used, the PAR MUST formulate
   NCoA using the MN's interface identifier and the NAR's subnet prefix
   according to [6] and include NCoA in the HI message.  The New Access
   Router MUST verify that NCoA is unique before beginning to defend
   that address.  If the address is not unique, a status code in the
   required HACK message indicates it.  And, PAR MUST convey that the
   proposed NCoA is not acceptable to MN in the FBACK message.

   If stateful address configuration is being used, NCoA is returned
   by the NAR, instead of being proposed by the PAR. The HI and HACK
   message exchange precedes the transmission of PrRtAdv from the PAR to
   the MN, because NAR allocates the new IP address.  The rest of the
   process is identical to the stateless approach.

   If the MN is unable to use anticipation to form a NCoA when attached
   to PAR, it SHOULD begin the process of configuring its NCoA as soon
   as it determines that it has moved to NAR. The NCoA configuration
   process follows either stateless (which could include DAD) or
   statefull IPv6 address configuration procedure.  In order to use
   NCoA with its correspondents however, the MN has to first send a BU
   to its Home Agent, and perform return routability prior to sending
   BU to its correspondents with which the MN is interested in route
   optimization.  These steps are specified in [3].  The MN MAY defer
   NCoA configuration for some period of time if the MN's traffic
   conditions or movement patterns do not allow it to perform NCoA
   configuration.  An example of such a condition is if the MN would
   be required to linger on the link solely in order to complete NCoA
   configuration.

   If the MN moves to another AR before completion of CoA configuration,
   either during the configuration process or prior to beginning the
   process, the considerations in Section 4.4, and Section 4.6 apply.
   In particular, if protocol support specified in Section 4.6 is
   available, the NAR SHOULD arrange for the MN's tunnel to be handed
   over to the MN's next destination router.

   The NAR MUST send the MN an unsolicited RA in the event it must
   terminate the tunnel for any reason prior to the MN's configuring
   it's NCoA. The MN SHOULD initiate NCoA configuration immediately upon
   receipt of the RA, or risk losing forwarding service to PCoA.


   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,



Koodli (Editor)             Expires 30 March 2003              [Page 22]


Internet Draft             Fast Handovers              30 September 2002


   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.


   5.4. DAD Handling

   Duplicate Address Detection (DAD) was defined in [6] 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 may add 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.  In such
   a case, the MN would have to follow stateless address configuration
   rules after attaching to the NAR. Since this specification allows the
   MN to continue to use PCoA, the delay due to DAD is not a concern.
   However, the transmission epoch of Binding Update to the Home Agent
   will be delayed.


   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



Koodli (Editor)             Expires 30 March 2003              [Page 23]


Internet Draft             Fast Handovers              30 September 2002


   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 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 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
   in the 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.  A long life times increases the chance of
   a circular tunnel from PAR to NAR and back again to PAR which could
   essentially result in a routing loop, especially if the PCoA is used
   with tunnels between ARs themselves, rather than forwarding to NCoA.

   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 the wrong 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.









Koodli (Editor)             Expires 30 March 2003              [Page 24]


Internet Draft             Fast Handovers              30 September 2002


   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].


   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 7: Router Solicitation for Proxy (RtSolPr) Message




 IP Fields:

   Source Address
                  An IP address assigned to the sending interface

   Destination Address
                  The address of the Access Router or the all routers
                  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



Koodli (Editor)             Expires 30 March 2003              [Page 25]


Internet Draft             Fast Handovers              30 September 2002



   Code           0

   Checksum       The ICMP checksum.

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

   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.

   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.

   Future versions of this protocol may define new option types.
   Receivers MUST silently ignore any options 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 twice, 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 attempt to
   send FBU as described in Section 4.2.


   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.


 IP Fields:




Koodli (Editor)             Expires 30 March 2003              [Page 26]


Internet Draft             Fast Handovers              30 September 2002



   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 8: Proxy Router Advertisement (PrRtAdv) Message



   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

   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.




Koodli (Editor)             Expires 30 March 2003              [Page 27]


Internet Draft             Fast Handovers              30 September 2002



 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
                  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
                  In stateful configuration, this option MUST be sent
                  to allocate an address on behalf of the Access
                  Router this message is proxied for (i.e.,NAR).
                  In stateless address auto-configuration 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.5.2.  A Proxy Router Advertisement with Code 0 and a New
   CoA Option means that the MN SHOULD use the CoA indicated as a NCoA
   at the NAR. The New CoA MUST be used when Stateful CoA configuration
   is indicated and MAY be used to assist the PAR and MN calculate the
   same NCoA when Stateless address configuration is used.

   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. Processing



Koodli (Editor)             Expires 30 March 2003              [Page 28]


Internet Draft             Fast Handovers              30 September 2002


   of such a FBU follows the description in Section 4.2.  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.


   6.1.3. Fast Neighbor Advertisement (FNA)

   A MN sends a Fast Neighbor Advertisement to announce itself to 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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|S|O|                     Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-



          Figure 9: Fast Neighbor Advertisement (FNA) Message




 IP Fields:

   Source Address
                  MUST be the MN's PCoA.

   Destination Address
                  NAR's IP address or the all-router's 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:



Koodli (Editor)             Expires 30 March 2003              [Page 29]


Internet Draft             Fast Handovers              30 September 2002



   Type           TBD

   Code           0

   Checksum       The ICMP checksum.

   R flag         The isRouter flag. MUST be set to zero.

   S flag         The solicited flag. MUST be set to zero.

   O flag         The override flag. MUST be set to one.

   Reserved       32-bit unused field.  It MUST be initialized to
                  zero by the sender and MUST be ignored by the
                  receiver.

  Possible options:

   Target link-layer address
                  The link-layer address for the target, i.e., the
                  sender of the advertisement.  This option MUST be
                  included in all FNA messages.

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

   The MN sends Fast Neighbor Advertisement to the NAR, as soon
   as it gains connectivity on the new link, when the Fast Binding
   Acknowledgment has not been received.  The Fast Neighbor
   Advertisement is sent because the MN is still unsure about the
   NCoA it should be using on its new link.  Using PCoA and the MN's
   link-layer address, the NAR checks its host route entry and proxy
   neighbor cache.  The NAR SHOULD enable the host route entry so that
   packets sent to PCoA can be forwarded.  If a proxy neighbor cache
   entry is found, the NAR SHOULD create a neighbor cache entry, set it
   to REACHABLE state and then delete the proxy neighbor cache entry.
   In any case, the NAR MUST send a Router Advertisement to PCoA as
   destination address with NAACK option(See Section 6.5.4).  The NAACK
   option indicates if it is acceptable to use NCoA or not.  When use
   of NCoA is not acceptable, the MN MUST fallback to IPv6 address
   configuration.









Koodli (Editor)             Expires 30 March 2003              [Page 30]


Internet Draft             Fast Handovers              30 September 2002


   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|H|T|R|    Reserved         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



               Figure 10: 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 30 March 2003              [Page 31]


Internet Draft             Fast Handovers              30 September 2002


   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
                  MUST be included so that packets sent to PCoA can
                  always be redirected to NAR.

   New Care of Address
                  The IP address the MN wishes to use when
                  connected to the destination. Used in stateless
                  configuration to request NAR to confirm whether the
                  MN can use this address. When the `S' bit is zero,
                  and if this option is not present, it indicates that
                  the MN is not anticipating a new CoA through this
                  message. This is useful when PAR has to initiate a HI
                  after the MN attaches to NAR and sends FBU.

   In addition, the following additional flags in the Reserved field are
   present and the Lifetime option MAY be present when the tunnel is
   established using the link layer triggers.  The default lifetime for
   the bidirectional tunnel between the access routers is BT_LIFETIME.

  H              Set if the message was triggered by an L2-ST in
                 a two party handover. All other bits are unset.



Koodli (Editor)             Expires 30 March 2003              [Page 32]


Internet Draft             Fast Handovers              30 September 2002



  T              Set if the message was triggered by an L2-TT.
                 All other bits are unset.

  R              Set if a request to extend or cancel tunnel
                 service. All other bits are unset.

  Lifetime Option
                  The lifetime, in seconds, for which the requester
                  would like tunnel service extended. If the field is
                  zero, the request is to cancel tunnel service. If
                  the field is 0xffffffff, the request is for infinity.


   If Handover Acknowledge (HACK) message is not received as a response,
   the Handover Initiate SHOULD be resent 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.  Failure to receive a Handover Acknowledgment means that no
   fast handover can be performed (See Section 4.2).


   6.2.2. Handover Acknowledge (HACK)

   The Handover Acknowledgment message is a new ICMPv6 message that MUST
   be sent (typically by NAR to PAR) in 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 11: Handover Acknowledge (HAck) Message




 IP Fields:




Koodli (Editor)             Expires 30 March 2003              [Page 33]


Internet Draft             Fast Handovers              30 September 2002


   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

   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
              131: Tunnel Lifetime Renewal failed

   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.





Koodli (Editor)             Expires 30 March 2003              [Page 34]


Internet Draft             Fast Handovers              30 September 2002


   In addition, the following flags are present Lifetime option MAY be
   present when using link layer triggers.  The default lifetime for the
   bidirectional tunnel between the access routers is BT_LIFETIME.

   H              Set if in response to HRqst(s) in a two party
                  handover. All other bits are unset.

   T              Set if in response to an HRqst(t) in a two party
                  handover, or when sent by aAR in a three party
                  handover. All other bits are unset.

   R              Set if in response to a HRqst(r). All other bits
                  are unset.

   Lifetime Option
                The lifetime, in seconds, for which the sender is
                willing to grant tunnel service. If the field is zero,
                the request for tunnel service is denied. If the field
                is 0xffffffff, the tunnel service is guaranteed until
                canceled.


   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.

   If the `S' flag is not set and NCoA is not present, it indicates that
   the PAR is requesting NAR to neither verify NCoA nor allocate one.

   In any case, the NAR MUST 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 30 March 2003              [Page 35]


Internet Draft             Fast Handovers              30 September 2002


   6.3. Handover To Third (HTT)

   This is a message used in the optional Three Party Handover protocol
   described in Section 4.6.

   HTT message is an extension of both HI and HACK. If HTT is triggered
   by an L2-ST, then it is an extension of HI. If HTT is sent in
   response to an HI with T bit set, then it is an extension of the
   HACK. The message can be distinguished as an HTT because it has
   both the H and T bits set regardless of whether it is received as a
   request or sent as a reply.  No other bits are set in HTT.

   In addition, the HTT MUST contain the following options in the
   specified order:


  Valid Options:

   IP Address Option containing AAR's Address.

   LLA Option containing the L2 address of the MN.

   LLA Option containing the L2 address of AAR.



   6.4. New Mobility Header Messages

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


   6.4.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.

      IP fields:

         Source address      The PCoA

         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.



Koodli (Editor)             Expires 30 March 2003              [Page 36]


Internet Draft             Fast Handovers              30 September 2002



                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |A|H|S|D|      Reserved         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Sequence Number           |          Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Lifetime                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                           Home Address                        +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                         Mobility options                      .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




              Figure 12: Fast Binding Update (FBU) Message



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

      `S' flag        See [3].

      `D' flag
                      SHOULD be set to zero (since ``home address'' is
                      the address in use (i.e., PCoA).

      Reserved        This field is unused.  MUST be set zero.

      Sequence Number
                      A 16-bit number used by the receiving node
                      to sequence Fast Binding Updates and by the
                      sending node to match a returned Fast Binding
                      Acknowledgment with this Fast Binding Update.
                      Each Fast Binding Update sent by a mobile node
                      MUST use a Sequence Number greater than the
                      Sequence Number value sent in the previous Fast
                      Binding Update (if any) to the same destination



Koodli (Editor)             Expires 30 March 2003              [Page 37]


Internet Draft             Fast Handovers              30 September 2002


                      address (modulo 2**16, as defined in [3]).  The
                      processing rules for this field are the same as
                      those described in [3].

      Lifetime
                      32-bit unsigned integer.  The number of seconds
                      remaining before the binding MUST be considered
                      expired.  A value of all one bits (0xffffffff)
                      indicates infinity.  A value of zero indicates
                      that the binding for the mobile node MUST be
                      deleted.

      Home Address    The Previous Care of Address.

      Mobility Options
                      MUST contain alternate CoA option set to NAR's IP
                      address.

   The MN MUST send a FBU message after receiving a PrRtAdv message.  If
   the MN moves prior to receiving a PrRtAdv message, it SHOULD send a
   FBU to the PAR.

   Since the source IP address in FBU is PCoA, then the Home Address
   field is redundant.  In addition, if FBU is sent after PrRtAdv
   is received, PAR can determine the target address for traffic
   redirection, namely the NAR's IP address from the HI and HACK
   sequence.  Since both of these addresses can be inferred, these
   fields MAY be omitted in a FBU message providing that a PrRtAdv
   message has been received.  The absence of these fields can be
   determined by observing the Option Length value in the Mobility
   Header.  The Previous Access Router SHOULD process a FBU that does
   not contain these fields.

   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.4.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 MUST NOT be sent
   to the MN before the PAR receives a Handover Acknowledge message from
   the NAR. If HACK contains a validation of NCoA, FBACK MUST be sent
   with the MN's PCoA as the destination address with a status code 0.
   The Fast Binding Acknowledgment MAY also be sent to the MN on the old
   link.  The Mobility Header Type value for FBACK is 9.




Koodli (Editor)             Expires 30 March 2003              [Page 38]


Internet Draft             Fast Handovers              30 September 2002



                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |    Status     |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Sequence Number          |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Lifetime                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                        Mobility options                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




         Figure 13: Fast Binding Acknowledgment (FBACK) Message


      IP fields:

         Source address      The IP address of the Previous Access
                             Router

         Destination Address The PCoA

      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 Fast Binding Update accepted
                        1 Fast Binding Update accepted but nCOA is
                        invalid


                        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



Koodli (Editor)             Expires 30 March 2003              [Page 39]


Internet Draft             Fast Handovers              30 September 2002


                        131 Incorrect interface identifier length


      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
                        sender of this message will retain a binding for
                        traffic redirection.

      Mobility Options  Currently, none specified.


   6.5. New ICMP Options

   6.5.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 [5].


   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 14: IPv6 Address Option





Koodli (Editor)             Expires 30 March 2003              [Page 40]


Internet Draft             Fast Handovers              30 September 2002



   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

   Prefix Length
        The Length of the IPv6 Address Prefix

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



   6.5.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 15: New Router Prefix Information Option



   Type
        TBA




Koodli (Editor)             Expires 30 March 2003              [Page 41]


Internet Draft             Fast Handovers              30 September 2002


   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.

   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.5.3. Link-layer Address (LLA)

   The format of this message is based on [5].



   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 16: 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
        1 for the Link-layer Address of the new Attachment Point.
        2 for the Link-layer Address of the MN.
        3 for the Link-layer Address of the Proxied Originator




Koodli (Editor)             Expires 30 March 2003              [Page 42]


Internet Draft             Fast Handovers              30 September 2002


   LLA
        The variable length link-layer address. The content and format
        of this field (including byte and bit ordering) is expected to
        be specified in specific documents that describe how IPv6
        operates over different link layers.

   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.

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

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


   6.5.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 17: 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



Koodli (Editor)             Expires 30 March 2003              [Page 43]


Internet Draft             Fast Handovers              30 September 2002


        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
         128   Link Layer Address unrecognized

   The NAR uses NAACK option, to confirm the validity of NCoA, in a
   Router Advertisement sent as a response the FNA message.  The PAR
   also provides such a confirmation in the FBACK message.  If the NCoA
   is valid, the Router Advertisement MUST use NCoA as the destination
   address and the MN SHOULD use it as its new CoA as defined in [3].
   If the NCoA is invalid, the Router Advertisement MUST use the PCoA
   as the destination address.  The MN MAY use PCoA as source address,
   however, it SHOULD start the process of obtaining a NCoA at the NAR.
   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.


   6.5.5. Handover Capability Extension

   The Handover Capabilities extension is used in the IPv6 Router
   Solicitation and Router Advertisement to indicate whether or not a MN
   and its access router are capable of supporting fast handovers.



    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    |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



            Figure 18: Handover Capability Extension Option



   Type
       TBD

   Length
        The length of the option (including the type, sub-type and



Koodli (Editor)             Expires 30 March 2003              [Page 44]


Internet Draft             Fast Handovers              30 September 2002


        length fields) in units of 8 octets.

  Sub-Type
        0

  Code
        0 The node supports fast handover


   7. Configurable Parameters

      Parameter Name       Default Value            Definition
      -------------------  ----------------------   -------
      FBU_RETRIES          3                        Section 4
      BT_LIFETIME          2 seconds                Section 4
      BT_LIFETIME_WARNING  500 ms                   Section 4.5.1
      PROXY_ND_LIFETIME    1 second                 Section 6.2.2
      HI_RETRIES           4                        Section 6.2.1




   8. Security Considerations

   The PAR MUST ensure that the FBU packet arrived from a node that
   legitimately owns the PCoA. Otherwise, a bogus node, either on-link
   or off-link, could attempt to disrupt packets meant for the MN and
   redirect them to some access router.  When FBU is sent on-link
   (i.e., it is not tunneled), the default security is what Neighbor
   Discovery offers.  The access router and its hosts may use any
   available mechanism to establish a security association.  When a
   pre-established security association is available, it MUST be used to
   secure FBU.

   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 should be performed at least on neighbor
   discovery messages including the RtSolPr message.

   When FBU is sent off-link (i.e., arrives in a tunnel), it MUST be
   protected by a security association established between the node
   sending FBU and the PAR.

   The target of malicious traffic redirection is limited to an access
   router only with which the PAR has a security association.  Because
   of this, traffic could only be redirected to NAR's IP address




Koodli (Editor)             Expires 30 March 2003              [Page 45]


Internet Draft             Fast Handovers              30 September 2002


   (and not to any other address), and the possibility of spamming an
   unsuspecting node is eliminated.


   9. Contributors

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


   10. Acknowledgments

   The editor would like to thank the design team for all their hard
   work.  The Design Team would like to recognize Hesham Soliman's
   valuable contribution to this work.  Also, warm thanks to Basavaraj
   Patil and Phil Roberts for supporting this effort and the whole
   Mobile IP WG for participating in the initial discussion.

   The WG would like to thank James Kempf, Pat Calhoun, Gopal Dommety,
   Sebastian Thalanany, Ajoy Singh, Peter J. McCann and Tom Hiller for
   proposing the BETH method which is the basis of Section 4.5 and
   Section 4.6.  James Kempf also contributed text in Section 4.5.1 and
   Section 5.2.


   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.

   [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] (editor) Kempf, J.  Requirements for Layer 2 Protocols to Support
       Optimized Handover for IP Mobility (work in progress).  Internet
       Draft, Internet Engineering Task Force.
       draft-manyfolks-l2-mobilereq-00.txt, January 2000.

   [5] M. Khalil, R. Narayanan, H. Akhtar, and E. Qaddoura.  Mobile IP
       Extensions Rationalization (MIER) (work in progress).  Internet



Koodli (Editor)             Expires 30 March 2003              [Page 46]


Internet Draft             Fast Handovers              30 September 2002


       Draft, Internet Engineering Task Force.
       draft-ietf-mobileip-mier-05.txt, February 2000.

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


   11. Contact Information

   The working group can be contacted via the current chairs:


     Basavaraj Patil                     Phil Roberts
     Nokia Corporation                   Megisto Systems,Inc
     6000 Connection Drive               20251 Century Blvd
     M/S M8-540                          Germantown, MD  20874
     Irving, Texas 75039                 USA
     USA                                 Phone: +1 301-444-1700
     Phone:  +1 972-894-6709             Fax:   +1 301-515-3675
     Fax :   +1 972-894-5349             E-Mail: proberts@megisto.com
     E-Mail: Basavaraj.Patil@nokia.com


   The design team member's contact information:


     Gopal Dommety
     Cisco Systems, Inc.
     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



Koodli (Editor)             Expires 30 March 2003              [Page 47]


Internet Draft             Fast Handovers              30 September 2002


     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

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

     Alper E. Yegin
     Sun Microsystems
     901 San Antonio Rd, UMPK17-202
     Palo Alto, CA, 94303,USA
     Phone: +1 650 786 4013
     E-mail: alper.yegin@sun.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
     E-Mail: Rajeev.Koodli@nokia.com























Koodli (Editor)             Expires 30 March 2003              [Page 48]


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