Mobile-IP Working Group Brett Pentland
INTERNET-DRAFT Greg Daley
Expires: November 2003 Monash University CTIE
JinHyeock Choi
Samsung AIT
May 2003
Router Advertisement Link Identification
for Mobile IPv6 Movement Detection
draft-pentland-mobileip-linkid-00.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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
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.
Abstract
This document defines a mechanism by which Access Routers on a link
may automatically assign a consistent identifier to this link to aid
in Movement Detection. This assists Movement Detection by allowing a
Mobile Node to rapidly determine whether it has moved to a new link
upon reception of a Router Advertisement containing this identifier.
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 1]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
Table of Contents
Abstract.................................................
Table of Contents........................................
1. Introduction..........................................
2. Link Identifiers for movement detection...............
3. Link ID Message Format................................
4. MN Operations.........................................
4.1. Interoperation with existing RAs.................
5. Access Router Operations..............................
5.1. Discovering the Link ID..........................
5.2. Generating the Link ID...........................
5.2.1. Conflicting Link ID Management..............
5.3. Advertising the Link ID..........................
6. IANA Considerations...................................
7. Constants and Variables...............................
7.1. Configuration Variables..........................
7.2. Protocol Constants...............................
8. IANA Considerations...................................
9. Security Considerations...............................
Normative References.....................................
Informative References...................................
Acknowledements..........................................
Authors Addresses........................................
1. Introduction
Movement detection is the task of determining if an IPv6 node has
moved to a new network. This detection is important since in the
case that the device has moved, addresses it has configured will be
invalid and additional configuration must be undertaken to establish
or maintain upper layer connectivity.
Movement detection is accomplished by determining that the current
router is unreachable, checking the validity of configured addresses
and finding that a new router is available on the network. Most
previous efforts at movement detection have aimed at speeding up
discovery of new routers with Router Advertisements(RAs)
[FASTRA-02][FRD-00] and discounted the requirement for determining
current router reachability[MIPv6-22][MDO-01].
In IPv6 multiple routers are allowed on a link, and these routers do
not have to advertise overlapping prefixes[RFC-2461]. Therefore,
reception of an RA from a new router does not imply movement. For
reliable movement detection, nodes can check the reachability of the
current router. Determination that the current router is unreachable
is typically a slow process[RFC-2461], but provides safeguards which
allow nodes to be sure that movement has occurred.
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 2]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
Link Identifiers (LinkIDs) are numeric values automatically
configured on a link, which are extremely unlikely to conflict with
an identifier on an adjacent link. Earlier work by Erik Nordmark
described a form of Link Identifier in [HINDSIGHT-00]. This document
describes a technique for automatically establishing a consistent
Link Identifier for the set of routers on a given link. The Link
Identifier is randomly generated by one of the routers on a link and
all of the other Link Identifier supporting routers on that link
agree to use that identifier.
Mobile Nodes (MNs) receiving Router Advertisements (RAs) with LinkID
options can use the LinkID value to identify the link that they are
attached to. This may aid movement detection by allowing MNs to
determine when the link changes. A change to the LinkID implies to
the MN that currently configured router is unreachable.
Terminology
Access - A Router that has interfaces on a link which
Router Mobile Nodes may communicate with directly.
LinkID - An identifier, consistant across the routers on
a given link, that can be used by Mobile Nodes as
an indication of link changes.
2. Link Identifiers for Movement Detection
All routers supporting the Link Identifier Option advertise it in
each of their Router Advertisements.
Advertised Link Identifiers are consistent within any one link.
Mobile Nodes store the Link Identifier internally, for comparison
with subsequently received Router Advertisements.
Upon receiving an RA with a LinkID that differs from the MN's
currently recorded value of LinkID, the MN
can assume that it has moved to a new network and that its
current default router is unreachable.
This infomation may be used to initiate further stateful or stateless
autoconfiguration procedures, or appropriate mobility signalling by
the MN.
When an MN receives an RA from a previously unseen router, which contains
the same LinkID as its default, this means the MN is on the same link,
but does not guarantee reachability for the current default router.
Other mechanisms can be used in order to check bidirectional reachability
with the default router, as described in [MIPv6-22].
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 3]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
3. Link ID Message 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 |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LinkID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type TBA
Length 1
A Ambiguity flag. When set, the A-flag indicates that
the LinkID field is ambiguous and may change.
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
LinkID 32-bit unsigned integer. Link identifer. Gener-
ated randomly.
4. MN Operations
Link Identifiers assist in the determination of whether advertise-
ments received from different routers are from the same link. This
is possible because multiple routers on a link will share the same
LinkID.
Mobile Nodes monitor the current link's identity using LinkID. They
maintain a system variable, CurrentLinkID, that is equal to the value
of the most recently received LinkID option. By comparing the value
of CurrentLinkID to a received LinkID option, a Mobile Node can tell
if this RA represents movement to a new link.
4.1. Interoperation with existing RAs
If an MN receives an RA with no LinkID and no prefixes that match its
current CoA, it cannot use this technique to infer anything about
point of network attachment. The MN SHOULD proceed to confirm bi-
directional reachability or otherwise with its current default
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 4]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
router.
If an MN starts receiving Link Identifiers and the LinkID is not cur-
rently set, it MUST set CurrentLinkID to the received value and
SHOULD test its current router for reachability to detect movement.
5. Access Router Operations
When undertaking LinkID advertisement, an Access Router needs to
ensure that it is in agreement with other Routers sending the same
option. The following sections describe mechanisms to discover, gen-
erate and advertise a LinkID.
5.1. Discovering the Link ID
Upon bringing up an interface, an AR will be unaware of any LinkID in
use on the link. In order to determine if a LinkID is in use on a
link, it solicits RAs from the network to determine if one is avail-
able.
While in this state it MUST send Router Solicitations in the way
specified for a host in section 6.3.7 of RFC-2461. Since multiple
routers may be performing the same test, the AR MUST randomly delay
sending its initial RS message using the mechanism described in
[RFC-2461].
Upon starting to solicit, the AR sets a timer, which is used to ter-
minate Router Solitication. This solicitation timer is calculated in
the following fashion:
SolicitTimer = MAX_RTR_SOLICITATIONS * RTR_SOLICITATION_INTERVAL
+ random_delay
In this case random_delay is equal to the delay calculated in accor-
dance with section 6.3.7 of [RFC-2461]. If this timer expires with-
out a LinkID being received by the router, it should generate its own
LinkID as described in section 5.2.
It is possible that the router will receive responses from routers
without LinkID options. When a router monitors RAs for the purpose
of LinkID discovery, these messages MUST be silently discarded.
If while it is soliciting, an AR receives an RA with a non-zero
LinkID option, the solicitation process MAY be terminated early.
If the router receives a LinkID option where the Ambiguity Flag is
set, the LinkID is not guaranteed to be at its final value. Routers
consider that a LinkID is ambiguous for AmbigTimer seconds, where
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 5]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
AmbigTimer is initially set to MAX_AMBIGUITY_TIME. Routers MUST con-
figure this LinkID, and advertise it to the All-Routers multicast
group. These advertisements are sent at the rate of one RA per sec-
ond. This informs the router which generated the LinkID that the
current router accepts the LinkID.
If while the LinkID is ambiguous, the router receives a non-zero
LinkID which is numerically less than the currently configured
LinkID, the new LinkID MUST be configured. This new LinkID MUST be
advertised in the same fashion as the previous LinkID, without reset-
ting AmbigTimer.
If a router receives an RA with a non-zero LinkID which has the Ambi-
guity Flag unset, it SHOULD not consider the LinkID ambiguous any
more.
Once the router determines that the LinkID is unambiguous, it enters
steady state operation and advertises LinkID as defined in section
5.3.
Additionally, once the LinkID is detected to be unambiguous, the
router SHOULD start listening to LinkID options with zero-value, in
order to support conflict management defined in section 5.2.1.
While soliciting for other routers and while a configured LinkID is
considered ambiguous, a router may be required to transmit RAs,
either in response to solicitation or unsolicited according to con-
figuration. These RAs MUST NOT include LinkID options.
5.2. Generating the Link ID
If, at expiration of the solicitation timer, no RAs with non-zero
LinkID options have been received, the router generates a random
32-bit integer to use as the LinkID with due care to its randomness
[RFC-1750].
The router then transmits an RA to the All-Routers multicast group
with a LinkID option and the Ambiguity Flag set. At this point the
LinkID is considered ambiguous since another router may have gener-
ated an address simultaneously or not received this first LinkID
packet. The LinkID remains ambiguous for MAX_AMBIGUITY_TIME seconds
and a timer, AmbigTimer, is started. RAs with the LinkID option are
tramsmitted one per second while the timer runs.
A router generating a LinkID considers itself to be the master for
LinkID purposes. Other routers that send RAs with this LinkID are
slaves.
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 6]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
If, while AmbigTimer runs, an RA is received with a LinkID that is
numerically less than the LinkID that was generated, this router
becomes a slave and transmits RAs with this new LinkID for the rest
of the ambiguity period.
If, while AmbigTimer runs, an RA is received with a LinkID that is
numerically greater than the LinkID that was generated, the router
takes note of the source address of the received RA and adds it to a
collision list. If a later RA is received from the same router with
the LinkID matching that generated by this router, the corresponding
entry in the collision list is removed.
If, at expiry of AmbigTimer, there are entries in the collision list,
the conflict SHOULD be resolved according to section 5.2.1. If there
are no entries in the collision list, the router enters its normal
operation state and uses its generated LinkID in all transmitted RAs.
If, at any time during the period of ambiguity, an AR receives an RA
with a Link option with the A-flag not set, it SHOULD set its LinkID
to the received value and enter normal operating state.
5.2.1. Conflicting Link ID Management
If at the expiry of AmbigTimer, the router that generated the LinkID
has found routers which continue to advertise a less preferred
LinkID, the following action may be applicable:
For a period equal to the sum of the maximum values of SolicitTimer
and AmbigTimer, the router MAY advertise a LinkID option with a
LinkID field value set to zero. This LinkID option MUST have the
Ambiguity Flag unset. After this period, the router returns to RA
advertising without LinkID, until the interface is reset.
Such interface resets may be undertaken upon Link-layer trigger
reception, or administrative action.
Other routers which are advertising LinkID SHOULD stop doing so upon
reception of an unambiguous advertisement with LinkID of zero value.
The routers return to RA advertising without LinkID until their
interface is reset.
In the case where LinkID advertisement is disabled because of con-
flicting LinkID, or upon the reception of zero-valued LinkIDs, a sys-
tem log message SHOULD be raised on the router in order to inform
administrators of the failure of LinkID advertisement.
If the router which originally did not correct LinkID continues to be
the sole router to advertise LinkID even after conflict notification,
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 7]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
this is unlikely to affect nodes on the network, since other routers'
reachability will still be checked after reception of the bogus
LinkID in accordance with Section 4.2.
5.3. Advertising the Link ID
Advertisement of Link Identifier Options in RAs MUST be configurable
on a per-interface basis.
When configured to send LinkID options in RAs for a given interface,
an AR monitors RAs on the link associated with that interface as
described in section 5.1.
When sending an RA with self-generated LinkID, the value calculated
in section 5.2 is used to fill the LinkID field.
Until the Access Router determines that a LinkID is unambiguous, the
Router MUST NOT send RAs containing LinkID, except to the All-Routers
group. This means that responses to Router Solicitations MUST NOT
contain the LinkID until the router reaches steady state operation.
Once the LinkID has been determined as unambiguous, the router MUST
advertise the LinkID in every RA. This encourages consistently fast
movement detection for mobile nodes arriving on a network.
One side benefit of requiring LinkID options in RAs on supporting
Routers, is that LinkIDs may remove the necessity to advertise Prefix
Information Options in all unsolicited RAs. Upon receiving a LinkID
that indicates a change of link, an MN is then able to solicit the
router for new addressing information. This may be an important
overhead saving in the case that the router is advertising RAs at the
highest rates allowed in [MIPv6-22].
6. Applicability Statement
Advertisement of Link Identifiers is only really applicable to net-
works where all of the routers on a link can see each other. Envi-
ronments with routers that are linked to one another by wireless con-
nections that may come and go SHOULD NOT be using this approach.
Using LinkIDs to infer unreachability may also be inappropriate for
MNs using technologies where it is possible to receive packets at
layer three on a single interface from two separate links simultane-
ously. In such a case the MN may incorrectly assume that its previ-
ous AR is unreachable each time it receives an RA, resulting in
"ping-ponging" behaviour.
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 8]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
7. Protocol Constants
This document defines the following constants:
MAX_AMBIGUITY_TIME 5 seconds
8. IANA Considerations
Allocation by the IANA of an ICMPv6 Option Type for the Link Identi-
fier Option is requested.
9. Security Considerations
9.1. Mobile Nodes
This document describes a mechanism by which reception of an RA is
used by nodes to de-configure the current default router (and associ-
ated on-link addresses associated with this router). Additionally,
in many environments, movement detection is used as an instigator for
configuration signaling.
This allows trivial denial-of-service or elicitation of configuration
packets by an unauthorized LinkID advertiser, if hosts listen to
unverified RAs. Therefore, it is imperative that Router Advertise-
ments are verified using a robust authentication scheme, before nodes
take action based on received LinkID information[SENDPSREQ-03]. A
candidate scheme which may provide such authentication (under devel-
opment at the time of writing) is SEND (Secure Neighbour Discov-
ery)[SEND-00].
Current proposals which would allow a host to verify a router by val-
idation of a chain of trust. This trust chain describes the rela-
tionship of the router with an authority on the Internet, with whom
the host has some relationship (presumably through its own trust
chain). In [SEND-00], this information is elicited through sending
the potential router a Delegation Chain Solicitation.
The response Delegation Chain Advertisement (DCA) has similar proper-
ties to solicited Router Advertisement in [RFC-2461]. In particular,
there may be some delay before the advertisement arrives (around
0-500ms, or longer for multicast DCA). Until this advertisement
arrives and is processed, it is unsafe to believe that the router is
valid, or that the LinkID provided by the RA implies that movement
has occurred (and existing addresses or routers are invalid).
Therefore, all statements regarding reachability of a router assume
that a DCA has been received and verified before a host uses the
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 9]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
LinkID for movement confirmation. This may cause significant over-
head to movement detection times, even in the case that the initial
router advertisement is received quickly.
It is worth noting that hosts can be made to consume computation
resources in verification of delegation chains, as well as on-link
bandwidth through solicitation and acceptance of delegation
chains(DCS/DCA). Particularly, if a bogus router advertises a LinkID
in a multicast RA, any node which is using LinkIDs for movement
detection may solicit for DCA. This may lead to multicast bombing
similar to that described in [MDO-01], unless random delays are
undertaken before solicitation. Alternatively, such random delays
may be unnecessary if additional information, such as a link-layer
trigger, is available.
Finally, hosts are unaware of the significance of the Ambiguity Flag.
If the MN listens to packets with the Ambiguity Flag set, it may
become confused if this LinkID subsequently changes. Given that
packets with this flag set are only sent to the All-Routers multicast
group address, we consider that an MN which listens to these adver-
tisements gets what it deserves.
9.2. Access Routers
The process of establishing a common LinkID is also vulnerable to
attack if unverified RA messages are processed. Upon reception of a
LinkID in an RA, the configuring router needs to establish the
authority of the router which advertised the identifier.
Since the number of routers on a link may be small, it is possible
that routers be preconfigured with SAs or shared keys (from which
negotiations for SAs may be started) with their peer routers. The
aim of this specification was to provide a mechanism which allows
LinkID configuration without any such shared state. If there is no
a-priori knowledge of peer routers, any router which wishes to verify
an RA may do so using the same procedure described for hosts
(DCS/DCA).
Normative References
[RFC-2119] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. Request for Comments (Best Current Practice)
2119 (BCP 14), Internet Engineering Task Force, March 1997
[RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 10]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
[RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfigu-
ration. Request for Comments (Draft Standard) 2462, Internet
Engineering Task Force, December 1998.
[FASTRA-02] M. Khalil, J. Kempf, B. Pentland. IPv6 Fast Router Adver-
tisement (FastRA), Internet Draft (work in progress), October
2002.
[FRD-00] JinHyeock Choi, DongYun Shin. Fast Router Discovery with RA
Caching in AP. Internet Draft (work in progress), Feb 2003.
[MIPv6-22] D. Johnson, C. Perkins, J. Arkko. Mobility Support in
IPv6. Internet Draft (work in progress), May 2003.
[SEND-00] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill. "SEcure Neigh-
bor Discovery (SEND)", Internet draft (work in progress), Feb
2003.
Informative References
[SENDPSREQ-03] P. Nikander (ed), J. Kempf, E. Nordmark. "IPv6 Neigh-
bor Discovery Trust Models and Threats", Internet Draft (work in
progress), Apr 2003.
[MDO-01] G. Daley, JinHyeock Choi. "Movement Detection Optimization
in Mobile IPv6", Internet Draft (work in progress), May 2003.
[RFC-1750] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness
Recommendations for Security", RFC1750 (Informational), Dec 1994
[HINDSIGHT-00] E. Nordmark. "MIPv6: from hindsight to foresight?",
Expired Internet Draft, Nov 2001, Available at:
http://www.watersprings.org/pub/id/draft-nordmark-mobileip-
mipv6-hindsight-00.txt
Acknowledgements
Much of this work is based upon an idea which Erik Nordmark had
regarding being able to unambiguously identify a link for MIPv6 move-
ment detection [HINDSIGHT-00].
This work has been supported by the Australian Telecommunications CRC
and Samsung.
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 11]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
Authors' Addresses:
Brett.Pentland
E-mail: brett.pentland@monash.edu
Phone: +61-3-9905-5245
Greg Daley
E-mail: greg.daley@monash.edu
Phone: +61-3-9905-4655
Address:
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton 3800 Victoria
Australia
JinHyeock Choi
E-mail: athene@sait.samsung.co.kr
Phone: +82-31-280-9233
Address:
i-Networking Lab, Samsung AIT (SAIT)
Appendix : State Diagram
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 12]
INTERNET-DRAFT RA Link Identifier for Movement Detection May 2003
----------- -----------------
|Start | Link Down |Steady | AmbigTimer
|State: |<-----------|State: |<----\ Expiry,
|NO LINKID| /--->|LINKID, A=Unset|<--\ \No Conflicts
----------- / ----------------- \ \
Link| / ^ ^ Better | | Same
Up | /Recv | | LinkID | | /--\ LinkID:
| /LinkID | | A=Unset| | | | Remove
| /A=Unset | | | | V | Conflict
| / | | ---------------
| / Recv | | |Ambiguous |<--\ Worse
| / LinkID | |AmbigTimer |Master State:| | LinkID:
V / A=Unset| |Expiry |LINKID, A=Set|---/ Add
-------------- ----------------- --------------- Conflict
|Solicitation| |Ambiguous Slave| / ^ |
|State: |-------->|State: |<--- | | AmbigTimer
|NO LINKID | Recv |LINKID, A=Set |Better | | Expiry,
-------------- LinkID -----------------LinkID | \ Conflicts
| A=Set Better | ^ A=Set | \--> Sec 5.2.1
\ LinkID | | |
\ A=Set \--/ /
\ /
\---------------------------------------/
Solicit Timer Expiry
Changes Since Last Revision:
..
This document expires in November 2003.
Pentland et al. draft-pentland-mobileip-linkid-00.txt [Page 13]