[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
DNA Working Group                                        Brett Pentland
INTERNET-DRAFT                                               Greg Daley
Expires: January 20, 2005                        Monash University CTIE
                                                         JinHyeock Choi
                                                            Samsung AIT
                                                          July 19, 2004


                Router Advertisement Link Identification
                   for Mobile IPv6 Movement Detection
                 draft-pentland-mobileip-linkid-02.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 January 20, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.










Pentland et al.   draft-pentland-mobileip-linkid-02.txt         [Page 1]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 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.4. Advertising the Link ID...............................  7
   6. Applicability Statement....................................  8
   7. IANA Considerations........................................  8
   8. Security Considerations....................................  8
      8.1. Hosts.................................................  8
      8.2. Access Routers........................................  9
   Normative References.......................................... 10
   Informative References........................................ 10
   Acknowledgements.............................................. 11
   Authors' Addresses............................................ 11
   Appendix : Alternative to Random Identifiers.................. 12

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



Pentland et al.   draft-pentland-mobileip-linkid-02.txt         [Page 2]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 2004


   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
   currently recorded value of LinkID, the host has a strong indication



Pentland et al.   draft-pentland-mobileip-linkid-02.txt         [Page 3]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 2004


   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.

   If the received LinkID in an RA differs from the value of



Pentland et al.   draft-pentland-mobileip-linkid-02.txt         [Page 4]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 2004


   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-00].  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-02.txt         [Page 5]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 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.  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_RTR_STATUS_REQS 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
   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



Pentland et al.   draft-pentland-mobileip-linkid-02.txt         [Page 6]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 2004


   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_RTR_STATUS_REQS 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_RTR_STATUS_REQS 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_RTR_STATUS_REQS 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.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



Pentland et al.   draft-pentland-mobileip-linkid-02.txt         [Page 7]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 2004


   is enabled.  This encourages consistently fast movement detection for
   mobile nodes arriving on a network.

   The LinkID advertised is always CurrentLinkID.

   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
   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



Pentland et al.   draft-pentland-mobileip-linkid-02.txt         [Page 8]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 2004


   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
   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



Pentland et al.   draft-pentland-mobileip-linkid-02.txt         [Page 9]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 2004


   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-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.

   [RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address
        Autoconfiguration.  Request for Comments (Draft Standard) 2462,
        Internet Engineering Task Force, December 1998.

   [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.

   [RFC-3775] D. Johnson, C. Perkins, J. Arkko.  Mobility Support in
        IPv6.  Request for Comments (Proposed Standard) 3775, June 2004.

   [SEND-05] J. Arkko et al. "SEcure Neighbor Discovery (SEND)",
        Internet draft (work in progress), April 2004.

Informative References


   [RFC-3756] P. Nikander (ed), J. Kempf, E. Nordmark. "IPv6 Neighbor
        Discovery Trust Models and Threats", Request for Comments
        (Informational) 3775,  May 2004.

   [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-



Pentland et al.   draft-pentland-mobileip-linkid-02.txt        [Page 10]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 2004


        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

   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-02.txt        [Page 11]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 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-02.txt        [Page 12]


INTERNET-DRAFT  RA Link Identifier for Movement Detection      July 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-02.txt        [Page 13]