Internet DRAFT - draft-koodli-mip4-fmipv4

draft-koodli-mip4-fmipv4



Mobile IPv4 Working Group                                  Rajeev Koodli
INTERNET DRAFT                                        Charles E. Perkins
17 October 2005                                    Nokia Research Center


                       Mobile IPv4 Fast Handovers
                    draft-koodli-mip4-fmipv4-00.txt

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note
   that other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a submission of the IETF MIP6 WG. Comments should be
   directed to the MIP6 WG mailing list, mip6@ietf.org.


   Abstract

   The Mobile IPv6 fast handover document [2] specifies a protocol to
   improve latency and packet loss resulting from Mobile IPv6 handover
   operations.  This document adapts the protocol for IPv4 networks
   to improve performance over Mobile IPv4 operations, including
   processing of Agent Advertisements, new Care of Address acquisition
   and Registration Request and Reply.  However, operation without
   Foreign Agent function at a router is also feasible.  In addition,
   the protocol may be used transparently on hosts which do not support
   Mobile IP, but with limited movement across subnets.  Using the
   concepts outlined in [2], this document also addresses movement
   detection, IP address configuration and location update latencies
   during a handover.  For reducing the IP address configuration, the
   document currently proposes that the new CoA is always made to be the
   new access router's IP address.  Additional mechanisms may be defined
   in the future versions of this document.



Koodli, Perkins              Expires 17 April 2006              [Page i]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005




                                 Contents


Abstract                                                               i

 1. Introduction                                                       2

 2. Protocol Operation                                                 2
     2.1. Basic NCoA Support  . . . . . . . . . . . . . . . . . . .    3
     2.2. Assigned Addressing Support . . . . . . . . . . . . . . .    4

 3. Use of Previous FA Notification Extension                          4

 4. Message Formats                                                    4
     4.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . . .    4
     4.2. Fast Binding Acknowledgment (FBAck) . . . . . . . . . . .    6
     4.3. Router Solicitation for Proxy Advertisement (RtSolPr) . .    7
     4.4. Proxy Router Advertisement (PrRtAdv)  . . . . . . . . . .    9
     4.5. Inter-Access Router Messages  . . . . . . . . . . . . . .   11
           4.5.1. Handover Initiate (HI)  . . . . . . . . . . . . .   11
           4.5.2. Handover Acknowledge (HAck) . . . . . . . . . . .   12

 5. Option formats                                                    14
     5.1. Link-Layer Address Option Format  . . . . . . . . . . . .   14
     5.2. New IPv4 Address Option Format  . . . . . . . . . . . . .   15
     5.3. New Router Prefix Information Option  . . . . . . . . . .   15

 6. Security Considerations                                           16

 7. IANA Considerations                                               17

Intellectual Property Statement                                       17

Disclaimer of Validity                                                18

Copyright Statement                                                   18

Acknowledgment                                                        18












Koodli, Perkins              Expires 17 April 2006              [Page 1]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   1. Introduction

   In this document, we adapt the fast handover specification [2] to
   IPv4 networks.  The fast handover protocol specified in this document
   is particularly interesting for operation on commonly available
   wireless links such as IEEE 802.11 WLAN links.  Fast handovers are
   not typically needed for wired media due to the relatively large
   delays attributable to establishing new connections in today's wired
   networks.  Mobile IPv4 registration messages are re-used (with new
   type numbers) to enable quick implementation using existing foreign
   agent software.  This draft does not rely on link-layer triggers for
   protocol operation, but performance will typically be enhanced by
   using the appropriate triggers when they are available.

   The active agents that enable continued packet delivery to a mobile
   node are the access routers on the networks that the mobile node
   connects to.  Handover means that the mobile node changes its network
   connection, and we consider the scenario in which this change means
   change in access routers.  The mobile node utilizes the access
   routers as default routers in the normal sense, but also as partners
   in mobility management.  Thus, when the mobile node moves to a new
   network, it processes handover-related signaling in order to identify
   and develop a relationship with a new access router.  In this
   document, we call the previous access router PAR and the new access
   router NAR. Unless otherwise mentioned, a PAR is also a Previous FA
   (PFA) and a NAR is also a New FA (NFA).

   On a particular network, the MN may obtain its IP address via DHCP
   (i.e., CCoA) or use the Foreign Agent CoA. During a handover, the new
   CoA is always made to be that of NAR. This allows a MN to receive and
   send packets using its previous CoA, so that delays resulting from IP
   configuration (such as DHCP address acquisition delay) subsequent to
   attaching to the new link are disengaged from affecting the existing
   sessions.


   2. Protocol Operation

   After a MN obtains its IPv4 care-of address, it builds a neighborhood
   access point and subnet map using the Router Solicitation for Proxy
   Advertisement and Proxy Router Advertisement messages.  The MN may
   scan for access points (APs) based on the configuration policy in
   operation for its wireless network interface.  If a scan results in
   a new AP discovery, the MN resolves the AP-ID to subnet information
   using the messages defined below.

   The coordination between the access routers is done by way of the
   Handover Initiate (HI) and Handover Acknowledge (HAck) messages.
   After these signals have been exchanged between the previous and new



Koodli, Perkins              Expires 17 April 2006              [Page 2]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   access routers (PAR and NAR), data arriving at PAR will be tunneled
   to NAR for delivery to the newly arrived mobile node.  The purpose
   of HI is to securely deliver the routing parameters for establishing
   this tunnel.  The tunnel is created by the access routers in response
   to the delivery of the FBU from the mobile node.

   We consider three scenarios.  First, the access routers are not
   involved in IP address assignment for the MN not any more than,
   e.g., being a DHCP Relay when DHCP is being used.  Second, an access
   router acts as a foreign agent, using the same IP address for use by
   a multiplicity of mobile nodes.  In this scenario, an access router
   provides its own IP address for the MN to use upon connecting to the
   new link.  Third, an access router may allocate an IP address to a
   visiting mobile node by some means not specified in this document.
   Just as a simple example, an access router may maintain a pool of
   IPv4 addresses for temporary use by visiting mobile nodes.

   The protocol semantics are almost identical in all scenarios.  The
   packet formats presented in RFC 3344 are re-used to achieve maximum
   compatibility with Mobile IP.


   2.1. Basic NCoA Support

   In response to a handover trigger or indication, the MN sends a
   Fast Binding Update message to Previous Access Router (PAR) (see
   Section 4.1).  This message should be sent when the MN is still
   connected to PAR. When sent in this ``predictive'' mode, the ``Home
   Address'' field must be the PCoA. The Home Agent field, even though
   redundant, must be set to PAR's IP address, and the Care-of Address
   must be the NAR's IP address discovered via PrRtAdv message.  The
   destination IP address of the FBU message must be PAR's IP address.

   When attachment to a new link is detected, FBU should be (re)sent.
   When sent in this ``reactive'' mode, the destination address must
   be NAR's IP address, and the source address must be PCoA from the
   FBU message.  The Home Agent field must be set to PAR's IP address.
   When NAR receives FBU, it may already have processed the HI message
   and created a host route entry for the PCoA. In that case, NAR can
   immediately forward arriving and buffered packets including the FBAck
   message.  In any case, NAR MUST forward the contents of this message,
   starting from the Type field, to PAR.

   The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
   serve to establish a tunnel between the routers to support packet
   forwarding for PCoA. The tunnel itself is established as a response
   to the FBU message.  Furthermore, when the MN obtains a NCoA from
   NAR, the reverse tunnel to the PAR is not necessary; the MN would
   reverse tunnel to the Home Agent directly using its NCoA.



Koodli, Perkins              Expires 17 April 2006              [Page 3]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   The PAR sends HI message with Code = 0 when it receives FBU with
   source IP address set to PCoA. The PAR sends HI with Code = 1 when
   it receives FBU with source IP address not set to PCoA (i.e., when
   received from NAR). This allows NAR to disambiguate processing when
   HI needs to be sent as a response to predictive and reactive modes of
   operation.


   2.2. Assigned Addressing Support

   In this mode, the NAR provides NCoA, which is delivered to the MN in
   the FBAck message either on the previous link or on the new link.
   Since the MN is unaware of the address that NAR might assign, it
   always binds its PCoA to NAR's address.  This results in a tunnel
   from PAR to NAR. However, with Mobile IP, a reverse tunnel to PAR is
   not necessary since the MN can directly reverse tunnel to the Home
   Agent.

   The source IP address in FBU is PCoA regardless of the link it is
   sent from.  The destination address is either PAR's IP address or the
   NAR's IP address depending on the link from which FBU is sent.  The
   FBAck message MUST include a NCoA extension.  The NAR MUST provide
   NCoA in the HAck message.  The NAR MUST also include the extension
   when responding to FBU sent from the new link.


   3. Use of Previous FA Notification Extension

   Sending FBU from the new link (i.e., reactive mode) is similar to
   using the extension defined in [3].  However, with the neighborhood
   information gathered using the proxy router messages (see
   Section 4.3, Section 4.4), movement detection and router discovery
   delays are avoided even in the reactive case.  The FBU and FBAck
   messages defined in this document can be naturally used even when no
   neighborhood information is available.


   4. Message Formats

   4.1. Fast Binding Update (FBU)

   The FBU format is bitwise identical to the Registration Request
   format in RFC 3344.  The same destination port number, 434, is used,
   but the FBU and FBAck messages in this specification have new message
   type numbers.







Koodli, Perkins              Expires 17 April 2006              [Page 4]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005



    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      |x|x|D|M|G|r|T|x| reserved  |     Lifetime      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-



              Figure 1: Fast Binding Update (FBU) Message


      IP fields:

         Source address
                             The interface address from which the
                             message is sent.  Either PCoA or NAR's IP
                             address.

         Destination Address
                             The IP address of the Previous Access
                             Router or the New Access Router.

         Source Port         variable

         Destination port    434 (TBA)

      Type                To be assigned by IANA

      Flags               See RFC 3344

      reserved            Sent as zero, ignored on input

      Lifetime            The number of seconds remaining before binding
                          expires.  MUST NOT exceed 10 seconds.

      Home Address        MUST be PCoA or the MN's Home Address



Koodli, Perkins              Expires 17 April 2006              [Page 5]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


      Home Agent          The Previous Access Router's global IP address

      Care-of Address     The New Access Router's global IP address

      Identification      See RFC 3344

      Extensions          MUST contain the MN - PAR Authentication
                          Extension


   4.2. Fast Binding Acknowledgment (FBAck)

   The FBAck format is bitwise identical to the Registration Reply
   format in [4].


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      | reserved  |     Lifetime      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-



         Figure 2: Fast Binding Acknowledgment (FBAck) Message

















Koodli, Perkins              Expires 17 April 2006              [Page 6]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


      IP fields:

         Source address
                             Typically copied from the destination
                             address of the FBU message

         Destination Address
                             Copied from the Source IP address in FBU
                             message

         Source Port         variable

         Destination port    copied from thr source port in FBU message

      Type                To be assigned by IANA

      Code                Indicates the result of processing FBU
                          message.  Code = 0 means Fast Binding Update
                          accepted.  Code = 1 means Fast Binding Update
                          accepted but NCoA is supplied as an extension.

      reserved            Sent as zero, ignored on input

      Lifetime            The number of seconds remaining before binding
                          expires.  MUST NOT exceed 10 seconds.

      Home Address        PCoA or MN's Home Address

      Home Agent          The Previous Access Router's global IP address

      Identification      a 64-bit number used for matching FBU. See RFC
                          3344.

      Extensions          The PAR - MN Authentication extension MUST be
                          present.  In addition, a NCoA option MUST be
                          present when NAR supplies the NCoA.

   If the FBAck message indicates that the new care-of address is a
   Foreign Agent care-of address [4], then the mobile node MUST set the
   'D' bit in its Registration Request message that it uses to register
   the NCoA with its home agent.


   4.3. Router Solicitation for Proxy Advertisement (RtSolPr)

   Mobile Nodes send Router Solicitation for Proxy Advertisement in
   order to prompt routers for Proxy Router Advertisements.  All the
   link-layer address options have the format defined in 5.1.  The




Koodli, Perkins              Expires 17 April 2006              [Page 7]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   message format and processing rules are identical to that defined
   in [2].  We only provide the format here for convenience.



   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             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Subtype     |   Reserved    |          Identifier           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
  +-+-+-+-+-+-+-+-+-+-+-+-



       Figure 3: 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.

   Time-to-Live   At least 1. See RFC 1256.

 ICMP Fields:

   Type           To be assigned by IANA

   Code           0

   Checksum       The ICMP checksum. See RFC 1256

   Subtype        To be assigned by IANA

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

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

 Valid Options:



Koodli, Perkins              Expires 17 April 2006              [Page 8]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005



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


   4.4. Proxy Router Advertisement (PrRtAdv)

   Access routers send out Proxy Router Advertisement message
   gratuitously if the handover is network-initiated or as a response
   to RtSolPr message from a MN, providing the link-layer address,
   IP address and subnet prefixes of neighboring routers.  All the
   link-layer address options have the format defined in 5.1.

   The message format and processing rules are identical to that defined
   in [2].  We only provide the format here for convenience.  The ICMP
   checksum is defined in [1].


   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             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Subtype     |   Reserved    |          Identifier           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
  +-+-+-+-+-+-+-+-+-+-+-+-



         Figure 4: Proxy Router Advertisement (PrRtAdv) Message




 IP Fields:

   Source Address
                  An IP address assigned to the sending interface

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



Koodli, Perkins              Expires 17 April 2006              [Page 9]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


                  handover.

   Time-to-Live   At least 1. See RFC 1256.

 ICMP Fields:

   Type           To be assigned by IANA

   Code           0, 1, 2, 3 or 4. See below.

   Checksum       The ICMP checksum. See RFC 1256.

   Subtype        To be assigned by IANA.

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

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

 Valid Options in the following order:

   New Access Point Link-layer Address
                  The link-layer address or identification of the
                  access point is copied from RtSolPr
                  message. This option MUST be present.

   New Router's Link-layer Address
                  The link-layer address of the Access Router for
                  which this message is proxied for. This option MUST be
                  included when Code is 0 or 1.

   New Router's IP Address
                  The IP address of NAR. This option MUST be
                  included when Code is 0 or 1.

   New Router Prefix Information Option
                  The number of leading bits that define the network
                  number of the corresponding Router's IP Address
                  option (see above).
   New CoA Option
                  MAY be present when PrRtAdv is sent
                  unsolicited. PAR MAY compute new CoA using NAR's
                  prefix information and the MN's L2 address, or by
                  any other means.







Koodli, Perkins             Expires 17 April 2006              [Page 10]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   4.5. Inter-Access Router Messages

   4.5.1. Handover Initiate (HI)

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

   The message format and processing rules are identical to that defined
   in [2].  We only provide the format here for convenience.



   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             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Subtype     |S|U| Reserved  |          Identifier           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
  +-+-+-+-+-+-+-+-+-+-+-+-



                Figure 5: Handover Initiate (HI) Message



 IP Fields:

   Source Address
                  The IP address of the PAR

   Destination Address
                  The IP address of the NAR

   Time-to-Live   At least 1. See RFC 1256.

 ICMP Fields:

   Type           To be assigned by IANA

   Code           0 or 1. See below

   Checksum       The ICMP checksum. See RFC 1256

   Subtype        To be assigned by IANA




Koodli, Perkins             Expires 17 April 2006              [Page 11]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   S              Assigned address configuration flag. When set, this
                  message requests a new CoA to be returned by the
                  destination. May be set when Code = 0. MUST be 0
                  when Code = 1.

   U              Buffer flag. When set, the destination SHOULD buffer
                  any packets towards the node indicated in the options
                  of this message. Used when Code = 0, SHOULD be set
                  to 0 when Code = 1.

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

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

 Valid Options:

   Link-layer address of MN
                  The link-layer address of the MN that is
                  undergoing handover to the destination (i.e., NAR).
                  This option MUST be included so that the destination
                  can recognize the MN.

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

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


   4.5.2. Handover Acknowledge (HAck)

   The Handover Acknowledgment message is a new ICMP message that MUST
   be sent (typically by NAR to PAR) as a reply to the Handover Initiate
   (HI) (see section 4.5.1) message.

   The message format and processing rules are identical to that defined
   in [2].  We only provide the format here for convenience.



 IP Fields:




Koodli, Perkins             Expires 17 April 2006              [Page 12]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005



   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             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Subtype     |    Reserved   |          Identifier           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
  +-+-+-+-+-+-+-+-+-+-+-+-



             Figure 6: Handover Acknowledge (HAck) Message



   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.

   Time-to-Live   At least 1. See RFC 1256.

 ICMP Fields:

   Type          To be assigned by IANA

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

   Checksum   The ICMP checksum. See RFC 1256.

   Subtype      To be assigned by IANA.




Koodli, Perkins             Expires 17 April 2006              [Page 13]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


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

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


 Valid Options:

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


   5. Option formats

   The options in this section are specified as optional extensions
   for the HI and HAck messages, as well as for the Router Proxy
   Solicitation and Router Proxy Advertisement messages..


   5.1. Link-Layer Address Option Format


   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     |    Link-Layer Address ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



               Figure 7: Link-Layer Address Option Format



   Fields:

      Type
                     1   Mobile Node Link-layer Address
     2   New Access Point Link-layer Address
                     3   NAR Link-layer Address

      Length         The length of the option (including the type and
                     length fields) in units of octets.  For example,
                     the length for IEEE 802 addresses is 1 [IPv6-



Koodli, Perkins             Expires 17 April 2006              [Page 14]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


                     ETHER].

      Link-Layer Address
                     The variable length link-layer address.
                     The content and format of this field (including
                     byte and bit ordering) depends on the specific
     link-layer in use.


   5.2. New IPv4 Address Option Format

   This option is used to provide the new router's IPv4 address in
   PrRtAdv.  When it is also used to provide NCoA, it MUST appear after
   the new router's IPv4 address to distinguish the two addresses.


   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     |          Reserved             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      New IPv4 Address                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                Figure 8: New IPv4 Address Option Format



   Fields:

      Type
                     To be assigned by IANA

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

     Reserved        Set to zero.

     NCoA            The New CoA assigned by NAR.



   5.3. New Router Prefix Information Option

   This option is the same as the ``Prefix-Lengths Extension'' in RFC
   3344 (Section 2.1.2).




Koodli, Perkins             Expires 17 April 2006              [Page 15]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   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     | Prefix-Length |  Reserved     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



         Figure 9: New Router Prefix Information Option Format




   Fields:

      Type
                     To be assigned by IANA

      Length         1

      Prefix-Length
                     The number of leading bits that define the network
                     number of the corresponding Router's IP Address
                     option.

     Reserved        Set to zero.



   6. Security Considerations

   The FBU and FBack messages MUST be protected using a security
   association shared between a MN and its access router.  In
   particular, the MN - PAR Authentication Extension MUST be present in
   each of these messages.  Failure to include this extension can lead
   to a bogus node claiming a genuine MN's address and binding it to
   an arbitrary address.  When the NCoA is NAR's address, there is no
   risk of a genuine MN misdirecting traffic, either inadvertantly or
   intentionally, to an unsuspecting node on NAR's subnet.  When NCoA is
   other than NAR's address, NAR MUST ensure that the proposed NCoA in
   HI is conflict-free, and MUST indicate the disposition in the HAck
   message.  If there is a conflict, PAR MUST NOT tunnel packets to
   the address in question.  Instead, PAR SHOULD tunnel packets to the
   address specified in HAck, if any is provided.








Koodli, Perkins             Expires 17 April 2006              [Page 16]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   7. IANA Considerations

   All the messages and the option formats specified in this document
   require Type assignment from IANA.


   References

   [1] S. Deering.  ICMP Router Discovery Messages.  Request for
       Comments (Proposed Standard) 1256, Internet Engineering Task
       Force, September 1991.

   [2] R. Koodli (Editor).  Fast Handovers for Mobile IPv6 (work in
       progress).  Internet Draft, Internet Engineering Task Force.
       draft-ietf-mipshop-fast-mipv6-03.txt, October 2005.

   [3] C. Perkins and D. Johnson.  Route Optimization in Mobile IP (work
       in progress).  Internet Draft, Internet Engineering Task Force.
       draft-ietf-mobileip-optim-09.txt, February 2000.

   [4] C. Perkins (Editor).  IP Mobility Support for IPv4.  Request for
       Comments (Proposed Standard) 3344, Internet Engineering Task
       Force, August 2002.

   Questions about this memo can be directed to the authors:


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

   Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.





Koodli, Perkins             Expires 17 April 2006              [Page 17]

Internet Draft      Fast Handovers for Mobile IPv4       17 October 2005


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the
   use of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


   Disclaimer of Validity

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


   Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
















Koodli, Perkins             Expires 17 April 2006              [Page 18]