Mobile IP Working Group Alper E. Yegin
Internet Draft Mohan Parthasarathy
Category: Standards Track Carl Williams
Expires: May, 2001 Sun Microsystems
November, 2000
Mobile IPv6 Neighborhood Routing for Fast Handoff
draft-yegin-mobileip-nrouting-01.txt
Status of this Memo
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
The Mobile IP working group is currently examining proposals to
assist in minimizing the latency and packet loss due to handoffs
when a Mobile IPv6 node moves from one point of attachment to
another. One of the desires to reduce this latency and packet loss
is a result of the strict requirements of real-time network
services. This proposal specifies a solution whereby the mobile
node sends a binding update with multiple care-of-addresses which
match the current link and other links that the mobile node may
possibly visit next. After receiving such a binding update, the
correspondent nodes and home agent use a new routing header
extension to route the packet that will be received by the mobile
node at one of the possible care-of-addresses. Thus, the
correspondent nodes and home agent can still communicate with
the mobile node despite not knowing its exact location while the
mobile node moves across links. The proposal presents no new
networking entities and the resulting architecture describes a
natural extension to the Mobile IPv6 protocol.
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 1
Internet Draft Neighborhood Routing 22 November 2000
Contents
Status of this Memo 1
Abstract 1
1. Introduction 3
2. Terminology 3
3. Protocol Operation 4
3.1. Access Router Sending Router Advertisements . . . 4
3.2. MN Processing . . . . . . . . . . . . . . . . . . 5
3.3. CN Processing . . . . . . . . . . . . . . . . . . 5
3.4. Access Router Processing Data Packets . . . . . . 5
3.5. Home Agent Processing . . . . . . . . . . . . . . 6
3.6. Establishing Forwarding from a Previous CoA . . . 6
3.7. Ping-pong Effect . . . . . . . . . . . . . . . . . 7
3.8. Other Details . . . . . . . . . . . . . . . . . . 7
4. New Requirements for IPv6 Nodes 8
4.1. Access Routers . . . . . . . . . . . . . . . . . . 8
4.2. Mobile Node . . . . . . . . . . . . . . . . . . . 8
4.3. Correspondent Nodes . . . . . . . . . . . . . . . 9
4.4. Home Agent . . . . . . . . . . . . . . . . . . . . 9
5. Protocol Extensions 9
5.1. Router Solicitation . . . . . . . . . . . . . . . 9
5.2. Router Advertisement . . . . . . . . . . . . . . . 10
5.3. Binding Update . . . . . . . . . . . . . . . . . . 11
5.4. New Routing Header . . . . . . . . . . . . . . . . 12
6. Security Considerations 15
7. Conclusion 15
Acknowledgements 15
References 16
Author's Addresses 16
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 2
Internet Draft Neighborhood Routing 22 November 2000
1. Introduction
MIPv6 draft [1] describes how a MN should send a BU after moving to
a new link. When MN is attached to a new link, it configures a new
CoA and sends BUs to CNs and HA. Although this would establish
"connectivity" as soon as BUs are received by CNs and HA, this
method doesn't produce acceptable results for communications that
require certain characteristics, such as minimum latency and packet
loss . During the time between when MN detaches from old link and
the time when BUs are received, MN is "unreachable". All the packets
in flight during this period end up at the old link and get dropped.
The unreachability problem is due to the lack of knowledge at the
CNs and HA about the possible movement of the MN. By the time
binding update reaches the CNs and HA, all packets that were sent to
the old location of the mobile node are lost. If the MN had provided
the information about its neighborhood and if the packet can be
routed in that neighborhood, then MN will always be reachable. The
"neighborhood" is an area in which the MN may visit in the immediate
future. It consists of the known current link and a number of
possible other links that the MN might move to next. With this
information the CNs and HA will send packets to the "neighborhood"
for the MN. Since the MN will be in the "neighborhood" even after
detaching from the old link, packets will be delivered successfully.
A Layer 2 (L2) entity in the network figures out a list of possible
next links that MN might visit in the immediate future. This
information is conveyed to L3 of Access Router (AR). Then AR
communicates this information to MN, and MN can send an extended BU
to CNs and HA, telling them about its neighborhood. So with this
extended information CNs and HA can send packets to this
neighborhood, which tries to reach the MN at the known current link
first, and then at the other links in the neighborhood. Packets can
be routed to multiple links using a new routing header described
later in this document.
In this manner, MN can notify CNs and HA where it is now and where
else it might be in the immediate future. Instead of "reactively"
updating the system to establish connectivity as soon as MN moves,
this protocol "proactively" informs CNs and HA to cover MN's
possible movements, and refine in time. And although no other entity
keeps track of instant movements of MN, it stays reachable.
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 [2].
Basic Mobile IPv6 terminology is used as defined in [1].
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 3
Internet Draft Neighborhood Routing 22 November 2000
Additionally, the following terminology is used in this draft:
Access Router (AR)
The closest router to the mobile node in the visited domain
that the mobile node uses to access the network [3].
Neighborhood
The ordered list of links which includes the link that MN is
currently attached to and a number of other links that MN may
visit in the immediate future. Since MN may visit links that
are more than one hop away, other links in the neighborhood
don't have to be adjacent to current link of attachment.
Current Care-of-Address
Care-of-Address configured using the prefix of the link that
MN is currently attached to.
Possible Next Link (pn-link)
Any of the links in a neighborhood other than the one that MN
is currently attached to.
Possible Next Prefix (pn-prefix)
Prefix of one of the pn-links.
Possible Next Care-of-Address (pn-CoA)
Care-of-Address configured using one of the pn-prefixes.
3. Protocol Operation
This section describes how this proposed protocol works. It uses an
example where MN is moving through a series of links: link1, link2,
link3, etc. link1 is attached to AR1, and uses the prefix prefix1.
Care-of-Address configured by using prefix1 is CoA1. Similarly,
link2 is attached to AR2, uses prefix2, and MN configures CoA2 by
using prefix2.
3.1. Access Router Sending Router Advertisements
Layer 2 of the AR comes up with a list of links that an attached MN
might be visiting in the immediate future. In case AR doesn't have
such an ability, MN can supply this information to AR by using a
router solicitation (RS) (see section 5.1). This list of links would
be the "neighborhood of MN". Neighborhood is conveyed to layer 3 of
AR in the form of a list of links (e.g. "link1, link2, link3").
Current access router, AR1, needs to map these links to prefixes
advertised on each link. One possible way of implementing this
mapping could be in the form of a table. This table can be a local
one or a centrally maintained one. Note that even without this
extension to the protocol, AR1 uses such a table to advertise its
own prefixes on various links. That table can be extended to include
other links a MN may visit in this domain.
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 4
Internet Draft Neighborhood Routing 22 November 2000
AR1 comes up with a list of prefixes, prefix1, prefix2, etc. after a
successful lookup. The first prefix is the one for the link MN is
physically attached to. The rest are the prefixes for possible next
links in the order of descending possibility. Note that this list is
per MN, and its elements and their order can change in time.
Now AR1 can send a unicast router advertisement (RA) to MN. This RA
includes a prefix information option to carry prefix1 as current
prefix, and a number of others to carry pn-prefixes (see section
5.2).
3.2. MN Processing
When MN receives an RA with pn-prefixes, it can configure one CoA
for each prefix. CoA1 will be current CoA, and others pn-CoAs. All
the pn-CoAs are marked as deprecated, so that they are not used as
source addresses in outgoing packets. Now MN can receive packets
that are sent to any of its CoAs.
Next, MN sends a new BU to CNs and HA. This BU, in addition to
current CoA, contains one pn-CoA destination option sub-option for
all pn-CoAs (see section 5.3).
3.3. CN Processing
After receiving a BU with pn-CoAs, whenever CN wants to send a
packet to MN, it includes a routing header extension in the packet.
CN uses new routing header type 1 (instead of type 0) that includes
all CoAs as intermediate hops (see section 5.4). The destination of
the packet is CoA1, and the routing header is initialized to contain
CoA2, CoA3, ..., home address of MN as the route segments. The
routing infrastructure makes a best effort to route packet through
intermediate hops. But, if a router on the same link as next hop
(such as AR1) determines that host at next hop (such as MN at CoA1)
is not reachable, it can simply skip this hop, update the routing
header, and forward the packet to the following hop (MN at CoA2).
If MN is not attached to any of the links, last AR forwards the
packet to the home link to be intercepted by HA since the last route
segment in the routing header is the home address of the MN (see
section 3.8 for more on this).
3.4. Access Router Processing Data Packets
When a packet with type 1 routing header arrives, AR1 will forward
it to MN for a successful delivery if MN is still attached to link1.
It's assumed that L2 of AR can determine whether a MN is attached or
not, and convey this information to L3.
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 5
Internet Draft Neighborhood Routing 22 November 2000
If MN had already moved to link2 before the packet arrives at AR1,
then AR1 would know that MN at CoA1 is no longer attached to link1.
AR1 would process the routing header, so that CoA1 is skipped, and
the packet is forwarded to next hop, CoA2. This time AR2, seeing
that MN at CoA2 is attached to link2, forwards the packet to MN.
Although sender of the packet didn't know the exact location of MN,
the packet is delivered successfully by using the information about
where else MN might be located currently.
3.5. Home Agent Processing
As stated in [1], HA intercepts packets from various CNs and tunnels
them to MN. Additionally, if HA has the knowledge of pn-CoAs, it
puts a routing header type 1 in the encapsulating packet's header.
The destination of this packet is CoA1, and the routing header is
initialized to contain CoA2, CoA3, ... as the route segments. This
way, tunneled packet will be delivered to MN at one of the CoAs.
Note that since home address of MN is not included in the routing
header (unlike CN processing, see section 3.3), this packet will
never be forwarded back to the home link.
One special case MAY need to be handled by HA. When a packet from CN
with routing header type 1 is not delivered at any of CoAs, it ends
up at the HA to be intercepted. If HA blindly processes, the
tunneled packet could traverse the same ARs as the original packet
and get dropped at the last AR. In order to prevent an extra
transmission, HA MAY implement an optional check. HA MAY compare its
knowledge of CoAs with the one derived from the routing header of
the intercepted packet. If they are same, HA MUST discard the
packet. This shows CN already tried the possibilities that HA would
try. Sending the packet again won't deliver the packet. This can be
the case when MN moved to a different domain, and neither CN nor HA
has received the most current BU yet.
3.6. Establishing Forwarding from a Previous Care-of Address
One alternative for speeding up handoff operation is to use previous
AR to establish forwarding from previous CoA. This would solve the
problem in local environment without involving CNs and HA.
This is based on the similar method described in [1]. But, the method
as decribed in [1] is not fast enough. MN needs to attach to new
link, acquire a new CoA, and then send a BU to previous AR to
establish forwarding. Until this BU is received by the previous AR,
MN is unreachable.
This method can be improved by using neighborhood routing. Whenever
MN detects it may move to a new link in the immediate future, it can
send a BU to current AR. Current AR doesn't use this information
until MN detaches from its link. As soon as AR detects that MN is
detached, it can start forwarding packets to the neighborhood of MN.
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 6
Internet Draft Neighborhood Routing 22 November 2000
In this way, MN can start receiving packets as soon as it attaches
to new link.
As MN had to provide the neighborhood information before L2 handoff
initiates, there is a possibility that it might not be 100% sure
where it's moving to. In that case, using more than one pn-CoA
solves this problem by increasing the confidence level.
3.7. Ping-pong Effect
Ping-pong effect is the rapid and repeated movement of MN between
two links. Such a movement should not effect the connectivity of
the MN.
Neighborhood routing automatically deals with ping-pong effect.
During a ping-pong between CoA1 and CoA2, any BU sent by MN to CNs
and HA would contain both CoA1 and CoA2. Therefore the packets sent
by CNs and HA would be received by the MN at one of the CoAs. MN
doesn't even have to detect ping-pong and take a special action.
An extension MAY be optionally implemented to prevent MN sending BUs
each time it changes the link during a ping-pong. By looking at the
links MN is visiting, it can easily detect if there's a ping-pong
going on. Upon detecting this, MN can suppress sending BUs. Note
that once MN sends a BU that contains CoA1 and CoA2, this is good
enough throughout the whole ping-pong between CoA1 and CoA2.
3.8. Other Details
The neighborhood of MN changes as MN moves within and across links.
When MN moves within the same link, current CoA stays the same but
pn-CoAs may change. Current CoA changes only when MN moves to
another link. Furthermore, each CoA has an associated lifetime and
they are removed when their lifetime expires. Each of such changes
to the list of CoAs can trigger a new BU transmission. MN
proactively makes sure each CN and HA has enough information to
deliver packets wherever it might move next by refining its list of
CoAs.
In this protocol, if AR doesn't send np-prefixes, or MN doesn't
recognize np-prefixes, or MN doesn't send np-CoA sub-options, or CN
and HA don't recognize np-CoA sub-options, then the system
automatically converges to the one in draft [1]. None of the
entities need to detect whether new protocol is recognized at
others or not.
Whenever L2 determines that MN will be staying at the current link
for an extended period of time (due to low speed, very large cell,
etc.), system can use only one CoA as in [1]. System can use the new
protocol to configure pn-CoAs as soon as a possible move to another
link is detected.
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 7
Internet Draft Neighborhood Routing 22 November 2000
Definition of "immediate future", the threshold used to determine
that the MN might move to a given link, and maximum number of CoAs
to configure on MN are system wide tuning parameters.
4. New Requirements for IPv6 Nodes
This protocol extension requires modification to the Access Routers,
the Mobile Node, the Correspondent Nodes, and the Home Agent. If
this protocol is used as specified in section 3.6, then only Access
Routers and Mobile Nodes need to be modified.
The proposed MIPv6 extensions are optional to basic Mobile IPv6;
networking elements can function with support of the new option
independent to any other networking entity providing support. If the
extensions are not supported by AR, MN, CN, and HA, the operation
will default to the base protocol as defined in [1].
4.1. Access Routers
Whenever this information is not provided by the MN, L3 of AR MUST
be capable of interfacing with L2 to obtain a list of links that
the MN may be visiting next. The actual interface is beyond the
scope of this document. The AR MUST be able to map each link to the
prefix information and also be capable of sending router
advertisements with the N bit set for these prefixes. Additionally,
L3 MUST be capable of determining if a MN is attached to its link or
not. The AR MUST be able to process data packets containing the
type 1 routing header extension.
If this protocol is used as specified in section 3.6, then AR also
needs to implement HA functionality.
4.2. Mobile Node
If AR does not have the capability to determine the neighborhood of
the MN, MN MUST be able to provide this information in a RS message.
The MN MUST recognize the use of the prefix information option with
N bit set so that the extended protocol can be used. The MN MUST be
able to configure one CoA for each prefix it receives. The MN MAY
perform further processing on the list of prefixes it receives from
the AR. This processing MAY include the reordering or reducing the
list of prefixes via some heuristic. The mobile node MUST be able to
send a BU with pn-CoA sub-option. The MN MUST be able to process
type 1 routing header extensions.
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 8
Internet Draft Neighborhood Routing 22 November 2000
4.3. Correspondent Nodes
The CN MUST be able to recognize a BU with pn-CoA sub-option. The CN
MUST be capable of maintaining binding cache entries based on the BU
with pn-CoA sub-option. The CN MUST be able to send a type 1
routing header extension whenever sending packets to the MN. If the
protocol is used as specified in section 3.6, then CN is not
effected at all.
4.4. Home Agent
The HA MUST be able to recognize BU with pn-CoA sub-option. The HA
MUST be capable of maintaining a binding cache entries based on the
neighborhood binding updates. The HA MUST be able to send a router
header extension of type 1 for all the intercepted packets that are
tunneled. The HA MAY also check the router headers in the
intercepted packets to handle the case specified in section 3.5. If
the protocol is used as specified in section 3.6, then HA is not
effected at all.
5. Protocol Extensions
5.1. Router Solicitation
This section defines a new option to be used with router
solicitations. In the networks that AR cannot determine the
neighborhood of MN, it's expected that MN figures this out by using
its L2. Upon determining the possible next links, MN needs to convey
this neighborhood information to AR. It can do so by sending a RS
that contains one or more pn-link options. This option contains
link identifiers for links that are part of the neighborhood.
When AR receives such a RS, it MUST lookup pn-prefixes for each
pn-link and send back a unicast RA that contains those pn-prefixes.
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 | Link IDs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : TBD
Length: The length of the option (including the type and
length fields) in units of 8 octets.
Link IDs: One or more link IDs. 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.
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 9
Internet Draft Neighborhood Routing 22 November 2000
5.2. Router Advertisement
This section defines a new bit as part of the prefix information
that is sent as part of the router advertisement [4]. Access routers
set this bit to indicate that the prefix contained in this option is
a pn-prefix (see section 3.1). MN can use this information to
configure the additional care of addresses and also use it in the
binding updates to indicate its neighborhood.
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 | Prefix Length |L|A|R|N|Resvd1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Prefix Information Option
N : This indicates that the contained prefix belongs to a link
of another router where the MN could possibly be visiting in
the near future. When N bit is set, none of the L, A, or R
bits must be set.
All other fields has the same meaning as that of [4].
If the N bit is not understood by the mobile node, it MUST skip the
prefix contained in the option as none of the other bits are set.
Thus, this mechanism provides backward compatibility to mobile nodes
that does not understand the bit and hence falls back to the old
scheme mentioned in the draft [1].
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 10
Internet Draft Neighborhood Routing 22 November 2000
5.3. Binding Update
This section defines a new destination option sub-option for the
binding update that lists the possible next care of addresses to be
used by the HA or CNs in routing header type 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address n +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Possible Next Care-of-Address Sub-Option
(alignment requirement: 8n+6)
len : n * 16 where n is the number of care of addresses.
The source address of the BUs will be the current CoA. If this
sub-option is not understood by the CN or HA, it MUST be skipped as
mentioned in the draft [1]. Thus, this mechanism provides backward
compatibility to nodes that does not understand the new sub-option
and hence falls back to the old scheme mentioned in the draft [1].
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 11
Internet Draft Neighborhood Routing 22 November 2000
5.4. New Routing Header
This proposal defines a new routing header type 1 which is used by
CNs and HA when sending packets to MN. This MUST be sent only if CN
and HA received a binding update with the new possible next
care-of-address sub-option defined in section 5.3.
The Routing header is used by an IPv6 source to list one or more
intermediate nodes to be "visited" on the way to a packet's
destination. The Routing header is identified by a Next Header
value of 43 in the immediately preceding header, and has the
following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Routing Header Extension
All the fields of the routing header remain the same as in type 0
[5] except that the Routing Type is 1.
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 12
Internet Draft Neighborhood Routing 22 November 2000
The Type 1 Routing header has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=1| Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[2] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Type 1 Routing Header Extension
The processing of Routing header type 1 is almost the same except
for the difference noted below.
A Routing header type 0 is not examined or processed until it
reaches the node identified in the Destination Address field of the
IPv6 header. But in the case of routing header type 1, the last hop
router that forwards the packet to the node identified by the
Destination Address of the IPv6 header also processes the packet if
the packet can't be delivered. If it knows readily that the node
identified by the destination address is reachable, it sends the
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 13
Internet Draft Neighborhood Routing 22 November 2000
packet. If it is not reachable, it swaps the destination addresses
with the next hop address contained in the route specific data, as
it does with routing header type 0 and forwards the packet to the
new destination address.
The router that determines that the packet being forwarded is
on-link, checks to see whether the destination is reachable or not.
It checks for a routing header type 1 and processes it only if the
destination is not reachable. The processing is as follows :
If (packet being forwarded is on-link) {
if (destination is reachable) {
Send the packet(*)
} else if (routing header type 1 present) {
Process the routing header type 1 similar to
routing header type 0. Swap the IPv6 destination
address with the next hop address in the option
and forward the packet to the new destination.
} else {
drop the packet.
}
} else {
forward the packet using the default IPv6 rules.
}
(*)If the destination is reachable and the packet was sent to the
destination connected on-link, the node receiving the packet would
see one of the care of addresses (it sent in the binding update) in
the destination field of the IPv6 header, depending on which link it
receives the packet. It processes the packet in the following way:
if (Segments Left == 0) {
Send an ICMP Parameter Problem, Code 0, message
to the Source Address, pointing to the Hdr Ext
Len field, and discard the packet
} else {
Swap the Destination address with the next hop address
and feed the packet for transmission.
As all the addresses belongs to this node, this will
eventually stop when the last hop address is
processed.
}
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 14
Internet Draft Neighborhood Routing 22 November 2000
6. Security Considerations
Binding updates MUST be protected by IPsec Authentication header.
When Routing header type 1 is used and IPsec is also used, routing
header should be protected by IPsec. The processing of routing
header type 1 is the same as routing header type 0 in the context
of IPsec.
7. Conclusion
Standard routing expects a host to be reachable at a certain link.
New protocol extends this to reaching a host at one of the possible
links it might be attached at that time. All the traffic can be
delivered to MN at any of those links by MN knowing which other
links it might be moving to and informing CNs and HA about them.
AR determines this link information using L2 knowledge and sends it
to MN.
This new protocol is a natural extension to the one in MIPv6 draft
[1]. It doesn't define new networking entities. The data flow is the
same as specified in the MIPv6 draft [1]: MN configures CoAs by
using the prefixes in RAs, MN informs CNs and HA by use of BUs, CNs
use routing header to deliver packets to MN, and HA intercepts
packets from CNs and tunnels them. The new protocol shows up as
extensions to router advertisement, binding update, and routing
header. These extensions are ignored when they are not recognized by
any of the networking entities, and the system automatically
converges to regular MIPv6.
As soon as MN moves to a new link, it can start sending and
receiving packets without anyone else keeping track of instant
movements of MN.
This protocol allows the MIPv6 infrastructure to dynamically adapt
itself to changing conditions and different deployment scenarios.
If handoffs are happening frequently (fast MN movement, too small
cells, etc.), MN sends more CoAs in its BUs. If no handoff is
expected for a while, none of the new extensions are used, therefore
only one CoA is sent and the system becomes what's described in [1].
Acknowledgements
We would like to thank Claude Castellucia (INRIA) for suggesting
another way of applying our solution as specified in section 3.6.
We would also like to thank members of the Mobile IPv6 Handover
Design Team for their valuable comments and suggestions (in
alphabetical order): Gopal Dommety (Cisco), Mohamed Khalil (Nortel
Networks), Basavaraj Patil (Nokia), Charles Perkins (Nokia), Hesham
Soliman (Ericsson), George Tsirtsis (Flarion).
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 15
Internet Draft Neighborhood Routing 22 November 2000
References
[1] D. Johnson and C. Perkins. "Mobility support in IPv6",
draft-ietf-mobileip-ipv6-12.txt, April 2000.
[2] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels", Request for Comments (Best Current Practice) 2119,
March 1997.
[3] J. Malinen and C. Perkins. "Mobile IPv6 Regional Registrations",
draft-malinen-mobileip-regreg6-00.txt, July 2000.
[4] T. Narten, E. Nordmark, and W. Simpson. "Neighbor Discovery for
IP Version 6 (IPv6)", Request for Comments (Draft Standard) 2461,
December 1998.
[5] S. Deering and R. Hinden. "Internet Protocol, Version 6 (IPv6)",
Request for Comments (Draft Standard) 2460, December 1998.
Author's Addresses
Alper E. Yegin
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
USA
phone: +1 650 786 4013
fax: +1 650 786 5896
email: Alper.Yegin@eng.sun.com
Mohan Parthasarathy
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
USA
phone: +1 650 786 8885
fax: +1 650 786 5896
email: Mohan.Parthasarathy@eng.sun.com
Carl Williams
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
USA
phone: +1 650 786 5186
fax: +1 650 786 5896
email: Carl.Williams@eng.sun.com
Yegin, Parthasarathy, Williams Expires 22 May 2001 Page 16