DNA Working Group Brett Pentland INTERNET-DRAFT Greg Daley Expires: April 28, 2005 Monash University CTIE JinHyeock Choi Samsung AIT October 25, 2004 Router Advertisement Link Identification for Mobile IPv6 Movement Detection draft-pentland-mobileip-linkid-03.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire April 28, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 1] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 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. Table of Contents Abstract...................................................... 2 Table of Contents............................................. 2 1. Introduction............................................... 2 2. Link Identifiers for Movement Detection.................... 3 3. Link ID Message Format..................................... 4 4. Host Operations............................................ 4 4.1. Processing LinkIDs.................................... 4 4.2. Interoperation with Existing RAs...................... 5 5. Access Router Operations................................... 5 5.1. Discovering the Link ID............................... 5 5.2. Generating the Link ID................................ 6 5.3. Link ID Change Management............................. 6 5.3.1. Initiating Change................................ 6 5.3.2. Responding to Change............................. 7 5.3.3. Joining Links.................................... 7 5.4. Advertising the Link ID............................... 8 6. Applicability Statement.................................... 8 7. IANA Considerations........................................ 9 8. Security Considerations.................................... 9 8.1. Hosts................................................. 9 8.2. Access Routers........................................ 10 Normative References.......................................... 10 Informative References........................................ 11 Acknowledgements.............................................. 11 Authors' Addresses............................................ 11 Appendix : Alternative to Random Identifiers.................. 13 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 Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 2] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 previous efforts at movement detection have aimed at speeding up discovery of new routers with Router Advertisements(RAs) [FASTRA-04][FRD-00] and discounted the requirement for determining current router reachability[RFC-3775][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. 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. Hosts 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 hosts to determine when the link changes. A change to the LinkID implies to the host 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, consistent 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. Hosts store the Link Identifier internally, for comparison with subsequently received Router Advertisements. Upon receiving an RA with a LinkID that differs from the host's Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 3] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 currently recorded value of LinkID, the host has a strong indication that it has moved to a new network and that its current default router is unreachable. This information may be used to initiate further stateful or stateless autoconfiguration procedures, or appropriate mobility signalling by the host. When a host receives an RA from a previously unseen router, which contains the same LinkID as its default, this means the host 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 [RFC-3775]. 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LinkID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA (suggest 203) Length 1 LinkID 48-bit unsigned integer. Link identifier. Generated randomly. 4. Host Operations Link Identifiers assist in the determination of whether advertisements received from different routers are from the same link. This is possible because multiple routers on a link will share the same LinkID. 4.1. Processing LinkIDs Hosts 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. Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 4] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 If the received LinkID in an RA differs from the value of CurrentLinkID it is likely that this RA represents movement to a new link. There may be circumstances where it is desirable for a link's LinkID to change so a node that has just detected a changing LinkID should compare the prefix information options (PIO) in the RA to its current list of valid prefixes. If there are no matches, the host should assume that it is on a new link. The host should then mark its current default router as unreachable and commence router discovery. 4.2. Interoperation with existing RAs If a host 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 host SHOULD proceed to confirm bi- directional reachability or otherwise with its current default router. If a host starts receiving Link Identifiers and the LinkID is not currently 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. To do this ARs maintain two variables for each interface where LinkID is being used: CurrentLinkID and ProspectiveLinkID. The following sections describe mechanisms to discover, generate 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 sends out Router-to-Router (RtR) Status Request messages as defined in [DETFASTRA-01]. A LinkID option is placed in the Status Request message and the value of LinkID in that option MUST be set to zero. After an initial random delay of zero to MAX_RTR_STATUS_DELAY milliseconds, the AR sends out MAX_RTR_STATUS_REQS Status Requests separated by RTR_STATUS_REQ_INTERVAL seconds and listens for Status messages in response. If one or more non-zero LinkIDs has been received at RetransTimer milliseconds after the last Status Request, then CurrentLinkID is set to the greatest value received (using modulo 2^48-1 arithmetic). Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 5] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 If no non-zero LinkIDs have been received, then the AR should attempt to generate one as described in section 5.2. 5.2. Generating the Link ID If, at the end of procedure described in 5.1 no non-zero LinkIDs have been received, the AR should generate a LinkID itself. If the AR is generating a LinkID for the first time after a system restart and has a previously used LinkID for this interface stored in non-volatile memory it SHOULD use this value in order to maintain continuity across restarts. If not, the AR generates a random 48-bit integer with due care to its randomness [RFC-1750], and assigns it to ProspectiveLinkID. The AR then attempts to propagate this to any other routers on the link. After an initial random delay of zero to MAX_RTR_STATUS_DELAY milliseconds, it transmits MAX_RTR_STATUS_REQS RtR Status messages on the All-Routers multicast address, separated by RTR_STATUS_REQ_INTERVAL seconds. This period of LinkID propagation ends at RetransTimer seconds after the last RtR Status message is sent. If the end is reached without receiving any non-zero LinkIDs that do not match the LinkID being transmitted, CurrentLinkID is set equal to ProspectiveLinkID and is used for transmission in Router Advertisements. If, during the propagation period, a non-zero LinkID is received that does not match the generated value, the two are compared and the greater, using modulo 2^48-1 arithmetic, assigned to ProspectiveLinkID, and is used in future transmissions. If no change takes place, operation continues as before, otherwise counters are reset and the propagation period begins afresh. At the end of the period, CurrentLinkID is set equal to ProspectiveLinkID. 5.3. Link ID Change Management During normal operation, there should be no reason to change the LinkID being used on a link, but it should be possible for the LinkID to be changed at an administrator's request. 5.3.1. Initiating Change At any time an AR may initiate LinkID change. It does so by first sending out MAX_INITIAL_RTR_ADVERTISEMENTS multicast RAs, separated by MIN_DELAY_BETWEEN_RAS with the old LinkID and at least one valid PIO. The first should be delayed if necessary to respect Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 6] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 MIN_DELAY_BETWEEN_RAS from any previous multicast RA. It should also be delayed by a small random interval if LinkID change is being triggered by something that could allow synchronization between multiple routers. Any solicited RAs sent during this time should also use the old LinkID and have at least one valid PIO. During this process, the AR generates a new non-zero LinkID, multiple times if necessary to ensure that it is greater than CurrentLinkID (using modulo 2^48-1 arithmetic) and assigns it to ProspectiveLinkID. It then propagates ProspectiveLinkID to the other routers on the link using the mechanism described in section 5.2. The AR then simply starts using the new LinkID. It should transmit MAX_INITIAL_RTR_ADVERTISEMENTS multicast RAs, separated by MIN_DELAY_BETWEEN_RAS with the new LinkID and with a PIO that matches one sent with the old LinkID. 5.3.2. Responding to Change If an AR receives an RtR Status message with a LinkID option that is greater than its value of CurrentLinkID (modulo 2^48-1), it sets ProspectiveLinkID to this new value. The AR should wait MAX_RTR_STATUS_REQS * RTR_STATUS_REQ_INTERVAL seconds for the LinkID propagation period to finish, monitoring RtR Status messages for any changes to the LinkID, updating ProspectiveLinkID as appropriate. At the end of this period the AR should send out MAX_INITIAL_RTR_ADVERTISEMENTS multicast RAs, separated by MIN_DELAY_BETWEEN_RAS with the old LinkID and at least one valid PIO. The AR can then set CurrentLinkID to ProspectiveLinkID and transmit MAX_INITIAL_RTR_ADVERTISEMENTS multicast RAs, separated by MIN_DELAY_BETWEEN_RAS with the LinkID set to CurrentLinkID and with a PIO that matches one sent with the old LinkID. 5.3.3. Joining Links It is possible that two links on which LinkIDs are being used are joined to form a single link. This may happen when a link is partitioned but then heals. In this case, the routers need to recognise the situation and agree on a single identifier for the combined link. If an AR receives an RA from another router on the link that contains a LinkID that is greater than CurrentLinkID (modulo 2^48-1), it MUST set CurrentLinkID to this new value and start using it immediately, rather than following the procedure in 5.3.2. This is because hosts Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 7] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 will have already heard the RA that initiated the change with its new LinkID, and it's in our interests to settle on a consistent LinkID as quickly as possible. This will minimise the amount of "ping-ponging" that hosts do in the event that there are no common prefixes between the two joined links. 5.4. 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 MUST monitor Router Status messages on that link and be prepared to change its advertised LinkID for that interface as described in section 5.2.1. During the initial period of discovering the LinkID (section 5.1), an AR SHOULD NOT include LinkID options in RAs. This is to avoid excessive changing of the advertised LinkID when machines start up simultaneously after, say, a power failure. Once the LinkID has been determined, an AR SHOULD advertise the LinkID in every RA it sends from an interface where the use of LinkID is enabled. This encourages consistently fast movement detection for mobile nodes arriving on a network. The LinkID advertised MUST always be set to CurrentLinkID. The value of CurrentLinkID SHOULD be stored in non-volatile storage if such storage is available to aid in maintaining continuity of the LinkID across router restarts. One side benefit of requiring LinkID options in RAs on supporting Routers, is that using LinkIDs may remove the necessity to advertise PIOs in all unsolicited RAs. Upon receiving a LinkID that indicates a change of link, a host 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 [RFC-3775]. 6. Applicability Statement Advertisement of Link Identifiers is only really applicable to networks where all of the routers on a link can see each other. Environments with routers that are linked to one another by wireless connections that may come and go SHOULD NOT be using this approach. Using LinkIDs to infer unreachability may also be inappropriate for Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 8] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 hosts using technologies where it is possible to receive packets at layer three on a single interface from two separate links simultaneously. In such a case the host may incorrectly assume that its previous AR is unreachable each time it receives an RA, resulting in "ping-ponging" behaviour. 7. IANA Considerations Allocation by the IANA of an ICMPv6 ND Option Type for the Link Identifier Option is requested. Suggested value: 203. 8. Security Considerations 8.1. Hosts This document describes a mechanism by which reception of an RA is used by nodes to de-configure the current default router (and associated 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 Advertisements are verified using a robust authentication scheme, before nodes take action based on received LinkID information[RFC-3756]. A candidate scheme which may provide such authentication (under development at the time of writing) is SEND (Secure Neighbour Discovery)[SEND-05]. Current proposals would allow a host to verify a router by validation of a chain of trust. This trust chain describes the relationship of the router with an authority on the Internet, with whom the host has some relationship (presumably through its own trust chain). In [SEND-05], this information is elicited through sending the potential router a Delegation Chain Solicitation. The response Delegation Chain Advertisement (DCA) has similar properties 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-03.txt [Page 9] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 LinkID for movement confirmation. This may cause significant overhead 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. 8.2. Access Routers The process of establishing a common LinkID is also vulnerable to attack if unverified RtR messages are processed. Upon reception of a LinkID in a Router Status message, 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 a Router Status message may do so using the same procedure described for hosts (DCS/DCA). Normative References [RFC-1750] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness Recommendations for Security", RFC1750 (Informational), Dec 1994 [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. [DETFASTRA-01] G. Daley, B. Pentland, E. Nordmark. Deterministic Fast Router Advertisement Configuration, Internet Draft (work in progress), October 2004. Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 10] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 [SEND-05] J. Arkko et al. "SEcure Neighbor Discovery (SEND)", Internet draft (work in progress), April 2004. Informative References [RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [RFC-3756] P. Nikander (ed), J. Kempf, E. Nordmark. "IPv6 Neighbor Discovery Trust Models and Threats", Request for Comments (Informational) 3756, May 2004. [RFC-3775] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6. Request for Comments (Proposed Standard) 3775, June 2004. [MDO-01] G. Daley, JinHyeock Choi. "Movement Detection Optimization in Mobile IPv6", Internet Draft (work in progress), May 2003. [FASTRA-04] M. Khalil, J. Kempf, B. Pentland. IPv6 Fast Router Advertisement (FastRA), Internet Draft (work in progress), September 2003. [FRD-00] JinHyeock Choi, DongYun Shin. Fast Router Discovery with RA Caching in AP. Internet Draft (work in progress), Feb 2003. [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 movement detection [HINDSIGHT-00]. This work has been supported by the Australian Telecommunications CRC and Samsung. Authors' Addresses: Brett Pentland E-mail: brett.pentland@eng.monash.edu.au Phone: +61-3-9905-5245 Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 11] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 Greg Daley E-mail: greg.daley@eng.monash.edu.au 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) Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 12] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 Appendix : Alternative to Random Identifiers The purpose of LinkID is to allow a host to quickly determine if an RA it receives is from the same link as its current default router or if it is from a new link, thus requiring the host to perform some configuration tasks. To do this, the LinkID used on a link must be different from the LinkIDs being used on any adjacent networks. This is a far less stringent requirement than being different from every other link in the world. If we have a set of 100 adjacent networks, then using 48-bit random identifiers there is a probability of approximately 2*10^-11 of there being any collisions. Though the Internet is not arranged this way, it is perhaps worth noting that if it were made up of 10,000,000 non- adjacent sets of 100 adjacent networks (ie. we are only concerned with collisions within each 100-network group), then the probability of there being a concerning collision is approximately 2*10-4 anywhere in this fictitious network. And even then the problem is handovers that go initially un-noticed, requiring several seconds to be dealt with, and the problem is fixed by an administrator simply telling one of the routers to initiate a LinkID change. If it is considered that this is unacceptable, if may be possible to alter this protocol to use globally unique identifiers. Global address prefixes can only be used on one link at a time and so may be a candidate. Some links may not have global prefixes assigned to them so careful consideration needs to be given to whether local- scope prefixes could be used in certain circumstances. Another alternative may be to use random identifiers on these links. The down side to using address prefixes is that they are generally 64 bits long. This means that the LinkID option would not fit into 8 bytes, and then next size up is 16 bytes. One of our goals was to keep the size of the identifier down since it is desirable to have it sent in all RAs. On networks supporting mobility, the rate that RAs are sent can be quite high and it would be good to keep the overhead associated with LinkID to a minimum. In fact it was noted in section 5.3 that it may be possible to reduce overhead by omitting PIOs altogether in the unsolicited multicast RAs that are used as beacons on such networks. Changes Since Last Revision: Removed concept of ambiguity of LinkID Simplified process of selecting LinkID Added appendix comparing random IDs to globally unique ones Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 13] INTERNET-DRAFT RA Link Identifier for Movement Detection October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pentland et al. draft-pentland-mobileip-linkid-03.txt [Page 14]