Mobile IPv4 Working Group                                     Rajeev Koodli
INTERNET DRAFT                                           Charles E. Perkins
23 October 2006
Experimental                                           Nokia Research Center
6 February 2007

                         Mobile IPv4 Fast Handovers
                        draft-ietf-mip4-fmipv4-02.txt
                        draft-ietf-mip4-fmipv4-03.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 MIP4 WG. Comments should
    be directed to the MIP6 MIP4 WG mailing list, mip4@ietf.org.

    Abstract

    The

    This document adapts the Mobile IPv6 fast handover document [2] specifies a protocol Fast Handovers [1] to
    improve latency delay and packet loss resulting from Mobile IPv6 IPv4 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.  Using the concepts outlined
    in [2],   Specifically, this document also addresses movement
    detection, IP address configuration and location update latencies
    during a handover.   For reducing the IP address configuration, configuration
    latency, the document currently proposes that the new CoA Care-of Address is
    always made to be the new access router's IP address.   Additional
    mechanisms may be defined in the future versions of this document.

                                     Contents

Abstract                                                                   i

 1.  Introduction                                                          2

 2.  Factors Affecting Handover                                              2                                            3

 3.  Protocol Operation                                                       3                                                              4
      3.1. Basic NCoA Support  . .  Overview   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .   4
      3.2. Assigned Addressing Support  Operation .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .    5

 4.  Use of Previous FA Notification Extension                             5                             8

 5.  Message Formats                                                          5                                                       9
      5.1.  Fast Binding Update (FBU) .  .  .  .  .  .  .  .  .  .  .  . . . . .     5   9
      5.2.  Fast Binding Acknowledgment (FBAck) .  .  .  .  .  .  .  .  . . .     7 11
      5.3.  Router Solicitation for Proxy Advertisement (RtSolPr) . .     8       13
      5.4.  Proxy Router Advertisement (PrRtAdv)   .  .  .  .  .  .  .  . . .    10 15
      5.5.  Inter-Access Router Messages   .  .  .  .  .  .  .  .  .  . . . . .    12   17
             5.5.1.  Handover Initiate (HI)   .  .  .  .  .  .  .  .  . . . . .    12   17
             5.5.2.  Handover Acknowledge (HAck) .  .  .  .  .  .  .  . . . .    13   19

 6.  Option formats                                                          15                                                       22
      6.1.  Link-Layer Address Option Format   .  .  .  .  .  .  .  .  . . . .    15  22
      6.2.  New IPv4 Address Option Format   .  .  .  .  .  .  .  .  .  . . . .    16 23
      6.3.  New Router Prefix Information Option   .  .  .  .  .  .  .  . . .    16 24

 7.  Security Considerations                                                17                                               25

 8.  IANA Considerations                                                    18                                                   25

 9.  Acknowledgement                                                       25

Intellectual Property Statement                                            18                                            27

Disclaimer of Validity                                                      19                                                     27

Copyright Statement                                                         19                                                        28

Acknowledgment                                                              19                                                             28
    1. Introduction

    This document adapts the fast handover specification [2] [1] to
    IPv4 networks.   The fast handover protocol specified in this
    document is particularly interesting for operation on commonly available over wireless
    links such as IEEE 802.11 WLAN 802 wireless 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 [2] registration messages are re-used (with
    new type numbers) to enable quick faster implementation using existing foreign
    agent
    Mobile IPv4 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.
    This document assumes that the reader is familiar with the basic
    operation and terminology of Mobile IPv4 [1] and Fast Handovers for
    Mobile IPv6 [1].

    The active agents that enable continued packet delivery to a mobile
    node (MN) 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. NAR, consistent with the terminology
    in [1].   Unless otherwise mentioned, a PAR is also a Previous FA
    Foreign Agent (PFA) and a NAR is also a New FA Foreign Agent (NFA).

    On a particular network, the MN a mobile node may obtain its IP address
    via DHCP [6] (i.e., CCoA) Co-located Care-of Address) or use the Foreign
    Agent CoA. During a handover, the new CoA (NCoA) is always made
    to be that of NAR. This allows a MN mobile node to receive and send
    packets using its previous CoA, CoA (PCoA), 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. Factors Affecting Handover

    Both the link-layer operations and IP layer procedures affect the
    perceived handover performance.   However, the overall performance
    is also (always) a function of specific implementation of the
    technology as well as the system configuration.   This document
    only specifies IP layer protocol operations.   The purpose of
    this section is to provide an illustration of events that affect
    handover performance, but it is purely informative.

    The IP layer handover delay and packet loss are influenced by
    latencies due to movement detection, IP address configuration and
    Mobile IP registration procedure.   Movement detection latency
    comes from the need to reliably detect movement to a new subnet.
    This is a function of frequency of router advertisements as well
    as default agent reachability.   IP address configuration latency
    depends on the particular IP CoA being used.   If co-located mode
    with DHCP is used, the latency is quite likely going to be higher
    and unacceptable for real-time applications such as Voice over IP.
    Finally, the Mobile IP registration procedure needs a round-trip of
    delay between the Mobile Node and its Home Agent over the Internet.
    This delay is incurred after the Mobile Node mobile node performs movement
    detection and IP configuration.

    Underlying the IP operations are link-layer procedures.   These are
    clearly technology-specific.   For instance, instance in IEEE 802.11b
    which is also known as WLAN, 802.11, the
    handover operation may involve typically involves scanning access points over
    all available channels, selecting a suitable access point point, and
    associating with it.   It may also involve performing access control
    operations such as those specified in IEEE 802.1X. 802.1X [4].   These
    delays contribute to the handover performance.   Optimizations have been proposed and are
    being standardized proposed for standardization in IEEE
    however. IEEE, for instance see [5]
    and [3].   Together with appropriate implementation techniques,
    these optimizations can provide the required level of delay support
    at the link-layer for real-time applications.

    3. Protocol Operation

    3.1. Overview

    The design of the protocol is the same as for Mobile IPv6 [2]. [1].
    Readers should consult [2] [1] for details, and here we provide a
    summary.

    The protocol avoids the delay due to movement detection and IP
    configuration and disengage Mobile IP registration delay from
    the time-critical path.   The protocol provides the surrounding
    network network neighborhood information so that a Mobile Node mobile node can
    determine whether it is moving to a new subnet even before the
    handover.   The information provided and the signaling exchange exchanged
    between the local mobility agents allows the Mobile Node mobile node to send
    and receive packets immediately after handover.   In order to
    disengage the Mobile IP registration latency, the protocol provides
    routing support for the continued use of a Mobile Node's mobile node's previous
    CoA.

    After a MN mobile node obtains its IPv4 care-of address, it builds
    a neighborhood access point and subnet map using the Router
    Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router
    Advertisement (PrRtAdv) messages.   The MN mobile node 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 mobile node resolves the AP-ID corresponding AP Identifier
    to subnet information using the RtSolPr and PrRtAdv messages defined below.

    The coordination between the access routers is done by way of
    mentioned above.

    At some point, the mobile node decides to undergo handover.   It
    sends an FBU message to PAR from the previous link or from the new
    link.   FBU message enables creation of a binding between the mobile
    node's previous CoA and the new CoA.

    The coordination between the access routers is done by way of the
    Handover Initiate (HI) and Handover Initiate (HI) and Handover Acknowledge (HAck) messages. messages
    defined in [1].   After these signals have been exchanged between
    the previous and new 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.

    3.1. Basic NCoA Support

    3.2. Operation

    In response to a handover trigger or indication, the MN mobile node
    sends a Fast Binding Update message to Previous Access Router (PAR)
    (see Section 5.1).  This   Depending on whether the Mobile IP mode of
    operation, the PCoA is either the Home Address (in FA CoA mode)
    or co-located CoA (in CCoA mode).   The FBU message should SHOULD be sent
    when the MN mobile node is still connected to PAR. When sent in this
    ``predictive'' mode, the fields in the FBU are used as follows:

     -  ``Home Address'' field must be the PCoA, which PCoA (which can be either
        the Home Address (in FA CoA mode) or the co-located CoA. The CoA)

     -  Home Agent field, even though redundant, must be set to PAR's
        IP address, and the address

     -  Care-of Address field must be the NAR's IP address discovered
        via PrRtAdv message.  The destination message

     -  Destination IP address of the FBU message must be PAR's IP address.  The source address

     -  Source IP address of FBU message must
    contain be the PCoA (in co-located mode) or (which can be either the
        Home Address (in FA CoA
    mode) or the co-located CoA)

    As a result of processing the FBU, PAR creates a binding between
    PCoA and NAR's IP address (when NAR forwards the in its routing table.   The PAR sends an
    FBack message (see 5.2) as a response to PAR).

    When the mobile node.

    The timeline for the predictive mode of operation (adapted
    from [1]) is shown in Figure 1.

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

                     Figure 1: Predictive Fast Handover

    The mobile node sends the FBU regardless of its previous
    transmission when attachment to a new link is detected, detected.   This
    minimally allows NAR to detect mobile node's attachment, but also
    the retransmission of FBU should be (re)sent. when an FBack has not been received yet.
    When sent in this ``reactive'' mode, the destination following fields in FBU
    are set differently compared to the predictive mode:

     -  Destination IP address must be NAR's IP address, and the source address

     -  Source IP address must be either PCoA (either the Home Address (FA CoA mode) or PCoA (in co-located mode) the from the FBU
    message.  The Home Agent field must be set to PAR's IP address.
        co-located CoA)

    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
    should 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. PAR, which means the
    Source and Destination IP addresses now contain the IP addresses of
    NAR and PAR respectively.

    The reactive mode of operation (adapted from [1]) is illustrated in
    Figure 2.

    The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
    serve to establish a bidirectional tunnel between the routers
    to support packet forwarding for PCoA. The tunnel itself is
    established as a response to the FBU message.   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 HI message processing sent as
    a response to predictive and reactive modes of operation.

    3.2. Assigned Addressing Support

    In this mode,   If NAR
    receives a HI message with Code = 1, and it has already set up a
    host route entry and a reverse tunnel for PCoA, it should silently
    discard the NAR HI message.

    The protocol provides NCoA, which is delivered an option for NAR to return NCoA for use by
    the MN
    in mobile node.   When NAR can provide an NCoA for exclusive use of
    the FBAck message either on mobile node, the previous link or on address is supplied in the new
    link.  Since HAck message.   The
    PAR includes this NCoA in FBack.

    Even though the MN mobile node can obtain this NCoA from the NAR, it
    is unaware of the address that NAR might assign, at the time it sends an FBU. Hence, it always
    binds its PCoA to NAR's address.  This results in a
    bidirectional tunnel between PAR and NAR.

    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 as before.

                MN                    PAR                  NAR MUST also include the extension
    when responding to FBU sent from the new link.
                 |                     |                    |
                 |------RtSolPr------->|                    |
                 |<-----PrRtAdv--------|                    |
                 |                     |                    |
              disconnect               |                    |
                 |                     |                    |
                 |                     |                    |
              connect                  |                    |
                 |-----------FBU-------|------------------->|
                 |                     |<-----FBU-----------|
                 |                     |------FBack-------->|
                 |                   forward                |
                 |                   packets===============>|
                 |                      |                   |
                 |<=================================== deliver packets
                 |                                          |

                      Figure 2: Reactive Fast Handover

    4. 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]. [2].   However, with the neighborhood
    information gathered using the proxy router messages (see
    Section 5.3, Section 5.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.

    5. Message Formats

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

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

                Figure 1: 3: Fast Binding Update (FBU) Message
       IP fields:

           Source address
                                 The interface address from which the
                                 message is sent.   Either PCoA (co-located
                                mode),
                                 or Home Address (FA CoA mode) Address), or NAR's IP address
                                 (when forwarded from NAR to PAR).

           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 (i.e., either co-located CoA or the MN's
                              Home Address Address)

       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
    5.2. Fast Binding Acknowledgment (FBAck)

    The FBAck format is bitwise identical to the Registration Reply
    format in [4]. [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     |   reserved    |   Lifetime    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Home Address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Home Agent                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                           Identification                      +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Extensions ...
     +-+-+-+-+-+-+-+-

          Figure 2: 4: Fast Binding Acknowledgment (FBAck) Message
       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 the 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 (i.e., either co-located CoA or MN's Home Address
                              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 an 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], [2], 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.

    5.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 6.1.   The
    message format and processing rules are identical to that those defined
    in [2]. [1].   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: 5: 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 16-bit one's complement of the one's
                      complement sum of the ICMP message, start-
                      ing with the ICMP checksum. Type.   For computing the
                      checksum, the Checksum and the Reserved fields are
                      set to 0. See RFC 1256 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:

     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.

    5.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, mobile node, providing the link-layer
    address, IP address and subnet prefixes of neighboring routers.
    All the link-layer address options have the format defined in 6.1.

    The message format and processing rules are identical to that those
    defined in [2]. [1].   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: 6: 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
                      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 16-bit one's complement of the one's
                      complement sum of the ICMP message, start-
                      ing with the ICMP checksum. Type.   For computing the
                      checksum, the Checksum and the Reserved fields are
                      set to 0. 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.

    5.5. Inter-Access Router Messages

    5.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 mobile node's handover.

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

    IP Fields:

     Source Address
                     The IP address of the PAR

     Destination Address
                     The IP address of 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           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Subtype    |S|U| Reserved  |            Identifier         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Options ...
    +-+-+-+-+-+-+-+-+-+-+-+-

                 Figure 5: 7: 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 16-bit one's complement of the one's
                      complement sum of the ICMP message, start-
                      ing with the ICMP checksum. Type.   For computing the
                      checksum, the Checksum and the Reserved fields are
                      set to 0. See RFC 1256 1256.

     Subtype         To be assigned by IANA

     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.

    5.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 5.5.1) message.

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

 IP Fields:

     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: 8: Handover Acknowledge (HAck) Message

    IP Fields:

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

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

     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 16-bit one's complement of the one's
                 complement sum of the ICMP message, start-
                 ing with the ICMP checksum. Type.   For computing the
                 checksum, the Checksum and the Reserved fields are
                 set to 0. 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 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.

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

    6.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: 9: 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-
                        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.

    6.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: 10: 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 IPv4 Address
                        NAR's IPv4 address or the NCoA assigned by NAR.

    6.3. New Router Prefix Information Option

    This option is the same as the ``Prefix-Lengths Extension'' in RFC
    3344 (Section 2.1.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     |     Length    | Prefix-Length |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 9: 11: 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.

    7. Security Considerations

    The FBU and FBack messages MUST be protected using a security
    association shared between a MN mobile node 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 mobile node's address
    and binding it to an arbitrary address.   When the NCoA is NAR's
    address, there is no risk of a genuine MN mobile node misdirecting
    traffic, either inadvertantly inadvertently 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.

    8. IANA Considerations

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

    9. Acknowledgement

    Thanks to all those who expressed interest in having a Fast
    Handovers for Mobile IPv4 protocol along the lines of [1].   Thanks
    to Vijay Devarapalli, Keng Leung, Alex Petrescu for their review
    and input.

    Normative References

    [1] S. Deering.  ICMP Router Discovery Messages. R. (Editor) Koodli.   Fast Handovers for Mobile IPv6.   Request
        for Comments (Proposed Standard) 1256, 4068, Internet Engineering Task Force, September 1991. July 2005.

    [2] R. Koodli C. Perkins (Editor).  Fast Handovers   IP Mobility Support for Mobile IPv6 (work in
        progress).  Internet Draft, IPv4.   Request
        for Comments (Proposed Standard) 3344, Internet Engineering
        Task Force.
        draft-ietf-mipshop-fast-mipv6-03.txt, October 2005. Force, August 2002.

    Informative References

    [3] The IEEE 802.21 group. http://www.ieee802.org/21.   Technical
        report, IEEE.

    [4] IEEE Standard for Local and Metropolitan Area Networks:
        Port-Based Network Access Control.   Technical report, IEEE.

    [5] IEEE Standard forLocal and Metropolitan Area Networks:
        Fast Roaming/Fast BSS Transition, the IEEE Task Group TGr.
        Technical report, IEEE.

    [6] R. Droms.   Dynamic Host Configuration Protocol.   Request for
        Comments (Draft Standard) 2131, Internet Engineering Task
        Force, March 1997.

    [7] 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
       Nokia Research Center                   Nokia Research Center
       313 Fairchild Drive                    313 Fairchild Drive
       Mountain View,
       975 Page Mill Road, 200                 975 Page Mill Road, 200
       Palo Alto, California 94043        Mountain View, 94304             Palo Alto, California 94043 94304
       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.

    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 SOCIETY, THE
    IETF TRUST, 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 (2006). IETF Trust (2007).

    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.