draft-pentland-mobileip-linkid-02.txt   draft-pentland-mobileip-linkid-03.txt 
DNA Working Group Brett Pentland DNA Working Group Brett Pentland
INTERNET-DRAFT Greg Daley INTERNET-DRAFT Greg Daley
Expires: January 20, 2005 Monash University CTIE Expires: April 28, 2005 Monash University CTIE
JinHyeock Choi JinHyeock Choi
Samsung AIT Samsung AIT
July 19, 2004 October 25, 2004
Router Advertisement Link Identification Router Advertisement Link Identification
for Mobile IPv6 Movement Detection for Mobile IPv6 Movement Detection
draft-pentland-mobileip-linkid-02.txt draft-pentland-mobileip-linkid-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
  Skipping to change at page 1, line 37:
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire January 20, 2005. This Internet-Draft will expire April 28, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines a mechanism by which Access Routers on a link This document defines a mechanism by which Access Routers on a link
may automatically assign a consistent identifier to this link to aid may automatically assign a consistent identifier to this link to aid
in Movement Detection. This assists Movement Detection by allowing a in Movement Detection. This assists Movement Detection by allowing a
  Skipping to change at page 2, line 29:
3. Link ID Message Format..................................... 4 3. Link ID Message Format..................................... 4
4. Host Operations............................................ 4 4. Host Operations............................................ 4
4.1. Processing LinkIDs.................................... 4 4.1. Processing LinkIDs.................................... 4
4.2. Interoperation with Existing RAs...................... 5 4.2. Interoperation with Existing RAs...................... 5
5. Access Router Operations................................... 5 5. Access Router Operations................................... 5
5.1. Discovering the Link ID............................... 5 5.1. Discovering the Link ID............................... 5
5.2. Generating the Link ID................................ 6 5.2. Generating the Link ID................................ 6
5.3. Link ID Change Management............................. 6 5.3. Link ID Change Management............................. 6
5.3.1. Initiating Change................................ 6 5.3.1. Initiating Change................................ 6
5.3.2. Responding to Change............................. 7 5.3.2. Responding to Change............................. 7
5.4. Advertising the Link ID............................... 7 5.3.3. Joining Links.................................... 7
5.4. Advertising the Link ID............................... 8
6. Applicability Statement.................................... 8 6. Applicability Statement.................................... 8
7. IANA Considerations........................................ 8 7. IANA Considerations........................................ 9
8. Security Considerations.................................... 8 8. Security Considerations.................................... 9
8.1. Hosts................................................. 8 8.1. Hosts................................................. 9
8.2. Access Routers........................................ 9 8.2. Access Routers........................................ 10
Normative References.......................................... 10 Normative References.......................................... 10
Informative References........................................ 10 Informative References........................................ 11
Acknowledgements.............................................. 11 Acknowledgements.............................................. 11
Authors' Addresses............................................ 11 Authors' Addresses............................................ 11
Appendix : Alternative to Random Identifiers.................. 12 Appendix : Alternative to Random Identifiers.................. 13
1. Introduction 1. Introduction
Movement detection is the task of determining if an IPv6 node has Movement detection is the task of determining if an IPv6 node has
moved to a new network. This detection is important since in the moved to a new network. This detection is important since in the
case that the device has moved, addresses it has configured will be case that the device has moved, addresses it has configured will be
invalid and additional configuration must be undertaken to establish invalid and additional configuration must be undertaken to establish
or maintain upper layer connectivity. or maintain upper layer connectivity.
Movement detection is accomplished by determining that the current Movement detection is accomplished by determining that the current
  Skipping to change at page 5, line 40:
option. To do this ARs maintain two variables for each interface option. To do this ARs maintain two variables for each interface
where LinkID is being used: CurrentLinkID and ProspectiveLinkID. The where LinkID is being used: CurrentLinkID and ProspectiveLinkID. The
following sections describe mechanisms to discover, generate and following sections describe mechanisms to discover, generate and
advertise a LinkID. advertise a LinkID.
5.1. Discovering the Link ID 5.1. Discovering the Link ID
Upon bringing up an interface, an AR will be unaware of any LinkID in 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 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 link, it sends out Router-to-Router (RtR) Status Request messages as
defined in [DETFASTRA-00]. A LinkID option is placed in the Status 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 Request message and the value of LinkID in that option MUST be set to
zero. zero.
After an initial random delay of zero to MAX_RTR_STATUS_DELAY After an initial random delay of zero to MAX_RTR_STATUS_DELAY
milliseconds, the AR sends out MAX_RTR_STATUS_REQS Status Requests milliseconds, the AR sends out MAX_RTR_STATUS_REQS Status Requests
separated by RTR_STATUS_REQ_INTERVAL seconds and listens for Status separated by RTR_STATUS_REQ_INTERVAL seconds and listens for Status
messages in response. If one or more non-zero LinkIDs has been messages in response. If one or more non-zero LinkIDs has been
received at RetransTimer milliseconds after the last Status Request, received at RetransTimer milliseconds after the last Status Request,
then CurrentLinkID is set to the greatest value received (using then CurrentLinkID is set to the greatest value received (using
modulo 2^48-1 arithmetic). modulo 2^48-1 arithmetic).
If no non-zero LinkIDs have been received, then the AR should attempt If no non-zero LinkIDs have been received, then the AR should attempt
to generate one as described in section 5.2. to generate one as described in section 5.2.
5.2. Generating the Link ID 5.2. Generating the Link ID
If, at the end of procedure described in 5.1 no non-zero LinkIDs have 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 been received, the AR should generate a LinkID itself. If the AR is
generates a random 48-bit integer with due care to its randomness generating a LinkID for the first time after a system restart and has
[RFC-1750], and assigns it to ProspectiveLinkID. 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 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 link. After an initial random delay of zero to MAX_RTR_STATUS_DELAY
milliseconds, it transmits MAX_RTR_STATUS_REQS RtR Status messages on milliseconds, it transmits MAX_RTR_STATUS_REQS RtR Status messages on
the All-Routers multicast address, separated by the All-Routers multicast address, separated by
RTR_STATUS_REQ_INTERVAL seconds. RTR_STATUS_REQ_INTERVAL seconds.
This period of LinkID propagation ends at RetransTimer seconds after This period of LinkID propagation ends at RetransTimer seconds after
the last RtR Status message is sent. If the end is reached without 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 receiving any non-zero LinkIDs that do not match the LinkID being
  Skipping to change at page 6, line 46:
5.3. Link ID Change Management 5.3. Link ID Change Management
During normal operation, there should be no reason to change the 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 LinkID being used on a link, but it should be possible for the LinkID
to be changed at an administrator's request. to be changed at an administrator's request.
5.3.1. Initiating Change 5.3.1. Initiating Change
At any time an AR may initiate LinkID change. It does so by first At any time an AR may initiate LinkID change. It does so by first
sending out MAX_RTR_STATUS_REQS multicast RAs, separated by sending out MAX_INITIAL_RTR_ADVERTISEMENTS multicast RAs, separated
MIN_DELAY_BETWEEN_RAS with the old LinkID and at least one valid PIO. by MIN_DELAY_BETWEEN_RAS with the old LinkID and at least one valid
The first should be delayed if necessary to respect PIO. The first should be delayed if necessary to respect
MIN_DELAY_BETWEEN_RAS from any previous multicast RA. It should also MIN_DELAY_BETWEEN_RAS from any previous multicast RA. It should also
be delayed by a small random interval if LinkID change is being be delayed by a small random interval if LinkID change is being
triggered by something that could allow synchronization between triggered by something that could allow synchronization between
multiple routers. Any solicited RAs sent during this time should multiple routers. Any solicited RAs sent during this time should
also use the old LinkID and have at least one valid PIO. also use the old LinkID and have at least one valid PIO.
During this process, the AR generates a new non-zero LinkID, multiple During this process, the AR generates a new non-zero LinkID, multiple
times if necessary to ensure that it is greater than CurrentLinkID times if necessary to ensure that it is greater than CurrentLinkID
(using modulo 2^48-1 arithmetic) and assigns it to ProspectiveLinkID. (using modulo 2^48-1 arithmetic) and assigns it to ProspectiveLinkID.
It then propagates ProspectiveLinkID to the other routers on the link It then propagates ProspectiveLinkID to the other routers on the link
using the mechanism described in section 5.2. using the mechanism described in section 5.2.
The AR then simply starts using the new LinkID. It should transmit The AR then simply starts using the new LinkID. It should transmit
MAX_RTR_STATUS_REQS multicast RAs, separated by MIN_DELAY_BETWEEN_RAS MAX_INITIAL_RTR_ADVERTISEMENTS multicast RAs, separated by
with the new LinkID and with a PIO that matches one sent with the old MIN_DELAY_BETWEEN_RAS with the new LinkID and with a PIO that matches
LinkID. one sent with the old LinkID.
5.3.2. Responding to Change 5.3.2. Responding to Change
If an AR receives an RtR Status message with a LinkID option that is 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 greater than its value of CurrentLinkID (modulo 2^48-1), it sets
ProspectiveLinkID to this new value. ProspectiveLinkID to this new value.
The AR should wait MAX_RTR_STATUS_REQS * RTR_STATUS_REQ_INTERVAL The AR should wait MAX_RTR_STATUS_REQS * RTR_STATUS_REQ_INTERVAL
seconds for the LinkID propagation period to finish, monitoring RtR seconds for the LinkID propagation period to finish, monitoring RtR
Status messages for any changes to the LinkID, updating Status messages for any changes to the LinkID, updating
ProspectiveLinkID as appropriate. At the end of this period the AR ProspectiveLinkID as appropriate. At the end of this period the AR
should send out MAX_RTR_STATUS_REQS multicast RAs, separated by should send out MAX_INITIAL_RTR_ADVERTISEMENTS multicast RAs,
MIN_DELAY_BETWEEN_RAS with the old LinkID and at least one valid PIO. 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 The AR can then set CurrentLinkID to ProspectiveLinkID and transmit
MAX_RTR_STATUS_REQS multicast RAs, separated by MIN_DELAY_BETWEEN_RAS MAX_INITIAL_RTR_ADVERTISEMENTS multicast RAs, separated by
with the LinkID set to CurrentLinkID and with a PIO that matches one MIN_DELAY_BETWEEN_RAS with the LinkID set to CurrentLinkID and with a
sent with the old LinkID. 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
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 5.4. Advertising the Link ID
Advertisement of Link Identifier Options in RAs MUST be configurable Advertisement of Link Identifier Options in RAs MUST be configurable
on a per-interface basis. on a per-interface basis.
When configured to send LinkID options in RAs for a given interface, When configured to send LinkID options in RAs for a given interface,
an AR MUST monitor Router Status messages on that link and be an AR MUST monitor Router Status messages on that link and be
prepared to change its advertised LinkID for that interface as prepared to change its advertised LinkID for that interface as
described in section 5.2.1. described in section 5.2.1.
  Skipping to change at page 8, line 7:
During the initial period of discovering the LinkID (section 5.1), an During the initial period of discovering the LinkID (section 5.1), an
AR SHOULD NOT include LinkID options in RAs. This is to avoid AR SHOULD NOT include LinkID options in RAs. This is to avoid
excessive changing of the advertised LinkID when machines start up excessive changing of the advertised LinkID when machines start up
simultaneously after, say, a power failure. simultaneously after, say, a power failure.
Once the LinkID has been determined, an AR SHOULD advertise the 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 LinkID in every RA it sends from an interface where the use of LinkID
is enabled. This encourages consistently fast movement detection for is enabled. This encourages consistently fast movement detection for
mobile nodes arriving on a network. mobile nodes arriving on a network.
The LinkID advertised is always CurrentLinkID. 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 One side benefit of requiring LinkID options in RAs on supporting
Routers, is that using LinkIDs may remove the necessity to advertise Routers, is that using LinkIDs may remove the necessity to advertise
PIOs in all unsolicited RAs. Upon receiving a LinkID that indicates a 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 change of link, a host is then able to solicit the router for new
addressing information. This may be an important overhead saving in addressing information. This may be an important overhead saving in
the case that the router is advertising RAs at the highest rates the case that the router is advertising RAs at the highest rates
allowed in [RFC-3775]. allowed in [RFC-3775].
6. Applicability Statement 6. Applicability Statement
  Skipping to change at page 10, line 11:
that routers be preconfigured with SAs or shared keys (from which that routers be preconfigured with SAs or shared keys (from which
negotiations for SAs may be started) with their peer routers. The negotiations for SAs may be started) with their peer routers. The
aim of this specification was to provide a mechanism which allows aim of this specification was to provide a mechanism which allows
LinkID configuration without any such shared state. If there is no LinkID configuration without any such shared state. If there is no
a-priori knowledge of peer routers, any router which wishes to verify a-priori knowledge of peer routers, any router which wishes to verify
a Router Status message may do so using the same procedure described a Router Status message may do so using the same procedure described
for hosts (DCS/DCA). for hosts (DCS/DCA).
Normative References 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 [RFC-2119] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. Request for Comments (Best Current Practice) Requirement Levels. Request for Comments (Best Current Practice)
2119 (BCP 14), Internet Engineering Task Force, March 1997 2119 (BCP 14), Internet Engineering Task Force, March 1997
[RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for [RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998. Internet Engineering Task Force, December 1998.
[RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address [DETFASTRA-01] G. Daley, B. Pentland, E. Nordmark. Deterministic Fast
Autoconfiguration. Request for Comments (Draft Standard) 2462, Router Advertisement Configuration, Internet Draft (work in
Internet Engineering Task Force, December 1998. progress), October 2004.
[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)", [SEND-05] J. Arkko et al. "SEcure Neighbor Discovery (SEND)",
Internet draft (work in progress), April 2004. Internet draft (work in progress), April 2004.
Informative References 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 [RFC-3756] P. Nikander (ed), J. Kempf, E. Nordmark. "IPv6 Neighbor
Discovery Trust Models and Threats", Request for Comments Discovery Trust Models and Threats", Request for Comments
(Informational) 3775, May 2004. (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 [MDO-01] G. Daley, JinHyeock Choi. "Movement Detection Optimization
in Mobile IPv6", Internet Draft (work in progress), May 2003. in Mobile IPv6", Internet Draft (work in progress), May 2003.
[RFC-1750] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness [FASTRA-04] M. Khalil, J. Kempf, B. Pentland. IPv6 Fast Router
Recommendations for Security", RFC1750 (Informational), Dec 1994 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?", [HINDSIGHT-00] E. Nordmark. "MIPv6: from hindsight to foresight?",
Expired Internet Draft, Nov 2001, Available at: Expired Internet Draft, Nov 2001, Available at:
http://www.watersprings.org/pub/id/draft-nordmark-mobileip- http://www.watersprings.org/pub/id/draft-nordmark-mobileip-
mipv6-hindsight-00.txt mipv6-hindsight-00.txt
Acknowledgements Acknowledgements
Much of this work is based upon an idea which Erik Nordmark had Much of this work is based upon an idea which Erik Nordmark had
regarding being able to unambiguously identify a link for MIPv6 regarding being able to unambiguously identify a link for MIPv6
 End of changes. 

This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/