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]