DNA Working Group S. Narayanan, Ed.
Internet-Draft Panasonic
Expires: September 5, 2007 March 4, 2007
Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-ietf-dna-protocol-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Efficient detection of network attachment in IPv6 needs the following
three components: a method for hosts to detect link change in the
presence of unmodified (non-DNAv6) routers, a method for the host to
query routers on the link to identify the link (Link Identification)
and a method for the routers on the link to consistently respond to
such a query with minimal delay (Fast RA). Solving the link
identification based strictly on RFC 2461 is difficult because of the
flexibility offered to routers in terms of prefixes advertised in a
router advertisement (RA) message. Similarly, the random delay in
Narayanan, et al. Expires September 5, 2007 [Page 1]
Internet-Draft DNAv6 March 2007
responding to router solicitation messages imposed by RFC 2461 makes
it difficult to receive an RA quickly. In this memo, a mechanism
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
routers is presented. A more efficient link-identification mechanism
requiring the DNAv6 routers to monitor the link for advertised
prefixes to assist the hosts in link identification combined with a
fast router advertisement mechanism that selects the order of
response for the router deterministicly is also presented.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5
3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7
3.3 Complete Prefix List generation . . . . . . . . . . . . . 8
3.3.1 Erroneous Prefix Lists . . . . . . . . . . . . . . . . 9
3.4 Tentative Source Link-Layer Address option (TO) . . . . . 10
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 11
4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 12
4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 13
4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 15
5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 16
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 16
5.1.2 Router Configuration Variables . . . . . . . . . . . . 17
5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 18
5.1.4 Processing Router Advertisements . . . . . . . . . . . 19
5.1.5 Processing Router Solicitations . . . . . . . . . . . 19
5.1.6 Complete Router Advertisements . . . . . . . . . . . . 20
5.1.7 Inclusion of smallest prefixes . . . . . . . . . . . . 21
5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 22
5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 23
5.1.10 Removing a Prefix from an Interface . . . . . . . . 23
5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 24
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 24
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 24
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 25
5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 25
5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 26
5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 26
Narayanan, et al. Expires September 5, 2007 [Page 2]
Internet-Draft DNAv6 March 2007
5.2.6 Processing Router Advertisements . . . . . . . . . . . 27
5.2.7 DNA and Address Configuration . . . . . . . . . . . . 33
5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 36
5.3.1 Sending solicitations containing Tentative Options . . 37
5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . 40
6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 40
6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 41
6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 41
6.4 Authorization and Detecting Network Attachment . . . . . . 42
6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 42
6.6 DNA Hint Management Security . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43
8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 43
9. Changes since -04 . . . . . . . . . . . . . . . . . . . . . 44
10. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 44
11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 45
12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 46
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
15.1 Normative References . . . . . . . . . . . . . . . . . . 47
15.2 Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
A. Sending directed advertisements without the neighbour
cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . 51
Narayanan, et al. Expires September 5, 2007 [Page 3]
Internet-Draft DNAv6 March 2007
1. Introduction
This memo defines a mechanism for an IPv6 host to detect link-change
in the presence of unmodified (non-DNAv6) routers and proposes new
extensions to "IPv6 Neighbor Discovery" [3] to increase the
efficiency of link-change detection in the presence of DNAv6 enabled
routers. The proposed mechanism define the construct that identifies
a link, proposes an algorithm for the routers on the link to send a
quick RA response without randomly waiting for upto MAX_RA_DELAY_TIME
seconds as specified in RFC2461 [3]. This memo also defines a
mechanism to exchange Source Link-Layer Address without affecting the
neighbor caches when the host is performing Optimistic DAD.
The rest of the document refers to the proposed mechanisms by the
term "DNAv6".
2. Terms and Abbreviations
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.
Attachment: The process of establishing a layer-2 connection.
Attachment (and detachment) may cause a link-change.
DNA Hint: An indication from other subsystems or protocol layers that
link-change may have occurred.
Link-Change: Link-Change occurs when a host moves from a point-of-
attachment on a link, to another point-of-attachment where it is
unable to reach devices belonging to the previous link, without
being forwarded through a router.
Point-of-Attachment: A link-layer base-station, VLAN or port through
which a device attempts to reach the network. Changes to a
host's point-of-attachment may cause link-change.
Reachability Detection: Determination that a device (such as a
router) is currently reachable. This is typically achieved using
Neighbor Unreachability Detection procedure [3].
3. Overview
The DNA protocol presented in this document tries to achieve the
following objectives:
o Eliminate the delays introduced by RFC 2461 in discovering the
configuration.
Narayanan, et al. Expires September 5, 2007 [Page 4]
Internet-Draft DNAv6 March 2007
o Make it possible for the hosts to accurately detect the identity
of their current link from a single RS-RA pair in the presence of
either DNAv6 enabled routers or non-DNAv6 routers.
DNAv6 assumes that the host's link interface software and hardware is
capable of delivering a 'link up' event notification when layer 2 on
the host is configured and sufficiently stable for IP traffic. This
event notification acts as a DNA Hint to the layer 3 DNA procedures
to check whether or not the host is attached to the same link as
before. DNAv6 also assumes that an interface on the host is never
connected to two links at the same time. In the case that the layer
2 technology is capable of having multiple attachments (for instance,
multiple layer 2 associations or connections) at the same time, DNAv6
requires the individual layer-2 associations to be represented as
separate (virtual interfaces) to layer 3 and DNAv6 in particular.
3.1 Link Identification
DNAv6 uses the set of prefixes that are assigned to the link to
uniquely identify the link, which is quite natural and doesn't
require introducing any new form of identifier. However, this choice
implies that the protocol needs to be robust against changes in the
set of prefixes assigned to a link, including the case when a link is
renumbered and the prefix is later reassigned to a different link.
The protocol handles this during graceful renumbering (when the valid
lifetime of the prefix is allowed to decrease to zero before it is
removed and perhaps reassigned to a different link), it describes how
to remove and reassign prefixes earlier than this without any
incorrect behaviour, and will also recover in case where a prefix is
reassigned without following the draft recommendations.
DNAv6 is based on using a Router Solicitation/Router Advertisement
exchange to both verify whether the host has changed link, and if it
has, provide the host with the configuration information for the new
link. The base method for detecting link change involves getting
routers to listen to all of the prefixes that are being advertised by
other routers on the link. They can then respond to solicitations
with complete prefix information. This information consists of the
prefixes a router would advertise itself as per RFC 2461, and also,
the prefixes learned from other routers on the link that are not
being advertised by itself. These learned prefixes are included in a
new Learned Prefix Option in the Router Advertisement.
A host receiving one of these "Complete RAs" - so marked by a flag -
then knows all of the prefixes in use on a link, and by inference all
those that are not. By comparing this with previously received
prefixes the host can correctly decide whether it is connected to the
same link as previously, or whether this Router Advertisement is from
Narayanan, et al. Expires September 5, 2007 [Page 5]
Internet-Draft DNAv6 March 2007
a router on a new link.
If the link contains all non-DNAv6 routers, then the host relies on
the completeness (which the host always keeps track) of its own
prefix list to make a decision; i.e. if its own prefix list is known
to be 'complete', the host can make a decision by comparing the
received prefixes with its prefix list, if its own prefix is not yet
'complete', the host will wait for the completeness criteria to be
met before making the comparison.
Though frequently all routers on a link will advertise the same set
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
prefixes advertised. Two mechanisms are defined that allow certain
RAs to be reduced in size. Both these mechanisms use one prefix as a
representative for the set of prefixes on a particular link.
One uses a technique called a "landmark", where the host chooses one
of the prefixes as a landmark prefix, and then includes this in the
Router Solicitation message in the form of a question "Am I on the
link which has this prefix?". The landmark is carried in a new
option, called the Landmark Option.
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
point to another, but the access points are on the same link, the
Router Advertisement(s) it receives will contain a "yes, that prefix
is on this link" answer by the inclusion of the landmark prefix in
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
router, the host will receive a "No" answer by non-inclusion of the
landmark prefix in the RA, and also the information it needs to
configure itself for the new link. The routers try to include as
much information as possible in such messages, so that the host can
be informed of all the prefixes assigned to the new link as soon as
possible.
A second mechanism for reducing packet sizes applies to unsolicited
Router Advertisements. By selecting the smallest prefix on the link
to be the representative for the entire set of prefixes on the link,
and making sure that it is included in every advertisement, it is
possible to omit some prefixes. Such advertisements will not inform
a host of all of the prefixes at once, but in general these
unsolicited advertisements will not be the first advertisement
received on a link. Inclusion of the smallest prefix simply ensures
that there is overlap in the information advertised by each router on
Narayanan, et al. Expires September 5, 2007 [Page 6]
Internet-Draft DNAv6 March 2007
a link and that hosts will thus not incorrectly interpret one of
these incomplete RAs as an indication of movement. Even though this
document recommends the use of a prefix as the representative of the
link, future specifications can use the Learned Prefix Option to
include a non-prefix link identifier as long as this identifier is
128 bit long to avoid collision with any currently assigned prefix.
So, any future non-prefix link identifier MUST be 128 bits long.
The Router Advertisement messages are, in general, larger than the
solicitations, and with multiple routers on the link there will be
multiple advertisements sent for each solicitation. This
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
unicast Router Advertisements sent directly in response to each
solicitation, and using multicast RAs when the rate limit is
exceeded.
In order for the routers be able to both respond to the landmark
questions and send the complete RAs, the routers need to track the
prefixes that other routers advertise on the link. This process is
initialized when a router is enabled, by sending a Router
Solicitation and collecting the resulting RAs, and then multicasting
a few RAs more rapidly as already suggested in RFC 2461. This
process ensures with high probability that all the routers have the
same notion of the set of prefixes assigned to the link.
In order for the host to be able to make decisions about link change
with a single received RA, the hosts need to track all the prefixes
advertised on the link. The hosts also have to maintain a notion of
'completeness' associated with its prefix list.
3.2 Fast Router Advertisement
According to RFC 2461 a solicited Router Advertisement should have a
random delay between 0 and 500 milliseconds, to avoid the
advertisements from all the routers colliding on the link causing
congestion and higher probability of packet loss. In addition, RFC
2461 suggests that the RAs be multicast, and multicast RAs are rate
limited to one message every 3 seconds. This implies that the
response to a RS might be delayed up to 3.5 seconds.
DNAv6 avoids this delay by using a different mechanism to ensure that
two routers will not respond at exactly the same time while allowing
one of the routers on the link to respond immediately. Since the
hosts might be likely to use the first responding router as the first
choice from their default router list, the mechanism also ensures
that the same router doesn't respond first to the RSs from different
hosts.
Narayanan, et al. Expires September 5, 2007 [Page 7]
Internet-Draft DNAv6 March 2007
The mechanism is based on the routers on the link determining (from
the same RAs that are used in Section 3.1 to determine all the
prefixes assigned to the link), the link-local addresses of all the
other routers on the link. With this loosely consistent list, each
router can independently compute some function of the (link-local)
source address of the RS and each of the routers' link-local
addresses. The results of that function are then compared to create
a ranking, and the ranking determines the delay each router will use
when responding to the RS. The router which is ranked as #0 will
respond with a zero delay.
If the routers become out-of-sync with respect to their learned
router lists, two or more routers may respond with the same delay,
but over time the routers will converge on their lists of learned
routers on the link.
3.3 Complete Prefix List generation
To efficiently check for link change, a host always maintains the
list of all known prefixes on the link. This procedure of attaining
and retaining the Complete Prefix List is initialized when the host
is powered on.
The host forms the prefix list at any PoA (Point of Attachment), that
is, this process starts independently of any movement. Though the
procedure may take some time, that doesn't matter unless the host
moves very fast. A host can generate the Complete Prefix List with
reasonable certainty if it remains attached to a link sufficiently
long. It will take approximately 4 seconds, when it actively
performs 1 RS/ RA exchange. If it passively relies on unsolicited RA
messages instead, it may take much more time.
First the host sends an RS to All-Router multicast address. Assuming
there is no packet loss, every router on the link would receive the
RS and usually reply with an RA containing all the prefixes that the
router advertises. However, RFC 2461 mandates certain delays for the
RA transmissions.
After an RS transmission, the host waits for all RAs that would have
been triggered by the RS. There is an upper limit on the delay of
the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec)
+ network propagation delay is the maximum delay between an RS and
the resulting RAs [3]. 4 seconds would be a safe number for the host
to wait for the solicited RAs. Assuming no packet loss, within 4
seconds, the host would receive all the RAs and know all the
prefixes. Thus we pick 4 seconds as the value for MinRAWait.
In case of packet loss, things get more complicated. In the above
Narayanan, et al. Expires September 5, 2007 [Page 8]
Internet-Draft DNAv6 March 2007
process, there may be a packet loss that results in the generation of
an Incomplete Prefix List, i.e. the prefix list that misses some
prefix on the link. To remedy this deficiency, the host may perform
multiple RS/ RA exchanges to collect all the assigned prefixes.
After one RS/ RA exchange, to corroborate the completeness of the
prefix list, the host may send additional RSs and wait for the
resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS
by RFC2461 [3]. The host takes the union of the prefixes from all
the RAs to generate the prefix list. The more RS/ RA exchange the
host performs, the more probable that the resulting prefix list is
complete.
To ascertain whether its existing prefix list is complete or not, the
host can set its own policy. The host may take into consideration
the estimated packet loss rate of the link and the number of RS/ RA
exchanges it performed or should have performed while it was attached
to the link.
In general, the higher the error rate, the longer time and more RA
transmissions from the routers are needed to assure the completeness
of the prefix list.
3.3.1 Erroneous Prefix Lists
The host may generate either 1) an Incomplete Prefix List, i.e. the
prefix list that does not include all the prefixes that are assigned
to the link or 2) the Superfluous Prefix List, i.e. the prefix list
that contains some prefix that is not assigned to the link.
It should be noted that 1) and 2) are not exclusive. The host may
generate the prefix list that excludes some prefix on the link but
includes the prefix not assigned to the link. Its important to note
that these erroneous prefix list possibility is significantly reduced
with a single DNAv6 router on the link that is sending CompleteRA
messages.
Severe packet losses during prefix list generation may cause an
Incomplete Prefix List. Or the host may have undergone a link change
before finishing the procedure of the Complete Prefix List
generation. Later we will deal with the case that the host can't be
sure of the completeness of the prefix list.
Even if the host falsely assumes that an Incomplete Prefix List is
complete, the effect of that assumption is that the host might later
think it has moved to a different link when in fact it has not.
In case that a link change happens, even if the host has an
Narayanan, et al. Expires September 5, 2007 [Page 9]
Internet-Draft DNAv6 March 2007
Incomplete Prefix List, it will detect a link change. Hence an
Incomplete Prefix List doesn't cause a connection disruption. But
when a link change hasn't occured, an erroneous prefix list may cause
the host to make the wrong decision resulting in extra signaling
messages, for example Binding Update messages in Mobile IPv6 [6]
The Superfluous Prefix List presents a more serious problem.
Without the assumed 'link UP' event notification from the link-layer,
the host can't perceive that it has changed its attachment point,
i.e. it has torn down an old link-layer connection and established a
new one.
With the assumed 'link UP' notification, and the assumption of
different concurrent layer 2 connections being represented as
different (virtual) interfaces to the DNA module the host will never
treat RAs from different links as being part of the same link. Hence
it will not create a Superfluous Prefix List.
3.4 Tentative Source Link-Layer Address option (TO)
DNAv6 protocol requires the host to switch its IPv6 addresses to
'optimistic' state as recommended by Optimistic DAD [5] after
receiving a link-up notification until a decision on the link-change
possibility is made.
Optimistic DAD [5] prevents usage of Source Link-Layer Address
options (SLLAOs) in Router and Neighbour Solicitation messages from a
tentative address (while Duplicate Address Detection is occurring).
This is because receiving a Neighbour Solicitation (NS) or Router
Solicitation (RS) containing an SLLAO would otherwise overwrite an
existing cache entry, even if the cache entry contained the
legitimate address owner, and the solicitor was a duplicate address.
Neighbour Advertisement (NA) messages don't have such an issue, since
the Advertisement message contains a flag which explicitly disallows
overriding of existing cache entries, by the target link-layer
address option carried within.
The effect of preventing SLLAOs for tentative addresses is that
communications with these addresses are difficult for the tentative
period. Sending solicitations without these options causes an
additional round-trip for neighbour discovery if the advertiser does
not have an existing neighbour cache entry for the solicitor. In
some cases, multicast advertisements will be scheduled, where
neighbour discovery is not possible on the advertiser.
The Tentative Option (TO) functions in the same role as the Source
Narayanan, et al. Expires September 5, 2007 [Page 10]
Internet-Draft DNAv6 March 2007
Link-Layer Address option defined for [3], but it MUST NOT override
an existing neighbour cache entry.
The differing neighbour cache entry MUST NOT be affected by the
reception of the Tentative Option. This ensures that tentative
addresses are unable to modify legitimate neighbour cache entries.
In the case where an entry is unable to be added to the neighbour
cache, a node MAY send responses direct to the link-layer address
specified in the TO.
4. Message Formats
This memo defines two new flags for inclusion in the router
advertisement message and three new options.
4.1 Router Advertisement
DNAv6 modifies the format of the Router Advertisement message by
defining a bit to indicate that the router sending the message is
participating in the DNAv6 protocol as well as a flag to indicate the
completeness of the set of prefixes included in the Router
Advertisement. 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|Pr |D|C|R| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
DNAAware (D)
The DNAAware (D) bit indicates that the router sending the RA is
participating in the DNAv6 protocol. Other routers should include
this router in calculating response delay tokens.
Narayanan, et al. Expires September 5, 2007 [Page 11]
Internet-Draft DNAv6 March 2007
Complete (C)
The Complete (C) bit indicates that the Router Advertisement
contains PIOs for all prefixes explicitly configured on the
sending router, and, if other routers on the link are advertising
additional prefixes, a Learned Prefix Option containing all
additional prefixes that the router has heard from other routers
on the link.
Reserved (R)
The reserved field is reduced from 3 bits to 1 bit.
4.2 Landmark Option
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
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
Solicitation, indicating whether the prefix referred to is being
advertised by any router on the link.
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 | Pref Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Landmark Prefix ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length of the option in
units of 8 octets. Set to 2 or 3.
Narayanan, et al. Expires September 5, 2007 [Page 12]
Internet-Draft DNAv6 March 2007
Pref Length
An 8 bit unsigned integer representing the number of bits in the
prefix to be used for matching.
Reserved
A 38 bit unused field. It MUST be initialised to zero by the
sender, and ignored by the receiver.
Prefix
A prefix being used by the host currently for a global IPv6
address, padded at the right with zeros. If the prefix length is
less than 65 bits, only 64 bits need be included, otherwise 128
bits are included.
4.3 Learned Prefix Option
The Learned Prefix Option (LPO) is used by a router to indicate
prefixes that are being advertised in PIOs by other routers on the
link, but not by itself.
Narayanan, et al. Expires September 5, 2007 [Page 13]
Internet-Draft DNAv6 March 2007
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 | Reserved | Prefix Len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Prefix Len N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix N +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length of the option in
units of 8 octets.
Prefix Len
Narayanan, et al. Expires September 5, 2007 [Page 14]
Internet-Draft DNAv6 March 2007
One or more fields (N) each consisting of an 8-bit unsigned
integer representing the prefix lengths of the following prefixes.
The Prefix Len fields are ordered the same as the Prefix fields so
that the first Prefix Len field represents the prefix length of
the prefix contained in the first prefix field, and so on.
Padding
Zero padding sufficient to align the following prefix field on an
8-octet boundary.
Prefix
One or more fields (N) each containing a 128-bit address
representing a prefix that has been heard on the link but is not
explicitly configured on this router.
Description
This option MUST only be included in a Router Advertisement. This
option contains prefixes that are being advertised on the link but
are not explicitly configured on the sending router. The router
MUST NOT include any prefixes with a zero valid lifetime in the
LPO.
4.4 Tentative option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (Requires IANA Allocation) suggest 17 (0x11)
Length
The length of the option (including the type and length fields) in
units of 8 octets.
Narayanan, et al. Expires September 5, 2007 [Page 15]
Internet-Draft DNAv6 March 2007
Link-Layer Address
The variable length link-layer address.
Description
The Tentative option contains the link-layer address of the sender
of the packet. It is used in the Neighbour Solicitation and
Router Solicitation packets.
5. DNA Operation
5.1 DNA Router Operation
Routers MUST collect information about the other routers that are
advertising on the link.
5.1.1 Data Structures
The routers maintain a set of conceptual data structures for each
interface to track the prefixes advertised by other routers on the
link, and also the set of DNA routers (the routers that will quickly
respond to RSs) on the link.
For each interface, routers maintain a list of all prefixes learned
from other routers on the link but not explicitly configured on the
router's own interface. The list will be referred to in this
document as "DNARouterLearnedPrefixList". Prefixes are learned by
their reception within Prefix Information Options [3] in Router
Advertisements. Prefixes in Learned Prefix Options (see Section 4.3)
MUST NOT update the contents of DNARouterLearnedPrefixList. For each
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 be achieved by storing the following information:
1. Prefix
2. Prefix length
3. Prefix valid lifetime
4. Expiry time
The expiry time for entries in DNARouterLearnedPrefixList is 3 times
maximum of MaxRtrAdvInterval after the last received Router
Advertisement affecting the entry, or the scheduled expiry of the
prefix valid lifetime, whichever is earlier.
Narayanan, et al. Expires September 5, 2007 [Page 16]
Internet-Draft DNAv6 March 2007
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
as "DNARouterList". For each router from which a Router
Advertisement is received with the DNAAware flag set, the following
information MUST be stored:
1. Link-local source address of advertising router
2. Token equal to the first 64 bits of an SHA-1 hash of the above
address
3. Expiry time
Each router MUST include itself in the DNARouterList and generate a
token for itself as described above based on the link-local address
used in its RA messages.
The expiry time for entries in DNARouterList is 3 times maximum of
MaxRtrAdvInterval after the last received Router Advertisement
affecting the entry.
5.1.2 Router Configuration Variables
A DNAv6 router MUST allow for the following conceptual variables to
be configured by the system management. Default values are set to
ease configuration load.
UnicastRAInterval
The interval corresponding to the maximum average rate of Router
Solicitations that the router is prepared to service with unicast
responses. This is the interval at which the token bucket
controlling the unicast responses is replenished.
Default: 50 milliseconds
MaxUnicastRABurst
The maximum size burst of Router Solicitations that the router is
prepared to service with unicast responses. This is the maximum
number of tokens allowed in the token bucket controlling the
unicast responses.
Default: 20
Narayanan, et al. Expires September 5, 2007 [Page 17]
Internet-Draft DNAv6 March 2007
RASeparation
The separation between responses from different routers on the
same link to a single Router Solicitation.
Default: 20 milliseconds
MulticastRADelay
The delay to be introduced when scheduling a multicast RA in
response to a RS message when the token bucket is empty.
Default: 3000 milliseconds
FastRAThreshold
The maximum number of fast responses that a host should receive
when soliciting for Router Advertisements.
Default: 3
5.1.3 Bootstrapping DNA Data Structures
As per RFC 2461 [3], when an interface on a host first starts up, it
SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations
separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of
the routers and prefixes active on the link. DNAv6 requires the
router to follow the same steps when its interface first starts up,
i.e., a router SHOULD transmit up to MAX_RTR_SOLICITATIONS Router
Solicitations separated by RTR_SOLICITATION_INTERVAL to learn quickly
about other routers and prefixes active on the link.
Upon startup, a router interface SHOULD also send a few unsolicited
Router Advertisements as recommended in Section 6.2.4 of RFC 2461
[3], in order to inform others routers on the link of its presence.
During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) *
RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface
both sends unsolicited Router Advertisements and responds to Router
Solicitations, but with a few restrictions on the message content.
Router Advertisements MUST NOT include any DNA specific options
except that the DNAAware flag MUST be set. The DNAAware flag is set
so that other routers will know to include this router in their
timing calculations for fast RA transmission. Other DNA options are
omitted because the router may have incomplete information during
bootstrap.
Narayanan, et al. Expires September 5, 2007 [Page 18]
Internet-Draft DNAv6 March 2007
During the bootstrap period, the Complete flag in Router
Advertisements MUST NOT be set.
During the bootstrap period, the timing of Router Advertisement
transmission is as specified in RFC 2461.
5.1.4 Processing Router Advertisements
When a router receives a Router Advertisement, it first validates the
RA as per the rules in RFC 2461, and then performs the actions
specified in RFC 2461. In addition, each valid Router Advertisement
is processed as follows:
If the DNAAware flag is set in the RA, the router checks if there is
an entry in its DNARouterList. Thus it looks up the source address
of the RA in that list and, if not found, a new entry is added to
DNARouterList, including the source address and a token equal to the
first 64 bits of an SHA-1 hash of the source address. The entry's
expiry time is updated.
Regardless of the state of the DNAAware flag, each PIO in the RA is
examined. If the prefix is not in the router's
DNARouterLearnedPrefixList and not in the router's AdvPrefixList [3],
it is added to the DNARouterLearnedPrefixList, and its expiry time is
set.
5.1.5 Processing Router Solicitations
The usual response to a Router Solicitation SHOULD be a unicast RA.
However, to keep control of the rate of unicast RAs sent, a token
bucket is used. The token bucket is filled at one token every
UnicastRAInterval. A maximum of MaxUnicastRABurst tokens are stored.
When a Router Solicitation is received, the router checks if it is
possible to send a unicast response. A unicast response requires
that the following conditions to be met:
o A unicast send token is available.
o The source address of the Router Solicitation is NOT the
unspecified address (::).
If a unicast response is possible and the Router Solicitation
contains a Landmark Option whose prefix is included in
DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send
an abbreviated Router Advertisement.This abbreviated advertisement
includes the Landmark prefix in a PIO if the prefix is in the
AdvPrefixList or in a LPO if the prefix is found in the
Narayanan, et al. Expires September 5, 2007 [Page 19]
Internet-Draft DNAv6 March 2007
DNAROuterLearnedPrefixList, plus the base RA header and any SEND
options as appropriate. The DNAAware flag MUST be set. The Complete
flag MUST NOT be set. This is the one exception where the smallest
prefix MAY be omitted as the landmark option implies that link change
has not occured and that the previously received smallest prefix is
still current.
If there is NO Landmark Option in the received Router Solicitation or
it contains a Landmark Option whose prefix is NOT included in
DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is
not possible, then the router SHOULD generate a Complete RA as
specified in Section 5.1.6. The Router Advertisement MUST include
the smallest prefix(es), as described in Section 5.1.7.
If a unicast response is possible, then a token is removed and the
Router Advertisement is scheduled for transmission as specified in
Section 5.1.8.
If a unicast response is not possible and there is no multicast RA
already scheduled for transmission in the next MulticastRADelay the
RA MUST be sent to the link-scoped all-nodes multicast address at the
current time plus MulticastRADelay.
If a unicast response is not possible but there is a multicast RA
already scheduled for transmission in the next MulticastRADelay, then
the Router Solicitation MUST be silently discarded.
All Router Advertisements sent by a DNA router MUST have the "D" flag
set so that hosts processing them know that they can count on the
content being interpretable according to this specification.
5.1.6 Complete Router Advertisements
A CompleteRA is formed as follows:
Starting with a Router Advertisement with all fixed options (MTU,
Advertisement Interval, flags, etc.), the DNAAware flag is set. As
many Prefix Information Options for explicitly configured prefixes as
will fit are added to the Router Advertisement. If there is
sufficient room, a Learned Prefix Option as defined in Section 4.3
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
link due to MTU or administrative limitations. If all Prefix
Information Options and a Learned Prefix Option containing all of the
learned prefixes were included in the RA, then the Complete flag in
the Router Advertisement header is set.
Narayanan, et al. Expires September 5, 2007 [Page 20]
Internet-Draft DNAv6 March 2007
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
into an RA, the smallest prefix(es) MUST be included.
5.1.7 Inclusion of smallest prefixes
The numerically smallest prefix stored in either of
DNARouterLearnedPrefixList or AdvPrefixList whose lifetime is greater
than 3 times maximum of MaxRtrAdvInterval is selected as the
representative of the set of prefixes advertised on the link. For
comparing prefixes, they are padded to the right with zeros to make
them 128 bit unsigned integers.
This smallest prefix may be included in the RA in either a PIO or LPO
as appropriate. Even when stateful address configuration (DHCPv6) is
used, the routers MUST be configured with one prefix, so that the
smallest prefix can be included in the RA messages. Note that this
smallest prefix is the smallest of all the prefixes configured on the
routers on the link and may not be the smallest prefix used in the
link through stateful address configuration.
5.1.7.1 Changing the smallest prefix
When either a new prefix is added to a link that is numerically
smaller than all those previously advertised or the lifetime of the
current smallest prefix falls below 3 times maximum of
MaxRtrAdvInterval, a new smallest prefix SHOULD be determined. In
order to ensure that there is overlap between consecutive RAs on the
link, the old smallest prefix must continue to be advertised for some
time alongside the new smallest prefix.
For the purposes of propagating information, it is assumed that after
three advertisements of a change, all routers have been made aware of
the change.
If the instant that a router sends its first unsolicited
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
have received it. Thus by time T + 3 times maximum of
MaxRtrAdvInterval, all routers on the link should have also sent at
least one advertisement with the new smallest prefix list.
3 times maximum of MaxRtrAdvInterval after first sending an
advertisement with a new smallest prefix it is safe to consider the
old smallest prefix gone and omit the corresponding prefix from RAs
if desired.
Narayanan, et al. Expires September 5, 2007 [Page 21]
Internet-Draft DNAv6 March 2007
Following a change of smallest prefix, the old smallest prefix MUST
be included in RAs for the following 3 times maximum of
MaxRtrAdvInterval. If the smallest prefix changes multiple times
with the 3 times maximum of MaxRtrAdvInterval time window, the RA
SHOULD include all of the smallest prefixes that were advertised
during that time window.
5.1.7.1.1 Non-Prefix link identifiers
Although this memo only discusses the use of prefixes as "link
identifier", a future specification or ammendment may describe a
mechanism to select a "link identifier" that is not a prefix.
Information from the Learned Prefix Option is only stored in
DNAHostPrefixList, and is only used for DNA purposes. Because a
length field is used, it is possible to carry any variable length
identifier less than or equal to 128 bits in an LPO and store it in
DNAHostPrefixList (Section 5.2.1). To avoid any collision to
prefixes, an future non-prefix link identifier MUST be 128 bits long
and can be included in the LPO of a RA message.
Following a change of link identifier, the old link identifier MUST
be included in RAs in an LPO for the following 3 times maximum of
MaxRtrAdvInterval.
Future specifications are advised NOT to treat the information in an
LPO as prefixes such as they would the prefixes found in a Prefix
Information Option. Future specifications are also advised NOT to
assume that the entries in a host's DNAHostPrefixList are actual
prefixes in use on the link.
5.1.8 Scheduling Fast Router Advertisements
RAs may need to be delayed to avoid collisions in the case that there
is more than one router on a link. The delay is calculated by
determining a ranking for the router for the received RS, and
multiplying that by RASeparation.
A Host Token is needed from the RS to calculate the router's ranking.
The first 64 bits of an SHA-1 hash of the source address of the RS
MUST be used as the RS host token.
A router's ranking is determined by taking the XOR of the RS Host
Token and each of the stored Router Tokens. The results of these XOR
operations are sorted lowest to highest. The router corresponding to
the first entry in the sorted list is ranked zero, the second, one,
and so on.
Narayanan, et al. Expires September 5, 2007 [Page 22]
Internet-Draft DNAv6 March 2007
Note: it is not necessary for a router to actually sort the whole
list. Each router just needs to determine its own position in the
sorted list.
If Rank < FastRAThreshold, then the RA MUST be scheduled for
transmission in Rank * RASeparation milliseconds. When the router is
ranked as zero, the resulting delay is zero, thus the RA SHOULD be
sent immediately.
If Rank >= FastRAThreshold, then the RA MUST be replaced with a
Complete RA, if it is not one already, and scheduled for multicast
transmission as in RFC 2461.
5.1.9 Scheduling Unsolicited Router Advertisements
Unsolicited router advertisements MUST be scheduled as per RFC 2461.
The "D" flag in the RA header MUST be set.
They MAY be Complete RAs or MAY include only a subset of the
configured prefixes, but MUST include the smallest prefix.
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
absence of that overlap can be used to infer link change.
5.1.10 Removing a Prefix from an Interface
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
router should treat it as though it has just learned a prefix that is
not explicitly configured on it. After sending the last RA
containing the prefix in a PIO, the router MUST add the prefix to the
DNARouterLearnedPrefixList and set it to expire in 3 times maximum of
MaxRtrAdvInterval or at the expiry of the last advertised valid
lifetime, whichever is earlier. This ensures that to hosts there
will be overlap in the prefixes in the RAs they see and prevent them
from incorrectly interpreting changed prefixes as movement.
5.1.10.1 Early Removal of the smallest Prefix
If the smallest prefix is to be withdrawn early from a link, that is
before the expiry of its previously advertised valid lifetime, it
MUST be advertised for at least 3 times maximum of MaxRtrAdvInterval
with a valid lifetime of less than 3 times maximum of
MaxRtrAdvInterval. This ensures that all of the other routers are
notified to begin the process of changing the smallest prefix as
well, and hosts will always see overlap between the prefixes in
Narayanan, et al. Expires September 5, 2007 [Page 23]
Internet-Draft DNAv6 March 2007
consecutive RAs and thus not mistake an RA for an indication of link
change.
5.1.11 Prefix Reassignment
A prefix whose lifetime has expired after counting down in real time
for at least 3 times maximum of MaxRtrAdvInterval may be reassigned
to another link immediately after expiry. If a prefix is withdrawn
from a link without counting down to the expiry of its valid
lifetime, it SHOULD NOT be reassigned to another link for at least 3
times maximum of MaxRtrAdvInterval or until the original expiry time,
whichever is earlier. This gives sufficient time for other routers
that have learned the prefix to expire it, and for hosts that have
seen advertisements from those routers to expire the prefix as well.
Earlier reassignment may result in hosts that move from between the
old and new links failing to detect the movement.
When the host is sure that the prefix list is complete, a false
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
'link UP' event. We may solve the renumbering problem with minor
modification like below.
When a router starts advertising a new prefix, for the time being,
every time the router advertises a new prefix in an RA, it includes
at least one old prefix in the same RA. The old prefix assures that
the host doesn't falsely assume a link change because of a new
prefix. After a while, hosts will recognize the new prefix as the
one assigned to the current link and update its prefix list.
In this way, we may provide a fast and robust solution. If a host
can make the Complete Prefix List with certainty, it can check for
link change fast. Otherwise, it can fall back on a slow but robust
scheme. It is up to the host to decide which scheme to use.
5.2 DNA Host Operation
Hosts collect information about the prefixes available on the link to
which they are connected to facilitate change detection.
5.2.1 Data Structures
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
here as the "DNAHostPrefixList". All prefixes SHOULD be stored,
however an upper bound MUST be placed on the number stored to prevent
overflow. For each prefix stored the host MUST store the following
Narayanan, et al. Expires September 5, 2007 [Page 24]
Internet-Draft DNAv6 March 2007
information:
1. Prefix
2. Prefix length
3. Expiry time
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
moved to a new link, when it receives advertisements from a non-DNA
router.
Prefix entries in the DNAHostPrefixList expire and MUST be removed 3
times maximum of MaxRtrAdvInterval after they are last seen in a
received Router Advertisement (in either a PIO or LPO) or at the
expiry of the valid lifetime of the prefix, whichever is earlier.
Host MUST also maintain a boolean flag, DNARAReceivedFlag, indicating
whether or not the host received a DNA RA message (RA message with
the "D" flag set) on this link. This value is initialized to zero
everytime a link change happens and is set to 1 when the first DNA RA
message is received.
Hosts SHOULD also maintain a "Landmark Prefix" as described in
Section 5.2.4.
5.2.2 Host Configuration Variables
Hosts MUST make use of the following conceptual variables and they
SHOULD be configurable:
DNASameLinkDADFlag
Boolean value indicating whether or not a host should re-run DAD
when DNA indicates that link change has not occurred.
Default: False
5.2.3 Detecting Network Attachment Steps
An IPv6 host SHOULD follow the following steps when they receive a
DNA Hint indicating the possibility of link change.
1. Mark all the IPv6 addresses in use as optimistic. Set
DNARAReceivedFlag to zero.
Narayanan, et al. Expires September 5, 2007 [Page 25]
Internet-Draft DNAv6 March 2007
2. Set all Neighbor Cache entries for routers on its Default Router
List to STALE.
3. Send router solicitation. (See Section 5.2.5).
4. Receive router advertisement(s).
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
currently exist.
6. Process received router advertisement. (See Section 5.2.6).
7. If the link has changed
Change the IP configuration parameters of the host (see
Section 5.2.7).
8. If the link has NOT changed
Restore the address configuration state of all the IPv6
addresses known to be on the link.
9. Update default routers list and their reachability information
(see Section 5.2.6.3).
5.2.4 Selection of a Landmark Prefix
For each interface, hosts SHOULD choose a prefix to use as a Landmark
Prefix in Router Solicitations. The following rules are used in
selecting the landmark prefix:
The prefix MUST have a non-zero valid lifetime. If the valid
lifetime of a previously selected Landmark Prefix expires, a new
Landmark Prefix MUST be selected.
The prefix MUST be one of those that the hosts has used to assign
a non-link-local address to itself
The prefix SHOULD be chosen as the one with the longest preferred
lifetime, but it is not necessary to switch to different prefix if
the preferred lifetime of the current landmark prefix changes.
5.2.5 Sending Router Solicitations
Upon the occurrence of a Layer 2 link-up event notification, hosts
Narayanan, et al. Expires September 5, 2007 [Page 26]
Internet-Draft DNAv6 March 2007
SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting
and/or hysteresis to this behaviour as appropriate to the link
technology subject to the reliability of the DNA Hints.
When the host receives a link UP notification from its link layer, it
sets time_last_linkUP_received to the current time.
The host also uses this to trigger sending an RS, subject to the rate
limitations in [3]. Since there is no natural limit on how
frequently the link UP notifications might be generated, we take the
conservative approach that even if the host establishes new link
layer connectivity very often, under no circumstances should it send
Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL
as specified by RFC 2461 [3].
If the RS does not result in the host receiving at least one RA with
at least one valid prefix, then the host can retransmit the RS. It
is allowed to multicast up to MAX_RTR_SOLICITATIONS RS messages
spaced RTR_SOLICITATION_INTERVAL apart as per RFC 2461 [3].
Note that if link-layer notifications are reliable, a host can reset
the number of sent Router Solicitations to 0, while still maintaining
RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is
necessary so that after each link up notification, the host is
allowed to send MAX_RTR_SOLICITATIONS to reliably discover the,
possibly new, prefix list.
Hosts SHOULD include a Landmark Option (LO) in the RS message with
the landmark prefix chosen based on the rules in Section 5.2.4.
Hosts SHOULD include a tentative source link layer address option
(TO) in the RS message Section 5.3. The router solicitation message
is sent to the All_Routers_Multicast address and the source address
MUST be the link local address of the host.
The host MUST consider its link local address to be in the
"Optimistic" state for duplicate address detection [5] until either
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
duplicate address detection for the address.
5.2.6 Processing Router Advertisements
When the host receives a Router Advertisement, the host checks for
the following conditions in the given order and derives the
associated conclusions given below:
Narayanan, et al. Expires September 5, 2007 [Page 27]
Internet-Draft DNAv6 March 2007
If the RA includes a prefix that matches an entry in
DNAHostPrefixList, then the host can conclude that no link change
has occurred and the current configuration can be assumed to still
be current.
If the RA is a Complete RA, as indicated by the "Complete" flag in
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
the host can conclude that it has changed link and SHOULD initiate
re-configuration using the information in the received Router
Advertisement.
If the RA is a DNA RA, as indicated by the "D" flag set in the RA
header, previously a DNA RA was received on this link as indicated
by the DNARAReceivedFlag being set to 1, and there are no prefixes
included in it in either a PIO or LPO that are also in the host's
DNAHostPrefixList, then the host can conclude that it has changed
link and SHOULD initiate re-configuration using the information in
the received Router Advertisement.
If the host has the complete prefix list (CPL) and the RA does NOT
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
and use the information in the received RA to configure itself.
If the host doesn't have the complete prefix list (CPL), the
received RA is not complete, contains no prefixes that are stored
in DNAHostPrefixList, does not contain a Landmark Option that
matches a corresponding option in the most recent RS, then the
host SHOULD send RS/RA exchange until num_RS_RA is equal to
NumRSRAComplete to create a new CPL and compare it with the
already known prefixes. If after NumRSRAComplete exchanges still
no prefix received in either a PIO or LPO of the RAs match known
prefixes, the host MUST conclude link change. If a matching
prefix is received in the RAs, then the host MUST conclude that no
link change has occured.
If the received RA has the "D" flag set, then set
DNARAReceivedFlag to one.
5.2.6.1 Pseudocode
IF (Receive RA contains a prefix matching a prefix in
DNAHostPrefixList) THEN
{
Narayanan, et al. Expires September 5, 2007 [Page 28]
Internet-Draft DNAv6 March 2007
/* This case covers the landmark prefix being included in the RA,
smallest prefix included in RA or CompleteRA message containg all
prefixes*/
No link change has occured.
RETURN; // Don't have to do the following checks.
}
IF (Receive RA is a CompleteRA) THEN
{
/* We already checked if there are any matching prefix before.
Since this is a CompleteRA, implies link-change.*/
Link change has occured.
RETURN; // Don't have to do the following checks.
}
IF (Receive RA is a DNA RA) THEN
{
/* We already checked if there are any matching prefix before.
Since this is a DNA RA, Check if previous DNA RA was received.*/
IF (DNARAReceivedFlag is set) THEN
/* If we previously received a DNA RA and don't see an overlap in
the prefix list - the smallest prefix is different on this link -
that means link change */
{
Link change has occured.
RETURN; // Don't have to do the following checks.
}
}
IF (DNAHostPrefixList is marked as complete (i.e. the completeness
criteria is already met)) THEN
Narayanan, et al. Expires September 5, 2007 [Page 29]
Internet-Draft DNAv6 March 2007
{
/* We already checked if there are any matching prefix before.
Since the DNAHostPrefixList is complete, implies link-change.*/
Link change has occured.
RETURN; // Don't have to do the following checks.
}
Wait for NumRSRAComplete exchanges of RS/RA message to be done since
the previous link_up event.
IF (One of the received RA contains a prefix matching a prefix in
DNAHostPrefixList from before link UP event), THEN No link change has
occured ELSE link change has occured.
If the received RA has the "D" flag set, then set DNARAReceivedFlag
to one.
5.2.6.2 Maintaining the DNAHostPrefixList
If a Router Advertisement does not indicate a link change, the host
updates its DNAHostPrefixList, adding any new prefixes if necessary.
If the Router Advertisement has the C flag set, then the host SHOULD
make the DNAHostPrefixList match the contents of the advertisement
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
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
LPO.
If the Router Advertisement does not have the C flag set, then the
host SHOULD add any new prefixes and update expiry times as above,
but SHOULD NOT remove any entries from DNAHostPrefixList.
When initiating reconfiguration due to link change, the host MUST
remove all prefixes in the DNAHostPrefixList and repopulate it with
the prefixes in the Prefix Information Options and Learned Prefix
Option, if any, in the RA.
In addition, the host maintains previous DNAHostPrefixList. It is
per interface since there are some security issues when merging
across interfaces.
The operations on DNAHostPrefixList is to create a new one, discard
Narayanan, et al. Expires September 5, 2007 [Page 30]
Internet-Draft DNAv6 March 2007
one, and merge two of them together. The issues with merging are
discussed in the next sub-section.
For each interface, the host maintains the last time a valid RA was
received (called time_last_RA_received in this document), which
actually ignores RAs without prefix options, and the last time a link
UP notification was received from the link layer on the host (called
time_last_linkUP_received in this document). Together these two
conceptual variables serve to identify when a RA containing disjoint
prefixes can't be due to being attached to a new link, because there
was no link UP notification.
For each interface, the host also maintains a counter (called
num_RS_RA) which counts how many successful RS/RA exchanges have been
accomplished since the last time the host moved to a different link.
The host declares "one successful RS/RA exchange" is accomplished
after it sends an RS, waits for MinRAWait seconds and receives a
positive number of resulting RAs. At least one RA (with at least one
prefix) should be received. After the RS, if a link UP event occurs
before MinRAWait seconds expire, the host should not assume that a
successful RS/RA exchange is accomplished. This counter is used to
determine when DNAHostPrefixList is considered to be complete. The
host SHOULD conclude that the prefix list is complete when
NumRSRAComplete number of RS/RA exchanges have been completed or a RA
message with the complete bit set is received. The complete
DNAHostPrefixList is also refered to as CPL ( Complete Prefix List).
After NumRSRAComplete RS/ RA exchange, the host will generate the
Complete Prefix List if there is no packet loss. Even though some
packet loss may cause an Incomplete Prefix List, there is a further
chance for the host to get the missing prefixes before it receives
link UP notification, i.e. moves to another PoA. Even if the host
moves to another PoA with Incomplete Prefix List,but if it has not
changed link, there is good chance that the first RA may contain a
prefix from its (incomplete) prefix list. Considering all those
above, even if the host performs only one RS/ RA exchange, it will be
rather rare for the host to falsely assume a link change. Moreover,
even in case of false detection, there would be no connectivity
disruption, because Incomplete Prefix List causes only additional
signaling.
5.2.6.2.1 Merging DNAHostPrefixList
When a host has been collecting information about a potentially
different link in its Current DNAHostPrefixList, and it discovers
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
single new object. Since the DNAHostPrefixList contains the most
Narayanan, et al. Expires September 5, 2007 [Page 31]
Internet-Draft DNAv6 March 2007
recent information, any information contained in it will override the
information in the old DNAHostPrefixList, for example the remaining
lifetimes for the prefixes. When the two objects contain different
pieces of information, for instance different prefixes or default
routers, the union of these are used in the resulting merged object.
5.2.6.3 Router Reachability Detection and Default Router Selection
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
routers that responded. Such reachability is necessary for the host
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
whether the messages are addressed to multicast or unicast address
will have different reachability implications. The reachability
implications from the hosts' perspective for the four different
message exchanges defined by RFC 2461 [3] are presented in the table
below. The host can confirm bi-directional reachability from the
neighbor discovery or router discovery message exchanges except when
a multicast RA is received at the host for its RS message. In this
case, using IPv6 Neighbour Discovery procedures, the host cannot know
whether the multicast RA is in response to its solicitation message
or whether it is a periodic un-solicited transmission from the router
[3].
+-----------------+----+----+----+-----+
| Exchanges: |Upstream |Downstream|
+-----------------+----+----+----+-----+
| multicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+
| unicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+
| RS/multicast RA | N | Y |
+-----------------+----+----+----+-----+
| RS/unicast RA | Y | Y |
+-----------------+----+----+----+-----+
If the destination address of the received RA is a unicast address,
the host knows the router heard its RS, and therefore that the host
has reachability with the router.
Prior to sending a DNA RS in response to an indication of link
change, the host SHOULD set all Neighbor Cache entries for routers on
its Default Router List to STALE. When the host receives an RA in
reply to the RS, the host SHOULD mark that router's Neighbor Cache
Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the
REACHABLE state if one does not currently exist.
Narayanan, et al. Expires September 5, 2007 [Page 32]
Internet-Draft DNAv6 March 2007
The host SHOULD also update its Default Router List in the following
fashion. If any of the routers returning RAs are already on the
default router list, the host SHOULD use the information in the RA to
update the Default Route List entry with the new information. The
host SHOULD add entries to the Default Router List for any routers
returning RAs that are not on the list. The host SHOULD confine
selection of a router from the Default Router List to those routers
whose Neighbor Cache entries are in the REACHABLE state. Note that
the Default Router List SHOULD be updated as described here
regardless of whether the RA indicates that the host has changed to a
new IP link, since changes in router reachability are possible on
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
to its current default router while the RA solicitation is in
progress and if reachability with the current default router is
unchanged, there should be no change in default router after the RA
solicitation completes. If the current default router is still
reachable, it will forward the packets.
5.2.7 DNA and Address Configuration
When a host moves to a new point of attachment, a potential exists
for a change in the validity of its unicast and multicast addresses
on that network interface. In this section, host processing for
address configuration is specified. The section considers both
statelessly and statefully configured addresses.
5.2.7.1 Duplicate Address Detection
A DNA host MUST support optimistic Duplicate Address Detection [5]
for autoconfiguring unicast link local addresses. If a DNA host uses
address autoconfiguration [7] for global unicast addresses, the DNA
host MUST support optimistic Duplicate Address Detection for
autoconfiguring global unicast addresses.
5.2.7.2 DNA and the Address Autoconfiguration State Machine
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
possible that a change in the reachability of the addresses
associated with that interface may occur. Upon detection of such 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
interface in the following way (address state designations follow RFC
2461):
Narayanan, et al. Expires September 5, 2007 [Page 33]
Internet-Draft DNAv6 March 2007
o Addresses in the "Preferred" state are moved to the "Optimistic"
state, but the host defers sending out an NS to initiate Duplicate
Address Detection.
o Addresses in the "Optimistic" state remain in the "Optimistic"
state, but the host defers sending out an NS to initiate Duplicate
Address Detection.
o Addresses in the "Deprecated" state remain in the "Deprecated"
state.
o No addresses should be in the "Tentative" state, since this state
is unnecessary for nodes that support optimistic Duplicate Address
Detection.
A host MUST keep track of which "Preferred" addresses are moved to
the "Optimistic" state, so it is possible to know which addresses
were in the "Preferred" state and which were in the "Optimistic"
state prior to the change in point of attachment.
In order to perform the DNA transaction, the DNA host SHOULD select
one of the unicast link local addresses that was in the "Preferred"
state prior to switching to "Optimistic" and utilize that as the
source address on the DNA RS. If the host had no "Preferred" unicast
link local address but did have an address in the "Optimistic" state,
it MUST utilize such an address as the source address. If the host
currently has no unicast link local addresses, it MUST construct one
and put it into the "Optimistic" state and note this address as
having been in the "Optimistic" state previously, but defer sending
the NS to confirm. Note that the presence of a duplicate unicast
link local address on the link will not interfere with the ability of
the link to route a unicast DNA RA from the router back to the host
nor will it result in corruption of the router's neighbor cache,
because the TSLLA option is included in the RS and is utilized by the
router on the RA frame without changing the neighbor cache.
When the host receives unicast or multicast RAs from the router, if
the host determines from the received RAs that it has moved to a new
link, the host MUST immediately move all unicast global addresses to
the "Deprecated" state and configure new addresses using the subnet
prefixes obtained from the RA. For all unicast link local addresses,
the host MUST initiate NS signaling for optimistic Duplicate Address
Detection to confirm the uniqueness of the unicast link local
addresses on the new link.
If the host determines from the received RAs that it has not moved to
a new link (i.e. the link has not changed) and the previous state of
an address was "Optimistic", then the host MUST send an NS to confirm
Narayanan, et al. Expires September 5, 2007 [Page 34]
Internet-Draft DNAv6 March 2007
that the address is unique on the link. This is required because
optimistic Duplicate Address Detection may not have completed on the
previous point of attachment, so the host may not have confirmed
address uniqueness. If the previous state of an address was
"Preferred", whether or not the host initiates optimistic Duplicate
Address Detection depends on the configurable DNASameLinkDADFlag
flag. A host MUST forgo sending an NS to confirm uniqueness if the
value of the DNASameLinkDAD flag is False. If, however, the
DNASameLinkDAD flag is True, the host MUST perform optimistic
duplicate address detection on its unicast link local and unicast
global addresses to determine address uniqueness.
5.2.7.3 DNA and Statefully Configured Addresses
The DHCPv6 specification [16] requires hosts to send a DHCPv6 CONFIRM
message when a change in point of attachment is detected. Since 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 message when a DNA RA is received, to avoid excessive
signaling. If, however, a non-DNA RA is received, the host SHOULD
use the DHCPv6 CONFIRM message as described in RFC 3315 [16] rather
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
has moved to a new link. If the CONFIRM message validates the
addresses, the host can continue to use them.
When a DNA RA is received and the received RA indicates that the host
has not moved to a new link, the host SHOULD apply the same rules to
interpreting the 'M' flag in the received RA and any subsequently
received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA
is received with the 'M' flag set, then the 'M' flag value is copied
into the ManagedFlag, and if the ManagedFlag changes from False to
True the host should run DHCPv6, but if the ManagedFlag changes from
True to False, the host should continue to run DHCPv6. If, however,
the value of the ManagedFlag remains the same both before and after
the change in point of attachment on the same link has been
confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain
new addresses, since the old addresses will continue to be valid.
If the DNA RA indicates that the host has moved to a new link or the
DHCPv6 CONFIRM indicates that the addresses are invalid, the host
MUST move its old addresses to the "Deprecated" state and MUST run
DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is
4-message exchange, however, this exchange allows for redundancy
(multiple DHCPv6 servers) without wasting addresses, as addresses are
only provisionally assigned to a host until the host chooses and
requests one of the provisionally assigned addresses. If the DNA
host supports the Rapid Commit Option [16], the host SHOULD use the
Narayanan, et al. Expires September 5, 2007 [Page 35]
Internet-Draft DNAv6 March 2007
Rapid Commit Option in order to shorten the exchange from 4 messages
to 2 messages.
5.2.7.4 Packet Delivery During DNA
The specification of packet delivery before, during, and immediately
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
on the mobility management protocols (if any) available to the host's
stack.
5.2.7.5 Multicast Address Configuration
Multicast routers on a link are aware of which groups are in use
within a link. This information is used to undertake initiation of
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
link, no further action is required for multicast addresses to which
the host has subscribed using MLD Report [17]. In particular, the
host MUST NOT perform MLD signaling for any multicast addresses
unless such signaling was not performed prior to movement to the new
point of attachment. For example, if an address is put into the
"Optimistic" state prior to movement but the MLD Report for the
Solicited_Node_Multicast_Address is not sent prior to movement to a
new point of attachment, the host MUST send the MLD Report on the new
point of attachment prior to performing optimistic Duplicate Address
Detection. The host SHOULD use the procedure described below for
sending an MLD Report.
If, on the other hand, the DNA RA indicates that the host has moved
to a new link, the host MUST issue a new MLD Report to the router for
subscribed multicast addresses. MLD signaling for the
Solicited_Node_Multicast_Addresses [7] MUST be sent prior to
performing signaling for optimistic DAD.
To avoid lengthy delays in address reconfiguration, it is RECOMMENDED
that the host send the MLD Report for newly configured addresses
immediately, as soon as the addresses have been constructed, rather
than waiting for a random backoff.
Hosts MUST defer MLD signaling until after the results of DNA have
confirmed whether or not a link change has occurred.
5.3 Tentative options for IPv6 ND
Narayanan, et al. Expires September 5, 2007 [Page 36]
Internet-Draft DNAv6 March 2007
5.3.1 Sending solicitations containing Tentative Options
Tentative Options may be sent in Router and Neighbour Solicitations,
as described below.
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
bemisinterpreted by legacy nodes.
Importantly, a node MUST NOT send a Tentative Option in the same
message where a Source Link-Layer Address Option is sent.
5.3.1.1 Sending Neighbour Solicitations with Tentative Options
Neighbour Solicitations sent to unicast addresses MAY contain a
Tentative Option.
Since delivery of a packet to a unicast destination requires prior
knowledge of the destination's hardware address, unicast Neighbour
Solicitation packets may only be sent to destinations for which a
neighbour cache entry already exists.
For example, if checking bidirectional reachability to a router, it
may be possible to send a Neighbour Solicitation with Tentative
Option to the router's advertised address.
As discussed in [3], the peer device may not have a cache entry even
if the soliciting host does, in which case reception of the Tentative
Option may create a neighbour cache entry, without the need for
neighbour discovering the original solicitor.
5.3.1.2 Sending Router Solicitations with Tentative Options
Any Router Solicitation from a Preferred, Deprecated or Optimistic
address MAY be sent with a Tentative Option [5].
An extension which allows Router Solicitations to be sent with a TO
from the unspecified address is described in Appendix A.
5.3.2 Receiving Tentative Options
Receiving a Tentative Option allows nodes to unicast responses to
solicitations without performing neighbour discovery.
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
link-layer address in the option matches the entry.
Narayanan, et al. Expires September 5, 2007 [Page 37]
Internet-Draft DNAv6 March 2007
Additionally, messages containing TO may be used to direct
advertisements to particular link-layer destinations without updating
neighbour cache entries. This is described in Appendix A.
Use of Tentative Options is only defined for Neighbour and Router
Solicitation messages.
In any other received message, the presence of the option is silently
ignored, that is, the packet is processed as if the option was not
present.
It is REQUIRED that the same validation algorithms for Neighbour and
Router Solicitations received with TO as in the IPv6 Neighbour
Discovery specification [3], are used.
In the case that a solicitation containing a Tentative Option is
received, The only processing differences occur in checking and
updating the neighbour cache entry. Particularly, there is no reason
to believe that the host will remain tentative after receiving a
responding advertisement.
Tentative Options do not overwrite existing neighbour cache entries
where the link-layer addresses of the option and entry differ.
If a solicitation from a unicast source address is received where no
difference exists between the TO and an existing neighbour cache
entry, the option MUST be treated as if it were an SLLAO after
message validation, and processed accordingly.
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
update the neighbour cache entry.
An extension which allows a direct advertisement to the soliciting
host without modifying the neighbour cache entry is described in
Appendix A.
5.3.2.1 Receiving Neighbour Solicitations containing Tentative Options
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
Solicitations with specified source addresses for which SLLAO is not
required.
A Neighbour Solicitation message received with a TO and an
unspecified source address MUST be silently discarded.
Upon reception of a Tentative Option in a Neighbour Solicitation for
Narayanan, et al. Expires September 5, 2007 [Page 38]
Internet-Draft DNAv6 March 2007
which the receiver has the Target Address configured, a node checks
to see if there is a neighbour cache entry with conflicting link-
layer address.
If no such entry exists, the neighbour cache of the receiver SHOULD
be updated, as if the Tentative Option was a SLLAO.
Sending of the solicited Neighbour Advertisement then proceeds
normally, as defined in section 7.2.4 of [3].
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
Neighbour Cache entry MUST NOT be modified.
5.3.2.2 Receiving Router Solicitations containing Tentative Options
In IPv6 Neighbour Discovery [3], responses to Router Solicitations
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.
Including a Tentative Option in the solicitation allows a router to
choose to send a packet directly to the link-layer address even in
situations where this would not normally be possible.
For Router Solicitations with unicast source addresses, neighbour
caches SHOULD be updated with the link-layer address from a Tentative
Option if there is no differing neighbour cache entry. In this case,
Router Advertisement continues as in Section 6.2.6 of [3].
For received solicitations with a differing link-layer address to
that stored in the neighbour cache, the node processes the
solicitation as defined in Section 6.2.6 of [3], except that the
Neighbour Cache entry MUST NOT be modified.
Each router can have its own configuration with respect to sending
RA, and the treatment of router and neighbor solicitations.
Different timers and constants might be used by different routers,
such as the delay between Router Advertisements or delay before
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
introduce more delay than the previous default r < title="Overlapping
Coverage"> If a host can be attached to different links at the same
time with the same interface, the host will probably listen to
different 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.
Narayanan, et al. Expires September 5, 2007 [Page 39]
Internet-Draft DNAv6 March 2007
Such a situation may happen in a wireless environment if the link
layer technology allows the MN to be simultaneously attached to
several points of attachment and if the coverage area of access
points are overlapping.
For the purposes of DNA, it is necessary to treat each of these
points-of-attachment separately, otherwise incorrect conclusions of
link-change may be made even if another of the link-layer connections
is valid.
When a host is participating in DNA on a link where multicast
snooping is in use, multicast packets may not be delivered to the
LAN-segment to which the host is attached until MLD signaling has
been performed [9][17] [11]. Where DNA relies upon multicast packet
delivery (for example, if a router needs to send a Neighbor
Solicitation to the host), its function will be degraded until after
an MLD report is sent.
Where it is possible that multicast snooping is in operation, hosts
MUST send MLD group joins (MLD reports) for solicited nodes'
addresses swiftly after starting DNA procedures.
Link partitioning occurs when a link's internal switching or relaying
hardware fails, or if the internal communications within a link are
prevented due to topology changes or wireless propagation.
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.
Where link partitioning is rare (for example, with wired
communication between routers on the link), existing router and
neighbor discovery procedures may be sufficient for detecting change.
6. Security Considerations
6.1 Attacks on the Token Bucket
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
link. For example, if a host sends one RS message every
UnicastRAInterval, and send a additional RS every third
UnicastRAInterval, the token bucket in the router(s) on the link will
drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units.
For the recommended values of UnicastRAInterval and
MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear
whether arrival of such RS messages can be recognized by the router
as a DoS attack. This attack can also be mitigated by aggregating
responses. Since only one aggregation is possible in this interval
due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able
Narayanan, et al. Expires September 5, 2007 [Page 40]
Internet-Draft DNAv6 March 2007
protect the tokens in the bucket.
6.2 Attacks on DNA Hosts
RFC 3756 outlines a collection of threats involving rouge routers.
Since DNAv6 requires a host to obtain trustworthy responses from
routers, such threats are relevant to DNAv6. In order to counter
such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure
router discovery.
6.3 Tentative options
The use of the Tentative Option in Neighbour and Router Solicitation
messages acts in a similar manner to SLLAO, updating neighbour cache
entries, in a way which causes packet transmission.
Particular care should be taken that transmission of messages
complies with existing IPv6 Neighbour Discovery Procedures, so that
unmodified hosts do not receive invalid messages.
An attacker may cause messages may be sent to another node by an
advertising node (a reflector), without creating any ongoing state on
the reflector.
This is attack requires one solicitation for each advertisement and
the advertisement has to go to a unicast MAC destination. That said,
the size of the advertisement may be significantly larger than the
solicitation, or the attacker and reflector may be on a medium with
greater available bandwidth than the victim.
For link-layers where it isn't possible to spoof the link-layer
source address this allows a slightly increased risk of reflection
attacks from nodes which are on-link.
Additionally, since a SEND host must always advertise using SEND
options and signatures, a non-SEND attacker may cause excess
computation on both a victim node and a router by causing SEND
advertisement messages to be transmitted to a particular MAC address
and the lall-nodes multicast. SEND specifies guidelines to hosts
receiving unsolicited advertisements in order to mitigate such
attacks [4].
While this is the same effect as experienced when accepting SLLAO
from non-SEND nodes, the lack of created neighbour cache entries on
the advertiser may make such attacks more difficult to trace.
Modification of Neighbour Discovery messages on the network is
possible, unless SEND is used. [4] provides a protocol specification
Narayanan, et al. Expires September 5, 2007 [Page 41]
Internet-Draft DNAv6 March 2007
in which soliciting nodes sign ND messages with a private key and use
addresses generated from this key.
Even if SEND is used, the lifetime of a neighbour cache entry may be
extended by continually replaying a solicitation message to a
particular router or hosts. Since this may be achieved for any
Neighbour or Router Solicitation message, corresponding
advertisements to the original transmitters of these solicitation
messages may occur.
SEND defines use of Timestamp values to protect a device from attack
through replay of previously sent messages. Although this applies to
Neighbour and Router Solicitation messages, granularity of the
timestamp allows the messages to be used for up to five minutes [4].
All Router and Neighbour Solicitations using SEND contain a Nonce
option, containing a random identifier octet string. Since SEND
messages are digitally signed, and may not be easily modified, replay
attacks will contain the same Nonce option, as was used in the
original solicitation.
6.4 Authorization and Detecting Network Attachment
When a host is determining if link change has occurred, it may
receive messages from devices with no advertised security mechanisms
purporting to be routers, nodes sending signed router advertisements
but with unknown delegation, or routers whose credentials need to be
checked [12]. Where a host wishes to configure an unsecured router,
it SHOULD confirm bidirectional reachability with the device, and it
MUST mark the device as unsecured as described in [4].
In any case, a secured router SHOULD be preferred over an unsecured
one, except where other factors (unreachability) make the router
unsuitable. Since secured routers' advertisement services may be
subject to attack, alternative (secured) reachability mechanisms from
upper layers, or secured reachability of other devices known to be on
the same link may be used to check reachability in the first
instance.
6.5 Addressing
While a DNA host is checking for link-change, and observing DAD, it
may receive a DAD defense NA from an unsecured source.
SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [4].
While deconfiguring the address is a valid action in the case where a
Narayanan, et al. Expires September 5, 2007 [Page 42]
Internet-Draft DNAv6 March 2007
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
a DAD defense NA message can only be a denial-of-service attempt.
6.6 DNA Hint Management Security
Events originating at other protocol layers may provide DNA Hints of
link change to network attachment detection systems. Two examples of
such events are TCP retransmission timeout and completion of link-
layer access procedures [20].
While DNA Hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat DNA Hints from
other protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be
triggered by untrusted messages, come from compromised sources (for
example 802.11 WEP Encryption [15]) or be inaccurate with regard to
network-layer state.
While these DNA Hints come from the host's own stack, such hints may
actually be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to
instigate DNA Hint delivery on a host or multiple hosts deliberately,
in order to prompt packet transmission, or configuration
modification.
Therefore, hosts SHOULD NOT change their configuration state based on
DNA Hints from other protocol layers. A host MAY adopt an
appropriate link change detection strategy based upon DNA Hints
received from other layers, with suitable caution and hysteresis.
7. IANA Considerations
This memo defines two new Neighbor Discovery [3] options, which must
be assigned Option Type values within the option numbering space for
Neighbor Discovery messages:
1. The Landmark option, described in Section 4.2; and
2. The Learned Prefix option, described in Section 4.3.
3. The tentative option, described in Section 4.4
8. Constants
Narayanan, et al. Expires September 5, 2007 [Page 43]
Internet-Draft DNAv6 March 2007
NumRSRAComplete
Number of RS/RA exchange messages necessary to declare the prefix
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 -04
o Edited the document to improve readability and clarity.
o Edited the document to make the distinction between what is
recommended by RFC 2461 and what is modified behavior for DNA.
(The flash renumbering sections were not touchted.)
10. Changes since -03
o A global replace of "1.5 hours" with "3 times maximum of
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.
Narayanan, et al. Expires September 5, 2007 [Page 44]
Internet-Draft DNAv6 March 2007
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.
11. 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,
MAX_CACHE_TIME to NumRSRAComplete, MinRAWait, MaxCacheTIme. Added
an open issue whether these should be variables or constants.
o Fixed some typos.
12. Open issues
1. Explain the idea of link identification better. The link is
identified by the "set of prefixes" and a prefix (either landmark
or smallest prefix) is used to identify the particular "set of
prefixes".
2. Do we need all of the router configuration variables?
3. Bootstrapping DNA data structures: Would be good to be more clear
about what is a change w.r.t. standard ND.
4. Future specificaitons MUST NOT: Can't make this sort of
reqirement. You can explain what the assumption/purpose is, but
you can't limit what future protocols do. Soln: The text has
been modified. But, we need text explaining the reasoning behind
recommendations.
5. 5.1.10: Removing a prefix from an interface: The first sentence
is unclear. 2461/2462 already have clear rules about what you do
if you stop advertisign prefixes, and hosts also have clear
rules. Is this document suggesting changes here? And note,
"stopping the advertising of a prefix" before it expires is bad
behavior. If you really mean to depracate it, advertise it with
a 0 lifetime first (this is clear in the other specs). Much of
the above is unclear to me because its not clear who is doing
what (which router? One receiving an RA, the one sending it, the
one proxying it or what?) Possible soln: We could remove section
5.1.10 under the assumption that RFC 2461 already handles the
issue. But, section 12 in RFC 2461 doesn't madate an particular
behavior.
Narayanan, et al. Expires September 5, 2007 [Page 45]
Internet-Draft DNAv6 March 2007
6. This docuemnt isn't always clear about whether it is mandating
new behavior or whether just suggesting how things ought to be.
7. The section Section 5.1.7 needs to be written better.
13. Contributors
This document is the result of merging four different working group
documents. The draft-ietf-dna-protocol-01.txt authored by James
Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock
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
for the complete prefix list mechanism described in this document.
The best current practice for hosts draft (draft-ietf-dna-hosts-03)
authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and
the tentative options (draft-ietf-dna-tentative-00) authored by Greg
Daley, Erik Normark and Nick Moore were also adopted into this
document.
14. Acknowledgments
The design presented in this document grew out of discussions among
the members of the DNA design team (JinHyeock Choi, Tero Kauppinen,
James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland).
The spirited debates on the design, and the advantages and dis-
advantages of various DNA solutions helped the creation of this
document.
Thanks to Syam Madanapalli who co-authored
draft-jinchoi-dna-protocol2 from which this draft draws ideas, as
well as providing feedback on draft-pentland-dna-protocol from which
most of the text for this draft comes.
Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol
and for helping to work out how to merge the two drafts into this
one.
Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli,
Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review
of draft-ietf-dna-protocol-01.
Thanks to Gabriel Montenegro for his review of
draft-pentland-dna-protocol.
Thanks also to other members of the DNA working group for their
comments that helped shape this work.
Narayanan, et al. Expires September 5, 2007 [Page 46]
Internet-Draft DNAv6 March 2007
15. References
15.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, April 2006.
15.2 Informative References
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462 2462, December 1998.
[8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[10] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC2463 2463, December 1998.
[11] Christensen, M., Kimball, K., and F. Solensky, "Considerations
for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12
(work in progress), February 2005.
[12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[13] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim,
"Candidate Access Router Discovery (CARD)", RFC 4066,
July 2005.
Narayanan, et al. Expires September 5, 2007 [Page 47]
Internet-Draft DNAv6 March 2007
[14] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[15] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE
Std 802.11, 1999.
[16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[17] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005.
[20] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-00 (work
in progress), September 2004.
[21] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004.
[22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005.
Authors' Addresses
Sathya Narayanan (editor)
Panasonic Princeton Laboratory
Two Research Way, 3rd Floor
Princeton, NJ 08540
USA
Phone: +1 609 734 7599
Email: sathya@Research.Panasonic.COM
Narayanan, et al. Expires September 5, 2007 [Page 48]
Internet-Draft DNAv6 March 2007
James Kempf
DoCoMo Communications Labs USA
USA
Phone:
Email: kempf@docomolabs-usa.com
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA
USA
Phone: +1 650 786 2921
Email: erik.nordmark@sun.com
Brett Pentland
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 5245
Email: brett.pentland@eng.monash.edu.au
JinHyeock Choi
Samsung Advanced Institute of Technology
PO Box 111
Suwon 440-600
Korea
Phone: +82-31-280-8194
Email: jinchoe@samsung.com
Narayanan, et al. Expires September 5, 2007 [Page 49]
Internet-Draft DNAv6 March 2007
Greg Daley
Centre for Telecommunications and Information Engineering
Department of Electrical adn Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 4655
Email: greg.daley@eng.monash.edu.au
Nicolas Montavont
LSIIT - Univerity Louis Pasteur
Pole API, bureau C444
Boulevard Sebastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 87
Email: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/
Nick 'Sharkey' Moore
Email: sharkey@zoic.org
Appendix A. Sending directed advertisements without the neighbour cache
In the case where an entry is unable to be added to the neighbour
cache, a node MAY send responses direct to the link-layer address
specified in the Tentative Option. Also, RS packets sent without a
specificed source address may potentially contain a Tentative Option.
In this case the unicast link-layer address from the solicitation MAY
be extracted from the Tentative Option and used as the destination of
the link-layer frame for a responding Router Advertisment.
Sending such a packet MUST NOT consult the neighbour or destination
caches for address.
Such packets SHOULD scheduled as if they were unicast advertisements
as specified in [3].
If an implementation can not send a Router Advertisement using
information from the Tentative Option i.e, without consulting the
neighbour cache, then it SHOULD behave as if the Tentative Option was
not present in the solicitation message.
Narayanan, et al. Expires September 5, 2007 [Page 50]
Internet-Draft DNAv6 March 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR,THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY),THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Narayanan, et al. Expires September 5, 2007 [Page 51]
