DNA Working Group Brett Pentland
INTERNET-DRAFT Greg Daley
Expires: January 10, 2005 Monash University CTIE
JinHyeock Choi
Samsung AIT
July 12, 2004
Router Advertisement Link Identification
for Mobile IPv6 Movement Detection
draft-pentland-mobileip-linkid-01.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 in January, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 1]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 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. MN Operations.............................................. 4
4.1. 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.2.1. Conflicting Link ID Management................... 7
5.3. Advertising the Link ID............................... 8
6. Applicability Statement.................................... 8
7. Protocol Constants......................................... 9
8. IANA Considerations........................................ 9
9. Security Considerations.................................... 9
9.1. Mobile Nodes.......................................... 9
9.2. Access Routers........................................ 10
Normative References.......................................... 11
Informative References........................................ 11
Acknowledgements.............................................. 12
Authors' Addresses............................................ 12
Appendix : State Diagram...................................... 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
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
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 2]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
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.
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, 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.
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.
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 3]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
This information 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
[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 |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 identifier.
Generated randomly.
4. MN 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.
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
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 4]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
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
router.
If an MN 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. 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 solicits RAs from the network to determine if one is
available.
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
terminate Router Solicitation. 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
accordance with section 6.3.7 of [RFC-2461]. If this timer expires
without a LinkID being received by the router, it should generate its
own LinkID as described in section 5.2.
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 5]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
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
AmbigTimer is initially set to MAX_AMBIGUITY_TIME. Routers MUST
configure this LinkID, and advertise it to the All-Routers multicast
group. These advertisements are sent at the rate of one RA per
second. 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
resetting AmbigTimer.
If a router receives an RA with a non-zero LinkID which has the
Ambiguity 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
configuration. 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
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 6]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
LinkID is considered ambiguous since another router may have
generated 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
transmitted 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.
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.
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 7]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
The routers return to RA advertising without LinkID until their
interface is reset.
In the case where LinkID advertisement is disabled because of
conflicting LinkID, or upon the reception of zero-valued LinkIDs, a
system 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,
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 [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
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 8]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
connections 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
simultaneously. In such a case the MN may incorrectly assume that
its previous AR is unreachable each time it receives an RA, resulting
in "ping-ponging" behaviour.
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
Identifier 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
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 which 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
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 9]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
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.
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
advertisements 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).
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 10]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
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-
mipv6-hindsight-00.txt
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 11]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
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-01.txt [Page 12]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 2004
Appendix : State Diagram
----------- -----------------
|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:
IETF boilerplate text
Table of contents
Pentland et al. draft-pentland-mobileip-linkid-01.txt [Page 13]
INTERNET-DRAFT RA Link Identifier for Movement Detection July 12, 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-01.txt [Page 14]