diff options
Diffstat (limited to 'doc/rfc/rfc4881.txt')
| -rw-r--r-- | doc/rfc/rfc4881.txt | 3587 |
1 files changed, 3587 insertions, 0 deletions
diff --git a/doc/rfc/rfc4881.txt b/doc/rfc/rfc4881.txt new file mode 100644 index 0000000..e504f30 --- /dev/null +++ b/doc/rfc/rfc4881.txt @@ -0,0 +1,3587 @@ + + + + + + +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: + + - 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. + + - 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 + + + - Allow the MN to communicate with the nFA while still connected + to the oFA. + + - 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: + + - PRE-REGISTRATION handoff method, + + - POST-REGISTRATION handoff method, and + + - 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: + + - to provide low-latency and low-loss handoff for real-time + services, + + - to have no dependence on a wireless L2 technology, + + - to support inter- and intra-access technology handoffs, and + + - 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: + + - an advertisement for an FA is received by an MN, + + - the advertisement allows the MN to perform movement detection, + and + + - 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: + + - 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. + + - when L2 security between the MN and the FA is either not present + or cannot be relied upon to provide adequate security. + + - 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: + + - L2 triggers are available on the network to indicate that L2 + handoff is pending. + + - Pre-provisioned security mechanisms are in place to allow fast + and secure messaging between the FAs and between the MN and an + FA. + + - 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] + |