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