GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4881

Network Working Group K. El Malki, Ed. Request for Comments: 4881 Athonet Category: Experimental June 2007

                Low-Latency Handoffs in Mobile IPv4

Status of This Memo

 This memo defines an Experimental Protocol for the Internet
 community.  It does not specify an Internet standard of any kind.
 Discussion and suggestions for improvement are requested.
 Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 Mobile IPv4 describes how a Mobile Node can perform IPv4-layer
 handoffs between subnets served by different Foreign Agents.  In
 certain cases, the latency involved in these handoffs can be above
 the threshold required for the support of delay-sensitive or real-
 time services.  The aim of this document is to present two methods to
 achieve low-latency Mobile IPv4 handoffs.  In addition, a combination
 of these two methods is described.  The described techniques allow
 greater support for real-time services on a Mobile IPv4 network by
 minimizing the period of time when a Mobile Node is unable to send or
 receive IPv4 packets due to the delay in the Mobile IPv4 Registration
 process.

Table of Contents

 1. Introduction ....................................................3
    1.1. Terminology ................................................4
    1.2. The Techniques .............................................5
    1.3. L2 Triggers ................................................7
    1.4. Requirements Language ......................................9
 2. Requirements ....................................................9
 3. The PRE-REGISTRATION Handoff Method ............................10
    3.1. Operation .................................................11
    3.2. Network-Initiated Handoff .................................13
    3.3. Mobile-Initiated Handoff ..................................15
    3.4. Obtaining and Proxying nFA Advertisements .................17
         3.4.1. Inter-FA Solicitation ..............................17
         3.4.2. Tunneled nFA Advertisements ........................18
    3.5. Caching Router Advertisements .............................19

El Malki, Ed. Experimental [Page 1] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

    3.6. Movement Detection, MN, and FA Considerations .............19
    3.7. L2 Address Considerations .................................21
    3.8. Applicability of PRE-REGISTRATION Handoff .................21
 4. The POST-REGISTRATION Handoff Method ...........................23
    4.1. Two-Party Handoff .........................................24
    4.2. Three-Party Handoff .......................................28
    4.3. Renewal or Termination of Tunneling Service ...............34
    4.4. When Will the MN Perform a Mobile IPv4 Registration? ......34
    4.5. Handoff Request (HRqst) Message Format ....................36
    4.6. Handoff Reply (HRply) Message Format ......................38
    4.7. Handoff to Third (HTT) Message Format .....................40
    4.8. Applicability of POST-REGISTRATION Handoff Method .........40
 5. Combined Handoff Method ........................................41
 6. Layer 2 and Layer 3 Handoff Timing Considerations ..............42
 7. Reverse Tunneling Support ......................................42
 8. Handoff Signaling Failure Recovery .............................43
    8.1. PRE-REGISTRATION Signaling Failure Recovery ...............43
         8.1.1. Failure of PrRtSol and PrRtAdv .....................43
         8.1.2. Failure of Inter-FA Solicitation and
                Advertisement ......................................44
    8.2. POST-REGISTRATION Signaling Failure Recovery ..............44
         8.2.1. HRqst Message Dropped ..............................44
         8.2.2. HRply Message Dropped ..............................45
 9. Generalized Link Layer and IPv4 Address (LLA) Extension ........46
    9.1. 3GPP2 IMSI Link Layer Address and Connection ID
         Extension .................................................47
    9.2. 3GPP IMSI Link Layer Address Extension ....................48
    9.3. Ethernet Link Layer Address Extension .....................49
    9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..50
    9.5. Solicited IPv4 Address Extension ..........................51
    9.6. Access Point Identifier Extension .........................52
    9.7. FA IPv4 Address Extension .................................53
 10. IANA Considerations ...........................................53
    10.1. New Extension Values .....................................53
    10.2. Generalized Link Layer and IP Address Identifier (LLA) ...54
    10.3. New Message Type and Code ................................54
 11. Security Considerations .......................................55
 12. Acknowledgements ..............................................57
 13. References ....................................................57
    13.1. Normative References .....................................57
    13.2. Informative References ...................................58
 Appendix A - Gateway Foreign Agents................................59
 Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......60
 Appendix C - PRE_REGISTRATION Message Summary......................61

El Malki, Ed. Experimental [Page 2] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

1. Introduction

 Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IPv4-
 layer handoff between subnets served by different Foreign Agents
 (FAs).  In certain cases, the latency involved in handoff can be
 above the threshold required for the support of delay-sensitive or
 real-time services.  The aim of this document is to present two
 techniques to achieve low-latency Mobile IPv4 handoff during movement
 between FAs.  A further combination of these two techniques is also
 described.  The presented techniques allow greater support for real-
 time services on a Mobile IPv4 network by minimizing the period of
 time during which an MN is unable to send or receive IPv4 packets due
 to the delay in the Mobile IPv4 Registration process.  One or more of
 these techniques may be required to achieve fast Mobile IPv4 handoffs
 over different wireless technologies (e.g., WLAN, Cellular, WiMAX,
 Flash-OFDM, etc.).  Each wireless technology has different layer 2
 handoff procedures, and the best low-latency technique for each
 scenario should be used to optimize the handoff performance.  Further
 deployment and experimentation are required to determine which
 technique is best suited to the wireless technologies in terms of
 implementation and performance.  Therefore, the authors encourage
 further performance measurements and work on low-latency-over-foo
 specifications in collaboration with the appropriate wireless
 technology fora to describe the applicability to different wireless
 layer 2s.
 In the rest of this section, terminology used throughout the document
 is presented, the handoff techniques are briefly described, and the
 use of link-layer information is outlined.  In Section 2, a brief
 description of requirements is presented.  Section 3 describes the
 details of the PRE-REGISTRATION handoff technique, and Section 4
 describes the details of the POST-REGISTRATION handoff technique.  In
 Section 5, a combined method using the two handoff techniques
 together is presented.  Section 6 discusses layer 2 and layer 3
 handoff timing considerations.  Section 7 discusses reverse tunneling
 support, Section 8 describes mechanisms to recover from message
 failures, and Section 9 describes protocol extensions required by the
 handoff techniques.  Sections 10 and 11 discuss IANA and security
 considerations.  Finally, the three appendices discuss additional
 material related to the handoff techniques.  Appendix A gives a short
 introduction to Regional Registrations [11], which can be used
 together with low-latency handoffs.  Appendix B discusses low-latency
 handoff when an MN has multiple wireless L2 interfaces, in which case
 the techniques in this document may not be necessary.  Appendix C
 provides a summary of the messages used in PRE-REGISTRATION.

El Malki, Ed. Experimental [Page 3] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

1.1. Terminology

 This section presents a few terms used throughout the document.
    oFA - old Foreign Agent (FA), the FA involved in handling the
       care-of address (CoA) of a Mobile Node (MN) prior to a layer 3
       (L3) handoff.
    nFA - new Foreign Agent, the FA anticipated to be handling an MN's
       care-of address after completion of an L3 handoff.
    aFA - anchor Foreign Agent, the FA that is currently handling the
       network end of the tunnel in POST-REGISTRATION.
    L2 handoff - Movement of an MN's point of layer 2 (L2) connection
       from one wireless access point to another.
    L3 handoff - Movement of an MN between FAs that involves changing
       the care-of address at Layer 3 (L3).
    L2 trigger - Information from L2 that informs L3 of particular
       events before and after L2 handoff.  The descriptions of L2
       triggers in this document are not specific to any particular
       L2, but rather represent generalizations of L2 information
       available from a wide variety of L2 protocols.
    L2-MT - An L2 trigger that occurs at the MN, informing of movement
       to a certain nFA (Mobile Trigger).
    L2-ST or source trigger - An L2 trigger that occurs at oFA,
       informing the oFA that L2 handoff is about to occur.
    L2-TT or target trigger - An L2 trigger that occurs at nFA,
       informing the nFA that an MN is about to be handed off to nFA.
    L2-LU - An L2 trigger that occurs at the MN or nFA, informing that
       the L2 link between MN and nFA is established.
    L2-LD - An L2 trigger that occurs at the oFA, informing the oFA
       that the L2 link between MN and oFA is lost.
    low-latency handoff - L3 handoff in which the period of time
       during which the MN is unable to receive packets is minimized.
    low-loss handoff - L3 handoff in which the number of packets
       dropped or delayed is minimized.  Low-loss handoff is often
       called smooth handoff.

El Malki, Ed. Experimental [Page 4] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

    seamless handoff - L3 handoff that is both low latency and low
       loss.
    bidirectional edge tunnel (BET) -  A bidirectional tunnel
       established between two FAs for purposes of temporarily routing
       an MN's traffic to/from it on a new subnet without requiring
       the MN to change CoA.
    ping-pong - Rapid back-and-forth movement between two wireless
       access points often due to failure of L2 handoff.  Ping-pong
       can occur if radio conditions for both the old and new access
       points are about equivalent and less than optimal for
       establishing a good, low-error L2 connection.
    network-initiated handoff - L3 handoff in which oFA or nFA
       initiates the handoff.
    mobile-initiated handoff - L3 handoff in which the MN initiates
       the handoff.
    MN or FA identifier - An IPv4 address of an MN or FA, or an L2
       identifier that can be resolved to the IPv4 address of an MN or
       FA.  If the identifier is an L2 identifier, it may be specific
       to the L2 technology.

1.2. The Techniques

 Mobile IPv4 was originally designed without any assumptions about the
 underlying link layers over which it would operate so that it could
 have the widest possible applicability.  This approach has the
 advantage of facilitating a clean separation between L2 and L3 of the
 protocol stack, but it has negative consequences for handoff latency.
 The strict separation between L2 and L3 results in the following
 built-in sources of delay:
  1. The MN may only communicate with a directly connected FA. This

implies that an MN may only begin the registration process after

      an L2 handoff to nFA (new FA) has completed.
  1. The registration process takes some non-zero time to complete as

the Registration Requests propagate through the network. During

      this period of time, the MN is not able to send or receive IPv4
      packets.
 This document presents techniques for reducing these built-in delay
 components of Mobile IPv4.  The techniques can be divided into two
 general categories, depending on which of the above problems they are
 attempting to address:

El Malki, Ed. Experimental [Page 5] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

  1. Allow the MN to communicate with the nFA while still connected

to the oFA.

  1. Provide for data delivery to the MN at the nFA even before the

formal registration process has completed.

 The first category of techniques allows the MN to "pre-build" its
 registration state on the nFA prior to an underlying L2 handoff.  The
 second category of techniques allows for service to continue
 uninterrupted while the handoff is being processed by the network
 without requiring the MN's involvement.
 Three methods are presented in this document to achieve low-latency
 L3 handoff, one for each category described above and one as a
 combination of the two:
  1. PRE-REGISTRATION handoff method,
  1. POST-REGISTRATION handoff method, and
  1. combined handoff method.
 The PRE-REGISTRATION handoff method allows the MN to be involved in
 an anticipated IPv4-layer handoff.  The MN is assisted by the network
 in performing an L3 handoff before it completes the L2 handoff.  The
 L3 handoff can be either network-initiated or mobile-initiated.
 Accordingly, L2 triggers are used both in the MN and in the FA to
 trigger particular L3 handoff events.  The PRE-REGISTRATION method
 coupled with L2 mobility helps to achieve seamless handoffs between
 FAs.  The basic Mobile IPv4 concept involving advertisement followed
 by registration is supported, and the PRE-REGISTRATION handoff method
 relies on Mobile IPv4 security.  No new messages are proposed, except
 for an extension to the Agent Solicitation message in the mobile-
 initiated case.
 The POST-REGISTRATION handoff method proposes extensions to the
 Mobile IPv4 protocol to allow the oFA (old FA) and nFA (new FA) to
 utilize L2 triggers to set up a bidirectional tunnel between oFA and
 nFA that allows the MN to continue using its oFA while on nFA's
 subnet.  This enables a rapid establishment of service at the new
 point of attachment, which minimizes the impact on real-time
 applications.  The MN must eventually perform a formal Mobile IPv4
 Registration after L2 communication with the new FA is established,
 but this can be delayed as required by the MN or FA.  Until the MN
 performs registration, the FAs will set up and move bidirectional
 tunnels as required to give the MN continued connectivity.

El Malki, Ed. Experimental [Page 6] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 The combined method involves running a PRE-REGISTRATION and a POST-
 REGISTRATION handoff in parallel.  If the PRE-REGISTRATION handoff
 can be performed before the L2 handoff completes, the combined method
 resolves to a PRE-REGISTRATION handoff.  However, if the PRE-
 REGISTRATION handoff does not complete within an access technology
 dependent time period, the oFA starts forwarding traffic for the MN
 to the nFA as specified in the POST-REGISTRATION handoff method.
 This provides for a useful backup mechanism when completion of a
 PRE-REGISTRATION handoff cannot always be guaranteed before the L2
 handoff completion.
 It should be noted that the methods described in this document may be
 applied to MNs having a single interface (e.g., Wireless LAN
 interface) or multiple interfaces (e.g., one WLAN and one cellular
 interface).  However, the case of multiply-interfaced MNs needs
 special consideration, since the handoff methods described in this
 document may not be required in all cases (see Appendix B).

1.3. L2 Triggers

 An L2 trigger is a signal of an L2 event.  In this document, the L2
 events relate to the L2 handoff process.  One possible event is early
 notice of an upcoming change in the L2 point of attachment of the
 mobile node to the access network.  Another possible event is the
 completion of relocation of the mobile node's L2 point of attachment
 to a new L2 access point.  This information may come explicitly from
 L2 in a solicited or unsolicited manner, or it may be derived from L2
 messages.  Although the protocols outlined in this document make use
 of specific L2 information, Mobile IPv4 should be kept independent of
 any specific L2.  L2 triggers are an abstraction mechanism for a
 technology-specific trigger.  Therefore, an L2 trigger that is made
 available to the Mobile IPv4 stack is assumed to be generic and
 technology independent.  The precise format of these triggers is not
 covered in this document, but the information required to be
 contained in the L2 triggers for low-latency handoffs is specified.
 In order to properly abstract from the L2, it is assumed that one of
 the three entities -- the MN, oFA, or nFA -- is made aware of the
 need for an L2 handoff and that the nFA or MN can optionally also be
 made aware that an L2 handoff has completed.  A specific L2 will
 often dictate when a trigger is received and which entity will
 receive it.  Certain L2s provide advance triggers on the network
 side, while others provide advance triggers on the MN.  Also, the
 particular timing of the trigger with respect to the actual L2
 handoff may differ from technology to technology.  For example, some
 wireless links may provide such a trigger well in advance of the
 actual handoff.  In contrast, other L2s may provide little or no
 information in anticipation of the L2 handoff.

El Malki, Ed. Experimental [Page 7] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 An L2 trigger may be categorized according to whether it is received
 by the MN, oFA, or nFA.  Table 1 gives such a categorization along
 with information contained in the trigger.  The methods presented in
 this document operate based on different types of L2 triggers as
 shown in Table 1.  Once the L2 trigger is received, the handoff
 processes described hereafter are initiated.  The three triggers,
 L2-ST, L2-TT, and L2-MT, are independent of each other and are not
 expected to occur together since each will trigger a different type
 of handoff behaviour.
 +-------------+----------------------+------------------------------+
 | L2 Trigger  |       Mobile         |           Source             |
 |             |       Trigger        |           Trigger            |
 |             |       (L2-MT)        |           (L2-ST)            |
 +-------------+----------------------+------------------------------+
 | Recipient   |          MN          |             oFA              |
 +-------------+----------------------+--------------+---------------+
 | Method      | PRE                  | PRE          | POST          |
 |             | mobile-initiated     | network-     | source        |
 |             |                      | initiated    | trigger       |
 +-------------+----------------------+--------------+---------------+
 | When?       | sufficiently before  | sufficiently | sufficiently  |
 |             | the L2 handoff       | before L2    | before L2     |
 |             | so that MN can       | handoff for  | handoff for   |
 |             | solicit PrRtAdv      | FA to send   | oFA & nFA to  |
 |             | from oFA             | PrRtAdv      | exchange      |
 |             |                      | to MN        | HRqst/HRply   |
 +-------------+----------------------+--------------+---------------+
 | Parameters  | nFA identifier       | nFA identifier, MN identifier|
 +-------------+----------------------+------------------------------+
                          Table 1 - L2 Trigger
                        (continued on next page)

El Malki, Ed. Experimental [Page 8] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 +------------+----------------------+---------------+---------------+
 | L2 Trigger |       Target         |  Link-Up      |  Link-Down    |
 |            |       Trigger        |  (L2-LU)      |   (L2-LD)     |
 |            |       (L2-TT)        |               |               |
 |------------+----------------------+---------------+---------------+
 | Recipient  |          nFA         |  MN or nFA    |     oFA       |
 |------------+-----------+----------+---------------+---------------+
 | Method     | PRE       |  POST    |  PRE & POST   |    POST       |
 |            | network-  |  target  |               |               |
 |            | initiated |  trigger |               |               |
 |------------+----------------------+---------------+---------------+
 | When?      |                      | when radio    |  when radio   |
 |            |   same as            | link between  |  link between |
 |            |   source trigger     | MN & nFA  is  |  MN and oFA   |
 |            |                      | established   |  is lost      |
 |------------+----------------------+---------------+---------------+
 | Parameters | oFA identifier       | @MN: nFA IPv4 | MN identifier |
 |            | MN identifier        | or L2 addr.   |               |
 |            |                      | @nFA: MN IPv4 |               |
 |            |                      | or L2 addr.   |               |
 +------------+----------------------+---------------+---------------+
                         Table 1 - L2 Trigger

1.4. Requirements Language

 In this document, the key words "MAY", "MUST", "MUST NOT",
 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT" are to be
 interpreted as described in [2].

2. Requirements

 The following requirements are applicable to low-latency handoff
 techniques and are supported by the methods in this document:
  1. to provide low-latency and low-loss handoff for real-time

services,

  1. to have no dependence on a wireless L2 technology,
  1. to support inter- and intra-access technology handoffs, and
  1. to limit wireless bandwidth usage.

El Malki, Ed. Experimental [Page 9] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

3. The PRE-REGISTRATION Handoff Method

 The PRE-REGISTRATION handoff method is based on the normal Mobile
 IPv4 handoff procedure specified in [1], according to which:
  1. an advertisement for an FA is received by an MN,
  1. the advertisement allows the MN to perform movement detection,

and

  1. the MN registers with the FA.
 The basic messages specified in [1] are extended to carry information
 required to achieve fast handoffs.  The PRE-REGISTRATION method
 allows both the MN and FA to initiate the layer 3 handoff and it can
 make use of L2 triggers on either the FA or MN side, depending on
 whether network-initiated or mobile-initiated handoff occurs.
 PRE-REGISTRATION supports the normal Mobile IPv4 model [1] and
 optionally also the Regional Registration model [11].  There can be
 advantages in implementing [11] together with low-latency handoff
 mechanisms, in particular in cases where the Home Agent (HA) is at a
 distance (in terms of delay) from the nFA.  The time required for the
 handoff procedure to complete can be reduced by using a closer local
 HA, called Gateway Foreign Agent (GFA) in [11].  However,
 implementation of [11] is not required by PRE-REGISTRATION.  PRE-
 REGISTRATION also supports movement where a new Authentication,
 Authorization, and Accounting (AAA) transaction must occur to
 authenticate the MN with a new domain.

El Malki, Ed. Experimental [Page 10] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

3.1. Operation

 The PRE-REGISTRATION handoff mechanism is summarized in Figure 1.
                          +---------+
                          | HA (GFA)|<---------+
                          +---------+          | 4.  (Reg)RegReq
                                               | 5.  (Reg)RegReply
                                               v
                 +-----+    1a.  PrRtSol    +-----+
                 |     | -----------------> | nFA |
                 | oFA |    1b.  PrRtAdv    |     |
                 +-----+ <----------------- +-----+
                  ^   |                       ^
    (2a.  PrRtSol)|   | 2b                    |
                  |   | PrRtAdv               | 3.  (Reg)RegReq
                  |   |                       |
                  |   v   --------------------+
                 +-----+ /
                 | MN  |
                 +-----+    - - - - - ->
                              Movement
          Figure 1 - PRE-REGISTRATION Handoff Protocol
 The following steps provide more detail on the protocol:
    1. Message 1a is a Proxy Router (Agent) Solicitation (PrRtSol)
       from oFA to nFA.  It is a Mobile IP agent solicitation
       containing an identifier for the nFA (i.e., IP address or L2
       address) in a Generalized Link Layer and IP Address Extension
       (see Section 9).  When message 1a is received by the nFA
       containing nFA's correct identifier in the LLA extension, the
       nFA MUST return the Proxy Router Advertisement (Agent
       Advertisement) in message 1b.  Message 1b is simply nFA's Agent
       Advertisement containing the nFA layer 2 address in a
       Generalized Link Layer and IP Address (LLA) Extension (see
       Section 9.3).  Messages 1a and 1b SHOULD occur in advance of
       the PRE-REGISTRATION handoff in order not to delay the handoff.
       For this to occur, oFA SHOULD solicit and cache advertisements
       from neighboring nFAs using messages 1a and 1b, thus decoupling
       the timing of this exchange from the rest of the PRE-
       REGISTRATION handoff.  When the L3 handoff is initiated by a
       target L2 trigger at nFA (L2-TT), message 1b equals message 2b
       and is sent unsolicited directly to MN (tunneled by nFA to MN
       through oFA) instead of being relayed by oFA.

El Malki, Ed. Experimental [Page 11] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

    2. Message 2a is a Proxy Router Solicitation (PrRtSol) from MN to
       oFA.  It is different from a normal Router (Agent) Solicitation
       since it is soliciting an advertisement from a router different
       from the one receiving this message.  It is a Mobile IP Agent
       Solicitation containing an identifier for the nFA (i.e., IP
       address or L2 address) in a Generalized Link Layer and IP
       Address Extension (see Section 9).  The presence of message 2a
       indicates that the handoff is mobile-initiated and its absence
       means that the handoff is network-initiated.  In mobile-
       initiated handoff, message 2a occurs if there is an L2 trigger
       in the MN to solicit for a Proxy Router Advertisement
       (PrRtAdv).  When message 2a is received by the oFA, it MUST
       return the Proxy Router Advertisement (Agent Advertisement) in
       message 2b.  This is simply nFA's Agent Advertisement
       containing the nFA layer 2 address in a Generalized Link Layer
       and IP Address (LLA) Extension (see Section 9.3).  In network-
       initiated source-triggered handoff, the L2 trigger occurs at
       oFA, and oFA MUST relay the Agent Advertisement in message 2b
       without the need for the MN to solicit.  Note that it is also
       possible for nFA to advertise directly to the MN in the
       network-initiated target-triggered case (see Section 3.2).
    3. The MN performs movement detection upon receipt of a solicited
       or unsolicited Agent Advertisement and, if required, it sends a
       Registration Request (RegReq) message [1] in message 3 to nFA.
       When a local Gateway Foreign Agent (GFA) is present, this
       message can optionally be a Regional Registration Request
       (RegRegReq) [11].  Message 3 is routed through oFA since the MN
       is not directly connected to nFA prior to the L2 handoff.
    4. Messages 4 and 5 complete the standard Mobile IPv4 Registration
       [1] or optionally Regional Registration [11] initiated with
       message 3.  The Registration Request MUST contain the MN's
       layer 2 address in a Generalized Link Layer and IP Address
       Extension (see Sections 3.7 and 9).  This identifier may be a
       plain Ethernet address or an identifier specific to the
       wireless technology.  If the MN is not already connected to
       nFA, the Registration Reply in message 5 MUST be buffered by
       the nFA and unicast to the MN on-link as soon as the MN
       connects to nFA (i.e., L2-LU trigger at nFA, which can be
       implemented by the MN sending an Agent Solicitation or
       optionally using special layer 2 techniques, which are outside
       the scope of this document).  This is necessary since the MN
       may have to detach from oFA, due to the wireless L2 connection,
       before it receives the reply.  The MN's L2 address is obtained
       using the extensions in Section 9, as described in Section 3.7.
       Figures 2 and 3 illustrate this procedure.

El Malki, Ed. Experimental [Page 12] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

    5. If the registration is successful, packets for the MN are
       tunneled from the HA (or GFA) to the nFA and then to the MN.
 PRE-REGISTRATION is not dependent on [11].  However, if the HA is at
 a distance (in terms of delay) from the nFA, the use of a local GFA
 may reduce the time required for the handoff procedure to complete.
 The time at which the L2 trigger is received by the oFA or MN,
 thereby triggering the PRE-REGISTRATION handoff, compared to the time
 at which the actual L2 handoff occurs is important for the optimal
 performance of the low-latency handoff.  That is, in the optimal
 case, the L2 trigger will be received and the four messaging steps of
 PRE-REGISTRATION described above will be completed (i.e., up to when
 the Registration Request is processed by HA or GFA) before the MN
 moves.  Optimally, the Registration Reply and the first packet
 redirected by the HA (or GFA) to nFA will reach the MN at the moment
 in which the MN's L2 link to nFA is fully established.  The MN would
 therefore not suffer any disruption due to the L3 handoff.  This
 cannot always be guaranteed unless particular implementation
 techniques are used.  To alleviate a part of this timing problem, the
 MN MAY set the S bit [1] in low-latency Registration Requests sent by
 the MN.  This allows the MN to receive packets at both oFA and nFA
 during the short layer 2 handoff time.  Other techniques may be
 required, such as L2 techniques or buffering, but these are outside
 the scope of this document.  In addition, further handoff smoothing
 considerations may be required to prevent the loss of packets in-
 flight between HA (or GFA) and oFA while the MN performs a PRE-
 REGISTRATION handoff.  These are also outside the scope of this
 document.
 Figures 2, 3, and 4 contain message timing diagrams for the network-
 initiated and mobile-initiated PRE-REGISTRATION handoff procedures.

3.2. Network-Initiated Handoff

 As described in Table 1, a PRE-REGISTRATION handoff can be initiated
 at oFA by a source trigger or at nFA by a target trigger.  Figures 2
 and 3 contain message timing diagrams for PRE-REGISTRATION network-
 initiated handoff for source and target triggers.
 A source-triggered, network-initiated handoff occurs when an L2
 trigger is received at the oFA informing it of a certain MN's
 upcoming movement from oFA to nFA.  The L2 trigger contains
 information including the MN's identifier (i.e., the IPv4 address
 itself or an identifier that can be resolved to the IPv4 address) and
 the nFA's identifier.  An identifier may be an IPv4 address or
 something specific to the wireless technology (e.g., Base Station or
 Access Point Identifier).  A target-triggered, network-initiated

El Malki, Ed. Experimental [Page 13] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 handoff occurs when an L2 trigger is received at the nFA informing it
 of a certain MN's upcoming movement from oFA.  This type of trigger
 is also shown in Table 1 and contains information including the MN's
 and the oFA's identifier.
 MN                    oFA                 nFA                 HA/GFA
  |                     |<~~~~~~ L2-Source  |                    |
  |                     |           Trigger |                    |
  |<--------------------|                   |                    |
  |     PrRtAdv         |                   |                    |
  |                     |                   |                    |
  |---------------------------------------->|                    |
  |   RegReq or         |                   |                    |
  |   RegRegReq (routed via oFA)            |------------------->|
  |                                         | RegReq or RegRegReq|
  |                                         |                    |
  |                          Buffered ~~~~~>|<-------------------|
  |---------------------------------------->|    (Reg)RegReply   |
  | Agent Solicitation                      |                    |
  | (sent when MN connects to nFA)          |                    |
  |                                         |                    |
  |<----------------------------------------|                    |
  |              (Reg)RegReply              |                    |
  |              (sent when nFA receives Solicitation or L2-LU)  |
       Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram
                   (Network-Initiated, Source Trigger)
 In a source-triggered handoff, when oFA receives the trigger (L2-ST),
 it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to
 the MN.  The PrRtAdv is nFA's Agent Advertisement [1] with one of the
 link-layer extensions described in Section 9.  The use of the
 contents of this extension is described in Section 3.7.  Messages 1a
 and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger is
 received (see Section 3.4.1).  Message 2a is not used.

El Malki, Ed. Experimental [Page 14] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 MN                    oFA                 nFA                 HA/GFA
  |                     | L2-Target~~~~~~~~>|                    |
  |                     |    Trigger        |                    |
  |                     |...................|                    |
  |<--------------------------------------- |                    |
  |     (PrRtAdv)       |...................|                    |
  |                     | Tunneled Agent Advertisement           |
  |                     |                   |                    |
  |---------------------------------------->|                    |
  |   RegReq. or        |                   |                    |
  |   RegRegReq (routed via oFA)            |------------------->|
  |                                         | RegReq or RegRegReq|
  |                                         |                    |
  |                          Buffered ~~~~~>|<-------------------|
  |---------------------------------------->|    (Reg)RegReply   |
  | Agent Solicitation                      |                    |
  | (sent when MN connects to nFA)          |                    |
  |                                         |                    |
  |<----------------------------------------|                    |
  |              (Reg)RegReply              |                    |
  |              (sent when nFA receives Solicitation or L2-LU)  |
       Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram
                   (Network-Initiated, Target Trigger)
 In a target-triggered handoff, when nFA receives the trigger (L2-TT),
 it MUST tunnel an Agent Advertisement to the MN through oFA to
 initiate the L3 handoff.  The inner advertisement is unicast by nFA
 to MN, thus nFA treats the target trigger as a Router (Agent)
 Solicitation.  This advertisement is tunneled to oFA, which functions
 as a normal router, decapsulating the advertisement and forwarding it
 to the MN.  This message MUST be authenticated to prevent attacks
 (see Section 3.4.2).

3.3. Mobile-Initiated Handoff

 As shown in Table 1, a mobile-initiated handoff occurs when an L2
 trigger is received at the MN informing that it will shortly move to
 nFA.  The L2 trigger contains information such as the nFA's
 identifier (i.e., nFA's IPv4 address or an identifier that can be
 resolved to the nFA's IPv4 address).  As an example, a Wireless LAN
 MN may perform a scan to obtain the Base Station Identifier (BSSID)
 of the access point that is a potential handoff target (i.e., its
 signal is becoming stronger).  The message timing diagram is shown in
 Figure 4.

El Malki, Ed. Experimental [Page 15] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 MN                    oFA                 nFA               HA/GFA
  |<~~~~~ L2-Trigger    |                   |                    |
  |                     |                   |                    |
  |-------------------->|                   |                    |
  |      PrRtSol        |                   |                    |
  |                     |                   |                    |
  |<--------------------|                   |                    |
  |      PrRtAdv        |                   |                    |
  |                     |                   |                    |
  |---------------------------------------->|                    |
  |   RegReq or         |                   |                    |
  |   RegRegReq (routed via oFA)            |------------------->|
  |                                         | RegReq or RegRegReq|
  |                                         |                    |
  |                          Buffered ~~~~~>|<-------------------|
  |---------------------------------------->|    (Reg)RegReply   |
  | Agent Solicitation                      |                    |
  | (sent when MN connects to nFA)          |                    |
  |                                         |                    |
  |<----------------------------------------|                    |
  |              (Reg)RegReply              |                    |
  |              (sent when nFA receives Solicitation or L2-LU)  |
       Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram
                           (Mobile-Initiated)
 As a consequence of the L2 trigger (L2-MT), the MN MUST send message
 1a, the Proxy Router Solicitation (PrRtSol).  This message is a
 unicast Agent Solicitation to oFA for a Proxy Router Advertisement
 (PrRtAdv).  This solicitation MUST have a TTL=1 as in [1].  The Proxy
 Router Advertisement Solicitation unicast to oFA is an Agent
 Solicitation with a special extension.  The solicitation MUST have an
 extension containing an FA identifier (i.e., IPv4 address or L2
 address contained in an LLA extension, see Section 9) because the MN
 is soliciting another specific FA's advertisement from the oFA.  This
 specific FA will be the MN's nFA.  The identifier is the IPv4 address
 of the nFA or another identifier that can be used by the oFA to
 resolve to nFA's IPv4 address.  If the identifier is not an IPv4
 address, it MAY be specific to the underlying wireless technology,
 for example, an access point or Base Station Identifier (e.g., WLAN
 BSSID) that can be mapped by oFA to the nFA IPv4 address as described
 in Section 3.4.1.  The extension containing the identifier is a sub-
 type of the Generalized Link Layer Address Extension described in
 Section 9.
 Two extension sub-types have been defined to contain the nFA's IPv4
 address and an access point identifier.  They are called the
 Solicited Agent IPv4 Address Extension and the Access Point

El Malki, Ed. Experimental [Page 16] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 Identifier Extension, and are described in Sections 9.5 and 9.6.
 These two extensions SHOULD NOT be present in the same PrRtSol
 message.
 When oFA receives the PrRtSol message, it MUST reply to the MN with
 the Proxy Router Advertisement (PrRtAdv, message 2b).  The PrRtAdv is
 simply the Agent Advertisement for the requested nFA, proxied by oFA.
 In order to expedite the handoff, the actual nFA advertisement SHOULD
 be cached by the oFA following a previous exchange with nFA, shown in
 messages 1a and 1b, as specified in Section 3.5.  The PrRtAdv message
 MUST contain the nFA's L2 address (using the LLA extension in Section
 9.3).  This is further described in Section 3.7.

3.4. Obtaining and Proxying nFA Advertisements

 Since L2 triggers are involved in initiating PRE-REGISTRATION
 handoff, the trigger timing SHOULD be arranged such that a full L3
 PRE-REGISTRATION handoff can complete before the L2 handoff process
 completes.  That is, the L2 handoff should be completed after the
 MN's registration with the nFA is performed (message 3 in Figure 1).
 The registration MAY be transmitted in more than one copy (default
 recommendation: 2) to reduce the probability that it is lost due to
 errors on the wireless link.  This would not apply to reliable
 wireless links where retransmissions are performed at layer 2 in case
 of error to guarantee packet delivery.
 A PRE-REGISTRATION handoff in this case requires the MN to receive an
 Agent Advertisement from the nFA through the old wireless access
 point.  How to achieve this is discussed in the following
 subsections.  Messages exchanged between FAs MUST be authenticated to
 prevent impersonation attacks.  The minimal requirement is that all
 FAs involved in low-latency handoffs MUST support manual pre-
 configuration of security associations with other neighboring FAs,
 involving shared keys and the default algorithms of [1] (see the
 Security Considerations of this document).

3.4.1. Inter-FA Solicitation

 This applies to the network-initiated source-triggered (L2-ST) and
 mobile-initiated (L2-MT) cases only.  Inter-FA solicitation assumes
 that oFA has access to the IPv4 address of the nFA.  The IPv4 address
 of nFA is obtained by means of an L2 trigger at oFA in the network-
 initiated case (see Section 3.2) or by means of the extension to the
 Proxy Router Solicitation (PrRtSol) from the MN in the mobile-
 initiated case (see Section 3.3).  This extension to the PrRtSol may
 contain an IPv4 address or another identifier, for example, an
 identifier of a Wireless Base Station such as the WLAN BSSID.  In the
 latter case, the oFA must implement a mechanism to resolve the Base

El Malki, Ed. Experimental [Page 17] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 Station Identifier to an IPv4 address.  The default mechanism is to
 use a configured table of neighboring Base Station Identifiers (e.g.,
 BSSID) to FA IPv4 address mappings in each FA.  Other automated
 discovery mechanisms may also be used.
 If oFA does not cache advertisements (see Section 3.5) once it
 receives an L2 trigger and obtains the address of the nFA for a
 specific MN, it MUST send a unicast Agent Solicitation (PrRtSol) to
 nFA.  The nFA replies to the oFA by unicasting an Agent Advertisement
 with appropriate extensions (PrRtAdv).  This method removes the TTL
 limitation of [1] for Mobile IPv4 messages (i.e., TTL=1 is not
 applicable here).  The TTL limitation cannot be applied since oFA and
 nFA may be more than one hop away and since it is unnecessary for a
 secured unicast message.  The ICMP solicitations and advertisements
 MUST be authenticated and integrity protected.  These messages MUST
 be protected using Encapsulating Security Payload (ESP) [10] to
 prevent attacks (see the Security Considerations section of this
 document).  An FA MUST NOT accept ICMP solicitations or
 advertisements from sources that are not authenticated.
 As a practical matter, oFA SHOULD pre-solicit and cache
 advertisements from known neighboring FAs (see section 3.5) to avoid
 performing the solicitation during an actual handoff procedure.

3.4.2. Tunneled nFA Advertisements

 This applies to the network-initiated target-triggered (L2-TT) case
 only.  Following a target trigger (L2-TT) the nFA MUST send a
 tunneled Agent Advertisement to the MN through oFA.  Tunneling nFA
 advertisements assumes that the nFA is aware of the IPv4 address for
 oFA and the MN.  These IPv4 addresses are obtained by means of the FA
 and MN identifiers contained in an L2 trigger received at nFA in the
 network-initiated case (see Section 3.2).  However, in [1] the TTL
 must be 1 on Agent Advertisements from the nFA.  Therefore, tunneling
 advertisements is applicable if the TTL limitation of [1] is relaxed.
 For this purpose, a pre-established security association between oFA
 and nFA MUST be in place to authenticate this message and relax the
 TTL limitation.  If the implementation requires this, a tunnel SHOULD
 be configured when the inter-FA security association is established.
 The tunneled ICMP advertisement MUST be secured using tunnel mode ESP
 [10] between nFA and oFA.  An FA MUST NOT accept tunneled ICMP
 packets destined to it from sources that are not authenticated.

El Malki, Ed. Experimental [Page 18] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

3.5. Caching Router Advertisements

 In the mobile-initiated (L2-MT) case and the network-initiated
 source-triggered (L2-ST) case, the message exchange 1 in Figure 1
 could impose an additional latency on the L3 handoff process if done
 as part of the handoff procedure.  In order to remove this source of
 latency, the inter-FA Router (Agent) Solicitation and Advertisement
 exchange SHOULD be performed in advance of handoff.  A process SHOULD
 be in place at the oFA to solicit its neighboring nFAs at a
 predefined time interval (MIN_SOLICITATION_INTERVAL).  This interval
 SHOULD NOT be set too small to avoid unnecessary consumption of
 network bandwidth and nFA processing resources.  The minimum value of
 MIN_SOLICITATION_INTERVAL is 1 second.  If the FA Challenge/Response
 mechanism in [7] is used, then the MIN_SOLICITATION_INTERVAL MUST be
 set to a value smaller then the window of time in which a challenge
 remains valid so that the nFA challenge does not expire before the MN
 issues the Registration Request.  Therefore, the recommended default
 value for the MIN_SOLICITATION_INTERVAL in oFA is (0.5 * nFA's
 CHALLENGE_WINDOW * nFA's Agent Advertisement interval).  The
 CHALLENGE_WINDOW and Agent Advertisement interval are defined in [7]
 and [1] respectively.  The minimum requirement is that the
 MIN_SOLICITATION_INTERVAL MUST be manually configurable, while
 possible autoconfiguration mechanisms are outside the scope of this
 document.  To allow advertisement caching in certain implementations
 and in cases where the nFA advertisement interval is very small, it
 MAY be necessary for the implementation in nFA to allow different
 CHALLENGE_WINDOW and Agent Advertisement interval settings for its
 nFA-oFA interface.
 The oFA SHOULD cache the most recent advertisement from its
 neighboring nFAs.  This advertisement MUST be sent to the MN in
 message 2b with a TTL=1.  The oFA SHOULD also have a mechanism in
 place to create a list of neighboring nFAs.  The minimum requirement
 for each FA is that it SHOULD allow manual configuration of a list of
 nFA addresses that an MN could possibly perform an L3 handoff to.
 The FA addresses in this list will depend on deployment and radio
 coverage.  It is also possible to specify another protocol to achieve
 nFA discovery, but this is outside the scope of this document.

3.6. Movement Detection, MN, and FA Considerations

 When the MN receives an Agent Advertisement with a Mobility Agent
 extension, it performs actions according to the following movement
 detection mechanism: the MN SHOULD be "Eager" to perform new
 bindings.  This means that the MN SHOULD perform registrations with
 any new FA from which it receives an advertisement (i.e., MN is
 Eager), as long as there are no locally-defined policies in the MN
 that discourage the use of the discovered FA.  For example, the MN

El Malki, Ed. Experimental [Page 19] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 could have a policy based on the cost of service.  The method by
 which the MN determines whether the FA is a new FA is described in
 [1] and MAY use an FA-NAI extension [11].  By being "Eager" to
 perform registrations, the MN reduces latency times.
 The MN also needs to change its default router from oFA to nFA.  The
 MN MUST change its default router to nFA as soon as the PRE-
 REGISTRATION procedure has completed (i.e., Registration Reply is
 received by MN) as described in [1].
 Overall, the MN behaves as described in [1] with the following
 changes: the specified movement detection mechanism mentioned above
 and the ability to use the L2-MT to initiate an Agent Solicitation
 with a special extension (PrRtSol).  Also, when the MN receives an
 L2-LU trigger (i.e., new interface or link is up), it MUST
 immediately send an Agent Solicitation [1] on that interface.  An nFA
 that receives an Agent Solicitation [1] will use it as an L2-LU
 trigger event, and according to [1] it will record the MN's
 IPv4/layer 2 addresses (i.e., the Address Resolution Protocol (ARP)
 entry).  At that point, the nFA starts delivering data to the MN
 including the previously buffered Registration Reply.  The nFA MAY
 also use other L2 mechanisms to detect earlier that the MN has
 attached to the new link and to start forwarding data to it.  The MN
 SHOULD NOT attempt to retransmit a low-latency Registration Request
 (i.e., Registration Request containing an LLA extension described in
 Section 9.) when it does not receive the Registration Reply.
 When moving from a PRE-REGISTRATION network to a normal Mobile IPv4
 [1] network, the MN will no longer receive PrRtAdv messages (i.e.,
 Agent Advertisements with the LLA extension).  If the MN still
 receives L2-MTs, it will attempt to send PrRtSol messages.  The
 normal FA will reply with a normal Agent Advertisement [1].  If the
 MN does not receive a PrRtAdv in reply to its PrRtSol, it MAY
 retransmit the PrRtSol message once after PRE_SOL_INTERVAL seconds
 and then for another PRE_SOL_ATTEMPTS times with exponential backoff
 of the transmission interval.  If a PrRtAdv is not received within
 PRE_SOL_INTERVAL seconds after the last PrRtSol attempt, the MN MUST
 stop sending PrRtSol messages until after a registration with a new
 FA is performed.  The default value for PRE_SOL_ATTEMPTS is 2, and
 for PRE_SOL_INTERVAL, it is 1 second.  It should be noted that the
 performance of the movement detection mechanism mandated in PRE-
 REGISTRATION (i.e., eager to register) may have sub-optimal behaviour
 in a standard Mobile IPv4 [1] network.  Therefore, standard movement
 detection mechanisms [1] should be used in plain Mobile IPv4
 networks.  Instead, when the MN moves from a normal Mobile IPv4 [1]
 network to a PRE-REGISTRATION network, the MN starts receiving L2-MT
 triggers or PrRtAdv messages.  When the MN receives L2-MT triggers or
 PrRtAdv messages, it SHOULD follow the PRE-REGISTRATION procedure.

El Malki, Ed. Experimental [Page 20] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 If there is uncertainty as to which mode to choose (e.g., MN receives
 messages from both PRE-REGISTRATION and normal FAs), the MN decides
 based on its registration status with the current FA.  If the MN
 already has a valid normal Mobile IPv4 Registration [1] with the
 advertising FA, it SHOULD give priority to the PRE-REGISTRATION
 procedure.  Otherwise it SHOULD give priority to normal Mobile IPv4
 [1] Registration procedure.  The MN SHOULD NOT attempt to perform
 PRE-REGISTRATION and standard Mobile IPv4 [1] Registrations in
 parallel.

3.7. L2 Address Considerations

 Some special considerations should be taken with respect to the
 wireless system on which this handoff method is being implemented.
 Consider an Ethernet-like system such as IEEE 802.11, for example.
 In PRE-REGISTRATION, the MN is registering with an FA (nFA) that is
 not its current first-hop router; therefore, the L2 address of the
 Ethernet frame containing the MN's Registration Request reaching the
 nFA is not the MN's address.  Therefore, the FA MUST NOT use the
 Ethernet address of the incoming Registration Request as the MN's L2
 address as specified in [1].  This applies to the cases where the
 wireless access points are bridges or routers and independently of
 whether the FA is implemented in the wireless access points
 themselves.  In this case, the MN's Registration Request (or Regional
 Registration Request) MUST use an L2 address extension to the
 registration message.  Such an L2 address is either the same L2
 address that remains constant as the MN moves, or it is the MN's L2
 address at nFA.  To communicate its L2 address, the MN includes a
 Generalized Link Layer and IP Address Extension (see Section 9) with
 its Registration Request (or Regional Registration Request) message.
 If this extension is present, the FA MUST use the L2 address
 contained in the extension to communicate with the MN.  If a
 particular wireless L2 technology has defined a special interface to
 the wireless network that allows the FA to resolve the mapping
 between an MN's IPv4 address and its L2 address without the need to
 use the extension, the L2 address extension contents may be
 discarded.  For the same reasons above, the MN MUST NOT use the
 source L2 address of the Agent Advertisement message (PrRtAdv) as its
 default router's L2 address.  Therefore, the nFA MUST include a
 Generalized Link Layer and IP Address Extension (see Section 9.3)
 with its Agent Advertisement (PrRtAdv) messages.

3.8. Applicability of PRE-REGISTRATION Handoff

 The PRE-REGISTRATION handoff method is applicable to scenarios where
 a period of service disruption due to layer 3 is not acceptable, for
 example, when performing real-time communications, and therefore
 where an anticipation of the layer 3 handoff is required.  Security

El Malki, Ed. Experimental [Page 21] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 for the PRE-REGISTRATION handoff method is based on the same security
 model as [1] including the use of AAA.  A prerequisite for PRE-
 REGISTRATION is that the FA or MN is able to obtain an L2 trigger
 informing it of a pending L2 handoff procedure.  The target of the L2
 handoff is another access point or radio network that is in the
 coverage area of a new FA.  The L2 trigger information may be in the
 form of identifiers that need to be resolved to IPv4 addresses using
 methods that may be specific to the wireless network and are not
 considered here.  If, for example, the oFA or MN determines that the
 IPv4 address of the new FA matches oFA's address, then the PRE-
 REGISTRATION handoff SHOULD NOT be initiated.
 The L2 trigger must allow enough time for the PRE-REGISTRATION
 handoff procedure to be performed.  In many wireless L2 technologies,
 the L2 handoff procedure involves a number of message exchanges
 before the effective L2 handoff is performed.  For such technologies,
 PRE-REGISTRATION handoff can be initiated at the beginning of the L2
 handoff procedure and completed before the L2 handoff is completed.
 It is efficient to engineer the network such that this succession of
 events is ensured.
 The PRE-REGISTRATION handoff method is applicable in the following
 cases:
  1. when the MN has locally defined policies that determine a

preference for one access over another, for example, due to

      service cost within the same or different technology, and
      therefore where it is necessary to allow the MN to select the
      appropriate FA with which to connect.
  1. when L2 security between the MN and the FA is either not present

or cannot be relied upon to provide adequate security.

  1. when the trigger to initiate the handoff is received at the MN.
 In the first case, it is necessary to involve eventual local MN
 policies in the movement detection procedure as described in Section
 3.6.

El Malki, Ed. Experimental [Page 22] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

4. The POST-REGISTRATION Handoff Method

 The POST-REGISTRATION handoff method uses bidirectional edge tunnels
 (BETs) or unidirectional tunnels to perform low-latency change in the
 L2 point of attachment for the MN without requiring any involvement
 by the MN.  Figure 5 illustrates the basic POST-REGISTRATION handoff.
                    +------+
                    |  CN  |
                    +------+
                       |
                      ...
                       |
                    +------+   BET    +------+
                    | aFA  |==========| nFA  |
                    +------+          +------+
                                          | wireless link
                                          |
                          movement    +------+
                         --------->   |  MN  |
                                      +------+
              Figure 5 - POST-REGISTRATION Concept
 Following a successful Mobile IPv4 Registration between MN and oFA,
 the oFA becomes the mobility anchor point for the MN, called the
 anchor FA (aFA).  When the MN moves from oFA to nFA, rather than
 performing signaling over the wireless link to register with the nFA,
 the MN can defer the L3 handoff and continue to use its aFA (i.e.,
 oFA in this case).  If the MN moves to a third FA before registering
 with the nFA, in certain cases described later, the third FA signals
 aFA to move the wireless link end of the BET from nFA to it.  The
 network end of the BET remains anchored at aFA until the MN performs
 the Mobile IPv4 Registration.
 Messages between oFA/aFA and nFA MUST be authenticated.  The minimal
 requirement is that all FAs involved in low-latency handoffs MUST
 support manual pre-configuration of security associations with other
 neighboring FAs, involving shared keys and the default algorithms of
 [1].  POST-REGISTRATION FAs MUST implement the inter-FA
 authentication extension (FA-FA authentication extension) specified
 in [11] and MAY additionally use other security mechanisms.

El Malki, Ed. Experimental [Page 23] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

4.1. Two-Party Handoff

 Two-party handoff occurs when the MN moves from oFA to nFA.
 Normally, this movement would result in a new Mobile IPv4
 Registration at nFA.  However, in POST-REGISTRATION, the MN and nFA
 MAY delay this but maintain connectivity using the BET (or
 alternatively unidirectional tunnel) between oFA and nFA.  The
 protocol is shown in Figure 6.
       1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT
                       | oFA  |<-------->| nFA  |
           4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU
                          ^                  ^
                old L2    |                  |     new L2
                          +-------+    +-----+
                                  |    |
                                  |    |
                                  V    V
                                 +------+  movement
                  4c) L2-LU ---> |  MN  | --------->
                                 +------+
          Figure 6 - Two-Party Handoff (POST-REGISTRATION)
 The following describes the progress of a two-party handoff.  The
 numbered items refer to steps in Figure 6.  The source-triggered
 HRqst/HRply message for tunnel creation, the target-triggered
 HRqst/HRply message for tunnel creation, and the HRqst/HRply to
 extend or terminate a BET (or unidirectional tunnel) are identified
 using the suffixes (s), (t), and (r), respectively.
    1) Either the oFA or nFA receives an L2 trigger informing it that
       a certain MN is about to move from oFA to nFA.  The two cases
       are:
       a) The L2 trigger is a source trigger (L2-ST) at oFA.  The
          trigger contains the MN's L2 address and an identifier for
          the nFA (the IPv4 address itself or an L2 address that can
          be resolved to the IPv4 address of the nFA).
       b) The L2 trigger is a target trigger (L2-TT) at nFA.  The
          trigger contains the MN's L2 address and an identifier for
          the oFA (the IPv4 address itself or an L2 address that can
          be resolved to the IPv4 address of the oFA).
    2) The FA receiving the trigger sends a Handoff Request (HRqst) to
       the other FA.  There are two cases:

El Malki, Ed. Experimental [Page 24] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

       a) If oFA is sending the HRqst, the H bit is set and the N bit
          is unset, indicating it is an HRqst(s).  The HRqst(s)
          contains the lifetime of the tunnel the oFA is willing to
          support, the MN's IPv4 home address, the MN's HA address,
          and an LLA option with the MN's L2 address.  If the lifetime
          is zero and the T bit is not set, the oFA is not willing to
          tunnel any packets for MN.  A positive lifetime and a set T
          bit indicate that the oFA is willing to tunnel for the
          indicated time.  Section 4.5 describes the HRqst(s) and
          Section 9 describes the LLA option.
       b) If nFA is sending the HRqst, the N bit is set and the H bit
          is unset, indicating that it is an HRqst(t).  If the T bit
          is set, nFA has requested a reverse tunnel and the HRqst(t)
          contains the lifetime of the tunnel the nFA is requesting.
          The HRqst(t) also contains an LLA option with the MN's L2
          address.  The MN's IPv4 home address and HA address are not
          sent, unless they are discovered by some means outside the
          scope of this document (for example, as part of the L2-TT).
          Section 4.5 describes the HRqst(t).
    3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the
       other FA.  There are two cases:
       a) If oFA is sending the HRply, the N bit is set and the H and
          R bits are unset, indicating that the reply is in response
          to a HRqst(t), i.e., it is an HRply(t).  If the T bit is
          set, the HRply(t) contains the tunnel lifetime the oFA is
          willing to provide; otherwise, the tunnel lifetime is set to
          zero indicating that the oFA is not willing to provide
          tunnel service.  If both HRply(t) and HRqst(t) have the T
          bit set and non-zero lifetime, a BET is established.  The
          HRply(t) also contains the MN's home subnet IPv4 address,
          the MN's HA address, and an LLA option containing the MN's
          L2 address.  Section 4.6 describes the HRply(t).
       b) If nFA sends the HRply, the H bit is set and the N and R
          bits are unset, indicating that this is a response to
          HRqst(s), i.e., it is an HRply(s).  If the T bit is set, the
          nFA indicates that it requests a reverse tunnel, and the
          lifetime field is set with the requested tunnel lifetime.
          The T bit can be set in HRply only if the oFA had set the T
          bit in the corresponding HRqst or if the nFA is required to
          reverse tunnel incoming packets to oFA because ingress
          filtering is enabled on its network.  This establishes a
          BET.  The tunnel lifetime requested by the nFA must be less
          than or equal to the tunnel lifetime offered by oFA in the
          HRqst(s).  Section 4.6 describes the HRply(s).

El Malki, Ed. Experimental [Page 25] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

    4) The point during the L2 handoff in which the MN is no longer
       connected on a given link is signaled by an L2-LD trigger at
       oFA and MN.  Completion of L2 handoff is signaled by an L2-LU
       trigger at nFA and MN.  The trigger is handled as follows:
       a) When oFA receives the L2-LD trigger, it begins forwarding
          MN-bound packets through the forward tunnel to nFA.
       b) When the nFA receives the L2-LU trigger, it begins
          delivering packets tunneled from oFA to MN and forwards
          outbound packets from MN using normal routing mechanisms or
          through a reverse tunnel to oFA or HA.  The nFA at this
          point may not yet be the default router of the MN (see
          Section 4.4); therefore, to receive all outbound packets
          from the MN the nFA must send a unicast proxy ARP message
          (used in [1]) to the MN upon receiving an L2-LU trigger.
          This proxy ARP message is an ARP Reply [5] sent by the nFA
          on behalf of oFA, therefore supplying the nFA link-layer
          address in the Sender Hardware Address field and the oFA
          IPv4 address in the Target Protocol Address field.
       c) When the MN receives the L2-LU, it MAY initiate the Mobile
          IPv4 Registration process by soliciting an Agent
          Advertisement as described in [1].  If the registration is
          successful, the nFA takes over the role of anchor FA (aFA)
          from the oFA.  Alternatively, the MN MAY defer the Mobile
          IPv4 Registration (see Section 4.4).
    5) The oFA becomes an aFA if the MN moves to a third FA before
       having performed a Mobile IPv4 Registration with nFA.
    6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a
       ping-pong situation arise, the oFA may be able to determine
       this case through the trigger mechanism (i.e., FA sees
       successive L2-ST/L2-TT followed by L2-LD and then L2-LU).  The
       FA that originated the HRqst can in this case cancel the tunnel
       by sending an HRqst(r) to the other FA with lifetime zero.  It
       will then simply continue delivering packets to MN exactly as
       if no handoff had been pending.  Section 4.5 describes the
       HRqst(r).
 If the oFA sets the B bit in HRqst/HRply and the nFA has not
 requested a reverse tunnel by setting the T bit, the nFA SHOULD
 tunnel outgoing packets from the MN to the HA because the MN has
 requested this service from the oFA.  The nFA SHOULD offer this
 service only if no security between the nFA and the MN's HA is
 required, or if there is an existing nFA-HA security association.

El Malki, Ed. Experimental [Page 26] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 The actual timing of BET or unidirectional tunnel placement depends
 on the available L2 triggers.  The forward tunnel from oFA to nFA is
 constructed using one of the tunneling procedures described in [1]
 for the HA to FA tunnel with the difference that the ends of the
 tunnel are at the oFA and nFA, respectively.  The reverse tunnel from
 nFA to oFA is constructed as described in [3] with the difference
 that the network end of the tunnel is at the oFA instead of the HA.
 If both forward and reverse tunnels are established, then a BET has
 been established.  With optimal L2 trigger information, as described
 above, the FAs can set up the BET immediately when the L2 handoff is
 initiated, start tunneling MN-bound data when the link to the MN goes
 down, and the nFA can use the link-up trigger to start delivering
 packets.  In the absence of optimal L2 trigger information, the HRply
 can act as the trigger to start tunneling MN-bound data, but in this
 case, the period of packet delivery disruption to the MN could still
 be present and additional measures may be required to provide
 uninterrupted service.  Particular implementation and deployment
 scenarios could require techniques to smooth the handoff by providing
 a means to convey packets arriving during the L2 handoff.  The exact
 techniques are outside the scope of this document.
 Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and
 target trigger (L2-TT) two-party handoffs, respectively.
            MN                    nFA                 oFA
             |                     |                   |
             |                     |     HRqst(s)      |<~~~ L2-ST
             |                     |<------------------|
             |                     |     HRply(s)      |
             |                     |------------------>|
             |                     |                   |
            --------------------------------------------<~~~ L2-LD
                              L2 Handoff
            --------------------------------------------<~~~ L2-LU
             |                     |                   |
             |<------------------->|                   |
             |    MN's traffic     |                   |
          Figure 7 - Two-Party Source Trigger Handoff Timing

El Malki, Ed. Experimental [Page 27] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

            MN                    nFA                 oFA
             |                     |                   |
             |           L2-TT ~~~>|     HRqst(t)      |
             |                     |------------------>|
             |                     |     HRply(t)      |
             |                     |<------------------|
             |                     |                   |
            --------------------------------------------<~~~ L2-LD
                              L2 Handoff
            --------------------------------------------<~~~ L2-LU
             |                     |                   |
             |<------------------->|                   |
             |    MN's traffic     |                   |
          Figure 8 - Two-Party Target Trigger Handoff Timing
 Once the tunnel between aFA and the current FA is in place, it is
 torn down by one of the following events:
    1) The aFA decides to stop tunneling because the lifetime it sent
       expires and was not renewed, or the aFA or current FA decide to
       terminate tunnel service prematurely for some other reason
       (refer to Section 4.3).
    2) The MN completes the process by performing a Mobile IPv4
       Registration with the current FA.  This may be initiated by the
       FA that sends an Agent Advertisement or by the MN that solicits
       for an Agent Advertisement as in [1].
    3) The MN moves to a third FA (see Section 4.2)

4.2. Three-Party Handoff

 Three-party handoff is applicable when an MN, which has already
 established an aFA and is receiving tunneled packets through its
 current FA, moves to a new FA without performing a Mobile IPv4
 Registration.
 The need for the three-party handoff function depends on the wireless
 system in which POST-REGISTRATION is being implemented.  For radio L2
 protocols in which it is possible for the MN to move so rapidly from
 one FA to another such that a probability exists that the Mobile IPv4
 Registration with nFA will not complete before the MN moves on, HTT
 (Handoff to Third) SHOULD be implemented.  Certain wireless systems
 and implementations do not allow such fast movement between FAs and
 may force the Mobile IPv4 Registration to occur soon after L2
 handoff, in which case three-party handoff is not applicable.  If
 this three-party handoff feature is not implemented, the FA SHOULD

El Malki, Ed. Experimental [Page 28] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 send an Agent Advertisement to the MN after L2 handoff has completed
 (L2-LU at nFA) and/or the MN SHOULD solicit an Agent Advertisement
 after L2 handoff (L2-LU at MN).
                                +------+
                           +--->| aFA  |<---+
                           |    +------+    |
              4b) HRqst(r) |                | 3) HRqst(t)
                  HRply(r) |                |    HRply(t)
                           |                |
                           v    2a) HRqst   v
        1a) L2-ST ~~~> +------+     HTT  +------+ <~~~ 1b) L2-TT
                       | oFA  |<-------->| nFA  |
       4a) L2-LD ~~~>  +------+ 2b) HTT  +------+ <~~~ 5a) L2-LU
                          ^         HRply    ^
                  old L2  |                  |  new L2
                          +-------+    +-----+
                                  |    |
                                  |    |
                                  V    V
                                 +------+  movement
                  5b) L2-LU ~~~> |  MN  | --------->
                                 +------+
                     Figure 9 - Three-Party Handoff
 The L3 handoff can be deferred either because of a decision by the
 MN/FA (i.e., MN does not send Agent Solicitations and FA does not
 send Agent Advertisements), or it may result from rapid movement
 between oFA and nFA that does not allow enough time for the
 registration to complete.  This scenario is shown in Figure 9.  In
 this case, oFA must inform nFA (i.e., the third FA) to contact aFA
 about moving the radio end of the tunnel.  This is performed with the
 HTT message.  The general idea behind the three-party handoff
 procedure is that the oFA supplies nFA with the same information it
 would have obtained via an L2-TT if handoff had occurred from aFA to
 nFA; then, the nFA performs an HRqst(t)/HRply(t) sequence with aFA in
 order to move the BET to nFA.  When the L2 handoff is complete, oFA
 sends an HRqst(r) to aFA to terminate the previous BET.
 The following describes the progress of a three-party handoff.  The
 numbered items refer to steps in Figure 9.
    1) Either the oFA or nFA receives an L2 trigger informing it that
       a certain MN is about to be moved.  The two cases are:

El Malki, Ed. Experimental [Page 29] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

       a) The L2 trigger is a source trigger (L2-ST) at oFA.  The
          trigger contains the MN's L2 address and an identifier for
          the nFA (the IPv4 address itself or an L2 address that can
          be mapped to the IPv4 address of the nFA).
       b) The L2 trigger is a target trigger (L2-TT) at nFA.  The
          trigger contains the MN's L2 address and an identifier for
          the oFA (the IPv4 address itself or an L2 address that can
          be resolved to the IPv4 address of the oFA).
    2) The oFA and nFA exchange an HTT/HRply or HRqst/HTT pair.  HTT
       is indicated by setting both the H and N bits in the HRqst or
       HRply.  The HTT message MUST NOT have any tunnel flag bits set,
       because the tunnel is negotiated between the aFA and nFA, not
       oFA and nFA.  There are two cases:
       a) The L2 trigger is an L2-ST.  The oFA sends HTT to nFA
          containing the MN's home IPv4 address, the MN's HA address,
          an LLA containing the aFA's IPv4 address, and an LLA
          containing the L2 address of the MN.  This is enough
          information for nFA to perform a target-triggered handoff
          with aFA.  The nFA responds with an HRply(s).  Section 4.7
          describes the HTT.
       b) The L2 trigger is an L2-TT.  The nFA sends HRqst(t) to oFA,
          exactly as if a two-party handoff were occurring.  The oFA
          responds with HTT containing the same information as in a)
          above.  This is enough information for nFA to perform a
          target-triggered handoff with aFA.
    3) Upon receipt of the HTT, the nFA first checks its Visitor Cache
       to see whether it is already tunneling for MN.  If so, Step 6
       is performed.  If not, nFA performs a target-triggered handoff
       with aFA, exactly as in Section 4.1, exchanging an
       HRqst(t)/HRply(t) pair.  Because aFA receives no L2 trigger
       indicating when L2 handoff starts, it may start tunneling to
       nFA upon transmission of the HRply(t).
    4) Once the L2 handoff is under way and the MN gets disconnected
       at L2, aFA and oFA exchange messages canceling tunnel service
       between aFA and oFA and allowing aFA to start the tunnel with
       nFA.
       a) The point in the L2 handoff process where the MN gets
          disconnected from oFA is signaled at oFA by L2-LD.

El Malki, Ed. Experimental [Page 30] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

       b) The oFA exchanges an HRqst(r)/HRply(r) pair having lifetime
          zero with aFA.  This cancels tunnel service between oFA and
          aFA.  If aFA has not already established a tunnel to nFA, it
          must do so immediately upon receipt of the HRqst(r).  The
          aFA provides tunneling service exactly as described in
          Section 4.1, Step 4a.
    5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA
       and/or MN.  The nFA and MN handle the trigger as follows:
       a) The nFA provides packet delivery service to the MN exactly
          as described in Section 4.1, Step 4b.
       b) The MN either defers or initiates Mobile IPv4 Registration
          when it receives the L2-LU, as in Section 4.1.
    6) In the special case where nFA and aFA are the same (i.e., the
       MN is moving back to the original anchor FA), aFA recognizes
       that it is tunneling to oFA when it checks its Visitor Cache in
       Step 3.  In this case, there is no need for aFA to send the
       HRqst(t)/HRply(t) in Step 3.  Upon receipt of the L2-LU trigger
       on handoff completion, the aFA begins routing packets to MN and
       the tunnel to nFA is torn down.  The oFA still exchanges the
       HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a
       priori that aFA and nFA are the same, but they are redundant.

El Malki, Ed. Experimental [Page 31] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and
 target trigger (L2-TT) three-party handoff, respectively.
           MN               nFA            oFA              aFA
            |                |   L2-ST ~~~> |                |
            |                |              |                |
            |                |<-------------|                |
            |                |       HTT    |                |
            |                |------------->|                |
            |                |    HRply(s)  |                |
            |                |------------------------------>|
            |                |   HRqst(t)   |                |
            |                |<------------------------------|
            |                |    HRply(t)  |                |
            |                |              |                |
           ----------------------------------<~~~ L2-LD      |
                                            |--------------->|
                         L2 Handoff         |     HRqst(r)   |
                                            |                |
                                            |<---------------|
                                            |     HRply(r)   |
                                            |                |
           ----------------------------------<~~~ L2-LU      |
            | MN's traffic   |              |                |
            |<-------------->|              |                |
          Figure 10 - Three-Party Source Trigger Handoff Timing

El Malki, Ed. Experimental [Page 32] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

           MN               nFA            oFA              aFA
            |                |              |                |
            |                |<~~~ L2-TT    |                |
            |                |------------->|                |
            |                |    HRqst(t)  |                |
            |                |<-------------|                |
            |                |    HTT       |                |
            |                |------------------------------>|
            |                |   HRqst(t)   |                |
            |                |<------------------------------|
            |                |    HRply(t)  |                |
            |                |              |                |
           ----------------------------------<~~~ L2-LD      |
                                            |--------------->|
                         L2 Handoff         |     HRqst(r)   |
                                            |                |
                                            |<---------------|
                                            |     HRply(r)   |
                                            |                |
           ----------------------------------<~~~ L2-LU      |
            | MN's traffic   |              |                |
            |<-------------->|              |                |
          Figure 11 - Three-Party Target Trigger Handoff Timing
 Unlike two-party handoff, the timing of BET establishment between aFA
 and nFA cannot fully depend on the availability of L2 trigger
 information because aFA does not receive an L2 trigger signaling L2
 handoff.  The two timing extremes at which aFA can place the BET with
 nFA are:
    1) At the earliest, aFA MAY start tunneling packets using the BET
       to nFA after sending the HRply(t) to nFA in response to the
       request for target-triggered handoff.
    2) At the latest, aFA MAY start tunneling packets using the BET to
       nFA and tear down the BET with oFA when receiving the HRqst(r)
       from oFA indicating that the MN has disconnected.
 In addition, aFA MAY continue tunneling to oFA if 1) is selected,
 until the HRqst(r) is received.  In this case, the result may be
 duplicated packets at the MN because the MN will receive packets
 through oFA on the old L2 until it disconnects (L2-LD).  If 2) is
 selected, the additional latency will add to the MN's L3 service
 disruption period.  Of course, aFA can choose to place the BET
 sometime between 1) and 2) if reliable bounds are available on the
 duration of time between L2-ST/L2-TT and the MN's disconnection (L2-
 LD).  The exact selection of when to establish the BET is likely to

El Malki, Ed. Experimental [Page 33] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 be influenced by network engineering and implementation
 considerations, including whether a handoff smoothing solution is
 used, and is beyond the scope of this specification.

4.3. Renewal or Termination of Tunneling Service

 To prevent a BET from expiring when its lifetime runs out, the MN's
 current FA signals the aFA to either renew or terminate the BET.
 This may be the case when the MN defers Mobile IPv4 Registration.  If
 no such signal is received, the aFA will terminate the BET when the
 lifetime expires.  In addition, the current FA or aFA may need to
 terminate the BET prior to the lifetime expiring.  In order to avoid
 error conditions in which tunnels do not expire even though the MN to
 which they apply is no longer reachable, FAs SHOULD set the tunnel
 lifetime field to some value other that 0xffff, which indicates "good
 until canceled".
 Figure 12 illustrates the message exchange that occurs between the FA
 needing to terminate or extend the tunnel (designated FA(1) in the
 figure) and the other FA (designated FA(2) in the figure).  The
 HRqst(r)/HRply(r) is indicated by setting the R bit in the
 HRqst/HRply messages.  If the HRqst(r) is renewing a BET, then it
 contains a non-zero lifetime; otherwise, if the lifetime is set to
 zero, it indicates tunnel termination.  The aFA has complete control
 over whether a tunnel is extended or terminated, and it MAY reply to
 a request for extension with a shorter lifetime than was requested.
                             HRqst(r)
                    +------+ <--------  +------+
                    | FA(2)| ---------> | FA(1)|
                    +------+ HRply(r)   +------+
              Figure 12 - BET Renewal or Termination

4.4. When Will the MN Perform a Mobile IPv4 Registration?

 The MN/FA have control over when to perform the Mobile IPv4
 Registration.  Although the MN/FA may decide to defer Mobile IPv4
 Registration for a certain period, three possible events can lead to
 the need to terminate tunneling service.  If this occurs, the MN MUST
 perform the Mobile IPv4 Registration.  These events are:
    1) The end of life for the BET is pending and a request by the
       current FA to aFA for renewal has been denied, or alternatively
       the current FA or aFA needs to terminate the BET prematurely.
       The FA in this case MUST initiate the Mobile IPv4 Registration
       by sending an Agent Advertisement to the MN as in [1].

El Malki, Ed. Experimental [Page 34] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

    2) The MN itself decides to perform a Mobile IPv4 Registration and
       initiates it by sending an Agent Solicitation as in [1].
    3) During a source-triggered handoff, the oFA attempts to perform
       BET handoff but nFA is not capable of performing it.  The FA in
       this case MUST initiate the Mobile IPv4 Registration by sending
       the MN an Agent Advertisement as in [1].  Note that this
       situation will never arise during target-triggered handoff
       because an HRqst(t) will not be sent to oFA by an nFA that
       doesn't support POST-REGISTRATION.
 Some detailed scenarios relating to case 2) will be described
 hereafter.  According to [1], when using an FA care-of address, the
 MN MAY use the FA as its default router.  Otherwise, it MUST choose
 its default router from those advertised in the ICMP Router
 Advertisement portion of the Agent Advertisement.  Here we assume
 that the FA router is also the MN's default router.  In POST-
 REGISTRATION, when a tunnel is established between oFA and nFA and
 the MN has moved to nFA, the oFA MUST NOT send Agent Advertisements
 to the MN.  In this case, it is possible that the MN will not receive
 Agent Advertisements for extended periods of time.  According to [8],
 hosts will remove default router entries if the lifetime of the
 Router Advertisement expires and no further advertisements are
 received.  Note that the ICMP Router Advertisement lifetime is not
 related to the Registration Lifetime in the Mobility Agent
 Advertisement extension [1].  To avoid this disruption, the MN MUST
 solicit the default router (i.e., FA) before the lifetime of its
 active default router entry runs out, or alternatively, the FA MUST
 advertise as soon as the MN-nFA link is up (L2-LU).  This effectively
 means that the MN will at most be able to defer Mobile IPv4
 Registration for as long as the remaining lifetime of the active
 default router, as configured in the ICMP Router Advertisements.  The
 MN MUST perform a Mobile IPv4 Registration [1] when it receives an
 Agent Advertisement following a POST-REGISTRATION handoff.

El Malki, Ed. Experimental [Page 35] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

4.5. Handoff Request (HRqst) Message Format

 This is a new Mobile IPv4 message carried on UDP (destination port
 434) [1].  The UDP header is followed by the fields below.
  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      |H|N|R|M|G|T|B|            Reserved             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Lifetime           |          Reserved             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        MN Home Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          HA Address                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                         Identification                        +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Extensions ...
 +-+-+-+-+-+-+-+-
    Type              16 (Handoff Request)
    H                 Source-triggered handoff request.  When set and
                      the N bit is unset, indicates that the request
                      was the result of an L2-ST at oFA.
    N                 Target triggered handoff request.  When set and
                      the H bit is unset, indicates that the request
                      was the result of an L2-TT at nFA.
    R                 Set if the request is an HRqst(r) (i.e., a
                      request to renew the tunnel, H and N bits must
                      be unset).
    M                 The FA issuing the HRqst will use Minimal
                      Encapsulation as defined in [1,5] for the
                      tunnel.
    G                 The FA issuing the HRqst will use Generic
                      Routing Encapsulation (GRE) [4] as defined in
                      [1,5] for the tunnel.  Extensions of HRqst
                      containing GRE type and key Fields are outside
                      the scope of this document.

El Malki, Ed. Experimental [Page 36] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

    T                 For an HRqst(s), indicates that the oFA is
                      willing to support both forward and reverse
                      tunnel service.  For an HRqst(t), indicates that
                      the nFA is requesting reverse tunnel service.
    B                 When sent in an HRqst(s), indicates that the MN
                      has requested a reverse tunnel to the HA and
                      that the nFA SHOULD use a reverse tunnel to the
                      HA if it will not be reverse tunneling to the
                      oFA.
    Lifetime          The lifetime of the tunnel in seconds.  If this
                      is an HRqst(t), then the lifetime represents a
                      request by nFA for a reverse tunnel.  If this is
                      an HRqst(s), then the lifetime represents the
                      maximum amount of time that oFA is willing to
                      maintain both forward and reverse tunnels.  If
                      this is an HRqst(r), then the lifetime
                      represents a request for the amount of time to
                      renew the tunnel's lifetime.  A value of 0 on an
                      HRqst(s) indicates that the oFA is unwilling to
                      grant tunnel service.  A value of 0 on an
                      HRqst(t) indicates that the nFA does not require
                      reverse tunnel service.  A value of 0 on an
                      HRqst(r) indicates that the tunnel should be
                      terminated.  A value of 0xffff indicates
                      infinity.
    MN Home Address   For HRqst(s), the home address of the MN.
    HA Addr           For HRqst(s), the HA address of the mobile node.
    Identification    As defined in [1].
    Extensions        The message MUST include an LLA (see Section 9)
                      containing the MN's L2 address and an L2 address
                      that can be mapped to an IPv4 address for the
                      FA.  This message MUST contain the FA-FA
                      Authentication Extension [11] that is used to
                      secure the HRqst message.

El Malki, Ed. Experimental [Page 37] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

4.6. Handoff Reply (HRply) Message Format

 This is a new Mobile IPv4 message carried on UDP (destination port
 434) [1].  The UDP header is followed by the fields below.
  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      |H|N|R|M|G|T|B|    Reserved     |    Code       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Lifetime             |         Reserved              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        MN Home Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          HA Address                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                         Identification                        +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Extensions ...
 +-+-+-+-+-+-+-+-
    Type              17 (Handoff Reply)
    Code              A value indicating the result of the Handoff
                      Request.  Only two codes are currently
                      supported, 0, indicating success, and 1,
                      indicating that the handoff cannot be performed.
                      The remaining values are for future use.
    Lifetime          The lifetime, in seconds, for which the
                      bidirectional tunnel for the MN will be
                      maintained.  If this is an HRply(s), then the
                      lifetime represents a request by nFA, and it can
                      be any value up to the maximum value sent in the
                      HRqst(s).  Larger values are assumed to default
                      to oFA's maximum.  If this is an HRply(t), then
                      the lifetime represents the maximum amount of
                      time that the oFA will grant to the nFA.  If
                      this is an HRply(r), then the lifetime
                      represents the amount of time by which the
                      tunnel life will be extended.  If the Code field
                      indicates that handoff failed, the Lifetime
                      field will be ignored and SHOULD be set to zero.
                      A value of 0 on an HRply(t) indicates that the
                      oFA is unwilling to grant service.  A value of 0
                      on an HRply(s) indicates that the nFA does not

El Malki, Ed. Experimental [Page 38] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

                      require service.  A value of 0 on an HRply(r)
                      indicates that the tunnel lifetime will be
                      terminated.  A value of 0xffff indicates an
                      infinite lifetime.
    H                 Source-triggered handoff reply.  When set and
                      the N bit is unset, indicates that the reply is
                      in response to an HRqst(s).
    N                 Target-triggered handoff reply.  When set and
                      the H bit is unset, indicates that the reply is
                      in response to an HRqst(t).
    R                 Set if the reply is an HRply(r).  Neither the H
                      nor the N bit are set.
    M                 The FA issuing the HRqst will use Minimal
                      Encapsulation as defined in [1,5] for the
                      tunnel.
    G                 The FA issuing the HRqst will use GRE [4]
                      Encapsulation as defined in [1,5] for the
                      tunnel.  When this flag bit is set, the HRply
                      may require extensions containing the GRE type
                      and key fields, but they are outside the scope
                      of this document.
    T                 For an HRply(s), indicates that the nFA is
                      requesting to reverse tunnel service.  For an
                      HRply(t), indicates that the oFA is willing to
                      provide both forward and reverse tunnel service.
    B                 When sent in an HRply(t), indicates that the MN
                      has requested a reverse tunnel to the HA and
                      that the nFA SHOULD use a reverse tunnel to the
                      HA if it will not be reverse tunneling to the
                      oFA.  It can be set in HRply(t) only if the T
                      bit was unset in the corresponding HRqst(t).
    MN Home Address   For HRply(t), the home IPv4 address of the MN.
    HA Addr           For HRply(t), the HA IPv4 address of the MN.
    Identification    As defined in [1].
    Extensions        This Message MUST contain the FA-FA
                      Authentication Extension [11] that is used to
                      secure the HRply message.

El Malki, Ed. Experimental [Page 39] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

4.7. Handoff to Third (HTT) Message Format

 The Handoff to Third message has the same format as the Handoff
 Request and Handoff Reply messages, except both the H and N bits are
 set.  If the HTT message is in response to an L2-ST and is sent to
 initiate a handoff, then, with the exception of the H and N bits, the
 message has the same fields set and includes the same extensions as
 an HRqst(s).  If the HTT message is sent in response to an HRqst(t),
 then, with the exception of the H and N bits, the message has the
 same fields set and includes the same extensions as an HRply(t).  The
 tunnel bits MUST NOT be set in the HTT message because BET
 construction is not negotiated between oFA and nFA; it is negotiated
 between nFA and aFA in the ensuing HRqst(t)/HRply(t).
 In addition, the HTT MUST contain the following extensions in the
 specified order:
    Solicited IPv4 Address Option: containing aFA's Address
    LLA Option: containing the L2 address of the MN.

4.8. Applicability of POST-REGISTRATION Handoff Method

 The POST-REGISTRATION handoff approach allows FAs to communicate
 directly about a pending handoff, and does not require any IPv4-layer
 messages to be sent to or from an MN prior to the L2 handoff event.
 Therefore, it eliminates a possible source of handoff latency.  This
 may be required when the link layer imposes hard deadlines on the
 time at which a handoff must occur, such as when an MN is rapidly
 moving out of a radio coverage area.  Consequently, POST-REGISTRATION
 is primarily of interest in handoff between FAs that support the same
 radio access technology.  Handoff between heterogeneous radio
 technologies will, of necessity, require interaction between the MN
 and the network, and so is not a domain of applicability for POST-
 REGISTRATION.
 Because a POST-REGISTRATION handoff is triggered by an unspecified
 mechanism that informs the oFA or nFA that an L2 handoff is pending,
 the POST-REGISTRATION approach is only applicable to networks where
 such a mechanism is available.  For example, an L2 may provide
 indications of radio signal quality that cause the oFA or nFA to send
 the POST-REGISTRATION handoff messages.  Any such indications must
 also provide each FA involved in the handoff with the identity of the
 other, so that messages can be sent to the right place.  This may
 involve mapping L2 information onto FA IPv4 addresses.  Also, the FAs
 involved in a handoff must have pre-provisioned security arrangements
 so that the POST-REGISTRATION messages can be authenticated.  If a
 handoff is to be completed as a result of the POST-REGISTRATION

El Malki, Ed. Experimental [Page 40] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 messaging, any L2 handoff indications must also be securely
 authenticated so that traffic to the old point of attachment is not
 improperly halted.
 POST-REGISTRATION handoff is appropriate in the following cases:
  1. L2 triggers are available on the network to indicate that L2

handoff is pending.

  1. Pre-provisioned security mechanisms are in place to allow fast

and secure messaging between the FAs and between the MN and an

      FA.
  1. Access point choice by the MN is not a concern or the choice

requires user intervention and therefore is not on the critical

      path for handoff.

5. Combined Handoff Method

 The combined method uses both PRE-REGISTRATION and POST-REGISTRATION
 handoff.  If PRE-REGISTRATION does not complete prior to the
 expiration of a timer on the nFA, the POST-REGISTRATION mechanism is
 used to create the tunnel between oFA and nFA.  This protects the MN
 from delays caused by errors such as loss of the Mobile IPv4
 Registration Reply message involved in PRE-REGISTRATION for the
 mobile-initiated and network-initiated source-triggered cases.  It
 also protects the MN from delays caused by errors or the loss of any
 of the Mobile IPv4 messages involved in PRE-REGISTRATION for the
 network-initiated target-triggered case.
 When the nFA receives a target trigger, it will follow the PRE-
 REGISTRATION procedure.  When the combined method is used, the nFA
 MUST also start a timer when it receives a target trigger.  The timer
 should be set to a small value (default for target trigger case: 1
 second).
 According to PRE-REGISTRATION, the nFA will receive the Registration
 Request from the MN.  When the combined method is used, this
 Registration Request sent by the MN MUST contain the IPv4 address of
 the oFA in an FA IPv4 address LLA extension (see Section 9.7).  This
 same Registration Request message will contain multiple LLA
 extensions, since it will also contain the MN's layer 2 address in an
 LLA extension as described for PRE-REGISTRATION (see Sections 3.7 and
 9).  When the nFA has not started the handoff procedure using a
 target trigger (i.e., mobile-initiated or network-initiated target-
 triggered cases), the nFA MUST start a timer as soon as it receives
 the low-latency Registration Request from the MN.  This timer should
 be set to a small value (default: 1 second).

El Malki, Ed. Experimental [Page 41] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 In all cases, the timer MUST be reset when the Registration Reply
 message is received by nFA.  If the timer expires before the
 Registration Reply is received, the nFA MUST initiate the POST-
 REGISTRATION procedure.  The nFA utilizes the oFA IPv4 address
 (previously received in the extension to the Registration Request
 message) as the destination of the POST-REGISTRATION HRqst message to
 create the tunnel between nFA and oFA.  The nFA MAY tear down this
 tunnel when it receives and forwards a successful Registration Reply
 for that MN.

6. Layer 2 and Layer 3 Handoff Timing Considerations

 In the optimal cases considered in the PRE-REGISTRATION and POST-
 REGISTRATION handoffs, it was assumed that a timely L2 trigger would
 be received in such a way that packets could be delivered to the MN
 via its nFA immediately upon connection.  In this way, the MN does
 not suffer disruption due to the L3 handoff.  However, such precise
 timing of the L2 trigger and handoff mechanism with respect to the
 actual L2 handoff event will not be possible in all wireless systems
 and may depend on particular implementation techniques.  Therefore,
 some uncertainty may exist at L3 as to exactly when the L2 connection
 between the MN and the nFA becomes fully established and can be used
 for L3 traffic.  It is possible that in certain implementations
 traffic will be re-routed too early or too late with respect to the
 moment when the connection between the MN and the nFA becomes fully
 established.  The techniques that may solve this problem and allow
 the MN to receive traffic independently of the timing of the L2
 handoff event include buffering and simultaneous bindings (i.e.,
 bicasting: setting the S bit [1] in Registration Requests).  However,
 these are optional and are not mandated.

7. Reverse Tunneling Support

 The handoff methods all support reverse tunneling.  The MN may
 request reverse tunneling [3] by setting the T bit in its
 Registration Request.  In the case of POST-REGISTRATION, if the MN
 had requested reverse tunneling previously at oFA, the handoff
 message from oFA (see Section 4) includes the T bit enabled to inform
 nFA to establish a BET for the visitor entry.  Typically, the T bit
 will always be set to ensure that any delays in the MN receiving its
 new care-of address do not result in any delay in uplink packet
 transmission from the MN, but local policies and particular L2
 technologies may allow the reverse tunnel to be turned off.

El Malki, Ed. Experimental [Page 42] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

8. Handoff Signaling Failure Recovery

 In general and to a greater extent in wireless networks, packets
 carrying handoff signaling may be dropped or lost due to errors on
 the link.  In this section, we consider mechanisms for recovery from
 handoff signaling failures.

8.1. PRE-REGISTRATION Signaling Failure Recovery

 Failure of PRE-REGISTRATION signaling breaks down into three cases:
    1) Loss of messages PrRtSol and PrRtAdv on the air link.
    2) Loss of the solicitation by an FA to obtain another neighboring
       FA's Advertisement or loss of the neighboring FA's
       advertisement.
    3) Failure of the standard Mobile IPv4 Registration.
 Of these, case 3) is handled by standard Mobile IPv4 mechanisms
 described in [1].  Case 2) is expected to be a rare event because
 spontaneous packet drop rates on the fixed network are caused by
 congestion or router failure.  Since bit error rates on wireless
 links are higher than on fixed links, case 1) is more likely to
 occur.  In the following subsections, cases 1) and 2) are considered.

8.1.1. Failure of PrRtSol and PrRtAdv

 PRE-REGISTRATION handoff can fail in network-initiated handoff when
 the PrRtAdv sent by oFA in response to the source trigger (L2-ST) or
 the advertisement sent by nFA in response to the target trigger (L2-
 TT) fails to reach the MN.  PRE-REGISTRATION handoff can also fail in
 mobile-initiated handoff when either the PrRtSol sent from the MN or
 return PrRtAdv sent from the oFA is dropped.  To reduce the
 probability that PrRtAdv and PrRtSol are lost, the MN and FA MAY
 transmit multiple copies of these messages.  Should these messages
 fail anyway, in both cases the MN connects to the nFA without having
 received any prior signaling.  In this case, the MN solicits an FA
 Advertisement when it connects to nFA at L2 (L2-LU), as described in
 Section 3.6, and performs a standard Mobile IPv4 Registration with
 the nFA as specified in [1].

El Malki, Ed. Experimental [Page 43] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

8.1.2. Failure of Inter-FA Solicitation and Advertisement

 The solicitation from an FA to another neighboring FA may fail or the
 corresponding advertisement from the neighboring FA may be lost.  To
 reduce the probability that these messages are lost, the FAs MAY
 transmit multiple copies of these messages.  If a failure occurs
 anyway, the FA soliciting the Agent Advertisement is unable to send a
 PrRtAdv in response to a source trigger or to a mobile-initiated
 PrRtSol.  In these cases, when the MN does not receive a notification
 or confirmation of a PRE-REGISTRATION handoff, the MN MUST perform a
 standard Mobile IPv4 Registration as soon as it connects to the nFA
 (L2-LU) as described in Section 8.1.1.

8.2. POST-REGISTRATION Signaling Failure Recovery

 Failure occurs in POST-REGISTRATION when either the HRqst or HRply
 message is dropped.  The effects of the failure and the recovery
 procedure depend on which message is dropped, and whether the handoff
 is source or target triggered.  Since all of the POST-REGISTRATION
 signaling is going over the fixed network, it can be expected that
 spontaneous dropping of packets in the absence of congestion and
 router failure should be a relatively rare event.  Nevertheless,
 failure recovery mechanisms SHOULD be implemented.

8.2.1. HRqst Message Dropped

 If the HRqst message is dropped, the effect is the same for both
 source- and target-triggered handoffs.  In either case, the FA to
 which the HRqst was destined will never respond with an HRply
 message.  If the handoff is source triggered, then the nFA never
 learns of the handoff, and the oFA never receives confirmation.  If
 the handoff is target-triggered, then the oFA never learns of the
 handoff, and the nFA never receives confirmation.
 The recovery procedure in this case is as follows: the oFA MUST NOT
 construct a forward tunnel when the MN moves off-link (L2-LD) if the
 handoff is source-triggered, and the nFA MUST NOT construct a reverse
 tunnel if the handoff is target triggered.  If the nFA was not
 informed of the handoff by an HRqst message (corresponding to failure
 of source-triggered handoff) or if the handoff was not confirmed by
 an HRply message (corresponding to failure of target-triggered
 handoff), the nFA MUST unicast an Agent Advertisement to the MN as
 soon as its L2 connection is established (L2-LU at nFA).

El Malki, Ed. Experimental [Page 44] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

8.2.2. HRply Message Dropped

 If the HRply message is dropped, the FA sending the HRply will assume
 that the handoff has been confirmed, but the FA that is expecting to
 receive the HRply does not receive confirmation.  In this case, the
 failure recovery procedure is different for source-triggered and
 target-triggered handoffs.
 In a target-triggered handoff, the oFA assumes that the handoff is
 confirmed because it has sent the HRply, but the nFA has not received
 it so it does not have confirmation.  The oFA starts tunneling
 packets to the nFA when the MN moves from its link (L2-LD).  The nFA
 MUST send an FA Advertisement to the MN as soon as its L2 link is up
 (L2-LU at nFA) and MAY drop the tunneled packets.  The nFA SHOULD
 send an ICMP Destination Unreachable [9] message to the oFA.  When
 the oFA receives this message, it will terminate the tunnel and stop
 forwarding packets.  If reverse tunneling was requested, the nFA MUST
 NOT reverse tunnel because it has not received handoff confirmation.
 In source-triggered handoff, the nFA assumes that the handoff is
 confirmed because it has sent the HRply, but the oFA has not received
 it so it does not have confirmation.  Without failure recovery, the
 MN could move to the nFA without the oFA being able to start the
 forward tunnel for the MN's packets, and the MN would not be able to
 initiate a Mobile IPv4 Registration because it does not know that the
 handoff has failed.  In this situation, the oFA MUST send out an
 HRqst message to the nFA with lifetime zero as soon as the MN leaves
 its link (L2-LD).  The oFA SHOULD continue to retransmit the HRqst
 message, with exponential backoff for CONFIG-HFAIL seconds or until
 it receives an HRply acknowledging the request to cancel the tunnel.
 The default value for CONFIG-HFAIL is 10 seconds.  When the nFA
 receives the HRqst, it MUST immediately send an Agent Advertisement
 to the MN, as is the case whenever a tunnel is canceled.  In
 addition, the oFA MUST also drop any packets received through the
 reverse tunnel from the nFA.  The oFA SHOULD NOT send the ICMP
 Destination Unreachable message to the nFA because the nFA has been
 informed by the HRqst message to cancel the tunnel.  However, if the
 nFA receives an ICMP Destination Unreachable message for the tunnel
 prior to receiving the HRqst canceling the tunnel, it MUST send an FA
 Advertisement to the MN and cancel the tunnel.

El Malki, Ed. Experimental [Page 45] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

9. Generalized Link Layer and IPv4 Address (LLA) Extension

 This section defines the Generalized Link Layer and IPv4 Address
 (LLA) Extension, used by any node that needs to communicate link
 layer and IPv4 addresses.  The format of the extension relies on
 sub-types, where each sub-type defines its own sub-structure.  This
 document defines six sub-types.  Future RFCs should allocate their
 own sub-type and define their own address formats.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    LLA ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Type
      138 (skippable) [1]  - when used in Registration Requests
      140 (skippable) [1]  - when used in Agent Advertisements
    Length
      The length of the Link Layer Address + the one-octet Sub-Type
      field
    Sub-Type
      This field contains the Link Layer sub-type identifier
    LLA
      Contains the Link Layer Address
    In this document, seven sub-types are defined:
          1        3GPP2 International Mobile Station Identity and
                   Connection ID [13]
          2        3GPP International Mobile Subscriber Identity [15]
          3        Ethernet 48-bit MAC address [5]
          4        64-bit Global ID, EUI-64 [6]
          5        Solicited IPv4 Address
          6        Access Point Identifier
          7        FA IPv4 Address
 The following subsections describe the extensions.

El Malki, Ed. Experimental [Page 46] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

9.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension

 The IMSI Link Layer Address Extension contains the International
 Mobile Station Identity (IMSI).
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    IMSI ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type
          1 (skippable) [1]
       Length
          The length of the IMSI field + the one-octet Sub-Type field
       Sub-Type
          1
       IMSI
          Contains the IMSI, in the form:
                     <IMSI>:<Connection Id>
          Where the <IMSI> is an ASCII-based representation of the
          International Mobile Station Identity, most significant
          digit first, ":" is ASCII 0x3a, and the Connection ID is the
          ASCII representation of a small, decimal number used for
          distinguishing different link-layer connections from the
          same mobile device.

El Malki, Ed. Experimental [Page 47] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

9.2. 3GPP IMSI Link Layer Address Extension

 The IMSI Link Layer Address Extension contains the International
 Mobile Station Identity.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    IMSI ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type
          2 (skippable) [1]
       Length
          The length of the IMSI field + the one-octet Sub-Type field
       Sub-Type
          2
       IMSI
          Contains the IMSI, a number composed of 15 digits or less,
          coded as described in [15].

El Malki, Ed. Experimental [Page 48] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

9.3. Ethernet Link Layer Address Extension

 The Ethernet Link Layer Address Extension contains the 48-bit
 Ethernet MAC Address, as defined in [5].
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    MAC ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type
          3 (skippable) [1]
       Length
          7 (includes the Sub-Type field)
       Sub-Type
          3
       MAC
          Contains the 48-bit Ethernet MAC Address.

El Malki, Ed. Experimental [Page 49] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension

 The 64-bit Global Identifier (EUI-64) Address Extension contains the
 64-bit address, as defined in [6].
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    MAC ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type
          4 (skippable) [1]
       Length
          9 (includes the Sub-Type field)
       Sub-Type
          4
       MAC
          Contains the 64-bit Global Identifier Address.

El Malki, Ed. Experimental [Page 50] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

9.5. Solicited IPv4 Address Extension

 The 32-bit Solicited IPv4 Address Extension contains the IPv4 address
 of the agent (FA) being solicited.  This extension MAY be present in
 an ICMP Agent Solicitation as explained in Section 3.3.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    IPv4 addr ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type
          5 (skippable) [1]
       Length
          5 (includes the Sub-Type field)
       Sub-Type
          5
       IPv4 Address
          Contains the 32-bit IPv4 Address of the solicited node.

El Malki, Ed. Experimental [Page 51] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

9.6. Access Point Identifier Extension

 The 32-bit Access Point Identifier Extension contains an identifier
 of the access point to which the MN will move.  This may be a
 wireless L2 identifier.  The MN is able to solicit an advertisement
 from the FA servicing a certain access point by using this extension
 with Agent Solicitations as explained in Section 3.3.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    AP ID...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type
          6 (skippable) [1]
       Length
          5 (includes the Sub-Type field)
       Sub-Type
          6
       AP ID
          Contains the 32-bit Access Point Identifier.

El Malki, Ed. Experimental [Page 52] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

9.7. FA IPv4 Address Extension

 The 32-bit FA IPv4 Address Extension contains the IPv4 address of the
 agent (FA).  This extension MAY be present in a Registration Request
 message to identify the oFA as explained in Section 5.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    IPv4 addr ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type
          7 (skippable) [1]
       Length
          5 (includes the Sub-Type field)
       Sub-Type
          7
       IPv4 Address
          Contains the 32-bit IPv4 Address of the FA node.

10. IANA Considerations

 This document defines one new extension to Mobile IPv4 Control
 messages and one new extension to Mobile IPv4 Router Discovery
 messages already maintained by IANA.  This document also defines a
 new Mobile IPv4 Control message type to be used between FAs.  To
 ensure correct interoperation based on this specification, IANA must
 reserve values in the Mobile IPv4 number space for two new extensions
 and one new message type.  IANA must also manage the numbering spaces
 created by the two new extensions, the message type, and its
 associated Code field.

10.1. New Extension Values

 Section 9 introduces two extensions.
 Generalized Link Layer and IPv4 Address (LLA) Extension for Router
 Discovery messages: A new Mobile IPv4 extension that follows after
 Mobile IPv4 ICMP Router Discovery messages (e.g., Mobile IP Agent
 Advertisements).  The type value of this extension belongs to the

El Malki, Ed. Experimental [Page 53] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 Mobile IPv4 number space for Router Discovery messages maintained by
 IANA.  The value assigned by IANA is 140.  This new extension uses
 the Link Layer and IPv4 Address Identifier (LLA) sub-type numbering
 space that requires IANA management (see Section 10.2).
 Generalized Link Layer and IPv4 Address (LLA) Extension for Mobile IP
 Control messages: A new Mobile IPv4 extension appended to Mobile IP
 Control messages (e.g., Registration Request).  The type value of
 this extension belongs to the Mobile IPv4 number space for extensions
 to Mobile IPv4 Control messages maintained by IANA.  It MUST be in
 the skippable (128-255) range as defined in [1].  The value assigned
 is 138 by IANA.  This new extension uses the Link Layer and IP
 Address Identifier (LLA) sub-type numbering space that requires IANA
 management (see Section 10.2).

10.2. Generalized Link Layer and IP Address Identifier (LLA)

     Sub-type Values
 This section describes the sub-type values that are applicable to
 both the Generalized LLA Extensions for Mobile IP Control and Router
 Discovery messages.  This specification makes use of the sub-type
 values 1-7, and all other values other than zero (reserved) are
 available for assignment via IETF consensus [14].  The seven sub-type
 values defined in this specification are:
       1        3GPP2 International Mobile Station Identity and
                Connection ID [13]
       2        3GPP International Mobile Subscriber Identity [15]
       3        Ethernet 48-bit MAC address [5]
       4        64-bit Global ID, EUI-64 [6]
       5        Solicited IPv4 Address
       6        Access Point Identifier
       7        FA IPv4 Address

10.3. New Message Type and Code

 Sections 4.5 and 4.6 define two new Mobile IPv4 message types:
 Handoff Request and Handoff Reply.  These require two type numbers to
 be assigned by IANA from the Mobile IPv4 Control message type address
 space.  The Handoff Reply message also introduces its own Code field
 that requires IANA to manage a new Code address space.  This
 specification makes use of the Code values 0-1, where 0 identifies a
 successful handoff and 1 defines a generic handoff failure.  All
 other values are available for assignment via IETF consensus [14].

El Malki, Ed. Experimental [Page 54] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 Code Values for Mobile IP Handoff Reply Messages
 0          Successful Handoff
 1          Generic Handoff Failure
 2-255      Unallocated

11. Security Considerations

 For the PRE-REGISTRATION method, as discussed in Section 3.8, the oFA
 and nFA MUST share a security association to authenticate and
 integrity protect messages transported between them.  In addition,
 oFA must be authorized to solicit nFA based on the security
 association.  The minimal requirement to establish a security
 association between FAs is that both FAs support manual pre-
 configuration of security associations involving shared keys.  Other
 mechanisms to establish security associations using IKE [16] based on
 shared secrets or public keys may also be used.  The inter-FA ICMP
 messages (solicitations and advertisements) MUST be authenticated and
 integrity protected using ESP [10].  The default ESP authentication
 algorithm for use in this specification is HMAC-SHA1-96 [12].  The
 absence of this security would allow denial-of-service attacks from
 malicious nodes at any distance from the FA.  To secure Registration
 Request and Reply messages, PRE-REGISTRATION uses the security
 mechanisms already described in [1] and optionally [11].
 POST-REGISTRATION introduces a new change to Mobile IPv4, which is
 the possibility that an MN may receive packets from an FA with which
 it has not yet performed a Mobile IPv4 Registration.  It is not
 recommended that the MN drop packets from unknown FAs since it would
 effectively eliminate the advantages of POST-REGISTRATION.  From a
 security viewpoint, dropping packets from unknown FAs would not
 provide significant protection for an MN from any attack.  This is
 because any malicious host may use the MN's home address to send
 packets to the MN through its current known FA; therefore, processing
 packets received from unknown FAs would not provide worse security
 than with normal Mobile IPv4.
 In a similar way to PRE-REGISTRATION, in POST-REGISTRATION, oFA and
 nFA MUST share a security association required to protect the Handoff
 Request and Reply messages.  The minimal requirement to establish a
 security association between FAs is that the FAs support manual pre-
 configuration of security associations involving shared keys.  Other
 mechanisms to establish security associations using IKE [16] based on
 shared secrets or public keys may also be used.  The Handoff Request
 and Reply messages MUST be authenticated using the FA-FA
 authentication extension [11] that uses the default algorithm
 specified in [7].  The absence of this security would allow
 impersonation attacks and denial-of-service attacks.

El Malki, Ed. Experimental [Page 55] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 The minimal requirement is that all FAs involved in low latency
 handoffs MUST support manual pre-configuration of peer-to-peer
 security associations with neighboring FAs, involving shared secrets
 and are already required to support the default algorithms of [1].
 Other mechanisms to establish security associations using IKE [16]
 based on shared or public keys may also be used.
 Since the techniques outlined in this document depend on particular
 L2 information (triggers) to optimize performance, some level of L2
 security is assumed.  Both PRE- and POST-REGISTRATION techniques
 depend on L2 triggers, but the L2 security implications are different
 for the two techniques.
 In particular, in POST-REGISTRATION, the L2 triggers initiate the
 establishment of tunnels that route IPv4 packets for the MN to its
 new location.  Therefore, the L2 triggers MUST be secured against any
 tampering by malicious nodes, either mobile or within the wired
 network.  The L2 addresses or IPv4 addresses for the MN and the FAs
 that appear in the L2 triggers MUST correspond to the actual nodes
 that are participating in the handoff.  If there is any possibility
 that tampering may occur, the recipient of an L2 trigger MUST have
 some way of authenticating the L2 information.  Wireless networks
 that do not provide such features will be subject to impersonation
 attacks, where malicious nodes could cause FAs to believe that an MN
 has moved to other service areas or to allow a bogus MN to obtain
 unauthorized service from an FA prior to performing a Mobile IPv4
 Registration.  In POST-REGISTRATION, the L2 triggers would typically
 be sent between a wireless base station and the FA.  No standard
 protocol exists at this time to communicate the L2 trigger
 information, but it is important that any future protocol used for
 this purpose provides adequate security.  If the wireless base
 station and FA were integrated, then this security threat would not
 apply.  Also the layer 2 control messages on the wireless link must
 be secured appropriately to prevent a malicious node from running
 impersonation attacks and causing unwanted L2 triggers to be
 generated.  Integrity and replay protection would be required to
 avoid impersonation threats and resource consumption threats where a
 malicious node replays old messages to cause resource consumption.
 This depends on the type of L2 security of the wireless link.  For
 example, in cellular technologies, the control messages are secured,
 although the type of security varies depending on the cellular
 standard, but this is not typically the case in WLAN IEEE 802.11
 networks.
 In PRE-REGISTRATION, the security of L2 triggers has different
 implications.  The PRE-REGISTRATION technique depends on Mobile IPv4
 security between MN and FA, so the same security considerations in
 [1] apply.  Should malicious nodes be able to generate or modify L2

El Malki, Ed. Experimental [Page 56] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 trigger information (i.e., L2-ST or L2-TT), this would cause
 advertisements to be sent to the MN.  They would consume wireless
 resources and processing in the MN, but would not allow an
 impersonation attack.  In order to prevent such denial-of-service
 attacks, there should be a limit on the number of advertisements that
 an FA (oFA) will relay to the MN as a result of the reception of L2
 triggers.  This number will depend on the L2 technology, and the
 default limit is 10 per second.

12. Acknowledgements

 The authors want to thank Lennart Bang, Bryan Hartwell, Joel
 Hortelius, Gianluca Verin, and Jonathan Wood for valuable comments
 and suggestions on the whole document.  The authors also thank the
 Mobile IPv4 WG chairs, Phil Roberts and Basavaraj Patil, for their
 input.

13. References

13.1. Normative References

 [1]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
      August 2002.
 [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [3]  Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised",
      RFC 3024, January 2001.
 [4]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
      "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
 [5]  Plummer, D., "Ethernet Address Resolution Protocol: Or
      Converting Network Protocol Addresses to 48.bit Ethernet Address
      for Transmission on Ethernet Hardware", STD 37, RFC 826,
      November 1982.
 [6]  IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
      Registration Authority",
      http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
      March 1997.
 [7]  Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
      Challenge/Response Extensions (Revised)", RFC 4721, January
      2007.

El Malki, Ed. Experimental [Page 57] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 [8]  Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256,
      September 1991.
 [9]  Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
      September 1981.
 [10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
      December 2005.
 [11] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
      Regional Registration", RFC 4857, June 2007.
 [12] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
      and AH", RFC 2404, November 1998.

13.2. Informative References

 [13] TIA/EIA/IS-2000.
 [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 [15] 3GPP TS 23.003 (www.3gpp.org).
 [16] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
      4306, December 2005.

El Malki, Ed. Experimental [Page 58] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

Appendix A - Gateway Foreign Agents

 The Mobile IPv4 Regional Registration specification [11] introduces
 the Gateway Foreign Agent (GFA), as a mobility agent that two FAs
 providing service to an MN have in common.  Figure A.1 provides an
 example of an MN's initial registration through the GFA.  If this is
 the first registration message, the message MUST be forwarded to the
 HA.  All packets sent to the MN will be delivered to the GFA, which
 in turn will forward the packets to the FA servicing the MN.
              RegReq    +-----+   RegReq
           +----------->| oFA |--------------+
           |            +-----+              |
           |                                 v
        +----+                            +-----+ RegReq  +----+
        | MN |                            | GFA |<------->| HA |
        +----+                            +-----+         +----+
                         +-----+
                         | nFA |
                         +-----+
          Figure A.1 - Initial Registrations through GFA
 If the MN moves to an nFA that is serviced by a GFA common with oFA,
 the MN MAY issue a Regional Registration Request (see Figure A.2).
 The Regional Registration message does not need to be forwarded to
 the HA, since the MN's traffic can still be delivered to the same
 GFA.  This optimized approach effectively reduces the latency
 involved in the registration process.
                         +-----+
                         | oFA |
                         +-----+
        +----+                            +-----+         +----+
        | MN |                            | GFA |         | HA |
        +----+                            +-----+         +----+
           |                                 ^
           |             +-----+             |
           +------------>| nFA |-------------+
             RegRegReq   +-----+  RegRegReq
         Figure A.2 - Regional Registration through GFA
 Note that the GFA may also be the MN's first-hop router.

El Malki, Ed. Experimental [Page 59] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

Appendix B - Low-Latency Handoffs for Multiple-Interface MNs

 For MNs that have two wireless network interfaces, either on the same
 wireless network or on wireless networks having different wireless L2
 technologies, the techniques discussed in this document may be
 unnecessary if the Mobile IPv4 stack on the MN allows switching an
 IPv4 address binding between interfaces.  This Appendix discusses how
 multiple wireless interfaces can aid low-latency handoff.
          +------+        +---------+
          |  HA  |--------|  (GFA)  |
          +------+        +---------+
                            /     \
                         ...       ...
                          /         \
                         /           \
                     +------+      +------+
                     | oFA  |      | nFA  |
                     +------+      +------+
                        |             |
                     +------+      +------+
                     | RN1  |      | RN2  |
                     +------+      +------+
                     +------+
                     |  MN  | --------->
                     +------+
                              Movement
      Figure B.1 - Network Model for Mobile IPv4 with Multi-Access
 Figure B.1 illustrates the normal and hierarchical MIPv4 models.  As
 shown in the figure, assume that the MN is connected to Radio Network
 1 (RN1) and is registered with oFA through which it is receiving
 traffic.  Suppose MN enters the coverage area of RN2 and nFA and that
 it prefers connectivity to this network for reasons beyond the scope
 of this document (e.g., user preferences, cost, QoS available, etc.).
 The MN activates the interface to RN2 but continues communicating
 through RN1.  The MN may solicit advertisements from nFA through the
 interface connected to RN1 to speed up the handoff process, provided
 there is no TTL restriction, or it can solicit advertisements through
 the interface connected to RN2 if it has been configured for IPv4
 traffic.
 Once the MN is registered with nFA and is successfully receiving and
 transmitting through the new network, it tears down the interface to
 RN1.  If the MN has enough time to complete this procedure without
 incurring degraded service or disconnection, the MN would experience
 a seamless multi-access handoff, but it may not be possible in all

El Malki, Ed. Experimental [Page 60] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

 cases, due to network coverage or for other reasons.  Should multiple
 interface handoff be possible, then the low-latency methods described
 in this document are not necessary.
 In order to support the possible failure of the connectivity with the
 new network (RN2/nFA) in the short period following handoff, the MN
 may use the S bit in its Mobile IPv4 Registration Request to maintain
 simultaneous bindings with both its existing (HA or GFA) binding with
 oFA and a new binding with nFA.

Appendix C - PRE-REGISTRATION Message Summary

 This appendix contains a quick reference for IPv4 and layer 2
 addresses to be used in PRE-REGISTRATION messages.
 Proxy Router Advertisement (PrRtAdv)
 This is a standard Router/Agent Advertisement [1] with the following
 characteristics:
    Source IPv4 Address: nFA IPv4 Address
    Source Layer 2 Address: oFA L2 Address
    Destination IPv4 Address: MN IPv4 Address (from PrRtSol)
    Destination Layer 2 Address: MN L2 Address (from PrRtSol)
    LLA Extension (defined in this spec): containing nFA Layer 2
    Address.
 Proxy Router Solicitation (PrRtSol)
 This is a standard Router/Agent Solicitation [1] with the following
 characteristics:
    Source IPv4 Address: MN Address
    Source Layer 2 Address: MN Address
    Destination IPv4 Address: oFA Address (from source address of
    previous Router Advertisement or PrRtAdv)
    Destination Layer 2 Address: oFA Address (from source address of
    previous Router Advertisement or PrRtAdv LLA)
    LLA Extension (defined in this spec): depends on the layer 2
    technology (e.g., typically for WLAN, this would be the BSSID of
    the new WLAN Access Point)
 Registration Request (as seen on MN-oFA link)
 This is a Mobile IPv4 Registration Request message [1] with the
 following characteristics:
    Source IPv4 Address: MN Address
    Source Layer 2 Address: MN Address
    Destination IPv4 Address: nFA Address (from source addr of
    PrRtAdv)

El Malki, Ed. Experimental [Page 61] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

    Destination Layer 2 Address: Default Router (i.e., oFA Address)
    LLA Extension (defined in this spec): containing the MN's L2
    address that must be used by nFA.  This will typically be an
    Ethernet MAC address but other types can be used as specified in
    Section 9 of this document.
 Although this is not mandated, an MN implementation may set the S bit
 (see Section 6) in Registration Request messages to improve the
 handoff and avoid problems due to failed layer 2 handoffs and layer 2
 ping-pong effects between two base stations.
 Registration Reply (as seen on oFA-MN link)
 This is a Mobile IPv4 Registration Reply message [1] with the
 following characteristics:
    Source IPv4 Address: nFA Address
    Source Layer 2 Address: oFA Address
    Destination IPv4 Address: MN Address (from source of Registration
    Request)
    Destination Layer 2 Address: MN Address (from source of
    Registration Request)

El Malki, Ed. Experimental [Page 62] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

Contributing Authors

 Pat Calhoun
 Cisco Systems
 EMail: pcalhoun@cisco.com
 Tom Hiller
 Lucent Technologies
 EMail: tom.hiller@lucent.com
 James Kempf
 NTT DoCoMo USA Labs
 EMail: kempf@docomolabs-usa.com
 Peter J. McCann
 Motorola Labs
 EMail: pete.mccann@motorola.com
 Ajoy Singh
 Motorola
 EMail: asingh1@email.mot.com
 Hesham Soliman
 Elevate Technologies
 EMail: Hesham@elevatemobile.com
 Sebastian Thalanany
 US Cellular
 EMail: Sebastian.thalanany@uscellular.com

Editor's Address

 Karim El Malki
 Athonet
 EMail: karim@athonet.com

El Malki, Ed. Experimental [Page 63] RFC 4881 Low-Latency Mobile IPv4 Handoffs June 2007

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

Intellectual Property

 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.

Acknowledgement

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

El Malki, Ed. Experimental [Page 64]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4881.txt · Last modified: 2007/06/29 21:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki