draft-daley-dna-det-fastra-00.txt | draft-daley-dna-det-fastra-01.txt | |
---|---|---|
DNA Working Group G. Daley | DNA Working Group G. Daley | |
Internet-Draft B. Pentland | Internet-Draft B. Pentland | |
Expires: January 10, 2005 Monash University CTIE | Expires: April 25, 2005 Monash University CTIE | |
E. Nordmark | E. Nordmark | |
Sun Microsystems | Sun Microsystems | |
July 12, 2004 | October 25, 2004 | |
Deterministic Fast Router Advertisement Configuration | Deterministic Fast Router Advertisement Configuration | |
draft-daley-dna-det-fastra-00.txt | draft-daley-dna-det-fastra-01.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 36: | ||
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 on January 10, 2005. | This Internet-Draft will expire on April 25, 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 | |
Neighbour Discovery forces routers responding to Router Solicitations | Neighbour Discovery forces routers responding to Router Solicitations | |
to delay a random interval of 0-500 ms in order to prevent contention | to delay a random interval of 0-500 ms in order to prevent contention | |
and bandwidth utilization by multiple responding routers. Routers | and bandwidth utilization by multiple responding routers. Routers | |
Skipping to change at page 2, line 16: | ||
allow hosts to securely agree on the relative ordering and delay of | allow hosts to securely agree on the relative ordering and delay of | |
their Fast Router Advertisements. | their Fast Router Advertisements. | |
Table of Contents | Table of Contents | |
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 | |
3.1 Deterministic Fast Router Advertisement Concepts . . . . . 6 | 3.1 Deterministic Fast Router Advertisement Concepts . . . . . 6 | |
3.2 Router-to-Router Status Communication . . . . . . . . . . 7 | 3.2 Router-to-Router Status Communication . . . . . . . . . . 7 | |
3.3 Deterministic Fast Router Advertisement Options . . . . . 8 | 3.3 Deterministic Fast Router Advertisement Options . . . . . 7 | |
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 | |
4.1 Router to Router ICMPv6 message . . . . . . . . . . . . . 8 | 4.1 Router to Router ICMPv6 message . . . . . . . . . . . . . 8 | |
4.2 Deterministic Fast Router Advertisement Option Format . . 10 | 4.2 Deterministic Fast Router Advertisement Option Format . . 10 | |
4.2.1 Rank . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.2.1 Rank . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |
4.2.2 Fixed Delay . . . . . . . . . . . . . . . . . . . . . 12 | 4.2.2 Fixed Delay . . . . . . . . . . . . . . . . . . . . . 12 | |
4.2.3 Separation . . . . . . . . . . . . . . . . . . . . . . 12 | 4.2.3 Separation . . . . . . . . . . . . . . . . . . . . . . 12 | |
4.2.4 Relative Preference . . . . . . . . . . . . . . . . . 12 | 4.2.4 Relative Preference . . . . . . . . . . . . . . . . . 12 | |
5. Sending Router-to-Router messages . . . . . . . . . . . . . . 12 | 5. Sending Router-to-Router messages . . . . . . . . . . . . . . 12 | |
5.1 Sending Router-to-Router Status-Requests . . . . . . . . . 12 | 5.1 Sending Router-to-Router Status-Requests . . . . . . . . . 12 | |
5.2 Sending Router-to-Router Status . . . . . . . . . . . . . 13 | 5.2 Sending Router-to-Router Status . . . . . . . . . . . . . 13 | |
6. Ranking Calculation . . . . . . . . . . . . . . . . . . . . . 13 | 6. Ranking Calculation . . . . . . . . . . . . . . . . . . . . . 13 | |
6.1 Ranking Score Calculation Reasoning . . . . . . . . . . . 14 | 6.1 Ranking Score Calculation Reasoning . . . . . . . . . . . 14 | |
7. Becoming a Fast Router . . . . . . . . . . . . . . . . . . . . 14 | 7. Becoming a Fast Router . . . . . . . . . . . . . . . . . . . . 15 | |
8. Receiving DetFRAO in ICMPv6 Router-to-Router . . . . . . . . . 15 | 8. Receiving DetFRAO in ICMPv6 Router-to-Router . . . . . . . . . 15 | |
8.1 Dealing with Duplicate List Entries . . . . . . . . . . . 15 | 8.1 Receiving Bootstrap Deterministic FastRA Options . . . . . 16 | |
8.2 Receiving Bootstrap Deterministic FastRA Options . . . . . 16 | 8.2 Cleaning up old entries . . . . . . . . . . . . . . . . . 16 | |
8.3 Cleaning up old entries . . . . . . . . . . . . . . . . . 16 | 8.3 Responding to Status-Requests with DetFRAO . . . . . . . . 16 | |
8.4 Responding to Status-Requests with DetFRAO . . . . . . . . 17 | 9. Sending DetFRAOs in ICMPv6 Router-to-Router . . . . . . . . . 16 | |
9. Sending DetFRAOs in ICMPv6 Router-to-Router . . . . . . . . . 17 | ||
9.1 Sending RAs on Rank or Delay Change . . . . . . . . . . . 17 | 9.1 Sending RAs on Rank or Delay Change . . . . . . . . . . . 17 | |
9.2 Sending Advertisement Intervals . . . . . . . . . . . . . 17 | 9.2 Sending Advertisement Intervals . . . . . . . . . . . . . 17 | |
10. Sending Fast Router Advertisements . . . . . . . . . . . . . 17 | 10. Sending Fast Router Advertisements . . . . . . . . . . . . . 17 | |
10.1 Sending Unicast Fast RAs . . . . . . . . . . . . . . . . . 18 | 10.1 Sending Unicast Fast RAs . . . . . . . . . . . . . . . . . 18 | |
10.2 Sending Multicast Fast RAs . . . . . . . . . . . . . . . . 18 | 10.2 Sending Multicast Fast RAs . . . . . . . . . . . . . . . . 18 | |
11. Interaction with Other Routers . . . . . . . . . . . . . . . 19 | 11. Interaction with Other Routers . . . . . . . . . . . . . . . 18 | |
11.1 Presence of Legacy Routers . . . . . . . . . . . . . . . . 19 | 11.1 Presence of Legacy Routers . . . . . . . . . . . . . . . . 18 | |
11.2 Ceasing to be a Fast Router . . . . . . . . . . . . . . . 19 | 11.2 Ceasing to be a Fast Router . . . . . . . . . . . . . . . 19 | |
11.3 Presence of Non Fast Routers . . . . . . . . . . . . . . . 19 | 11.3 Presence of Non Fast Routers . . . . . . . . . . . . . . . 19 | |
11.4 Presence of Incompatible Fast Routers . . . . . . . . . . 20 | 11.4 Presence of Incompatible Fast Routers . . . . . . . . . . 19 | |
12. Host interaction with DetFRAOs . . . . . . . . . . . . . . . 20 | 12. Configuration Parameters . . . . . . . . . . . . . . . . . . 20 | |
12.1 Host Transmission of DetFRAOs . . . . . . . . . . . . . . 20 | 13. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 20 | |
12.2 Reception of DetFRAOs in Router Solicitations . . . . . . 20 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 | |
12.3 Transmission of DetFRAOs in Router Advertisements . . . . 20 | 15. Security Considerations . . . . . . . . . . . . . . . . . . 21 | |
12.4 Host Reception of DetFRAOs . . . . . . . . . . . . . . . . 20 | 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22 | |
13. Configuration Parameters . . . . . . . . . . . . . . . . . . 21 | 17. Changes Since Last Revision . . . . . . . . . . . . . . . . 22 | |
14. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 22 | 17.1 draft-daley-dna-det-fastra-00 to -01 . . . . . . . . . . . 22 | |
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 | 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |
16. Security Considerations . . . . . . . . . . . . . . . . . . 23 | 18.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 | |
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24 | 18.2 Informative References . . . . . . . . . . . . . . . . . . . 23 | |
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 | |
18.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 | A. State Diagram . . . . . . . . . . . . . . . . . . . . . . . . 24 | |
18.2 Informative References . . . . . . . . . . . . . . . . . . . 24 | Intellectual Property and Copyright Statements . . . . . . . . 26 | |
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 | ||
A. State Diagram . . . . . . . . . . . . . . . . . . . . . . . . 25 | ||
Intellectual Property and Copyright Statements . . . . . . . . 27 | ||
1. Introduction | 1. Introduction | |
Existing standards require that hosts which respond to Router | Existing standards require that hosts which respond to Router | |
Solicitations introduce a random delay of 0-500ms before sending a | Solicitations introduce a random delay of 0-500ms before sending a | |
Router Advertisement [2]. | Router Advertisement [2]. | |
The Fast RA draft [6] introduces the concept of a Fast Router | The Fast RA draft [6] introduces the concept of a Fast Router | |
Advertisement. Fast Router advertisements provide the capability for | Advertisement. Fast Router advertisements provide the capability for | |
a router to avoid performing the random delay before transmission, | a router to avoid performing the random delay before transmission, | |
Skipping to change at page 5, line 8: | ||
2. Terminology | 2. Terminology | |
The following terms are used throughout the document | The following terms are used throughout the document | |
Bootstrapping Router: A router which has not yet determined its rank | Bootstrapping Router: A router which has not yet determined its rank | |
and delay for Fast Router Advertisement. | and delay for Fast Router Advertisement. | |
Deterministic Fast Router Advertisement Option (DetFRAO): An ICMPv6 | Deterministic Fast Router Advertisement Option (DetFRAO): An ICMPv6 | |
option indicating the Fast Router's participation in this | option indicating the Fast Router's participation in this | |
protocol, as well as its rank and delay. This option may appear | protocol, as well as its rank and delay. This option may appear | |
in Router-to-Router Status-Requests and Status messages, as well | in Router-to-Router Status-Requests and Status messages. The | |
as Router Solicitations and Advertisements. The option's format | option's format is defined in Section 4.2. | |
is defined in Section 4.2. | ||
Fast Router: A router participating in this protocol and exchanging | Fast Router: A router participating in this protocol and exchanging | |
Deterministic Fast Router Advertisement Options in | Deterministic Fast Router Advertisement Options in | |
Router-to-Router messages. | Router-to-Router messages. | |
Fast Router Advertisement: A response to a Router Solicitation which | Fast Router Advertisement: A response to a Router Solicitation which | |
is not randomly delayed. Please note that at a particular time, a | is not randomly delayed. Please note that at a particular time, a | |
Fast Advertising Router may advertise with a delay whose mean is | Fast Advertising Router may advertise with a delay whose mean is | |
slower than that defined by [2]. Even in this case, the response | slower than that defined by [2]. Even in this case, the response | |
is still called a Fast Router Advertisement (or FastRA). | is still called a Fast Router Advertisement (or FastRA). | |
Skipping to change at page 7, line 12: | ||
order for RS response. In this document, the ordinal position agreed | order for RS response. In this document, the ordinal position agreed | |
to by a router is its Rank. | to by a router is its Rank. | |
The lowest number provides the best Rank, and the fastest responding | The lowest number provides the best Rank, and the fastest responding | |
router has a Rank of 1. The ranking algorithm seeks to avoid ties, | router has a Rank of 1. The ranking algorithm seeks to avoid ties, | |
although from time to time, multiple routers will be seen to have the | although from time to time, multiple routers will be seen to have the | |
same Rank. Handling of this condition is specified in Section 6. | same Rank. Handling of this condition is specified in Section 6. | |
Upon determining the advertisement order, each router needs to choose | Upon determining the advertisement order, each router needs to choose | |
a delay exceeding that advertised by its better Ranked routers. To | a delay exceeding that advertised by its better Ranked routers. To | |
do this it inspects advertised values for other routers and | do this it inspects the Separation value advertised by the fastest | |
advertises its own Fixed Delay value exceeding this. The Fixed Delay | router, and advertises its own Fixed Delay value based on the number | |
is the lowest value used by the router as delay for responding to | of routers preceding it and the fastest router's Separation. The | |
Router Solicitations. In this fashion, a poorly ranked router needs | Fixed Delay is the lowest value used by the router as delay for | |
only to inspect the immediately preceding routers' status messages to | responding to Router Solicitations. | |
guarantee that it exceeds the expected values. | ||
At this stage, routers introduce a Separation time, which is used to | ||
separate the Fast Router Advertisements. A worse Ranked router must | ||
select a delay greater than or equal to the sum of the advertised | ||
Fixed Delay and Separation of its immediately preceding router(s). | ||
3.2 Router-to-Router Status Communication | 3.2 Router-to-Router Status Communication | |
In order to accomplish Ranking and delay agreement between routers on | In order to accomplish Ranking and delay agreement between routers on | |
a link, messages need to be exchanged between FastRA routers. These | a link, messages need to be exchanged between FastRA routers. These | |
messages contain information about the router's current configuration | messages contain information about the router's current configuration | |
status, and indicate that FastRA is in use. This document specifies | status, and indicate that FastRA is in use. This document specifies | |
the Router-to-Router(RtR) ICMPv6 message which allows configuration | the Router-to-Router(RtR) ICMPv6 message which allows configuration | |
status to be requested from other routers while advertising the | status to be requested from other routers while advertising the | |
router's own status. | router's own status. | |
Skipping to change at page 8, line 45: | ||
| Reserved | | | Reserved | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Options ... | | Options ... | |
+-+-+-+-+-+-+-+-+-+-+-+- | +-+-+-+-+-+-+-+-+-+-+-+- | |
Source Address | Source Address | |
MUST be the link-local address assigned to the | MUST be the link-local address assigned to the | |
interface from which this message is sent. | interface from which this message is sent. | |
Destination Address | Destination Address | |
Typically the Source Address of an invoking | Typically the router-to-routers multicast | |
Router-to-Router Status-Request or the | group (TBD Suggest: FF02::12). | |
all-routers multicast address. | ||
Hop Limit 255 | Hop Limit 255 | |
ICMP Fields: | ICMP Fields: | |
Type TBD (Suggest 191) | Type TBD (Suggest 191) | |
Code 0 - Status Request | Code 0 - Status Request | |
1 - Status | 1 - Status | |
Checksum The ICMPv6 checksum. | Checksum The ICMPv6 checksum. | |
Reserved This field is unused. It MUST be initialized to | Reserved This field is unused. It MUST be initialized to | |
zero by the sender and MUST be ignored by the | zero by the sender and MUST be ignored by the | |
receiver. | receiver. | |
Valid Options: | Valid Options: | |
Advertisement Interval | Advertisement Interval | |
The maximum delay between unsolicited Router | The maximum delay between unsolicited Router | |
Skipping to change at page 11, line 32: | ||
Reserved This field MUST be set to zero and be MUST be | Reserved This field MUST be set to zero and be MUST be | |
ignored by receivers. | ignored by receivers. | |
Fixed Delay The minimum delay used by this router to send | Fixed Delay The minimum delay used by this router to send | |
Router Advertisements in response to Router | Router Advertisements in response to Router | |
Solicitation. | Solicitation. | |
(Units: milliseconds) | (Units: milliseconds) | |
Separation A delay after the current router's Fixed Delay | Separation A delay after the current router's Fixed Delay | |
that worse ranked routers wait before transmitting. | that worse ranked routers wait before transmitting. | |
This is used by other routers when the subject | ||
router is fastest. | ||
(Units: milliseconds) | (Units: milliseconds) | |
Rel Pref The Relative Preference of the router seeking to | Rel Pref The Relative Preference of the router seeking to | |
perform Fast Router Advertisement. This is set | perform Fast Router Advertisement. This is set | |
to the variable FastRARelPref. | to the variable FastRARelPref. | |
This option may appear in Router-to-Router, Router Solicitation and | This option may appear in Router-to-Router, Router Solicitation and | |
Router Advertisement messages. Nodes receiving this option in other | Router Advertisement messages. Nodes receiving this option in other | |
messages MUST ignore it, acting as if they didn't understand the | messages MUST ignore it, acting as if they didn't understand the | |
option. | option. | |
4.2.1 Rank | 4.2.1 Rank | |
The Router ranked 1 will be the fastest router, and SHOULD configure | The Router ranked 1 will be the fastest router, and MUST configure a | |
a Fixed Delay of 0. No router may adopt a rank (other than | Fixed Delay of 0. No router may adopt a rank (other than | |
BOOTSTRAP_RANK) until it has undertaken router querying as defined in | BOOTSTRAP_RANK) until it has undertaken router querying as defined in | |
Section 7. | Section 7. | |
4.2.2 Fixed Delay | 4.2.2 Fixed Delay | |
The router determines its Fixed Delay by summing its immediately | The router determines its Fixed Delay by counting the number of | |
preceding router's Fixed Delay and Separation values. | preceding routers (Rank - 1) and multiplying this by the fastest | |
router's Separation value. | ||
The Fastest Router SHOULD set its Fixed Delay to 0. | The Fastest Router MUST set its Fixed Delay to 0. | |
4.2.3 Separation | 4.2.3 Separation | |
This value for the Fast Router's Separation from subsequent Fast | This value for the Fast Router's Separation from subsequent Fast | |
Routers exceeds the maximum additional delay over Fixed Delay | Routers exceeds the maximum additional delay over Fixed Delay | |
required to transmit a Fast Router Advertisement. | required to transmit a Fast Router Advertisement. | |
This delay MUST allow for computation delays in forming the RA (such | This delay MUST allow for computation delays in forming the RA (such | |
as incurred with SEND) [5]. | as incurred with SEND) [5]. | |
Skipping to change at page 13, line 5: | ||
5.1 Sending Router-to-Router Status-Requests | 5.1 Sending Router-to-Router Status-Requests | |
When seeking to learn about other routers' status, a router may send | When seeking to learn about other routers' status, a router may send | |
Router-to-Router status Requests to its peers. | Router-to-Router status Requests to its peers. | |
In doing so the router delays randomly for between 0 and | In doing so the router delays randomly for between 0 and | |
MAX_RTR_STATUS_REQ_DELAY, and then sends up to MAX_RTR_STATUS_REQS | MAX_RTR_STATUS_REQ_DELAY, and then sends up to MAX_RTR_STATUS_REQS | |
requests separated by at least RTR_STATUS_REQ_INTERVAL seconds. | requests separated by at least RTR_STATUS_REQ_INTERVAL seconds. | |
These messages are sent to the all-routers multicast group, and | These messages are sent to the router-to-routers multicast group, and | |
contain the Nonce, Signature, CGA and Timestamp options (at least) if | contain the Nonce, Signature, CGA and Timestamp options (at least) if | |
CGA is used. | CGA is used. | |
5.2 Sending Router-to-Router Status | 5.2 Sending Router-to-Router Status | |
Router-to-Router Status messages MAY be sent periodically to other | Router-to-Router Status messages MAY be sent periodically to other | |
routers to update the peers although the router's own reachability is | routers to update the peers although the router's own reachability is | |
readily confirmed by periodic unsolicited RA reception. | readily confirmed by periodic unsolicited RA reception. | |
When changes in configuration occur, the router SHOULD send up to | When changes in configuration occur, the router SHOULD send up to | |
Skipping to change at page 13, line 29: | ||
Responses to Status-Request messages MUST be sent. | Responses to Status-Request messages MUST be sent. | |
This responding Status MUST be sent after a random delay of 0 to | This responding Status MUST be sent after a random delay of 0 to | |
MAX_RTR_STATUS_DELAY. Additionally, multicast Status Messages MUST | MAX_RTR_STATUS_DELAY. Additionally, multicast Status Messages MUST | |
NOT be sent more regularly than once every | NOT be sent more regularly than once every | |
MIN_DELAY_BETWEEN_RTR_STATUS on average. | MIN_DELAY_BETWEEN_RTR_STATUS on average. | |
Responding Status messages MAY be sent to the unicast source address | Responding Status messages MAY be sent to the unicast source address | |
of the Status-Request. If MIN_DELAY_BETWEEN_RTR_STATUS has elapsed | of the Status-Request. If MIN_DELAY_BETWEEN_RTR_STATUS has elapsed | |
since the last multicast Status message, the response SHOULD be | since the last multicast Status message, the response SHOULD be | |
multicast to the all-routers group. | multicast to the router-to-routers group. | |
When a router's configuration the steady state, it adopts a periodic | ||
Router-to-Router Status advertisement interval as specificed by | ||
R2RStatusInt. The Advertisements are randomly distributed by their | ||
random delay upon advertisement of configuration changes. However, | ||
routers SHOULD periodically pause an additional random delay between | ||
0 and MAX_RTR_STATUS_DELAY, in order to re-spread Status messages. | ||
6. Ranking Calculation | 6. Ranking Calculation | |
When receiving Router-to-Router messages containing the DetFRAO, a | When receiving Router-to-Router messages containing the DetFRAO, a | |
router may maintain a list of Fast Routers and determines a relative | router may maintain a list of Fast Routers and determines a relative | |
order amongst them. Changes in the relative order trigger changes in | order amongst them. Changes in the relative order trigger changes in | |
Router Advertisement delays, so calculations for Rank need to be done | Router Advertisement delays, so calculations for Rank need to be done | |
simply, and reliably on information available in each | simply, and reliably on information available in each | |
Router-to-Router message with a Deterministic FastRA option. | Router-to-Router message with a Deterministic FastRA option. | |
Skipping to change at page 14, line 44: | ||
of fastest router in the case of interface identifier creation from | of fastest router in the case of interface identifier creation from | |
MAC-48 addresses, without reference to manufacturer's | MAC-48 addresses, without reference to manufacturer's | |
Organizationally Unique Identifier (OUI). Use of the XOR reverses | Organizationally Unique Identifier (OUI). Use of the XOR reverses | |
the order of the IPv6 address suffix so that EUI-64 based addresses | the order of the IPv6 address suffix so that EUI-64 based addresses | |
favour newer routers rather than older ones (unlike in [8] for the | favour newer routers rather than older ones (unlike in [8] for the | |
case where OUIs are the same), and the relative preference overrides | case where OUIs are the same), and the relative preference overrides | |
all[7]. | all[7]. | |
Maintaining this structure (RelPref,Suffix) allows routers to check | Maintaining this structure (RelPref,Suffix) allows routers to check | |
not only the relative ordering of a router in the list on DetFRAO | not only the relative ordering of a router in the list on DetFRAO | |
reception, but allows even Router Advertisements which do not contain | reception, but allows even Router-to-Router messages which do not | |
DetFRAOs to update the validity of the Fast Router's existing list | contain DetFRAOs to update the validity of the Fast Router's existing | |
entry by matching Rank Identifiers created from the RA's source | list entry by matching Rank Identifiers created from the RA's source | |
address (if this is a unique match). | address (if this is a unique match). | |
7. Becoming a Fast Router | 7. Becoming a Fast Router | |
When a router wishes to be a Fast Router, it needs to check if anyone | When a router wishes to be a Fast Router, it needs to check if anyone | |
else is acting as a Fast Router on this link. The router begins this | else is acting as a Fast Router on this link. The router begins this | |
bootstrap process sending Status-Request messages containing a | bootstrap process sending Status-Request messages containing a | |
DetFRAO, as defined in Section 5.1. | DetFRAO, as defined in Section 5.1. | |
The Deterministic FastRA option in this case MUST contain the values: | The Deterministic FastRA option in this case MUST contain the values: | |
Rank = BOOTSTRAP_RANK | Rank = BOOTSTRAP_RANK | |
Fixed Delay= BOOTSTRAP_DELAY | Fixed Delay= BOOTSTRAP_DELAY | |
Separation = FastRASep | Separation = FastRASep | |
Rel Pref = FastRARelPref | Rel Pref = FastRARelPref | |
Receivers will see this option and recognise that the requester is a | Receivers will see this option and recognise that the requester is a | |
bootstrapping router. As defined in Section 8.4, the routers MUST | bootstrapping router. As defined in Section 8.3, the routers MUST | |
send a Status message responding to the request containing the DetFRA | send a Status message responding to the request containing the DetFRA | |
option. This informs the requester of their own identity, Rank and | option. This informs the requester of their own identity, Rank and | |
delays. | delays. | |
While collecting information about other routers, the bootstrapping | While collecting information about other routers, the bootstrapping | |
router MUST send Router-to-Router messages with the DetFRA option. | router MUST send Router-to-Router messages with the DetFRA option. | |
It MUST delay when sending responses to Router Solicitations by 0 to | It MUST delay when sending responses to Router Solicitations by 0 to | |
MAX_RA_DELAY_TIME, and ensure that MIN_DELAY_BETWEEN_RAS separates | MAX_RA_DELAY_TIME, and ensure that MIN_DELAY_BETWEEN_RAS separates | |
multicast advertisements. | multicast advertisements. | |
Skipping to change at page 15, line 42: | ||
When receiving Router-to-Router messages with the DetFRAO option, the | When receiving Router-to-Router messages with the DetFRAO option, the | |
router determines whether the transmitting router has been seen | router determines whether the transmitting router has been seen | |
before, and whether the transmitted Rank, Fixed Delay or Separation | before, and whether the transmitted Rank, Fixed Delay or Separation | |
have changed. If either the router is previously unseen or the | have changed. If either the router is previously unseen or the | |
ranking or delay parameters have changed, the entry is inserted into | ranking or delay parameters have changed, the entry is inserted into | |
the list at the position indicated by the router's Ranking Scores. | the list at the position indicated by the router's Ranking Scores. | |
If the delay or rank of the receiving router have changed, it | If the delay or rank of the receiving router have changed, it | |
advertises its changed configuration as indicated in Section 9.1. | advertises its changed configuration as indicated in Section 9.1. | |
It SHOULD also send a unicast Status message to the transmitter of a | 8.1 Receiving Bootstrap Deterministic FastRA Options | |
Status-Request message if change occurred due to the option in that | ||
request. | ||
8.1 Dealing with Duplicate List Entries | ||
Where Router-to-Router messages are received with a DetFRA Option | ||
indicating the the same rank as another preceding entry, then the | ||
receiving router MUST configure its Rank to be the number of elements | ||
preceding it in the Fast Routers List plus one, and the router's own | ||
fixed delay MUST be configured to the maximum immediately preceding | ||
routers' fixed delays plus both of the other routers' received | ||
Separation values. | ||
This ensures the router is will not then collide with a router which | ||
subsequently increases its Rank. | ||
When this change occurs, advertisement follows the procedures in | ||
Section 9.1. | ||
8.2 Receiving Bootstrap Deterministic FastRA Options | ||
Deterministic FastRA routers or bootstrapping routers may receive | Deterministic FastRA routers or bootstrapping routers may receive | |
Router-to-Router messages containing a DetFRAO from a bootstrapping | Router-to-Router messages containing a DetFRAO from a bootstrapping | |
router. | router. | |
Routers SHOULD add such routers into their Fast Router List, in | Routers SHOULD add such routers into their Fast Router List, in | |
anticipation of the router's arrival as a fully functioning Fast | anticipation of the router's arrival as a fully functioning Fast | |
Router. | Router. | |
Calculations for the Rank and Fixed delay of the bootstrapping Router | Calculations for the Rank and Fixed delay of the bootstrapping Router | |
MUST NOT be made based on the values in the received Option, but on | MUST NOT be made based on the values in the received Option, but on | |
the Ranking Score generated as described in Section 6. The Fixed | the Ranking Score generated as described in Section 6. The Fixed | |
Delay calculated for the bootstrap router should be the sum of the | Delay calculated for the bootstrap router should be based on the best | |
preceding router's Fixed Delay and Separation. | ranked router's Separation, and the number of preceding routers. | |
Where the best ranked router is the bootstrapping router, this | ||
router's Separation is used in Fixed Delay calculations. | ||
8.3 Cleaning up old entries | 8.2 Cleaning up old entries | |
If a Fast Router fails to receive multiple expected Router | If a Fast Router fails to receive multiple expected Router | |
Advertisement packets from a peer router, it SHOULD check if the peer | Advertisement packets from a peer router, it SHOULD check if the peer | |
router is dead using either router or neighbour discovery . Such | router is dead using either router or neighbour discovery . Such | |
mechanisms may be invoked upon non-reception of advertisements in | mechanisms may be invoked upon non-reception of advertisements in | |
multiple retransmission intervals as advertised by the peer router, | multiple retransmission intervals as advertised by the peer router, | |
or non-response to previous Router-to-Router Status-Request [4]. | or non-response to previous Router-to-Router Status-Request [4]. | |
If the peer is dead, the local router removes its entry from the | If the peer is dead, the local router removes its entry from the | |
list, and re-advertises its own preference and distance as defined in | list, and re-advertises its own preference and distance as defined in | |
Section 9.1, if any change has occurred. | Section 9.1, if any change has occurred. | |
If one of a router's preceding routers reduces their Rank, so that it | If one of a router's preceding routers reduces their Rank, so that it | |
conflicts with another router in the list, a router MAY send a | conflicts with another router in the list, a router MAY send a | |
Router-to-Router Status-Request message containing DetFRAO after a | Router-to-Router Status-Request message containing DetFRAO after a | |
random delay between 0 and MAX_RTR_STATUS_REQ_DELAY, to establish | random delay between 0 and MAX_RTR_STATUS_REQ_DELAY, to establish | |
whether routers are still reachable. | whether routers are still reachable. | |
8.4 Responding to Status-Requests with DetFRAO | 8.3 Responding to Status-Requests with DetFRAO | |
A router MUST send a Deterministic FastRA option to a router which | A router MUST send a Deterministic FastRA option to a router which | |
sends a Router-to-Router Status-Request to it, if the router is | sends a Router-to-Router Status-Request to it, if the router is | |
trusted. Delays to Status message are described in Section 5.2. | trusted. Delays to Status message are described in Section 5.2. | |
9. Sending DetFRAOs in ICMPv6 Router-to-Router | 9. Sending DetFRAOs in ICMPv6 Router-to-Router | |
9.1 Sending RAs on Rank or Delay Change | 9.1 Sending RAs on Rank or Delay Change | |
In the case that a router's Rank, Fixed Delay or Separation change, | In the case that a router's Rank, Fixed Delay or Separation change, | |
Skipping to change at page 17, line 31: | ||
If subsequent changes occur within this interval, it extends such | If subsequent changes occur within this interval, it extends such | |
that three multicast Router-to-Router Status messages are sent with | that three multicast Router-to-Router Status messages are sent with | |
the new configuration. This allows all peer routers to be updated in | the new configuration. This allows all peer routers to be updated in | |
a configuration interval of less than 12.5 seconds, if one set of | a configuration interval of less than 12.5 seconds, if one set of | |
changes occurs. | changes occurs. | |
9.2 Sending Advertisement Intervals | 9.2 Sending Advertisement Intervals | |
When a router advertises Deterministic Fast RA Options in | When a router advertises Deterministic Fast RA Options in | |
Router-to-Router messages, it MAY also indicate the frequency of its | Router-to-Router messages, it MAY also indicate the frequency of its | |
periodic Router Advertisements using Advertisement Interval Options | periodic Router-to-Router Status messages using Advertisement | |
in the message if there is room. | Interval Options in the message if there is room. | |
Alternatively, a router may advertise the interval in its Router | ||
Advertisement messages as defined in [4]. | ||
This option allows receiving routers to know how often to expect | This option allows receiving routers to know how often to expect | |
these Router Advertisements, so that they can check that the | these Router Advertisements, so that they can check that the | |
advertising router is active if expected packets are not received (as | advertising router is active if expected packets are not received (as | |
in Section 8.3). | in Section 8.2). | |
Routers MAY send DetFRAOs occasionally in their periodic unsolicited | Routers MAY send DetFRAOs occasionally in their periodic unsolicited | |
Router Advertisements, in order to show hosts their FastRA | Router Advertisements, in order to show hosts their FastRA | |
configuration. | configuration. | |
10. Sending Fast Router Advertisements | 10. Sending Fast Router Advertisements | |
Fast Router Advertisements are sent in response to Router | Fast Router Advertisements are sent in response to Router | |
Solicitations. Where Deterministic Fast Router Advertisement Options | Solicitations. Where Deterministic Fast Router Advertisement Options | |
have been exchanged, and the routers know their fixed delays, Router | have been exchanged, and the routers know their fixed delays, Router | |
Skipping to change at page 19, line 27: | ||
11.2 Ceasing to be a Fast Router | 11.2 Ceasing to be a Fast Router | |
A router which no longer wishes to undertake FastRA may stop making | A router which no longer wishes to undertake FastRA may stop making | |
fast responses at any time, but SHOULD delay by a random value | fast responses at any time, but SHOULD delay by a random value | |
between 0 and MAX_RTR_STATUS_DELAY, before sending | between 0 and MAX_RTR_STATUS_DELAY, before sending | |
MAX_INITIAL_RTR_STATUS successive multicast Router-to-Router Status | MAX_INITIAL_RTR_STATUS successive multicast Router-to-Router Status | |
messages. These messages MUST contain the DetFRA option with Rank | messages. These messages MUST contain the DetFRA option with Rank | |
set to NOT_FAST_RTR_RANK and an advertised Fixed Delay of | set to NOT_FAST_RTR_RANK and an advertised Fixed Delay of | |
NOT_FAST_RTR_DELAY. These multicast Router Advertisements SHOULD be | NOT_FAST_RTR_DELAY. These multicast Router Advertisements SHOULD be | |
sent once every MIN_DELAY_BETWEEN_RTR_STATUS to the all-routers | sent once every MIN_DELAY_BETWEEN_RTR_STATUS to the router-to-routers | |
group. | group. | |
While a router advertises its Fixed Delay as NOT_FAST_RTR_DELAY, it | While a router advertises its Fixed Delay as NOT_FAST_RTR_DELAY, it | |
in fact reverts to the procedures defined in IPv6 Neighbour Discovery | in fact reverts to the procedures defined in IPv6 Neighbour Discovery | |
[2]. | [2]. | |
Routers receiving this option in a Router-to-Router message SHOULD | Routers receiving this option in a Router-to-Router message SHOULD | |
remove the router from the Fast Routers List, and recalculate | remove the router from the Fast Routers List, and recalculate | |
subsequent Ranks and delays of routers remaining in the list. | subsequent Ranks and delays of routers remaining in the list. | |
Skipping to change at page 20, line 19: | ||
of routers may appear. | of routers may appear. | |
Each set may not trust another, and may instead have its own router | Each set may not trust another, and may instead have its own router | |
at each Rank. In this case, the IncompatibleFastRouters flag SHOULD | at each Rank. In this case, the IncompatibleFastRouters flag SHOULD | |
be set on the interface until the untrusted routers become trusted, | be set on the interface until the untrusted routers become trusted, | |
or cease being Fast Routers. | or cease being Fast Routers. | |
Each Fast Router which has the IncompatibleFastRouters flag MUST | Each Fast Router which has the IncompatibleFastRouters flag MUST | |
attempt to inform its administrator about the misconfiguration. | attempt to inform its administrator about the misconfiguration. | |
12. Host interaction with DetFRAOs | 12. Configuration Parameters | |
While the principle use of Deterministic FastRA options is for router | ||
to router configuration, the options may be used to pass information | ||
to hosts. | ||
12.1 Host Transmission of DetFRAOs | ||
A host may transmit a Deterministic FastRA option in a Router | ||
Solicitation. This option MUST be sent with a Rank of | ||
NOT_FAST_RTR_RANK and a Fixed Delay of NOT_FAST_RTR_DELAY. | ||
This option in a solicitation requests that the responding Router | ||
Advertisement contains a Deterministic FastRA option. | ||
12.2 Reception of DetFRAOs in Router Solicitations | ||
Routers receiving a DetFRAO option in a Router Solicitation sends a | ||
Router Advertisement responding to the solicitation if it is able to | ||
do so. In responding to the solicitation with this option, the | ||
Router Advertisement MAY contain the router's own configuration in a | ||
DetFRAO. | ||
12.3 Transmission of DetFRAOs in Router Advertisements | ||
Routers MAY inform hosts of their status by including their | ||
Router-to-Router status in some unsolicited Router Advertisements. | ||
If a router does this, it SHOULD inform them with updated options | ||
after configuration status change. | ||
12.4 Host Reception of DetFRAOs | ||
If a host which configures a router receives a DetFRAO from this | ||
router in a Router Advertisement, it can determine the routers' Ranks | ||
and delays. | ||
If when receiving a Router Advertisement in response to its | ||
solicitation it receives a DetFRAO with a Rank which matches an | ||
existing configured router, it may suspect change has occurred. | ||
Where no prefixes exist in common with the previously received | ||
advertisements, reception of a FastRA from a router within the | ||
reception interval defined by another router either implies a new | ||
router joining the link, or a link change. | ||
Since new routers joining a Fast Router Advertisement set are | ||
unlikely to occur often, a host MAY assume that the new router is on | ||
a new link, and begin configuration operations. | ||
Where a single router has joined a link, the next best Fast Router | ||
will then be the previously configured router, if the host remains on | ||
the same link. Therefore, a host MAY delay until after the sum of | ||
the old and newly received routers' Separation have elapsed before | ||
concluding that link change has occurred. This additional cost is | ||
likely to be less than that incurred with Legacy Router | ||
Advertisements, but provides slightly more safety than the previous | ||
heuristic. | ||
13. Configuration Parameters | ||
The following parameters are defined in this document: | The following parameters are defined in this document: | |
FastRARelPref A parameter which controls the | FastRARelPref A parameter which controls the | |
ranking of Fast Routers. It sets | ranking of Fast Routers. It sets | |
the advertised Rel Pref field in | the advertised Rel Pref field in | |
the DetFRAO. Setting this value lower | the DetFRAO. Setting this value lower | |
betters the preference of the router. | betters the preference of the router. | |
Minimum: 0 | Minimum: 0 | |
Skipping to change at page 22, line 26: | ||
scheduling of Fast Router Advertisements | scheduling of Fast Router Advertisements | |
on adjacent routers in the Fast Routers | on adjacent routers in the Fast Routers | |
List. | List. | |
(Units: milliseconds) | (Units: milliseconds) | |
Minimum: 1 | Minimum: 1 | |
Maximum: 255 | Maximum: 255 | |
Default: DEF_SEP | Default: DEF_SEP | |
MaxFastRAs The maximum bucket size for Unicast | MaxFastRAs The maximum bucket size for Unicast | |
FastRAs | FastRAs. | |
[6] | ||
. | ||
Minimum: 0 (not Fast RA) | Minimum: 0 (not Fast RA) | |
Default: MAXFASTRAS | Default: MAXFASTRAS | |
MaxMCFastRAs The maximum bucket size for Multicast | MaxMCFastRAs The maximum bucket size for Multicast | |
FastRAs. | FastRAs. | |
Minimum: 0 (no Multicast Fast RA) | Minimum: 0 (no Multicast Fast RA) | |
Default: MAXMCFASTRAS | Default: MAXMCFASTRAS | |
14. Protocol Constants | R2RStatusInt The interval between Router-to-Router | |
Status messages while in steady state. | ||
Minimum: MIN_DELAY_BETWEEN_RTR_STATUS | ||
Default: DEF_DELAY_BETWEEN_RTR_STATUS | ||
13. Protocol Constants | ||
BOOTSTRAP_DELAY 500ms | BOOTSTRAP_DELAY 500ms | |
BOOTSTRAP_RANK 254 | BOOTSTRAP_RANK 254 | |
DEF_SEP 50ms | DEF_SEP 50ms | |
DEF_REL_PREF 127 | DEF_REL_PREF 127 | |
MAXMCFASTRAS 5 | MAXMCFASTRAS 5 | |
MAX_INITIAL_RTR_STATUS 3 | MAX_INITIAL_RTR_STATUS 3 | |
MAX_RTR_STATUS_REQ_DELAY 1000ms | MAX_RTR_STATUS_REQ_DELAY 1000ms | |
MAX_RTR_STATUS_REQS 3 | MAX_RTR_STATUS_REQS 3 | |
MAX_RTR_STATUS_DELAY 500ms | MAX_RTR_STATUS_DELAY 500ms | |
MIN_DELAY_BETWEEN_RTR_STATUS 3 seconds | MIN_DELAY_BETWEEN_RTR_STATUS 3 seconds | |
DEF_DELAY_BETWEEN_RTR_STATUS 15 seconds | ||
NOT_FAST_RTR_DELAY 500ms | NOT_FAST_RTR_DELAY 500ms | |
NOT_FAST_RTR_RANK 255 | NOT_FAST_RTR_RANK 255 | |
RTR_STATUS_REQ_INTERVAL 4 seconds | RTR_STATUS_REQ_INTERVAL 4 seconds | |
UCASTFASTRAREFRESHIVAL 400ms | UCASTFASTRAREFRESHIVAL 400ms | |
15. IANA Considerations | 14. IANA Considerations | |
The new ICMPv6 message type - Router to Router (with two codes) and a | The new ICMPv6 message type - Router to Router (with two codes) and a | |
new ICMPv6 'Deterministic Fast Router Advertisement Option' are | new ICMPv6 'Deterministic Fast Router Advertisement Option' are | |
defined in this document. | defined in this document. | |
The Router-to-Router message is suggested to be an Informational | The Router-to-Router message is suggested to be an Informational | |
ICMPv6 message and is defined in Section 4.1. | ICMPv6 message and is defined in Section 4.1. | |
In order to provide a unique multicast address for routers wishing to | ||
participate in router-to-rotuer configuration, it is suggested the | ||
IANA supply the following Link-Local Scope multicast address: | ||
FF02:0:0:0:0:0:0:12 Router-to-Routers Configuration | ||
(DetFRAO) is defined in Section 4.2 of this document. It is | (DetFRAO) is defined in Section 4.2 of this document. It is | |
suggested that the option number 13 is used for the Type of this | suggested that the option number 13 is used for the Type of this | |
option. | option. | |
16. Security Considerations | 15. Security Considerations | |
The Router-to-Router message's use of the Neighbour Discovery option | The Router-to-Router message's use of the Neighbour Discovery option | |
format allows SEND options to be used to check the authenticity of | format allows SEND options to be used to check the authenticity of | |
the messages sent from the peer router. | the messages sent from the peer router. | |
The authorization of a node to be a router is described by a | The authorization of a node to be a router is described by a | |
delegation chain advertised in a succession of Delegation Chain | delegation chain advertised in a succession of Delegation Chain | |
Advertisement messages. When using SEND, routers MUST check that the | Advertisement messages. When using SEND, routers MUST check that the | |
router from which they receive a DetFRAO is an authorized router from | router from which they receive a DetFRAO is an authorized router from | |
that link, and that the router trusts the delegation service used to | that link, and that the router trusts the delegation service used to | |
Skipping to change at page 24, line 12: | ||
flag on that interface. This will turn attempt to inform the | flag on that interface. This will turn attempt to inform the | |
administrator of the configuration problem. | administrator of the configuration problem. | |
Where disjoint sets of routers each undertake FastRA (but don't trust | Where disjoint sets of routers each undertake FastRA (but don't trust | |
each other), they can choose the same delay timers for sending | each other), they can choose the same delay timers for sending | |
FastRA. In the worst case this means that every FastRA sent will | FastRA. In the worst case this means that every FastRA sent will | |
collide with another RA. Administrative action is currently required | collide with another RA. Administrative action is currently required | |
to fix this issue, but further work may establish if automated | to fix this issue, but further work may establish if automated | |
robustness to this issue is desirable. | robustness to this issue is desirable. | |
17. Acknowledgments | 16. Acknowledgments | |
This work is based on and expands the FastRA internet-draft [6]. | This work is based on and expands the FastRA internet-draft [6]. | |
17. Changes Since Last Revision | ||
17.1 draft-daley-dna-det-fastra-00 to -01 | ||
Force Fastest Router to respond with no delay MUST instead of SHOULD. | ||
Allow calculation based on advertised Separation in fastest router | ||
Removed section about duplicate list entries. Working from | ||
calculated rank only now. | ||
Cleaned up references to Router Advertisement and Router-to-Router. | ||
Removed Misleading SHOULD from Status-Request response | ||
Removed capability to use Advertisement Interval in RA for R2R. | ||
Removed entire section about hosts using DETFRAO. | ||
Added configuration option for Router-to-Router Status Interval (15s | ||
Def). | ||
18. References | 18. References | |
18.1 Normative References | 18.1 Normative References | |
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |
Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |
[2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for | [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for | |
IP Version 6 (IPv6)", RFC 2461, December 1998. | IP Version 6 (IPv6)", RFC 2461, December 1998. | |
End of changes. | ||
This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |