draft-ietf-dna-protocol-03.txt   draft-ietf-dna-protocol-04.txt 
DNA Working Group S. Narayanan, Ed. DNA Working Group S. Narayanan, Ed.
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: April 26, 2007 October 23, 2006 Expires: August 6, 2007 February 2, 2007
Detecting Network Attachment in IPv6 Networks (DNAv6) Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-ietf-dna-protocol-03.txt draft-ietf-dna-protocol-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007. This Internet-Draft will expire on August 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Efficient detection of network attachment in IPv6 needs the following Efficient detection of network attachment in IPv6 needs the following
three components: a method for hosts to detect link change in the three components: a method for hosts to detect link change in the
presence of unmodified (non-DNAv6) routers, a method for the host to presence of unmodified (non-DNAv6) routers, a method for the host to
query routers on the link to identify the link (Link Identification) query routers on the link to identify the link (Link Identification)
and a method for the routers on the link to consistently respond to and a method for the routers on the link to consistently respond to
such a query with minimal delay (Fast RA). Solving the link such a query with minimal delay (Fast RA). Solving the link
identification based strictly on RFC 2461 is difficult because of the identification based strictly on RFC 2461 is difficult because of the
skipping to change at page 2, line 16 skipping to change at page 2, line 16
that requires the hosts to monitor all the prefixes advertised on the that requires the hosts to monitor all the prefixes advertised on the
link and use it for link identification in the presence of non-DNAv6 link and use it for link identification in the presence of non-DNAv6
routers is presented. A more efficient link-identification mechanism routers is presented. A more efficient link-identification mechanism
requiring the DNAv6 routers to monitor the link for advertised requiring the DNAv6 routers to monitor the link for advertised
prefixes to assist the hosts in link identification combined with a prefixes to assist the hosts in link identification combined with a
fast router advertisement mechanism that selects the order of fast router advertisement mechanism that selects the order of
response for the router deterministicly is also presented. response for the router deterministicly is also presented.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Link Identification . . . . . . . . . . . . . . . . . . . 6 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5
3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 9 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 8
3.3 Complete Prefix List generation . . . . . . . . . . . . . 10 3.3 Complete Prefix List generation . . . . . . . . . . . . . 8
3.4 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 11 3.4 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 10
3.5 Tentative Source Link-Layer Address option (TO) . . . . . 12 3.5 Tentative Source Link-Layer Address option (TO) . . . . . 11
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 13 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 12
4.2 Prefix Information Option LinkID Bit . . . . . . . . . . . 14 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 12
4.3 Landmark Option . . . . . . . . . . . . . . . . . . . . . 14 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 13
4.4 Learned Prefix Option . . . . . . . . . . . . . . . . . . 16 4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 15
4.5 Tentative option . . . . . . . . . . . . . . . . . . . . . 18
5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 19 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 19 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 16
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 19 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 16
5.1.2 Router Configuration Variables . . . . . . . . . . . . 20 5.1.2 Router Configuration Variables . . . . . . . . . . . . 17
5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 21 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 18
5.1.4 Processing Router Advertisements . . . . . . . . . . . 22 5.1.4 Processing Router Advertisements . . . . . . . . . . . 19
5.1.5 Processing Router Solicitations . . . . . . . . . . . 22 5.1.5 Processing Router Solicitations . . . . . . . . . . . 19
5.1.6 Complete Router Advertisements . . . . . . . . . . . . 23 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 20
5.1.7 LinkID . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.7 Inclusion of smallest prefixes . . . . . . . . . . . . 21
5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 25 5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 22
5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 26 5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 23
5.1.10 Removing a Prefix from an Interface . . . . . . . . 26 5.1.10 Removing a Prefix from an Interface . . . . . . . . 23
5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 26 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 23
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 27 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 24
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 27 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 24
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 28 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 25
5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 29 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 25
5.2.4 Making use of Prior Information . . . . . . . . . . . 30 5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 26
5.2.5 Selection of a Landmark Prefix . . . . . . . . . . . . 30 5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 26
5.2.6 Sending Router Solicitations . . . . . . . . . . . . . 31 5.2.6 Processing Router Advertisements . . . . . . . . . . . 27
5.2.7 Processing Router Advertisements . . . . . . . . . . . 32 5.2.7 DNA and Address Configuration . . . . . . . . . . . . 33
5.2.8 DNA and Address Configuration . . . . . . . . . . . . 38 5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 36
5.3 DNA without a 'link UP' notification . . . . . . . . . . . 41 5.3.1 Sending solicitations containing Tentative Options . . 37
5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 37
6. Tentative options for IPv6 ND . . . . . . . . . . . . . . . 43 6. Security Considerations . . . . . . . . . . . . . . . . . . 40
6.1 Sending solicitations containing Tentative Options . . . . 43 6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 40
6.1.1 Sending Neighbour Solicitations with Tentative 6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 41
Options . . . . . . . . . . . . . . . . . . . . . . . 43 6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 41
6.1.2 Sending Router Solicitations with Tentative Options . 43 6.4 Authorization and Detecting Network Attachment . . . . . . 42
6.2 Receiving Tentative Options . . . . . . . . . . . . . . . 44 6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.1 Receiving Neighbour Solicitations containing 6.6 Hint Management Security . . . . . . . . . . . . . . . . . 43
Tentative Options . . . . . . . . . . . . . . . . . . 45
6.2.2 Receiving Router Solicitations containing Tentative
Options . . . . . . . . . . . . . . . . . . . . . . . 45
7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . 45 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43
7.1 Hints Due to Network Layer Messages . . . . . . . . . . . 46
7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 46
7.3 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 47
7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 47
7.5 Hint Management for Inactive Hosts . . . . . . . . . . . . 48
8. Complications to Detecting Network Attachment . . . . . . . 48 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 49
8.2 Router Configurations . . . . . . . . . . . . . . . . . . 49
8.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 49
8.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 49
8.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 50
9. Security Considerations . . . . . . . . . . . . . . . . . . 50 9. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 44
9.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 50
9.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 50
9.3 Tentative options . . . . . . . . . . . . . . . . . . . . 51
9.4 Authorization and Detecting Network Attachment . . . . . . 52
9.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 52
9.6 Hint Management Security . . . . . . . . . . . . . . . . . 52
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53 10. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 44
11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 53 11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45
12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 46
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 14.1 Normative References . . . . . . . . . . . . . . . . . . 46
15.1 Normative References . . . . . . . . . . . . . . . . . . 55 14.2 Informative References . . . . . . . . . . . . . . . . . 47
15.2 Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 58 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 50
B. Sending directed advertisements without the neighbour B. Sending directed advertisements without the neighbour
cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . 61 Intellectual Property and Copyright Statements . . . . . . . 52
1. Introduction 1. Introduction
This memo defines a mechanism for an IPv6 host to detect link-change This memo defines a mechanism for an IPv6 host to detect link-change
in the presence of unmodified (non-DNAv6) routers and proposes new in the presence of unmodified (non-DNAv6) routers and proposes new
extensions to "IPv6 Neighbor Discovery" [3] to increase the extensions to "IPv6 Neighbor Discovery" [3] to increase the
efficiency of link-change detection in the presence of DNAv6 enabled efficiency of link-change detection in the presence of DNAv6 enabled
routers. The new extensions use complete RA for link identification, routers. The new extensions use complete RA for link identification,
and Hash-based Fast RA to achieve fast response to RS messages. and Hash-based Fast RA to achieve fast response to RS messages.
Aspects of prefix-based LinkID and Requested Landmark are included to Aspects of requested Landmark is included to allow for a decrease in
allow for a decrease in the packet sizes associated with Complete RA. the packet sizes associated with Complete RA. This memo also defines
This memo also defines a new Tentative option (TO) which is designed a new Tentative option (TO) which is designed to replace the existing
to replace the existing Source Link-Layer Address Options available Source Link-Layer Address Options available in IPv6 Neighbor
in IPv6 Neighbor Discovery when the host is performing Optimistic Discovery when the host is performing Optimistic DAD.
DAD.
The rest of the document refers to the proposed mechanisms by the The rest of the document refers to the proposed mechanisms by the
term "DNAv6". term "DNAv6".
2. Terms and Abbreviations 2. Terms and Abbreviations
There is an existing DNA terminology draft [21]. [Editor's note: Do
we have to bring in the terms from this draft?] This draft does not
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.
Access network: A network where hosts are present. Especially, a Access network: A network where hosts are present. Especially, a
network used for the support of visiting wireless hosts. network used for the support of visiting wireless hosts.
Attachment: The process of entering a new cell. Attachment (and Attachment: The process of entering a new cell. Attachment (and
detachment) may cause a link-change. detachment) may cause a link-change.
Cell: A system constituted by the propagation range of a wireless Cell: A system constituted by the propagation range of a wireless
skipping to change at page 7, line 46 skipping to change at page 6, line 37
met before making the comparison. met before making the comparison.
Though frequently all routers on a link will advertise the same set Though frequently all routers on a link will advertise the same set
of prefixes and thus experience no cost in making the RAs complete, of prefixes and thus experience no cost in making the RAs complete,
there is potential for the RAs to be large when there are many there is potential for the RAs to be large when there are many
prefixes advertised. Two mechanisms are defined that allow certain prefixes advertised. Two mechanisms are defined that allow certain
RAs to be reduced in size. RAs to be reduced in size.
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 on the
connected to the link which has this prefix?". The landmark is link which has this prefix?". The landmark is carried in a new
carried in a new option, called the Landmark Option. option, called the Landmark Option.
In the case when the host is still attached to the same link, which In the case when the host is still attached to the same link, which
might occur when the host has changed from using one layer 2 access might occur when the host has changed from using one layer 2 access
point to another, but the access points are on the same link, the point to another, but the access points are on the same link, the
Router Advertisement(s) it receives will contain a "yes, that prefix Router Advertisement(s) it receives will contain a "yes, that prefix
is on this link" answer, and no other information. Thus, such RA is on this link" answer by the inclusion of the landmark prefix in
messages are quite small. the RA, and no other information. Thus, such RA messages are quite
small.
In the case when the landmark prefix is unknown to the responding In the case when the landmark prefix is unknown to the responding
router, the host will receive a "No" answer to its landmark question, router, the host will receive a "No" answer by non-inclusion of the
and also the information it needs to configure itself for the new landmark prefix in the RA, and also the information it needs to
link. The routers try to include as much information as possible in configure itself for the new link. The routers try to include as
such messages, so that the host can be informed of all the prefixes much information as possible in such messages, so that the host can
assigned to the new link as soon as possible. be informed of all the prefixes assigned to the new link as soon as
possible.
A second mechanism for reducing packet sizes applies to unsolicited A second mechanism for reducing packet sizes applies to unsolicited
Router Advertisements. By selecting one prefix on the link to be the Router Advertisements. By selecting the smallest prefix on the link
"link identifier", and making sure that it is included in every to be the "link identifier", and making sure that it is included in
advertisement, it is possible to omit some prefixes. Such every advertisement, it is possible to omit some prefixes. Such
advertisements will not inform a host of all of the prefixes at once, advertisements will not inform a host of all of the prefixes at once,
but in general these unsolicited advertisements will not be the first but in general these unsolicited advertisements will not be the first
advertisement received on a link. Inclusion of the link identifier advertisement received on a link. Inclusion of the smallest prefix
simply ensures that there is overlap in the information advertised by simply ensures that there is overlap in the information advertised by
each router on a link and that hosts will thus not incorrectly each router on a link and that hosts will thus not incorrectly
interpret one of these incomplete RAs as an indication of movement. interpret one of these incomplete RAs as an indication of movement.
Even though this document recommends the use of a prefix as the "link Even though this document recommends the use of a prefix as the "link
identifier", future specifications can use this option to support identifier", future specifications can use the Learned Prefix Option
non-prefix link identifiers. to include a non-prefix link identifier as long as this identifier is
128 bit long to avoid overlap with any currently assigned prefix.
Any future non-prefix link identifier MUST be 128 bits long.
The Router Advertisement messages are, in general, larger than the The Router Advertisement messages are, in general, larger than the
solicitations, and with multiple routers on the link there will be solicitations, and with multiple routers on the link there will be
multiple advertisements sent for each solicitation. This multiple advertisements sent for each solicitation. This
amplification can be used by an attacker to cause a Denial of Service amplification can be used by an attacker to cause a Denial of Service
attack. Such attacks are limited by applying a rate limit on the attack. Such attacks are limited by applying a rate limit on the
unicast Router Advertisements sent directly in response to each unicast Router Advertisements sent directly in response to each
solicitation, and using multicast RAs when the rate limit is solicitation, and using multicast RAs when the rate limit is
exceeded. exceeded.
skipping to change at page 11, line 46 skipping to change at page 10, line 42
Incomplete Prefix List, it will detect a link change. Hence an Incomplete Prefix List, it will detect a link change. Hence an
Incomplete Prefix List doesn't cause a connection disruption. But it Incomplete Prefix List doesn't cause a connection disruption. But it
may cause extra signaling messages, for example Binding Update may cause extra signaling messages, for example Binding Update
messages in [6] messages in [6]
The Superfluous Prefix List presents a more serious problem. The Superfluous Prefix List presents a more serious problem.
Without the assumed 'link UP' event notification from the link-layer, Without the assumed 'link UP' event notification from the link-layer,
the host can't perceive that it has changed its attachment point, the host can't perceive that it has changed its attachment point,
i.e. it has torn down an old link-layer connection and established a i.e. it has torn down an old link-layer connection and established a
new one. We further discuss the issues, should this assumption be new one.
removed, in Section 5.3.
With the assumed 'link UP' notification, and the assumption of With the assumed 'link UP' notification, and the assumption of
different concurrent layer 2 connections being represented as different concurrent layer 2 connections being represented as
different (virtual) interfaces to the DNA module the host will never different (virtual) interfaces to the DNA module the host will never
treat RAs from different links as being part of the same link. Hence treat RAs from different links as being part of the same link. Hence
it will not create a Superfluous Prefix List. it will not create a Superfluous Prefix List.
3.5 Tentative Source Link-Layer Address option (TO) 3.5 Tentative Source Link-Layer Address option (TO)
DNAv6 protocol requires the host to switch its IPv6 addresses to DNAv6 protocol requires the host to switch its IPv6 addresses to
skipping to change at page 14, line 4 skipping to change at page 12, line 43
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.
4.2 Prefix Information Option LinkID Bit
DNAv6 modifies the format of the Prefix Information Option by
defining a 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. The reserved field is reduced from 3 bits to 1 bit.
4.3 Landmark Option 4.2 Landmark Option
The Landmark Option is used by hosts in a Router Solicitation message The Landmark Option is used by hosts in a Router Solicitation message
to ask the routers on a link if the specified prefix is being to ask the routers on a link if the specified prefix is being
advertised by some router on the link. It is used by routers in a advertised by some router on the link. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pref Length |Y|N| | | Type | Length | Pref Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Landmark Prefix ~ ~ Landmark Prefix ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBA TBA
skipping to change at page 15, line 33 skipping to change at page 13, line 34
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. Set to 2 or 3. units of 8 octets. Set to 2 or 3.
Pref Length Pref Length
An 8 bit unsigned integer representing the number of bits in the An 8 bit unsigned integer representing the number of bits in the
prefix to be used for matching. prefix to be used for matching.
Yes (Y)
The Yes (Y) bit, when included in a Landmark Option in a Router
Advertisement, indicates that the prefix referred to in the Prefix
field of this option is being advertised by one or more routers on
the current link. In a Landmark Option in a Router Solicitation,
this bit MUST be set to zero and ignored by receivers.
No (N)
The No (N) bit, when included in a Landmark Option in a Router
Advertisement, indicates that the prefix referred to in the Prefix
field of this option is not being advertised by any router on the
current link. In a Landmark Option in a Router Solicitation, this
bit MUST be set to zero and ignored by receivers.
Reserved Reserved
A 38 bit unused field. It MUST be initialised to zero by the A 38 bit unused field. It MUST be initialised to zero by the
sender, and ignored by the receiver. sender, and ignored by the receiver.
Prefix Prefix
A prefix being used by the host currently for a global IPv6 A prefix being used by the host currently for a global IPv6
address, padded at the right with zeros. If the prefix length is address, padded at the right with zeros. If the prefix length is
less than 65 bits, only 64 bits need be included, otherwise 128 less than 65 bits, only 64 bits need be included, otherwise 128
bits are included. bits are included.
4.4 Learned Prefix Option 4.3 Learned Prefix Option
The Learned Prefix Option (LPO) is used by a router to indicate The Learned Prefix Option (LPO) is used by a router to indicate
prefixes that are being advertised in PIOs by other routers on the prefixes that are being advertised 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 |I| Reserved | Prefix Len 1 | | Type | Length | Reserved | Prefix Len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Prefix Len N | Padding | | ... | Prefix Len N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Prefix 1 + + Prefix 1 +
| | | |
+ + + +
| | | |
skipping to change at page 17, line 48 skipping to change at page 15, line 5
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
skipping to change at page 18, line 34 skipping to change at page 15, line 32
explicitly configured on this router. explicitly configured on this router.
Description Description
This option MUST only be included in a Router Advertisement. This This option MUST only be included in a Router Advertisement. This
option contains prefixes that are beingF advertised on the link option contains prefixes that are beingF advertised on the link
but are not explicitly configured on the sending router. The but are not explicitly configured on the sending router. The
router MUST NOT include any prefixes with a zero valid lifetime in router MUST NOT include any prefixes with a zero valid lifetime in
the LPO. the LPO.
4.5 Tentative option 4.4 Tentative option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ... | Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD (Requires IANA Allocation) suggest 17 (0x11) TBD (Requires IANA Allocation) suggest 17 (0x11)
skipping to change at page 19, line 38 skipping to change at page 16, line 34
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 4.4) Advertisements. Prefixes in Learned Prefix Options (see Section 4.3)
MUST NOT update the contents of DNARouterPrefixList. For each prefix MUST NOT update the contents of 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 20, line 4 skipping to change at page 16, line 45
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
4. Expiry time 4. Expiry time
The expiry time for entries in DNARouterPrefixList is 1.5 hours The expiry time for entries in DNARouterPrefixList is 3 times maximum
(three times the maximum value of the Router Advertisement interval) of MaxRtrAdvInterval after the last received Router Advertisement
after the last received Router Advertisement affecting the entry, or affecting the entry, or the scheduled expiry of the prefix valid
the scheduled expiry of the prefix valid lifetime, whichever is 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 FastRA 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 3 times maximum of
last received Router Advertisement affecting the entry. MaxRtrAdvInterval after the last received Router Advertisement
affecting the entry.
5.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
skipping to change at page 23, line 6 skipping to change at page 19, line 46
o The source address of the Router Solicitation is NOT the o The source address of the Router Solicitation is NOT the
unspecified address (::). unspecified address (::).
If a unicast response is possible and the Router Solicitation If a unicast response is possible and the Router Solicitation
contains a Landmark Option whose prefix is included in contains a Landmark Option whose prefix is included in
DNARouterPrefixList or AdvPrefixList, the router SHOULD send an DNARouterPrefixList or AdvPrefixList, the router SHOULD send an
abbreviated Router Advertisement. abbreviated Router Advertisement.
This abbreviated advertisement includes only the Landmark Option, This abbreviated advertisement includes only the Landmark Option,
with the "Y" flag set, plus the base RA header and any SEND options plus the base RA header and any SEND options as appropriate. The
as appropriate. The FastRA flag MUST be set. The Complete flag MUST FastRA flag MUST be set. The Complete flag MUST NOT be set. This is
NOT be set. This is the one exception where the LinkID MAY be the one exception where the smallest prefix MAY be omitted as the
omitted as the Y flag implies that link change has not occured and landmark option implies that link change has not occured and that the
that the previously received LinkID is still current. previously received smallest prefix is still current.
If there is NO Landmark Option in the received Router Solicitation or If there is NO Landmark Option in the received Router Solicitation or
it contains a Landmark Option whose prefix is NOT included in it contains a Landmark Option whose prefix is NOT included in
DNARouterPrefixList or AdvPrefixList or a unicast response is not DNARouterPrefixList or AdvPrefixList or a unicast response is not
possible, then the router SHOULD generate a Complete RA as specified possible, then the router SHOULD generate a Complete RA as specified
in Section 5.1.6. The Router Advertisement MUST include the LinkID, in Section 5.1.6. The Router Advertisement MUST include the smallest
as described in Section 5.1.7. prefix(es), as described in Section 5.1.7.
If a unicast response is possible, then a token is removed and the If a unicast response is possible, then a token is removed and the
Router Advertisement is scheduled for transmission as specified in Router Advertisement is scheduled for transmission as specified in
Section 5.1.8. Section 5.1.8.
If a unicast response is not possible and there is no multicast RA If a unicast response is not possible and there is no multicast RA
already scheduled for transmission in the next MulticastRADelay the already scheduled for transmission in the next MulticastRADelay the
RA MUST be sent to the link-scoped all-nodes multicast address at the RA MUST be sent to the link-scoped all-nodes multicast address at the
current time plus MulticastRADelay. current time plus MulticastRADelay.
If a unicast response is not possible but there is a multicast RA If a unicast response is not possible but there is a multicast RA
already scheduled for transmission in the next MulticastRADelay, then already scheduled for transmission in the next MulticastRADelay, then
the Router Solicitation MUST be silently discarded. the Router Solicitation MUST be silently discarded.
All Router Advertisements sent by a DNA router MUST have the "F" flag
set so that hosts processing them know that they can count on the
content being interpretable according to this specification.
5.1.6 Complete Router Advertisements 5.1.6 Complete Router Advertisements
A CompleteRA is formed as follows: A CompleteRA is formed as follows:
Starting with a Router Advertisement with all fixed options (MTU, Starting with a Router Advertisement with all fixed options (MTU,
Advertisement Interval, flags, etc.), the FastRA flag is set. As Advertisement Interval, flags, etc.), the FastRA flag is set. As
many Prefix Information Options for explicitly configured prefixes as many Prefix Information Options for explicitly configured prefixes as
will fit are added to the Router Advertisement. If there is will fit are added to the Router Advertisement. If there is
sufficient room, a Learned Prefix Option as defined in Section 4.4 sufficient room, a Learned Prefix Option as defined in Section 4.3
containing as many of the learned prefixes as will fit is added. containing as many of the learned prefixes as will fit is added.
It may not be possible to include all of the prefixes in use on the It may not be possible to include all of the prefixes in use on the
link due to MTU or administrative limitations. If all Prefix link due to MTU or administrative limitations. If all Prefix
Information Options and a Learned Prefix Option containing all of the Information Options and a Learned Prefix Option containing all of the
learned prefixes were included in the RA, then the Complete flag in learned prefixes were included in the RA, then the Complete flag in
the Router Advertisement header is set. the Router Advertisement header is set.
If it is not possible to generate a Complete RA but the Router If there are known to be prefixes that are not included in the Router
Solicitation that this Router Advertisement is in response to, if Advertisement, then the Complete flag MUST NOT be set.
any, includes a Landmark Option containing a prefix that is not in
the router's DNARouterPrefixList and not in the router's
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 MUST be included. into an RA, the smallest prefix(es) MUST be included.
5.1.7 LinkID
One of the prefixes in use on a link is chosen to be the LinkID. 5.1.7 Inclusion of smallest prefixes
The LinkID is the numerically smallest prefix stored in either of The numerically smallest prefix stored in either of
DNARouterPrefixList or AdvPrefixList whose lifetime is greater than DNARouterPrefixList or AdvPrefixList whose lifetime is greater than 3
1.5 hours. For comparing prefixes, they are padded to the right with times maximum of MaxRtrAdvInterval is selected as the conceptual
zeros to make them 128 bit unsigned integers. "link identifier". For comparing prefixes, they are padded to the
right with zeros to make them 128 bit unsigned integers.
The prefix may be included in the RA in either a PIO or LPO as The prefix may be included in the RA in either a PIO or LPO as
appropriate. If the prefix is included in a PIO, then the "I" flag appropriate. Even when stateful address configuration (DHCPv6) is
in that PIO MUST be set. If the prefix is included in an LPO, then used, the routers MUST be configured with one prefix, so that the
the prefix MUST be placed in the first prefix field in the LPO, and smallest prefix can be included in the RA messages. Note that this
the LPO "I" flag MUST be set. smallest prefix is the smallest of all the prefixes configured on the
routers on the link and may not be the smallest prefix used in the
link through stateful address configuration.
5.1.7.1 Changing the LinkID 5.1.7.1 Changing the smallest prefix
When either a new prefix is added to a link that is numerically When either a new prefix is added to a link that is numerically
smaller than all those previously advertised or the lifetime of the smaller than all those previously advertised or the lifetime of the
prefix that is currently being used as the LinkID falls below 1.5 prefix that is currently being used as the "link identifier" falls
hours, a new LinkID is determined. In order to ensure that there is below 3 times maximum of MaxRtrAdvInterval, a new "link identifier"
overlap between consecutive RAs on the link, the old LinkID must is determined. In order to ensure that there is overlap between
continue to be advertised for some time alongside the new LinkID. consecutive RAs on the link, the old smallest prefix must continue to
be advertised for some time alongside the new smallest prefix.
For the purposes of propagating information, it is assumed that after For the purposes of propagating information, it is assumed that after
three advertisements of a change, all routers have been made aware of three advertisements of a change, all routers have been made aware of
the change. the change.
If the instant that a router sends its first unsolicited If the instant that a router sends its first unsolicited
advertisement is time T, then by T + 1 hour at least three such advertisement is time T, then by T + 1 hour at least three such
advertisements will have been made and all routers can be assumed to advertisements will have been made and all routers can be assumed to
have received it. Thus by time T + 1.5 hours, all routers on the have received it. Thus by time T + 3 times maximum of
link should have also sent at least one advertisement with the new MaxRtrAdvInterval, all routers on the link should have also sent at
LinkID. least one advertisement with the new smallest prefix list.
1.5 hours after first sending an advertisement with a new LinkID it 3 times maximum of MaxRtrAdvInterval after first sending an
is safe to consider the old LinkID gone and omit the corresponding advertisement with a new smallest prefix it is safe to consider the
prefix from RAs if desired. old smallest prefix gone and omit the corresponding prefix from RAs
if desired.
Following a change of LinkID, the old LinkID MUST be included in RAs Following a change of smallest prefix, the old smallest prefix MUST
for the following 1.5 hours. be included in RAs for the following 3 times maximum of
MaxRtrAdvInterval.
5.1.7.1.1 Non-Prefix LinkIDs 5.1.7.1.1 Non-Prefix link identifiers
Although this memo only discusses LinkIDs that are prefixes, a future Although this memo only discusses the use of prefixes as "link
specification or ammendment may describe a mechanism to select a identifier", a future specification or ammendment may describe a
LinkID that is not a prefix. mechanism to select a "link identifier" that is not a prefix.
Information from the Learned Prefix Option is only stored in Information from the Learned Prefix Option is only stored in
DNAHostPrefixList, and is only used for DNA purposes. Because a DNAHostPrefixList, and is only used for DNA purposes. Because a
length field is used, it is possible to carry any variable length length field is used, it is possible to carry any variable length
identifier less than or equal to 128 bits in an LPO and store it in identifier less than or equal to 128 bits in an LPO and store it in
DNAHostPrefixList (Section 5.2.1). DNAHostPrefixList (Section 5.2.1). To avoid any collision to
prefixes, an future non-prefix link identifier MUST be 128 bits long
and can be included in the LPO of a RA message.
Following a change of LinkID, the old LinkID MUST be included in RAs Following a change of link identifier, the old link identifier MUST
in an LPO for the following 1.5 hours. be included in RAs in an LPO for the following 3 times maximum of
MaxRtrAdvInterval.
Future specifications MUST NOT treat the information in an LPO as Future specifications MUST NOT treat the information in an LPO as
prefixes such as they would the prefixes found in a Prefix prefixes such as they would the prefixes found in a Prefix
Information Option. Future specifications MUST NOT assume that the Information Option. Future specifications MUST NOT assume that the
entries in a host's DNAHostPrefixList are actual prefixes in use on entries in a host's DNAHostPrefixList are actual prefixes in use on
the link. the link.
5.1.8 Scheduling Fast Router Advertisements 5.1.8 Scheduling Fast Router Advertisements
RAs may need to be delayed to avoid collisions in the case that there RAs may need to be delayed to avoid collisions in the case that there
skipping to change at page 26, line 16 skipping to change at page 23, line 17
Complete RA, if it is not one already, and scheduled for multicast Complete RA, if it is not one already, and scheduled for multicast
transmission as in RFC 2461. transmission as in RFC 2461.
5.1.9 Scheduling Unsolicited Router Advertisements 5.1.9 Scheduling Unsolicited Router Advertisements
Unsolicited router advertisements MUST be scheduled as per RFC 2461. Unsolicited router advertisements MUST be scheduled as per RFC 2461.
The "F" flag in the RA header MUST be set. The "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. configured prefixes, but MUST include the smallest prefix.
This ensures that there will be overlap in the sets of prefixes This ensures that there will be overlap in the sets of prefixes
contained in consecutive RAs on a link from DNA routers, and thus an contained in consecutive RAs on a link from DNA routers, and thus an
absence of that overlap can be used to infer link change. absence of that overlap can be used to infer link change.
5.1.10 Removing a Prefix from an Interface 5.1.10 Removing a Prefix from an Interface
When a prefix is to stop being advertised in a PIO in RAs by an When a prefix is to stop being advertised in a PIO in RAs by an
interface before the expiry of the prefix's valid lifetime, then the interface before the expiry of the prefix's valid lifetime, then the
router should treat it as though it has just learned a prefix that is router should treat it as though it has just learned a prefix that is
not explicitly configured on it. After sending the last RA not explicitly configured on it. After sending the last RA
containing the prefix in a PIO, the router MUST add the prefix to the containing the prefix in a PIO, the router MUST add the prefix to the
DNARouterPrefixList and set it to expire in 1.5 hours or at the DNARouterPrefixList and set it to expire in 3 times maximum of
expiry of the last advertised valid lifetime, whichever is earlier. MaxRtrAdvInterval or at the expiry of the last advertised valid
This ensures that to hosts there will be overlap in the prefixes in lifetime, whichever is earlier. This ensures that to hosts there
the RAs they see and prevent them from incorrectly interpreting will be overlap in the prefixes in the RAs they see and prevent them
changed prefixes as movement. from incorrectly interpreting changed prefixes as movement.
5.1.10.1 Early Removal of the LinkID Prefix 5.1.10.1 Early Removal of the smallest Prefix
If the LinkID prefix is to be withdrawn early from a link, that is If the smallest prefix is to be withdrawn early from a link, that is
before the expiry of its previously advertised valid lifetime, it before the expiry of its previously advertised valid lifetime, it
MUST be advertised for at least 1.5 hours with a valid lifetime of MUST be advertised for at least 3 times maximum of MaxRtrAdvInterval
less than 1.5 hours. This ensures that all of the other routers are with a valid lifetime of less than 3 times maximum of
notified to begin the process of changing the LinkID as well, and MaxRtrAdvInterval. This ensures that all of the other routers are
hosts will always see overlap between the prefixes in consecutive RAs notified to begin the process of changing the smallest prefix as
and thus not mistake an RA for an indication of link change. well, and hosts will always see overlap between the prefixes in
consecutive RAs and thus not mistake an RA for an indication of link
change.
5.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 3 times maximum of MaxRtrAdvInterval may be reassigned
after expiry. If a prefix is withdrawn from a link without counting to another link immediately after expiry. If a prefix is withdrawn
down to the expiry of its valid lifetime, it SHOULD NOT be reassigned from a link without counting down to the expiry of its valid
to another link for at least 1.5 hours or until the original expiry lifetime, it SHOULD NOT be reassigned to another link for at least 3
time, whichever is earlier. This gives sufficient time for other times maximum of MaxRtrAdvInterval or until the original expiry time,
routers that have learned the prefix to expire it, and for hosts that whichever is earlier. This gives sufficient time for other routers
have seen advertisements from those routers to expire the prefix as that have learned the prefix to expire it, and for hosts that have
well. seen advertisements from those routers to expire the prefix as well.
Earlier reassignment may result in hosts that move from between the Earlier reassignment may result in hosts that move from between the
old and new links failing to detect the movement. old and new links failing to detect the movement.
When the host is sure that the prefix list is complete, a false When the host is sure that the prefix list is complete, a false
movement assumption may happen due to renumbering when a new prefix movement assumption may happen due to renumbering when a new prefix
is introduced in RAs at about the same time as the host handles the is introduced in RAs at about the same time as the host handles the
'link UP' event. We may solve the renumbering problem with minor 'link UP' event. We may solve the renumbering problem with minor
modification like below. modification like below.
skipping to change at page 27, line 46 skipping to change at page 25, line 4
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
2. Prefix length 2. Prefix length
3. Expiry time 3. Expiry time
If a host is not able to store this information for every prefix, If a host is not able to store this information for every prefix,
there is a risk that the host will incorrectly decide that it has there is a risk that the host will incorrectly decide that it has
moved to a new link, when it receives advertisements from a non-DNA moved to a new link, when it receives advertisements from a non-DNA
router. router.
Prefix entries in the DNAHostPrefixList expire and MUST be removed Prefix entries in the DNAHostPrefixList expire and MUST be removed 3
1.5 hours after they are last seen in a received Router Advertisement times maximum of MaxRtrAdvInterval after they are last seen in a
(in either a PIO or LPO) or at the expiry of the valid lifetime of received Router Advertisement (in either a PIO or LPO) or at the
the prefix, whichever is earlier. expiry of the valid lifetime of the prefix, whichever is earlier.
Hosts MUST also maintain a list of all LinkIDs seen on the current
Link. This list will be referred to as "DNAHostLinkIDList". This
list is identical in structure to DNAHostPrefixList but contains
LinkIDs instead of prefixes.
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 Host MUST also maintain a boolean flag, DNARAReceivedFlag, indicating
DNAHostPrefixList. whether or not the host received a DNA RA message (RA message with
the "F" flag set) on this link. This value is initialized to zero
everytime a link change happens and is set to 1 when the first DNA RA
message is received.
Hosts SHOULD also maintain a "Landmark Prefix" as described in Hosts SHOULD also maintain a "Landmark Prefix" as described in
Section 5.2.5. Section 5.2.4.
5.2.2 Host Configuration Variables 5.2.2 Host Configuration Variables
Hosts MUST make use of the following conceptual variables and they Hosts MUST make use of the following conceptual variables and they
SHOULD be configurable: SHOULD be configurable:
DNASameLinkDADFlag DNASameLinkDADFlag
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
NumRSRAComplete
Number of RS/RA exchange messages necessary to declare the prefix
list to be complete.
Default: 1
MinRAWait
Minimum time the host will have to wait before assuming receipt of
all possible RAs.
Default: 4 seconds
MaxCacheTime
[Editor's note: Do we want to keep this and the associated
Section 5.2.4?] Maximum time for which link information can be
stored in the hosts.
Default: 30 mins
5.2.3 Detecting Network Attachment Steps 5.2.3 Detecting Network Attachment Steps
An IPv6 host SHOULD follow the following steps when they receive a An IPv6 host SHOULD follow the following steps when they receive a
hint (see also Section 7) indicating the possibility of link change. hint indicating the possibility of link change.
[Editor's note: Check if DNA steps are correct]
1. Try making use of prior information stored related to the links
the host visited in the past (see Section 5.2.4).
If the prior information implies no link change, the host MAY
conduct reachability detection (see Section 5.2.7.4) to one
of the default routers it is using, otherwise no action is
needed.
If the prior information implies that there is a link change
or there is no useful prior information available, follow the
procedure below.
2. Mark all the IPv6 addresses in use as optimistic. 1. Mark all the IPv6 addresses in use as optimistic.
3. Set all Neighbor Cache entries for routers on its Default Router 2. Set all Neighbor Cache entries for routers on its Default Router
List to STALE. List to STALE.
4. Send router solicitation. (See Section 5.2.6). 3. Send router solicitation. (See Section 5.2.5).
5. Receive router advertisement(s). 4. Receive router advertisement(s).
6. Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add 5. Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add
a Neighbor Cache Entry in the REACHABLE state if one does not a Neighbor Cache Entry in the REACHABLE state if one does not
currently exist. currently exist.
7. Process received router advertisement. (See Section 5.2.7). 6. Process received router advertisement. (See Section 5.2.6).
8. If the link has changed 7. If the link has changed
Change the IP configuration parameters of the host (see Change the IP configuration parameters of the host (see
Section 5.2.8). Section 5.2.7).
9. If the link has NOT changed 8. If the link has NOT changed
Restore the address configuration state of all the IPv6 Restore the address configuration state of all the IPv6
addresses known to be on the link. addresses known to be on the link.
10. Update default routers list and their reachability information 9. Update default routers list and their reachability information
(see Section 5.2.7.4). (see Section 5.2.6.3).
5.2.4 Making use of Prior Information
A device that has recently been attached to a particular wireless
base station may still have state regarding the IP configuration
valid for use on that link. This allows a host to begin any
configuration procedures before checking the ongoing validity and
security of the parameters.
The experimental protocols CARD [13] and FMIPv6 [14] each provide
ways to generate such information using network-layer signaling,
before arrival on a link. Additionally, the issue is the same when a
host disconnects from one cell and returns to it immediately, or
movement occurs between a pair of cells (the ping-pong effect).
A IP host MAY store L2 to L3 mapping information for the links for a
period of time in order to use the information in the future. When a
host attaches itself to a point-of-attachment for which it has an L2
to L3 mapping, if the stored record doesn't contain the prefix the
host is using, the host SHOULD conclude that it has changed link and
initiate a new configuration procedure.
If the host finds the prefix it is using in the stored record, a host
MAY conclude that it is on the same link, but SHOULD undertake
reachability testing as described in Section 5.2.7.4. In this case,
the host MUST undertake Duplicate Address Detection [7][5] to confirm
that there are no duplicate addresses on the link.
The host MUST age this cached information based on the possibility
that the link's configuration has changed and MUST NOT store
information beyond either the remaining router or address lifetime or
(at the outside) MaxCacheTime time-units.
5.2.5 Selection of a Landmark Prefix 5.2.4 Selection of a Landmark Prefix
For each interface, hosts SHOULD choose a prefix to use as a Landmark For each interface, hosts SHOULD choose a prefix to use as a Landmark
Prefix in Router Solicitations. The following rules are used in Prefix in Router Solicitations. The following rules are used in
selecting the landmark prefix: selecting the landmark prefix:
The prefix MUST have a non-zero valid lifetime. If the valid The prefix MUST have a non-zero valid lifetime. If the valid
lifetime of a previously selected Landmark Prefix expires, a new lifetime of a previously selected Landmark Prefix expires, a new
Landmark Prefix MUST be selected. Landmark Prefix MUST be selected.
The prefix MUST be one of those that the hosts has used to assign The prefix MUST be one of those that the hosts has used to assign
a non-link-local address to itself a non-link-local address to itself
The prefix SHOULD be chosen as the one with the longest preferred The prefix SHOULD be chosen as the one with the longest preferred
lifetime, but it is not necessary to switch to different prefix if lifetime, but it is not necessary to switch to different prefix if
the preferred lifetime of the current landmark prefix changes. the preferred lifetime of the current landmark prefix changes.
5.2.6 Sending Router Solicitations 5.2.5 Sending Router Solicitations
Upon the occurrence of a Layer 2 link-up event notification, hosts Upon the occurrence of a Layer 2 link-up event notification, hosts
SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting
and/or hysteresis to this behaviour as appropriate to the link and/or hysteresis to this behaviour as appropriate to the link
technology subject to the reliability of the hints. technology subject to the reliability of the hints.
When the host receives a link UP notification from its link layer, it When the host receives a link UP notification from its link layer, it
sets time_last_linkUP_received to the current time. sets time_last_linkUP_received to the current time.
The host also uses this to trigger sending an RS, subject to the rate The host also uses this to trigger sending an RS, subject to the rate
skipping to change at page 31, line 49 skipping to change at page 27, line 28
spaced RTR_SOLICITATION_INTERVAL apart. spaced RTR_SOLICITATION_INTERVAL apart.
Note that if link-layer notifications are reliable, a host can reset Note that if link-layer notifications are reliable, a host can reset
the number of sent Router Solicitations to 0, while still maintaining the number of sent Router Solicitations to 0, while still maintaining
RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is
necessary so that after each link up notification, the host is necessary so that after each link up notification, the host is
allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, allowed to send MAX_RTR_SOLICITATIONS to reliably discover the,
possibly new, prefix list. possibly new, prefix list.
Hosts SHOULD include a Landmark Option (LO) in the RS message with Hosts SHOULD include a Landmark Option (LO) in the RS message with
the landmark prefix chosen based on the rules in Section 5.2.5. the landmark prefix chosen based on the rules in Section 5.2.4.
Hosts SHOULD include a tentative source link layer address option Hosts SHOULD include a tentative source link layer address option
(TO) in the RS message Section 6. The router solicitation message is (TO) in the RS message Section 5.3. The router solicitation message
sent to the All_Routers_Multicast address and the source address MUST is sent to the All_Routers_Multicast address and the source address
be the link local address of the host. MUST be the link local address of the host.
The host MUST consider its link local address to be in the The host MUST consider its link local address to be in the
"Optimistic" state for duplicate address detection [5] until either "Optimistic" state for duplicate address detection [5] until either
the returned RA confirms that the host has not switched to a new link the returned RA confirms that the host has not switched to a new link
or, if an link change has occurred, the host has performed optimistic or, if an link change has occurred, the host has performed optimistic
duplicate address detection for the address. duplicate address detection for the address.
5.2.7 Processing Router Advertisements 5.2.6 Processing Router Advertisements
When the host receives a Router Advertisement, the host checks for When the host receives a Router Advertisement, the host checks for
the following conditions in the given order and derives the the following conditions in the given order and derives the
associated conclusions given below [Editor's note: Review and make associated conclusions given below:
sure that there are no corner cases]:
If the RA contains a Landmark Option that matches the Landmark If the RA contains a Landmark Option that matches the Landmark
Option in the last transmitted Router Solicitation, and the 'Y' Option in the last transmitted Router Solicitation then that
bit is set then that indicates that no link change has occurred indicates that no link change has occurred and current
and current configuration can be assumed to still be 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 includes a prefix that matches an entry in If the RA includes a prefix that matches an entry in
DNAHostPrefixList, then the host can conclude that no link change DNAHostPrefixList, then the host can conclude that no link change
has occurred and the current configuration can be assumed to still has occurred and the current configuration can be assumed to still
be current. be current.
If the RA is a Complete RA, as indicated by the "Complete" flag in If the RA is a Complete RA, as indicated by the "Complete" flag in
the RA header, and there are no prefixes included in it in either the RA header, and there are no prefixes included in it in either
a PIO or LPO that are also in the host's DNAHostPrefixList, then a PIO or LPO that are also in the host's DNAHostPrefixList, then
the host can conclude that it has changed link and SHOULD initiate the host can conclude that it has changed link and SHOULD initiate
re-configuration using the information in the received Router re-configuration using the information in the received Router
Advertisement. Advertisement.
If the RA is not a CompleteRA and includes a LinkID that is not in If the RA is a DNA RA, as indicated by the "F" flag set in the RA
DNAHostLinkIDList and no prefixes that match entries in header, previously a DNA RA was received on this link as indicated
by the DNARAReceivedFlag being set to 1, and there are no prefixes
included in it in either a PIO or LPO that are also in the host's
DNAHostPrefixList, then the host can conclude that it has changed DNAHostPrefixList, then the host can conclude that it has changed
link and SHOULD initiate re-configuration using the information in link and SHOULD initiate re-configuration using the information in
the received Router Advertisement. the received Router Advertisement.
If the host has the complete prefix list (CPL) and the RA does NOT If the host has the complete prefix list (CPL) and the RA does NOT
include any prefixes in either a PIO or LPO that matches a prefix include any prefixes in either a PIO or LPO that matches a prefix
in CPL then the host can conclude that link change has occurred in CPL then the host can conclude that link change has occurred
and use the information in the received RA to configure itself. and use the information in the received RA to configure itself.
If the host doesn't have the complete prefix list (CPL), the If the host doesn't have the complete prefix list (CPL), the
received RA is not complete, contains no prefixes that are stored received RA is not complete, contains no prefixes that are stored
in DNAHostPrefixList, does not contain a Landmark Option that in DNAHostPrefixList, does not contain a Landmark Option that
matches a corresponding option in the most recent RS and contains matches a corresponding option in the most recent RS, then the
no LinkID, then the host SHOULD send RS/RA exchange until host SHOULD send RS/RA exchange until num_RS_RA is equal to
num_RS_RA is equal to NumRSRAComplete to create a new CPL and NumRSRAComplete to create a new CPL and compare it with the
compare it with the already known prefixes. If after already known prefixes. If after NumRSRAComplete exchanges still
NumRSRAComplete exchanges still no prefix received in either a PIO no prefix received in either a PIO or LPO of the RAs match known
or LPO of the RAs match known prefixes, the host MUST conclude prefixes, the host MUST conclude link change. If a matching
link change. If a matching prefix is received in the RAs, then prefix is received in the RAs, then the host MUST conclude that no
the host MUST conclude that no link change has occured. link change has occured.
5.2.7.1 Pseudocode 5.2.6.1 Pseudocode
IF (Received RA contains Landmark that matches the Landmark option in IF (Received RA contains Landmark that matches the Landmark option in
the last transmitted RS AND Landmark 'Y' bit is set) THEN the last transmitted RS) THEN
{ {
No-link change has occured No-link change has occured
RETURN; // Don't have to do the following checks.
}
IF (Received RA contains LinkID AND LinkID matches an entry in
DNAHostLinkIDList) THEN
{
No-link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
IF (Receive RA contains a prefix matching a prefix in IF (Receive RA contains a prefix matching a prefix in
DNAHostPrefixList) THEN DNAHostPrefixList) THEN
{ {
No link change has occured. No link change has occured.
skipping to change at page 34, line 20 skipping to change at page 29, line 32
/* We already checked if there are any matching prefix before. /* We already checked if there are any matching prefix before.
Since this is a CompleteRA, implies link-change.*/ Since this is a CompleteRA, implies link-change.*/
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
IF (Received RA contains LinkID AND LinkID matches none of the IF (Receive RA is a DNA RA) THEN
entries in DNAHostLinkIDList) THEN
{
/* We already checked if there are any matching prefix before.
Since this is a DNA RA, Check if previous DNA RA was received.*/
IF (DNARAReceivedFlag is set) THEN
/* If we previously received a DNA RA and don't see an overlap in
the prefix list - the smallest prefix is different on this link -
that means link change */
{ {
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
}
IF (DNAHostPrefixList is marked as complete (i.e. the completeness IF (DNAHostPrefixList is marked as complete (i.e. the completeness
criteria is already met)) THEN criteria is already met)) THEN
{ {
/* We already checked if there are any matching prefix before. /* We already checked if there are any matching prefix before.
Since the DNAHostPrefixList is complete, implies link-change.*/ Since the DNAHostPrefixList is complete, implies link-change.*/
Link change has occured. Link change has occured.
skipping to change at page 35, line 5 skipping to change at page 30, line 27
} }
Wait for NumRSRAComplete exchanges of RS/RA message to be done since Wait for NumRSRAComplete exchanges of RS/RA message to be done since
the previous link_up event. the previous link_up event.
IF (One of the received RA contains a prefix matching a prefix in IF (One of the received RA contains a prefix matching a prefix in
DNAHostPrefixList from before link UP event), THEN No link change has DNAHostPrefixList from before link UP event), THEN No link change has
occured ELSE link change has occured. occured ELSE link change has occured.
5.2.7.2 Maintaining the DNAHostPrefixList 5.2.6.2 Maintaining the DNAHostPrefixList
If a Router Advertisement does not indicate a link change, the host If a Router Advertisement does not indicate a link change, the host
updates its DNAHostPrefixList, adding any new prefixes if necessary. updates its DNAHostPrefixList, adding any new prefixes if necessary.
If the Router Advertisement has the C flag set, then the host SHOULD If the Router Advertisement has the C flag set, then the host SHOULD
make the DNAHostPrefixList match the contents of the advertisement make the DNAHostPrefixList match the contents of the advertisement
and mark it as complete (i.e. it becomes CPL). Any new prefixes are and mark it as complete (i.e. it becomes CPL). Any new prefixes are
added and any prefixes in the list that are absent in the added and any prefixes in the list that are absent in the
advertisement are removed. Expiry times on prefixes are updated if advertisement are removed. Expiry times on prefixes are updated if
the prefix was contained in a PIO, but not if it was contained in an the prefix was contained in a PIO, but not if it was contained in an
skipping to change at page 36, line 24 skipping to change at page 31, line 47
link UP notification, i.e. moves to another PoA. Even if the host link UP notification, i.e. moves to another PoA. Even if the host
moves to another PoA with Incomplete Prefix List,but if it has not moves to another PoA with Incomplete Prefix List,but if it has not
changed link, there is good chance that the first RA may contain a changed link, there is good chance that the first RA may contain a
prefix from its (incomplete) prefix list. Considering all those prefix from its (incomplete) prefix list. Considering all those
above, even if the host performs only one RS/ RA exchange, it will be above, even if the host performs only one RS/ RA exchange, it will be
rather rare for the host to falsely assume a link change. Moreover, rather rare for the host to falsely assume a link change. Moreover,
even in case of false detection, there would be no connectivity even in case of false detection, there would be no connectivity
disruption, because Incomplete Prefix List causes only additional disruption, because Incomplete Prefix List causes only additional
signaling. signaling.
5.2.7.2.1 Merging DNAHostPrefixList 5.2.6.2.1 Merging DNAHostPrefixList
When a host has been collecting information about a potentially When a host has been collecting information about a potentially
different link in its Current DNAHostPrefixList, and it discovers different link in its Current DNAHostPrefixList, and it discovers
that it is in fact the same link as another DNAHostPrefixList, then that it is in fact the same link as another DNAHostPrefixList, then
it needs to merge the information in the two objects to produce a it needs to merge the information in the two objects to produce a
single new object. Since the DNAHostPrefixList contains the most single new object. Since the DNAHostPrefixList contains the most
recent information, any information contained in it will override the recent information, any information contained in it will override the
information in the old DNAHostPrefixList, for example the remaining information in the old DNAHostPrefixList, for example the remaining
lifetimes for the prefixes. When the two objects contain different lifetimes for the prefixes. When the two objects contain different
pieces of information, for instance different prefixes or default pieces of information, for instance different prefixes or default
routers, the union of these are used in the resulting merged object. routers, the union of these are used in the resulting merged object.
5.2.7.3 Maintaining DNAHostLinkIDList 5.2.6.3 Router Reachability Detection and Default Router Selection
If a Router Advertisement does not indicate a link change, the host
updates its DNAHostLinkIDList, adding any new LinkIDs if necessary.
If the link has changed, the DNAHostLinkIDList MUST be updated with
the ONLY the linkIDs from the router advertisment.[Editor's note: Do
we have say something about storing old LinkID list as prior
information for future use].
5.2.7.4 Router Reachability Detection and Default Router Selection
The receipt of a unicast RA from a router in response to a multicast The receipt of a unicast RA from a router in response to a multicast
RS indicates that the host has bi-directional reachability with the RS indicates that the host has bi-directional reachability with the
routers that responded. Such reachability is necessary for the host routers that responded. Such reachability is necessary for the host
to use a router as a default router, in order to have packets routed to use a router as a default router, in order to have packets routed
off the host's current link. It is notable that the choice of off the host's current link. It is notable that the choice of
whether the messages are addressed to multicast or unicast address whether the messages are addressed to multicast or unicast address
will have different reachability implications. The reachability will have different reachability implications. The reachability
implications from the hosts' perspective for the four different implications from the hosts' perspective for the four different
message exchanges defined by RFC 2461 [3] are presented in the table message exchanges defined by RFC 2461 [3] are presented in the table
skipping to change at page 38, line 12 skipping to change at page 33, line 25
new IP link, since changes in router reachability are possible on new IP link, since changes in router reachability are possible on
some link types even if the host remains on the same IP link. some link types even if the host remains on the same IP link.
Note that this procedure does not prevent a MN from sending packets Note that this procedure does not prevent a MN from sending packets
to its current default router while the RA solicitation is in to its current default router while the RA solicitation is in
progress and if reachability with the current default router is progress and if reachability with the current default router is
unchanged, there should be no change in default router after the RA unchanged, there should be no change in default router after the RA
solicitation completes. If the current default router is still solicitation completes. If the current default router is still
reachable, it will forward the packets. reachable, it will forward the packets.
5.2.8 DNA and Address Configuration 5.2.7 DNA and Address Configuration
[Editor's note: Nothing has changed in this section] When a host When a host moves to a new point of attachment, a potential exists
moves to a new point of attachment, a potential exists for a change for a change in the validity of its unicast and multicast addresses
in the validity of its unicast and multicast addresses on that on that network interface. In this section, host processing for
network interface. In this section, host processing for address address configuration is specified. The section considers both
configuration is specified. The section considers both statelessly statelessly and statefully configured addresses.
and statefully configured addresses.
5.2.8.1 Duplicate Address Detection 5.2.7.1 Duplicate Address Detection
A DNA host MUST support optimistic Duplicate Address Detection [5] A DNA host MUST support optimistic Duplicate Address Detection [5]
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 [7] 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.
5.2.8.2 DNA and the Address Autoconfiguration State Machine 5.2.7.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 40, line 5 skipping to change at page 35, line 16
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.
5.2.8.3 DNA and Statefully Configured Addresses 5.2.7.3 DNA and Statefully Configured Addresses
The DHCPv6 specification [16] requires hosts to send a DHCPv6 CONFIRM The DHCPv6 specification [16] 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 [16] rather use the DHCPv6 CONFIRM message as described in RFC 3315 [16] 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
skipping to change at page 40, line 44 skipping to change at page 36, line 7
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 [16], the host SHOULD use the host supports the Rapid Commit Option [16], 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.
5.2.8.4 Packet Delivery During DNA 5.2.7.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.
5.2.8.5 Multicast Address Configuration 5.2.7.5 Multicast Address Configuration
Multicast routers on a link are aware of which groups are in use Multicast routers on a link are aware of which groups are in use
within a link. This information is used to undertake initiation of within a link. This information is used to undertake initiation of
multicast routing for off-link multicast sources to the link [9][17]. multicast routing for off-link multicast sources to the link [9][17].
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 [17]. In particular, the the host has subscribed using MLD Report [17]. 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
skipping to change at page 41, line 38 skipping to change at page 36, line 48
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.
5.3 DNA without a 'link UP' notification 5.3 Tentative options for IPv6 ND
[Editor's note: Do we need this section? The question is raised in
the issues section of CPL. If we keep this, the section should be
generalised to make it applicable to the whole DNAv6, right now its
specific to CPL only ]
If the host implementation does not provide any link-layer event
notifications [20], and in particular, a link UP notification, the
host needs additional logic to try to decide whether a received RA
applies to the "old" link or a "new" link.
In this case there is an increased risk that the host get confused,
thus it isn't clear whether this should be part of the
recommendation, or whether we should just require that hosts which
implement this draft have a 'link UP' notification.
If there is no 'link UP' notification when the host might have moved,
the host would collect the prefixes from multiple links into a single
DNAHostPrefixList, and would never detect movement.
Here is an example. The host begins to collect the prefixes on a
link. But before the prefix list generation is completed, without
its knowledge, the host moves to a new link. Unaware that now it is
at the different link, the host keeps collecting prefixes from the
received RAs to generate the prefix list. This results in the prefix
list containing prefixes from two different links. If the host uses
this prefix list, it fails to detect a link change.
A possible way to prevent this situation for implementations without
a link UP notification, is to treat the arrival of a RA with a
disjoint set of prefixes as a hint, as specified below.
The implications of treating such an RA as a hint, is that such an RA
would set 'time_last_linkUP_received' to the current time, create a
new Candidate Link object with the information extracted from that
RA, and then send an RS as specified in Section 5.2.6.
However, there is still a risk for confusion because the host can not
tell from the RAs whether they were solicited by the host. (RFC 2461
recommends that solicited RAs be multicast.) The danger is
exemplified by this:
1. Assume the host has a DNAHostPrefixList with prefixes P1 and P2.
2. The host changes link layer attachment, but there is no link UP
notification.
3. The host receives an RA with a disjoint set of prefixes: prefix
P3. This causes the host to form a new DNAHostPrefixList with P3
and send an RS.
4. The host again changes link layer attachment, and no link UP
notification.
5. The host receives one of the periodic multicast RAs on the link,
which contains prefix P4. It can not tell whether this RA was in
response to the RS it send above. The host ends up adding this
to the DNAHostPrefixList, which now has P3 and P4, even though
those prefixes are assigned to different links.
There doesn't appear to be a way to solve this problem without
changes to the routers and the Router Advertisement messages.
However, the probability of this occurring can be limited by limiting
the window of exposure. The simplest approach is for the host to
assume that any RA received within MinRAWait seconds after sending an
RS was in response to the RS. Basically this relies on the small
probability of both moving again in that MinRAWait second interval,
and receiving one of the periodic RAs. If the periodic RAs are sent
infrequently enough, this might work in practise, but is by no means
bullet-proof.
6. Tentative options for IPv6 ND
6.1 Sending solicitations containing Tentative Options 5.3.1 Sending solicitations containing Tentative Options
Tentative Options may be sent in Router and Neighbour Solicitations, Tentative Options may be sent in Router and Neighbour Solicitations,
as described below. as described below.
In a case where it is safe to send a Source Link-Layer Address In a case where it is safe to send a Source Link-Layer Address
Option, a host SHOULD NOT send a TO, since the message may Option, a host SHOULD NOT send a TO, since the message may
bemisinterpreted by legacy nodes. bemisinterpreted by legacy nodes.
Importantly, a node MUST NOT send a Tentative Option in the same Importantly, a node MUST NOT send a Tentative Option in the same
message where a Source Link-Layer Address Option is sent. message where a Source Link-Layer Address Option is sent.
6.1.1 Sending Neighbour Solicitations with Tentative Options 5.3.1.1 Sending Neighbour Solicitations with Tentative Options
Neighbour Solicitations sent to unicast addresses MAY contain a Neighbour Solicitations sent to unicast addresses MAY contain a
Tentative Option. Tentative Option.
Since delivery of a packet to a unicast destination requires prior Since delivery of a packet to a unicast destination requires prior
knowledge of the destination's hardware address, unicast Neighbour knowledge of the destination's hardware address, unicast Neighbour
Solicitation packets may only be sent to destinations for which a Solicitation packets may only be sent to destinations for which a
neighbour cache entry already exists. neighbour cache entry already exists.
For example, if checking bidirectional reachability to a router, it For example, if checking bidirectional reachability to a router, it
may be possible to send a Neighbour Solicitation with Tentative may be possible to send a Neighbour Solicitation with Tentative
Option to the router's advertised address. Option to the router's advertised address.
As discussed in [3], the peer device may not have a cache entry even As discussed in [3], the peer device may not have a cache entry even
if the soliciting host does, in which case reception of the Tentative if the soliciting host does, in which case reception of the Tentative
Option may create a neighbour cache entry, without the need for Option may create a neighbour cache entry, without the need for
neighbour discovering the original solicitor. neighbour discovering the original solicitor.
6.1.2 Sending Router Solicitations with Tentative Options 5.3.1.2 Sending Router Solicitations with Tentative Options
Any Router Solicitation from a Preferred, Deprecated or Optimistic Any Router Solicitation from a Preferred, Deprecated or Optimistic
address MAY be sent with a Tentative Option [5]. address MAY be sent with a Tentative Option [5].
An extension which allows Router Solicitations to be sent with a TO An extension which allows Router Solicitations to be sent with a TO
from the unspecified address is described in Appendix B. from the unspecified address is described in Appendix B.
6.2 Receiving Tentative Options 5.3.2 Receiving Tentative Options
Receiving a Tentative Option allows nodes to unicast responses to Receiving a Tentative Option allows nodes to unicast responses to
solicitations without performing neighbour discovery. solicitations without performing neighbour discovery.
It does this by allowing the solicitation to create STALE neighbour It does this by allowing the solicitation to create STALE neighbour
cache entries if one doesn't exist, but only update an entry if the cache entries if one doesn't exist, but only update an entry if the
link-layer address in the option matches the entry. link-layer address in the option matches the entry.
Additionally, messages containing TO may be used to direct Additionally, messages containing TO may be used to direct
advertisements to particular link-layer destinations without updating advertisements to particular link-layer destinations without updating
skipping to change at page 45, line 5 skipping to change at page 38, line 42
message validation, and processed accordingly. message validation, and processed accordingly.
In the case that a cache entry is unable to be created or updated due In the case that a cache entry is unable to be created or updated due
to existence of a conflicting neighbour cache entry, it MUST NOT to existence of a conflicting neighbour cache entry, it MUST NOT
update the neighbour cache entry. update the neighbour cache entry.
An extension which allows a direct advertisement to the soliciting An extension which allows a direct advertisement to the soliciting
host without modifying the neighbour cache entry is described in host without modifying the neighbour cache entry is described in
Appendix B. Appendix B.
6.2.1 Receiving Neighbour Solicitations containing Tentative Options 5.3.2.1 Receiving Neighbour Solicitations containing Tentative Options
The Tentative Option is only [Editor's note: This only is not right? The Tentative Option is only [Editor's note: This only is not right?
TO is allowed in both NS and RS? right?] allowed in Neighbour TO is allowed in both NS and RS? right?] allowed in Neighbour
Solicitations with specified source addresses for which SLLAO is not Solicitations with specified source addresses for which SLLAO is not
required. required.
A Neighbour Solicitation message received with a TO and an A Neighbour Solicitation message received with a TO and an
unspecified source address MUST be silently discarded. unspecified source address MUST be silently discarded.
Upon reception of a Tentative Option in a Neighbour Solicitation for Upon reception of a Tentative Option in a Neighbour Solicitation for
skipping to change at page 45, line 30 skipping to change at page 39, line 18
If no such entry exists, the neighbour cache of the receiver SHOULD If no such entry exists, the neighbour cache of the receiver SHOULD
be updated, as if the Tentative Option was a SLLAO. be updated, as if the Tentative Option was a SLLAO.
Sending of the solicited Neighbour Advertisement then proceeds Sending of the solicited Neighbour Advertisement then proceeds
normally, as defined in section 7.2.4 of [3]. normally, as defined in section 7.2.4 of [3].
If there is a conflicting neighbour cache entry, the node processes If there is a conflicting neighbour cache entry, the node processes
the solicitation as defined in Section 7.2.4 of [3], except that the the solicitation as defined in Section 7.2.4 of [3], except that the
Neighbour Cache entry MUST NOT be modified. Neighbour Cache entry MUST NOT be modified.
6.2.2 Receiving Router Solicitations containing Tentative Options 5.3.2.2 Receiving Router Solicitations containing Tentative Options
In IPv6 Neighbour Discovery [3], responses to Router Solicitations In IPv6 Neighbour Discovery [3], responses to Router Solicitations
are either sent to the all-nodes multicast address, or may be sent to are either sent to the all-nodes multicast address, or may be sent to
the solicitation's source address if it is a unicast address. the solicitation's source address if it is a unicast address.
Including a Tentative Option in the solicitation allows a router to Including a Tentative Option in the solicitation allows a router to
choose to send a packet directly to the link-layer address even in choose to send a packet directly to the link-layer address even in
situations where this would not normally be possible. situations where this would not normally be possible.
For Router Solicitations with unicast source addresses, neighbour For Router Solicitations with unicast source addresses, neighbour
caches SHOULD be updated with the link-layer address from a Tentative caches SHOULD be updated with the link-layer address from a Tentative
Option if there is no differing neighbour cache entry. In this case, Option if there is no differing neighbour cache entry. In this case,
Router Advertisement continues as in Section 6.2.6 of [3]. Router Advertisement continues as in Section 6.2.6 of [3].
For received solicitations with a differing link-layer address to For received solicitations with a differing link-layer address to
that stored in the neighbour cache, the node processes the that stored in the neighbour cache, the node processes the
solicitation as defined in Section 6.2.6 of [3], except that the solicitation as defined in Section 6.2.6 of [3], except that the
Neighbour Cache entry MUST NOT be modified. Neighbour Cache entry MUST NOT be modified.
7. Initiation of DNA Procedures
Link change detection procedures defined in the document are
initiated when "link UP" event notification. This event indicates
that network reachability or configuration is suspect and is called a
hint. In this section, other possible hints that can imply that the
configuration is suspect are presented and discussed. [Editor's
note: Is this section useful?]
Hints MAY be used to update a wireless host's timers or probing
behavior in such a way as to assist detection of network attachment.
Hints SHOULD NOT be considered to be authoritative for detecting IP
configuration change by themselves.
In some cases, hints will carry significant information (for example
a hint indicating PPP IPv6CP open state [8]), although details of the
configuration parameters may be available only after other IP
configuration procedures. Implementers are encouraged to treat hints
as though they may be incorrect, and require confirmation.
Hosts MUST ensure that untrusted hints do not cause unnecessary
configuration changes, or significant consumption of host resources
or bandwidth. In order to achieve this aim, a host MAY implement
hysteresis mechanisms such as token buckets, hint weighting or
holddown timers in order to limit the effect of excessive hints.
7.1 Hints Due to Network Layer Messages
Hint reception may be due to network-layer messages such as
unexpected Router Advertisements, multicast listener queries or
ICMPv6 error messages [3][9][10]. In these cases, the authenticity
of the messages MUST be verified before expending resources to
initiate DNA procedure.
When a host arrives on a new link, hints received due to external IP
packets will typically be due to multicast messages. Actions based
on multicast reception from untrusted sources are dangerous due to
the threat of multicast response flooding. This issue is discussed
further in Section 9.
State changes within the network-layer itself may initiate link-
change detection procedures. Existing subsystems for router and
neighbor discovery, address leasing and multicast reception maintain
their own timers and state variables. Changes to the state of one or
more of these mechanisms may hint that link change has occurred, and
initiate detection of network attachment.
7.2 Handling Hints from Other Layers
Events at other protocol layers may provide hints of link change to
network attachment detection systems. Two examples of such events
are TCP retransmission timeout and completion of link-layer access
procedures [20].
While hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat hints from other
protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be
triggered by untrusted messages, come from compromised sources (for
example 802.11 WEP Encryption [15]) or be inaccurate with regard to
network-layer state.
While these hints come from the host's own stack, such hints may
actually be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to
instigate hint delivery on a host or multiple hosts deliberately, in
order to prompt packet transmission, or configuration modification.
Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers. A host MAY adopt an appropriate
link change detection strategy based upon hints received from other
layers, with suitable caution and hysteresis.
7.3 Timer and Loss Based Hints
Other hints may be received due to timer expiry, particularly In some
cases the expiry of these timers may be a good hint that DNA
procedures are necessary.
Since DNA is likely to be used when communicating with devices over
wireless links, suitable resilience to packet loss SHOULD be
incorporated into the DNA initiation system. Notably, non-reception
of data associated with end-to-end communication over the Internet
may be caused by reception errors at either end or because of network
congestion. Hosts SHOULD NOT act immediately on packet loss
indications, delaying until it is clear that the packet losses aren't
caused by transient events.
Use of the Advertisement Interval Option specified in [6] follows
these principles. Routers sending this option indicate the maximum
interval between successive router advertisements. Hosts receiving
this option monitor for multiple successive packet losses and
initiate change discovery.
7.4 Simultaneous Hints
Some events which generate hints may affect a number of devices
simultaneously.
For example, if a wireless base station goes down, all the hosts on
that base station are likely to initiate link-layer configuration
strategies after losing track of the last beacon or pilot signal from
the base station.
As described in [3][10], a host SHOULD delay randomly before acting
on a widely receivable advertisement, in order to avoid response
implosion.
Where a host considers it may be on a new link and learns this from a
hint generated by a multicast message, the host SHOULD defer 0-1000ms
in accordance with [3][7]. Please note though that a single
desynchronization is required for any number of transmissions
subsequent to a hint, regardless of which messages need to be sent.
In link-layers where sufficient serialization occurs after an event
experienced by multiple hosts, each host MAY avoid the random delays
before sending solicitations specified in [3].
7.5 Hint Management for Inactive Hosts
If a host does not expect to send or receive packets soon, it MAY
choose to defer detection of network attachment. This may preserve
resources on latent hosts, by removing any need for packet
transmission when a hint is received.
These hosts SHOULD delay 0-1000ms before sending a solicitation, and
MAY choose to wait up to twice the advertised Router Advertisement
Interval (plus the random delay) before sending a solicitation [6].
One benefit of inactive hosts' deferral of DNA procedures is that
herd-like host configuration testing is mitigated when base-station
failure or simultaneous motion occur. When latent hosts defer DNA
tests, the number of devices actively probing for data simultaneously
is reduced to those hosts which currently support active data
sessions.
When a device begins sending packets, it will be necessary to test
bidirectional reachability with the router (whose current Neighbor
Cache state is STALE). As described in [3], the host will delay
before probing to allow for the probability that upper layer packet
reception confirms reachability.
8. Complications to Detecting Network Attachment
Detection of network attachment procedures can be delayed or may be
incorrect due to different factors. This section gives some examples
where complications may interfere with DNA processing.
8.1 Packet Loss
Generally, packet loss introduces significant delays in validation of
current configuration or discovery of new configuration. Because
most of the protocols rely on timeout to consider that a peer is not
reachable anymore, packet loss may lead to erroneous conclusions.
Additionally, packet loss rates for particular transmission modes
(multicast or unicast) may differ, meaning that particular classes of
DNA tests have higher chance of failure due to loss. Hosts SHOULD
attempt to verify tests through retransmission where packet loss is
prevalent.
8.2 Router Configurations
Each router can have its own configuration with respect to sending Each router can have its own configuration with respect to sending
RA, and the treatment of router and neighbor solicitations. RA, and the treatment of router and neighbor solicitations.
Different timers and constants might be used by different routers, Different timers and constants might be used by different routers,
such as the delay between Router Advertisements or delay before such as the delay between Router Advertisements or delay before
replying to an RS. If a host is changing its IPv6 link, the new replying to an RS. If a host is changing its IPv6 link, the new
router on that link may have a different configuration and may router on that link may have a different configuration and may
introduce more delay than the previous default router of the host. introduce more delay than the previous default r < title="Overlapping
The time needed to discover the new link can then be longer than Coverage"> If a host can be attached to different links at the same
expected by the host. time with the same interface, the host will probably listen to
different routers, at least one on each link. To be simultaneously
8.3 Overlapping Coverage attached to several links may be very valuable for a MN when it moves
from one access network to another. If the node can still be
If a host can be attached to different links at the same time with reachable through its old link while configuring the interface for
the same interface, the host will probably listen to different its new link, packet loss can be minimized.
routers, at least one on each link. To be simultaneously attached to
several links may be very valuable for a MN when it moves from one
access network to another. If the node can still be reachable
through its old link while configuring the interface for its new
link, packet loss can be minimized.
Such a situation may happen in a wireless environment if the link Such a situation may happen in a wireless environment if the link
layer technology allows the MN to be simultaneously attached to layer technology allows the MN to be simultaneously attached to
several points of attachment and if the coverage area of access several points of attachment and if the coverage area of access
points are overlapping. points are overlapping.
For the purposes of DNA, it is necessary to treat each of these For the purposes of DNA, it is necessary to treat each of these
points-of-attachment separately, otherwise incorrect conclusions of points-of-attachment separately, otherwise incorrect conclusions of
link-change may be made even if another of the link-layer connections link-change may be made even if another of the link-layer connections
is valid. is valid.
8.4 Multicast Snooping
When a host is participating in DNA on a link where multicast When a host is participating in DNA on a link where multicast
snooping is in use, multicast packets may not be delivered to the snooping is in use, multicast packets may not be delivered to the
LAN-segment to which the host is attached until MLD signaling has LAN-segment to which the host is attached until MLD signaling has
been performed [9][17] [11]. Where DNA relies upon multicast packet been performed [9][17] [11]. Where DNA relies upon multicast packet
delivery (for example, if a router needs to send a Neighbor delivery (for example, if a router needs to send a Neighbor
Solicitation to the host), its function will be degraded until after Solicitation to the host), its function will be degraded until after
an MLD report is sent. an MLD report is sent.
Where it is possible that multicast snooping is in operation, hosts Where it is possible that multicast snooping is in operation, hosts
MUST send MLD group joins (MLD reports) for solicited nodes' MUST send MLD group joins (MLD reports) for solicited nodes'
addresses swiftly after starting DNA procedures. addresses swiftly after starting DNA procedures.
8.5 Link Partition
Link partitioning occurs when a link's internal switching or relaying Link partitioning occurs when a link's internal switching or relaying
hardware fails, or if the internal communications within a link are hardware fails, or if the internal communications within a link are
prevented due to topology changes or wireless propagation. prevented due to topology changes or wireless propagation.
When a host is on a link which partitions, only a subset of the When a host is on a link which partitions, only a subset of the
addresses or devices it is communicating with may still be available. addresses or devices it is communicating with may still be available.
Where link partitioning is rare (for example, with wired Where link partitioning is rare (for example, with wired
communication between routers on the link), existing router and communication between routers on the link), existing router and
neighbor discovery procedures may be sufficient for detecting change. neighbor discovery procedures may be sufficient for detecting change.
9. Security Considerations 6. Security Considerations
9.1 Attacks on the Token Bucket 6.1 Attacks on the Token Bucket
A host on the link could easily drain the token bucket(s) of the A host on the link could easily drain the token bucket(s) of the
router(s) on the link by continuously sending RS messages on the router(s) on the link by continuously sending RS messages on the
link. For example, if a host sends one RS message every link. For example, if a host sends one RS message every
UnicastRAInterval, and send a additional RS every third 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.
9.2 Attacks on DNA Hosts 6.2 Attacks on DNA Hosts
RFC 3756 outlines a collection of threats involving rouge routers. RFC 3756 outlines a collection of threats involving rouge routers.
Since DNAv6 requires a host to obtain trustworthy responses from Since DNAv6 requires a host to obtain trustworthy responses from
routers, such threats are relevant to DNAv6. In order to counter routers, such threats are relevant to DNAv6. In order to counter
such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure
router discovery. router discovery.
9.3 Tentative options 6.3 Tentative options
The use of the Tentative Option in Neighbour and Router Solicitation The use of the Tentative Option in Neighbour and Router Solicitation
messages acts in a similar manner to SLLAO, updating neighbour cache messages acts in a similar manner to SLLAO, updating neighbour cache
entries, in a way which causes packet transmission. entries, in a way which causes packet transmission.
Particular care should be taken that transmission of messages Particular care should be taken that transmission of messages
complies with existing IPv6 Neighbour Discovery Procedures, so that complies with existing IPv6 Neighbour Discovery Procedures, so that
unmodified hosts do not receive invalid messages. unmodified hosts do not receive invalid messages.
An attacker may cause messages may be sent to another node by an An attacker may cause messages may be sent to another node by an
skipping to change at page 52, line 16 skipping to change at page 42, line 25
through replay of previously sent messages. Although this applies to through replay of previously sent messages. Although this applies to
Neighbour and Router Solicitation messages, granularity of the Neighbour and Router Solicitation messages, granularity of the
timestamp allows the messages to be used for up to five minutes [4]. timestamp allows the messages to be used for up to five minutes [4].
All Router and Neighbour Solicitations using SEND contain a Nonce All Router and Neighbour Solicitations using SEND contain a Nonce
option, containing a random identifier octet string. Since SEND option, containing a random identifier octet string. Since SEND
messages are digitally signed, and may not be easily modified, replay messages are digitally signed, and may not be easily modified, replay
attacks will contain the same Nonce option, as was used in the attacks will contain the same Nonce option, as was used in the
original solicitation. original solicitation.
9.4 Authorization and Detecting Network Attachment 6.4 Authorization and Detecting Network Attachment
When a host is determining if link change has occurred, it may When a host is determining if link change has occurred, it may
receive messages from devices with no advertised security mechanisms receive messages from devices with no advertised security mechanisms
purporting to be routers, nodes sending signed router advertisements purporting to be routers, nodes sending signed router advertisements
but with unknown delegation, or routers whose credentials need to be but with unknown delegation, or routers whose credentials need to be
checked [12]. Where a host wishes to configure an unsecured router, checked [12]. Where a host wishes to configure an unsecured router,
it SHOULD confirm bidirectional reachability with the device, and it it SHOULD confirm bidirectional reachability with the device, and it
MUST mark the device as unsecured as described in [4]. MUST mark the device as unsecured as described in [4].
In any case, a secured router SHOULD be preferred over an unsecured In any case, a secured router SHOULD be preferred over an unsecured
one, except where other factors (unreachability) make the router one, except where other factors (unreachability) make the router
unsuitable. Since secured routers' advertisement services may be unsuitable. Since secured routers' advertisement services may be
subject to attack, alternative (secured) reachability mechanisms from subject to attack, alternative (secured) reachability mechanisms from
upper layers, or secured reachability of other devices known to be on upper layers, or secured reachability of other devices known to be on
the same link may be used to check reachability in the first the same link may be used to check reachability in the first
instance. instance.
9.5 Addressing 6.5 Addressing
While a DNA host is checking for link-change, and observing DAD, it While a DNA host is checking for link-change, and observing DAD, it
may receive a DAD defense NA from an unsecured source. may receive a DAD defense NA from an unsecured source.
SEND says that DAD defenses MAY be accepted even from non SEND nodes SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [4]. for the first configured address [4].
While deconfiguring the address is a valid action in the case where a While deconfiguring the address is a valid action in the case where a
host collides with another address owner after arrival on a new link, host collides with another address owner after arrival on a new link,
In the case that the host returns immediately to the same link, such In the case that the host returns immediately to the same link, such
a DAD defense NA message can only be a denial-of-service attempt. a DAD defense NA message can only be a denial-of-service attempt.
9.6 Hint Management Security 6.6 Hint Management Security
Events originating at other protocol layers may provide hints of link Events originating at other protocol layers may provide hints of link
change to network attachment detection systems. Two examples of such change to network attachment detection systems. Two examples of such
events are TCP retransmission timeout and completion of link-layer events are TCP retransmission timeout and completion of link-layer
access procedures [20]. access procedures [20].
While hints from other protocol layers originate from within the While hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat hints from other host's own stack, the network layer SHOULD NOT treat hints from other
protocol layers as authoritative indications of link change. protocol layers as authoritative indications of link change.
skipping to change at page 53, line 25 skipping to change at page 43, line 35
actually be due to packet reception or non-reception events at the actually be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to originating layers. As such, it may be possible for other devices to
instigate hint delivery on a host or multiple hosts deliberately, in instigate hint delivery on a host or multiple hosts deliberately, in
order to prompt packet transmission, or configuration modification. order to prompt packet transmission, or configuration modification.
Therefore, hosts SHOULD NOT change their configuration state based on Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers. A host MAY adopt an appropriate hints from other protocol layers. A host MAY adopt an appropriate
link change detection strategy based upon hints received from other link change detection strategy based upon hints received from other
layers, with suitable caution and hysteresis. layers, with suitable caution and hysteresis.
10. IANA Considerations 7. IANA Considerations
This memo defines two new Neighbor Discovery [3] options, which must This memo defines two new Neighbor Discovery [3] options, which must
be assigned Option Type values within the option numbering space for be assigned Option Type values within the option numbering space for
Neighbor Discovery messages: Neighbor Discovery messages:
1. The Landmark option, described in Section 4.3; and 1. The Landmark option, described in Section 4.2; and
2. The Learned Prefix option, described in Section 4.4. 2. The Learned Prefix option, described in Section 4.3.
3. The tentative option, described in Section 4.5 3. The tentative option, described in Section 4.4
11. Changes since -02 8. Constants
NumRSRAComplete
o Changed the Router Advertisment processing in Section 5.2.7 and Number of RS/RA exchange messages necessary to declare the prefix
Section 5.2.7.1 to fix a mistake in the logic. list to be complete.
Value: 2
MinRAWait
Minimum time the host will have to wait before assuming receipt of
all possible RAs.
Default: 4 seconds
9. Changes since -03
o A global replace of "1.5 hours" with "3 times maximum of
MaxRtrAdvInterval".
o Removed Y/N bit from the landmark option and modified the text to
remove all references to the Y/N bit. The description in
Section 3.1 was twicked to explain the semantics of Yes and No.
o Removed MaxCacheTime and reference to use of prior link
information.
o Made NumRSRAComplete a constant with value 2, MinRAWait a constant
with value 4 seconds.
o Removed reference to the terminology draft as there was nothing
important to be transferred.
o Removed sections on Link indication, complications and DNA without
link UP notifications.
o Removed reference to linkID and replaced with smallest prefix.
Which requires a DNARAReceivedFlag to be added to the conceptual
values maintained by the host.
o Included sentence to mandate the configuration of atleast one
prefix on each routers even when stateful address configuration is
used. The change was made in Section 5.1.7.
10. Changes since -02
o Changed the Router Advertisment processing in Section 5.2.6 and
Section 5.2.6.1 to fix a mistake in the logic.
o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT, o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT,
MAX_CACHE_TIME to NumRSRAComplete, MinRAWait, MaxCacheTIme. Added MAX_CACHE_TIME to NumRSRAComplete, MinRAWait, MaxCacheTIme. Added
an open issue whether these should be variables or constants. an open issue whether these should be variables or constants.
o Fixed some typos. o Fixed some typos.
12. Open issues 11. Open issues
1. The protocol uses only the prefixes with lifetime greater than 1. The protocol uses only the prefixes with lifetime greater than
1.5 hours. 1.5 hour is decided with the assumption that 1.5 hours. 1.5 hour is decided with the assumption that
MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to
increase the value into hours or even days because it would be increase the value into hours or even days because it would be
difficult to waken all idle nodes in every 30 mins in cellular difficult to waken all idle nodes in every 30 mins in cellular
network. network.
2. There may be a link where no prefix is advertised. For example, 2. There may be a link where no prefix is advertised. For example,
an network administrator may not support stateless address an network administrator may not support stateless address
autoconfiguration for policy reason. Then it won't advertise any autoconfiguration for policy reason. Then it won't advertise any
prefix with A-bit set. Also it may want all traffic going prefix with A-bit set. Also it may want all traffic going
through an AR and not allow direct communication among hosts through an AR and not allow direct communication among hosts
because of accounting. Then it won't advertise any prefix with because of accounting. Then it won't advertise any prefix with
L-bit set either. As of my knowledge the prefix without any bit L-bit set either. As of my knowledge the prefix without any bit
set won't be advertised, which would hurt DNA operation. set won't be advertised, which would hurt DNA operation.
3. Third, I propose we do away with 'Landmark Option with Y bit'. 3. Third, I propose we do away with 'Landmark Option with Y bit'.
The router can notify no-link change by simply putting the The router can notify no-link change by simply putting the
landmark prefix in either PIO or LPIO. Then we can remove the landmark prefix in either PIO or LPIO. Then we can remove the
check for landmark from Section 5.2.7. check for landmark from Section 5.2.6.
4. Should variables NumRSRAComplete, MinRAWait, MaxCacheTime be kept 4. Should variables NumRSRAComplete, MinRAWait, MaxCacheTime be kept
as variables or should they be constants? as variables or should they be constants?
13. Contributors 12. Contributors
This document is the result of merging four different working group This document is the result of merging four different working group
documents. The draft-ietf-dna-protocol-01.txt authored by James documents. The draft-ietf-dna-protocol-01.txt authored by James
Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock
Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02
authored by JinHyeock Choi and Erik Normark provided the idea/text authored by JinHyeock Choi and Erik Normark provided the idea/text
for the complete prefix list mechanism described in this document. for the complete prefix list mechanism described in this document.
The best current practice for hosts draft (draft-ietf-dna-hosts-03) The best current practice for hosts draft (draft-ietf-dna-hosts-03)
authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and
the tentative options (draft-ietf-dna-tentative-00) authored by Greg the tentative options (draft-ietf-dna-tentative-00) authored by Greg
Daley, Erik Normark and Nick Moore were also adopted into this Daley, Erik Normark and Nick Moore were also adopted into this
document. document.
14. Acknowledgments 13. Acknowledgments
The design presented in this document grew out of discussions among The design presented in this document grew out of discussions among
the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, the members of the DNA design team (JinHyeock Choi, Tero Kauppinen,
James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland).
The spirited debates on the design, and the advantages and dis- The spirited debates on the design, and the advantages and dis-
advantages of various DNA solutions helped the creation of this advantages of various DNA solutions helped the creation of this
document. document.
Thanks to Syam Madanapalli who co-authored Thanks to Syam Madanapalli who co-authored
draft-jinchoi-dna-protocol2 from which this draft draws ideas, as draft-jinchoi-dna-protocol2 from which this draft draws ideas, as
skipping to change at page 55, line 24 skipping to change at page 46, line 35
Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli,
Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review
of draft-ietf-dna-protocol-01. of draft-ietf-dna-protocol-01.
Thanks to Gabriel Montenegro for his review of Thanks to Gabriel Montenegro for his review of
draft-pentland-dna-protocol. draft-pentland-dna-protocol.
Thanks also to other members of the DNA working group for their Thanks also to other members of the DNA working group for their
comments that helped shape this work. comments that helped shape this work.
15. References 14. References
15.1 Normative References 14.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, April 2006. IPv6", RFC 4429, April 2006.
15.2 Informative References 14.2 Informative References
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address [7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462 2462, December 1998. Autoconfiguration", RFC2462 2462, December 1998.
[8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998. December 1998.
skipping to change at page 56, line 47 skipping to change at page 48, line 12
[18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment [19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005. in IPv6", RFC 4135, August 2005.
[20] Yegin, A., "Link-layer Event Notifications for Detecting [20] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-00 (work Network Attachments", draft-ietf-dna-link-information-00 (work
in progress), September 2004. in progress), September 2004.
[21] Yamamoto, S., "Detecting Network Attachment Terminology", [21] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-yamamoto-dna-term-00 (work in progress), February 2004.
[22] 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.
[23] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix [22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress), list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005. April 2005.
Authors' Addresses Authors' Addresses
Sathya Narayanan (editor) Sathya Narayanan (editor)
Panasonic Princeton Laboratory Panasonic Princeton Laboratory
Two Research Way, 3rd Floor Two Research Way, 3rd Floor
Princeton, NJ 08540 Princeton, NJ 08540
USA USA
skipping to change at page 61, line 33 skipping to change at page 52, line 33
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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 (2006). This document is subject Copyright (C) The IETF Trust (2007). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. 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. 143 change blocks. 
707 lines changed or deleted 343 lines changed or added

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