decoupled from the actual handover; see Section 6.1.2.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: "Predictive" Fast Handover
4. Protocol Details
All descriptions refer to Figure 1.
After discovering one or more nearby access points, the MN sends
RtSolPr to resolve access point identifiers to subnet router
information. This is convenient to do after performing router
discovery. However, the MN can send RtSolPr at any time, e.g., when
one or more new access points are discovered. The MN can also send
RtSolPr more than once during its attachment to PAR. The trigger for
sending RtSolPr can originate from a link-specific event, such as the
promise of a better signal strength from another access point coupled
with fading signal quality with the current access point. Such
events, often broadly referred to as "L2 triggers", are outside the
scope of this document. Nevertheless, they serve as events that
invoke this protocol. For instance, when a "link up" indication is
obtained on the new link, protocol messages (e.g., FNA) can be
immediately transmitted. Implementations SHOULD make use of such
triggers whenever possible.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU]-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
Figure 3: "Reactive" Fast Handover
The RtSolPr message contains one or more AP-IDs. A wildcard requests
all available tuples.
As a response to RtSolPr, PAR sends a PrRtAdv message that indicates
one of the following possible conditions.
1. If the PAR does not have an entry corresponding to the new access
point, it MUST respond indicating that the new access point is
unknown. The MN MUST stop fast handover protocol operations on
the current link. The MN MAY send an FBU from its new link.
2. If the new access point is connected to the PAR’s current
interface (to which MN is attached), the PAR MUST respond with a
Code value indicating that the new access point is connected to
the current interface, but not send any prefix information. This
scenario could arise, for example, when several wireless access
points are bridged into a wired network. No further protocol
action is necessary.
3. If the new access point is known and the PAR has information about
it, then PAR MUST respond indicating that the new access point is
known and supply the [AP-ID, AR-Info] tuple. If the new access
point is known, but does not support fast handover, the PAR MUST
indicate this with Code 3 (See Section 6.1.2).
4. If a wildcard is supplied as an identifier for the new access
point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples
that are subject to path MTU restrictions (i.e., provide any `n’
tuples without exceeding the link MTU).
When further protocol action is necessary, some implementations MAY
choose to begin buffering copies of incoming packets at the PAR. If
such FIFO buffering is used, the PAR MUST continue forwarding the
packets to PCoA (i.e., buffer and forward). Such buffering can be
useful when the MN leaves without sending the FBU message from the
PAR’s link. The PAR SHOULD stop buffering after processing the FBU
message. The size of the buffer is an implementation-specific
consideration.
The method by which Access Routers exchange information about their
neighbors, and thereby allow construction of Proxy Router
Advertisements with information about neighboring subnets is outside
the scope of this document.
The RtSolPr and PrRtAdv messages MUST be implemented by an MN and an
access router that supports fast handovers. However, when the
parameters necessary for the MN to send packets immediately upon
attaching to the NAR are supplied by the link layer handover
mechanism itself, use of above messages is optional on such links.
After a PrRtAdv message is processed, the MN sends an FBU at a time
determined by link-specific events, and includes the proposed NCoA.
The MN SHOULD send the FBU from PAR’s link whenever "anticipation" of
handover is feasible. When anticipation is not feasible or when it
has not received an FBack, the MN sends an FBU immediately after
attaching to NAR’s link. This FBU SHOULD be encapsulated in an FNA
message. The encapsulation allows the NAR to discard the (inner) FBU
packet if an address conflict is detected as a result of (outer) FNA
packet processing (see FNA processing below). In response to the
FBU, the PAR establishes a binding between PCoA ("Home Address") and
NCoA, and sends the FBack to the MN. Prior to establishing this
binding, PAR SHOULD send an HI message to NAR, and receive HAck in
response. To determine the NAR’s address for the HI message, the PAR
can perform the longest prefix match of NCoA (in FBU) with the prefix
list of neighboring access routers. When the source IP address of
the FBU is PCoA, i.e., the FBU is sent from the PAR’s link, and the
HI message MUST have a Code value set to 0; see Section 6.2.1. When
the source IP address of the FBU is not PCoA, i.e., the FBU is sent
from the NAR’s link, the HI message MUST have a Code value of 1; see
Section 6.2.1.
The HI message contains the PCoA, Link-Layer Address, and the NCoA of
the MN. In response to processing an HI message with Code 0, the NAR
1. determines whether NCoA supplied in the HI message is a valid
address for use. If it is, the NAR starts proxying [6] the
address for PROXY_ND_LIFETIME during which the MN is expected to
connect to the NAR. The NAR MAY use the Link-Layer Address to
verify whether a corresponding IP address exists in its forwarding
tables.
2. allocates NCoA for the MN when assigned addressing is used,
creates a proxy neighbor cache entry, and begins defending it.
The NAR MAY allocate the NCoA proposed in HI.
3. MAY create a host route entry for PCoA in case NCoA cannot be
accepted or assigned. This host route entry SHOULD be implemented
such that until the MN’s presence is detected, either through
explicit announcement by the MN or by other means, arriving
packets do not invoke neighbor discovery. The NAR MAY also set up
a reverse tunnel to the PAR in this case.
4. provides the status of the handover request in the Handover
Acknowledge (HAck) message.
When the Code value in HI is 1, NAR MUST skip the above operations
since it would have performed those operations during FNA processing.
However, it SHOULD be prepared to process any other options that may
be defined in the future. Sending an HI message with Code 1 allows
NAR to validate the neighbor cache entry it creates for the MN during
FNA processing. That is, NAR can make use of the knowledge that its
trusted peer (i.e., PAR) has a trust relationship with the MN.
If HAck contains an assigned NCoA, the FBack MUST include it, and the
MN MUST use the address provided in the FBack. The PAR MAY send the
FBack to the previous link to facilitate faster reception in the
event that the MN is still present. The result of the FBU and FBack
processing is that PAR begins tunneling the MN’s packets to NCoA. If
the MN does not receive an FBack message even after retransmitting
the FBU for FBU_RETRIES, it must assume that fast handover support is
not available and stop the protocol operation.
When the MN establishes link connectivity with the NAR, it SHOULD
send a Fast Neighbor Advertisement (FNA) message (see 6.3.3). If the
MN has not received an FBack by the time the FNA is being sent, it
SHOULD encapsulate the FBU in the FNA and send them together.
When the NCoA corresponding to the FNA message is acceptable, the NAR
MUST
1. delete its proxy neighbor cache entry, if any is present.
2. create a neighbor cache entry and set its state to REACHABLE
without overwriting an existing entry for a different layer 2
address.
3. forward any buffered packets.
4. enable the host route entry for PCoA, if any is present.
When the NCoA corresponding to the FNA message is not acceptable, the
NAR MUST
1. discard the inner (FBU) packet.
2. send a Router Advertisement with the NAACK option in which it MAY
include an alternate NCoA for use. This message MUST be sent to
the source IP address present in the FNA using the same Layer 2
address present in the FNA.
If the MN receives a Router Advertisement with a NAACK option, it
MUST use the IP address, if any, provided in the NAACK option.
Otherwise, the MN should configure another NCoA. Subsequently, the
MN SHOULD send an FBU using the new CoA. As a special case, the
address supplied in NAACK could be PCoA itself, in which case the MN
MUST NOT send any more FBUs.
Once the MN has confirmed its NCoA, it SHOULD send a Neighbor
Advertisement message. This message allows MN’s neighbors to update
their neighbor cache entries with the MN’s addresses.
Just as in Mobile IPv6, the PAR sets the ’R’ bit in the Prefix
Information option, and includes its 128 bit global address in the
router advertisements. This allows the mobile nodes to learn the
PAR’s global IPv6 address. The MN reverse tunnels its packets to the
same global address of PAR. The tunnel end-point addresses must be
configured accordingly. When PAR receives a reverse tunneled packet,
it must verify if a secure binding exists for the MN identified by
PCoA in the tunneled packet, before forwarding the packet.
5. Miscellaneous
5.1. Handover Capability Exchange
The MN expects a PrRtAdv in response to its RtSolPr message. If the
MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it
must assume that PAR does not support the fast handover protocol and
stop sending RtSolPr messages.
Even if an MN’s current access router is capable of fast handover,
the new access router to which the MN attaches may be incapable of
fast handover. This is indicated to the MN during "runtime", through
the PrRtAdv message with a Code value of 3 (see Section 6.1.2).
5.2. Determining New Care of Address
Typically, the MN formulates its prospective NCoA using the
information provided in a PrRtAdv message and sends the FBU. The PAR
MUST use the NCoA present in the FBU in its HI message. The NAR MUST
verify if the NCoA present in HI is already in use. In any case, NAR
MUST respond to HI using a HAck, in which it may include another NCoA
to use, especially when assigned address configuration is used. If
there is a CoA present in HAck, the PAR MUST include it in the FBack
message.
If a PrRtAdv message carries an NCoA, the MN MUST use it as its
prospective NCoA.
5.3. Packet Loss
Handover involves link switching, which may not be exactly
coordinated with fast handover signaling. Furthermore, the arrival
pattern of packets is dependent on many factors, including
application characteristics, network queuing behaviors, etc. Hence,
packets may arrive at the NAR before the MN is able to establish its
link there. These packets will be lost unless they are buffered by
the NAR. Similarly, if the MN attaches to the NAR and then sends an
FBU message, packets arriving at the PAR will be lost unless they are
buffered. This protocol provides an option to indicate a request for
buffering at the NAR in the HI message. When the PAR requests this
feature (for the MN), it SHOULD also provide its own support for
buffering.
5.4. DAD Handling
Duplicate Address Detection (DAD) was defined in [7] to avoid address
duplication on links when stateless address auto-configuration is
used. The use of DAD to verify the uniqueness of an IPv6 address
configured through stateless auto-configuration adds delays to a
handover.
The probability of an interface identifier duplication on the same
subnet is very low, however it cannot be ignored. In this document,
certain precautions are proposed to minimize the effects of a
duplicate address occurrence.
In some cases, the NAR may already have the knowledge required to
assess whether the MN’s address is a duplicate before the MN moves to
the new subnet. For example, the NAR can have a list of all nodes on
its subnet, perhaps for access control, and by searching this list,
it can confirm whether the MN’s address is a duplicate. The result
of this search is sent back to the PAR in the HAck message. If such
knowledge is not available at the NAR, it may indicate this by not
confirming the NCoA in the HAck message. The NAR may also indicate
this in the NAACK option in response to the FNA message. In such
cases, the MN would have to follow the address configuration
procedure according to [6] after attaching to the NAR.
5.5. Fast or Erroneous Movement
Although this specification is for fast handover, the protocol is
limited in terms of how fast an MN can move. Ping-Pong is a special
case of fast movement, where an MN moves between the same two access
points rapidly. Another instance of the same problem is erroneous
movement, i.e., the MN receives information prior to a handover that
it is moving to a new access point, but it is either moved to a
different one or it aborts movement altogether. All of the above
behaviors are usually the result of link layer idiosyncrasies and
thus are often resolved at the link layer itself.
IP layer mobility, however, introduces its own limits. IP layer
handovers should occur at a rate suitable for the MN to update the
binding of, at least, its HA and preferably that of every CN with
which it is in communication. An MN that moves faster than necessary
for this signaling to complete, which may be a few seconds, may start
losing packets. The signaling cost over the air interface and in the
network may increase significantly, especially in the case of rapid
movement between several access routers. To avoid the signaling
overhead, the following measures are suggested.
An MN returning to the PAR before updating the necessary bindings
when present on the NAR MUST send a Fast Binding Update with the Home
Address equal to the MN’s PCoA and a lifetime of zero to the PAR.
The MN should have a security association with the PAR since it
performed a fast handover to the NAR. The PAR, upon receiving this
Fast Binding Update, will check its set of outgoing (temporary fast
handover) tunnels. If it finds a match, it SHOULD tear down that
tunnel (i.e., stop forwarding packets for this MN and start
delivering packets directly to the node instead). The MN SHOULD NOT
attempt to use any of the fast handover mechanisms described in this
specification and SHOULD revert back to standard Mobile IPv6.
Temporary tunnels for the purpose of fast handovers should use short
lifetimes (a small number of seconds or less). The lifetime of such
tunnels should be enough to allow an MN to update all its active
bindings. The default lifetime of the tunnel should be the same as
the lifetime value in the FBU message.
The effect of erroneous movement is typically limited to the loss of
packets since routing can change and the PAR may forward packets
toward another router before the MN actually connects to that router.
If the MN discovers itself on an unanticipated access router, a Fast
Binding Update to the PAR SHOULD be sent. Since Fast Binding Updates
are authenticated, they supercede the existing binding and packets
MUST be redirected to the newly confirmed location of the MN.
6. Message Formats
All the ICMPv6 messages have a common Type specified in [4]. The
messages are distinguished based on the Subtype field (see below).
The values for the Subtypes are specified in Section 9. For all the
ICMPv6 messages, the checksum is defined in [2].
6.1. New Neighborhood Discovery Messages
6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr)
Mobile Nodes send Router Solicitation for Proxy Advertisement in
order to prompt routers for Proxy Router Advertisements. All the
Link-Layer Address options have the format defined in 6.4.3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Router Solicitation for Proxy (RtSolPr) Message
IP Fields:
Source Address
An IP address assigned to the sending interface.
Destination Address
The address of the Access Router or the all routers
multicast address.
Hop Limit 255. See RFC 2461.
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. See RFC 2402 [5].
ICMP Fields:
Type The Experimental Mobility Protocol Type. See [4].
Code 0
Checksum The ICMPv6 checksum.
Subtype 2
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Identifier MUST be set by the sender so that replies can be
matched to this Solicitation.
Valid Options:
Source Link-Layer Address
When known, the Link-Layer Address of the sender
SHOULD be included using the Link-Layer Address
option. See the LLA option format below.
New Access Point Link-Layer Address
The Link-Layer Address or identification of the
access point for which the MN requests routing
advertisement information. It MUST be included in
all RtSolPr messages. More than one such address
or identifier can be present. This field can also
be a wildcard address with all bits set to zero.