[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
23 October 2006                                        Nokia Research Center



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



    Abstract


    The Mobile IPv6 fast handover document [2] specifies a protocol to
    improve latency and packet loss resulting from Mobile IPv6 handover
    operations.  This document adapts the protocol for IPv4 networks
    to improve performance over Mobile IPv4 operations, including
    processing of Agent Advertisements, new Care of Address acquisition
    and Registration Request and Reply.  Using the concepts outlined
    in [2], this document also addresses movement detection, IP address
    configuration and location update latencies during a handover.
    For reducing the IP address configuration, the document currently
    proposes that the new CoA is always made to be the new access
    router's IP address.  Additional mechanisms may be defined in the
    future versions of this document.



Koodli, Perkins                Expires 23 April 2007                  [Page i]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



                                     Contents



Abstract                                                                      i


 1.  Introduction                                                             2


 2.  Factors Affecting Handover                                              2


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


 4.  Use of Previous FA Notification Extension                             5


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


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


 7.  Security Considerations                                                17


 8.  IANA Considerations                                                    18


Intellectual Property Statement                                            18


Disclaimer of Validity                                                      19


Copyright Statement                                                         19


Acknowledgment                                                              19



Koodli, Perkins                Expires 23 April 2007                  [Page 1]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    1. Introduction


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


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


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



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



Koodli, Perkins                Expires 23 April 2007                  [Page 2]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    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.11b
    which is also known as WLAN, the handover operation may involve
    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. These delays contribute to the handover performance.
    Optimizations have been proposed and are being standardized in IEEE
    however.  Together with appropriate implementation techniques, these
    optimizations can provide the required level of delay support for
    real-time applications.



    3. Protocol Operation


    The design of the protocol is the same as for Mobile IPv6 [2].
    Readers should consult [2] 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 exchange 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 MN obtains its IPv4 care-of address, it builds a neighborhood
    access point and subnet map using the Router Solicitation for Proxy
    Advertisement and Proxy Router Advertisement messages.  The MN may
    scan for access points (APs) based on the configuration policy in
    operation for its wireless network interface.  If a scan results in
    a new AP discovery, the MN resolves the AP-ID to subnet information
    using the messages defined below.



Koodli, Perkins                Expires 23 April 2007                  [Page 3]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



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


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


    When attachment to a new link is detected, FBU should be (re)sent.
    When sent in this ``reactive'' mode, the destination address must
    be NAR's IP address, and the source address must be either 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.
    When NAR receives FBU, it may already have processed the HI message
    and created a host route entry for the PCoA. In that case, NAR can
    immediately forward arriving and buffered packets including the FBAck



Koodli, Perkins                Expires 23 April 2007                  [Page 4]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    message.  In any case, NAR MUST forward the contents of this message,
    starting from the Type field, to PAR.


    The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
    serve to establish a 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, the NAR provides NCoA, which is delivered to the MN
    in the FBAck message either on the previous link or on the new
    link.  Since the MN is unaware of the address that NAR might assign,
    it always binds its PCoA to NAR's address.  This results in a
    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 NAR MUST also include the extension
    when responding to FBU sent from the new link.



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



Koodli, Perkins                Expires 23 April 2007                  [Page 5]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    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|          Lifetime             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Home Address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              Home Agent                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Care-of Address                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                            Identification                     +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Extensions ...
    +-+-+-+-+-+-+-+-



                Figure 1: Fast Binding Update (FBU) Message



       IP fields:


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






Koodli, Perkins                Expires 23 April 2007                  [Page 6]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



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


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


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



     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     |           Lifetime            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Home Address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              Home Agent                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                            Identification                     +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Extensions ...
    +-+-+-+-+-+-+-+-



           Figure 2: Fast Binding Acknowledgment (FBAck) Message



Koodli, Perkins                Expires 23 April 2007                  [Page 7]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



       IP fields:


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


          Destination Address
                                Copied from the Source IP address in FBU
                                message


          Source Port           variable


          Destination port      copied from thr source port in FBU message


       Type                  To be assigned by IANA


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



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


       Home Address          PCoA or MN's Home Address


       Home Agent            The Previous Access Router's global IP address


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


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


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



    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



Koodli, Perkins                Expires 23 April 2007                  [Page 8]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



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



    0                   1                 2                     3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |      Code     |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Subtype    |    Reserved   |           Identifier          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-



         Figure 3: Router Solicitation for Proxy (RtSolPr) Message



 IP Fields:


    Source Address
                    An IP address assigned to the sending interface


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


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


 ICMP Fields:


    Type            To be assigned by IANA


    Code            0


    Checksum        The ICMP checksum. See RFC 1256


    Subtype         To be assigned by IANA


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


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


 Valid Options:



Koodli, Perkins                Expires 23 April 2007                  [Page 9]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    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, 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 defined
    in [2].  We only provide the format here for convenience.  The ICMP
    checksum is defined in [1].



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |      Code     |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Subtype    |    Reserved   |           Identifier          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-



          Figure 4: Proxy Router Advertisement (PrRtAdv) Message



 IP Fields:


    Source Address
                    An IP address assigned to the sending interface


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



Koodli, Perkins               Expires 23 April 2007                  [Page 10]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



                    handover.


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


 ICMP Fields:


    Type            To be assigned by IANA


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


    Checksum        The ICMP checksum. See RFC 1256.


    Subtype         To be assigned by IANA.


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


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


 Valid Options in the following order:


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


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


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


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



Koodli, Perkins               Expires 23 April 2007                  [Page 11]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



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


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



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |      Code     |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Subtype    |S|U| Reserved  |             Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-



                  Figure 5: Handover Initiate (HI) Message



 IP Fields:


    Source Address
                    The IP address of the PAR


    Destination Address
                    The IP address of the NAR


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


 ICMP Fields:


    Type            To be assigned by IANA


    Code            0 or 1. See below


    Checksum        The ICMP checksum. See RFC 1256


    Subtype         To be assigned by IANA



Koodli, Perkins               Expires 23 April 2007                  [Page 12]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    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 defined
    in [2].  We only provide the format here for convenience.



 IP Fields:



Koodli, Perkins               Expires 23 April 2007                  [Page 13]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |      Code     |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Subtype    |     Reserved  |           Identifier          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-



               Figure 6: Handover Acknowledge (HAck) Message



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


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


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


 ICMP Fields:


    Type           To be assigned by IANA


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


    Checksum    The ICMP checksum. See RFC 1256.


    Subtype       To be assigned by IANA.



Koodli, Perkins               Expires 23 April 2007                  [Page 14]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    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: Link-Layer Address Option Format



    Fields:


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


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



Koodli, Perkins               Expires 23 April 2007                  [Page 15]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



                        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: New IPv4 Address Option Format



    Fields:


       Type
                        To be assigned by IANA


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


      Reserved         Set to zero.


      NCoA              The New CoA assigned by NAR.



    6.3. New Router Prefix Information Option


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



Koodli, Perkins               Expires 23 April 2007                  [Page 16]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    | Prefix-Length |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



           Figure 9: New Router Prefix Information Option Format



    Fields:


       Type
                        To be assigned by IANA


       Length          1


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


      Reserved         Set to zero.



    7. Security Considerations


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



Koodli, Perkins               Expires 23 April 2007                  [Page 17]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    8. IANA Considerations


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



    References


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


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


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


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


    Questions about this memo can be directed to the authors:



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


    Intellectual Property Statement


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


    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an



Koodli, Perkins               Expires 23 April 2007                  [Page 18]

Internet Draft       Fast Handovers for Mobile IPv4           23 October 2006



    attempt made to obtain a general license or permission for the
    use of such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.


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



    Disclaimer of Validity


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



    Copyright Statement


    Copyright (C) The Internet Society (2006).  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 23 April 2007                  [Page 19]


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