draft-ietf-dna-protocol-04.txt   draft-ietf-dna-protocol-05.txt 
DNA Working Group S. Narayanan, Ed. DNA Working Group S. Narayanan, Ed.
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: August 6, 2007 February 2, 2007 Expires: September 5, 2007 March 4, 2007
Detecting Network Attachment in IPv6 Networks (DNAv6) Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-ietf-dna-protocol-04.txt draft-ietf-dna-protocol-05.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 August 6, 2007. This Internet-Draft will expire on September 5, 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 20 skipping to change at page 2, line 20
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 deterministicly 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5
3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 8 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7
3.3 Complete Prefix List generation . . . . . . . . . . . . . 8 3.3 Complete Prefix List generation . . . . . . . . . . . . . 8
3.4 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 10 3.3.1 Erroneous Prefix Lists . . . . . . . . . . . . . . . . 9
3.5 Tentative Source Link-Layer Address option (TO) . . . . . 11 3.4 Tentative Source Link-Layer Address option (TO) . . . . . 10
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 11 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 12 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 11
4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 12 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 12
4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 13 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 13
4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 15 4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 15
5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 16 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 16 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 16
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 16 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 16
5.1.2 Router Configuration Variables . . . . . . . . . . . . 17 5.1.2 Router Configuration Variables . . . . . . . . . . . . 17
5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 18 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 18
5.1.4 Processing Router Advertisements . . . . . . . . . . . 19 5.1.4 Processing Router Advertisements . . . . . . . . . . . 19
5.1.5 Processing Router Solicitations . . . . . . . . . . . 19 5.1.5 Processing Router Solicitations . . . . . . . . . . . 19
5.1.6 Complete Router Advertisements . . . . . . . . . . . . 20 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 20
5.1.7 Inclusion of smallest prefixes . . . . . . . . . . . . 21 5.1.7 Inclusion of smallest prefixes . . . . . . . . . . . . 21
5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 22 5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 22
5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 23 5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 23
5.1.10 Removing a Prefix from an Interface . . . . . . . . 23 5.1.10 Removing a Prefix from an Interface . . . . . . . . 23
5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 23 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 24
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 24 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 24
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 24 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 24
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 25 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 25
5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 25 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 25
5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 26 5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 26
5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 26 5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 26
5.2.6 Processing Router Advertisements . . . . . . . . . . . 27 5.2.6 Processing Router Advertisements . . . . . . . . . . . 27
5.2.7 DNA and Address Configuration . . . . . . . . . . . . 33 5.2.7 DNA and Address Configuration . . . . . . . . . . . . 33
5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 36 5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 36
5.3.1 Sending solicitations containing Tentative Options . . 37 5.3.1 Sending solicitations containing Tentative Options . . 37
5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 37 5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . 40
6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 40 6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 40
6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 41 6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 41
6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 41 6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 41
6.4 Authorization and Detecting Network Attachment . . . . . . 42 6.4 Authorization and Detecting Network Attachment . . . . . . 42
6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 42 6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 42
6.6 Hint Management Security . . . . . . . . . . . . . . . . . 43 6.6 DNA Hint Management Security . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43
8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 43
9. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 44 9. Changes since -04 . . . . . . . . . . . . . . . . . . . . . 44
10. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 44 10. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 44
11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45 11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 45
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 46 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 46
14.1 Normative References . . . . . . . . . . . . . . . . . . 46
14.2 Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
15.1 Normative References . . . . . . . . . . . . . . . . . . 47
15.2 Informative References . . . . . . . . . . . . . . . . . 47
A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
B. Sending directed advertisements without the neighbour A. Sending directed advertisements without the neighbour
cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . 52 Intellectual Property and Copyright Statements . . . . . . . 51
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 new extensions use complete RA for link identification, routers. The proposed mechanism define the construct that identifies
and Hash-based Fast RA to achieve fast response to RS messages. a link, proposes an algorithm for the routers on the link to send a
Aspects of requested Landmark is included to allow for a decrease in quick RA response without randomly waiting for upto MAX_RA_DELAY_TIME
the packet sizes associated with Complete RA. This memo also defines seconds as specified in RFC2461 [3]. This memo also defines a
a new Tentative option (TO) which is designed to replace the existing mechanism to exchange Source Link-Layer Address without affecting the
Source Link-Layer Address Options available in IPv6 Neighbor neighbor caches when the host is performing Optimistic DAD.
Discovery when the host is performing Optimistic DAD.
The rest of the document refers to the proposed mechanisms by the The rest of the document refers to the proposed mechanisms by the
term "DNAv6". term "DNAv6".
2. Terms and Abbreviations 2. Terms and Abbreviations
The term "link" is used as defined in RFC 2460 [2]. NOTE: this is The term "link" is used as defined in RFC 2460 [2]. NOTE: this is
completely different from the term "link" as used by IEEE 802, etc. completely different from the term "link" as used by IEEE 802, etc.
Access network: A network where hosts are present. Especially, a Attachment: The process of establishing a layer-2 connection.
network used for the support of visiting wireless hosts. Attachment (and detachment) may cause a link-change.
Attachment: The process of entering a new cell. Attachment (and
detachment) may cause a link-change.
Cell: A system constituted by the propagation range of a wireless
base station and its serviced hosts. Dependent on topology, one
or many cells may be part of the same link.
Hint: An indication from other subsystems or protocol layers that DNA Hint: An indication from other subsystems or protocol layers that
link-change may have occurred. link-change may have occurred.
Link-Change: Link-Change occurs when a host moves from a point-of- Link-Change: Link-Change occurs when a host moves from a point-of-
attachment on a link, to another point-of-attachment where it is attachment on a link, to another point-of-attachment where it is
unable to reach devices belonging to the previous link, without unable to reach devices belonging to the previous link, without
being forwarded through a router. being forwarded through a router.
Point-of-Attachment: A link-layer base-station, VLAN or port through Point-of-Attachment: A link-layer base-station, VLAN or port through
which a device attempts to reach the network. Changes to a which a device attempts to reach the network. Changes to a
host's point-of-attachment may cause link-change. host's point-of-attachment may cause link-change.
Reachability Detection: Determination that a device (such as a Reachability Detection: Determination that a device (such as a
router) is currently reachable, over both a wireless medium, and router) is currently reachable. This is typically achieved using
any attached fixed network. This is typically achieved using
Neighbor Unreachability Detection procedure [3]. Neighbor Unreachability Detection procedure [3].
Wireless Medium: A physical layer which incorporates free space
electromagnetic or optical propagation. Such media are
susceptible to mobility and interference effects, potentially
resulting in high packet loss probabilities.
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 RA in the presence of either of their current link from a single RS-RA pair in the presence of
DNAv6 enabled routers or non-DNAv6 routers. either DNAv6 enabled routers or non-DNAv6 routers.
DNAv6 assumes that the host's wireless link interface software and DNAv6 assumes that the host's link interface software and hardware is
hardware is capable of delivering a 'link up' event notification when capable of delivering a 'link up' event notification when layer 2 on
layer 2 on the host is configured and sufficiently stable for IP the host is configured and sufficiently stable for IP traffic. This
traffic. This event notification acts as a hint to the layer 3 DNA event notification acts as a DNA Hint to the layer 3 DNA procedures
procedures to check whether or not the host is attached to the same to check whether or not the host is attached to the same link as
link as before. DNAv6 also assumes that an interface on the host is before. DNAv6 also assumes that an interface on the host is never
never connected to two links at the same time. In the case that the connected to two links at the same time. In the case that the layer
layer 2 technology is capable of having multiple attachments (for 2 technology is capable of having multiple attachments (for instance,
instance, multiple layer 2 associations or connections) at the same multiple layer 2 associations or connections) at the same time, DNAv6
time, DNAv6 requires the individual layer-2 associations to be requires the individual layer-2 associations to be represented as
represented as separate (virtual interfaces) to layer 3 and DNAv6 in separate (virtual interfaces) to layer 3 and DNAv6 in particular.
particular.
3.1 Link Identification 3.1 Link Identification
DNAv6 identifies a link by the set of prefixes that are assigned to DNAv6 uses the set of prefixes that are assigned to the link to
the link, which is quite natural and doesn't require introducing any uniquely identify the link, which is quite natural and doesn't
new form of identifier. However, this choice implies that the require introducing any new form of identifier. However, this choice
protocol needs to be robust against changes in the set of prefixes implies that the protocol needs to be robust against changes in the
assigned to a link, including the case when a link is renumbered and set of prefixes assigned to a link, including the case when a link is
the prefix is later reassigned to a different link. The protocol renumbered and the prefix is later reassigned to a different link.
handles this during graceful renumbering (when the valid lifetime of The protocol handles this during graceful renumbering (when the valid
the prefix is allowed to decrease to zero before it is removed and lifetime of the prefix is allowed to decrease to zero before it is
perhaps reassigned to a different link), it describes how to remove removed and perhaps reassigned to a different link), it describes how
and reassign prefixes earlier than this without any incorrect to remove and reassign prefixes earlier than this without any
behaviour, and will also recover in case where a prefix is reassigned incorrect behaviour, and will also recover in case where a prefix is
without following the draft recommendations. reassigned without following the draft recommendations.
DNAv6 is based on using a Router Solicitation/Router Advertisement DNAv6 is based on using a Router Solicitation/Router Advertisement
exchange to both verify whether the host has changed link, and if it exchange to both verify whether the host has changed link, and if it
has, provide the host with the configuration information for the new has, provide the host with the configuration information for the new
link. The base method for detecting link change involves getting link. The base method for detecting link change involves getting
routers to listen to all of the prefixes that are being advertised by routers to listen to all of the prefixes that are being advertised by
other routers on the link. They can then respond to solicitations other routers on the link. They can then respond to solicitations
with complete prefix information. This information consists of the with complete prefix information. This information consists of the
prefixes a router would advertise itself as per RFC 2461, and also, prefixes a router would advertise itself as per RFC 2461, and also,
the prefixes learned from other routers on the link that are not the prefixes learned from other routers on the link that are not
being advertised by itself. These learned prefixes are included in a being advertised by itself. These learned prefixes are included in a
new Learned Prefix Option in the Router Advertisement. new Learned Prefix Option in the Router Advertisement.
A host receiving one of these "Complete RAs" - so marked by a flag - A host receiving one of these "Complete RAs" - so marked by a flag -
then knows all of the prefixes in use on a link, and by inference all then knows all of the prefixes in use on a link, and by inference all
those that are not. By comparing this with previously received those that are not. By comparing this with previously received
prefixes the host can correctly decide whether it is connected to the prefixes the host can correctly decide whether it is connected to the
same link as previously, or whether this Router Advertisement is from same link as previously, or whether this Router Advertisement is from
a new link. a router on a new link.
If the link contains all non-DNAv6 routers, then the host relies on If the link contains all non-DNAv6 routers, then the host relies on
the completeness (which the host always keeps track) of its own the completeness (which the host always keeps track) of its own
prefix list to make a decision; i.e. if its own prefix list is known prefix list to make a decision; i.e. if its own prefix list is known
to be 'complete', the host can make a decision by comparing the to be 'complete', the host can make a decision by comparing the
received prefixes with its prefix list, if its own prefix is not yet received prefixes with its prefix list, if its own prefix is not yet
'complete', the host will wait for the completeness criteria to be 'complete', the host will wait for the completeness criteria to be
met before making the comparison. met before making the comparison.
Though frequently all routers on a link will advertise the same set Though frequently all routers on a link will advertise the same set
of prefixes and thus experience no cost in making the RAs complete, of prefixes and thus experience no cost in making the RAs complete,
there is potential for the RAs to be large when there are many there is potential for the RAs to be large when there are many
prefixes advertised. Two mechanisms are defined that allow certain prefixes advertised. Two mechanisms are defined that allow certain
RAs to be reduced in size. RAs to be reduced in size. Both these mechanisms use one prefix as a
representative for the set of prefixes on a particular link.
One uses a technique called a "landmark", where the host chooses one One uses a technique called a "landmark", where the host chooses one
of the prefixes as a landmark prefix, and then includes this in the of the prefixes as a landmark prefix, and then includes this in the
Router Solicitation message in the form of a question "Am I on the Router Solicitation message in the form of a question "Am I on the
link which has this prefix?". The landmark is carried in a new link which has this prefix?". The landmark is carried in a new
option, called the Landmark Option. option, called the Landmark Option.
In the case when the host is still attached to the same link, which In the case when the host is still attached to the same link, which
might occur when the host has changed from using one layer 2 access might occur when the host has changed from using one layer 2 access
point to another, but the access points are on the same link, the point to another, but the access points are on the same link, the
skipping to change at page 7, line 11 skipping to change at page 6, line 45
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 the smallest prefix on the link
to be the "link identifier", and making sure that it is included in to be the representative for the entire set of prefixes on the link,
every advertisement, it is possible to omit some prefixes. Such and making sure that it is included in every advertisement, it is
advertisements will not inform a host of all of the prefixes at once, possible to omit some prefixes. Such advertisements will not inform
but in general these unsolicited advertisements will not be the first a host of all of the prefixes at once, but in general these
advertisement received on a link. Inclusion of the smallest prefix unsolicited advertisements will not be the first advertisement
simply ensures that there is overlap in the information advertised by received on a link. Inclusion of the smallest prefix simply ensures
each router on a link and that hosts will thus not incorrectly that there is overlap in the information advertised by each router on
interpret one of these incomplete RAs as an indication of movement. a link and that hosts will thus not incorrectly interpret one of
Even though this document recommends the use of a prefix as the "link these incomplete RAs as an indication of movement. Even though this
identifier", future specifications can use the Learned Prefix Option document recommends the use of a prefix as the representative of the
to include a non-prefix link identifier as long as this identifier is link, future specifications can use the Learned Prefix Option to
128 bit long to avoid overlap with any currently assigned prefix. include a non-prefix link identifier as long as this identifier is
Any future non-prefix link identifier MUST be 128 bits long. 128 bit long to avoid collision with any currently assigned prefix.
So, any 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.
skipping to change at page 7, line 46 skipping to change at page 7, line 33
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 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 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 advertised on the link. The hosts also have to maintain a notion of
'completeness' associated with its prefix list. This document 'completeness' associated with its prefix list.
recommends that NumRSRAComplete RS/RA exchanges SHOULD be done for
the prefix list to be considered 'complete'.
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 500 milliseconds, 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.
skipping to change at page 8, line 39 skipping to change at page 8, line 21
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.
If a host has the complete list of all the assigned prefixes, it can
properly determine whether a link change has occurred. If the host
receives an RA containing one or more prefixes and none of the
prefixes in it matches the previously known prefixes for the link,
then it is assumed to be a new link.
This works because each and every valid global prefix on a link must
not be used on any other link thus the sets of global prefixes on
different links must be disjoint [18].
3.3 Complete Prefix List generation 3.3 Complete Prefix List generation
To efficiently check for link change, a host always maintains the To efficiently check for link change, a host always maintains the
list of all known prefixes on the link. This procedure of attaining list of all known prefixes on the link. This procedure of attaining
and retaining the Complete Prefix List is initialized when the host and retaining the Complete Prefix List is initialized when the host
is powered on. is powered on.
The host forms the prefix list at any PoA (Point of Attachment), that The host forms the prefix list at any PoA (Point of Attachment), that
is, this process starts independently of any movement. Though the is, this process starts independently of any movement. Though the
procedure may take some time, that doesn't matter unless the host procedure may take some time, that doesn't matter unless the host
skipping to change at page 9, line 40 skipping to change at page 9, line 12
In case of packet loss, things get more complicated. In the above 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 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 an Incomplete Prefix List, i.e. the prefix list that misses some
prefix on the link. To remedy this deficiency, the host may perform prefix on the link. To remedy this deficiency, the host may perform
multiple RS/ RA exchanges to collect all the assigned prefixes. multiple RS/ RA exchanges to collect all the assigned prefixes.
After one RS/ RA exchange, to corroborate the completeness of the After one RS/ RA exchange, to corroborate the completeness of the
prefix list, the host may send additional RSs and wait for 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 resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS
[3]. The host takes the union of the prefixes from all the RAs to by RFC2461 [3]. The host takes the union of the prefixes from all
generate the prefix list. The more RS/ RA exchange the host the RAs to generate the prefix list. The more RS/ RA exchange the
performs, the more probable that the resulting prefix list is host performs, the more probable that the resulting prefix list is
complete. complete.
To ascertain whether its existing prefix list is complete or not, the To ascertain whether its existing prefix list is complete or not, the
host can set its own policy. The host may take into consideration 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 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 exchanges it performed or should have performed while it was attached
to the link. to the link.
In general, the higher the error rate, the longer time and more RA In general, the higher the error rate, the longer time and more RA
transmissions from the routers are needed to assure the completeness transmissions from the routers are needed to assure the completeness
of the prefix list. of the prefix list.
3.4 Erroneous Prefix Lists 3.3.1 Erroneous Prefix Lists
The host may generate either 1) an Incomplete Prefix List, i.e. the 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 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 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. 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 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 generate the prefix list that excludes some prefix on the link but
includes the prefix not assigned to the link. Its important to note includes the prefix not assigned to the link. Its important to note
that these erroneous prefix list possibility is significantly reduced that these erroneous prefix list possibility is significantly reduced
skipping to change at page 10, line 33 skipping to change at page 10, line 5
before finishing the procedure of the Complete Prefix List before finishing the procedure of the Complete Prefix List
generation. Later we will deal with the case that the host can't be generation. Later we will deal with the case that the host can't be
sure of the completeness of the prefix list. sure of the completeness of the prefix list.
Even if the host falsely assumes that an Incomplete Prefix List is Even if the host falsely assumes that an Incomplete Prefix List is
complete, the effect of that assumption is that the host might later 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. 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 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, it will detect a link change. Hence an
Incomplete Prefix List doesn't cause a connection disruption. But it Incomplete Prefix List doesn't cause a connection disruption. But
may cause extra signaling messages, for example Binding Update when a link change hasn't occured, an erroneous prefix list may cause
messages in [6] 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. The Superfluous Prefix List presents a more serious problem.
Without the assumed 'link UP' event notification from the link-layer, Without the assumed 'link UP' event notification from the link-layer,
the host can't perceive that it has changed its attachment point, 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 i.e. it has torn down an old link-layer connection and established a
new one. new one.
With the assumed 'link UP' notification, and the assumption of With the assumed 'link UP' notification, and the assumption of
different concurrent layer 2 connections being represented as different concurrent layer 2 connections being represented as
different (virtual) interfaces to the DNA module the host will never different (virtual) interfaces to the DNA module the host will never
treat RAs from different links as being part of the same link. Hence treat RAs from different links as being part of the same link. Hence
it will not create a Superfluous Prefix List. it will not create a Superfluous Prefix List.
3.5 Tentative Source Link-Layer Address option (TO) 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 usage of Source Link-Layer Address
options (SLLAOs) in Router and Neighbour Solicitation messages from a options (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 sub-optimal 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 The Tentative Option (TO) functions in the same role as the Source
Link-Layer Address option defined for [3], but it MUST NOT override Link-Layer Address option defined for [3], but it MUST NOT override
an existing neighbour cache entry. 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.
For these messages, no Neighbour Cache entry may be created, although
response messages may be directed to a particular unicast address.
4. Message Formats 4. Message Formats
This memo defines two new flags for inclusion in the router This memo defines two new flags for inclusion in the router
advertisement message and three new options. advertisement message and three new options.
4.1 Router Advertisement 4.1 Router Advertisement
DNAv6 modifies the format of the Router Advertisement message by DNAv6 modifies the format of the Router Advertisement message by
defining a bit to indicate that the router sending the message is defining a bit to indicate that the router sending the message is
participating in the DNAv6 protocol as well as a flag to indicate the participating in the DNAv6 protocol as well as a flag to indicate the
completeness of the set of prefixes included in the Router completeness of the set of prefixes included in the Router
Advertisement. The new message format is as follows: Advertisement. The new message format is as follows:
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 | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|Pr |F|C|R| Router Lifetime | | Cur Hop Limit |M|O|H|Pr |D|C|R| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time | | Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer | | Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Options ... + Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
FastRA (F) DNAAware (D)
The FastRA (F) bit indicates that the router sending the RA is The DNAAware (D) bit indicates that the router sending the RA is
participating in the DNAv6 protocol. Other routers should include participating in the DNAv6 protocol. Other routers should include
this router in calculating response delay tokens. this router in calculating response delay tokens.
Complete (C) Complete (C)
The Complete (C) bit indicates that the Router Advertisement The Complete (C) bit indicates that the Router Advertisement
contains PIOs for all prefixes explicitly configured on the contains PIOs for all prefixes explicitly configured on the
sending router, and, if other routers on the link are advertising sending router, and, if other routers on the link are advertising
additional prefixes, a Learned Prefix Option containing all additional prefixes, a Learned Prefix Option containing all
additional prefixes that the router has heard from other routers additional prefixes that the router has heard from other routers
skipping to change at page 15, line 27 skipping to change at page 15, line 24
Prefix Prefix
One or more fields (N) each containing a 128-bit address One or more fields (N) each containing a 128-bit address
representing a prefix that has been heard on the link but is not representing a prefix that has been heard on the link but is not
explicitly configured on this router. explicitly configured on this router.
Description Description
This option MUST only be included in a Router Advertisement. This This option MUST only be included in a Router Advertisement. This
option contains prefixes that are beingF advertised on the link option contains prefixes that are being advertised on the link but
but are not explicitly configured on the sending router. The are not explicitly configured on the sending router. The router
router MUST NOT include any prefixes with a zero valid lifetime in MUST NOT include any prefixes with a zero valid lifetime in the
the LPO. LPO.
4.4 Tentative option 4.4 Tentative option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 5 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 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ... | Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
skipping to change at page 16, line 32 skipping to change at page 16, line 32
5.1.1 Data Structures 5.1.1 Data Structures
The routers maintain a set of conceptual data structures for each The routers maintain a set of conceptual data structures for each
interface to track the prefixes advertised by other routers on the interface to track the prefixes advertised by other routers on the
link, and also the set of DNA routers (the routers that will quickly link, and also the set of DNA routers (the routers that will quickly
respond to RSs) on the link. respond to RSs) on the link.
For each interface, routers maintain a list of all prefixes learned For each interface, routers maintain a list of all prefixes learned
from other routers on the link but not explicitly configured on the from other routers on the link but not explicitly configured on the
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 "DNARouterPrefixList". Prefixes are learned by their document as "DNARouterLearnedPrefixList". Prefixes are learned by
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 DNARouterPrefixList. For each prefix MUST NOT update the contents of DNARouterLearnedPrefixList. For each
the router MUST store sufficient information to identify the prefix prefix the router MUST store sufficient information to identify the
and to know when to remove the prefix entry from the list. This may prefix and to know when to remove the prefix entry from the list.
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 DNARouterPrefixList is 3 times maximum The expiry time for entries in DNARouterLearnedPrefixList is 3 times
of MaxRtrAdvInterval after the last received Router Advertisement maximum of MaxRtrAdvInterval after the last received Router
affecting the entry, or the scheduled expiry of the prefix valid Advertisement affecting the entry, or the scheduled expiry of the
lifetime, whichever is earlier. prefix valid 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 FastRA 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
skipping to change at page 18, line 27 skipping to change at page 18, line 27
FastRAThreshold FastRAThreshold
The maximum number of fast responses that a host should receive The maximum number of fast responses that a host should receive
when soliciting for Router Advertisements. when soliciting for Router Advertisements.
Default: 3 Default: 3
5.1.3 Bootstrapping DNA Data Structures 5.1.3 Bootstrapping DNA Data Structures
When an interface on a router first starts up, it SHOULD transmit up As per RFC 2461 [3], when an interface on a host first starts up, it
to MAX_RTR_SOLICITATIONS Router Solicitations separated by SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations
RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of
routers and prefixes active on the link. the routers and prefixes active on the link. DNAv6 requires the
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 with a few restrictions on the message content.
Router Advertisements MUST NOT include any DNA specific options Router Advertisements MUST NOT include any DNA specific options
except that the FastRA flag MUST be set. The FastRA flag is set so except that the DNAAware flag MUST be set. The DNAAware flag is set
that other routers will know to include this router in their timing so that other routers will know to include this router in their
calculations for fast RA transmission. Other DNA options are omitted timing calculations for fast RA transmission. Other DNA options are
because the router may have incomplete information during bootstrap. omitted because the router may have incomplete information during
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.4 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 FastRA flag is set in the RA, the router checks if there is an If the DNAAware flag is set in the RA, the router checks if there is
entry in its DNARouterList. Thus it looks up the source address of an entry in its DNARouterList. Thus it looks up the source address
the RA in that list and, if not found, a new entry is added to of the RA in that list and, 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 FastRA 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 DNARouterPrefixList examined. If the prefix is not in the router's
and not in the router's AdvPrefixList [3], it is added to the DNARouterLearnedPrefixList and not in the router's AdvPrefixList [3],
DNARouterPrefixList, and its expiry time is set. it is added to the DNARouterLearnedPrefixList, and its expiry time is
set.
5.1.5 Processing Router Solicitations 5.1.5 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. UnicastRAInterval. A maximum of MaxUnicastRABurst 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 included in
DNARouterPrefixList or AdvPrefixList, the router SHOULD send an DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send
abbreviated Router Advertisement. an abbreviated Router Advertisement.This abbreviated advertisement
includes the Landmark prefix in a PIO if the prefix is in the
This abbreviated advertisement includes only the Landmark Option, AdvPrefixList or in a LPO if the prefix is found in the
plus the base RA header and any SEND options as appropriate. The DNAROuterLearnedPrefixList, plus the base RA header and any SEND
FastRA flag MUST be set. The Complete flag MUST NOT be set. This is options as appropriate. The DNAAware flag MUST be set. The Complete
the one exception where the smallest prefix MAY be omitted as the flag MUST NOT be set. This is the one exception where the smallest
landmark option implies that link change has not occured and that the prefix MAY be omitted as the landmark option implies that link change
previously received smallest prefix is still current. 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 included in
DNARouterPrefixList or AdvPrefixList or a unicast response is not DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is
possible, then the router SHOULD generate a Complete RA as specified not possible, then the router SHOULD generate a Complete RA as
in Section 5.1.6. The Router Advertisement MUST include the smallest specified in Section 5.1.6. The Router Advertisement MUST include
prefix(es), as described in Section 5.1.7. the smallest prefix(es), as described in Section 5.1.7.
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.8.
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 MulticastRADelay 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 MulticastRADelay.
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 MulticastRADelay, then
the Router Solicitation MUST be silently discarded. the Router Solicitation MUST be silently discarded.
All Router Advertisements sent by a DNA router MUST have the "F" 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 count on the
content being interpretable according to this specification. content being interpretable according to this specification.
5.1.6 Complete Router Advertisements 5.1.6 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 FastRA 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.
5.1.7 Inclusion of smallest prefixes 5.1.7 Inclusion of smallest prefixes
The numerically smallest prefix stored in either of The numerically smallest prefix stored in either of
DNARouterPrefixList or AdvPrefixList whose lifetime is greater than 3 DNARouterLearnedPrefixList or AdvPrefixList whose lifetime is greater
times maximum of MaxRtrAdvInterval is selected as the conceptual than 3 times maximum of MaxRtrAdvInterval is selected as the
"link identifier". For comparing prefixes, they are padded to the representative of the set of prefixes advertised on the link. For
right with zeros to make them 128 bit unsigned integers. comparing prefixes, they are padded to the right with zeros to make
them 128 bit unsigned integers.
The prefix may be included in the RA in either a PIO or LPO as This smallest prefix may be included in the RA in either a PIO or LPO
appropriate. Even when stateful address configuration (DHCPv6) is as appropriate. Even when stateful address configuration (DHCPv6) is
used, the routers MUST be configured with one prefix, so that the used, the routers MUST be configured with one prefix, so that the
smallest prefix can be included in the RA messages. Note that this smallest prefix can be included in the RA messages. Note that this
smallest prefix is the smallest of all the prefixes configured on the 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 routers on the link and may not be the smallest prefix used in the
link through stateful address configuration. link through stateful address configuration.
5.1.7.1 Changing the smallest prefix 5.1.7.1 Changing the smallest prefix
When either a new prefix is added to a link that is numerically When either a new prefix is added to a link that is numerically
smaller than all those previously advertised or the lifetime of the smaller than all those previously advertised or the lifetime of the
prefix that is currently being used as the "link identifier" falls current smallest prefix falls below 3 times maximum of
below 3 times maximum of MaxRtrAdvInterval, a new "link identifier" MaxRtrAdvInterval, a new smallest prefix SHOULD be determined. In
is determined. In order to ensure that there is overlap between order to ensure that there is overlap between consecutive RAs on the
consecutive RAs on the link, the old smallest prefix must continue to link, the old smallest prefix must continue to be advertised for some
be advertised for some time alongside the new smallest prefix. time alongside the new smallest prefix.
For the purposes of propagating information, it is assumed that after For the purposes of propagating information, it is assumed that after
three advertisements of a change, all routers have been made aware of three advertisements of a change, all routers have been made aware of
the change. the change.
If the instant that a router sends its first unsolicited If the instant that a router sends its first unsolicited
advertisement is time T, then by T + 1 hour at least three such advertisement is time T, then by T + 1 hour at least three such
advertisements will have been made and all routers can be assumed to advertisements will have been made and all routers can be assumed to
have received it. Thus by time T + 3 times maximum of have received it. Thus by time T + 3 times maximum of
MaxRtrAdvInterval, all routers on the link should have also sent at MaxRtrAdvInterval, all routers on the link should have also sent at
least one advertisement with the new smallest prefix list. least one advertisement with the new smallest prefix list.
3 times maximum of MaxRtrAdvInterval after first sending an 3 times maximum of MaxRtrAdvInterval after first sending an
advertisement with a new smallest prefix it is safe to consider the advertisement with a new smallest prefix it is safe to consider the
old smallest prefix gone and omit the corresponding prefix from RAs old smallest prefix gone and omit the corresponding prefix from RAs
if desired. if desired.
Following a change of smallest prefix, the old smallest prefix MUST Following a change of smallest prefix, the old smallest prefix MUST
be included in RAs for the following 3 times maximum of be included in RAs for the following 3 times maximum of
MaxRtrAdvInterval. MaxRtrAdvInterval. If the smallest prefix changes multiple times
with the 3 times maximum of MaxRtrAdvInterval time window, the RA
SHOULD include all of the smallest prefixes that were advertised
during that time window.
5.1.7.1.1 Non-Prefix link identifiers 5.1.7.1.1 Non-Prefix link identifiers
Although this memo only discusses the use of prefixes as "link Although this memo only discusses the use of prefixes as "link
identifier", a future specification or ammendment may describe a identifier", a future specification or ammendment may describe a
mechanism to select a "link identifier" that is not a prefix. mechanism to select a "link identifier" that is not a prefix.
Information from the Learned Prefix Option is only stored in Information from the Learned Prefix Option is only stored in
DNAHostPrefixList, and is only used for DNA purposes. Because a DNAHostPrefixList, and is only used for DNA purposes. Because a
length field is used, it is possible to carry any variable length length field is used, it is possible to carry any variable length
identifier less than or equal to 128 bits in an LPO and store it in identifier less than or equal to 128 bits in an LPO and store it in
DNAHostPrefixList (Section 5.2.1). To avoid any collision to DNAHostPrefixList (Section 5.2.1). To avoid any collision to
prefixes, an future non-prefix link identifier MUST be 128 bits long prefixes, an future non-prefix link identifier MUST be 128 bits long
and can be included in the LPO of a RA message. and can be included in the LPO of a RA message.
Following a change of link identifier, the old link identifier MUST Following a change of link identifier, the old link identifier MUST
be included in RAs in an LPO for the following 3 times maximum of be included in RAs in an LPO for the following 3 times maximum of
MaxRtrAdvInterval. MaxRtrAdvInterval.
Future specifications MUST NOT treat the information in an LPO as Future specifications are advised NOT to treat the information in an
prefixes such as they would the prefixes found in a Prefix LPO as prefixes such as they would the prefixes found in a Prefix
Information Option. Future specifications MUST NOT assume that the Information Option. Future specifications are also advised NOT to
entries in a host's DNAHostPrefixList are actual prefixes in use on assume that the entries in a host's DNAHostPrefixList are actual
the link. prefixes in use on the link.
5.1.8 Scheduling Fast Router Advertisements 5.1.8 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 RASeparation.
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
skipping to change at page 23, line 14 skipping to change at page 23, line 22
sent immediately. sent immediately.
If Rank >= FastRAThreshold, then the RA MUST be replaced with a If Rank >= FastRAThreshold, then the RA MUST be replaced with a
Complete RA, if it is not one already, and scheduled for multicast Complete RA, if it 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.9 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 "F" 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 smallest prefix.
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.10 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 should treat it as though it has just learned a prefix that is
not explicitly configured on it. After sending the last RA not explicitly configured on it. After sending the last RA
containing the prefix in a PIO, the router MUST add the prefix to the containing the prefix in a PIO, the router MUST add the prefix to the
DNARouterPrefixList and set it to expire in 3 times maximum of DNARouterLearnedPrefixList and set it to expire in 3 times maximum of
MaxRtrAdvInterval or at the expiry of the last advertised valid MaxRtrAdvInterval or at the expiry of the last advertised valid
lifetime, whichever is earlier. This ensures that to hosts there lifetime, whichever is earlier. This ensures that to hosts there
will be overlap in the prefixes in the RAs they see and prevent them will be overlap in the prefixes in the RAs they see and prevent them
from incorrectly interpreting changed prefixes as movement. from incorrectly interpreting changed prefixes as movement.
5.1.10.1 Early Removal of the smallest Prefix 5.1.10.1 Early Removal of the smallest Prefix
If the smallest prefix is to be withdrawn early from a link, that is If the smallest prefix is to be withdrawn early from a link, that is
before the expiry of its previously advertised valid lifetime, it before the expiry of its previously advertised valid lifetime, it
MUST be advertised for at least 3 times maximum of MaxRtrAdvInterval MUST be advertised for at least 3 times maximum of MaxRtrAdvInterval
skipping to change at page 25, line 18 skipping to change at page 25, line 24
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 3
times maximum of MaxRtrAdvInterval after they are last seen in a times maximum of MaxRtrAdvInterval after they are last seen in a
received Router Advertisement (in either a PIO or LPO) or at the received Router Advertisement (in either a PIO or LPO) or at the
expiry of the valid lifetime of the prefix, whichever is earlier. expiry of the valid lifetime of the prefix, whichever is earlier.
Host MUST also maintain a boolean flag, DNARAReceivedFlag, indicating Host MUST also maintain a boolean flag, DNARAReceivedFlag, indicating
whether or not the host received a DNA RA message (RA message with whether or not the host received a DNA RA message (RA message with
the "F" flag set) on this link. This value is initialized to zero 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 everytime a link change happens and is set to 1 when the first DNA RA
message is received. 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:
skipping to change at page 25, line 40 skipping to change at page 25, line 46
DNASameLinkDADFlag DNASameLinkDADFlag
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
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. 1. Mark all the IPv6 addresses in use as optimistic. Set
DNARAReceivedFlag to zero.
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 that router's Neighbor Cache Entry [3] as REACHABLE, or add
a Neighbor Cache Entry in the REACHABLE state if one does not a Neighbor Cache Entry in the REACHABLE state if one does not
skipping to change at page 26, line 46 skipping to change at page 27, line 6
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 hints. technology subject to the reliability of the DNA Hints.
When the host receives a link UP notification from its link layer, it When the host receives a link UP notification from its link layer, it
sets time_last_linkUP_received to the current time. sets time_last_linkUP_received to the current time.
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
Thus if it handled the most recent link UP notification less than as specified by RFC 2461 [3].
MinRAWait seconds ago, it can not immediately send one when it
processes a link UP notification.
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
at least one valid prefix, then the host can retransmit the RS. It at least one valid prefix, then the host can retransmit the RS. It
is allowed to multicast up to MAX_RTR_SOLICITATIONS [3] RS messages is allowed to multicast up to MAX_RTR_SOLICITATIONS RS messages
spaced RTR_SOLICITATION_INTERVAL apart. spaced RTR_SOLICITATION_INTERVAL apart as per RFC 2461 [3].
Note that if link-layer notifications are reliable, a host can reset Note that if link-layer notifications are reliable, a host can reset
the number of sent Router Solicitations to 0, while still maintaining the number of sent Router Solicitations to 0, while still maintaining
RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is
necessary so that after each link up notification, the host is necessary so that after each link up notification, the host is
allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, allowed to send MAX_RTR_SOLICITATIONS to reliably discover the,
possibly new, prefix list. possibly new, prefix list.
Hosts SHOULD include a Landmark Option (LO) in the RS message with Hosts SHOULD include a Landmark Option (LO) in the RS message with
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.
skipping to change at page 27, line 47 skipping to change at page 28, line 5
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, the host has performed optimistic
duplicate address detection for the address. 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 contains a Landmark Option that matches the Landmark
Option in the last transmitted Router Solicitation then that
indicates that no link change has occurred and current
configuration can be assumed to still be current.
If the RA includes a prefix that matches an entry in If the RA includes a prefix that matches an entry in
DNAHostPrefixList, then the host can conclude that no link change DNAHostPrefixList, then the host can conclude that no link change
has occurred and the current configuration can be assumed to still has occurred and the current configuration can be assumed to still
be current. 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 LPO that are also in the host's DNAHostPrefixList, then
the host can conclude that it has changed link and SHOULD initiate the host can conclude that it has changed link and SHOULD 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 "F" flag set in the RA 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 header, previously a DNA RA was received on this link as indicated
by the DNARAReceivedFlag being set to 1, and there are no prefixes 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 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 DNAHostPrefixList, then the host can conclude that it has changed
link and SHOULD initiate re-configuration using the information in link and SHOULD initiate re-configuration using the information in
the received Router Advertisement. 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 LPO that matches a prefix
in CPL then the host can conclude that link change has occurred in CPL then the host can conclude that link change has occurred
skipping to change at page 28, line 42 skipping to change at page 28, line 42
in DNAHostPrefixList, does not contain a Landmark Option that in DNAHostPrefixList, does not contain a Landmark Option that
matches a corresponding option in the most recent RS, then the matches a corresponding option in the most recent RS, then the
host SHOULD send RS/RA exchange until num_RS_RA is equal to host SHOULD send RS/RA exchange until num_RS_RA is equal to
NumRSRAComplete to create a new CPL and compare it with the NumRSRAComplete to create a new CPL and compare it with the
already known prefixes. If after NumRSRAComplete exchanges still already known prefixes. If after NumRSRAComplete exchanges still
no prefix received in either a PIO or LPO of the RAs match known no prefix received in either a PIO or LPO of the RAs match known
prefixes, the host MUST conclude link change. If a matching prefixes, the host MUST conclude link change. If a matching
prefix is received in the RAs, then the host MUST conclude that no prefix is received in the RAs, then the host MUST conclude that no
link change has occured. link change has occured.
5.2.6.1 Pseudocode If the received RA has the "D" flag set, then set
DNARAReceivedFlag to one.
IF (Received RA contains Landmark that matches the Landmark option in
the last transmitted RS) THEN
{
No-link change has occured
RETURN; // Don't have to do the following checks.
} 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,
smallest prefix included in RA or CompleteRA message containg all
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.
} }
IF (Receive RA is a CompleteRA) THEN IF (Receive RA is a CompleteRA) THEN
{ {
skipping to change at page 30, line 27 skipping to change at page 30, line 22
} }
Wait for NumRSRAComplete exchanges of RS/RA message to be done since Wait for NumRSRAComplete exchanges of RS/RA message to be done since
the previous link_up event. the previous link_up event.
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 link UP event), THEN No link change has
occured ELSE link change has occured. 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 If a Router Advertisement does not indicate a link change, the host
updates its DNAHostPrefixList, adding any new prefixes if necessary. updates its DNAHostPrefixList, adding any new prefixes if necessary.
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 DNAHostPrefixList match the contents of the advertisement
and mark it as complete (i.e. it becomes CPL). Any new prefixes are and mark it as complete (i.e. it becomes CPL). Any new prefixes are
added and any prefixes in the list that are absent in the added and any prefixes in the list that are absent in the
advertisement are removed. Expiry times on prefixes are updated if advertisement are removed. Expiry times on prefixes are updated if
skipping to change at page 31, line 27 skipping to change at page 31, line 25
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 The host declares "one successful RS/RA exchange" is accomplished
after it sends an RS, waits for MinRAWait seconds and receives a after it sends an RS, waits for MinRAWait seconds and receives a
positive number of resulting RAs. At least one RA (with at least one positive 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 prefix) should be received. After the RS, if a link UP event occurs
before MinRAWait seconds expire, the host should not assume that a before MinRAWait 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. This determine when DNAHostPrefixList is considered to be complete. The
document considers it to be complete when NumRSRAComplete number of host SHOULD conclude that the prefix list is complete when
RS/RA exchanges have been completed or a RA message with the complete NumRSRAComplete number of RS/RA exchanges have been completed or a RA
bit set is received. The complete DNAHostPrefixList is also refered message with the complete bit set is received. The complete
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 NumRSRAComplete 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. Even though some
packet loss may cause an Incomplete Prefix List, there is a further packet loss may cause an Incomplete Prefix List, there is a further
chance for the host to get the missing prefixes before it receives 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 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 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 changed link, there is good chance that the first RA may contain a
prefix from its (incomplete) prefix list. Considering all those prefix from its (incomplete) prefix list. Considering all those
above, even if the host performs only one RS/ RA exchange, it will be above, even if the host performs only one RS/ RA exchange, it will be
skipping to change at page 37, line 42 skipping to change at page 37, line 42
if the soliciting host does, in which case reception of the Tentative if the soliciting host does, in which case reception of the Tentative
Option may create a neighbour cache entry, without the need for Option may create a neighbour cache entry, without the need for
neighbour discovering the original solicitor. 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 B. from the unspecified address is described in Appendix A.
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 B. neighbour cache entries. This is described in Appendix A.
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 38, line 40
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 B. Appendix A.
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 only [Editor's note: This only is not right?
TO is allowed in both NS and RS? right?] allowed in Neighbour TO is allowed in both NS and RS? right?] allowed in Neighbour
Solicitations with specified source addresses for which SLLAO is not Solicitations with specified source addresses for which SLLAO is not
required. 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.
skipping to change at page 43, line 8 skipping to change at page 43, line 8
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 can only be a denial-of-service attempt.
6.6 Hint Management Security 6.6 DNA Hint Management Security
Events originating at other protocol layers may provide hints of link Events originating at other protocol layers may provide DNA Hints of
change to network attachment detection systems. Two examples of such link change to network attachment detection systems. Two examples of
events are TCP retransmission timeout and completion of link-layer such events are TCP retransmission timeout and completion of link-
access procedures [20]. layer access procedures [20].
While hints from other protocol layers originate from within the While DNA Hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat hints from other host's own stack, the network layer SHOULD NOT treat DNA Hints from
protocol layers as authoritative indications of link change. other protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be This is because state changes within other protocol layers may be
triggered by untrusted messages, come from compromised sources (for triggered by untrusted messages, come from compromised sources (for
example 802.11 WEP Encryption [15]) or be inaccurate with regard to example 802.11 WEP Encryption [15]) or be inaccurate with regard to
network-layer state. network-layer state.
While these hints come from the host's own stack, such hints may 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 actually be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to originating layers. As such, it may be possible for other devices to
instigate hint delivery on a host or multiple hosts deliberately, in instigate DNA Hint delivery on a host or multiple hosts deliberately,
order to prompt packet transmission, or configuration modification. in order to prompt packet transmission, or configuration
modification.
Therefore, hosts SHOULD NOT change their configuration state based on Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers. A host MAY adopt an appropriate DNA Hints from other protocol layers. A host MAY adopt an
link change detection strategy based upon hints received from other appropriate link change detection strategy based upon DNA Hints
layers, with suitable caution and hysteresis. 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 two new Neighbor Discovery [3] options, which must
be assigned Option Type values within the option numbering space for be assigned Option Type values within the option numbering space for
Neighbor Discovery messages: 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.
skipping to change at page 44, line 18 skipping to change at page 44, line 18
Value: 2 Value: 2
MinRAWait MinRAWait
Minimum time the host will have to wait before assuming receipt of Minimum time the host will have to wait before assuming receipt of
all possible RAs. all possible RAs.
Default: 4 seconds Default: 4 seconds
9. Changes since -03 9. Changes since -04
o Edited the document to improve readability and clarity.
o Edited the document to make the distinction between what is
recommended by RFC 2461 and what is modified behavior for DNA.
(The flash renumbering sections were not touchted.)
10. 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.
skipping to change at page 44, line 47 skipping to change at page 45, line 9
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.7.
10. Changes since -02 11. 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 NumRSRAComplete, MinRAWait, MaxCacheTIme. Added
an open issue whether these should be variables or constants. an open issue whether these should be variables or constants.
o Fixed some typos. o Fixed some typos.
11. Open issues 12. Open issues
1. The protocol uses only the prefixes with lifetime greater than 1. Explain the idea of link identification better. The link is
1.5 hours. 1.5 hour is decided with the assumption that identified by the "set of prefixes" and a prefix (either landmark
MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to or smallest prefix) is used to identify the particular "set of
increase the value into hours or even days because it would be prefixes".
difficult to waken all idle nodes in every 30 mins in cellular
network.
2. There may be a link where no prefix is advertised. For example, 2. Do we need all of the router configuration variables?
an network administrator may not support stateless address
autoconfiguration for policy reason. Then it won't advertise any
prefix with A-bit set. Also it may want all traffic going
through an AR and not allow direct communication among hosts
because of accounting. Then it won't advertise any prefix with
L-bit set either. As of my knowledge the prefix without any bit
set won't be advertised, which would hurt DNA operation.
3. Third, I propose we do away with 'Landmark Option with Y bit'. 3. Bootstrapping DNA data structures: Would be good to be more clear
The router can notify no-link change by simply putting the about what is a change w.r.t. standard ND.
landmark prefix in either PIO or LPIO. Then we can remove the
check for landmark from Section 5.2.6.
4. Should variables NumRSRAComplete, MinRAWait, MaxCacheTime be kept 4. Future specificaitons MUST NOT: Can't make this sort of
as variables or should they be constants? 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.
12. Contributors 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
new behavior or whether just suggesting how things ought to be.
7. The section Section 5.1.7 needs to be written better.
13. 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.
13. Acknowledgments 14. 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 46, line 35 skipping to change at page 47, line 5
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.
14. References 15. References
14.1 Normative References 15.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.
14.2 Informative References 15.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 50, line 5 skipping to change at page 50, line 29
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. How the Goals are Met? Appendix A. Sending directed advertisements without the neighbour cache
The DNA goals document [19] contains a list of goals identified by G1
to G10. This section discusses how the proposed scheme addresses
each of these goals.
G1 The Complete RA contains the complete list of prefixes advertised
on the link allowing the host to determine whether link change has
occurred and to re-configure if necessary.
G2 Under normal circumstances the host will receive a RA response
within round-trip time and some processing time on the router. If
the first RA message is lost, if another router is on the link, a
second RA should arrive within a slot time and so on.
G3 Non movement scenarios will be correctly identified because the
landmark will be confirmed by the router(s) on the link or the
Complete RA will have prefixes that have already been seen,
indicating non-movement.
G4 A single RS/RA message exchange is initiated in response to a hint
that link change may have occurred.
G5 The existing RS/RA signalling is used along with unsolicited RA
messages. Some new options and flags are proposed.
G6 Only link scope signaling is used.
G7 SEND can be used to protect the RS and RA messages exchanged.
G8 If SEND is not deployed, then a rogue device could cause a host to
think its configuration is invalid by sending an RA that answers
the RS question incorrectly. A similar effect is already
possible, however, by a rogue device sending an RA with valid
prefixes with zero lifetimes.
G9 The CPL logic allows a graceful fallback position for dealing with
non-DNA routers and non DNA hosts will still receive the benefit
of receiving an RA response from its current router faster than
RFC 2461.
G10 This technique is carried out on an interface by interface basis.
A host with multiple interfaces can get information about changes
to configuration on each interface, but would need a higher level
process to decide how the information from the various interfaces
relates to each other.
Appendix B. Sending directed advertisements without the neighbour cache
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 Tentative Option. Also, RS packets sent without a specified in the Tentative Option. Also, RS packets sent without a
specificed source address may potentially contain a Tentative Option. specificed source address may potentially contain a Tentative Option.
In this case the unicast link-layer address from the solicitation MAY In this case the unicast link-layer address from the solicitation MAY
be extracted from the Tentative Option and used as the destination of be extracted from the Tentative Option and used as the destination of
the link-layer frame for a responding Router Advertisment. the link-layer frame for a responding Router Advertisment.
 End of changes. 96 change blocks. 
304 lines changed or deleted 255 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/