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/