Internet DRAFT - draft-doswald-robert-mip4-btn-fmipv4
draft-doswald-robert-mip4-btn-fmipv4
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]
