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]