tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4881

 
 
 

Low-Latency Handoffs in Mobile IPv4

Part 3 of 3, p. 46 to 64
Prev RFC Part

 


prevText      Top      Up      ToC       Page 46 
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.

Top      Up      ToC       Page 47 
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.

Top      Up      ToC       Page 48 
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].

Top      Up      ToC       Page 49 
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.

Top      Up      ToC       Page 50 
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.

Top      Up      ToC       Page 51 
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.

Top      Up      ToC       Page 52 
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.

Top      Up      ToC       Page 53 
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

Top      Up      ToC       Page 54 
   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].

Top      Up      ToC       Page 55 
   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.

Top      Up      ToC       Page 56 
   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

Top      Up      ToC       Page 57 
   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.

Top      Up      ToC       Page 58 
   [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.

Top      Up      ToC       Page 59 
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.

Top      Up      ToC       Page 60 
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

Top      Up      ToC       Page 61 
   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)

Top      Up      ToC       Page 62 
      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)

Top      Up      ToC       Page 63 
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

Top      Up      ToC       Page 64 
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.