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

Versions: (draft-koodli-mip4-fmipv4) 00 01 02 03 04 05 06 07 RFC 4988

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



                         Mobile IPv4 Fast Handovers
                        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 MIP4 WG mailing list, mip4@ietf.org.


    Abstract

    This document adapts the Mobile IPv6 Fast Handovers [1] to
    improve delay and packet loss resulting from Mobile IPv4 handover
    operations.   Specifically, this document addresses movement
    detection, IP address configuration and location update latencies
    during a handover.   For reducing the IP address configuration
    latency, the document proposes that the new 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.

Koodli, Perkins             Expires 6 August 2007                  [Page i]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007


                                     Contents


Abstract                                                                   i


 1.  Introduction                                                          2

 2.  Factors Affecting Handover                                            3

 3.  Protocol                                                              4
      3.1.  Overview   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .   4
      3.2.  Operation .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .    5

 4.  Use of Previous FA Notification Extension                             8

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

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

 7.  Security Considerations                                               25

 8.  IANA Considerations                                                   25

 9.  Acknowledgement                                                       25

Intellectual Property Statement                                            27



Koodli, Perkins               Expires 6 August 2007                 [Page ii]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



Disclaimer of Validity                                                     27

Copyright Statement                                                        28

Acknowledgment                                                             28



Koodli, Perkins               Expires 6 August 2007                  [Page 1]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



    1. Introduction

    This document adapts the fast handover specification [1] to
    IPv4 networks.   The fast handover protocol specified in this
    document is particularly interesting for operation over wireless
    links such as IEEE 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 faster implementation using existing
    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, consistent with the terminology
    in [1].   Unless otherwise mentioned, a PAR is also a Previous
    Foreign Agent (PFA) and a NAR is also a New Foreign Agent (NFA).

    On a particular network, a mobile node may obtain its IP address
    via DHCP [6] (i.e., 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 mobile node to receive and send
    packets using its previous CoA (PCoA), so that delays resulting
    from IP configuration (such as DHCP address acquisition delay)



Koodli, Perkins               Expires 6 August 2007                  [Page 2]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



    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 performs movement
    detection and IP configuration.

    Underlying the IP operations are link-layer procedures.   These are
    clearly technology-specific.   For instance in IEEE 802.11, the
    handover operation typically involves scanning access points over
    all available channels, selecting a suitable access point, and
    associating with it.   It may also involve performing access control
    operations such as those specified in IEEE 802.1X [4].   These
    delays contribute to the handover performance.   Optimizations are
    being proposed for standardization in IEEE, for instance see [5]
    and [3].   Together with appropriate implementation techniques,


Koodli, Perkins               Expires 6 August 2007                  [Page 3]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



    these optimizations can provide the required level of delay support
    at the link-layer for real-time applications.


    3. Protocol

    3.1. Overview

    The design of the protocol is the same as for Mobile IPv6 [1].
    Readers should consult [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 can
    determine whether it is moving to a new subnet even before the
    handover.   The information provided and the signaling exchanged
    between the local mobility agents allows the 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 previous
    CoA.

    After a 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 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 mobile node resolves the corresponding AP Identifier
    to subnet information using the RtSolPr and PrRtAdv messages
    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.


Koodli, Perkins               Expires 6 August 2007                  [Page 4]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007


    The coordination between the access routers is done by way of the
    Handover Initiate (HI) and Handover Acknowledge (HAck) 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.


    3.2. Operation

    In response to a handover trigger or indication, the mobile node
    sends a Fast Binding Update message to Previous Access Router (PAR)
    (see Section 5.1).   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 be sent
    when the 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 can be either
        the Home Address or the co-located CoA)

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

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

     -  Destination IP address must be PAR's IP address

     -  Source IP address must be the PCoA (which can be either the
        Home Address or the co-located CoA)

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


Koodli, Perkins               Expires 6 August 2007                  [Page 5]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



    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.   This
    minimally allows NAR to detect mobile node's attachment, but also
    the retransmission of FBU when an FBack has not been received yet.
    When sent in this ``reactive'' mode, the following fields in FBU
    are set differently compared to the predictive mode:


Koodli, Perkins               Expires 6 August 2007                  [Page 6]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007


     -  Destination IP address must be NAR's IP address

     -  Source IP address must be PCoA (either the Home Address or the
        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
    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, 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.   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 HI message.

    The protocol provides an option for NAR to return NCoA for use by
    the mobile node.   When NAR can provide an NCoA for exclusive use of
    the mobile node, the address is supplied in the HAck message.   The
    PAR includes this NCoA in FBack.

    Even though the mobile node can obtain this NCoA from the NAR, it
    is unaware of the address at the time it sends an FBU. Hence, it
    binds PCoA to NAR's IP address as before.


Koodli, Perkins               Expires 6 August 2007                  [Page 7]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



                MN                    PAR                  NAR
                 |                     |                    |
                 |------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 [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.


Koodli, Perkins               Expires 6 August 2007                  [Page 8]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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



                Figure 3: Fast Binding Update (FBU) Message



Koodli, Perkins               Expires 6 August 2007                  [Page 9]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



       IP fields:

           Source address
                                 The interface address from which the
                                 message is sent.   Either PCoA (co-located
                                 or Home 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

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



Koodli, Perkins               Expires 6 August 2007                 [Page 10]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



    5.2. Fast Binding Acknowledgment (FBAck)

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



          Figure 4: Fast Binding Acknowledgment (FBAck) Message



Koodli, Perkins               Expires 6 August 2007                 [Page 11]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



       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 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 Home
                              Address)

       Home Agent             The Previous Access Router's global IP
                              address

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



Koodli, Perkins               Expires 6 August 2007                 [Page 12]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



       Extensions             The PAR - MN Authentication extension MUST
                              be present.   In addition, 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 [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 those defined
    in [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 5: Router Solicitation for Proxy (RtSolPr) Message



    IP Fields:


Koodli, Perkins               Expires 6 August 2007                 [Page 13]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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



Koodli, Perkins               Expires 6 August 2007                 [Page 14]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



                     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 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 those
    defined in [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 6: Proxy Router Advertisement (PrRtAdv) Message



    IP Fields:

     Source Address
                     An IP address assigned to the sending interface



Koodli, Perkins               Expires 6 August 2007                 [Page 15]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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



Koodli, Perkins               Expires 6 August 2007                 [Page 16]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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

    The message format and processing rules are identical to those
    defined in [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


Koodli, Perkins               Expires 6 August 2007                 [Page 17]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



     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 7: Handover Initiate (HI) Message


     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 Type.   For computing the
                      checksum, the Checksum and the Reserved fields are
                      set to 0. See RFC 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.


Koodli, Perkins               Expires 6 August 2007                 [Page 18]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



     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.



Koodli, Perkins               Expires 6 August 2007                 [Page 19]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



    The message format and processing rules are identical to those
    defined in [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 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:



Koodli, Perkins               Expires 6 August 2007                 [Page 20]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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



Koodli, Perkins               Expires 6 August 2007                 [Page 21]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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



Koodli, Perkins               Expires 6 August 2007                 [Page 22]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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


Koodli, Perkins               Expires 6 August 2007                 [Page 23]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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


Koodli, Perkins               Expires 6 August 2007                 [Page 24]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



      Reserved         Set to zero.


    7. Security Considerations

    The FBU and FBack messages MUST be protected using a security
    association shared between a 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 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 mobile node misdirecting
    traffic, either 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.



Koodli, Perkins               Expires 6 August 2007                 [Page 25]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



    Normative References

    [1] R. (Editor) Koodli.   Fast Handovers for Mobile IPv6.   Request
        for Comments 4068, Internet Engineering Task Force, July 2005.

    [2] C. Perkins (Editor).   IP Mobility Support for IPv4.   Request
        for Comments (Proposed Standard) 3344, Internet Engineering
        Task 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.



    Questions about this memo can be directed to the authors:

       Rajeev Koodli                           Charles E. Perkins
       Nokia Research Center                   Nokia Research Center
       975 Page Mill Road, 200                 975 Page Mill Road, 200
       Palo Alto, California 94304             Palo Alto, California 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



Koodli, Perkins               Expires 6 August 2007                 [Page 26]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007



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


Koodli, Perkins               Expires 6 August 2007                 [Page 27]

Internet Draft       Fast Handovers for Mobile IPv4          6 February 2007


    Copyright Statement

    Copyright (C) The 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.



Koodli, Perkins               Expires 6 August 2007                 [Page 28]


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