draft-pentland-dna-protocol3-00.txt   draft-ietf-dna-protocol-pre00.txt 
DNA Working Group B. Pentland, Ed. DNA Working Group J. Kempf
Internet-Draft Monash University CTIE Internet-Draft DoCoMo Communications Labs USA
Expires: April 20, 2006 October 17, 2005 Expires: July 28, 2006 S. Narayanan
Panasonic
E. Nordmark
Sun Microsystems
B. Pentland, Ed.
Monash University CTIE
JH. Choi
Samsung AIT
January 24, 2006
Detecting Network Attachment in IPv6 Networks (DNAv6) Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-pentland-dna-protocol3-00.txt draft-ietf-dna-protocol-pre00.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 41
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 April 20, 2006. This Internet-Draft will expire on July 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
Efficient detection of network attachment in IPv6 needs the following Efficient detection of network attachment in IPv6 needs the following
two components: a method for the host to query routers on the link to two components: a method for the host to query routers on the link to
identify the link (Link Identification) and a method for the routers identify the link (Link Identification) and a method for the routers
on the link to consistently respond to such a query with minimal on the link to consistently respond to such a query with minimal
delay (Fast RA). Solving the link identification based strictly on delay (Fast RA). Solving the link identification based strictly on
RFC 2461 is difficult because of the flexibilities offered to routers RFC 2461 is difficult because of the flexibility offered to routers
in terms of prefixes advertised in a router advertisement (RA) in terms of prefixes advertised in a router advertisement (RA)
message. Similarly, the random delay in responding to router message. Similarly, the random delay in responding to router
solicitation messages imposed by RFC 2461 makes to it difficult to solicitation messages imposed by RFC 2461 makes to it difficult to
achieve fast RA. In this memo, an integrated solution is presented. receive an RA quickly. In this memo, an integrated solution is
Monitoring of prefixes by both hosts and routers is used to achieve presented. Monitoring of prefixes by both hosts and routers is used
link identification while router advertisements are sent rapidly in a to achieve link identification while router advertisements are sent
deterministic order by combining router solicitation source addresses rapidly in a deterministic order by combining router solicitation
with hash-based router tokens. source addresses with hash-based router tokens.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 5
4.2 Link Identification . . . . . . . . . . . . . . . . . . . 5
4.3 Fast Router Advertisement . . . . . . . . . . . . . . . . 7
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8
5.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 9
5.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 10
6. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 12
6.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 12
6.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 12
6.1.2 Router Configuration Variables . . . . . . . . . . . . 13
6.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 14
6.1.4 Processing Router Advertisements . . . . . . . . . . . 15
6.1.5 Processing Router Solicitations . . . . . . . . . . . 15
6.1.6 Complete Router Advertisements . . . . . . . . . . . . 16
6.1.7 LinkID Prefix . . . . . . . . . . . . . . . . . . . . 17
6.1.8 Scheduling Fast Router Advertisements . . . . . . . . 17
6.1.9 Scheduling Unsolicited Router Advertisements . . . . . 18
6.1.10 Removing a Prefix from an Interface . . . . . . . . 18
6.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 19
6.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 19
6.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 19
6.2.2 Host Configuration Variables . . . . . . . . . . . . . 20
6.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 20
6.2.4 Sending Router Solicitations . . . . . . . . . . . . . 20
6.2.5 Processing Router Advertisements . . . . . . . . . . . 21
6.2.6 DNA and Address Configuration . . . . . . . . . . . . 22
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 25
7.1 Non DNA Host with DNA Routers . . . . . . . . . . . . . . 25
7.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . 26
8.1 Amplification Effect . . . . . . . . . . . . . . . . . . . 26
8.2 Attacks on the Token Bucket . . . . . . . . . . . . . . . 26
8.3 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1 Normative References . . . . . . . . . . . . . . . . . . 27
11.2 Informative References . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . 29
A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 29 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . 31 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5
3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7
1. Contributors 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8
4.2 Prefix Information Option LinkID Flag . . . . . . . . . . 9
4.3 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10
4.4 Learned Prefix Option . . . . . . . . . . . . . . . . . . 12
This document merges ideas from two earlier documents and as such is 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 13
the work of many. Most notably, but in no particular order are: 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 13
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 14
5.1.2 Router Configuration Variables . . . . . . . . . . . . 15
5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 16
5.1.4 Processing Router Advertisements . . . . . . . . . . . 16
5.1.5 Processing Router Solicitations . . . . . . . . . . . 17
5.1.6 Complete Router Advertisements . . . . . . . . . . . . 18
5.1.7 LinkID Prefix . . . . . . . . . . . . . . . . . . . . 18
5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 19
5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 20
5.1.10 Removing a Prefix from an Interface . . . . . . . . 20
5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 21
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22
5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 22
5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 23
5.2.5 Processing Router Advertisements . . . . . . . . . . . 23
5.2.6 DNA and Address Configuration . . . . . . . . . . . . 25
James Kempf - DoCoMo Communications Labs USA 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 28
6.1 Non-DNA Host with DNA Routers . . . . . . . . . . . . . . 28
6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 28
Sathya Narayanan - Panasonic 7. Security Considerations . . . . . . . . . . . . . . . . . . 28
7.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 28
7.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 29
Erik Nordmark - Sun Microsystems 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29
Brett Pentland - Monash University CTIE 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1 Normative References . . . . . . . . . . . . . . . . . . 30
10.2 Informative References . . . . . . . . . . . . . . . . . 30
JinHyeock Choi - Samsung AIT Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
Greg Daley - Monash University CTIE A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 32
Syam Madanapalli - Samsung ISO Intellectual Property and Copyright Statements . . . . . . . 34
2. Introduction 1. Introduction
The proposed scheme in this memo is built upon the following The proposed scheme in this memo is built upon the following
solutions catalogued in [15]: Complete RA is used for the link solutions catalogued in [16]: Complete RA is used for the link
identification, and Hash-based Fast RA is used to achieve fast identification, and Hash-based Fast RA is used to achieve fast
response to RS messages. Aspects of prefix-based LinkID and response to RS messages. Aspects of prefix-based LinkID and
Requested Landmark are optionally included to allow for a decrease in Requested Landmark are included to allow for a decrease in the packet
the packet sizes associated with Complete RA. sizes associated with Complete RA.
The rest of the document refers to this approach by the term "DNAv6". The rest of the document refers to this approach by the term "DNAv6".
3. Terms and Abbreviations 2. Terms and Abbreviations
There is an existing DNA terminology draft [12]. This draft does not There is an existing DNA terminology draft [13]. This draft does not
introduce any new terminology not already used by existing drafts. introduce any new terminology not already used by existing drafts.
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.
4. 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. of their current link from a single RA.
skipping to change at page 5, line 21 skipping to change at page 5, line 48
traffic. This event notification acts as a hint to the layer 3 DNA traffic. This event notification acts as a hint to the layer 3 DNA
procedures to check whether or not the host is attached to the same procedures to check whether or not the host is attached to the same
link as before. DNAv6 also assumes that an interface on the host is link as before. DNAv6 also assumes that an interface on the host is
never connected to two links at the same time. In the case that the never connected to two links at the same time. In the case that the
layer 2 technology is capable of having multiple attachments (for layer 2 technology is capable of having multiple attachments (for
instance, multiple layer 2 associations or connections) at the same instance, multiple layer 2 associations or connections) at the same
time, DNAv6 requires the individual layer-2 associations to be time, DNAv6 requires the individual layer-2 associations to be
represented as separate (virtual interfaces) to layer 3 and DNAv6 in represented as separate (virtual interfaces) to layer 3 and DNAv6 in
particular. particular.
4.1 What Identifies a Link? 3.1 Link Identification
DNAv6 identifies a link by the set of prefixes that are assigned to DNAv6 identifies a link by the set of prefixes that are assigned to
the link, which is quite natural and doesn't require introducing any the link, which is quite natural and doesn't require introducing any
new form of identifier. However, this choice implies that the new form of identifier. However, this choice implies that the
protocol needs to be robust against changes in the set of prefixes protocol needs to be robust against changes in the set of prefixes
assigned to a link, including the case when a link is renumbered and assigned to a link, including the case when a link is renumbered and
the prefix is later reassigned to a different link. The protocol the prefix is later reassigned to a different link. The protocol
handles this quite well during graceful renumbering (when the valid handles this during graceful renumbering (when the valid lifetime of
lifetime of the prefix is allowed to decrease to zero before it is the prefix is allowed to decrease to zero before it is removed and
removed and perhaps reassigned to a different link), however, it can perhaps reassigned to a different link), it describes how to remove
also cope with "flash" renumbering and reassignment but not in an and reassign prefixes earlier than this without any incorrect
optimized fashion. behaviour, and will also recover in case where a prefix is reassigned
without following the draft recommendations.
4.2 Link Identification
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. Unlike CPL [14], the host does not have to wait for a new link. Unlike CPL [15], the host does not have to wait for
multiple advertisements before making a decision. multiple advertisements before making a decision.
Frequently, all routers on a link will advertise the same set of Though frequently all routers on a link will advertise the same set
prefixes and so this technique will incur no space penalty. However, of prefixes and thus experience no cost in making the RAs complete,
on links where routers advertise different sets of prefixes, packets there is potential for the RAs to be large when there are many
may be larger. To combat this, two optional mechanisms are defined. prefixes advertised. Two mechanisms are defined that allow certain
RAs to be reduced in size.
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 still Router Solicitation message in the form of a question "am I still
connected to the link which has this prefix?". The landmark is connected to the link which has this prefix?". The landmark is
carried in a new option, called the Landmark Option. carried in a new 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 15 skipping to change at page 7, line 42
In order for the routers be able to both respond to the landmark In order for the routers be able to both respond to the landmark
questions and send the complete RAs, the routers need to track the questions and send the complete RAs, the routers need to track the
prefixes that other routers advertise on the link. This process is prefixes that other routers advertise on the link. This process is
initialized when a router is enabled, by sending a Router initialized when a router is enabled, by sending a Router
Solicitation and collecting the resulting RAs, and then multicasting Solicitation and collecting the resulting RAs, and then multicasting
a few RAs more rapidly as already suggested in RFC 2461. This a few RAs more rapidly as already suggested in RFC 2461. This
process ensures with high probability that all the routers have the process ensures with high probability that all the routers have the
same notion of the set of prefixes assigned to the link. same notion of the set of prefixes assigned to the link.
4.3 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.
DNAv6 avoids this delay by using a different mechanism to ensure that DNAv6 avoids this delay by using a different mechanism to ensure that
two routers will not respond at exactly the same time while allowing two routers will not respond at exactly the same time while allowing
one of the routers on the link to respond immediately. Since the one of the routers on the link to respond immediately. Since the
hosts might be likely to use the first responding router as the first hosts might be likely to use the first responding router as the first
choice from their default router list, the mechanism also ensures choice from their default router list, the mechanism also ensures
that the same router doesn't respond first to the RSs from different that the same router doesn't respond first to the RSs from different
hosts. hosts.
The mechanism is based on the routers on the link determining (from The mechanism is based on the routers on the link determining (from
the same RAs that are used in section Section 4.1 to determine all the same RAs that are used in section Section 3.1 to determine all
the prefixes assigned to the link), the link-local addresses of all the prefixes assigned to the link), the link-local addresses of all
the other routers on the link. With this loosely consistent list, the other routers on the link. With this loosely consistent list,
each router can independently compute some function of the (link- each router can independently compute some function of the (link-
local) source address of the RS and each of the routers' link-local local) source address of the RS and each of the routers' link-local
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.
5. 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 two new options. advertisement message and two new options.
5.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
adding a flag bit to indicate that the router sending the message is adding a flag 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 |D|C|R| Router Lifetime | | Cur Hop Limit |M|O|H|Pr |F|C|R| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time | | Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer | | Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Options ... + Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
DNA (D) FastRA (F)
The DNA (D) bit indicates that the router sending the RA is The FastRA (F) 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
on the link. on the link.
Reserved (R) Reserved (R)
The reserved field is reduced from 3 bits to 1 bit. The reserved field is reduced from 3 bits to 1 bit.
5.2 Landmark Option 4.2 Prefix Information Option LinkID Flag
DNAv6 modifies the format of the Prefix Information Option by adding
a flag bit to indicate that the enclosed prefix is currently being
used as the Link Identifier. The new message format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|I|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LinkID (I)
The LinkID (I) bit indicates that the prefix in the Prefix field
of this option is currently being used as the Link Identfier
(LinkID).
Reserved1
The Reserved1 field is reduced from 6 bits to 5 bits.
4.3 Landmark Option
The Landmark Option is used by hosts in a Router Solicitation message The Landmark Option is used by hosts in a Router Solicitation message
to ask the routers on a link if the specified prefix is being to ask the routers on a link if the specified prefix is being
advertised by some router on the link. It is used by routers in a advertised by some router on the link. It is used by routers in a
Router Advertisement to reply to a corresponding question in a Router Router Advertisement to reply to a corresponding question in a Router
Solicitation, indicating whether the prefix referred to is being Solicitation, indicating whether the prefix referred to is being
advertised by any router on the link. advertised by any router on the link.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 10, line 22 skipping to change at page 12, line 12
A 38 bit unused field. It MUST be initialised to zero by the A 38 bit unused field. It MUST be initialised to zero by the
sender, and ignored by the receiver. sender, and ignored by the receiver.
Prefix Prefix
A prefix being used by the host currently for a global IPv6 A prefix being used by the host currently for a global IPv6
address, padded at the right with zeros. If the prefix length is address, padded at the right with zeros. If the prefix length is
less than 65 bits, only 64 bits need be included, otherwise 128 less than 65 bits, only 64 bits need be included, otherwise 128
bits are included. bits are included.
5.3 Learned Prefix Option 4.4 Learned Prefix Option
The Learned Prefix Option (LPO) is used by a router to indicate The Learned Prefix Option (LPO) is used by a router to indicate
prefixes that are being advertised in PIOs by other routers on the prefixes that are being advertised in PIOs by other routers on the
link, but not by itself. link, but not by itself.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Len 1 | Prefix Len 2 | | Type | Length |I| Reserved | Prefix Len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Prefix Len N | Padding | | ... | Prefix Len N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Prefix 1 + + Prefix 1 +
| | | |
+ + + +
| | | |
skipping to change at page 11, line 38 skipping to change at page 13, line 4
~ ... ~ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Prefix N + + Prefix N +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBA TBA
Length Length
8 bit unsigned integer indicating the length of the option in 8 bit unsigned integer indicating the length of the option in
units of 8 octets. units of 8 octets.
I
LinkID (I) flag. When set indicates that the first prefix in this
option is the LinkID for this link.
Prefix Len Prefix Len
One or more fields (N) each consisting of an 8-bit unsigned One or more fields (N) each consisting of an 8-bit unsigned
integer representing the prefix lengths of the following prefixes. integer representing the prefix lengths of the following prefixes.
The Prefix Len fields are ordered the same as the Prefix fields so The Prefix Len fields are ordered the same as the Prefix fields so
that the first Prefix Len field represents the prefix length of that the first Prefix Len field represents the prefix length of
the prefix contained in the first prefix field, and so on. the prefix contained in the first prefix field, and so on.
Padding Padding
Zero padding sufficient to align the following prefix field on an Zero padding sufficient to align the following prefix field on an
8-octet boundary. 8-octet boundary.
skipping to change at page 12, line 29 skipping to change at page 13, line 45
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 being advertised on the link but option contains prefixes that are being advertised on the link but
are not explicitly configured on the sending router. The router are not explicitly configured on the sending router. The router
MUST NOT include any prefixes with a zero valid lifetime in the MUST NOT include any prefixes with a zero valid lifetime in the
LPO. LPO.
6. DNA Operation 5. DNA Operation
6.1 DNA Router Operation 5.1 DNA Router Operation
Routers MUST collect information about the other routers that are Routers MUST collect information about the other routers that are
advertising on the link. advertising on the link.
6.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 "DNARouterPrefixList". Prefixes are learned by their
reception within Prefix Information Options [3] in Router reception within Prefix Information Options [3] in Router
Advertisements. Prefixes in Learned Prefix Options (see Section 5.3) Advertisements. Prefixes in Learned Prefix Options (see Section 4.4)
MUST NOT update the contents of DNARouterPrefixList. For each prefix MUST NOT update the contents of DNARouterPrefixList. For each prefix
the router MUST store sufficient information to identify the prefix the router MUST store sufficient information to identify the prefix
and to know when to remove the prefix entry from the list. This may and to know when to remove the prefix entry from the list. This may
be achieved by storing the following information: 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
skipping to change at page 13, line 24 skipping to change at page 14, line 40
The expiry time for entries in DNARouterPrefixList is 1.5 hours The expiry time for entries in DNARouterPrefixList is 1.5 hours
(three times the maximum value of the Router Advertisement interval) (three times the maximum value of the Router Advertisement interval)
after the last received Router Advertisement affecting the entry, or after the last received Router Advertisement affecting the entry, or
the scheduled expiry of the prefix valid lifetime, whichever is the scheduled expiry of the prefix valid lifetime, whichever is
earlier. 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 DNA flag set, the following Advertisement is received with the FastRA flag set, the following
information MUST be stored: information MUST be stored:
1. Link-local source address of advertising router 1. Link-local source address of advertising router
2. Token equal to the first 64 bits of an SHA-1 hash of the above 2. Token equal to the first 64 bits of an SHA-1 hash of the above
address address
3. Expiry time 3. Expiry time
Each router MUST include itself in the DNARouterList and generate a Each router MUST include itself in the DNARouterList and generate a
token for itself as described above based on the link-local address token for itself as described above based on the link-local address
used in its RA messages. used in its RA messages.
The expiry time for entries in DNARouterList is 1.5 hours after the The expiry time for entries in DNARouterList is 1.5 hours after the
last received Router Advertisement affecting the entry. last received Router Advertisement affecting the entry.
6.1.2 Router Configuration Variables 5.1.2 Router Configuration Variables
A DNAv6 router MUST allow for the following conceptual variables to A DNAv6 router MUST allow for the following conceptual variables to
be configured by the system management. Default values are set to be configured by the system management. Default values are set to
ease configuration load. ease configuration load.
UnicastRAInterval UnicastRAInterval
The interval corresponding to the maximum average rate of Router The interval corresponding to the maximum average rate of Router
Solicitations that the router is prepared to service with unicast Solicitations that the router is prepared to service with unicast
responses. This is the interval at which the token bucket responses. This is the interval at which the token bucket
controlling the unicast responses is replenished. controlling the unicast responses is replenished.
Default: 50 milliseconds Default: 50 milliseconds
MaxUnicastRABurst MaxUnicastRABurst
The maximum size burst of Router Solicitations that the router is The maximum size burst of Router Solicitations that the router is
skipping to change at page 14, line 41 skipping to change at page 16, line 7
Default: 3000 milliseconds Default: 3000 milliseconds
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
6.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 When an interface on a router first starts up, it SHOULD transmit up
to MAX_RTR_SOLICITATIONS Router Solicitations separated by to MAX_RTR_SOLICITATIONS Router Solicitations separated by
RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other
routers and prefixes active on the link. 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 DNA flag MUST be set. The DNA flag is set so that except that the FastRA flag MUST be set. The FastRA flag is set so
other routers will know to include this router in their timing that other routers will know to include this router in their timing
calculations for fast RA transmission. Other DNA options are omitted calculations for fast RA transmission. Other DNA options are omitted
because the router may have incomplete information during bootstrap. because the router may have incomplete information during bootstrap.
During the bootstrap period, the Complete flag in Router
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.
6.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 DNA flag is set in the RA, the router checks if there is an If the FastRA flag is set in the RA, the router checks if there is an
entry in its DNARouterList. Thus it looks up the source address of entry in its DNARouterList. Thus it looks up the source address of
the RA in that list and, if not found, a new entry is added to 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 DNA flag, each PIO in the RA is Regardless of the state of the FastRA 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 DNARouterPrefixList
or AdvPrefixList [3], it is added to the DNARouterPrefixList, and its and not in the router's AdvPrefixList [3], it is added to the
expiry time is set. DNARouterPrefixList, and its expiry time is set.
6.1.5 Processing Router Solicitations 5.1.5 Processing Router Solicitations
All Router Advertisements sent by a DNA router MUST have the "D" flag All Router Advertisements sent by a DNA router MUST have the "F" 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.
The usual response to an RS SHOULD be a unicast RA. However, to keep The usual response to an RS SHOULD be a unicast RA. However, to keep
control of the rate of unicast RAs sent, a token bucket is used. The control of the rate of unicast RAs sent, a token bucket is used. The
token bucket is filled at one token every UnicastRAInterval. A token bucket is filled at one token every UnicastRAInterval. A
maximum of MaxUnicastRABurst tokens are stored. maximum of MaxUnicastRABurst tokens are stored.
In order to respond to a Router Solicitation, the router SHOULD In order to respond to a Router Solicitation, the router SHOULD
generate a Complete RA as specified in Section 6.1.6. The Router generate a Complete RA as specified in Section 5.1.6. The Router
Advertisement MUST include the LinkID, as described in Section 6.1.7. Advertisement MUST include the LinkID, as described in Section 5.1.7.
If a unicast send token is available AND the source address of the If a unicast send token is available AND the source address of the
Router Solicitation is NOT the unspecified address (::), then a token Router Solicitation is NOT the unspecified address (::), then a token
is removed and the Router Advertisement is scheduled for transmission is removed and the Router Advertisement is scheduled for transmission
as specified in Section 6.1.8. as specified in Section 5.1.8.
If this is not the case AND there is no multicast RA scheduled for If no unicast send token is available OR the source address of the
transmission in the next MulticastRADelay, then the RA MUST be sent Router Solicitation is the unspecified address, then if there is no
to the link-scoped all-hosts multicast address at the current time multicast RA scheduled for transmission in the next MulticastRADelay
plus MulticastRADelay. the RA MUST be sent to the link-scoped all-nodes multicast address at
the current time plus MulticastRADelay.
If neither of these conditions is true and there is already a If no unicast send token is available OR the source address of the
Router Solicitation is the unspecified address but there is a
multicast RA scheduled for transmission in the next MulticastRADelay, multicast RA scheduled for transmission in the next MulticastRADelay,
then the Router Solicitation MUST be dropped. then the Router Solicitation MUST be dropped.
6.1.5.1 Space Optimized Advertisements 5.1.5.1 Space Optimized Advertisements
If the Router Solicitation contains a Landmark Option whose prefix is If the Router Solicitation contains a Landmark Option whose prefix is
included in DNARouterPrefixList or AdvPrefixList AND the included in DNARouterPrefixList or AdvPrefixList AND the
corresponding Router Advertisement will be unicast, the router MAY corresponding Router Advertisement will be unicast, the router MAY
send an abbreviated Router Advertisement. send an abbreviated Router Advertisement.
The abbreviated advertisement includes only the Landmark Option, with The abbreviated advertisement includes only the Landmark Option, with
the "Y" flag set, plus the base RA header and any SEND options as the "Y" flag set, plus the base RA header and any SEND options as
appropriate. appropriate. The Complete flag MUST NOT be set. This is the one
exception where the LinkID prefix MAY be omitted as the Y flag
implies that link change has not occured.
6.1.6 Complete Router Advertisements Some prefixes may also be omitted from unsolicited Router
Advertisements, as described in Section 5.1.9.
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 DNA flag is set. As many Advertisement Interval, flags, etc.), the FastRA flag is set. As
Prefix Information Options for explicitly configured prefixes as will many Prefix Information Options for explicitly configured prefixes as
fit are added to the Router Advertisement. If there is sufficient will fit are added to the Router Advertisement. If there is
room, a Learned Prefix Option as defined in Section 5.3 containing as sufficient room, a Learned Prefix Option as defined in Section 4.4
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 it is not possible to generate a Complete RA but the Router If it is not possible to generate a Complete RA but the Router
Solicitation that this Router Advertisement is in response to, if Solicitation that this Router Advertisement is in response to, if
any, includes a Landmark Option containing a prefix that is not in any, includes a Landmark Option containing a prefix that is not in
DNARouterPrefixList or AdvPrefixList then the router SHOULD include a the router's DNARouterPrefixList and not in the router's
Landmark Option with the "N" flag set. AdvPrefixList then the router SHOULD include a Landmark Option with
the "N" flag set. If there are known to be prefixes that are not
included in the Router 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 LinkID prefix MUST be included. into an RA, the LinkID prefix MUST be included.
6.1.7 LinkID Prefix 5.1.7 LinkID Prefix
One of the prefixes in use on a link is chosen to be the LinkID. One of the prefixes in use on a link is chosen to be the LinkID.
The LinkID is the numerically smallest prefix stored in either of The LinkID is the numerically smallest prefix stored in either of
DNARouterPrefixList or AdvPrefixList whose lifetime is greater than DNARouterPrefixList or AdvPrefixList whose lifetime is greater than
1.5 hours. For comparing prefixes, they are padded to the right with 1.5 hours. For comparing prefixes, they are padded to the right with
zeros to make them 128 bit unsigned integers. zeros to make them 128 bit unsigned integers.
The prefix may be included in the RA in either a PIO or LPO as The prefix may be included in the RA in either a PIO or LPO as
appropriate. appropriate. If the prefix is included in a PIO, then the "I" flag
in that PIO MUST be set. If the prefix is included in an LPO, then
the prefix MUST be placed in the first prefix field in the LPO, and
the LPO "I" flag MUST be set.
6.1.7.1 Changing the LinkID 5.1.7.1 Changing the LinkID
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 LinkID falls below 1.5 prefix that is currently being used as the LinkID falls below 1.5
hours, a new LinkID is determined. In order to ensure that there is hours, a new LinkID is determined. In order to ensure that there is
overlap between consecutive RAs on the link, the old LinkID must overlap between consecutive RAs on the link, the old LinkID must
continue to be advertised for some time alongside the new LinkID. continue to be advertised for some time alongside the new LinkID.
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
skipping to change at page 17, line 45 skipping to change at page 19, line 27
link should have also sent at least one advertisement with the new link should have also sent at least one advertisement with the new
LinkID. LinkID.
1.5 hours after first sending an advertisement with a new LinkID it 1.5 hours after first sending an advertisement with a new LinkID it
is safe to consider the old LinkID gone and omit the corresponding is safe to consider the old LinkID gone and omit the corresponding
prefix from RAs if desired. prefix from RAs if desired.
Following a change of LinkID, the old LinkID prefix MUST be included Following a change of LinkID, the old LinkID prefix MUST be included
in RAs for the following 1.5 hours. in RAs for the following 1.5 hours.
6.1.8 Scheduling Fast Router Advertisements 5.1.7.1.1 Non-Prefix LinkIDs
Although this memo only discusses LinkIDs that are prefixes, a future
specification or ammendment may describe a mechanism to select a
LinkID that is not a prefix.
Information from the Learned Prefix Option is only stored in
DNAHostPrefixList, and is only used for DNA purposes. Because a
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
DNAHostPrefixList (Section 5.2.1).
Following a change of LinkID, the old LinkID prefix MUST be included
in RAs in an LPO for the following 1.5 hours.
Future specifications MUST NOT treat the information in an LPO as
prefixes such as they would the prefixes found in a Prefix
Information Option. Future specifications MUST NOT assume that the
entries in a host's DNAHostPrefixList are actaul prefixes in use on
the link.
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
MUST be used as the RS host token. MUST be used as the RS host token.
skipping to change at page 18, line 28 skipping to change at page 20, line 30
If Rank < FastRAThreshold, then the RA MUST be scheduled for If Rank < FastRAThreshold, then the RA MUST be scheduled for
transmission in Rank * RASeparation milliseconds. When the router is transmission in Rank * RASeparation milliseconds. When the router is
ranked as zero, the resulting delay is zero, thus the RA SHOULD be ranked as zero, the resulting delay is zero, thus the RA SHOULD be
sent immediately. sent immediately.
If Rank >= FastRAThreshold, then the RA MUST be replaced with a If Rank >= 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.
6.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 "D" flag in the RA header MUST be set. The "F" 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 LinkID prefix. configured prefixes, but MUST include the LinkID 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.
6.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 1.5 hours or at the DNARouterPrefixList and set it to expire in 1.5 hours or at the
expiry of the last advertised valid lifetime, whichever is earlier. expiry of the last advertised valid lifetime, whichever is earlier.
This ensures that to hosts there will be overlap in the prefixes in This ensures that to hosts there will be overlap in the prefixes in
the RAs they see and prevent them from incorrectly interpreting the RAs they see and prevent them from incorrectly interpreting
changed prefixes as movement. changed prefixes as movement.
6.1.10.1 Early Removal of the LinkID Prefix 5.1.10.1 Early Removal of the LinkID Prefix
If the LinkID prefix is to be withdrawn early from a link, that is If the LinkID 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 1.5 hours with a valid lifetime of MUST be advertised for at least 1.5 hours with a valid lifetime of
less than 1.5 hours. This ensures that all of the other routers are less than 1.5 hours. This ensures that all of the other routers are
notified to begin the process of changing the LinkID as well, and notified to begin the process of changing the LinkID as well, and
hosts will always see overlap between the prefixes in consecutive RAs hosts will always see overlap between the prefixes in consecutive RAs
and thus not mistake an RA for an indication of link change. and thus not mistake an RA for an indication of link change.
6.1.11 Prefix Reassignment 5.1.11 Prefix Reassignment
A prefix whose lifetime has expired after counting down in real time A prefix whose lifetime has expired after counting down in real time
for at least 1.5 hours may be reassigned to another link immediately for at least 1.5 hours may be reassigned to another link immediately
after expiry. If a prefix is withdrawn from a link without counting after expiry. If a prefix is withdrawn from a link without counting
down to the expiry of its valid lifetime, it SHOULD NOT be reassigned down to the expiry of its valid lifetime, it SHOULD NOT be reassigned
to another link for at least 1.5 hours or until the original expiry to another link for at least 1.5 hours or until the original expiry
time, whichever is earlier. This gives sufficient time for other time, whichever is earlier. This gives sufficient time for other
routers that have learned the prefix to expire it, and for hosts that routers that have learned the prefix to expire it, and for hosts that
have seen advertisements from those routers to expire the prefix as have seen advertisements from those routers to expire the prefix as
well. well.
Earlier reassignment may result in hosts that move from between the Earlier reassignment may result in hosts that move from between the
old and new links failing to detect the movement. old and new links failing to detect the movement.
6.2 DNA Host Operation 5.2 DNA Host Operation
Hosts collect information about the prefixes available on the link to Hosts collect information about the prefixes available on the link to
which they are connected to facilitate change detection. which they are connected to facilitate change detection.
6.2.1 Data Structures 5.2.1 Data Structures
Hosts MUST maintain a list of prefixes advertised on the link. This Hosts MUST maintain a list of prefixes advertised on the link. This
is separate from the RFC 2461 "Prefix List" and will be referred to is separate from the RFC 2461 "Prefix List" and will be referred to
here as the "DNAHostPrefixList". All prefixes SHOULD be stored, here as the "DNAHostPrefixList". All prefixes SHOULD be stored,
however an upper bound MUST be placed on the number stored to prevent however an upper bound MUST be placed on the number stored to prevent
overflow. For each prefix stored the host MUST store the following overflow. For each prefix stored the host MUST store the following
information: information:
1. Prefix 1. Prefix
skipping to change at page 20, line 11 skipping to change at page 22, line 16
If a host is not able to store this information for every prefix, If a host is not able to store this information for every prefix,
there is a risk that the host will incorrectly decide that it has there is a risk that the host will incorrectly decide that it has
moved to a new link, when it receives advertisements from a non-DNA moved to a new link, when it receives advertisements from a non-DNA
router. router.
Prefix entries in the DNAHostPrefixList expire and MUST be removed Prefix entries in the DNAHostPrefixList expire and MUST be removed
1.5 hours after they are last seen in a received Router Advertisement 1.5 hours after they are last seen in a received Router Advertisement
(in either a PIO or LPO) or at the expiry of the valid lifetime of (in either a PIO or LPO) or at the expiry of the valid lifetime of
the prefix, whichever is earlier. the prefix, whichever is earlier.
Hosts MUST also maintain a "Landmark Prefix" as described in Hosts MUST also maintain a list of all LinkIDs seen on the current
Section 6.2.3. Link. This list will be referred to as "DNAHostLinkIDList". This
list is identical in structure to DNAHostPrefixList but contains
LinkIDs instead of prefixes.
6.2.2 Host Configuration Variables At this time LinkIDs are also prefixes but in future may be able to
be identifiers other than prefixes. A list is stored rather than a
single entry to allow for changes in the LinkID used on a link.
Entries are expired from DNAHostLinkIDList in the same way as
DNAHostPrefixList.
Hosts SHOULD also maintain a "Landmark Prefix" as described in
Section 5.2.3.
5.2.2 Host Configuration Variables
Hosts MUST make use of the following conceptual variables and they Hosts MUST make use of the following conceptual variables and they
SHOULD be configurable: SHOULD be configurable:
DNASameLinkDADFlag DNASameLinkDADFlag
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
6.2.3 Selection of a Landmark Prefix 5.2.3 Selection of a Landmark Prefix
For each interface, hosts SHOULD choose a prefix to use as a Landmark For each interface, hosts SHOULD choose a prefix to use as a Landmark
Prefix in Router Solicitations. The following rules are used in Prefix in Router Solicitations. The following rules are used in
selecting the landmark prefix: selecting the landmark prefix:
The prefix MUST have a non-zero valid lifetime. The prefix MUST have a non-zero valid lifetime. If the valid
lifetime of a previously selected Landmark Prefix expires, a new
Landmark Prefix MUST be selected.
The prefix MUST be one the host is using for one of its non-link- The prefix MUST be one of those that the hosts has used to assign
local IPv6 addresses. a non-link-local address to itself
The prefix SHOULD be chosen as the one with the longest preferred The prefix SHOULD be chosen as the one with the longest preferred
lifetime, but it is not necessary to switch to different prefix if lifetime, but it is not necessary to switch to different prefix if
the preferred lifetime of the current landmark prefix changes. the preferred lifetime of the current landmark prefix changes.
6.2.4 Sending Router Solicitations 5.2.4 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 hints.
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 the landmark prefix chosen based on the rules in Section 5.2.3.
Section 6.2.3.
Hosts MUST include a tentative source link layer address option Hosts MUST include a tentative source link layer address option
(TSLLAO) in the RS message [16]. The router solicitation message is (TSLLAO) in the RS message [7]. The router solicitation message is
sent to the All_Routers_Multicast address and the source address MUST sent to the All_Routers_Multicast address and the source address MUST
be the link local address of the host. be the link local address of the host.
The host MUST consider its link local address to be in the The host MUST consider its link local address to be in the
"Optimistic" state for duplicate address detection [6] until either "Optimistic" state for duplicate address detection [6] until either
the returned RA confirms that the host has not switched to a new link the returned RA confirms that the host has not switched to a new link
or, if an link change has occurred, the host has performed optimistic or, if an link change has occurred, the host has performed optimistic
duplicate address detection for the address. duplicate address detection for the address.
6.2.5 Processing Router Advertisements 5.2.5 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 conditions and derives the associated conclusions given below: the conditions and derives the associated conclusions given below:
If the RA contains a Landmark Option with the "Y" flag set that If the RA contains a Landmark Option with the "Y" flag set that
matches the Landmark Option in the last transmitted Router matches the Landmark Option in the last transmitted Router
Solicitation, then that indicates that no link change has occurred Solicitation, then that indicates that no link change has occurred
and current configuration can be assumed to still be current. and current configuration can be assumed to still be current.
If the RA includes any prefixes in either a PIO or LPO then the If the RA includes any prefixes in either a PIO or LPO that
host can conclude that no link change has occurred and current matches a prefix in DNAHostPrefixList then the host can conclude
configuration can be assumed to still be current. that no link change has occurred and current configuration can be
assumed to still be current.
If the RA includes a LinkID that matches an entry in
DNAHostLinkIDList, then the host can conclude that no link change
has occurred and the current configuration can be assumed to still
be current.
If the RA is a Complete RA, as indicated by the "Complete" flag in If the RA is a Complete RA, as indicated by the "Complete" flag in
the RA header, and there are no prefixes included in it in either the RA header, and there are no prefixes included in it in either
a PIO or LPO that are also in the hosts DNAHostPrefixList, then a PIO or LPO that are also in the hosts 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 not a Complete RA, but there is a Landmark Option If the RA is not a CompleteRA, but includes a LinkID that is not
with the "N" flag set that matches the Landmark Option in the last in DNAHostLinkIDList and no prefixes that match entries in
transmitted Router Solicitation and there are no prefixes included
in the RA 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 received RA is not complete, contains no prefixes that are If the received RA is not complete, contains no prefixes that are
stored in DNAHostPrefixList and does not contain a Landmark Option stored in DNAHostPrefixList, does not contain a Landmark Option
that matches a corresponding option in the most recent RS, then that matches a corresponding option in the most recent RS and
the host SHOULD use CPL logic to decide whether or not to contains no LinkID, then the host SHOULD use CPL logic to decide
reconfigure as described in [14]. whether or not to reconfigure as described in [15].
If the destination address of the received RA is a unicast address, If the destination address of the received RA is a unicast address,
the host knows the router heard its RS, and hence it SHOULD mark that the host knows the router heard its RS, and hence it SHOULD mark that
router's Neighbor Cache Entry [3] as REACHABLE. router's Neighbor Cache Entry [3] as REACHABLE.
5.2.5.1 Maintaining the DNAHostPrefixList
If a Router Advertisement does not indicate a link change, the host
update its DNAHostPrefixList.
If the Router Advertisement has the C flag set, then the host should
make the DNAHostPrefixList match the contents of the advertisement.
Any new prefixes should be added and any prefixes in the list that
are absent in the advertisement should be removed. Expiry times on
prefixes should be updated if the prefix was contained in a PIO, but
not if it was contained in an LPO.
If the Router Advertisement does not have the C flag set, then the
host should add any new prefixes and update expiry times as above,
but should not remove any entries from DNAHostPrefixList.
When initiating reconfiguration due to link change, the host MUST When initiating reconfiguration due to link change, the host MUST
remove all prefixes in the DNAHostPrefixList and repopulate it with remove all prefixes in the DNAHostPrefixList and repopulate it with
the prefixes in the Prefix Information Options and Learned Prefix the prefixes in the Prefix Information Options and Learned Prefix
Option, if any, in the RA. Option, if any, in the RA.
6.2.6 DNA and Address Configuration 5.2.6 DNA and Address Configuration
When a host moves to a new point of attachment, a potential exists When a host moves to a new point of attachment, a potential exists
for a change in the validity of its unicast and multicast addresses for a change in the validity of its unicast and multicast addresses
on that network interface. In this section, host processing for on that network interface. In this section, host processing for
address configuration is specified. The section considers both address configuration is specified. The section considers both
statelessly and statefully configured addresses. statelessly and statefully configured addresses.
6.2.6.1 Duplicate Address Detection 5.2.6.1 Duplicate Address Detection
A DNA host MUST support optimistic Duplicate Address Detection [6] A DNA host MUST support optimistic Duplicate Address Detection [6]
for autoconfiguring unicast link local addresses. If a DNA host uses for autoconfiguring unicast link local addresses. If a DNA host uses
address autoconfiguration [7] for global unicast addresses, the DNA address autoconfiguration [8] for global unicast addresses, the DNA
host MUST support optimistic Duplicate Address Detection for host MUST support optimistic Duplicate Address Detection for
autoconfiguring global unicast addresses. autoconfiguring global unicast addresses.
6.2.6.2 DNA and the Address Autoconfiguration State Machine 5.2.6.2 DNA and the Address Autoconfiguration State Machine
When a link level event occurs on a network interface indicating that When a link level event occurs on a network interface indicating that
the host has moved from one point of attachment to another, it is the host has moved from one point of attachment to another, it is
possible that a change in the reachability of the addresses possible that a change in the reachability of the addresses
associated with that interface may occur. Upon detection of such a associated with that interface may occur. Upon detection of such a
link event and prior to sending the RS initiating a DNA exchange, a link event and prior to sending the RS initiating a DNA exchange, a
DNA host MUST change the state of addresses associated with the DNA host MUST change the state of addresses associated with the
interface in the following way (address state designations follow RFC interface in the following way (address state designations follow RFC
2461): 2461):
skipping to change at page 24, line 5 skipping to change at page 26, line 43
previous point of attachment, so the host may not have confirmed previous point of attachment, so the host may not have confirmed
address uniqueness. If the previous state of an address was address uniqueness. If the previous state of an address was
"Preferred", whether or not the host initiates optimistic Duplicate "Preferred", whether or not the host initiates optimistic Duplicate
Address Detection depends on the configurable DNASameLinkDADFlag Address Detection depends on the configurable DNASameLinkDADFlag
flag. A host MUST forgo sending an NS to confirm uniqueness if the flag. A host MUST forgo sending an NS to confirm uniqueness if the
value of the DNASameLinkDAD flag is False. If, however, the value of the DNASameLinkDAD flag is False. If, however, the
DNASameLinkDAD flag is True, the host MUST perform optimistic DNASameLinkDAD flag is True, the host MUST perform optimistic
duplicate address detection on its unicast link local and unicast duplicate address detection on its unicast link local and unicast
global addresses to determine address uniqueness. global addresses to determine address uniqueness.
6.2.6.3 DNA and Statefully Configured Addresses 5.2.6.3 DNA and Statefully Configured Addresses
The DHCPv6 specification [8] requires hosts to send a DHCPv6 CONFIRM The DHCPv6 specification [9] requires hosts to send a DHCPv6 CONFIRM
message when a change in point of attachment is detected. Since the message when a change in point of attachment is detected. Since the
DNA protocol provides the same level of movement detection as the DNA protocol provides the same level of movement detection as the
DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the
DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive
signaling. If, however, a non-DNA RA is received, the host SHOULD signaling. If, however, a non-DNA RA is received, the host SHOULD
use the DHCPv6 CONFIRM message as described in RFC 3315 [8] rather use the DHCPv6 CONFIRM message as described in RFC 3315 [9] rather
than wait for additional RAs to perform CPL, since this will reduce than wait for additional RAs to perform CPL, since this will reduce
the amount of time required for the host to confirm whether or not it the amount of time required for the host to confirm whether or not it
has moved to a new link. If the CONFIRM message validates the has moved to a new link. If the CONFIRM message validates the
addresses, the host can continue to use them. addresses, the host can continue to use them.
When a DNA RA is received and the received RA indicates that the host When a DNA RA is received and the received RA indicates that the host
has not moved to a new link, the host SHOULD apply the same rules to has not moved to a new link, the host SHOULD apply the same rules to
interpreting the 'M' flag in the received RA and any subsequently interpreting the 'M' flag in the received RA and any subsequently
received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA
is received with the 'M' flag set, then the 'M' flag value is copied is received with the 'M' flag set, then the 'M' flag value is copied
skipping to change at page 24, line 40 skipping to change at page 27, line 30
new addresses, since the old addresses will continue to be valid. new addresses, since the old addresses will continue to be valid.
If the DNA RA indicates that the host has moved to a new link or the If the DNA RA indicates that the host has moved to a new link or the
DHCPv6 CONFIRM indicates that the addresses are invalid, the host DHCPv6 CONFIRM indicates that the addresses are invalid, the host
MUST move its old addresses to the "Deprecated" state and MUST run MUST move its old addresses to the "Deprecated" state and MUST run
DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is
4-message exchange, however, this exchange allows for redundancy 4-message exchange, however, this exchange allows for redundancy
(multiple DHCPv6 servers) without wasting addresses, as addresses are (multiple DHCPv6 servers) without wasting addresses, as addresses are
only provisionally assigned to a host until the host chooses and only provisionally assigned to a host until the host chooses and
requests one of the provisionally assigned addresses. If the DNA requests one of the provisionally assigned addresses. If the DNA
host supports the Rapid Commit Option [8], the host SHOULD use the host supports the Rapid Commit Option [9], the host SHOULD use the
Rapid Commit Option in order to shorten the exchange from 4 messages Rapid Commit Option in order to shorten the exchange from 4 messages
to 2 messages. to 2 messages.
6.2.6.4 Packet Delivery During DNA 5.2.6.4 Packet Delivery During DNA
The specification of packet delivery before, during, and immediately The specification of packet delivery before, during, and immediately
after DNA when a change in point of attachment occurs is out of scope after DNA when a change in point of attachment occurs is out of scope
for this document. The details of how packets are delivered depends for this document. The details of how packets are delivered depends
on the mobility management protocols (if any) available to the host's on the mobility management protocols (if any) available to the host's
stack. stack.
6.2.6.5 Multicast Address Configuration 5.2.6.5 Multicast Address Configuration
If the returning RAs indicate that the host has not moved to a new If the returning RAs indicate that the host has not moved to a new
link, no further action is required for multicast addresses to which link, no further action is required for multicast addresses to which
the host has subscribed using MLD Report [9]. In particular, the the host has subscribed using MLD Report [10]. In particular, the
host MUST NOT perform MLD signaling for any multicast addresses host MUST NOT perform MLD signaling for any multicast addresses
unless such signaling was not performed prior to movement to the new unless such signaling was not performed prior to movement to the new
point of attachment. For example, if an address is put into the point of attachment. For example, if an address is put into the
"Optimistic" state prior to movement but the MLD Report for the "Optimistic" state prior to movement but the MLD Report for the
Solicited_Node_Multicast_Address is not sent prior to movement to a Solicited_Node_Multicast_Address is not sent prior to movement to a
new point of attachment, the host MUST send the MLD Report on the new new point of attachment, the host MUST send the MLD Report on the new
point of attachment prior to performing optimistic Duplicate Address point of attachment prior to performing optimistic Duplicate Address
Detection. The host SHOULD use the procedure described below for Detection. The host SHOULD use the procedure described below for
sending an MLD Report. sending an MLD Report.
If, on the other hand, the DNA RA indicates that the host has moved If, on the other hand, the DNA RA indicates that the host has moved
to a new link, the host MUST issue a new MLD Report to the router for to a new link, the host MUST issue a new MLD Report to the router for
subscribed multicast addresses. MLD signaling for the subscribed multicast addresses. MLD signaling for the
Solicited_Node_Multicast_Addresses [7] MUST be sent prior to Solicited_Node_Multicast_Addresses [8] MUST be sent prior to
performing signaling for optimistic DAD. performing signaling for optimistic DAD.
To avoid lengthy delays in address reconfiguration, it is RECOMMENDED To avoid lengthy delays in address reconfiguration, it is RECOMMENDED
that the host send the MLD Report for newly configured addresses that the host send the MLD Report for newly configured addresses
immediately, as soon as the addresses have been constructed, rather immediately, as soon as the addresses have been constructed, rather
than waiting for a random backoff. than waiting for a random backoff.
Hosts MUST defer MLD signaling until after the results of DNA have Hosts MUST defer MLD signaling until after the results of DNA have
confirmed whether or not a link change has occurred. confirmed whether or not a link change has occurred.
7. Backward Compatibility 6. Backward Compatibility
7.1 Non DNA Host with DNA Routers 6.1 Non-DNA Host with DNA Routers
The RS message sent by non-DNA hosts will not contain any of the new The RS message sent by non-DNA hosts will not contain any of the new
options defined by this document. The host will receive a Complete options defined by this document. The host will receive a Complete
RA in response to the solicitation message and process it as per RFC RA in response to the solicitation message and process it as per RFC
2461. This means that it will drop the unrecognised Learned Prefix 2461. This means that it will drop the unrecognised Learned Prefix
option, but process the included PIOs and non-DNA flags normally. option, but process the included PIOs and non-DNA flags normally.
7.2 DNA Host with Non-DNA Routers 6.2 DNA Host with Non-DNA Routers
The routers will behave based in the recommendations of RFC 2461 [3] The routers will behave based in the recommendations of RFC 2461 [3]
and ignore the new options defined in this memo. Hosts will receive and ignore the new options defined in this memo. Hosts will receive
RA message without the DNA bit in the RA header set and will fallback RA message without the FastRA flag in the RA header set and will
on CPL for link identification. Obviously, the objective of fallback on CPL for link identification. Obviously, the objective of
receiving fast response for RS message can not be achieved. receiving fast response for RS message can not be achieved.
8. Security Considerations This case can occur on a link with no DNA routers or on a link with a
mix of the two. In the latter, usually a response from the DNA
8.1 Amplification Effect router(s) will be received first and CPL will just be used with the
non-DNA Router Advertisement to confirm that no movement has taken
place since the previous DNA advertisement.
With N routers on a link, each RS message sent on the link will have 7. Security Considerations
N RA responses sent on the link within (N-1) * RASeparation time.
The rate control mechanism specified by this memo only controls the
rate of RA messages generated by each of the routers. But, since
there is no theoretical restriction on the number of routers on the
link, this amplification can deteriorate the performance of the nodes
on the link. The routers could mitigate this effect by aggregating
multiple RA messages into a single multicast RA message. When a RS
message is received, except for the router chosen to respond first,
all the other routers have a delay introduced before they respond to
the RS message. Also, when the token bucket is empty (see
Section 8.2), the routers will have to wait for a token to be
generated before responding. If multiple RS messages are received
during this wait time, the routers MAY choose to aggregate the
responses to a single multicast RA message. Aggregation can be done
by creating a Complete RA message as specified by Section 6.1.6.
But, since MIN_DELAY_BETWEEN_RAS restriction for multicast RA
messages is inherited by this document, such aggregations are only
possible every MIN_DELAY_BETWEEN_RAS (3 seconds).
8.2 Attacks on the Token Bucket 7.1 Attacks on the Token Bucket
A host on the link could easily drain the token bucket(s) of the A host on the link could easily drain the token bucket(s) of the
router(s) on the link by continuously sending RS messages on the router(s) on the link by continuously sending RS messages on the
link. For example, if a host sends one RS message every link. For example, if a host sends one RS message every
UnicastRAInterval, and send a additional RS every third UnicastRAInterval, and send a additional RS every third
UnicastRAInterval, the token bucket in the router(s) on the link will UnicastRAInterval, the token bucket in the router(s) on the link will
drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units.
For the recommended values of UnicastRAInterval and For the recommended values of UnicastRAInterval and
MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear
whether arrival of such RS messages can be recognized by the router whether arrival of such RS messages can be recognized by the router
as a DoS attack. This attack can also be mitigated by aggregating as a DoS attack. This attack can also be mitigated by aggregating
responses. Since only one aggregation is possible in this interval responses. Since only one aggregation is possible in this interval
due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able
protect the tokens in the bucket. protect the tokens in the bucket.
8.3 Attacks on DNA Hosts 7.2 Attacks on DNA Hosts
RFC 3756 outlines a collection of threats involving rouge routers. RFC 3756 outlines a collection of threats involving rouge routers.
Since DNAv6 requires a host to obtain trustworthy responses from Since DNAv6 requires a host to obtain trustworthy responses from
routers, such threats are relevant to DNAv6. In order to counter routers, such threats are relevant to DNAv6. In order to counter
such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router such threats, DNAv6 hosts SHOULD support RFC 3971 (SEND) secure
discovery. router discovery.
9. IANA Considerations 8. 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 5.2; and 1. The Landmark option, described in Section 4.3; and
2. The Learned Prefix option, described in Section 5.3. 2. The Learned Prefix option, described in Section 4.4.
10. Acknowledgments 9. Acknowledgments
The design presented in this document was generated by discussions The design presented in this document grew out of discussions among
among the members of the DNA design team (JinHyeock Choi, Tero the members of the DNA design team (JinHyeock Choi, Tero Kauppinen,
Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland).
Pentland). The spirited debates on the design, advantages and dis- The spirited debates on the design, and the advantages and dis-
advantages of various DNA solutions helped creation of this document. advantages of various DNA solutions helped the creation of this
Thanks to Subba Reddy and Gabriel Montenegro for their review of document.
draft-pentland-dna-protocol-00.txt upon which this was based. Thanks
also to other members of the DNA working group for their comments
that helped shape this work.
11. References Thanks to Syam Madanapalli who co-authored
draft-jinchoi-dna-protocol2 from which this draft draws ideas, as
well as providing feedback on draft-pentland-dna-protocol from which
most of the text for this draft comes.
11.1 Normative References Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol
and for helping to work out how to merge the two drafts into this
one.
Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli,
Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review
of this document.
Thanks to Gabriel Montenegro for his review of
draft-pentland-dna-protocol.
Thanks also to other members of the DNA working group for their
comments that helped shape this work.
10. References
10.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.
skipping to change at page 28, line 5 skipping to change at page 30, line 40
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, [5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
(work in progress), July 2004. (work in progress), July 2004.
[6] Moore, N., "Optimistic Duplicate Address Detection for IPv6", [6] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
draft-ietf-ipv6-optimistic-dad-05 (work in progress), draft-ietf-ipv6-optimistic-dad-05 (work in progress),
February 2005. February 2005.
11.2 Informative References [7] Daley, G., "Tentative Source Link-Layer Address Options for IPv6
Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in
progress), June 2004.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address 10.2 Informative References
[8] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462 2462, December 1998. Autoconfiguration", RFC2462 2462, December 1998.
[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[10] Choi, J., "Detecting Network Attachment in IPv6 Goals", [11] Choi, J., "Detecting Network Attachment in IPv6 Goals",
draft-ietf-dna-goals-04 (work in progress), December 2004. draft-ietf-dna-goals-04 (work in progress), December 2004.
[11] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network [12] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network
Attachment in IPv6 - Best Current Practices", Attachment in IPv6 - Best Current Practices",
draft-narayanan-dna-bcp-00 (work in progress), June 2004. draft-narayanan-dna-bcp-00 (work in progress), June 2004.
[12] Yamamoto, S., "Detecting Network Attachment Terminology", [13] Yamamoto, S., "Detecting Network Attachment Terminology",
draft-yamamoto-dna-term-00 (work in progress), February 2004. draft-yamamoto-dna-term-00 (work in progress), February 2004.
[13] Manner, J. and M. Kojo, "Mobility Related Terminology", [14] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in progress), draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004. February 2004.
[14] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix [15] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress), list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005. April 2005.
[15] Pentland, B., "An Overview of Approaches to Detecting Network [16] Pentland, B., "An Overview of Approaches to Detecting Network
Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
progress), February 2005. progress), February 2005.
[16] Daley, G., "Tentative Source Link-Layer Address Options for Authors' Addresses
IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in
progress), June 2004.
Author's Address James Kempf
DoCoMo Communications Labs USA
USA
Phone:
Email: kempf@docomolabs-usa.com
Sathya Narayanan
Panasonic Digital Networking Lab
Two Research Way, 3rd Floor
Princeton, NJ 08536
USA
Phone: 609 734 7599
Email: sathya@Research.Panasonic.COM
URI:
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA
USA
Phone: +1 650 786 2921
Email: erik.nordmark@sun.com
Brett Pentland (editor) Brett Pentland (editor)
Centre for Telecommunications and Information Engineering Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering Department of Electrical and Computer Systems Engineering
Monash University Monash University
Clayton, Victoria 3800 Clayton, Victoria 3800
Australia Australia
Phone: +61 3 9905 5245 Phone: +61 3 9905 5245
Email: brett.pentland@eng.monash.edu.au Email: brett.pentland@eng.monash.edu.au
JinHyeock Choi
Samsung Advanced Institute of Technology
PO Box 111
Suwon 440-600
Korea
Phone: +82-31-280-8194
Email: jinchoe@samsung.com
Appendix A. How the Goals are Met? Appendix A. How the Goals are Met?
The DNA goals document [10] contains a list of goals identified by G1 The DNA goals document [11] contains a list of goals identified by G1
to G10. This is also enumerated in the solutions discussion document to G10. This is also enumerated in the solutions discussion document
[15] generated by the DNA design team. This section discusses how [16] generated by the DNA design team. This section discusses how
the proposed scheme addresses each of these goals. the proposed scheme addresses each of these goals.
G1 The Complete RA contains the complete list of prefixes advertised G1 The Complete RA contains the complete list of prefixes advertised
on the link allowing the host to determine whether link change has on the link allowing the host to determine whether link change has
occurred and to re-configure if necessary. occurred and to re-configure if necessary.
G2 Under normal circumstances the host will receive a RA response G2 Under normal circumstances the host will receive a RA response
within round-trip time and some processing time on the router. If 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 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. second RA should arrive within a slot time and so on.
skipping to change at page 31, line 41 skipping to change at page 34, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/