draft-ietf-dna-protocol-05.txt   draft-ietf-dna-protocol-06.txt 
DNA Working Group S. Narayanan, Ed. DNA Working Group S. Narayanan, Ed.
Internet-Draft Panasonic Internet-Draft iTCD/CSUMB
Expires: September 5, 2007 March 4, 2007 Expires: December 27, 2007 June 25, 2007
Detecting Network Attachment in IPv6 Networks (DNAv6) Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-ietf-dna-protocol-05.txt draft-ietf-dna-protocol-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 33 skipping to change at page 1, line 33
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 September 5, 2007. This Internet-Draft will expire on December 27, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Efficient detection of network attachment in IPv6 needs the following Efficient detection of network attachment in IPv6 needs the following
three components: a method for hosts to detect link change in the three components: a method for hosts to detect link change in the
presence of unmodified (non-DNAv6) routers, a method for the host to presence of unmodified (non-DNAv6) routers, a method for the host to
skipping to change at page 2, line 12 skipping to change at page 2, line 12
flexibility offered to routers in terms of prefixes advertised in a flexibility offered to routers in terms of prefixes advertised in a
router advertisement (RA) message. Similarly, the random delay in router advertisement (RA) message. Similarly, the random delay in
responding to router solicitation messages imposed by RFC 2461 makes responding to router solicitation messages imposed by RFC 2461 makes
it difficult to receive an RA quickly. In this memo, a mechanism it difficult to receive an RA quickly. In this memo, a mechanism
that requires the hosts to monitor all the prefixes advertised on the that requires the hosts to monitor all the prefixes advertised on the
link and use it for link identification in the presence of non-DNAv6 link and use it for link identification in the presence of non-DNAv6
routers is presented. A more efficient link-identification mechanism routers is presented. A more efficient link-identification mechanism
requiring the DNAv6 routers to monitor the link for advertised requiring the DNAv6 routers to monitor the link for advertised
prefixes to assist the hosts in link identification combined with a prefixes to assist the hosts in link identification combined with a
fast router advertisement mechanism that selects the order of fast router advertisement mechanism that selects the order of
response for the router deterministicly is also presented. response for the router deterministically is also presented.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5
3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7
3.3 Complete Prefix List generation . . . . . . . . . . . . . 8 3.3 Tentative Source Link-Layer Address option (TO) . . . . . 8
3.3.1 Erroneous Prefix Lists . . . . . . . . . . . . . . . . 9
3.4 Tentative Source Link-Layer Address option (TO) . . . . . 10
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 11 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 11 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 9
4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 12 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10
4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 13 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 11
4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 15 4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 12
5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 16 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 16 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 13
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 16 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 13
5.1.2 Router Configuration Variables . . . . . . . . . . . . 17 5.1.2 Bootstrapping DNA Data Structures . . . . . . . . . . 14
5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 18 5.1.3 Processing Router Advertisements . . . . . . . . . . . 15
5.1.4 Processing Router Advertisements . . . . . . . . . . . 19 5.1.4 Processing Router Solicitations . . . . . . . . . . . 15
5.1.5 Processing Router Solicitations . . . . . . . . . . . 19 5.1.5 Complete Router Advertisements . . . . . . . . . . . . 17
5.1.6 Complete Router Advertisements . . . . . . . . . . . . 20 5.1.6 Inclusion of a common prefixes . . . . . . . . . . . . 17
5.1.7 Inclusion of smallest prefixes . . . . . . . . . . . . 21 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 19
5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 22 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 20
5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 23 5.1.9 Removing a Prefix from an Interface . . . . . . . . . 20
5.1.10 Removing a Prefix from an Interface . . . . . . . . 23 5.1.10 Prefix Reassignment . . . . . . . . . . . . . . . . 20
5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 24 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 24 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 24 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 25 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 22
5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 25 5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 23
5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 26 5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 23
5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 26 5.2.6 Processing Router Advertisements . . . . . . . . . . . 24
5.2.6 Processing Router Advertisements . . . . . . . . . . . 27 5.2.7 DNA and Address Configuration . . . . . . . . . . . . 29
5.2.7 DNA and Address Configuration . . . . . . . . . . . . 33 5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 32
5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 36 5.3.1 Sending solicitations containing Tentative Options . . 32
5.3.1 Sending solicitations containing Tentative Options . . 37 5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 33
5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 37 5.3.3 Sending directed advertisements without the
neighbour cache . . . . . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . 36
6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 40 6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 36
6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 41 6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 36
6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 41 6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 37
6.4 Authorization and Detecting Network Attachment . . . . . . 42 6.4 Authorization and Detecting Network Attachment . . . . . . 38
6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 42 6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 38
6.6 DNA Hint Management Security . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 39
9. Changes since -04 . . . . . . . . . . . . . . . . . . . . . 44 9. Changes since -05 . . . . . . . . . . . . . . . . . . . . . 40
10. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 44 10. Changes since -04 . . . . . . . . . . . . . . . . . . . . . 41
11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 45 11. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 41
12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45 12. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 41
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46 13. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 42
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 46 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
15.1 Normative References . . . . . . . . . . . . . . . . . . 47
15.2 Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
16.1 Normative References . . . . . . . . . . . . . . . . . . 43
16.2 Informative References . . . . . . . . . . . . . . . . . 43
A. Sending directed advertisements without the neighbour Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44
cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . 47
1. Introduction 1. Introduction
This memo defines a mechanism for an IPv6 host to detect link-change This memo defines a mechanism for an IPv6 host to detect link-change
in the presence of unmodified (non-DNAv6) routers and proposes new in the presence of unmodified (non-DNAv6) routers and proposes new
extensions to "IPv6 Neighbor Discovery" [3] to increase the extensions to "IPv6 Neighbor Discovery" [3] to increase the
efficiency of link-change detection in the presence of DNAv6 enabled efficiency of link-change detection in the presence of DNAv6 enabled
routers. The proposed mechanism define the construct that identifies routers. The proposed mechanism define the construct that identifies
a link, proposes an algorithm for the routers on the link to send a a link, proposes an algorithm for the routers on the link to send a
quick RA response without randomly waiting for upto MAX_RA_DELAY_TIME quick RA response without randomly waiting for upto MAX_RA_DELAY_TIME
skipping to change at page 5, line 7 skipping to change at page 5, line 7
3. Overview 3. Overview
The DNA protocol presented in this document tries to achieve the The DNA protocol presented in this document tries to achieve the
following objectives: following objectives:
o Eliminate the delays introduced by RFC 2461 in discovering the o Eliminate the delays introduced by RFC 2461 in discovering the
configuration. configuration.
o Make it possible for the hosts to accurately detect the identity o Make it possible for the hosts to accurately detect the identity
of their current link from a single RS-RA pair in the presence of of their current link from a single RS-RA pair in the presence of
either DNAv6 enabled routers or non-DNAv6 routers. either DNAv6 enabled routers and/or non-DNAv6 routers.
DNAv6 assumes that the host's link interface software and hardware is DNAv6 assumes that the host's link interface software and hardware is
capable of delivering a 'link up' event notification when layer 2 on capable of delivering a 'link up' event notification when layer 2 on
the host is configured and sufficiently stable for IP traffic. This the host is configured and sufficiently stable for IP traffic. This
event notification acts as a DNA Hint to the layer 3 DNA procedures event notification acts as a DNA Hint to the layer 3 DNA procedures
to check whether or not the host is attached to the same link as to check whether or not the host is attached to the same link as
before. DNAv6 also assumes that an interface on the host is never before. DNAv6 also assumes that an interface on the host is never
connected to two links at the same time. In the case that the layer connected to two links at the same time. In the case that the layer
2 technology is capable of having multiple attachments (for instance, 2 technology is capable of having multiple attachments (for instance,
multiple layer 2 associations or connections) at the same time, DNAv6 multiple layer 2 associations or connections) at the same time, DNAv6
skipping to change at page 6, line 44 skipping to change at page 6, line 44
In the case when the landmark prefix is unknown to the responding In the case when the landmark prefix is unknown to the responding
router, the host will receive a "No" answer by non-inclusion of the router, the host will receive a "No" answer by non-inclusion of the
landmark prefix in the RA, and also the information it needs to landmark prefix in the RA, and also the information it needs to
configure itself for the new link. The routers try to include as configure itself for the new link. The routers try to include as
much information as possible in such messages, so that the host can much information as possible in such messages, so that the host can
be informed of all the prefixes assigned to the new link as soon as be informed of all the prefixes assigned to the new link as soon as
possible. possible.
A second mechanism for reducing packet sizes applies to unsolicited A second mechanism for reducing packet sizes applies to unsolicited
Router Advertisements. By selecting the smallest prefix on the link Router Advertisements. By selecting a common prefix on the link to
to be the representative for the entire set of prefixes on the link, be the representative for the entire set of prefixes on the link, and
and making sure that it is included in every advertisement, it is making sure that it is included in every advertisement, it is
possible to omit some prefixes. Such advertisements will not inform possible to omit some prefixes. The smallest prefix on the link is
a host of all of the prefixes at once, but in general these selected as the common prefix. Such advertisements will not inform a
unsolicited advertisements will not be the first advertisement host of all of the prefixes at once, but in general these unsolicited
received on a link. Inclusion of the smallest prefix simply ensures advertisements will not be the first advertisement received on a
that there is overlap in the information advertised by each router on link. Inclusion of the smallest prefix simply ensures that there is
a link and that hosts will thus not incorrectly interpret one of overlap in the information advertised by each router on a link and
these incomplete RAs as an indication of movement. Even though this that hosts will thus not incorrectly interpret one of these
incomplete RAs as an indication of movement. Even though this
document recommends the use of a prefix as the representative of the document recommends the use of a prefix as the representative of the
link, future specifications can use the Learned Prefix Option to link, future specifications can use the Learned Prefix Option to
include a non-prefix link identifier as long as this identifier is include a non-prefix identifier as long as this identifier is 128 bit
128 bit long to avoid collision with any currently assigned prefix. long to avoid collision with any currently assigned prefix. So, any
So, any future non-prefix link identifier MUST be 128 bits long. future non-prefix link identifier MUST be 128 bits long.
The Router Advertisement messages are, in general, larger than the The Router Advertisement messages are, in general, larger than the
solicitations, and with multiple routers on the link there will be solicitations, and with multiple routers on the link there will be
multiple advertisements sent for each solicitation. This multiple advertisements sent for each solicitation. This
amplification can be used by an attacker to cause a Denial of Service amplification can be used by an attacker to cause a Denial of Service
attack. Such attacks are limited by applying a rate limit on the attack. Such attacks are limited by applying a rate limit on the
unicast Router Advertisements sent directly in response to each unicast Router Advertisements sent directly in response to each
solicitation, and using multicast RAs when the rate limit is solicitation, and using multicast RAs when the rate limit is
exceeded. exceeded.
In order for the routers be able to both respond to the landmark In order for the routers be able to both respond to the landmark
questions and send the complete RAs, the routers need to track the questions and send the complete RAs, the routers need to track the
prefixes that other routers advertise on the link. This process is prefixes that other routers advertise on the link. This process is
initialized when a router is enabled, by sending a Router initialized when a router is enabled, by sending a Router
Solicitation and collecting the resulting RAs, and then multicasting Solicitation and collecting the resulting RAs, and then multicasting
a few RAs more rapidly as already suggested in RFC 2461. This a few RAs more rapidly as already suggested in RFC 2461. This
process ensures with high probability that all the routers have the process ensures with high probability that all the routers have the
same notion of the set of prefixes assigned to the link. same notion of the set of prefixes assigned to the link.
In order for the host to be able to make decisions about link change
with a single received RA, the hosts need to track all the prefixes
advertised on the link. The hosts also have to maintain a notion of
'completeness' associated with its prefix list.
3.2 Fast Router Advertisement 3.2 Fast Router Advertisement
According to RFC 2461 a solicited Router Advertisement should have a According to RFC 2461 a solicited Router Advertisement should have a
random delay between 0 and 500 milliseconds, to avoid the random delay between 0 and MAX_RA_DELAY_TIME, to avoid the
advertisements from all the routers colliding on the link causing advertisements from all the routers colliding on the link causing
congestion and higher probability of packet loss. In addition, RFC congestion and higher probability of packet loss. In addition, RFC
2461 suggests that the RAs be multicast, and multicast RAs are rate 2461 suggests that the RAs be multicast, and multicast RAs are rate
limited to one message every 3 seconds. This implies that the limited to one message every 3 seconds. This implies that the
response to a RS might be delayed up to 3.5 seconds. response to a RS might be delayed up to 3.5 seconds.
DNAv6 avoids this delay by using a different mechanism to ensure that DNAv6 avoids this delay by using a different mechanism to ensure that
two routers will not respond at exactly the same time while allowing two routers will not respond at exactly the same time while allowing
one of the routers on the link to respond immediately. Since the one of the routers on the link to respond immediately. Since the
hosts might be likely to use the first responding router as the first hosts might be likely to use the first responding router as the first
skipping to change at page 8, line 21 skipping to change at page 8, line 17
addresses. The results of that function are then compared to create addresses. The results of that function are then compared to create
a ranking, and the ranking determines the delay each router will use a ranking, and the ranking determines the delay each router will use
when responding to the RS. The router which is ranked as #0 will when responding to the RS. The router which is ranked as #0 will
respond with a zero delay. respond with a zero delay.
If the routers become out-of-sync with respect to their learned If the routers become out-of-sync with respect to their learned
router lists, two or more routers may respond with the same delay, router lists, two or more routers may respond with the same delay,
but over time the routers will converge on their lists of learned but over time the routers will converge on their lists of learned
routers on the link. routers on the link.
3.3 Complete Prefix List generation 3.3 Tentative Source Link-Layer Address option (TO)
To efficiently check for link change, a host always maintains the
list of all known prefixes on the link. This procedure of attaining
and retaining the Complete Prefix List is initialized when the host
is powered on.
The host forms the prefix list at any PoA (Point of Attachment), that
is, this process starts independently of any movement. Though the
procedure may take some time, that doesn't matter unless the host
moves very fast. A host can generate the Complete Prefix List with
reasonable certainty if it remains attached to a link sufficiently
long. It will take approximately 4 seconds, when it actively
performs 1 RS/ RA exchange. If it passively relies on unsolicited RA
messages instead, it may take much more time.
First the host sends an RS to All-Router multicast address. Assuming
there is no packet loss, every router on the link would receive the
RS and usually reply with an RA containing all the prefixes that the
router advertises. However, RFC 2461 mandates certain delays for the
RA transmissions.
After an RS transmission, the host waits for all RAs that would have
been triggered by the RS. There is an upper limit on the delay of
the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec)
+ network propagation delay is the maximum delay between an RS and
the resulting RAs [3]. 4 seconds would be a safe number for the host
to wait for the solicited RAs. Assuming no packet loss, within 4
seconds, the host would receive all the RAs and know all the
prefixes. Thus we pick 4 seconds as the value for MinRAWait.
In case of packet loss, things get more complicated. In the above
process, there may be a packet loss that results in the generation of
an Incomplete Prefix List, i.e. the prefix list that misses some
prefix on the link. To remedy this deficiency, the host may perform
multiple RS/ RA exchanges to collect all the assigned prefixes.
After one RS/ RA exchange, to corroborate the completeness of the
prefix list, the host may send additional RSs and wait for the
resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS
by RFC2461 [3]. The host takes the union of the prefixes from all
the RAs to generate the prefix list. The more RS/ RA exchange the
host performs, the more probable that the resulting prefix list is
complete.
To ascertain whether its existing prefix list is complete or not, the
host can set its own policy. The host may take into consideration
the estimated packet loss rate of the link and the number of RS/ RA
exchanges it performed or should have performed while it was attached
to the link.
In general, the higher the error rate, the longer time and more RA
transmissions from the routers are needed to assure the completeness
of the prefix list.
3.3.1 Erroneous Prefix Lists
The host may generate either 1) an Incomplete Prefix List, i.e. the
prefix list that does not include all the prefixes that are assigned
to the link or 2) the Superfluous Prefix List, i.e. the prefix list
that contains some prefix that is not assigned to the link.
It should be noted that 1) and 2) are not exclusive. The host may
generate the prefix list that excludes some prefix on the link but
includes the prefix not assigned to the link. Its important to note
that these erroneous prefix list possibility is significantly reduced
with a single DNAv6 router on the link that is sending CompleteRA
messages.
Severe packet losses during prefix list generation may cause an
Incomplete Prefix List. Or the host may have undergone a link change
before finishing the procedure of the Complete Prefix List
generation. Later we will deal with the case that the host can't be
sure of the completeness of the prefix list.
Even if the host falsely assumes that an Incomplete Prefix List is
complete, the effect of that assumption is that the host might later
think it has moved to a different link when in fact it has not.
In case that a link change happens, even if the host has an
Incomplete Prefix List, it will detect a link change. Hence an
Incomplete Prefix List doesn't cause a connection disruption. But
when a link change hasn't occured, an erroneous prefix list may cause
the host to make the wrong decision resulting in extra signaling
messages, for example Binding Update messages in Mobile IPv6 [6]
The Superfluous Prefix List presents a more serious problem.
Without the assumed 'link UP' event notification from the link-layer,
the host can't perceive that it has changed its attachment point,
i.e. it has torn down an old link-layer connection and established a
new one.
With the assumed 'link UP' notification, and the assumption of
different concurrent layer 2 connections being represented as
different (virtual) interfaces to the DNA module the host will never
treat RAs from different links as being part of the same link. Hence
it will not create a Superfluous Prefix List.
3.4 Tentative Source Link-Layer Address option (TO)
DNAv6 protocol requires the host to switch its IPv6 addresses to DNAv6 protocol requires the host to switch its IPv6 addresses to
'optimistic' state as recommended by Optimistic DAD [5] after 'optimistic' state as recommended by Optimistic DAD [5] after
receiving a link-up notification until a decision on the link-change receiving a link-up notification until a decision on the link-change
possibility is made. possibility is made.
Optimistic DAD [5] prevents usage of Source Link-Layer Address Optimistic DAD [5] prevents use of Source Link-Layer Address options
options (SLLAOs) in Router and Neighbour Solicitation messages from a (SLLAOs) in Router and Neighbour Solicitation messages from a
tentative address (while Duplicate Address Detection is occurring). tentative address (while Duplicate Address Detection is occurring).
This is because receiving a Neighbour Solicitation (NS) or Router This is because receiving a Neighbour Solicitation (NS) or Router
Solicitation (RS) containing an SLLAO would otherwise overwrite an Solicitation (RS) containing an SLLAO would otherwise overwrite an
existing cache entry, even if the cache entry contained the existing cache entry, even if the cache entry contained the
legitimate address owner, and the solicitor was a duplicate address. legitimate address owner, and the solicitor was a duplicate address.
Neighbour Advertisement (NA) messages don't have such an issue, since Neighbour Advertisement (NA) messages don't have such an issue, since
the Advertisement message contains a flag which explicitly disallows the Advertisement message contains a flag which explicitly disallows
overriding of existing cache entries, by the target link-layer overriding of existing cache entries, by the target link-layer
address option carried within. address option carried within.
The effect of preventing SLLAOs for tentative addresses is that The effect of preventing SLLAOs for tentative addresses is that
communications with these addresses are difficult for the tentative communications with these addresses are difficult for the tentative
period. Sending solicitations without these options causes an period. Sending solicitations without these options causes an
additional round-trip for neighbour discovery if the advertiser does additional round-trip for neighbour discovery if the advertiser does
not have an existing neighbour cache entry for the solicitor. In not have an existing neighbour cache entry for the solicitor. In
some cases, multicast advertisements will be scheduled, where some cases, multicast advertisements will be scheduled, where
neighbour discovery is not possible on the advertiser. neighbour discovery is not possible on the advertiser.
The Tentative Option (TO) functions in the same role as the Source A new option, called Tentative Option (TO), is defined that functions
Link-Layer Address option defined for [3], but it MUST NOT override in the same role as the Source Link-Layer Address option defined by
an existing neighbour cache entry. [3], but it MUST NOT override an existing neighbour cache entry.
The differing neighbour cache entry MUST NOT be affected by the The differing neighbour cache entry MUST NOT be affected by the
reception of the Tentative Option. This ensures that tentative reception of the Tentative Option. This ensures that tentative
addresses are unable to modify legitimate neighbour cache entries. addresses are unable to modify legitimate neighbour cache entries.
In the case where an entry is unable to be added to the neighbour In the case where an entry is unable to be added to the neighbour
cache, a node MAY send responses direct to the link-layer address cache, a node MAY send responses direct to the link-layer address
specified in the TO. specified in the TO.
4. Message Formats 4. Message Formats
skipping to change at page 12, line 22 skipping to change at page 10, line 13
on the link. on the link.
Reserved (R) Reserved (R)
The reserved field is reduced from 3 bits to 1 bit. The reserved field is reduced from 3 bits to 1 bit.
4.2 Landmark Option 4.2 Landmark Option
The Landmark Option is used by hosts in a Router Solicitation message The Landmark Option is used by hosts in a Router Solicitation message
to ask the routers on a link if the specified prefix is being to ask the routers on a link if the specified prefix is being
advertised by some router on the link. It is used by routers in a advertised by some router on the link.
Router Advertisement to reply to a corresponding question in a Router
Solicitation, indicating whether the prefix referred to is being
advertised by any router on the link.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pref Length | | | Type | Length | Pref Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Landmark Prefix ~ ~ Landmark Prefix ~
skipping to change at page 13, line 16 skipping to change at page 11, line 4
An 8 bit unsigned integer representing the number of bits in the An 8 bit unsigned integer representing the number of bits in the
prefix to be used for matching. prefix to be used for matching.
Reserved Reserved
A 38 bit unused field. It MUST be initialised to zero by the A 38 bit unused field. It MUST be initialised to zero by the
sender, and ignored by the receiver. sender, and ignored by the receiver.
Prefix Prefix
A prefix being used by the host currently for a global IPv6 A prefix being used by the host currently for a global IPv6
address, padded at the right with zeros. If the prefix length is address, padded at the right with zeros. If the prefix length is
less than 65 bits, only 64 bits need be included, otherwise 128 less than 65 bits, only 64 bits need be included, otherwise 128
bits are included. bits are included.
4.3 Learned Prefix Option 4.3 Learned Prefix Option
The Learned Prefix Option (LPO) is used by a router to indicate The Learned Prefix Option (LPO) is used by a router to indicate
prefixes that are being advertised in PIOs by other routers on the prefixes that are being advertised by other routers on the link, but
link, but not by itself. not by itself.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Len 1 | | Type | Length | Reserved | Prefix Len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Prefix Len N | Padding | | ... | Prefix Len N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 16, line 41 skipping to change at page 14, line 4
router's own interface. The list will be referred to in this router's own interface. The list will be referred to in this
document as "DNARouterLearnedPrefixList". Prefixes are learned by document as "DNARouterLearnedPrefixList". Prefixes are learned by
their reception within Prefix Information Options [3] in Router their reception within Prefix Information Options [3] in Router
Advertisements. Prefixes in Learned Prefix Options (see Section 4.3) Advertisements. Prefixes in Learned Prefix Options (see Section 4.3)
MUST NOT update the contents of DNARouterLearnedPrefixList. For each MUST NOT update the contents of DNARouterLearnedPrefixList. For each
prefix the router MUST store sufficient information to identify the prefix the router MUST store sufficient information to identify the
prefix and to know when to remove the prefix entry from the list. prefix and to know when to remove the prefix entry from the list.
This may be achieved by storing the following information: This may be achieved by storing the following information:
1. Prefix 1. Prefix
2. Prefix length 2. Prefix length
3. Prefix valid lifetime 3. Prefix valid lifetime
4. Expiry time 4. Expiry time
The expiry time for entries in DNARouterLearnedPrefixList is 3 times The expiry time for entries in DNARouterLearnedPrefixList is
maximum of MaxRtrAdvInterval after the last received Router LEAST_VALID_LIFETIME after the last received Router Advertisement
Advertisement affecting the entry, or the scheduled expiry of the affecting the entry, or the scheduled expiry of the prefix valid
prefix valid lifetime, whichever is earlier. lifetime, whichever is earlier.
For each interface, routers also maintain a list of the other routers For each interface, routers also maintain a list of the other routers
advertising on the link. The list will be referred to in this memo advertising on the link. The list will be referred to in this memo
as "DNARouterList". For each router from which a Router as "DNARouterList". For each router from which a Router
Advertisement is received with the DNAAware flag set, the following Advertisement is received with the DNAAware flag set, the following
information MUST be stored: information MUST be stored:
1. Link-local source address of advertising router 1. Link-local source address of advertising router
2. Token equal to the first 64 bits of an SHA-1 hash of the above 2. Token equal to the first 64 bits of an SHA-1 hash of the above
address address
3. Expiry time 3. Expiry time
Each router MUST include itself in the DNARouterList and generate a Each router MUST include itself in the DNARouterList and generate a
token for itself as described above based on the link-local address token for itself as described above based on the link-local address
used in its RA messages. used in its RA messages.
The expiry time for entries in DNARouterList is 3 times maximum of The expiry time for entries in DNARouterList is LEAST_VALID_LIFETIME
MaxRtrAdvInterval after the last received Router Advertisement after the last received Router Advertisement affecting the entry.
affecting the entry.
5.1.2 Router Configuration Variables
A DNAv6 router MUST allow for the following conceptual variables to
be configured by the system management. Default values are set to
ease configuration load.
UnicastRAInterval
The interval corresponding to the maximum average rate of Router
Solicitations that the router is prepared to service with unicast
responses. This is the interval at which the token bucket
controlling the unicast responses is replenished.
Default: 50 milliseconds
MaxUnicastRABurst
The maximum size burst of Router Solicitations that the router is
prepared to service with unicast responses. This is the maximum
number of tokens allowed in the token bucket controlling the
unicast responses.
Default: 20
RASeparation
The separation between responses from different routers on the
same link to a single Router Solicitation.
Default: 20 milliseconds
MulticastRADelay
The delay to be introduced when scheduling a multicast RA in
response to a RS message when the token bucket is empty.
Default: 3000 milliseconds
FastRAThreshold
The maximum number of fast responses that a host should receive
when soliciting for Router Advertisements.
Default: 3
5.1.3 Bootstrapping DNA Data Structures 5.1.2 Bootstrapping DNA Data Structures
As per RFC 2461 [3], when an interface on a host first starts up, it As per RFC 2461 [3], when an interface on a host first starts up, it
SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations
separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of
the routers and prefixes active on the link. DNAv6 requires the the routers and prefixes active on the link. DNAv6 requires the
router to follow the same steps when its interface first starts up, router to follow the same steps when its interface first starts up.
i.e., a router SHOULD transmit up to MAX_RTR_SOLICITATIONS Router
Solicitations separated by RTR_SOLICITATION_INTERVAL to learn quickly
about other routers and prefixes active on the link.
Upon startup, a router interface SHOULD also send a few unsolicited Upon startup, a router interface SHOULD also send a few unsolicited
Router Advertisements as recommended in Section 6.2.4 of RFC 2461 Router Advertisements as recommended in Section 6.2.4 of RFC 2461
[3], in order to inform others routers on the link of its presence. [3], in order to inform others routers on the link of its presence.
During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) *
RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface
both sends unsolicited Router Advertisements and responds to Router both sends unsolicited Router Advertisements and responds to Router
Solicitations, but with a few restrictions on the message content. Solicitations, but the Router Advertisements MUST NOT include any DNA
Router Advertisements MUST NOT include any DNA specific options specific options except for setting the DNAAware flag. The DNAAware
except that the DNAAware flag MUST be set. The DNAAware flag is set flag is set so that other routers will know to include this router in
so that other routers will know to include this router in their their timing calculations for fast RA transmission. Other DNA
timing calculations for fast RA transmission. Other DNA options are options are omitted because the router may have incomplete
omitted because the router may have incomplete information during information during bootstrap.
bootstrap.
During the bootstrap period, the Complete flag in Router During the bootstrap period, the Complete flag in Router
Advertisements MUST NOT be set. Advertisements MUST NOT be set.
During the bootstrap period, the timing of Router Advertisement During the bootstrap period, the timing of Router Advertisement
transmission is as specified in RFC 2461. transmission is as specified in RFC 2461.
5.1.4 Processing Router Advertisements 5.1.3 Processing Router Advertisements
When a router receives a Router Advertisement, it first validates the When a router receives a Router Advertisement, it first validates the
RA as per the rules in RFC 2461, and then performs the actions RA as per the rules in RFC 2461, and then performs the actions
specified in RFC 2461. In addition, each valid Router Advertisement specified in RFC 2461. In addition, each valid Router Advertisement
is processed as follows: is processed as follows:
If the DNAAware flag is set in the RA, the router checks if there is If the DNAAware flag is set in the RA, the router checks if there is
an entry in its DNARouterList. Thus it looks up the source address an entry in its DNARouterList by looking up the source address of the
of the RA in that list and, if not found, a new entry is added to RA in that list. If not found, a new entry is added to
DNARouterList, including the source address and a token equal to the DNARouterList, including the source address and a token equal to the
first 64 bits of an SHA-1 hash of the source address. The entry's first 64 bits of an SHA-1 hash of the source address. The entry's
expiry time is updated. expiry time is updated.
Regardless of the state of the DNAAware flag, each PIO in the RA is Regardless of the state of the DNAAware flag, each PIO in the RA is
examined. If the prefix is not in the router's examined. If the prefix is not in the router's
DNARouterLearnedPrefixList and not in the router's AdvPrefixList [3], DNARouterLearnedPrefixList and not in the router's AdvPrefixList [3],
it is added to the DNARouterLearnedPrefixList, and its expiry time is the prefix is added to the DNARouterLearnedPrefixList, and its expiry
set. time is set.
5.1.5 Processing Router Solicitations 5.1.4 Processing Router Solicitations
The usual response to a Router Solicitation SHOULD be a unicast RA. The usual response to a Router Solicitation SHOULD be a unicast RA.
However, to keep control of the rate of unicast RAs sent, a token However, to keep control of the rate of unicast RAs sent, a token
bucket is used. The token bucket is filled at one token every bucket is used. The token bucket is filled at one token every
UnicastRAInterval. A maximum of MaxUnicastRABurst tokens are stored. UNICAST_RA_INTERVAL. A maximum of MAX_UNICAST_RA_BURST tokens are
stored.
When a Router Solicitation is received, the router checks if it is When a Router Solicitation is received, the router checks if it is
possible to send a unicast response. A unicast response requires possible to send a unicast response. A unicast response requires
that the following conditions to be met: that the following conditions to be met:
o A unicast send token is available. o A unicast send token is available.
o The source address of the Router Solicitation is NOT the o The source address of the Router Solicitation is NOT the
unspecified address (::). unspecified address (::).
If a unicast response is possible and the Router Solicitation If a unicast response is possible and the Router Solicitation
contains a Landmark Option whose prefix is included in contains a Landmark Option whose prefix is present in
DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send
an abbreviated Router Advertisement.This abbreviated advertisement an abbreviated Router Advertisement.This abbreviated advertisement
includes the Landmark prefix in a PIO if the prefix is in the includes the Landmark prefix in a PIO if the prefix is in the
AdvPrefixList or in a LPO if the prefix is found in the AdvPrefixList or in a LPO if the prefix is found in the
DNAROuterLearnedPrefixList, plus the base RA header and any SEND DNAROuterLearnedPrefixList, plus the base RA header and any SEND
options as appropriate. The DNAAware flag MUST be set. The Complete options as appropriate. The DNAAware flag MUST be set. The Complete
flag MUST NOT be set. This is the one exception where the smallest flag MUST NOT be set. This is the one exception where the common
prefix MAY be omitted as the landmark option implies that link change prefix (i.e. the smallest prefix) MAY be omitted.
has not occured and that the previously received smallest prefix is
still current.
If there is NO Landmark Option in the received Router Solicitation or If there is NO Landmark Option in the received Router Solicitation or
it contains a Landmark Option whose prefix is NOT included in it contains a Landmark Option whose prefix is NOT present in
DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is
not possible, then the router SHOULD generate a Complete RA as not possible, then the router SHOULD generate a Complete RA as
specified in Section 5.1.6. The Router Advertisement MUST include specified in Section 5.1.5. The Router Advertisement MUST include
the smallest prefix(es), as described in Section 5.1.7. the common prefix(es), as described in Section 5.1.6.
If a unicast response is possible, then a token is removed and the If a unicast response is possible, then a token is removed and the
Router Advertisement is scheduled for transmission as specified in Router Advertisement is scheduled for transmission as specified in
Section 5.1.8. Section 5.1.7.
If a unicast response is not possible and there is no multicast RA If a unicast response is not possible and there is no multicast RA
already scheduled for transmission in the next MulticastRADelay the already scheduled for transmission in the next MULTICAST_RA_DELAY the
RA MUST be sent to the link-scoped all-nodes multicast address at the RA MUST be sent to the link-scoped all-nodes multicast address at the
current time plus MulticastRADelay. current time plus MULTICAST_RA_DELAY.
If a unicast response is not possible but there is a multicast RA If a unicast response is not possible but there is a multicast RA
already scheduled for transmission in the next MulticastRADelay, then already scheduled for transmission in the next MULTICAST_RA_DELAY,
the Router Solicitation MUST be silently discarded. then the Router Solicitation MUST be silently discarded.
All Router Advertisements sent by a DNA router MUST have the "D" flag All Router Advertisements sent by a DNA router MUST have the "D" flag
set so that hosts processing them know that they can count on the set so that hosts processing them know that they can interpret the
content being interpretable according to this specification. messages according to this specification.
5.1.6 Complete Router Advertisements In order to understand the conditions leading to the different type
of Router Advertisement messages (Abbreviated Vs CompleteRA, Unicast
Vs Multicast), please refer to the figure below,
+---------------+--+----+-----+-----+----+-----+----+-----+----+
| RA Message | Unicast | Multicast |
+---------------+--+----+-----+-----+----+-----+----+-----+----+
| Abbreviated RA| Landmark prefix present| Never |
| | on the link | |
+---------------+--+----+-----+-----+----+-----+----+-----+----+
| Complete RA |No LO in RS or Landmark |No token available in|
| |prefix NOT present | the token bucket. |
| | on the link. | |
+---------------+--+----+-----+-----+----+-----+----+-----+----+
5.1.5 Complete Router Advertisements
A CompleteRA is formed as follows: A CompleteRA is formed as follows:
Starting with a Router Advertisement with all fixed options (MTU, Starting with a Router Advertisement with all fixed options (MTU,
Advertisement Interval, flags, etc.), the DNAAware flag is set. As Advertisement Interval, flags, etc.), the DNAAware flag is set. As
many Prefix Information Options for explicitly configured prefixes as many Prefix Information Options for explicitly configured prefixes as
will fit are added to the Router Advertisement. If there is will fit are added to the Router Advertisement. If there is
sufficient room, a Learned Prefix Option as defined in Section 4.3 sufficient room, a Learned Prefix Option as defined in Section 4.3
containing as many of the learned prefixes as will fit is added. containing as many of the learned prefixes as will fit is added.
It may not be possible to include all of the prefixes in use on the It may not be possible to include all of the prefixes in use on the
link due to MTU or administrative limitations. If all Prefix link due to MTU or administrative limitations. If all Prefix
Information Options and a Learned Prefix Option containing all of the Information Options and a Learned Prefix Option containing all of the
learned prefixes were included in the RA, then the Complete flag in learned prefixes were included in the RA, then the Complete flag in
the Router Advertisement header is set. the Router Advertisement header is set.
If there are known to be prefixes that are not included in the Router If there are known to be prefixes that are not included in the Router
Advertisement, then the Complete flag MUST NOT be set. Advertisement, then the Complete flag MUST NOT be set.
Note that although it may not be possible to fit all of the prefixes Note that although it may not be possible to fit all of the prefixes
into an RA, the smallest prefix(es) MUST be included. into an RA, the smallest prefix(es) MUST be included as discussed in
Section 5.1.6.
5.1.7 Inclusion of smallest prefixes 5.1.6 Inclusion of a common prefixes
The numerically smallest prefix stored in either of Among the prefixes advertised on a link, all routers selects one
DNARouterLearnedPrefixList or AdvPrefixList whose lifetime is greater prefix and include that as a common prefix whenever they send an RA,
than 3 times maximum of MaxRtrAdvInterval is selected as the both solicited and unsolicited.The inclusion of the common prefix
representative of the set of prefixes advertised on the link. For ensures that there always is an overlap in the information advertised
comparing prefixes, they are padded to the right with zeros to make by each router on the link and that hosts will have a common prefix
them 128 bit unsigned integers. to correlate all RA messages received from routers on the same link.
This smallest prefix may be included in the RA in either a PIO or LPO This section presents how the routers select the common prefix
as appropriate. Even when stateful address configuration (DHCPv6) is without pre-arrangement,advertise it and change the common prefix
used, the routers MUST be configured with one prefix, so that the gracefully without causing hosts to mistakenly assume a link change.
smallest prefix can be included in the RA messages. Note that this
smallest prefix is the smallest of all the prefixes configured on the
routers on the link and may not be the smallest prefix used in the
link through stateful address configuration.
5.1.7.1 Changing the smallest prefix Even when stateful address configuration (DHCPv6) is used, at least
one router on a link MUST be configured with one prefix, so that the
common prefix can be included in the RA messages.
When either a new prefix is added to a link that is numerically 5.1.6.1 Selecting the common prefix
smaller than all those previously advertised or the lifetime of the
current smallest prefix falls below 3 times maximum of
MaxRtrAdvInterval, a new smallest prefix SHOULD be determined. In
order to ensure that there is overlap between consecutive RAs on the
link, the old smallest prefix must continue to be advertised for some
time alongside the new smallest prefix.
For the purposes of propagating information, it is assumed that after The router MUST pick the smallest prefix of all the prefixes
three advertisements of a change, all routers have been made aware of configured on the routers on the link as the common prefix. The
the change. selection is made from among the prefixes whose valid lifetime is
greater than LEAST_VALID_LIFETIME, and learned prefixes which were
received within LEAST_VALID_LIFETIME.
If the instant that a router sends its first unsolicited For comparing prefixes, they are padded to the right with zeros to
advertisement is time T, then by T + 1 hour at least three such make them 128 bit unsigned integers. Note that this smallest prefix
advertisements will have been made and all routers can be assumed to is the smallest of all the prefixes configured on the routers on the
have received it. Thus by time T + 3 times maximum of link and may not be the smallest prefix used in the link through
MaxRtrAdvInterval, all routers on the link should have also sent at stateful address configuration.
least one advertisement with the new smallest prefix list.
3 times maximum of MaxRtrAdvInterval after first sending an When a router receives a new prefix in PIO, if the prefix is smaller
advertisement with a new smallest prefix it is safe to consider the than the current common prefix and has valid lifetime greater than
old smallest prefix gone and omit the corresponding prefix from RAs LEAST_VALID_LIFETIME, the router selects that new prefix as a new
if desired. common prefix. In case a new prefix smaller than the current common
prefix is advertised in LPIO, the router doesn't change the common
prefix.
Following a change of smallest prefix, the old smallest prefix MUST 5.1.6.2 Advertising the common prefix
be included in RAs for the following 3 times maximum of
MaxRtrAdvInterval. If the smallest prefix changes multiple times Whenever a router sends an RA, whether solicited or unsolicited, it
with the 3 times maximum of MaxRtrAdvInterval time window, the RA MUST include the common prefix in it. Hence, all RAs MUST carry the
SHOULD include all of the smallest prefixes that were advertised common prefix except the abbreviated RA message sent in response to a
RS with LO.
When a router advertises the common prefix, if the common prefix is
explicitly configured on the router, it sends it in PIO. If the
prefix was learned from advertisement of another router on the link,
the router sends the common prefix in LPIO.
5.1.6.3 Changing the common prefix gracefully
Basic idea is, when a router changes a common prefix, it MUST send
both the new common prefix and the old common prefix to ensure an
overlapping prefix among RAs for LEAST_VALID_LIFETIME period and then
it can retire the old common prefix.
When either a new prefix is added to a link that is numerically
smaller than the current common prefix or the lifetime of the current
common prefix falls below LEAST_VALID_LIFETIME, a new common prefix
MUST be determined. In order to ensure that there is overlap between
consecutive RAs on the link, the old common prefix must continue to
be advertised for some time alongside the new common prefix. After
the change, the old common prefix MUST be included in RAs for the
following LEAST_VALID_LIFETIME. If the common prefix changes
multiple times within LEAST_VALID_LIFETIME time window, the RA SHOULD
include all of the previous common prefixes that were advertised
during that time window. during that time window.
5.1.7.1.1 Non-Prefix link identifiers For the purposes of propagating information, it is reasonable to
assume that after three advertisements of the change, all routers
have been made aware of it.
Although this memo only discusses the use of prefixes as "link 5.1.6.3.1 Using non-prefix identifier as common prefix
identifier", a future specification or ammendment may describe a
mechanism to select a "link identifier" that is not a prefix.
Information from the Learned Prefix Option is only stored in Although this memo only discusses the use of prefixes as common
DNAHostPrefixList, and is only used for DNA purposes. Because a identifier among multiple RA messages, a future specification or
length field is used, it is possible to carry any variable length ammendment may describe a mechanism to select a "link identifier"
identifier less than or equal to 128 bits in an LPO and store it in that is not a prefix.
DNAHostPrefixList (Section 5.2.1). To avoid any collision to
prefixes, an future non-prefix link identifier MUST be 128 bits long
and can be included in the LPO of a RA message.
Following a change of link identifier, the old link identifier MUST Sinice information from the Learned Prefix Option is only stored in
be included in RAs in an LPO for the following 3 times maximum of DNAHostPrefixList, and is only used for DNA purposes and because a
MaxRtrAdvInterval. length field is used in LPIO, it is possible to carry any variable
length identifier less than or equal to 128 bits in an LPIO and store
it in DNAHostPrefixList (Section 5.2.1). To avoid any collision to
prefixes, an future non-prefix link identifier MUST be 128 bits long
and can be included in the LPIO of a RA message.
Future specifications are advised NOT to treat the information in an Future specifications are advised NOT to treat the information in an
LPO as prefixes such as they would the prefixes found in a Prefix LPIO as prefixes such as they would the prefixes found in a Prefix
Information Option. Future specifications are also advised NOT to Information Option. Future specifications are also advised NOT to
assume that the entries in a host's DNAHostPrefixList are actual assume that the entries in a host's DNAHostPrefixList are actual
prefixes in use on the link. prefixes in use on the link.
5.1.8 Scheduling Fast Router Advertisements 5.1.7 Scheduling Fast Router Advertisements
RAs may need to be delayed to avoid collisions in the case that there RAs may need to be delayed to avoid collisions in the case that there
is more than one router on a link. The delay is calculated by is more than one router on a link. The delay is calculated by
determining a ranking for the router for the received RS, and determining a ranking for the router for the received RS, and
multiplying that by RASeparation. multiplying that by RA_SEPARATION.
A Host Token is needed from the RS to calculate the router's ranking. A Host Token is needed from the RS to calculate the router's ranking.
The first 64 bits of an SHA-1 hash of the source address of the RS The first 64 bits of an SHA-1 hash of the source address of the RS
MUST be used as the RS host token. MUST be used as the RS host token.
A router's ranking is determined by taking the XOR of the RS Host A router's ranking is determined by taking the XOR of the RS Host
Token and each of the stored Router Tokens. The results of these XOR Token and each of the stored Router Tokens. The results of these XOR
operations are sorted lowest to highest. The router corresponding to operations are sorted lowest to highest. The router corresponding to
the first entry in the sorted list is ranked zero, the second, one, the first entry in the sorted list is ranked zero, the second, one,
and so on. and so on.
Note: it is not necessary for a router to actually sort the whole Note: it is not necessary for a router to actually sort the whole
list. Each router just needs to determine its own position in the list. Each router just needs to determine its own position in the
sorted list. sorted list.
If Rank < FastRAThreshold, then the RA MUST be scheduled for If Rank < FAST_RA_THRESHOLD, then the RA MUST be scheduled for
transmission in Rank * RASeparation milliseconds. When the router is transmission in Rank * RA_SEPARATION milliseconds. When the router
ranked as zero, the resulting delay is zero, thus the RA SHOULD be is ranked as zero, the resulting delay is zero, thus the RA SHOULD be
sent immediately. sent immediately.
If Rank >= FastRAThreshold, then the RA MUST be replaced with a If Rank >= FAST_RA_THRESHOLD, then the RA MUST be replaced with a
Complete RA, if it is not one already, and scheduled for multicast Complete RA, if there is not one already, and scheduled for multicast
transmission as in RFC 2461. transmission as in RFC 2461.
5.1.9 Scheduling Unsolicited Router Advertisements 5.1.8 Scheduling Unsolicited Router Advertisements
Unsolicited router advertisements MUST be scheduled as per RFC 2461. Unsolicited router advertisements MUST be scheduled as per RFC 2461.
The "D" flag in the RA header MUST be set. The "D" flag in the RA header MUST be set.
They MAY be Complete RAs or MAY include only a subset of the They MAY be Complete RAs or MAY include only a subset of the
configured prefixes, but MUST include the smallest prefix. configured prefixes, but MUST include the common prefix as discussed
in Section 5.1.6.
This ensures that there will be overlap in the sets of prefixes This ensures that there will be overlap in the sets of prefixes
contained in consecutive RAs on a link from DNA routers, and thus an contained in consecutive RAs on a link from DNA routers, and thus an
absence of that overlap can be used to infer link change. absence of that overlap can be used to infer link change.
5.1.10 Removing a Prefix from an Interface 5.1.9 Removing a Prefix from an Interface
When a prefix is to stop being advertised in a PIO in RAs by an When a prefix is to stop being advertised in a PIO in RAs by an
interface before the expiry of the prefix's valid lifetime, then the interface before the expiry of the prefix's valid lifetime, then the
router should treat it as though it has just learned a prefix that is router MUST add the prefix to the DNARouterLearnedPrefixList and set
not explicitly configured on it. After sending the last RA it to expire in LEAST_VALID_LIFETIME or at the expiry of the last
containing the prefix in a PIO, the router MUST add the prefix to the advertised valid lifetime, whichever is earlier. This ensures that
DNARouterLearnedPrefixList and set it to expire in 3 times maximum of to hosts there will be overlap in the prefixes in the RAs they see
MaxRtrAdvInterval or at the expiry of the last advertised valid and prevent them from incorrectly interpreting changed prefixes as
lifetime, whichever is earlier. This ensures that to hosts there movement.
will be overlap in the prefixes in the RAs they see and prevent them
from incorrectly interpreting changed prefixes as movement.
5.1.10.1 Early Removal of the smallest Prefix 5.1.9.1 Early Removal of the common Prefix
If the smallest prefix is to be withdrawn early from a link, that is If the common (the smallest) prefix is to be withdrawn early from a
before the expiry of its previously advertised valid lifetime, it link, that is before the expiry of its previously advertised valid
MUST be advertised for at least 3 times maximum of MaxRtrAdvInterval lifetime, it MUST be advertised for at least LEAST_VALID_LIFETIME
with a valid lifetime of less than 3 times maximum of with a valid lifetime of less than LEAST_VALID_LIFETIME. This
MaxRtrAdvInterval. This ensures that all of the other routers are ensures that all of the other routers are notified to begin the
notified to begin the process of changing the smallest prefix as process of changing the common prefix as well, and hosts will always
well, and hosts will always see overlap between the prefixes in see overlap between the prefixes in consecutive RAs and thus not
consecutive RAs and thus not mistake an RA for an indication of link mistake an RA for an indication of link change.
change.
5.1.11 Prefix Reassignment 5.1.10 Prefix Reassignment
A prefix whose lifetime has expired after counting down in real time A prefix whose lifetime has expired after counting down in real time
for at least 3 times maximum of MaxRtrAdvInterval may be reassigned for at least LEAST_VALID_LIFETIME may be reassigned to another link
to another link immediately after expiry. If a prefix is withdrawn immediately after expiry. If a prefix is withdrawn from a link
from a link without counting down to the expiry of its valid without counting down to the expiry of its valid lifetime, it SHOULD
lifetime, it SHOULD NOT be reassigned to another link for at least 3 NOT be reassigned to another link for at least LEAST_VALID_LIFETIME
times maximum of MaxRtrAdvInterval or until the original expiry time, or until the original expiry time, whichever is earlier. This gives
whichever is earlier. This gives sufficient time for other routers sufficient time for other routers that have learned the prefix to
that have learned the prefix to expire it, and for hosts that have expire it, and for hosts that have seen advertisements from those
seen advertisements from those routers to expire the prefix as well. routers to expire the prefix as well.
Earlier reassignment may result in hosts that move from between the Earlier reassignment may result in hosts that move from between the
old and new links failing to detect the movement. old and new links failing to detect the movement.
When the host is sure that the prefix list is complete, a false When the host is sure that the prefix list is complete, a false
movement assumption may happen due to renumbering when a new prefix movement assumption may happen due to renumbering when a new prefix
is introduced in RAs at about the same time as the host handles the is introduced in RAs at about the same time as the host handles the
'link UP' event. We may solve the renumbering problem with minor 'link UP' event. We may solve the renumbering problem with minor
modification like below. modification as specified below.
When a router starts advertising a new prefix, for the time being, When a router starts advertising a new prefix, it includes at least
every time the router advertises a new prefix in an RA, it includes one old prefix in the same RA. The old prefix assures that the host
at least one old prefix in the same RA. The old prefix assures that doesn't falsely assume a link change because of a new prefix. After
the host doesn't falsely assume a link change because of a new a while, hosts will recognize the new prefix as the one assigned to
prefix. After a while, hosts will recognize the new prefix as the the current link and update its prefix list.
one assigned to the current link and update its prefix list.
In this way, we may provide a fast and robust solution. If a host In this way, we may provide a fast and robust solution. If a host
can make the Complete Prefix List with certainty, it can check for can make the Complete Prefix List with certainty, it can check for
link change fast. Otherwise, it can fall back on a slow but robust link change fast. Otherwise, it can fall back on a slow but robust
scheme. It is up to the host to decide which scheme to use. scheme. It is up to the host to decide which scheme to use.
5.2 DNA Host Operation 5.2 DNA Host Operation
Hosts collect information about the prefixes available on the link to Hosts collect information about the prefixes advertised on the link
which they are connected to facilitate change detection. to facilitate change detection.
5.2.1 Data Structures 5.2.1 Data Structures
Hosts MUST maintain a list of prefixes advertised on the link. This Hosts MUST maintain a list of prefixes advertised on the link. This
is separate from the RFC 2461 "Prefix List" and will be referred to is separate from the RFC 2461 "Prefix List" and will be referred to
here as the "DNAHostPrefixList". All prefixes SHOULD be stored, here as the "DNAHostPrefixList". All prefixes SHOULD be stored,
however an upper bound MUST be placed on the number stored to prevent however an upper bound MUST be placed on the number stored to prevent
overflow. For each prefix stored the host MUST store the following overflow. For each prefix stored the host MUST store the following
information: information:
skipping to change at page 25, line 17 skipping to change at page 22, line 8
2. Prefix length 2. Prefix length
3. Expiry time 3. Expiry time
If a host is not able to store this information for every prefix, If a host is not able to store this information for every prefix,
there is a risk that the host will incorrectly decide that it has there is a risk that the host will incorrectly decide that it has
moved to a new link, when it receives advertisements from a non-DNA moved to a new link, when it receives advertisements from a non-DNA
router. router.
Prefix entries in the DNAHostPrefixList expire and MUST be removed 3 Prefix entries in the DNAHostPrefixList expire and MUST be removed
times maximum of MaxRtrAdvInterval after they are last seen in a LEAST_VALID_LIFETIME after they are last seen in a received Router
received Router Advertisement (in either a PIO or LPO) or at the Advertisement (in either a PIO or LPIO) or at the expiry of the valid
expiry of the valid lifetime of the prefix, whichever is earlier. lifetime of the prefix, whichever is earlier.
Host MUST also maintain a boolean flag, DNARAReceivedFlag, indicating
whether or not the host received a DNA RA message (RA message with
the "D" flag set) on this link. This value is initialized to zero
everytime a link change happens and is set to 1 when the first DNA RA
message is received.
Hosts SHOULD also maintain a "Landmark Prefix" as described in Hosts SHOULD also maintain a "Landmark Prefix" as described in
Section 5.2.4. Section 5.2.4.
5.2.2 Host Configuration Variables 5.2.2 Host Configuration Variables
Hosts MUST make use of the following conceptual variables and they Hosts MUST make use of the following conceptual variables and they
SHOULD be configurable: SHOULD be configurable:
DNASameLinkDADFlag DNASameLinkDADFlag
skipping to change at page 25, line 48 skipping to change at page 22, line 33
Boolean value indicating whether or not a host should re-run DAD Boolean value indicating whether or not a host should re-run DAD
when DNA indicates that link change has not occurred. when DNA indicates that link change has not occurred.
Default: False Default: False
5.2.3 Detecting Network Attachment Steps 5.2.3 Detecting Network Attachment Steps
An IPv6 host SHOULD follow the following steps when they receive a An IPv6 host SHOULD follow the following steps when they receive a
DNA Hint indicating the possibility of link change. DNA Hint indicating the possibility of link change.
1. Mark all the IPv6 addresses in use as optimistic. Set 1. Mark all the preferred IPv6 addresses in use as optimistic. See
DNARAReceivedFlag to zero. Section 5.2.7.2.
2. Set all Neighbor Cache entries for routers on its Default Router 2. Set all Neighbor Cache entries for routers on its Default Router
List to STALE. List to STALE.
3. Send router solicitation. (See Section 5.2.5). 3. Send router solicitation. (See Section 5.2.5).
4. Receive router advertisement(s). 4. Receive router advertisement(s).
5. Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add 5. Mark the router Neighbor Cache Entry [3] as REACHABLE for the
a Neighbor Cache Entry in the REACHABLE state if one does not router from which RA(s) arrived, or add a new Neighbor Cache
Entry for the router in the REACHABLE state if one does not
currently exist. currently exist.
6. Process received router advertisement. (See Section 5.2.6). 6. Process received router advertisement. (See Section 5.2.6).
7. If the link has changed 7. If the link has changed
Change the IP configuration parameters of the host (see Change the IP configuration parameters of the host (see
Section 5.2.7). Section 5.2.7).
8. If the link has NOT changed 8. If the link has NOT changed
Restore the address configuration state of all the IPv6 Restore the address configuration state of all the IPv6
addresses known to be on the link. addresses known to be on the link. See Section 5.2.7.2.
9. Update default routers list and their reachability information 9. Update default routers list and their reachability information
(see Section 5.2.6.3). (see Section 5.2.6.3).
5.2.4 Selection of a Landmark Prefix 5.2.4 Selection of a Landmark Prefix
For each interface, hosts SHOULD choose a prefix to use as a Landmark For each interface, hosts SHOULD choose a prefix to use as a Landmark
Prefix in Router Solicitations. The following rules are used in Prefix in Router Solicitations. The following rules are used in
selecting the landmark prefix: selecting the landmark prefix:
The prefix MUST have a non-zero valid lifetime. If the valid The prefix MUST have a non-zero valid lifetime. If the valid
lifetime of a previously selected Landmark Prefix expires, a new lifetime of a previously selected Landmark Prefix expires, a new
Landmark Prefix MUST be selected. Landmark Prefix MUST be selected.
The prefix MUST be one of those that the hosts has used to assign The prefix MUST be one of those that the hosts has used to assign
a non-link-local address to itself a non-link-local address to itself.
The prefix SHOULD be chosen as the one with the longest preferred The prefix SHOULD be chosen as the one with the longest preferred
lifetime, but it is not necessary to switch to different prefix if lifetime, but it is not necessary to switch to different prefix if
the preferred lifetime of the current landmark prefix changes. the preferred lifetime of the current landmark prefix changes.
5.2.5 Sending Router Solicitations 5.2.5 Sending Router Solicitations
Upon the occurrence of a Layer 2 link-up event notification, hosts Upon the occurrence of a Layer 2 link-up event notification, hosts
SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting
and/or hysteresis to this behaviour as appropriate to the link and/or hysteresis to this behaviour as appropriate to the link
technology subject to the reliability of the DNA Hints. technology subject to the reliability of the DNA Hints.
When the host receives a link UP notification from its link layer, it Editor's note: The following two paragraph are talking about behavior
sets time_last_linkUP_received to the current time. specified by 2461. Do we want to keep these?
The host also uses this to trigger sending an RS, subject to the rate The host also uses this to trigger sending an RS, subject to the rate
limitations in [3]. Since there is no natural limit on how limitations in [3]. Since there is no natural limit on how
frequently the link UP notifications might be generated, we take the frequently the link UP notifications might be generated, we take the
conservative approach that even if the host establishes new link conservative approach that even if the host establishes new link
layer connectivity very often, under no circumstances should it send layer connectivity very often, under no circumstances should it send
Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL
as specified by RFC 2461 [3]. as specified by RFC 2461 [3].
If the RS does not result in the host receiving at least one RA with If the RS does not result in the host receiving at least one RA with
skipping to change at page 27, line 42 skipping to change at page 24, line 29
the landmark prefix chosen based on the rules in Section 5.2.4. the landmark prefix chosen based on the rules in Section 5.2.4.
Hosts SHOULD include a tentative source link layer address option Hosts SHOULD include a tentative source link layer address option
(TO) in the RS message Section 5.3. The router solicitation message (TO) in the RS message Section 5.3. The router solicitation message
is sent to the All_Routers_Multicast address and the source address is sent to the All_Routers_Multicast address and the source address
MUST be the link local address of the host. MUST be the link local address of the host.
The host MUST consider its link local address to be in the The host MUST consider its link local address to be in the
"Optimistic" state for duplicate address detection [5] until either "Optimistic" state for duplicate address detection [5] until either
the returned RA confirms that the host has not switched to a new link the returned RA confirms that the host has not switched to a new link
or, if an link change has occurred, the host has performed optimistic or, if an link change has occurred, until the host has performed
duplicate address detection for the address. optimistic duplicate address detection for the address.
5.2.6 Processing Router Advertisements 5.2.6 Processing Router Advertisements
When the host receives a Router Advertisement, the host checks for When the host receives a Router Advertisement, the host checks for
the following conditions in the given order and derives the the following conditions in the given order and derives the
associated conclusions given below: associated conclusions given below:
If the RA includes a prefix that matches an entry in If the RA includes a prefix that matches an entry in its
DNAHostPrefixList, then the host can conclude that no link change DNAHostPrefixList, then the host SHOULD conclude that no link
has occurred and the current configuration can be assumed to still change has occurred and the current configuration can be assumed
be current. to still be current.
If the RA is a Complete RA, as indicated by the "Complete" flag in If the RA is a Complete RA, as indicated by the "Complete" flag in
the RA header, and there are no prefixes included in it in either the RA header, and there are no prefixes included in it in either
a PIO or LPO that are also in the host's DNAHostPrefixList, then a PIO or LPIO that are also in the host's DNAHostPrefixList, then
the host can conclude that it has changed link and SHOULD initiate the host MUST conclude that it has changed link and MUST initiate
re-configuration using the information in the received Router re-configuration using the information in the received Router
Advertisement. Advertisement.
If the RA is a DNA RA, as indicated by the "D" flag set in the RA
header, previously a DNA RA was received on this link as indicated
by the DNARAReceivedFlag being set to 1, and there are no prefixes
included in it in either a PIO or LPO that are also in the host's
DNAHostPrefixList, then the host can conclude that it has changed
link and SHOULD initiate re-configuration using the information in
the received Router Advertisement.
If the host has the complete prefix list (CPL) and the RA does NOT If the host has the complete prefix list (CPL) and the RA does NOT
include any prefixes in either a PIO or LPO that matches a prefix include any prefixes in either a PIO or LPIO that matches a prefix
in CPL then the host can conclude that link change has occurred in CPL then the host MUST conclude that link change has occurred
and use the information in the received RA to configure itself. and use the information in the received RA to configure itself.
If the host doesn't have the complete prefix list (CPL), the If the host doesn't have the complete prefix list (CPL), the
received RA is not complete, contains no prefixes that are stored received RA is not complete, contains no prefixes that are stored
in DNAHostPrefixList, does not contain a Landmark Option that in DNAHostPrefixList, then the host SHOULD execute RS/RA exchange
matches a corresponding option in the most recent RS, then the until num_RS_RA is equal to NUM_RS_RA_COMPLETE to create a new CPL
host SHOULD send RS/RA exchange until num_RS_RA is equal to and compare it with the already known prefixes. If after
NumRSRAComplete to create a new CPL and compare it with the NUM_RS_RA_COMPLETE exchanges still no prefix received in either a
already known prefixes. If after NumRSRAComplete exchanges still PIO or LPO of the RAs match known prefixes, the host MUST conclude
no prefix received in either a PIO or LPO of the RAs match known link change. If a matching prefix is received in the RAs, then
prefixes, the host MUST conclude link change. If a matching the host SHOULD conclude that no link change has occured.
prefix is received in the RAs, then the host MUST conclude that no
link change has occured.
If the received RA has the "D" flag set, then set
DNARAReceivedFlag to one.
5.2.6.1 Pseudocode 5.2.6.1 Pseudocode
IF (Receive RA contains a prefix matching a prefix in IF (Receive RA contains a prefix matching a prefix in
DNAHostPrefixList) THEN DNAHostPrefixList) THEN
{ {
/* This case covers the landmark prefix being included in the RA, /* This case covers the landmark prefix being included in the RA,
smallest prefix included in RA or CompleteRA message containg all smallest prefix included in RA or CompleteRA message containg all
prefixes*/ prefixes*/
No link change has occured. No link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
skipping to change at page 29, line 27 skipping to change at page 25, line 50
/* We already checked if there are any matching prefix before. /* We already checked if there are any matching prefix before.
Since this is a CompleteRA, implies link-change.*/ Since this is a CompleteRA, implies link-change.*/
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
IF (Receive RA is a DNA RA) THEN
{
/* We already checked if there are any matching prefix before.
Since this is a DNA RA, Check if previous DNA RA was received.*/
IF (DNARAReceivedFlag is set) THEN
/* If we previously received a DNA RA and don't see an overlap in
the prefix list - the smallest prefix is different on this link -
that means link change */
{ {
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} } -->
}
IF (DNAHostPrefixList is marked as complete (i.e. the completeness IF (DNAHostPrefixList is marked as complete (i.e. the completeness
criteria is already met)) THEN criteria is already met)) THEN
{ {
/* We already checked if there are any matching prefix before. /* We already checked if there are any matching prefix before.
Since the DNAHostPrefixList is complete, implies link-change.*/ Since the DNAHostPrefixList is complete, implies link-change.*/
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
skipping to change at page 30, line 15 skipping to change at page 26, line 24
/* We already checked if there are any matching prefix before. /* We already checked if there are any matching prefix before.
Since the DNAHostPrefixList is complete, implies link-change.*/ Since the DNAHostPrefixList is complete, implies link-change.*/
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
Wait for NumRSRAComplete exchanges of RS/RA message to be done since Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done
the previous link_up event. since the previous link UP event (Previous link UP event here refers
to the link UP received before the current link UP event that lead to
this processing).
IF (One of the received RA contains a prefix matching a prefix in IF (One of the received RA contains a prefix matching a prefix in
DNAHostPrefixList from before link UP event), THEN No link change has DNAHostPrefixList from before the current link UP event), THEN No
occured ELSE link change has occured. link change has occured ELSE link change has occured.
If the received RA has the "D" flag set, then set DNARAReceivedFlag
to one.
5.2.6.2 Maintaining the DNAHostPrefixList 5.2.6.2 Maintaining the DNAHostPrefixList
If a Router Advertisement does not indicate a link change, the host The host should maintain a current DNAHostPrefixList with the
updates its DNAHostPrefixList, adding any new prefixes if necessary. prefixes learned after the current link UP event and a previous
DNAHostPrefixList with prefixes learned prior to the link UP event.
These data structures are maintained per interface.
If the Router Advertisement has the C flag set, then the host SHOULD If the Router Advertisement has the C flag set, then the host SHOULD
make the DNAHostPrefixList match the contents of the advertisement make the current DNAHostPrefixList match the contents of the
and mark it as complete (i.e. it becomes CPL). Any new prefixes are advertisement and mark it as complete (i.e. it becomes CPL). Any new
added and any prefixes in the list that are absent in the prefixes are added and any prefixes in the list that are absent in
advertisement are removed. Expiry times on prefixes are updated if the advertisement are removed. Expiry times on prefixes are updated
the prefix was contained in a PIO, but not if it was contained in an if the prefix was contained in a PIO, but not if it was contained in
LPO. an LPO.
If the Router Advertisement does not have the C flag set, then the If the Router Advertisement does not have the C flag set, then the
host SHOULD add any new prefixes and update expiry times as above, host SHOULD add any new prefixes and update expiry times as above,
but SHOULD NOT remove any entries from DNAHostPrefixList. but SHOULD NOT remove any entries from DNAHostPrefixList.
When initiating reconfiguration due to link change, the host MUST If the host decides that a link change has occurred after processing
remove all prefixes in the DNAHostPrefixList and repopulate it with the received RA message, it uses the information available in the
the prefixes in the Prefix Information Options and Learned Prefix current DNAHostPrefixList to configure itself as specified in
Option, if any, in the RA. Section 5.2.7. If the host decides that it is on the same link, then
the current DNAHostPrefixList and the previous DNAHostPrefixList are
In addition, the host maintains previous DNAHostPrefixList. It is merged as specified in the next sub-section and the merged list
per interface since there are some security issues when merging becomes the current DNAHostPrefixList.
across interfaces.
The operations on DNAHostPrefixList is to create a new one, discard
one, and merge two of them together. The issues with merging are
discussed in the next sub-section.
For each interface, the host maintains the last time a valid RA was
received (called time_last_RA_received in this document), which
actually ignores RAs without prefix options, and the last time a link
UP notification was received from the link layer on the host (called
time_last_linkUP_received in this document). Together these two
conceptual variables serve to identify when a RA containing disjoint
prefixes can't be due to being attached to a new link, because there
was no link UP notification.
For each interface, the host also maintains a counter (called For each interface, the host also maintains a counter (called
num_RS_RA) which counts how many successful RS/RA exchanges have been num_RS_RA) which counts how many successful RS/RA exchanges have been
accomplished since the last time the host moved to a different link. accomplished since the last time the host moved to a different link.
The host declares "one successful RS/RA exchange" is accomplished Note that this is not necessarily since the last link UP event as a
after it sends an RS, waits for MinRAWait seconds and receives a link UP event may not correspond to an actual link change. The host
positive number of resulting RAs. At least one RA (with at least one declares "one successful RS/RA exchange" is accomplished after it
prefix) should be received. After the RS, if a link UP event occurs sends an RS, waits for MIN_RA_WAIT seconds and receives a positive
before MinRAWait seconds expire, the host should not assume that a number of resulting RAs. At least one RA (with at least one prefix)
should be received. After the RS, if a link UP event occurs before
MIN_RA_WAIT seconds expire, the host should not assume that a
successful RS/RA exchange is accomplished. This counter is used to successful RS/RA exchange is accomplished. This counter is used to
determine when DNAHostPrefixList is considered to be complete. The determine when DNAHostPrefixList is considered to be complete. The
host SHOULD conclude that the prefix list is complete when host SHOULD conclude that the prefix list is complete when
NumRSRAComplete number of RS/RA exchanges have been completed or a RA NUM_RS_RA_COMPLETE number of RS/RA exchanges have been completed or a
message with the complete bit set is received. The complete RA message with the complete bit set is received. The complete
DNAHostPrefixList is also refered to as CPL ( Complete Prefix List). DNAHostPrefixList is also refered to as CPL ( Complete Prefix List).
After NumRSRAComplete RS/ RA exchange, the host will generate the After NUM_RS_RA_COMPLETE RS/ RA exchange, the host will generate the
Complete Prefix List if there is no packet loss. Even though some Complete Prefix List if there is no packet loss.
packet loss may cause an Incomplete Prefix List, there is a further
chance for the host to get the missing prefixes before it receives
link UP notification, i.e. moves to another PoA. Even if the host
moves to another PoA with Incomplete Prefix List,but if it has not
changed link, there is good chance that the first RA may contain a
prefix from its (incomplete) prefix list. Considering all those
above, even if the host performs only one RS/ RA exchange, it will be
rather rare for the host to falsely assume a link change. Moreover,
even in case of false detection, there would be no connectivity
disruption, because Incomplete Prefix List causes only additional
signaling.
5.2.6.2.1 Merging DNAHostPrefixList 5.2.6.2.1 Merging DNAHostPrefixList
When a host has been collecting information about a potentially When a host has been collecting information about a potentially
different link in its Current DNAHostPrefixList, and it discovers different link in its Current DNAHostPrefixList, and it discovers
that it is in fact the same link as another DNAHostPrefixList, then that it is in fact the same link as another DNAHostPrefixList, then
it needs to merge the information in the two objects to produce a it needs to merge the information in the two objects to produce a
single new object. Since the DNAHostPrefixList contains the most single new object. Since the DNAHostPrefixList contains the most
recent information, any information contained in it will override the recent information, any information contained in it will override the
information in the old DNAHostPrefixList, for example the remaining information in the old DNAHostPrefixList, for example the remaining
skipping to change at page 34, line 38 skipping to change at page 30, line 23
source address on the DNA RS. If the host had no "Preferred" unicast source address on the DNA RS. If the host had no "Preferred" unicast
link local address but did have an address in the "Optimistic" state, link local address but did have an address in the "Optimistic" state,
it MUST utilize such an address as the source address. If the host it MUST utilize such an address as the source address. If the host
currently has no unicast link local addresses, it MUST construct one currently has no unicast link local addresses, it MUST construct one
and put it into the "Optimistic" state and note this address as and put it into the "Optimistic" state and note this address as
having been in the "Optimistic" state previously, but defer sending having been in the "Optimistic" state previously, but defer sending
the NS to confirm. Note that the presence of a duplicate unicast the NS to confirm. Note that the presence of a duplicate unicast
link local address on the link will not interfere with the ability of link local address on the link will not interfere with the ability of
the link to route a unicast DNA RA from the router back to the host the link to route a unicast DNA RA from the router back to the host
nor will it result in corruption of the router's neighbor cache, nor will it result in corruption of the router's neighbor cache,
because the TSLLA option is included in the RS and is utilized by the because the TO is included in the RS and is utilized by the router on
router on the RA frame without changing the neighbor cache. the RA frame without changing the neighbor cache.
When the host receives unicast or multicast RAs from the router, if When the host receives unicast or multicast RAs from the router, if
the host determines from the received RAs that it has moved to a new the host determines from the received RAs that it has moved to a new
link, the host MUST immediately move all unicast global addresses to link, the host MUST immediately move all unicast global addresses to
the "Deprecated" state and configure new addresses using the subnet the "Deprecated" state and configure new addresses using the subnet
prefixes obtained from the RA. For all unicast link local addresses, prefixes obtained from the RA. For all unicast link local addresses,
the host MUST initiate NS signaling for optimistic Duplicate Address the host MUST initiate NS signaling for optimistic Duplicate Address
Detection to confirm the uniqueness of the unicast link local Detection to confirm the uniqueness of the unicast link local
addresses on the new link. addresses on the new link.
skipping to change at page 37, line 11 skipping to change at page 32, line 41
confirmed whether or not a link change has occurred. confirmed whether or not a link change has occurred.
5.3 Tentative options for IPv6 ND 5.3 Tentative options for IPv6 ND
5.3.1 Sending solicitations containing Tentative Options 5.3.1 Sending solicitations containing Tentative Options
Tentative Options may be sent in Router and Neighbour Solicitations, Tentative Options may be sent in Router and Neighbour Solicitations,
as described below. as described below.
In a case where it is safe to send a Source Link-Layer Address In a case where it is safe to send a Source Link-Layer Address
Option, a host SHOULD NOT send a TO, since the message may Option, a host SHOULD NOT send a TO, since the message may be
bemisinterpreted by legacy nodes. misinterpreted by legacy nodes.
Importantly, a node MUST NOT send a Tentative Option in the same Importantly, a node MUST NOT send a Tentative Option in the same
message where a Source Link-Layer Address Option is sent. message where a Source Link-Layer Address Option is sent.
5.3.1.1 Sending Neighbour Solicitations with Tentative Options 5.3.1.1 Sending Neighbour Solicitations with Tentative Options
Neighbour Solicitations sent to unicast addresses MAY contain a Neighbour Solicitations sent to unicast addresses MAY contain a
Tentative Option. Tentative Option.
Since delivery of a packet to a unicast destination requires prior
knowledge of the destination's hardware address, unicast Neighbour
Solicitation packets may only be sent to destinations for which a
neighbour cache entry already exists.
For example, if checking bidirectional reachability to a router, it
may be possible to send a Neighbour Solicitation with Tentative
Option to the router's advertised address.
As discussed in [3], the peer device may not have a cache entry even
if the soliciting host does, in which case reception of the Tentative
Option may create a neighbour cache entry, without the need for
neighbour discovering the original solicitor.
5.3.1.2 Sending Router Solicitations with Tentative Options 5.3.1.2 Sending Router Solicitations with Tentative Options
Any Router Solicitation from a Preferred, Deprecated or Optimistic Any Router Solicitation from a Preferred, Deprecated or Optimistic
address MAY be sent with a Tentative Option [5]. address MAY be sent with a Tentative Option [5].
An extension which allows Router Solicitations to be sent with a TO An extension which allows Router Solicitations to be sent with a TO
from the unspecified address is described in Appendix A. from the unspecified address is described in Section 5.3.3.
5.3.2 Receiving Tentative Options 5.3.2 Receiving Tentative Options
Receiving a Tentative Option allows nodes to unicast responses to Receiving a Tentative Option allows nodes to unicast responses to
solicitations without performing neighbour discovery. solicitations without performing neighbour discovery.
It does this by allowing the solicitation to create STALE neighbour It does this by allowing the solicitation to create STALE neighbour
cache entries if one doesn't exist, but only update an entry if the cache entries if one doesn't exist, but only update an entry if the
link-layer address in the option matches the entry. link-layer address in the option matches the entry.
Additionally, messages containing TO may be used to direct Additionally, messages containing TO may be used to direct
advertisements to particular link-layer destinations without updating advertisements to particular link-layer destinations without updating
neighbour cache entries. This is described in Appendix A. neighbour cache entries. This is described in Section 5.3.3.
Use of Tentative Options is only defined for Neighbour and Router Use of Tentative Options is only defined for Neighbour and Router
Solicitation messages. Solicitation messages.
In any other received message, the presence of the option is silently In any other received message, the presence of the option is silently
ignored, that is, the packet is processed as if the option was not ignored, that is, the packet is processed as if the option was not
present. present.
It is REQUIRED that the same validation algorithms for Neighbour and It is REQUIRED that the same validation algorithms for Neighbour and
Router Solicitations received with TO as in the IPv6 Neighbour Router Solicitations received with TO as in the IPv6 Neighbour
skipping to change at page 38, line 40 skipping to change at page 34, line 8
difference exists between the TO and an existing neighbour cache difference exists between the TO and an existing neighbour cache
entry, the option MUST be treated as if it were an SLLAO after entry, the option MUST be treated as if it were an SLLAO after
message validation, and processed accordingly. message validation, and processed accordingly.
In the case that a cache entry is unable to be created or updated due In the case that a cache entry is unable to be created or updated due
to existence of a conflicting neighbour cache entry, it MUST NOT to existence of a conflicting neighbour cache entry, it MUST NOT
update the neighbour cache entry. update the neighbour cache entry.
An extension which allows a direct advertisement to the soliciting An extension which allows a direct advertisement to the soliciting
host without modifying the neighbour cache entry is described in host without modifying the neighbour cache entry is described in
Appendix A. Section 5.3.3.
5.3.2.1 Receiving Neighbour Solicitations containing Tentative Options 5.3.2.1 Receiving Neighbour Solicitations containing Tentative Options
The Tentative Option is only [Editor's note: This only is not right? The Tentative Option is allowed in Neighbour Solicitations with
TO is allowed in both NS and RS? right?] allowed in Neighbour specified source addresses for which SLLAO is not required.
Solicitations with specified source addresses for which SLLAO is not
required.
A Neighbour Solicitation message received with a TO and an A Neighbour Solicitation message received with a TO and an
unspecified source address MUST be silently discarded. unspecified source address MUST be silently discarded.
Upon reception of a Tentative Option in a Neighbour Solicitation for Upon reception of a Tentative Option in a Neighbour Solicitation for
which the receiver has the Target Address configured, a node checks which the receiver has the Target Address configured, a node checks
to see if there is a neighbour cache entry with conflicting link- to see if there is a neighbour cache entry with conflicting link-
layer address. layer address.
If no such entry exists, the neighbour cache of the receiver SHOULD If no such entry exists, the neighbour cache of the receiver SHOULD
skipping to change at page 39, line 38 skipping to change at page 35, line 5
For Router Solicitations with unicast source addresses, neighbour For Router Solicitations with unicast source addresses, neighbour
caches SHOULD be updated with the link-layer address from a Tentative caches SHOULD be updated with the link-layer address from a Tentative
Option if there is no differing neighbour cache entry. In this case, Option if there is no differing neighbour cache entry. In this case,
Router Advertisement continues as in Section 6.2.6 of [3]. Router Advertisement continues as in Section 6.2.6 of [3].
For received solicitations with a differing link-layer address to For received solicitations with a differing link-layer address to
that stored in the neighbour cache, the node processes the that stored in the neighbour cache, the node processes the
solicitation as defined in Section 6.2.6 of [3], except that the solicitation as defined in Section 6.2.6 of [3], except that the
Neighbour Cache entry MUST NOT be modified. Neighbour Cache entry MUST NOT be modified.
5.3.3 Sending directed advertisements without the neighbour cache
In the case where an entry is unable to be added to the neighbour
cache, a node MAY send responses direct to the link-layer address
specified in the Tentative Option. Also, RS packets sent without a
specificed source address may potentially contain a Tentative Option.
In this case the unicast link-layer address from the solicitation MAY
be extracted from the Tentative Option and used as the destination of
the link-layer frame for a responding Router Advertisment.
Sending such a packet MUST NOT consult the neighbour or destination
caches for address.
Such packets SHOULD scheduled as if they were unicast advertisements
as specified in [3].
If an implementation can not send a Router Advertisement using
information from the Tentative Option i.e, without consulting the
neighbour cache, then it SHOULD behave as if the Tentative Option was
not present in the solicitation message.
Each router can have its own configuration with respect to sending Each router can have its own configuration with respect to sending
RA, and the treatment of router and neighbor solicitations. RA, and the treatment of router and neighbor solicitations.
Different timers and constants might be used by different routers, Different timers and constants might be used by different routers,
such as the delay between Router Advertisements or delay before such as the delay between Router Advertisements or delay before
replying to an RS. If a host is changing its IPv6 link, the new replying to an RS. If a host is changing its IPv6 link, the new
router on that link may have a different configuration and may router on that link may have a different configuration and may
introduce more delay than the previous default r < title="Overlapping introduce more delay than the previous default r < title="Overlapping
Coverage"> If a host can be attached to different links at the same Coverage"> If a host can be attached to different links at the same
time with the same interface, the host will probably listen to time with the same interface, the host will probably listen to
different routers, at least one on each link. To be simultaneously different routers, at least one on each link. To be simultaneously
skipping to change at page 40, line 44 skipping to change at page 36, line 32
communication between routers on the link), existing router and communication between routers on the link), existing router and
neighbor discovery procedures may be sufficient for detecting change. neighbor discovery procedures may be sufficient for detecting change.
6. Security Considerations 6. Security Considerations
6.1 Attacks on the Token Bucket 6.1 Attacks on the Token Bucket
A host on the link could easily drain the token bucket(s) of the A host on the link could easily drain the token bucket(s) of the
router(s) on the link by continuously sending RS messages on the router(s) on the link by continuously sending RS messages on the
link. For example, if a host sends one RS message every link. For example, if a host sends one RS message every
UnicastRAInterval, and send a additional RS every third UNICAST_RA_INTERVAL, and send a additional RS every third
UnicastRAInterval, the token bucket in the router(s) on the link will UNICAST_RA_INTERVAL, the token bucket in the router(s) on the link
drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. will drain within MAX_UNICAST_RA_BURST * UNICAST_RA_INTERVAL * 3
For the recommended values of UnicastRAInterval and time-units. For the recommended values of UNICAST_RA_INTERVAL and
MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear MAX_UNICAST_RA_BURST, this value is 3000 milliseconds. It is not
whether arrival of such RS messages can be recognized by the router clear whether arrival of such RS messages can be recognized by the
as a DoS attack. This attack can also be mitigated by aggregating router as a DoS attack. This attack can also be mitigated by
responses. Since only one aggregation is possible in this interval aggregating responses. Since only one aggregation is possible in
due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able this interval due to MIN_DELAY_BETWEEN_RAS restriction, the routers
protect the tokens in the bucket. may not be able protect the tokens in the bucket.
6.2 Attacks on DNA Hosts 6.2 Attacks on DNA Hosts
RFC 3756 outlines a collection of threats involving rouge routers. RFC 3756 outlines a collection of threats involving rouge routers.
Since DNAv6 requires a host to obtain trustworthy responses from Since DNAv6 requires a host to obtain trustworthy responses from
routers, such threats are relevant to DNAv6. In order to counter routers, such threats are relevant to DNAv6. In order to counter
such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure
router discovery. router discovery.
6.3 Tentative options 6.3 Tentative options
The use of the Tentative Option in Neighbour and Router Solicitation The use of the Tentative Option in Neighbour and Router Solicitation
messages acts in a similar manner to SLLAO, updating neighbour cache messages acts in a similar manner to SLLAO, updating neighbour cache
entries, in a way which causes packet transmission. entries, in a way which causes packet transmission.
Particular care should be taken that transmission of messages An attacker may cause messages be sent to another node by an
complies with existing IPv6 Neighbour Discovery Procedures, so that
unmodified hosts do not receive invalid messages.
An attacker may cause messages may be sent to another node by an
advertising node (a reflector), without creating any ongoing state on advertising node (a reflector), without creating any ongoing state on
the reflector. the reflector.
This is attack requires one solicitation for each advertisement and This attack requires one solicitation for each advertisement and the
the advertisement has to go to a unicast MAC destination. That said, advertisement has to go to a unicast MAC destination. That said, the
the size of the advertisement may be significantly larger than the size of the advertisement may be significantly larger than the
solicitation, or the attacker and reflector may be on a medium with solicitation, or the attacker and reflector may be on a medium with
greater available bandwidth than the victim. greater available bandwidth than the victim.
For link-layers where it isn't possible to spoof the link-layer For link-layers where it isn't possible to spoof the link-layer
source address this allows a slightly increased risk of reflection source address this allows a slightly increased risk of reflection
attacks from nodes which are on-link. attacks from nodes which are on-link.
Additionally, since a SEND host must always advertise using SEND Additionally, since a SEND host must always advertise using SEND
options and signatures, a non-SEND attacker may cause excess options and signatures, a non-SEND attacker may cause excess
computation on both a victim node and a router by causing SEND computation on both a victim node and a router by causing SEND
advertisement messages to be transmitted to a particular MAC address advertisement messages to be transmitted to a particular MAC address
and the lall-nodes multicast. SEND specifies guidelines to hosts and the all-nodes multicast. SEND specifies guidelines to hosts
receiving unsolicited advertisements in order to mitigate such receiving unsolicited advertisements in order to mitigate such
attacks [4]. attacks [4].
While this is the same effect as experienced when accepting SLLAO While this is the same effect as experienced when accepting SLLAO
from non-SEND nodes, the lack of created neighbour cache entries on from non-SEND nodes, the lack of created neighbour cache entries on
the advertiser may make such attacks more difficult to trace. the advertiser may make such attacks more difficult to trace.
Modification of Neighbour Discovery messages on the network is Modification of Neighbour Discovery messages on the network is
possible, unless SEND is used. [4] provides a protocol specification possible, unless SEND is used. [4] provides a protocol specification
in which soliciting nodes sign ND messages with a private key and use in which soliciting nodes sign ND messages with a private key and use
skipping to change at page 43, line 6 skipping to change at page 38, line 40
While a DNA host is checking for link-change, and observing DAD, it While a DNA host is checking for link-change, and observing DAD, it
may receive a DAD defense NA from an unsecured source. may receive a DAD defense NA from an unsecured source.
SEND says that DAD defenses MAY be accepted even from non SEND nodes SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [4]. for the first configured address [4].
While deconfiguring the address is a valid action in the case where a While deconfiguring the address is a valid action in the case where a
host collides with another address owner after arrival on a new link, host collides with another address owner after arrival on a new link,
In the case that the host returns immediately to the same link, such In the case that the host returns immediately to the same link, such
a DAD defense NA message can only be a denial-of-service attempt. a DAD defense NA message may be a denial-of-service attempt.
6.6 DNA Hint Management Security
Events originating at other protocol layers may provide DNA Hints of
link change to network attachment detection systems. Two examples of
such events are TCP retransmission timeout and completion of link-
layer access procedures [20].
While DNA Hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat DNA Hints from
other protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be
triggered by untrusted messages, come from compromised sources (for
example 802.11 WEP Encryption [15]) or be inaccurate with regard to
network-layer state.
While these DNA Hints come from the host's own stack, such hints may
actually be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to
instigate DNA Hint delivery on a host or multiple hosts deliberately,
in order to prompt packet transmission, or configuration
modification.
Therefore, hosts SHOULD NOT change their configuration state based on
DNA Hints from other protocol layers. A host MAY adopt an
appropriate link change detection strategy based upon DNA Hints
received from other layers, with suitable caution and hysteresis.
7. IANA Considerations 7. IANA Considerations
This memo defines two new Neighbor Discovery [3] options, which must This memo defines three new Neighbor Discovery [3] options, which
be assigned Option Type values within the option numbering space for must be assigned Option Type values within the option numbering space
Neighbor Discovery messages: for Neighbor Discovery messages:
1. The Landmark option, described in Section 4.2; and 1. The Landmark option, described in Section 4.2; and
2. The Learned Prefix option, described in Section 4.3. 2. The Learned Prefix option, described in Section 4.3.
3. The tentative option, described in Section 4.4 3. The tentative option, described in Section 4.4
8. Constants 8. Constants
NumRSRAComplete
Number of RS/RA exchange messages necessary to declare the prefix NUM_RS_RA_COMPLETE
list to be complete.
Definition: Number of RS/RA exchange messages necessary to declare
the prefix list to be complete.
Value: 2 Value: 2
MinRAWait MIN_RA_WAIT
Minimum time the host will have to wait before assuming receipt of Definition: Minimum time the host will have to wait before
all possible RAs. assuming receipt of all possible RAs.
Default: 4 seconds Default: 4 seconds
9. Changes since -04 UNICAST_RA_INTERVAL
Definition: The interval corresponding to the maximum average rate
of Router Solicitations that the router is prepared to service
with unicast responses. This is the interval at which the token
bucket controlling the unicast responses is replenished.
Value: 50 milliseconds
MAX_UNICAST_RA_BURST
Definition: The maximum size burst of Router Solicitations that
the router is prepared to service with unicast responses. This is
the maximum number of tokens allowed in the token bucket
controlling the unicast responses.
Value: 20
RA_SEPARATION
Definition: The separation between responses from different
routers on the same link to a single Router Solicitation.
Value: 20 milliseconds
MULTICAST_RA_DELAY
Definition: The delay to be introduced when scheduling a multicast
RA in response to a RS message when the token bucket is empty.
Value: 3000 milliseconds
FAST_RA_THRESHOLD
Definition: The maximum number of fast responses that a host
should receive when soliciting for Router Advertisements.
Value: 3
LEAST_VALID_LIFETIME
Definition: The time for which received prefix can be considered
valid for use in link indentification.
Value: LEAST_VALID_LIFETIME
9. Changes since -05
o Removed DNARAReceivedFlag and related text. The RA processing is
very simple now: Check for prefix overlap, else if check if
completeRA, else fall back on CPL.
o Changed Router Configuration variables to constants.
o Remove "Complete Prefix List Generation" subsection from the
"Overview" section. The text was not adding that much value to
the document. We talk further about CPL generation in seciton
"Maintaining the DNAHostPrefixList".
o Added a table to explain the conditions for different type of
router advertisement, a table was added to Section 5.1.4.
o All "link change" decisions were made "MUSTs" and "no link change"
decision "SHOULDs" in the process RA message section of the host
operation.
o Revised "Maintained the DNAHostPrefixList" section.
o Revised "Inclusion of the common prefix" section (JinHyeock).
o Thorough review of the whole document.
10. Changes since -04
o Edited the document to improve readability and clarity. o Edited the document to improve readability and clarity.
o Edited the document to make the distinction between what is o Edited the document to make the distinction between what is
recommended by RFC 2461 and what is modified behavior for DNA. recommended by RFC 2461 and what is modified behavior for DNA.
(The flash renumbering sections were not touchted.) (The flash renumbering sections were not touchted.)
10. Changes since -03 11. Changes since -03
o A global replace of "1.5 hours" with "3 times maximum of o A global replace of "1.5 hours" with "3 times maximum of
MaxRtrAdvInterval". MaxRtrAdvInterval".
o Removed Y/N bit from the landmark option and modified the text to o Removed Y/N bit from the landmark option and modified the text to
remove all references to the Y/N bit. The description in remove all references to the Y/N bit. The description in
Section 3.1 was twicked to explain the semantics of Yes and No. Section 3.1 was twicked to explain the semantics of Yes and No.
o Removed MaxCacheTime and reference to use of prior link o Removed MaxCacheTime and reference to use of prior link
information. information.
o Made NumRSRAComplete a constant with value 2, MinRAWait a constant o Made NUM_RS_RA_COMPLETE a constant with value 2, MIN_RA_WAIT a
with value 4 seconds. constant with value 4 seconds.
o Removed reference to the terminology draft as there was nothing o Removed reference to the terminology draft as there was nothing
important to be transferred. important to be transferred.
o Removed sections on Link indication, complications and DNA without o Removed sections on Link indication, complications and DNA without
link UP notifications. link UP notifications.
o Removed reference to linkID and replaced with smallest prefix. o Removed reference to linkID and replaced with smallest prefix.
Which requires a DNARAReceivedFlag to be added to the conceptual Which requires a DNARAReceivedFlag to be added to the conceptual
values maintained by the host. values maintained by the host.
o Included sentence to mandate the configuration of atleast one o Included sentence to mandate the configuration of atleast one
prefix on each routers even when stateful address configuration is prefix on each routers even when stateful address configuration is
used. The change was made in Section 5.1.7. used. The change was made in Section 5.1.6.
11. Changes since -02 12. Changes since -02
o Changed the Router Advertisment processing in Section 5.2.6 and o Changed the Router Advertisment processing in Section 5.2.6 and
Section 5.2.6.1 to fix a mistake in the logic. Section 5.2.6.1 to fix a mistake in the logic.
o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT, o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT,
MAX_CACHE_TIME to NumRSRAComplete, MinRAWait, MaxCacheTIme. Added MAX_CACHE_TIME to NUM_RS_RA_COMPLETE, MIN_RA_WAIT, MaxCacheTIme.
an open issue whether these should be variables or constants. Added an open issue whether these should be variables or
constants.
o Fixed some typos. o Fixed some typos.
12. Open issues 13. Open issues
1. Explain the idea of link identification better. The link is
identified by the "set of prefixes" and a prefix (either landmark
or smallest prefix) is used to identify the particular "set of
prefixes".
2. Do we need all of the router configuration variables?
3. Bootstrapping DNA data structures: Would be good to be more clear
about what is a change w.r.t. standard ND.
4. Future specificaitons MUST NOT: Can't make this sort of
reqirement. You can explain what the assumption/purpose is, but
you can't limit what future protocols do. Soln: The text has
been modified. But, we need text explaining the reasoning behind
recommendations.
5. 5.1.10: Removing a prefix from an interface: The first sentence
is unclear. 2461/2462 already have clear rules about what you do
if you stop advertisign prefixes, and hosts also have clear
rules. Is this document suggesting changes here? And note,
"stopping the advertising of a prefix" before it expires is bad
behavior. If you really mean to depracate it, advertise it with
a 0 lifetime first (this is clear in the other specs). Much of
the above is unclear to me because its not clear who is doing
what (which router? One receiving an RA, the one sending it, the
one proxying it or what?) Possible soln: We could remove section
5.1.10 under the assumption that RFC 2461 already handles the
issue. But, section 12 in RFC 2461 doesn't madate an particular
behavior.
6. This docuemnt isn't always clear about whether it is mandating 1. Is my re-write of Section 5.2.6.2 right?
new behavior or whether just suggesting how things ought to be.
7. The section Section 5.1.7 needs to be written better. 2. Is Section 5.3 still too long?
13. Contributors 14. Contributors
This document is the result of merging four different working group This document is the result of merging four different working group
documents. The draft-ietf-dna-protocol-01.txt authored by James documents. The draft-ietf-dna-protocol-01.txt authored by James
Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock
Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02
authored by JinHyeock Choi and Erik Normark provided the idea/text authored by JinHyeock Choi and Erik Normark provided the idea/text
for the complete prefix list mechanism described in this document. for the complete prefix list mechanism described in this document.
The best current practice for hosts draft (draft-ietf-dna-hosts-03) The best current practice for hosts draft (draft-ietf-dna-hosts-03)
authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and
the tentative options (draft-ietf-dna-tentative-00) authored by Greg the tentative options (draft-ietf-dna-tentative-00) authored by Greg
Daley, Erik Normark and Nick Moore were also adopted into this Daley, Erik Normark and Nick Moore were also adopted into this
document. document.
14. Acknowledgments 15. Acknowledgments
The design presented in this document grew out of discussions among The design presented in this document grew out of discussions among
the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, the members of the DNA design team (JinHyeock Choi, Tero Kauppinen,
James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland).
The spirited debates on the design, and the advantages and dis- The spirited debates on the design, and the advantages and dis-
advantages of various DNA solutions helped the creation of this advantages of various DNA solutions helped the creation of this
document. document.
Thanks to Syam Madanapalli who co-authored Thanks to Syam Madanapalli who co-authored
draft-jinchoi-dna-protocol2 from which this draft draws ideas, as draft-jinchoi-dna-protocol2 from which this draft draws ideas, as
skipping to change at page 47, line 5 skipping to change at page 43, line 8
Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli,
Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review
of draft-ietf-dna-protocol-01. of draft-ietf-dna-protocol-01.
Thanks to Gabriel Montenegro for his review of Thanks to Gabriel Montenegro for his review of
draft-pentland-dna-protocol. draft-pentland-dna-protocol.
Thanks also to other members of the DNA working group for their Thanks also to other members of the DNA working group for their
comments that helped shape this work. comments that helped shape this work.
15. References 16. References
15.1 Normative References 16.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] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, April 2006. IPv6", RFC 4429, April 2006.
15.2 Informative References 16.2 Informative References
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address [7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462 2462, December 1998. Autoconfiguration", RFC2462 2462, December 1998.
[8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998. December 1998.
skipping to change at page 48, line 40 skipping to change at page 44, line 42
draft-ietf-seamoby-mobility-terminology-06 (work in progress), draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004. February 2004.
[22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix [22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress), list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005. April 2005.
Authors' Addresses Authors' Addresses
Sathya Narayanan (editor) Sathya Narayanan (editor)
Panasonic Princeton Laboratory School of Information Technology and Communications Design
Two Research Way, 3rd Floor California State University, Monterey Bay
Princeton, NJ 08540 3110, Inter-Garrison Road, Building 18, Room 150
Seaside, CA 93955
USA USA
Phone: +1 609 734 7599 Phone: +1 (831) 582-3621
Email: sathya@Research.Panasonic.COM Email: sathya@njit.edu
James Kempf James Kempf
DoCoMo Communications Labs USA DoCoMo Communications Labs USA
USA USA
Phone: Phone:
Email: kempf@docomolabs-usa.com Email: kempf@docomolabs-usa.com
Erik Nordmark Erik Nordmark
Sun Microsystems, Inc. Sun Microsystems, Inc.
17 Network Circle 17 Network Circle
skipping to change at page 50, line 29 skipping to change at page 47, line 5
FRANCE FRANCE
Phone: (33) 3 90 24 45 87 Phone: (33) 3 90 24 45 87
Email: montavont@dpt-info.u-strasbg.fr Email: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/ URI: http://www-r2.u-strasbg.fr/~montavont/
Nick 'Sharkey' Moore Nick 'Sharkey' Moore
Email: sharkey@zoic.org Email: sharkey@zoic.org
Appendix A. Sending directed advertisements without the neighbour cache
In the case where an entry is unable to be added to the neighbour
cache, a node MAY send responses direct to the link-layer address
specified in the Tentative Option. Also, RS packets sent without a
specificed source address may potentially contain a Tentative Option.
In this case the unicast link-layer address from the solicitation MAY
be extracted from the Tentative Option and used as the destination of
the link-layer frame for a responding Router Advertisment.
Sending such a packet MUST NOT consult the neighbour or destination
caches for address.
Such packets SHOULD scheduled as if they were unicast advertisements
as specified in [3].
If an implementation can not send a Router Advertisement using
information from the Tentative Option i.e, without consulting the
neighbour cache, then it SHOULD behave as if the Tentative Option was
not present in the solicitation message.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 142 change blocks. 
657 lines changed or deleted 470 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/