Better Than Nothing Mobile IPv4 Fast Handovers
draft-doswald-robert-mip4-btn-fmipv4-00.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 10, 2008.

Abstract

Proposed fast handover solutions for Mobile IPv4 depend on the presence of Foreign Agents (FA) in the networks between which the Mobile Node (MN) moves to ensure their operation. However, in many situations the MN moves into networks without FAs. This document proposes a solution that includes fast handover mechanisms involving a direct connection to the Home Agent (HA). This solution is not a full fledged fast handover proposal, but rather a complement to RFC 4881: Low-Latency Handovers in Mobile IPv4, and RFC 4988: Mobile IPv4 Fast Handover.

Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol
    3.1.  Predictive Handover
    3.2.  Reactive Handover
4.  Handover Using RFC 4881 Mechanisms
    4.1.  Network with FA to Network without FA
    4.2.  Network without FA to Network without FA
    4.3.  Network without FA to Network with FA
5.  Handover Using RFC 4988 Mechanisms
    5.1.  Network with FA to Network without FA
    5.2.  Network without FA to Network without FA
    5.3.  Network without FA to Network with FA
6.  Security Considerations
    6.1.  NAT Considerations
    6.2.  Security associations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The mobile IPv4 specification [rfc3344] (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) allows for a Mobile Node (MN) to perform IPv4-layer handover when passing between different subnets whether a Foreign Agent (FA) is present or not. However, methods to achieve low-latency (or fast) handover between subnets described in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.) and [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.) only describe situations where FAs are present. While the presence of FAs is almost certainly necessary to accommodate for real-time services on a MN, the case will almost certainly present itself where a mobile node will pass onto a subnet without an FA. And while it may not me possible to offer a perfect service in the cases where no FAs are present, this document describes the methods with which such handovers may be done faster and with less packet loss then otherwise.

The purpose of this document is not to describe a new fast-handover method, but rather to complement those described in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.) and rfc4988 (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.) [rfc4988], and as such it is assumed that the reader is familiar with the basic operations and terminology of those RFCs. The general new protocol mechanisms to be introduced are described in Section 3 (Protocol), Section 4 (Handover Using RFC 4881 Mechanisms) presents the adaptations using [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.) messages and protocol mechanisms, while Section 5 (Handover Using RFC 4988 Mechanisms) deals with handovers with the [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.) scheme. Finally, Section 6 (Security Considerations) addresses security considerations, and Section 7 (IANA Considerations) addresses IANA considerations.

Some concepts are common to [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.) and [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.), but are described with different terms. The terms that are borrowed from one RFC, but have a different name in the other are described in Section 2 (Terminology). Terms introduced in this document are also described in that section.

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [rfc2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

In addition, this document introduces or redefines the following terms:

NwFA: Network with a FA that supports fast handovers.

NwoFA: Network without a FA, or with an FA that doesn’t have fast handover capability.

oFA: old Foreign Agent (as in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.)), corresponds to the PAR in rfc4988 (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.) [rfc4988].

nFA: new Foreign Agent (as in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.)), corresponds to the NAR in [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.).

Handover: A process of terminating existing connectivity and obtaining new IP connectivity (as described in [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.)), corresponds to “handoff” in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.).

3.  Protocol

The protocol can roughly be divided into three parts: the handover from a network with an FA (NwFA) to a network without an FA (NwoFA), the handover from a NwoFA to another NwoFA, and the handover from a NwoFA to a NwFA. In all cases, to achieve better handovers the protocol relies on the following mechanisms:

• The ability for the Home Agent (HA) to understand and process correctly fast handover messages. As the HA will play an important role, it should have the best possible connection to the MN. Therefore [rfc4433] (Kulkarni, M., Patel, A., and K. Leung, “Mobile IPv4 Dynamic Home Agent (HA) Assignment,” March 2006.) SHOULD also be implemented so that the MN can dynamically be assigned to an HA with the best possible connection (usually the HA closest to the MN).
• The HA MUST maintain a dynamically created list of AP/FA associations for the NwoFA to NwFA handovers. The reason for this is simply that the HA cannot know in advance the movement of the MN, and so a static list of FA/AP associations cannot be set up in advance. The method with which the HA creates this list is not enforced, but it MAY implement the candidate access router protocol (CARD) [rfc4066] (Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, “Candidate Access Router Discovery (CARD),” July 2005.). The appendix A of that document describes how to use CARD protocol to dynamically create a list of neighbours. If another method is used, that method MUST create security associations for FA-FA and HA-FA communications (see Section 6.2 (Security associations)).
• The HA will buffer the messages that pass through it, which will be resent after the MN finishes a handover to a NwoFA, or in case of a reactive handover. The HA MUST, if possible, buffer the messages for the duration of a handover up to a certain limit. That limit may be set either statically or dynamically. The HA MUST maintain a minimal buffer of all traffic to MNs, the size of which MAY be dynamically adjusted to traffic intensity and traffic type. The HA MUST also drop the buffer corresponding to a MN if its handover takes too long. The suggested default time is 2 seconds, and the maximum value is 10 seconds. The particulars of buffer management are however beyond the scope of this document.

The handover from a NwFA to another NwFA is the standard case covered in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.) and [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.). For all cases, one can distinguish the situation where the MN or the networkpredicts the handover (predictive situation) from the situation where the handover happens abruptly (reactive situation).

3.1.  Predictive Handover

The basic concepts for predictive handovers are simple:

• When the mobile node is about to move to a network which does not support fast handovers, either because there’s no FA or because the FA present does not support fast handovers, the HA buffers the communication to the MN for the duration of the handover. When the MN reconnects, the HA transmits the buffer to the MN, followed by the normal communication.
• When the mobile node will moves from a network without a FA (or with a FA that doesn’t support fast handovers) to a network with an nFA that supports fast handovers, the HA tunnels information to the nFA in advance, which buffers it until the handover is completed.

The general case of a MN moving from a NwFA to a NwoFA (predictive) is presented in greater detail in Figure 1:

+-----+  4: ask to buffer   +-----+
|     | ------------------> | HA  |
| oFA |                     |     |
+-----+                     +-----+
 ^ |  ^                      ^  /\
2| |3 |                      |  ||
 | |  |4: trigger           7|  || 8: buffer +
 | |  |  (optional)|         |  ||    tunneled data
 | v  |            |         v  \/
+-----+            |        +-----+
| MN  |            |        | MN  |
+-----+    - - - - |- - >   +-----+
          Movement |
                   |
              NwFA | NwoFA

1. The MN receives a trigger (most likely signal-strength dependent) that it should move to a new AP.
2. The MN sends a message to the oFA asking for a (AP-ID, AR-Info) tuple.
3. The oFA responds that it has no such association.
4. The oFA receives a trigger informing it the MN is about to change network. The message may be from an L2 trigger, or a message sent by the MN. The oFA sends a message to the HA requesting that it buffers data.
5. The HA stops relaying messages, buffers them, and sends an acknowledgement message to the oFA. If the oFA received a trigger message from the MN, it acknowledges it so that the MN knows that it can disconnect.
6. The MN disconnects, reconnects on the new network and obtains an IP addess.
7. The MN sends a registration request to the HA, The HA sends a registration reply.
8. The tunnel is established, and the HA sends buffered data + new data.

The predictive handover from a NwoFA to another NwoFA is similar, to only difference being that the HA also plays the role of the oFA. However, as it is not possible for the HA to receive L2 triggers, the handover has to be initiated by the MN.

The general predictive handover from a NwoFA to a NwFA is depicted in Figure 2:

+-----+           5         +-----+
|     | <-----------------> | nFA |
| HA  | ------------------> |     |
+-----+           6    ---> +-----+
 ^ |  ^               /      ^  /\
2| |3 |4b  ----------/       |  ||
 | |  |   /     4a          7|  || 8: buffer +
 | |  |  /         |         |  ||    tunneled data
 | v  | /          |         |  \/
+-----+            |        +-----+
| MN  |            |        | MN  |
+-----+    - - - - |- - >   +-----+
          Movement |
                   |
             NwoFA | NwFA

1. The MN receives a trigger (most likely signal-strength dependent) that it should move to a new AP.
2. The MN sends a message to the HA asking for a (AP-ID, AR-Info) tuple.
3. The HA responds with AR-Info for that network
4. The MN sends a message to initiate a fast handover. The recipient of the message depends on which fast handover protocol is used:

   4a.

   in the case of [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.) it is the nFA (tunnelled via the HA)

   4b.

   in the case of [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.) it is the HA.

5. The HA and nFA negotiate to create a tunnel from the HA to the nFA.
6. The HA sends an acknowledgment for the MN to the nFA. The message is buffered. Following messages for the MN are tunnelled to the nFA and buffered.
7. The MN disconnects, reconnects to the new network, and sends a message to the nFA to indicate its presence.
8. The nFA tunnels buffered data (including the acknowledge for the MN) and new data to the MN
9. The MN completes registration with the HA (if necessary) and resumes normal operation

In many cases, a MN may have the option to switch to several networks. Although the exact mechanism a MN uses to determine to which network it will attach itself is beyond the scope of this document, the presence of an FA FA supporting fast handovers SHOULD be taken into consideration.

3.2.  Reactive Handover

A reactive situation occurs as the handover happens before the MN has time to complete a predictive handover. The reactive situation as the MN moves to or from a NwoFA is the following:

1. The MN is disconnected, reconnects, and obtains an IP.
2. The MN sends a Registration request to the HA.
3. The HA replies and sends the default buffer.
4. Normal operation resumes.

The reactive situation is in fact almost identical to normal registration as described in [rfc3344] (Perkins, C., “IP Mobility Support for IPv4,” August 2002.), the only difference being the buffer which is maintained and sent by the HA. As such, its working doesn’t need to be described in terms of [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.) or [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.).

4.  Handover Using RFC 4881 Mechanisms

This section details the better than nothing fast handover protocol as described in Section 3.1 (Predictive Handover) using the same message patterns as in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.). In all cases, we will describe the handover with both the PRE-REGISTRATION and POST-REGISTRATION methods if possible. The PRE-REGISTRATION method normally allows the MN to register its next connection in advance with the HA, while the POST-REGISTRATION method normally allows a tunnel to be created between the oFA and the nFA to ensure that the communication remains unbroken during handover. Unfortunately, it is not possible to pre-register when moving to a network without a FA, and it is not possible either to create a tunnel from an old network to a new one without both an oFA and a nFA. However, the messages used in PRE-REGISTRATION and POST-REGISTRATION may sent to the HA in order for it to buffer information or send it to a nFA. Also, unlike normal POST-REGISTRATION situations, it is either impossible or undesirable to have three party handover situations.

The [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.) protocol also describes a combined method with the mechanisms of both PRE- and POST-REGISTRATION. This combined method makes no sense in a situation where at least one of the networks doesn’t have an FA, as both PRE- and POST-REGISTRATION messages have the same effect. The only difference is that POST-REGISTRATION uses L2-triggers to allow the handover to happen without a message from the MN.

4.1.  Network with FA to Network without FA

Moving from an NwFA to an NwoFA allows the use of both PRE-REGISTRATION and POST-REGISTRATION messages to communicate with the HA. Figure 3 presents the PRE-REGISTRATION situation:

    MN                    oFA                   HA
     |                     |                    |
     |-------PrRtSol------>|                    |
     |<------PrRtAdv-------|                    |
     |                     |                    |
     |--------------RegReq (via oFA)----------->| <~buffer
     |<-------RegReply (error, via oFA)---------|
     |                     |                    |
     |                     |                    |
disconnect                 |                    |
     |                     |                    |
 connect                   |                    |
     |--------------- RegRequest--------------->|
     |<-------------- RegReply------------------|
     |<==================================== deliver packets
     |                     |                    |

1. Upon receiving an L2 trigger (L2-MT), the MN sends a PrRtSol message to the oFA containing an identifier for the new network, in a Generalized Link Layer and IP Address Extension. This message MUST have a TTL=1. When the unknown identifier is received by the oFA, it MUST reply with a PrRtAdv with the nFAs IP address set to 0.0.0.0 (indicating that the oFA doesn’t have a neighbour for that network). The PrRtAdv MUST contain an LLA Extension identical to the one sent in the PrRtSol message. The PrRtAdv message may also be unsolicited if the oFA receives an L2-source trigger, in which case the MN’s identifier is contained by L2-trigger. The L2-source trigger MUST also contain an identifier for the target network, from which the oFA can determine the absence of an nFA. That identifier MUST be attached in an LLA Extension to the PrRtAdv message.
2. The MN sends a registration request to the HA, with the care of address field set to 0.0.0.0. The registration request MUST also contain the address of the HA in an FA IPv4 address LLA extension.
3. Upon receiving the registration reply, the HA starts buffering, and sends back a registration reply with error code 77 (invalid care-of address). If it cannot buffer, it sends a registration reply with error code 66 (insufficient resources) [rfc3344] (Perkins, C., “IP Mobility Support for IPv4,” August 2002.).
4. The MN disconnects from the HA, reconnects to it on the new network, and completes a normal registration with the HA.
5. When the registration with the HA is completed, it sends the buffer followed by normal communication.

The situation with POST-REGISTRATION methods is depicted in figure 4:

         MN                    oFA                  HA
          |                     |                    |
          |           L2-ST ~~~>|-------HRqst------->|<~buffer
          |                     |<------HRply--------|
          |                     |                    |
          |                     |                    |
       disconnect     L2-LD ~~~>|                    |
          |                     |                    |
          |                     |                    |
          |                     |                    |
       connect                  |                    |
L2-LU ~~~>|--------- RegRequest--------------------->|
          |<------- RegReply-------------------------|
          |<=================================== deliver packets
          |                     |                    |

1. The oFA receives a L2 source trigger informing it that the MN is about to move to a new network. The trigger contains the MN’s L2 address, and an identifier for the new network. The oFA is unable to resolve the identifier to an nFA IPv4 address.
2. The oFA sends a Handover Request (HRqst(s)) to the HA. The H bit is set and the following bits (N, R, M, G, T and B) MUST be unset. The lifetime of 0 indicates that the tunnel to the oFA MUST be discontinued; other values indicate the time that the oFA is willing to maintain a tunnel to the HA, and that the HA SHOULD send data to the oFA as well as buffer it. A value of 0xffff indicates infinity. The message MUST include an LLA extension containing the MN’s L2 address and it MUST also contain the FA-HA authentication extension [rfc3344] to secure the HRqst message.
3. The HA sends a HRply, with the H bit set, and the N and R bits unset, indicating that it is a HRply(s). All other bits are unset. The lifetime represents the time the HA will maintain the tunnel to the FA, unless the MN registers with it before, with any value beyond the one sent in the HRqst defaulting to that value. The message MUST contain the FA-HA authentication Extension to secure the HRply message.
4. The MN disconnects from the oFA’s network, and reconnects on the new one. The oFA receives a L2-LD trigger, indicating that it should stop attempting to send data to the MN.
5. Upon receiving a L2-LU trigger, the MN completes a normal registration with the HA, the HA sends the buffer followed by the new data to the MN. Normal operation resumes.

4.2.  Network without FA to Network without FA

When a MN moves from a network without FA to another NwoFA, POST-REGISTRATION is impossible as the HA cannot receive a L2 trigger. PRE-REGISTRATION messages can however be used to inform the HA that it needs to buffer. The message exchange is depicted in Figure 5:

   MN                    HA
   |                     |
   |------RtSolPr------->|
   |<-----PrRtAdv--------|
   |                     |
   |------RegRequest---->|<~buffer
   |                     |
   |<--RegReply(error)---|
   |                     |
disconnect               |
   |                     |
   |                     |
   |                     |
connect                  |
   |                     |
   |-------RegRequest--->|
   |<------RegReply------|
   |<================ deliver packets
   |                     |

1. Upon receiving an L2 trigger (L2-MT), the MN sends a PrRtSol message to the HA containing an identifier for the new network, in a Generalized Link Layer and IP Address Extension. This message MUST have a TTL=1. When received by the HA, it MUST reply with a PrRtAdv with the nFAs IP address set to 0.0.0.0 (indicating that the oFA doesn’t have a neighbour for that network). The LLA Extension MUST be identical to the one sent in the PrRtSol message.
2. The MN sends a registration request to the HA, with the care of address field set to 0.0.0.0. The registration request MUST also contain the address of the HA in an FA IPv4 address LLA extension.
3. Upon receiving the registration reply, the HA starts buffering, and sends back a registration reply with error code 77 (invalid care-of address). If it cannot buffer, it sends a registration reply with error code 66 (insufficient resources) [rfc3344] (Perkins, C., “IP Mobility Support for IPv4,” August 2002.).
4. The MN disconnects from the HA, reconnects to it on the new network, and completes a normal registration with the HA
5. When the registration with the HA is completed, it sends the buffer followed by normal communication.

4.3.  Network without FA to Network with FA

This movement uses the PRE-REGISTRATION handover system, with the HA in the role of the oFA. Since there is no oFA, it is unlikely that there can be a source triggered handover, but a target triggered handover and a mobile triggered handover are possible. The mechanism is described in figure 6:

    MN                     HA                  nFA
     |                     |                    |
     |                     |------PrRtSol------>|
     |                     |<-----PrRtAdv-------|
     |                     |                    |
     |-------PrRtSol------>|                    |
     |<------PrRtAdv-------|                    |
     |                     |                    |
     |-----------RegReq (tunneled via HA)------>|
     |                     |<------ RegReq------|
     |                     |----- RegReply----->|<~buffer
     |                     |                    |
     |                   forward                |
     |                   packets===============>|
disconnect                 |                    |
     |                     |                    |
 connect                   |                    |
     |                     |                    |
     |-----------Agent Solicitation------------>|
     |<=================================== deliver packets
     |                     |              (including RegReply)
     |                     |                    |

1. The HA sends a PrRtSol message to the nFA, to which the nFA MUST respond with a PrRtAdv if the message contained the correct identifier in the LLA extension. These messages SHOULD be sent in advance of the actual handover, as the HA SHOULD try to solicit and cache agent advertisements for all FAs of which it is aware. In case of a target triggered handover, a message PrRtAdv is tunnelled from the nFA directly to the MN (through the HA). In that case the message MUST be authenticated (with an FA-MN authentication) to prevent attacks.
2. The MN sends a PrRtSol message to the HA containing an identifier for the nFA, in a Generalized Link Layer and IP Address Extension. This message MUST have a TTL=1. When received by the HA, it MUST reply with the nFA’s PrRtAdv.
3. The MN sends a registration request (RegReq) to the nFA, tunnelled via the HA.
4. The nFA sends a RegReq to the HA. The message MUST contain the MN’s layer 2 address in a Generalized Link Layer and IP Address Extension.
5. The HA sends a RegReply to the nFA, which MUST be buffered and unicast to the MN as soon as the MN connects to the nFA. The nFA SHOULD also buffer all data received from the HA to the MN until the connection is achieved before unicasting it to the MN.
6. The MN disconnects, reconnects, and sends an agent solicitation.
7. The nFA forwards the RegReply and buffer to the MN as soon as it receives either the agent solicitation, or a L2-LU message that the nFA can resolve to the MN.

The ‘S’ bit MAY be set in the registration message from the MN (in 3), in which case all data is sent both to the nFA and to the MN. In this case, buffering by the nFA may not be necessary, or even beneficial.

The situation with POST-REGISTRATION methods is depicted in figure 7:

         MN                    nFA                  HA
          |                     |                    |
          |           L2-TT ~~~>|-------HRqst------->|
          |                     |<------HRply--------|
          |             buffer~>|<================ deliver packets
          |                     |                    |
       disconnect     L2-LD ~~~>|                    |
          |                     |                    |
          |                     |                    |
          |                     |                    |
       connect                  |                    |
          |<==deliver packets==>|<~~~ L2-LU          |
L2-LU ~~~>|--------- RegRequest--------------------->|
          |<-------- RegReply------------------------|
          |<=================================== deliver new packets
          |                     |                 (via nFA)
          |                     |                    |

1. The nFA receives a L2 Target Trigger informing it that the MN is about to move to its network. The trigger contains the MN’s L2 address, its home address, the address of its home agent, and an identifier for the old network. The nFA is unable to resolve the identifier to an oFA IPv4 address.
   
   In order for the following messages to be transmitted, there MUST be a security association between the nFA and the HA. All messages between those agents MUST be authenticated with a HA-FA authentication extension [rfc3344] (Perkins, C., “IP Mobility Support for IPv4,” August 2002.).
2. The nFA sends a Handover Request to the HA with the N bit set, and the H and R bit unset, indicating that it is an HRqst(t). The B bit MUST also be unset. If the T bit is set, the nFA is also requesting a reverse tunnel, and the lifetime field indicates the desired duration for the tunnel, the recommended time is 2 seconds (a value of 0xffff indicates infinity). If the T bit is unset, the lifetime must also be set to 0, indicating that the nFA doesn’t require reverse tunnel service. The home address and address of the home agent are included as they were obtained through the L2-TT. The HRqst(t) also contains an LLA option with the MN's L2 address.
3. The HA sends a HRply, with the N bit set, and the H and R bits unset, indicating that it is a HRply(t). Setting the T bit indicates that the HA is willing to tunnel information in advance to the nFA, and the lifetime field indicates how long the HA is willing to maintain the tunnel before requiring a RegRequest. If the T bit is unset, the lifetime MUST be 0, indicating that the HA is unwilling to provide tunnel service. 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.
   
   If the tunnel established at this point expires before the handover is complete, the nFA MAY transmit a HRqst(r) to renew the tunnel. The descriptions of the fields are identical to those described in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.).
4. The MN disconnects from the old network, and reconnects on the new one. Upon receiving a L2-LU, the nFA sends its buffered data, followed by new data from the HA. It also transmits outbound data either with normal routing mechanisms, or with a reverse tunnel.
5. Upon receiving a L2-LU trigger, the MN completes a normal registration with the HA. Registration should be completed as soon as possible, in order to have a situation where the MN can use normal fast-handover procedures.

5.  Handover Using RFC 4988 Mechanisms

This section details the better than nothing fast handover protocol as described in Section 3.1 (Predictive Handover) using the same messages and message patterns as in [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.).

5.1.  Network with FA to Network without FA

Figure 8 shows the timeline for the predictive mode of operation:

  MN                    oFA                  HA
   |                     |                    |
   |------RtSolPr------->|                    |
   |<-----PrRtAdv--------|                    |
   |                     |                    |
   |------FBU----------->|--------HI--------->|
   |                     |<------HAck---------|
   |          <--FBack---|--FBack--->         |<~buffer
   |                     |                    |
disconnect               |                    |
   |                     |                    |
   |                     |                    |
   |                     |                    |
connect                  |                    |
   |                     |                    |
   |--------- RegRequest--------------------->|
   |<-------- RegReply------------------------|
   |<=================================== deliver packets
   |                     |              (including FBack)

1. MN sends a RtSolPr message (either containing the wildcard, or with the identifiers of the access points it wishes move to).
2. The oFA responds with a PrRtAdv with code 2 or code 3. If the message is sent unsolicited by the oFA, its code is 4. The LLA options for unknown access points have code 7.
3. The MN sends an FBU to the oFA. The CoA field MUST contain the Home Agent’s IP address when attempting to connect to a NwoFA.
4. The oFA sends a HI message to the HA. The ‘S’ bit MUST be set to 0 and the ‘U’ bit MUST be set to 1. The New Care-of Address option MUST NOT be present.
5. The HA responds with a HAck. Valid options are 0, 128, 129 or 130. Other options (1-4) are treated as if option 0 was received.
6. The oFA sends an Fback to the MN and the HA, the new IPv4 extension MUST NOT be present. The HA MUST buffer messages from this point until receiving a registration message from the MN, although it MAY drop packets due to space limitations or buffer management.
7. Upon receiving the Fback, the MN disconnects, and reconnects to the new network. Upon receiving a new IP address, it completes normal registration procedure to the HA (RegRequest and RegReply). The MN doesn’t send an FBU as it would when communicating with a nFA.
8. The HA forwards buffered messages (including the FBack) to the MN. Normal operation resumes.

5.2.  Network without FA to Network without FA

Figure 9 shows the timeline for the predictive mode of operation:

   MN                    HA
   |                     |
   |------RtSolPr------->|
   |<-----PrRtAdv--------|
   |                     |
   |------FBU----------->|
   |                     |
   |          <--FBack---|<~buffer
   |                     |
disconnect               |
   |                     |
   |                     |
   |                     |
connect                  |
   |                     |
   |-------RegRequest--->|
   |<------RegReply------|
   |<================deliver packets
   |                 (including FBack)

1. MN sends a RtSolPr message with the identifiers of the access points it wishes move to. The wildcard option is not used in this situation, as the MN realises it is not attached to an FA and can’t expect the HA to know in which neighbourhood the MN is currently moving in.
2. The HA responds with a PrRtAdv with code 2 or code 3 (codes 0, 1 and 4 are irrelevant). The LLA options for unknown access points have code 7.
3. The MN sends an FBU to the HA. The CoA field MUST contain the Home Agent’s IP address when attempting to connect to a NwoFA.
4. The HA sends an Fback to the MN, the new IPv4 extension MUST NOT be present. The HA MUST buffer messages from this point until receiving a registration message from the MN, although it MAY drop packets due to space limitations or buffer management.
5. Upon receiving the Fback, the MN disconnects, and reconnects to the new network. Upon receiving a new IP address, it completes a normal registration procedure to the HA (RegRequest and RegReply). The MN doesn’t send an FBU as it would when communicating with a nFA.
6. The HA forwards buffered messages (including the FBack) to the MN. Normal operation resumes.

5.3.  Network without FA to Network with FA

Figure 10 shows the timeline for the predictive mode of operation:

   MN                     HA                  nFA
    |                     |                    |
    |------RtSolPr------->|                    |
    |<-----PrRtAdv--------|                    |
    |                     |                    |
    |------FBU----------->|--------HI--------->|
    |                     |<------HAck---------|
    |          <--FBack---|--FBack--->         |<~buffer
    |                     |                    |
disconnect              forward                |
    |                   packets===============>|
    |                     |                    |
    |                     |                    |
connect                   |                    |
    |                     |                    |
    |--------- FBU --------------------------->|
    |<=================================== deliver packets
    |                     |              (including FBack)
    |                     |<-----FBU-----------|
    |-----RegRequest----->|                    |
    |<----RegReply--------|                    |

1. MN sends a RtSolPr message with the identifiers of the access points it wishes move to. The wildcard option is not used in this situation, as the MN realises it is not attached to an FA and can’t expect the HA to know in which neighbourhood the MN is currently moving in.
2. The HA responds with a PrSolAdv with code 1 or code 3 (codes 0, 2 and 4 are irrelevant).
3. The MN sends a FBU to the HA. The CoA field MUST contain the nFA IP address.
4. The HA sends a HI to the nFA, the S bit MAY be set to 1, and the U bit MUST be set to 1.
5. The nFA responds with a HAck.
6. The HA sends an FBack to the nFA and the MN.
7. The MN disconnects, reconnects, and if necessary obtains an IP address.
8. The MN sends an FBU to the nFA, which delivers buffered packets including the Fback.
9. The nFA forwards the FBU to the HA, with the source and destination IP fields containing the addresses of the nFA and HA respectively. This message is sent only for consistency purposes, and should be silently discarded by the HA.
10. The MN registers with the HA, and normal operation resumes.

6.  Security Considerations

6.1.  NAT Considerations

A FA that supports fast handover MUST either have a public address or, if it really must be behind a NAT, there MUST be a mechanism whereby all mobile IP traffic is relayed to the FA. A simple way to accomplish this may simply be to forward all traffic on UDP port 434 to the FA, but mechanisms such as STUN [rfc3489] may also be used. In any case, a FA behind a NAT MUST implement [rfc3519], in which case all fast handover registration messages must carry either the UDP Tunnel Request or UDP Tunnel Reply extension.

6.2.  Security associations

In addition to the mobile IP communications defined in [rfc3344] (Perkins, C., “IP Mobility Support for IPv4,” August 2002.), fast handovers (as defined in [rfc4881] (El Malki, K., “Low-Latency Handoffs in Mobile IPv4,” June 2007.), [rfc4988] (Koodli, R. and C. Perkins, “Mobile IPv4 Fast Handovers,” October 2007.) and this document) feature extra messages that are solely between the FA and HA or in between two FAs. In order to prevent attacks such as traffic redirection and denial of service, those messages MUST be secured. However, having a security association between FAs and HAs may be problematic. For local communications, such as between neighbouring FAs, or for mobile IP elements belonging to a same organisation, the security association may simply be a statically input shared secret. However, this documents stipulates that the HA must be able to dynamically discover and create security associations with FAs (Section 3 (Protocol)). The CARD protocol [rfc4066] (Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, “Candidate Access Router Discovery (CARD),” July 2005.) already describes how its security associations are to be implemented, but other possible methods include using IKEv2 [rfc4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) or an AAA infrastructure such as Diameter [rfc3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” Septemper 2003.) whose use is specified in relation to mobile IPv4 (as described in [rfc4004] (Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, “Diameter Base Protocol,” August 2005.)).

7.  IANA Considerations

This document does not allocate any numbers, so there are no IANA considerations.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, 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.