[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
MIP4                                                     A. Doswald, Ed.
Internet-Draft                                                 S. Robert
Intended status: Experimental                                    HEIG-VD
Expires: October 10, 2008                                  April 8, 2008


             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.






Doswald & Robert        Expires October 10, 2008                [Page 1]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


Table of Contents

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



























Doswald & Robert        Expires October 10, 2008                [Page 2]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


1.  Introduction

   The mobile IPv4 specification [rfc3344] 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] and [rfc4988] 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] and
   rfc4988 [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, Section 4 presents the adaptations using [rfc4881]
   messages and protocol mechanisms, while Section 5 deals with
   handovers with the [rfc4988] scheme.  Finally, Section 6 addresses
   security considerations, and Section 7 addresses IANA considerations.

   Some concepts are common to [rfc4881] and [rfc4988], 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.  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].

   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]), corresponds to the PAR
      in rfc4988 [rfc4988].



Doswald & Robert        Expires October 10, 2008                [Page 3]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


      nFA: new Foreign Agent (as in [rfc4881]), corresponds to the NAR
      in [rfc4988].

      Handover: A process of terminating existing connectivity and
      obtaining new IP connectivity (as described in [rfc4988]),
      corresponds to "handoff" in [rfc4881].


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:

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

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

   o  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



Doswald & Robert        Expires October 10, 2008                [Page 4]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


   in [rfc4881] and [rfc4988].  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:

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

   o  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

                                 Figure 1

   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.



Doswald & Robert        Expires October 10, 2008                [Page 5]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


   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

                                 Figure 2





Doswald & Robert        Expires October 10, 2008                [Page 6]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


   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] it is the nFA (tunnelled via the
            HA)

       4b.  in the case of [rfc4988] 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.





Doswald & Robert        Expires October 10, 2008                [Page 7]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


   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], 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] or [rfc4988].


4.  Handover Using RFC 4881 Mechanisms

   This section details the better than nothing fast handover protocol
   as described in Section 3.1 using the same message patterns as in
   [rfc4881].  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] 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:







Doswald & Robert        Expires October 10, 2008                [Page 8]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


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

                                 Figure 3

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

   4.  The MN disconnects from the HA, reconnects to it on the new
       network, and completes a normal registration with the HA.





Doswald & Robert        Expires October 10, 2008                [Page 9]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


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

                                 Figure 4

   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



Doswald & Robert        Expires October 10, 2008               [Page 10]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


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

                                 Figure 5

   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.



Doswald & Robert        Expires October 10, 2008               [Page 11]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


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

   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)
            |                     |                    |

                                 Figure 6

   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



Doswald & Robert        Expires October 10, 2008               [Page 12]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


       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:
















Doswald & Robert        Expires October 10, 2008               [Page 13]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


             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)
              |                     |                    |

                                 Figure 7

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

   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



Doswald & Robert        Expires October 10, 2008               [Page 14]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


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

   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 using the same messages and message
   patterns as in [rfc4988].

5.1.  Network with FA to Network without FA

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




















Doswald & Robert        Expires October 10, 2008               [Page 15]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


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

                                 Figure 8

   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



Doswald & Robert        Expires October 10, 2008               [Page 16]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


       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)

                                 Figure 9

   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



Doswald & Robert        Expires October 10, 2008               [Page 17]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


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

                                 Figure 10

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



Doswald & Robert        Expires October 10, 2008               [Page 18]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


   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],
   fast handovers (as defined in [rfc4881], [rfc4988] 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.



Doswald & Robert        Expires October 10, 2008               [Page 19]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


   However, this documents stipulates that the HA must be able to
   dynamically discover and create security associations with FAs
   (Section 3).  The CARD protocol [rfc4066] already describes how its
   security associations are to be implemented, but other possible
   methods include using IKEv2 [rfc4306] or an AAA infrastructure such
   as Diameter [rfc3588] whose use is specified in relation to mobile
   IPv4 (as described in [rfc4004]).


7.  IANA Considerations

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


8.  References

8.1.  Normative References

   [rfc2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997,
              <http://www.ietf.org/rfc/rfc2119.txt>.

   [rfc3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002, <http://tools.ietf.org/html/rfc3344>.

   [rfc3519]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
              Network Address Translation (NAT) Devices", RFC 3519,
              April 2003, <http://tools.ietf.org/html/rfc3519>.

   [rfc3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, Septemper 2003,
              <http://tools.ietf.org/html/rfc3588>.

   [rfc4004]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
              P. McCann, "Diameter Base Protocol", RFC 4004,
              August 2005, <http://tools.ietf.org/html/rfc4004>.

   [rfc4066]  Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E.
              Shim, "Candidate Access Router Discovery (CARD)",
              RFC 4066, July 2005, <http://tools.ietf.org/html/rfc4066>.

   [rfc4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005,
              <http://tools.ietf.org/html/rfc4306>.

   [rfc4433]  Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4
              Dynamic Home Agent (HA) Assignment", March 2006,



Doswald & Robert        Expires October 10, 2008               [Page 20]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


              <http://tools.ietf.org/html/rfc4433>.

   [rfc4881]  El Malki, K., "Low-Latency Handoffs in Mobile IPv4",
              RFC 4881, June 2007, <http://tools.ietf.org/html/rfc4881>.

   [rfc4988]  Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
              RFC 4988, October 2007,
              <http://tools.ietf.org/html/rfc4988>.

8.2.  Informative References

   [rfc4068]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
              July 2005.


Authors' Addresses

   Alistair Doswald (editor)
   Haute Ecole d'Ingenieurie et de Gestion du Canton de Vaud
   Route de Cheseaux 1
   Yverdon-les-Bains, VD  1401
   CH

   Email: alistair.doswald@heig-vd.ch
   URI:   http://www.heig-vd.ch/


   Stephan Robert
   Haute Ecole d'Ingenieurie et de Gestion du Canton de Vaud
   Route de Cheseaux 1
   Yverdon-les-Bains, VD  1401
   CH

   Email: stephan.robert@heig-vd.ch
   URI:   http://www.heig-vd.ch/
















Doswald & Robert        Expires October 10, 2008               [Page 21]


Internet-Draft          BTN MIPv4 Fast Handovers              April 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Doswald & Robert        Expires October 10, 2008               [Page 22]