One document matched: draft-ietf-mobileip-fast-mipv6-00.txt
Personal G. Tsirtsis
Editor
A. Yegin
C. Perkins
G. Dommety
K. El-Malki
M. Khalil
Internet Draft
Title: draft-ietf-mobileip-fast-mipv6-00.txt
Category: Informational February 2001
Expires : July 2001
Fast Handovers for Mobile IPv6
<draft-ietf-mobileip-fast-mipv6-00.txt>
Status of This Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
This document specifies protocol enhancements to MIPv6 that enable
mobile nodes to more quickly become connected at new points of
attachment to the Internet. These protocol enhancements are intended
to minimize the time during which the mobile node is unable to send
or receive IPv6 packets (i.e., the handover latency).
Design Team 1
Internet Draft Fast Handovers for MIPv6 February 2001
1. Introduction
This draft presents the initial output of the MIPv6 Design Team on
Fast Handovers with Mobile IPv6.
The design decision has been taken not to consider scenarios in which
the handover cannot be initiated until the mobile node has layer-2
connectivity to the new access router, since these are covered
adequately by the base Mobile IPv6 Specification [MIPv6].
In scenarios which the handover can be initiated while the mobile
node still has layer-2 connectivity at the previous access router,
another design decision has been taken. Since this specification
deals with layer-3 issues, the handover is considered to require
some layer three information relevant to the new access router.
Specifically, the handover at layer 3 requires a new care-of
address on the new link, as well as prefix lifetime information and
possibly other link parameters typically advertised by the new access
router. In parallel the acquisition of this new care-of address
should be performed in away that a duplicate or invalid address can
not be picked and in the rear case that it does the system to be able
to recover gracefully.
Situations where the mobile node would be expected to acquire this
information from advertisements from the new access router while
still maintaining layer-2 connectivity with the previous access
router are excluded from consideration in this specification.
Otherwise, the protocol would actually become a special case of again
the base MIPv6 specification.
2. Protocol Overview
The aim of this protocol is to enable the MN to configure a newCOA
before it moves to a newAR in a way that can use this newCOA
immediately at connection with newAR. The areas of preparation are
newCOA configuration, Duplicate Addressing avoidance and Neighbor
Discovery.
The pictured model provides standard terminology, standard behavior,
standard messages, and standard message semantics that enable fast
handover behavior with minimal interruption to packets flowing to a
mobile node as it moves. This model applies both to networks in
which the network determines that a handover will take place and to
networks in which the mobile determines that a handover will take
place. The model also preserves the Mobile IP characteristic of
having the mobile making the ultimate determination of whether
traffic destined to it is diverted to its new point of attachment.
Design Team 2
Internet Draft Fast Handovers for MIPv6 February 2001
MN oldAR newAR
| | |
|-----RtSolPr-------->| |
| | |
|<------PrRtAdv-------| |
| |--------HI--------->|
|----------BU-------->| |
|<---------BACK-------|<-------HACK--------|
| forward |
| packets===============>|
| | |
|--------------------NA-----------> |
| | deliver
|<=====================================Packets
Figure 1: General Framework.
Fast handover is implemented by adding 4 new messages which are
implemented between access routers and between an access router and a
mobile node. An access router is the last router between the network
and the mobile node. From the point of view of an upcoming handover,
the old Access Router (oldAR) is the router to which the mobile node
is currently attached (mobile's default router) and the new Access
Router (newAR) is the router to which the mobile node is about to
move.
The following messages are used in this specification and are defined
in detail in later sections:
- Router Solicitation for Proxy (RtSolPr) - MN to oldAR
- Proxy Router Advert (PrRtAdv) - oldAR to MN
- Handover Initiate (HI) - oldAR to newAR
- Handover Ack (HAck) - newAR to oldAR
- Binding Update (BU/BACK) - as defined in [MIPv6] + some flags
The behavior of the entities involved in the exchange are described
as follows.
To initiate a fast handover the mobile node sends a Router
Solicitation for Proxy to the oldAR indicating that it desires to
implement a fast handover to a new attachment point. The Router
Solicitation Proxy contains some form of identifier to indicate the
new attachment point. It will receive in response a Proxy Router
Advertisement message from the oldAR with a set of possible responses
indicating that the point of attachment is unknown, the point of
attachment is known and is connected through the same access router,
or is known and here is the prefix (or care-of-address) you should
Design Team 3
Internet Draft Fast Handovers for MIPv6 February 2001
use to form your new care-of-address (COA). The mobile node sends a
Binding Update using its newly formed COA as the last message before
it executes the handover. The mobile node then receives a Binding
Acknowledgement either through the oldAR or the newAR indicating that
the binding was complete. Whenever a mobile node moves to the newAR
it sends the Neighbor Advertisement to initiate the flow of packets
that may be waiting there for the mobile.
The oldAR can also initiate a handover for the mobile node using the
same messages. In this case the mobile node receives a Proxy Router
Advertisement with a new prefix (or care-of-address) indicating that
the mobile is about to be moved. The mobile responds by sending a
Binding Update to the oldAR with its new care-of-address. The mobile
receives a Binding Acknowledgement indicating that the handover is
complete.
The MN needs to be prepared for a number of error conditions. It may
not receive a response to an initial RtSolPr in which case it needs
to resend it. It also may not receive a response to its Binding
Update in which case it needs to sends a Neighbor Advertisement to
the newAR. If it does not receive its BACK at this point, the
Binding Update never got to the old access router and the Binding
Update needs to be resent.
The oldAR communicates with the MN using the exchange of packets
described above. If the mobile node is initiating the handover it
will receive a Router Solicitation Proxy with some access network
information. It will respond to this in one of three ways. If it
does not understand the access network information it will respond
saying that the access network information is unknown. If the oldAR
understands the access network information but realizes that the
access network information provided uses the same access router it
will respond that the mobile node will continue to use the same
access router. If the oldAR recognizes the access network
information but realizes it uses a different access router, it will
respond with a care-of-address or prefix for the new Access Router.
The oldAR MUST wait for a Binding Update from the MN before actually
forwarding packets. The oldAR sends a Binding Update acknowledgement
message to the mobile node through the temporary tunnel that is
constructed and to the mobile node over its old link.
If the oldAR is initiating the handover, it will begin the exchange
by using the Proxy Router Advertisement informing the MN of the new
care-of-address that will be used to deliver packets to it. The
oldAR MUST wait for a Binding Update from the MN before actually
forwarding packets. The oldAR sends a Binding Acknowledgement message
to the mobile node through the temporary tunnel that is constructed
and to the mobile node over its old link.
In addition to the exchange with the MN the oldAR exchanges
information with the newAR to facilitate the forwarding of packets
between the two and reduce the latency perceived by the MN during the
handover. The oldAR sends a Handover Initiate (HI) message to the
Design Team 4
Internet Draft Fast Handovers for MIPv6 February 2001
newAR with the requested care-of-address on the newAR and the care-
of-address being used currently at the oldAR. The oldAR receives in
response a Handover Acknowledgement (HACK) message either accepting
or rejecting the new care-of-address. If the new care-of-address is
accepted, the oldAR sets up a temporary tunnel to forward packets
destined for the mobile to the new care-of-address on the newAR. If
the new care-of-address is rejected by the newAR, the oldAR sets up a
temporary tunnel to forward packets destined for the mobile to the
old care-of-address which will be temporarily hosted on the newAR.
In either case the oldAR does not forward packets until it has
received a Binding Update from the MN.
In the case of stateful address allocation, the HI/HACK exchange
needs to be completed before the Proxy Router Advertisement is sent
to the mobile node.
The newAR also exchanges messages with the oldAR and forwards
messages between the oldAR and the MN. When the newAR receives an HI
message without a new COA it allocates a new COA and sends it to the
oldAR in the HACK message. When the newAR receives an HI message
with a new COA it determines whether the newCOA is valid and sends an
indication in the HACK message. If a valid newCOA is returned to the
oldAR the newAR will be receiving packets for the MN with a valid
newCOA and will just forward them as normal to the MN. If no valid
newCOA is determined, the newAR will record the oldCOA, de-tunnel the
packets received in the tunnel from the oldAR and deliver them to the
MN.
The newAR will deliver packets to the MN when it receives an
indication from the access network that it can begin sending packets
to the MN or when it receives a neighbor advertisement from the MN,
also an indication that it can send packets to the MN.
The following summarizes the semantics of the messages.
The Router Solicitation for Proxy is always an indication to the
oldAR that the MN would like to perform a handover and is requesting
information to enable the handover to be performed with minimal
interruption.
The Proxy Router Advertisement is an indication that the MN should go
ahead and move and it provides the prefix or address to be used on
the New AR. If the handover is mobile determined it provides
information about whether the handover will involve moving to a new
AR. If the handover is network determined it provides the indication
that the mobile is about to be moved and the information that it will
be using in the newAR. In network determined handover, failure to
conform with the Proxy Router Advertisement may result in loss of
service.
The Binding Update indicates the Binding that the mobile node wants
the oldAR to make. It also indicates to the network that the mobile
is moving and that it wants its packets forwarded.
Design Team 5
Internet Draft Fast Handovers for MIPv6 February 2001
The Binding Update Ack indicates whether the Binding Update was
successful. A negative acknowledgement may indicate that the newCOA
is invalid or that the Binding Update failed for any of the standard
reasons.
The Handover Initiate Message indicates the oldAR is trying to
facilitate a fast handover to the newAR and the oldCOA that will be
used in the case that the requested address negotiation between the
routers fail.
The Handover Ack Message indicates what the newCOA should be in the
new Router.
3. Supported scenarios
The framework described above applies to two main network scenarios.
A Network Determined Handover scenario were the network is
responsible for moving the mobile node from one attachment point to
another and a Mobile Determined Handover scenario were the mobile
itself has to define and initiate the handovers.
In either case the ultimate decision is on the mobile, in that no
routing change (no redirection of packets) takes place unless the MN
confirms the handover with a Binding Update to the old Access Router.
3.1. Network Determined Handover
In this scenario both stateless and stateful care of address
configuration is supported.
3.1.1. Stateless new Care-of-Address Configuration
When the oldAR realizes (or gets notified) that a MN must move to a
newAR it compiles a newCOA based on the MN's Interface ID and the
newAR's Prefix. It then sends this newCOA to the MN together with the
NewAR IP address and Link Layer Address using the PrRtAdv message. At
the same time the oldAR sends the HI message to the newAR indicating
the MN's oldCOA as well as the newly created newCOA.
The newAR first establishes whether the newCOA is a valid address
performing checks to ensure that it is not a duplicate. If the newCOA
is legal and acceptable to the newAR it adds it to the Neighboring
Cash for a short time period so it can defend it and it responds with
an HACK. If the newCOA is not valid (e.g.: used by other node) the
newAR adds a host route for the oldCOA pointing to its mobility
interface, for a short time period and responds to the oldAR with a
HACK (newCOA not valid).
Design Team 6
Internet Draft Fast Handovers for MIPv6 February 2001
MN oldAR newAR
| | |
|<------PrRtAdv-------|--------HI--------->|
|--------BU---------->|<-------HAck--------|
Disconnect <--BACK--|--BACK--> |
| | |
| forward |
| packets===============>|
| | |
|--------------------NA-----------> |
| | deliver
|<=====================================Packets
Figure 2: Network Determined and Stateless
If the HACK indicates the newCOA is valid the oldAR will get ready to
forward packets for this MN to its newCOA. If the HACK indicates the
newCOA is not valid the oldAR will get ready to forward packets for
this MN to the newAR.
The oldAR will only change its routing regarding an MN after it
receives a BU from the MN confirming the handover. This BU SHOULD be
sent (if permitted by the link layer conditions at handover time) to
the oldAR while the MN is still connected to the oldAR. If this is
not possible the BU MUST be sent after the MN connects to the newAR.
The oldAR MUST then send a BACK message to the MN both locally and by
way of newAR (using the newCOA or the newAR as encapsulating address)
On reception of the BU and providing the HACK has also been received,
the oldAR can start forwarding packets destined to the MN's oCOA to
either the newCOA or the newAR, depending of the HACK value.
Additionally, and if the link layer supports such indications, the
oldAR MAY delay the routing change until it determines that the MN
has disconnected. Now the oldAR acts as a Home Agent with home
address being the MN's oldCOA and care-of-address being either the
MN's newCOA or the newAR address.
The MN MUST NOT use the newCOA address as source address until it
receives a BACK from the oldAR. The BACK may be received while the MN
is still connected to the oldAR in which case the MN will only have
to announce itself to the newAR to get full connectivity. In the case
were the BACK was sent but not received at the oldAR, there will be a
copy of it waiting for the MN at the newAR. If the BACK is not
received at all the MN should assume the BU was not received by the
oldAR and it MUST resent the BU to the oldAR.
Design Team 7
Internet Draft Fast Handovers for MIPv6 February 2001
3.1.2. Stateful new Care-of-Address Configuration
An alternative message sequence has HI/HAck message exchange proceeds
the PrRtAdv message send from the oldAR to the MN. This provides a
way to retrieve the correct contents for the PrRtAdv from the newAR
when this information is not available to the oldAR by other means.
MN oldAR newAR
| | |
| |--------HI--------->|
| |<-------HAck--------|
|<------PrRtAdv-------| |
| | |
Figure 3: Network Determined and Stateful
The rest of the process is identical to the stateless approach
3.2. Mobile Determined Handover
The main difference between this and the Network Determined approach
is that here the mobile node MUST send a Router Solicitation for
Proxy message to the oldAR and trigger the Proxy router
Advertisement.
In the RtSolPr message the MN indicates the Link Layer address or the
Identifier of the Attachment Point that it wants to attach to. The
oldAR will then reply with a PrRtAdv which contains the same
information with the stateless approach of Network Determined
approach.
MN oldAR newAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------|--------HI--------->|
|--------BU---------->|<------HACK---------|
Disconnect <--BACK--|--BACK--> |
| | |
| forward |
| packets===============>|
Connect | |
|------------------NA-------------> |
| | Deliver
|<=====================================Packets
Figure 4: Mobile Determined
Design Team 8
Internet Draft Fast Handovers for MIPv6 February 2001
The rest of the behavior is the same in that the newCOA is sent to
the newAR for validation using the HI/HACK sequence and the oldAR
does not changes its routing regarding the mobile in question unless
it receives a Binding Update from it, and depending on the link layer
until the MN disconnects, while the MN does not use the newCOA until
it receives a BACK. After all this is done, as before, the oldAR acts
as a Home Agent with home address being the MN's oldCOA and care-of-
address being either the MN's newCOA or the newAR address.
3.3. Sending Binding Updates at the New Access Router
When the mobile node move to a new access router, it needs to send a
Binding Update to its home agent. It also may need to send a Binding
Update to its old access router, unless it has a positive indication
that the old access router already has made the appropriate binding
cache modifications. The typical form of such a positive indication
is a Binding Acknowledgement send from the old access router to the
mobile node; if the mobile node expects but does not receive the
acknowledgement, then it must effectively carry out the
retransmission algorithm for Binding Updates, as specified in
[MIPv6].
In this section, it is considered that all necessary link
establishment details have been completed. This may possibly include
Duplicate Address Detection, and/or reception of a Router
Advertisement from the new access router. Those events may not
always have to occur, and when they are needed they must have
occurred before the transmission of Binding Updates messages.
When the new access router receives any packet from the mobile node
to be forwarded elsewhere, it means that the mobile node considers
the new access router to be its default router, and thus that link
establishment is complete from the point of view of the mobile node.
If the Binding Acknowledgement was received, then the mobile node
only has to send the Binding Update to its home agent. In that case,
that Binding Update would be sent through the mobile node's default
router--that is, the new access router.
If on the other hand the mobile node has not yet received a Binding
Acknowledgement from the old access router, then the mobile node
SHOULD arrange for oldAR to receive an appropriate Binding Update
associating the mobile node's new care-of address to its new care-of
address (as specified in [MIPv6]). Therefore, we specify that if the
mobile node knows the address of the newAR, it should first send any
necessary Binding Update packet to its old access router, before
sending the Binding Update packet to its home agent.
Furthermore, alternative encapsulation strategies, which would allow
both Binding Update options to be sent with a single transmission
Design Team 9
Internet Draft Fast Handovers for MIPv6 February 2001
over the air from the mobile node, are the subject of current
discussion in the design team.
If the mobile node does not know the address of the new access
router, Neighbor Discovery will have to take place before the Binding
Update is send.
In some circumstances, packets sent by the mobile node to the
previous access router just before handover may have been dropped.
If this information contained directives to the oldAR to initiate the
smooth handover, the new access router may not have taken any steps
to speed up the handover before the mobile node arrives. In this
case, the mobile node may assume that the new access router is ready
to provide connectivity, and then send a Binding Update through the
new access router before Duplicate Address Detection has been
accomplished for the new care-of address. In this case, the new
access router is expected to send a (perhaps newly defined) ICMP
message back to the mobile node. After taking care of the necessary
processes to protect its link-local address on the network at the
new point of attachment, the mobile node MAY resend the same Binding
Update packet(s) to the new access router, and/or home agent without
any recalculation.
3.3.1. Features enabling Partial Handover Optimization
The following features are related, and yet able to be separated, and
enable various facets of connectivity between the mobile node and the
new access router.
1. The mobile node may be able to discover the IP address of the new
access router
2. The mobile node may be able to discover the MAC address of the new
access router.
3. The mobile node may be able to direct the new access router to
ascertain the uniqueness of its new care-of address before
establishing connectivity with the new access router
4. The mobile node may be able to send a Binding Update to its
previous access router before breaking the previous connection
4a. The mobile node may be able to receive the Binding
Acknowledgement for the Binding Update sent to the old
access router before breaking the old connection.
4b. The mobile node may fail to receive the Binding Acknowledgement
for the Binding Update sent to the previous access router before
breaking the old connection.
Design Team 10
Internet Draft Fast Handovers for MIPv6 February 2001
All of these operations are possibly both in the network-determined
and the mobile-determined scenarios.
If (1), (2), and (3) hold, then the mobile node can begin to use the
new access router as its default router as soon as layer-2
connectivity is established. Thus, in this optimal circumstance,
any necessary Binding Updates can be delivered without any additional
delay as soon as the mobile node gets to the new network.
If any of (1), (2) or (3) do not hold, then the mobile node is
required to perform some combination of Neighbor Discovery and
Duplicate Address Detection when it arrives at the new access
router's area.
For all of cases 4, 4a, 4b, a simple rule is effective. If the
mobile node does not receive a Binding Acknowledgement for the
Binding Updates that it has sent, then it MUST retransmit those
Binding Updates according to the retransmission algorithm specified
in the base Mobile IPv6 document.
4. Message Extension and Option Formats
In this section, message and option formats are specified. The
description for each message extension and option will specify which
message or option it may be used with.
4.1. Router Solicitation for Proxy (RtSolPr)
Hosts send Router Solicitation for Proxy in order to prompt routers
for Proxy Router Advertisements.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
An IP address assigned to the sending interface
Destination Address
The address of the Access Router
Hop Limit 255
Design Team 11
Internet Draft Fast Handovers for MIPv6 February 2001
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type TBA
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Identifier MUST be set by the sender so replies can be matched
to this Solicitation.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
Source link-layer address
The link-layer address of the sender, if known.
It SHOULD be included on link layers that have
addresses.
New attachment point link-layer address
The link-layer address or identification of the
attachment point the mobile node requests routing
advertisement information for. It MUST be included
in all RtSolPr messages.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message.
Description
The mobile node MUST sends this message if it wants to
initiate a fast handover. It indicates its destination
with the New Attachment Point Link-Layer Address. A
PrRtAdv message should be received in response. If such
message is not received in a short time period but no less
than 2 times the typical round trip time (RTT) over the
access link or 100msec if RTT is not known, it SHOULD
resend it once or at the most twice (after the same
waiting time). If the PrRtAdv is not received by the time
the mobile node disconnects from oldAR, Fast Handover can
Design Team 12
Internet Draft Fast Handovers for MIPv6 February 2001
not be performed and the mobile node SHOULD revert back to
normal MIPv6.
4.2 Proxy Router Advertisement (PrRtAdv)
Routers send out Router Advertisement message unsolicited if the
network is controlling the handover or in response to a Router
Solicitation for Proxy message from a mobile node.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
MUST be the link-local address assigned to the
interface from which this message is sent.
Destination Address
The Source Address of an invoking Router
Solicitation for Proxy or the address of the node
the Access Router is instructing to handover.
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type TBA
Code 0 - Handover Information
1 - No change of COA required
2 - New Attachment Point not known
Checksum The ICMP checksum. See [ICMPv6].
Identifier Copied from Router Solicitation for Proxy or set to
Design Team 13
Internet Draft Fast Handovers for MIPv6 February 2001
Zero if unsolicited.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
Source link-layer address
The link-layer address of the sender, if known.
It SHOULD be included on link layers that have
addresses.
Link-layer address of proxied originator
The link-layer address of the Access Router for
which this message is proxied for.
Prefix Information
These options specify the prefixes of the Access
Router the message is proxied for and are used
for address autoconfiguration.
New COA Option
In sateful configuration, this option MUST be sent
to allocate an address on behalf of the Access
Router this message is proxied for. In stateless
address auto-configuration this option may or may
not be sent.
If sent, indicates that the requesting node SHOULD
use this address as newCOA for the duration
of the handover. If not sent the requesting node
SHOULD compute the newCOA using the Interface ID
from the Destination Address of this message.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message.
Description
A PrRtAdv with Code 0 but without a New COA Option means
that the mobile node SHOULD construct a newCOA out of its
Interface ID (used in the Destination Address in this
PrRtAdv) and the Prefix in the Prefix Information Option.
A PrRtAdv with Code 0 and a New COA Option means that the
mobile node SHOULD use the COA indicated as a newCOA at
the new Access Router. This MUST used when Stateful COA
configuration is in use and MAY be used to help the oldAR
and MN calculate the same newCOA when Stateless COA
configuration is used.
Design Team 14
Internet Draft Fast Handovers for MIPv6 February 2001
A PrRtAdv with Code 1 is sent if handover to the New
Attachment Point, as indicated by the New Attachment Point
Link Layer address in the corresponding RtSolPr message,
does not require change of COA. No options required in
this case.
A PrRtAdv with Code 2 means that the oldAR is not aware of
the Prefix Information requested. The MN MUST give up its
attempt to perform fast handover to this new attachment
point. Normal MIPv6 MAY be used instead. No options
required in this case.
This message is sent once for every RtSolPr received.
4.3. Handover Initiation (HI)
The Handover Initiation message is a new ICMPv6 message sent by the
old Access Router to new Access Router to initiate the process of
Mobile Node's handover from one sub-network to another.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |S|U| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
The IP address of the Router sending this message
Destination Address
The IP address of the Router this message is sent
To.
Hop Limit 255
Authentication Header
A Security Association MUST exists between the
sender and the destination address. This messages
MUST be authenticated and so the authentication
header MUST be used when this message is sent
ICMP Fields:
Type TBA
Code 0
Design Team 15
Internet Draft Fast Handovers for MIPv6 February 2001
Checksum The ICMP checksum. See [ICMPv6].
Identifier MUST be set by the sender so replies can be matched
to this Solicitation.
S Stateful address configuration flag. When SET this
message requests a new COA to be returned by the
destination.
U Buffer flag. The destination SHOULD buffer any
packets towards the node indicated in the options
of this message.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
Link-layer address of mobile node
The link-layer address of the mobile node that is
being handed of to the destination. This options
SHOULD be included to help the destination
recognize the mobile node when it will be connected
to it.
Old Care of Address
The IP address used by the mobile node while
attached to the originating router. This option
MUST be included so packets to this mobile node can
be redirected to the destination even if the new
Care of Address is not acceptable.
New Care of Address
The IP address the mobile node wants to use when
connected to the destination. In Stateless
configuration this option indicates the new Care of
Address the mobile node will be using when
connected to the destination.
Description
If HACK message is not received as a response to this
message. the HI SHOULD be resent up to 4 times using a
short retransmission timer but no less than twice the
round trip time between source and destination or 100msec
if RTT is not known. Failure to receive an HACK means that
no fast handover can be performed.
The purpose of this message is to notify the newAR about
the upcoming handover and establish a valid newCOA for the
mobile node. If the S flag is SET this message requests an
Design Team 16
Internet Draft Fast Handovers for MIPv6 February 2001
address from the newAR to be assigned statefully. If the
new COA option is included the oldAR requests the newAR to
confirm that this is a valid newCOA.
4.4. Handover Acknowledgement (HACK) Message
The Handover Acknowledgement message is a new ICMPv6 message that
MUST be sent by the new Access Router to the old Access Router in
response to a Handover Initiate message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
Copied from the destination address of the HI
Message this message is in response to.
Destination Address
Copied from the source address of the HI
Message this message is in response to.
Hop Limit 255
Authentication Header
A Security Association MUST exists between the
sender and the destination address. This messages
MUST be authenticated and so the authentication
header MUST be used when this message is sent
ICMP Fields:
Type TBA
Code
0-Handover Accepted, newCOA valid
1-Handover Accepted, newCOA not valid
2-Handover Accepted, newCOA in use
3-Handover Accepted, newCOA assigned (Stateful)
4-Handover Accepted, newCOA not assigned (Stateful)
128-Handover Not Accepted, reason unspecified
Design Team 17
Internet Draft Fast Handovers for MIPv6 February 2001
129-Administratively prohibited
130-Insufficient resources
Checksum The ICMP checksum. See [ICMPv6].
Identifier Copied from the corresponding field in the HI
message this message is in response to.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
New Care of Address
If the S flag in the HI message is SET, this option
Is used to provide the new Care of Address the
mobile node should use when connected to this
router.
Description
On reception of HI the newAR MUST respond with an HACK. If
the S flag is SET in the HI, the newAR SHOULD include the
new Care of Address option and a Code of 3.
If the S flag is not SET in the HI, the newAR SHOULD check
the validity of the newCOA sent with the HI and reply
accordingly.
If the newCOA is valid and the handover the newAR SHOULD
insert the newCOA in its Neighbor Cash and defended on
behalf of the mobile for a short period of time of a
default value of 1 second in which period the mobile node
is expected to connect to the newAR.
If the newCOA is not valid or not assigned (Stateful) the
newAR SHOULD insert a host route, pointing to its mobility
interface the mobile node is expected to connect to, for
the mobile's oldCOA.
The newAR can always refuse the handover in which case it
should indicate the reason in one of the available Code
values.
4.5. IP Address Option
This section defines the IP Address Option, used by the ICMPv6
messages defined in this document. The extension format is based on
[MIER].
Design Team 18
Internet Draft Fast Handovers for MIPv6 February 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
3
Sub-Type
1 Old Care-of Address
2 New Care-of Address
Prefix Length
The Length of the IPv6 Address Prefix
IPv6 address
The IP address for the unit defined by the Type
field.
This option is sent in the Proxy Router Advertisement, the Handover
Initiate and Handover Acknowledgement messages. The PrRtAdv and HACK
messages only contain the newCOA while the HI message may include
both newCOA and oldCOA.
4.6. Link-layer Addresses (LLA)
This extension is based on the [MIER] format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Design Team 19
Internet Draft Fast Handovers for MIPv6 February 2001
Fields:
Type
TBA
Length
The length of the option (including the type, sub-type and
length fields) in units of 8 octets.
Sub-Type
1 for the Link-layer Address of the new Attachment Point.
2 for the Link-layer Address of the Mobile Node.
3 for the Link-layer Address of the Proxied Originator
LLA
The variable length link-layer address.
The content and format of this field (including byte and bit
ordering) is expected to be specified in specific documents
that describe how IPv6 operates over different link layers.
Description
The New Attachment Point Link Layer address contains the
link-layer address of the attachment point the mobile node
attempts to handover to. This is used in the Router
Solicitation for Proxy message.
The Mobile Node Link-Layer address option contains the link-
layer address of a mobile node. It is used in the Handover
Initiation message.
The Proxied Originator Link-Layer address option contains the
Link Layer address of the Access Router the Proxy Router
Solicitation message refers to.
These options MUST be silently ignored for other Neighbor
Discovery messages.
NOTE: Source and Target Link Layer Addresses as defined in [ND] MAY
also be used by Router Solicitation for Proxy and Proxy Routing
Advertisement messages.
4.7 Modified Binding Update Option
Two flags B, U are added to the flag bits in the Binding Update
Option. The mobile node sets the B flag in the Binding Update, to
indicate that the mobile node would like the AR to do bicasting. The
mobile node sets the U flag in the Binding Update to indicate that
Design Team 20
Internet Draft Fast Handovers for MIPv6 February 2001
the mobile node would like the AR to do buffering. Finally the AR MAY
honor the bicasting and buffering requests or reject them silently.
Thus, the Binding Update Option under Fast Handovers for Mobile IPv6
will show as below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|R|D|B|U|r|r| Prefix Length ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B The mobile node is requesting the AR to do bicasting.
U The mobile node is requesting the AR to do buffering.
r reserved and it MUST be set to 0.
The rest of the flag bits and the other fields are as defined in
[MIPv6].
Description
This message MUST be send by the mobile node to the old
Access Router so that the latter can redirect traffic to
the mobile node by the way of the new Access Router. The
message SHOULD be sent while the mobile node is still
connected to the oldAR and a BACK SHOULD be received at the
same place. If that is not possible, due to link layer
conditions, the BU MUST be send or resend at the newAR and
the BACK MUST be received before the mobile node can use
the newCOA. The initial retransmission timer for the BU in
this particular case should be very short but no less than
1.5 worst case RTTs of the link layer after the MN connects
to the newAR. The BU SHOULD be resent using exponential
backoff but only once or at most twice more. If that does
not yield a BACK the mobile node MUST give up the attempt
for a fast handover and revert back to normal MIPv6.
DISCUSSION: The design team has recently come to the conclusion that
a different TYPE should be used for the Fast Handoff BU and BACK
(maybe we will call the new messages FBU and FBACK). This new TYPE
would ensure that the oldAR will only make a routing change, after
reception of a FBU AND a HACK as opposed to the regular BU which does
not require a HACK. In an effort to catch the I-D submission
deadline, however, we have postponed this change for after the IETF
meeting.
Design Team 21
Internet Draft Fast Handovers for MIPv6 February 2001
5. Error Cases and other issues
In this section we are going to examine some common error cases that
may affect the performance and/or reliability of the mechanisms
described in this specification.
5.1. DAD handling
Duplicate Address Detection (DAD) was defined in [AUTO] to avoid
address duplication on links when stateless address auto-
configuration is used. The use of DAD to verify the uniqueness of a
statelessly configured IPv6 address may add delays to a MIPv6
handover.
The probability of an interface identifier duplication on the same
subnet can be considered very low, however it can not be ignored. In
this draft certain precautions are proposed to minimize the effects
of a duplicate address occurrence.
In some cases the new AR may already have the knowledge required to
assess whether the MN's address is duplicated or not, before the MN
moves to the new subnet. For example, the AR can have a list of all
nodes on its subnet (may be used for access control) and by searching
this list it can confirm whether the MN's address is duplicated. The
result of this search can be sent back to the old AR in the HAck
message.
If such knowledge is not available in the new AR, the MN would have
to perform DAD after moving to the new subnet. To avoid delays due to
performing DAD, it is suggested that the MN performs DAD while using
its oldCOA. This is possible since the framework described in this
specification allows packet redirection based on the oldCOA
encapsulated into the newAR IP address.
So, if the newAR cannot confirm the validity of the newCOA address
included in the HI message but is never the less willing to serve the
MN it can describe that in the HACK message and install a host route
towards its mobility interface regarding the MN's oldCOA.
The oldAR on reception of this type of HACK replies with a BUNACK to
the BU sent by the MN attempting to registers is newCOA. The oldAR
now forwards packets for this MN to the newAR which will decapsulates
and due to the host route installed earlier it can forward these
packets to the mobile.
The MN will at some point, either at the old or at the newAR receive
the BUNACK and thus attempt to get a newCOA. If the MN does not
receive the BACK or BUNACK at the oldAR and after connecting to the
newAR it still does not receive it in a short time frame (X sec) it
can assume that the BU was not received by the oldAR and it MUST
retransmit it. The source address used in this BU SHOULD be the
Design Team 22
Internet Draft Fast Handovers for MIPv6 February 2001
newCOA, which is not yet confirmed, to avoid ingress filtering. If
the newCOA is not valid the oldAR will send (or resend) a BUNACK to
the oldAR, encapsulated in the address of the newAR and thus it will
safely be received by the MN.
6. Security Considerations
The security needed for fast handover is almost the same as is
needed for handling Binding Updates in IPv6. If a handover could
be initiated by a node masquerading as the mobile node, a range of
undesirable effects might result. The malicious node could usurp
traffic destined from the mobile node, diverting it to a nearby
router and possibly an unauthorized care-of address. The exact
details of the possible effects would depend on the kinds of handover
data available as part of the fast handover process.
The Fast MIPv6 Handover proposal assumes that a security association
exists between the oldAR and the MN, as well as between the old and
newARs. Providing the above is true then, routing is only changes by
a BU from the MN, which MUST be authenticated. It is also highly
recommended that RtSolPr and PrRtAdv messages are also authenticated
since they are between oldAR and MN which have a security
association.
7. Acknowledgements
The Design Team would like to recognize Hesham Soliman's valuable
contribution to this work. Also, a warm thank you to Basavaraj Patil
and Phil Roberts for supporting this effort and the whole Mobile IP
WG for participating in the initial discussion.
References
[ASSNUM] J. Reynolds, J. Postel, Assigned Numbers, Request For
Comments (Standards Track) 1700. October 1994.
[AUTO] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998.
[EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997.
[IMSI] TIA/EIA/IS-95-B
[MAC] D. Plummer, "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address for
Transmission on Ethernet Hardware", RFC 826, November 1982.
Design Team 23
Internet Draft Fast Handovers for MIPv6 February 2001
[MIER] M.Khalil, R. Narayanan, H. Akhtar, E. Qaddoura, Mobile IP
Extensions Rationalization (MIER)(work in progress).
draft-ietf-mobileip-mier-05.txt, December 1999.
[MIPv6] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress). draft-ietf-mobileip-ipv6-12.txt, April 2000.
[ND] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola
6000 Connection Drive 1501 West Shure Drive
M/S M8-540
Irving, Texas 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com
The authors of this document are:
Alper Yegin, Sun Microsystems, Alper.Yegin@eng.sun.com
Charles E. Perkins, Nokia, charliep@iprg.nokia.com
George Tsirtsis, Flarion Technologies, G.Tsirtsis@flarion.com
Gopal Dommety, Cisco Systems, gdommety@cisco.com
Karim El-Malki, Ericsson, Karim.El-Malki@era.ericsson.se
Mohamed Khalil, Nortel Networks, mkhalil@nortelnetworks.com
Design Team 24
---------------------------------end--------------------------------------
| PAFTECH AB 2003-2026 | 2026-04-21 09:59:26 |