draft-ietf-dna-protocol-01.txt   draft-ietf-dna-protocol-02.txt 
DNA Working Group J. Kempf DNA Working Group S. Narayanan, Ed.
Internet-Draft DoCoMo Communications Labs USA Internet-Draft Panasonic
Expires: December 27, 2006 S. Narayanan Expires: April 23, 2007 October 20, 2006
Panasonic
E. Nordmark
Sun Microsystems
B. Pentland, Ed.
Monash University CTIE
JH. Choi
Samsung AIT
June 25, 2006
Detecting Network Attachment in IPv6 Networks (DNAv6) Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-ietf-dna-protocol-01.txt draft-ietf-dna-protocol-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 27, 2006. This Internet-Draft will expire on April 23, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Efficient detection of network attachment in IPv6 needs the following Efficient detection of network attachment in IPv6 needs the following
two components: a method for the host to query routers on the link to three components: a method for hosts to detect link change in the
identify the link (Link Identification) and a method for the routers presence of unmodified (non-DNAv6) routers, a method for the host to
on the link to consistently respond to such a query with minimal query routers on the link to identify the link (Link Identification)
delay (Fast RA). Solving the link identification based strictly on and a method for the routers on the link to consistently respond to
RFC 2461 is difficult because of the flexibility offered to routers such a query with minimal delay (Fast RA). Solving the link
in terms of prefixes advertised in a router advertisement (RA) identification based strictly on RFC 2461 is difficult because of the
message. Similarly, the random delay in responding to router flexibility offered to routers in terms of prefixes advertised in a
solicitation messages imposed by RFC 2461 makes to it difficult to router advertisement (RA) message. Similarly, the random delay in
receive an RA quickly. In this memo, an integrated solution is responding to router solicitation messages imposed by RFC 2461 makes
presented. Monitoring of prefixes by both hosts and routers is used it difficult to receive an RA quickly. In this memo, a mechanism
to achieve link identification while router advertisements are sent that requires the hosts to monitor all the prefixes advertised on the
rapidly in a deterministic order by combining router solicitation link and use it for link identification in the presence of non-DNAv6
source addresses with hash-based router tokens. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 6
3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 9
3.3 Complete Prefix List generation . . . . . . . . . . . . . 10
3.4 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 11
3.5 Tentative Source Link-Layer Address option (TO) . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 8 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 13
4.2 Prefix Information Option LinkID Bit . . . . . . . . . . . 9 4.2 Prefix Information Option LinkID Bit . . . . . . . . . . . 14
4.3 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10 4.3 Landmark Option . . . . . . . . . . . . . . . . . . . . . 14
4.4 Learned Prefix Option . . . . . . . . . . . . . . . . . . 12 4.4 Learned Prefix Option . . . . . . . . . . . . . . . . . . 16
4.5 Tentative option . . . . . . . . . . . . . . . . . . . . . 18
5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 13 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 13 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 19
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 14 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 19
5.1.2 Router Configuration Variables . . . . . . . . . . . . 15 5.1.2 Router Configuration Variables . . . . . . . . . . . . 20
5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 16 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 21
5.1.4 Processing Router Advertisements . . . . . . . . . . . 16 5.1.4 Processing Router Advertisements . . . . . . . . . . . 22
5.1.5 Processing Router Solicitations . . . . . . . . . . . 17 5.1.5 Processing Router Solicitations . . . . . . . . . . . 22
5.1.6 Complete Router Advertisements . . . . . . . . . . . . 18 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 23
5.1.7 LinkID . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.7 LinkID . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 19 5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 25
5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 20 5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 26
5.1.10 Removing a Prefix from an Interface . . . . . . . . 20 5.1.10 Removing a Prefix from an Interface . . . . . . . . 26
5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 21 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 26
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 27
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 27
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 28
5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 22 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 29
5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 23 5.2.4 Making use of Prior Information . . . . . . . . . . . 30
5.2.5 Processing Router Advertisements . . . . . . . . . . . 23 5.2.5 Selection of a Landmark Prefix . . . . . . . . . . . . 30
5.2.6 DNA and Address Configuration . . . . . . . . . . . . 25 5.2.6 Sending Router Solicitations . . . . . . . . . . . . . 31
5.2.7 Processing Router Advertisements . . . . . . . . . . . 32
5.2.8 DNA and Address Configuration . . . . . . . . . . . . 37
5.3 DNA without a 'link UP' notification . . . . . . . . . . . 41
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 29 6. Tentative options for IPv6 ND . . . . . . . . . . . . . . . 42
6.1 Non-DNA Host with DNA Routers . . . . . . . . . . . . . . 29 6.1 Sending solicitations containing Tentative Options . . . . 42
6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 29 6.1.1 Sending Neighbour Solicitations with Tentative
Options . . . . . . . . . . . . . . . . . . . . . . . 43
6.1.2 Sending Router Solicitations with Tentative Options . 43
6.2 Receiving Tentative Options . . . . . . . . . . . . . . . 43
6.2.1 Receiving Neighbour Solicitations containing
Tentative Options . . . . . . . . . . . . . . . . . . 44
6.2.2 Receiving Router Solicitations containing Tentative
Options . . . . . . . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . 29 7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . 45
7.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 29 7.1 Hints Due to Network Layer Messages . . . . . . . . . . . 46
7.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 29 7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 46
7.3 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 47
7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 47
7.5 Hint Management for Inactive Hosts . . . . . . . . . . . . 48
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 8. Complications to Detecting Network Attachment . . . . . . . 48
8.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 48
8.2 Router Configurations . . . . . . . . . . . . . . . . . . 48
8.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 49
8.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 49
8.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 49
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . 50
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 50
10.1 Normative References . . . . . . . . . . . . . . . . . . 31 9.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 50
10.2 Informative References . . . . . . . . . . . . . . . . . 31 9.3 Tentative options . . . . . . . . . . . . . . . . . . . . 50
9.4 Authorization and Detecting Network Attachment . . . . . . 51
9.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 52
9.6 Hint Management Security . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53
A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 33 11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . 35 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1 Normative References . . . . . . . . . . . . . . . . . . 54
14.2 Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56
A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 58
B. Sending directed advertisements without the neighbour
cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . . 60
1. Introduction 1. Introduction
The proposed scheme in this memo is built upon the following This memo defines a mechanism for an IPv6 host to detect link-change
solutions catalogued in [16]: Complete RA is used for the link in the presence of unmodified (non-DNAv6) routers and proposes new
identification, and Hash-based Fast RA is used to achieve fast extensions to "IPv6 Neighbor Discovery" [3] to increase the
response to RS messages. Aspects of prefix-based LinkID and efficiency of link-change detection in the presence of DNAv6 enabled
Requested Landmark are included to allow for a decrease in the packet routers. The new extensions use complete RA for link identification,
sizes associated with Complete RA. and Hash-based Fast RA to achieve fast response to RS messages.
Aspects of prefix-based LinkID and Requested Landmark are included to
allow for a decrease in the packet sizes associated with Complete RA.
This memo also defines a new Tentative option (TO) which is designed
to replace the existing Source Link-Layer Address Options available
in IPv6 Neighbor Discovery when the host is performing Optimistic
DAD.
The rest of the document refers to this approach by the term "DNAv6". The rest of the document refers to the proposed mechanisms by the
term "DNAv6".
2. Terms and Abbreviations 2. Terms and Abbreviations
There is an existing DNA terminology draft [13]. This draft does not There is an existing DNA terminology draft [21]. [Editor's note: Do
we have to bring in the terms from this draft?] This draft does not
introduce any new terminology not already used by existing drafts. introduce any new terminology not already used by existing drafts.
The term "link" is used as defined in RFC 2460 [2]. NOTE: this is The term "link" is used as defined in RFC 2460 [2]. NOTE: this is
completely different from the term "link" as used by IEEE 802, etc. completely different from the term "link" as used by IEEE 802, etc.
Access network: A network where hosts are present. Especially, a
network used for the support of visiting wireless hosts.
Attachment: The process of entering a new cell. Attachment (and
detachment) may cause a link-change.
Cell: A system constituted by the propagation range of a wireless
base station and its serviced hosts. Dependent on topology, one
or many cells may be part of the same link.
Hint: An indication from other subsystems or protocol layers that
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, over both a wireless medium, and
any attached fixed network. This is typically achieved using
Neighbor Unreachability Detection procedure [3].
Wireless Medium: A physical layer which incorporates free space
electromagnetic or optical propagation. Such media are
susceptible to mobility and interference effects, potentially
resulting in high packet loss probabilities.
3. Overview 3. Overview
The DNA protocol presented in this document tries to achieve the The DNA protocol presented in this document tries to achieve the
following objectives: following objectives:
o Eliminate the delays introduced by RFC 2461 in discovering the o Eliminate the delays introduced by RFC 2461 in discovering the
configuration. configuration.
o Make it possible for the hosts to accurately detect the identity o Make it possible for the hosts to accurately detect the identity
of their current link from a single RA. of their current link from a single RA in the presence of either
DNAv6 enabled routers or non-DNAv6 routers.
DNAv6 assumes that the host's wireless link interface software and DNAv6 assumes that the host's wireless link interface software and
hardware is capable of delivering a 'link up' event notification when hardware is capable of delivering a 'link up' event notification when
layer 2 on the host is configured and sufficiently stable for IP layer 2 on the host is configured and sufficiently stable for IP
traffic. This event notification acts as a hint to the layer 3 DNA traffic. This event notification acts as a hint to the layer 3 DNA
procedures to check whether or not the host is attached to the same procedures to check whether or not the host is attached to the same
link as before. DNAv6 also assumes that an interface on the host is link as before. DNAv6 also assumes that an interface on the host is
never connected to two links at the same time. In the case that the never connected to two links at the same time. In the case that the
layer 2 technology is capable of having multiple attachments (for layer 2 technology is capable of having multiple attachments (for
instance, multiple layer 2 associations or connections) at the same instance, multiple layer 2 associations or connections) at the same
skipping to change at page 6, line 31 skipping to change at page 7, line 28
prefixes a router would advertise itself as per RFC 2461, and also, prefixes a router would advertise itself as per RFC 2461, and also,
the prefixes learned from other routers on the link that are not the prefixes learned from other routers on the link that are not
being advertised by itself. These learned prefixes are included in a being advertised by itself. These learned prefixes are included in a
new Learned Prefix Option in the Router Advertisement. new Learned Prefix Option in the Router Advertisement.
A host receiving one of these "Complete RAs" - so marked by a flag - A host receiving one of these "Complete RAs" - so marked by a flag -
then knows all of the prefixes in use on a link, and by inference all then knows all of the prefixes in use on a link, and by inference all
those that are not. By comparing this with previously received those that are not. By comparing this with previously received
prefixes the host can correctly decide whether it is connected to the prefixes the host can correctly decide whether it is connected to the
same link as previously, or whether this Router Advertisement is from same link as previously, or whether this Router Advertisement is from
a new link. Unlike CPL [15], the host does not have to wait for a new link.
multiple advertisements before making a decision.
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 Though frequently all routers on a link will advertise the same set
of prefixes and thus experience no cost in making the RAs complete, of prefixes and thus experience no cost in making the RAs complete,
there is potential for the RAs to be large when there are many there is potential for the RAs to be large when there are many
prefixes advertised. Two mechanisms are defined that allow certain prefixes advertised. Two mechanisms are defined that allow certain
RAs to be reduced in size. RAs to be reduced in size.
One uses a technique called a "landmark", where the host chooses one One uses a technique called a "landmark", where the host chooses one
of the prefixes as a landmark prefix, and then includes this in the of the prefixes as a landmark prefix, and then includes this in the
Router Solicitation message in the form of a question "am I still Router Solicitation message in the form of a question "am I still
skipping to change at page 7, line 19 skipping to change at page 8, line 23
such messages, so that the host can be informed of all the prefixes such messages, so that the host can be informed of all the prefixes
assigned to the new link as soon as possible. assigned to the new link as soon as possible.
A second mechanism for reducing packet sizes applies to unsolicited A second mechanism for reducing packet sizes applies to unsolicited
Router Advertisements. By selecting one prefix on the link to be the Router Advertisements. By selecting one prefix on the link to be the
"link identifier", and making sure that it is included in every "link identifier", and making sure that it is included in every
advertisement, it is possible to omit some prefixes. Such advertisement, it is possible to omit some prefixes. Such
advertisements will not inform a host of all of the prefixes at once, advertisements will not inform a host of all of the prefixes at once,
but in general these unsolicited advertisements will not be the first but in general these unsolicited advertisements will not be the first
advertisement received on a link. Inclusion of the link identifier advertisement received on a link. Inclusion of the link identifier
prefix simply ensures that there is overlap between the sets of simply ensures that there is overlap in the information advertised by
prefixes advertised by each router on a link and that hosts will thus each router on a link and that hosts will thus not incorrectly
not incorrectly interpret one of these incomplete RAs as an interpret one of these incomplete RAs as an indication of movement.
indication of movement. Even though this document recommends the use of a prefix as the "link
identifier", future specifications can use this option to support
non-prefix link identifiers.
The Router Advertisement messages are, in general, larger than the The Router Advertisement messages are, in general, larger than the
solicitations, and with multiple routers on the link there will be solicitations, and with multiple routers on the link there will be
multiple advertisements sent for each solicitation. This multiple advertisements sent for each solicitation. This
amplification can be used by an attacker to cause a Denial of Service amplification can be used by an attacker to cause a Denial of Service
attack. Such attacks are limited by applying a rate limit on the attack. Such attacks are limited by applying a rate limit on the
unicast Router Advertisements sent directly in response to each unicast Router Advertisements sent directly in response to each
solicitation, and using multicast RAs when the rate limit is solicitation, and using multicast RAs when the rate limit is
exceeded. exceeded.
In order for the routers be able to both respond to the landmark In order for the routers be able to both respond to the landmark
questions and send the complete RAs, the routers need to track the questions and send the complete RAs, the routers need to track the
prefixes that other routers advertise on the link. This process is prefixes that other routers advertise on the link. This process is
initialized when a router is enabled, by sending a Router initialized when a router is enabled, by sending a Router
Solicitation and collecting the resulting RAs, and then multicasting Solicitation and collecting the resulting RAs, and then multicasting
a few RAs more rapidly as already suggested in RFC 2461. This a few RAs more rapidly as already suggested in RFC 2461. This
process ensures with high probability that all the routers have the process ensures with high probability that all the routers have the
same notion of the set of prefixes assigned to the link. same notion of the set of prefixes assigned to the link.
In order for the host to be able to make decisions about link change
with a single received RA, the hosts need to track all the prefixes
advertised on the link. The hosts also have to maintain a notion of
'completeness' associated with its prefix list. This document
recommends that NUM_RS_RA_COMPLETE RS/RA exchanges SHOULD be done for
the prefix list to be considered 'complete'.
3.2 Fast Router Advertisement 3.2 Fast Router Advertisement
According to RFC 2461 a solicited Router Advertisement should have a According to RFC 2461 a solicited Router Advertisement should have a
random delay between 0 and 500 milliseconds, to avoid the random delay between 0 and 500 milliseconds, to avoid the
advertisements from all the routers colliding on the link causing advertisements from all the routers colliding on the link causing
congestion and higher probability of packet loss. In addition, RFC congestion and higher probability of packet loss. In addition, RFC
2461 suggests that the RAs be multicast, and multicast RAs are rate 2461 suggests that the RAs be multicast, and multicast RAs are rate
limited to one message every 3 seconds. This implies that the limited to one message every 3 seconds. This implies that the
response to a RS might be delayed up to 3.5 seconds. response to a RS might be delayed up to 3.5 seconds.
DNAv6 avoids this delay by using a different mechanism to ensure that DNAv6 avoids this delay by using a different mechanism to ensure that
two routers will not respond at exactly the same time while allowing two routers will not respond at exactly the same time while allowing
one of the routers on the link to respond immediately. Since the one of the routers on the link to respond immediately. Since the
hosts might be likely to use the first responding router as the first hosts might be likely to use the first responding router as the first
choice from their default router list, the mechanism also ensures choice from their default router list, the mechanism also ensures
that the same router doesn't respond first to the RSs from different that the same router doesn't respond first to the RSs from different
hosts. hosts.
The mechanism is based on the routers on the link determining (from The mechanism is based on the routers on the link determining (from
the same RAs that are used in section Section 3.1 to determine all the same RAs that are used in Section 3.1 to determine all the
the prefixes assigned to the link), the link-local addresses of all prefixes assigned to the link), the link-local addresses of all the
the other routers on the link. With this loosely consistent list, other routers on the link. With this loosely consistent list, each
each router can independently compute some function of the (link- router can independently compute some function of the (link-local)
local) source address of the RS and each of the routers' 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 addresses. The results of that function are then compared to create
a ranking, and the ranking determines the delay each router will use a ranking, and the ranking determines the delay each router will use
when responding to the RS. The router which is ranked as #0 will when responding to the RS. The router which is ranked as #0 will
respond with a zero delay. respond with a zero delay.
If the routers become out-of-sync with respect to their learned If the routers become out-of-sync with respect to their learned
router lists, two or more routers may respond with the same delay, router lists, two or more routers may respond with the same delay,
but over time the routers will converge on their lists of learned but over time the routers will converge on their lists of learned
routers on the link. routers on the link.
If a host has the complete list of all the assigned prefixes, it can
properly determine whether a link change has occurred. If the host
receives an RA containing one or more prefixes and none of the
prefixes in it matches the previously known prefixes for the link,
then it is assumed to be a new link.
This works because each and every valid global prefix on a link must
not be used on any other link thus the sets of global prefixes on
different links must be disjoint [18].
3.3 Complete Prefix List generation
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 MAX_RA_WAIT.
In case of packet loss, things get more complicated. In the above
process, there may be a packet loss that results in the generation of
an Incomplete Prefix List, i.e. the prefix list that misses some
prefix on the link. To remedy this deficiency, the host may perform
multiple RS/ RA exchanges to collect all the assigned prefixes.
After one RS/ RA exchange, to corroborate the completeness of the
prefix list, the host may send additional RSs and wait for the
resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS
[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.4 Erroneous Prefix Lists
The host may generate either 1) an Incomplete Prefix List, i.e. the
prefix list that does not include all the prefixes that are assigned
to the link or 2) the Superfluous Prefix List, i.e. the prefix list
that contains some prefix that is not assigned to the link.
It should be noted that 1) and 2) are not exclusive. The host may
generate the prefix list that excludes some prefix on the link but
includes the prefix not assigned to the link. Its important to note
that these erroneous prefix list possibility is significantly reduced
with a single DNAv6 router on the link that is sending CompleteRA
messages.
Severe packet losses during prefix list generation may cause an
Incomplete Prefix List. Or the host may have undergone a link change
before finishing the procedure of the Complete Prefix List
generation. Later we will deal with the case that the host can't be
sure of the completeness of the prefix list.
Even if the host falsely assumes that an Incomplete Prefix List is
complete, the effect of that assumption is that the host might later
think it has moved to a different link when in fact it has not.
In case that a link change happens, even if the host has an
Incomplete Prefix List, it will detect a link change. Hence an
Incomplete Prefix List doesn't cause a connection disruption. But it
may cause extra signaling messages, for example Binding Update
messages in [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. We further discuss the issues, should this assumption be
removed, in Section 5.3.
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.5 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 sub-optimal 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
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.
For these messages, no Neighbour Cache entry may be created, although
response messages may be directed to a particular unicast address.
4. Message Formats 4. Message Formats
This memo defines two new flags for inclusion in the router This memo defines two new flags for inclusion in the router
advertisement message and two new options. advertisement message and three new options.
4.1 Router Advertisement 4.1 Router Advertisement
DNAv6 modifies the format of the Router Advertisement message by DNAv6 modifies the format of the Router Advertisement message by
defining a bit to indicate that the router sending the message is defining a bit to indicate that the router sending the message is
participating in the DNAv6 protocol as well as a flag to indicate the participating in the DNAv6 protocol as well as a flag to indicate the
completeness of the set of prefixes included in the Router completeness of the set of prefixes included in the Router
Advertisement. The new message format is as follows: Advertisement. The new message format is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 13, line 40 skipping to change at page 18, line 29
Prefix Prefix
One or more fields (N) each containing a 128-bit address One or more fields (N) each containing a 128-bit address
representing a prefix that has been heard on the link but is not representing a prefix that has been heard on the link but is not
explicitly configured on this router. explicitly configured on this router.
Description Description
This option MUST only be included in a Router Advertisement. This This option MUST only be included in a Router Advertisement. This
option contains prefixes that are being advertised on the link but option contains prefixes that are beingF advertised on the link
are not explicitly configured on the sending router. The router but are not explicitly configured on the sending router. The
MUST NOT include any prefixes with a zero valid lifetime in the router MUST NOT include any prefixes with a zero valid lifetime in
LPO. the LPO.
4.5 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.
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. DNA Operation
5.1 DNA Router Operation 5.1 DNA Router Operation
Routers MUST collect information about the other routers that are Routers MUST collect information about the other routers that are
advertising on the link. advertising on the link.
5.1.1 Data Structures 5.1.1 Data Structures
skipping to change at page 21, line 34 skipping to change at page 27, line 11
down to the expiry of its valid lifetime, it SHOULD NOT be reassigned down to the expiry of its valid lifetime, it SHOULD NOT be reassigned
to another link for at least 1.5 hours or until the original expiry to another link for at least 1.5 hours or until the original expiry
time, whichever is earlier. This gives sufficient time for other time, whichever is earlier. This gives sufficient time for other
routers that have learned the prefix to expire it, and for hosts that routers that have learned the prefix to expire it, and for hosts that
have seen advertisements from those routers to expire the prefix as have seen advertisements from those routers to expire the prefix as
well. well.
Earlier reassignment may result in hosts that move from between the Earlier reassignment may result in hosts that move from between the
old and new links failing to detect the movement. old and new links failing to detect the movement.
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 5.2 DNA Host Operation
Hosts collect information about the prefixes available on the link to Hosts collect information about the prefixes available on the link to
which they are connected to facilitate change detection. which they are connected to facilitate change detection.
5.2.1 Data Structures 5.2.1 Data Structures
Hosts MUST maintain a list of prefixes advertised on the link. This Hosts MUST maintain a list of prefixes advertised on the link. This
is separate from the RFC 2461 "Prefix List" and will be referred to is separate from the RFC 2461 "Prefix List" and will be referred to
here as the "DNAHostPrefixList". All prefixes SHOULD be stored, here as the "DNAHostPrefixList". All prefixes SHOULD be stored,
skipping to change at page 22, line 29 skipping to change at page 28, line 24
LinkIDs instead of prefixes. LinkIDs instead of prefixes.
At this time LinkIDs are also prefixes but in future may be able to At this time LinkIDs are also prefixes but in future may be able to
be identifiers other than prefixes. A list is stored rather than a be identifiers other than prefixes. A list is stored rather than a
single entry to allow for changes in the LinkID used on a link. single entry to allow for changes in the LinkID used on a link.
Entries are expired from DNAHostLinkIDList in the same way as Entries are expired from DNAHostLinkIDList in the same way as
DNAHostPrefixList. DNAHostPrefixList.
Hosts SHOULD also maintain a "Landmark Prefix" as described in Hosts SHOULD also maintain a "Landmark Prefix" as described in
Section 5.2.3. Section 5.2.5.
5.2.2 Host Configuration Variables 5.2.2 Host Configuration Variables
Hosts MUST make use of the following conceptual variables and they Hosts MUST make use of the following conceptual variables and they
SHOULD be configurable: SHOULD be configurable:
DNASameLinkDADFlag DNASameLinkDADFlag
Boolean value indicating whether or not a host should re-run DAD Boolean value indicating whether or not a host should re-run DAD
when DNA indicates that link change has not occurred. when DNA indicates that link change has not occurred.
Default: False Default: False
5.2.3 Selection of a Landmark Prefix NUM_RS_RA_COMPLETE
Number of RS/RA exchange messages necessary to declare the prefix
list to be complete.
Default: 1
MAX_RA_WAIT
[Editor's note: This should be MIN_RA_WAIT, right? This is the
minimum time we are recommending the host should wait before
assuming cpl?] Maximum time for the host will have to wait before
assuming receipt of all possible RAs.
Default: 4 seconds
MAX_CACHE_TIME
[Editor's note: Do we want to keep this and the associated
Section 5.2.4?] Maximum time for which link information can be
stored in the hosts.
Default: 30 mins
5.2.3 Detecting Network Attachment Steps
An IPv6 host SHOULD follow the following steps when they receive a
hint (see also Section 7) indicating the possibility of link change.
[Editor's note: Check if DNA steps are correct]
Try making use of prior information stored related to the links
the host visited in the past (see Section 5.2.4).
If the prior information implies no link change, the host MAY
conduct reachability detection (see Section 5.2.7.4) to one of
the default routers it is using, otherwise no action is needed.
If the prior information implies that there is a link change or
there is no useful prior information available, follow the
procedure below.
Mark all the IPv6 addresses in use as optimistic.
Set all Neighbor Cache entries for routers on its Default Router
List to STALE.
Send router solicitation. (See Section 5.2.6).
Receive router advertisement(s).
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.
Process received router advertisement. (See Section 5.2.7).
If the link has changed
Change the IP configuration parameters of the host (see
Section 5.2.8).
If the link has NOT changed
Restore the address configuration state of all the IPv6
addresses known to be on the link.
Update default routers list and their reachability information
(see Section 5.2.7.4).
5.2.4 Making use of Prior Information
A device that has recently been attached to a particular wireless
base station may still have state regarding the IP configuration
valid for use on that link. This allows a host to begin any
configuration procedures before checking the ongoing validity and
security of the parameters.
The experimental protocols CARD [13] and FMIPv6 [14] each provide
ways to generate such information using network-layer signaling,
before arrival on a link. Additionally, the issue is the same when a
host disconnects from one cell and returns to it immediately, or
movement occurs between a pair of cells (the ping-pong effect).
A IP host MAY store L2 to L3 mapping information for the links for a
period of time in order to use the information in the future. When a
host attaches itself to a point-of-attachment for which it has an L2
to L3 mapping, if the stored record doesn't contain the prefix the
host is using, the host SHOULD conclude that it has changed link and
initiate a new configuration procedure.
If the host finds the prefix it is using in the stored record, a host
MAY conclude that it is on the same link, but SHOULD undertake
reachability testing as described in Section 5.2.7.4. In this case,
the host MUST undertake Duplicate Address Detection [7][5] to confirm
that there are no duplicate addresses on the link.
The host MUST age this cached information based on the possibility
that the link's configuration has changed and MUST NOT store
information beyond either the remaining router or address lifetime or
(at the outside) MAX_CACHE_TIME time-units.
5.2.5 Selection of a Landmark Prefix
For each interface, hosts SHOULD choose a prefix to use as a Landmark For each interface, hosts SHOULD choose a prefix to use as a Landmark
Prefix in Router Solicitations. The following rules are used in Prefix in Router Solicitations. The following rules are used in
selecting the landmark prefix: selecting the landmark prefix:
The prefix MUST have a non-zero valid lifetime. If the valid The prefix MUST have a non-zero valid lifetime. If the valid
lifetime of a previously selected Landmark Prefix expires, a new lifetime of a previously selected Landmark Prefix expires, a new
Landmark Prefix MUST be selected. Landmark Prefix MUST be selected.
The prefix MUST be one of those that the hosts has used to assign The prefix MUST be one of those that the hosts has used to assign
a non-link-local address to itself a non-link-local address to itself
The prefix SHOULD be chosen as the one with the longest preferred The prefix SHOULD be chosen as the one with the longest preferred
lifetime, but it is not necessary to switch to different prefix if lifetime, but it is not necessary to switch to different prefix if
the preferred lifetime of the current landmark prefix changes. the preferred lifetime of the current landmark prefix changes.
5.2.4 Sending Router Solicitations 5.2.6 Sending Router Solicitations
Upon the occurrence of a Layer 2 link-up event notification, hosts Upon the occurrence of a Layer 2 link-up event notification, hosts
SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting
and/or hysteresis to this behaviour as appropriate to the link and/or hysteresis to this behaviour as appropriate to the link
technology subject to the reliability of the hints. technology subject to the reliability of the hints.
When the host receives a link UP notification from its link layer, it
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.
Thus if it handled the most recent link UP notification less than
MAX_RA_WAIT seconds ago, it can not immediately send one when it
processes a link UP notification.
If the RS does not result in the host receiving at least one RA with
at least one valid prefix, then the host can retransmit the RS. It
is allowed to multicast up to MAX_RTR_SOLICITATIONS [3] RS messages
spaced RTR_SOLICITATION_INTERVAL apart.
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 Hosts SHOULD include a Landmark Option (LO) in the RS message with
the landmark prefix chosen based on the rules in Section 5.2.3. the landmark prefix chosen based on the rules in Section 5.2.5.
Hosts SHOULD include a tentative source link layer address option Hosts SHOULD include a tentative source link layer address option
(TSLLAO) in the RS message [7]. The router solicitation message is (TO) in the RS message Section 6. The router solicitation message is
sent to the All_Routers_Multicast address and the source address MUST sent to the All_Routers_Multicast address and the source address MUST
be the link local address of the host. be the link local address of the host.
The host MUST consider its link local address to be in the The host MUST consider its link local address to be in the
"Optimistic" state for duplicate address detection [6] until either "Optimistic" state for duplicate address detection [5] until either
the returned RA confirms that the host has not switched to a new link the returned RA confirms that the host has not switched to a new link
or, if an link change has occurred, the host has performed optimistic or, if an link change has occurred, the host has performed optimistic
duplicate address detection for the address. duplicate address detection for the address.
5.2.5 Processing Router Advertisements 5.2.7 Processing Router Advertisements
When the host receives a Router Advertisement, the host checks for When the host receives a Router Advertisement, the host checks for
the conditions and derives the associated conclusions given below: the following conditions in the given order and derives the
associated conclusions given below [Editor's note: Review and make
sure that there are no corner cases]:
If the RA contains a Landmark Option with the "Y" flag set that If the RA contains a Landmark Option that matches the Landmark
matches the Landmark Option in the last transmitted Router Option in the last transmitted Router Solicitation, and the 'Y'
Solicitation, then that indicates that no link change has occurred bit is set then that indicates that no link change has occurred
and current configuration can be assumed to still be current. and current configuration can be assumed to still be current.
If the RA includes any prefixes in either a PIO or LPO that
matches a prefix in DNAHostPrefixList then the host can conclude
that no link change has occurred and current configuration can be
assumed to still be current.
If the RA includes a LinkID that matches an entry in If the RA includes a LinkID that matches an entry in
DNAHostLinkIDList, then the host can conclude that no link change DNAHostLinkIDList, then the host can conclude that no link change
has occurred and the current configuration can be assumed to still has occurred and the current configuration can be assumed to still
be current.If the RA includes a LinkID that is not in
DNAHostLinkIDList and no prefixes that match entries in
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 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. be current.
If the RA is a Complete RA, as indicated by the "Complete" flag in If the RA is a Complete RA, as indicated by the "Complete" flag in
the RA header, and there are no prefixes included in it in either the RA header, and there are no prefixes included in it in either
a PIO or LPO that are also in the hosts DNAHostPrefixList, then a PIO or LPO that are also in the host's DNAHostPrefixList, then
the host can conclude that it has changed link and SHOULD initiate the host can conclude that it has changed link and SHOULD initiate
re-configuration using the information in the received Router re-configuration using the information in the received Router
Advertisement. Advertisement.
If the RA is not a CompleteRA, but includes a LinkID that is not If the host has the complete prefix list (CPL) and the RA doest
in DNAHostLinkIDList and no prefixes that match entries in NOT include any prefixes in either a PIO or LPO that matches a
DNAHostPrefixList, then the host can conclude that it has changed prefix in CPL then the host can conclude that link change has
link and SHOULD initiate re-configuration using the information in occurred and use the information in the received RA to configure
the received Router Advertisement. itself.
If the received RA is not complete, contains no prefixes that are If the host doesn't have the complete prefix list (CPL), the
stored in DNAHostPrefixList, does not contain a Landmark Option received RA is not complete, contains no prefixes that are stored
that matches a corresponding option in the most recent RS and in DNAHostPrefixList, does not contain a Landmark Option that
contains no LinkID, then the host SHOULD use CPL logic to decide matches a corresponding option in the most recent RS and contains
whether or not to reconfigure as described in [15]. no LinkID, then the host SHOULD send RS/RA exchange until
num_RS_RA is equal to NUM_RS_RA_COMPLETE to create a new CPL and
compare it with the already known prefixes. If after
NUM_RS_RA_COMPLETE 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.
5.2.5.1 Maintaining the DNAHostPrefixList 5.2.7.1 Pseudocode
IF (Received RA contains Landmark that matches the Landmark option in
the last transmitted RS AND Landmark 'Y' bit is set) THEN
{
No-link change has occured
RETURN; // Don't have to do the following checks.
}
IF (Received RA contains LinkID) THEN
{
IF (LinkID matches an entry in DNAHostLinkIDList), THEN no-link
change has occured ELSE link-change.
RETURN; // Don't have to do the following checks.
}
IF (Receive RA contains a prefix matching a prefix in
DNAHostPrefixList) THEN
{
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 (DNAHostPrefixList is marked as complete (i.e. the completeness
criteria is already met)) THEN
{
/* 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 NUM_RS_RA_COMPLETE 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.
5.2.7.2 Maintaining the DNAHostPrefixList
If a Router Advertisement does not indicate a link change, the host If a Router Advertisement does not indicate a link change, the host
updates its DNAHostPrefixList, adding any new prefixes if necessary. updates its DNAHostPrefixList, adding any new prefixes if necessary.
If the Router Advertisement has the C flag set, then the host SHOULD If the Router Advertisement has the C flag set, then the host SHOULD
make the DNAHostPrefixList match the contents of the advertisement. make the DNAHostPrefixList match the contents of the advertisement
Any new prefixes are added and any prefixes in the list that are and mark it as complete (i.e. it becomes CPL). Any new prefixes are
absent in the advertisement are removed. Expiry times on prefixes added and any prefixes in the list that are absent in the
are updated if the prefix was contained in a PIO, but not if it was advertisement are removed. Expiry times on prefixes are updated if
contained in an LPO. 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 If the Router Advertisement does not have the C flag set, then the
host SHOULD add any new prefixes and update expiry times as above, host SHOULD add any new prefixes and update expiry times as above,
but SHOULD NOT remove any entries from DNAHostPrefixList. but SHOULD NOT remove any entries from DNAHostPrefixList.
When initiating reconfiguration due to link change, the host MUST When initiating reconfiguration due to link change, the host MUST
remove all prefixes in the DNAHostPrefixList and repopulate it with remove all prefixes in the DNAHostPrefixList and repopulate it with
the prefixes in the Prefix Information Options and Learned Prefix the prefixes in the Prefix Information Options and Learned Prefix
Option, if any, in the RA. Option, if any, in the RA.
5.2.5.2 Router Reachability Detection and Default Router Selection 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
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 MAX_RA_WAIT 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 MAX_RA_WAIT 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. This
document considers it to be complete when NUM_RS_RA_COMPLETE 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 NUM_RS_RA_COMPLETE 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.7.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
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.7.3 Maintaining DNAHostLinkIDList
If a Router Advertisement does not indicate a link change, the host
updates its DNAHostLinkIDList, adding any new LinkIDs if necessary.
If the link has changed, the DNAHostLinkIDList MUST be updated with
the ONLY the linkIDs from the router advertisment.[Editor's note: Do
we have say something about storing old LinkID list as prior
information for future use].
5.2.7.4 Router Reachability Detection and Default Router Selection
The receipt of a unicast RA from a router in response to a multicast The receipt of a unicast RA from a router in response to a multicast
RS indicates that the host has bi-directional reachability with the RS indicates that the host has bi-directional reachability with the
routers that responded. Such reachability is necessary for the host routers that responded. Such reachability is necessary for the host
to use a router as a default router, in order to have packets routed to use a router as a default router, in order to have packets routed
off the host's current link. If the destination address of the off the host's current link. It is notable that the choice of
received RA is a unicast address, the host knows the router heard its whether the messages are addressed to multicast or unicast address
RS, and therefore that the host has reachability with the router. 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 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 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 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 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 Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the
REACHABLE state if one does not currently exist. REACHABLE state if one does not currently exist.
The host SHOULD also update its Default Router List in the following The host SHOULD also update its Default Router List in the following
fashion. If any of the routers returning RAs are already on the fashion. If any of the routers returning RAs are already on the
skipping to change at page 25, line 37 skipping to change at page 37, line 48
new IP link, since changes in router reachability are possible on new IP link, since changes in router reachability are possible on
some link types even if the host remains on the same IP link. some link types even if the host remains on the same IP link.
Note that this procedure does not prevent a MN from sending packets Note that this procedure does not prevent a MN from sending packets
to its current default router while the RA solicitation is in to its current default router while the RA solicitation is in
progress and if reachability with the current default router is progress and if reachability with the current default router is
unchanged, there should be no change in default router after the RA unchanged, there should be no change in default router after the RA
solicitation completes. If the current default router is still solicitation completes. If the current default router is still
reachable, it will forward the packets. reachable, it will forward the packets.
5.2.6 DNA and Address Configuration 5.2.8 DNA and Address Configuration
When a host moves to a new point of attachment, a potential exists [Editor's note: Nothing has changed in this section] When a host
for a change in the validity of its unicast and multicast addresses moves to a new point of attachment, a potential exists for a change
on that network interface. In this section, host processing for in the validity of its unicast and multicast addresses on that
address configuration is specified. The section considers both network interface. In this section, host processing for address
statelessly and statefully configured addresses. configuration is specified. The section considers both statelessly
and statefully configured addresses.
5.2.6.1 Duplicate Address Detection 5.2.8.1 Duplicate Address Detection
A DNA host MUST support optimistic Duplicate Address Detection [6] A DNA host MUST support optimistic Duplicate Address Detection [5]
for autoconfiguring unicast link local addresses. If a DNA host uses for autoconfiguring unicast link local addresses. If a DNA host uses
address autoconfiguration [8] for global unicast addresses, the DNA address autoconfiguration [7] for global unicast addresses, the DNA
host MUST support optimistic Duplicate Address Detection for host MUST support optimistic Duplicate Address Detection for
autoconfiguring global unicast addresses. autoconfiguring global unicast addresses.
5.2.6.2 DNA and the Address Autoconfiguration State Machine 5.2.8.2 DNA and the Address Autoconfiguration State Machine
When a link level event occurs on a network interface indicating that When a link level event occurs on a network interface indicating that
the host has moved from one point of attachment to another, it is the host has moved from one point of attachment to another, it is
possible that a change in the reachability of the addresses possible that a change in the reachability of the addresses
associated with that interface may occur. Upon detection of such a associated with that interface may occur. Upon detection of such a
link event and prior to sending the RS initiating a DNA exchange, a link event and prior to sending the RS initiating a DNA exchange, a
DNA host MUST change the state of addresses associated with the DNA host MUST change the state of addresses associated with the
interface in the following way (address state designations follow RFC interface in the following way (address state designations follow RFC
2461): 2461):
skipping to change at page 27, line 27 skipping to change at page 39, line 39
previous point of attachment, so the host may not have confirmed previous point of attachment, so the host may not have confirmed
address uniqueness. If the previous state of an address was address uniqueness. If the previous state of an address was
"Preferred", whether or not the host initiates optimistic Duplicate "Preferred", whether or not the host initiates optimistic Duplicate
Address Detection depends on the configurable DNASameLinkDADFlag Address Detection depends on the configurable DNASameLinkDADFlag
flag. A host MUST forgo sending an NS to confirm uniqueness if the flag. A host MUST forgo sending an NS to confirm uniqueness if the
value of the DNASameLinkDAD flag is False. If, however, the value of the DNASameLinkDAD flag is False. If, however, the
DNASameLinkDAD flag is True, the host MUST perform optimistic DNASameLinkDAD flag is True, the host MUST perform optimistic
duplicate address detection on its unicast link local and unicast duplicate address detection on its unicast link local and unicast
global addresses to determine address uniqueness. global addresses to determine address uniqueness.
5.2.6.3 DNA and Statefully Configured Addresses 5.2.8.3 DNA and Statefully Configured Addresses
The DHCPv6 specification [9] requires hosts to send a DHCPv6 CONFIRM The DHCPv6 specification [16] requires hosts to send a DHCPv6 CONFIRM
message when a change in point of attachment is detected. Since the message when a change in point of attachment is detected. Since the
DNA protocol provides the same level of movement detection as the DNA protocol provides the same level of movement detection as the
DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the
DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive
signaling. If, however, a non-DNA RA is received, the host SHOULD signaling. If, however, a non-DNA RA is received, the host SHOULD
use the DHCPv6 CONFIRM message as described in RFC 3315 [9] rather use the DHCPv6 CONFIRM message as described in RFC 3315 [16] rather
than wait for additional RAs to perform CPL, since this will reduce than wait for additional RAs to perform CPL, since this will reduce
the amount of time required for the host to confirm whether or not it the amount of time required for the host to confirm whether or not it
has moved to a new link. If the CONFIRM message validates the has moved to a new link. If the CONFIRM message validates the
addresses, the host can continue to use them. addresses, the host can continue to use them.
When a DNA RA is received and the received RA indicates that the host When a DNA RA is received and the received RA indicates that the host
has not moved to a new link, the host SHOULD apply the same rules to has not moved to a new link, the host SHOULD apply the same rules to
interpreting the 'M' flag in the received RA and any subsequently interpreting the 'M' flag in the received RA and any subsequently
received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA
is received with the 'M' flag set, then the 'M' flag value is copied is received with the 'M' flag set, then the 'M' flag value is copied
skipping to change at page 28, line 14 skipping to change at page 40, line 26
new addresses, since the old addresses will continue to be valid. new addresses, since the old addresses will continue to be valid.
If the DNA RA indicates that the host has moved to a new link or the If the DNA RA indicates that the host has moved to a new link or the
DHCPv6 CONFIRM indicates that the addresses are invalid, the host DHCPv6 CONFIRM indicates that the addresses are invalid, the host
MUST move its old addresses to the "Deprecated" state and MUST run MUST move its old addresses to the "Deprecated" state and MUST run
DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is
4-message exchange, however, this exchange allows for redundancy 4-message exchange, however, this exchange allows for redundancy
(multiple DHCPv6 servers) without wasting addresses, as addresses are (multiple DHCPv6 servers) without wasting addresses, as addresses are
only provisionally assigned to a host until the host chooses and only provisionally assigned to a host until the host chooses and
requests one of the provisionally assigned addresses. If the DNA requests one of the provisionally assigned addresses. If the DNA
host supports the Rapid Commit Option [9], the host SHOULD use the host supports the Rapid Commit Option [16], the host SHOULD use the
Rapid Commit Option in order to shorten the exchange from 4 messages Rapid Commit Option in order to shorten the exchange from 4 messages
to 2 messages. to 2 messages.
5.2.6.4 Packet Delivery During DNA 5.2.8.4 Packet Delivery During DNA
The specification of packet delivery before, during, and immediately The specification of packet delivery before, during, and immediately
after DNA when a change in point of attachment occurs is out of scope after DNA when a change in point of attachment occurs is out of scope
for this document. The details of how packets are delivered depends for this document. The details of how packets are delivered depends
on the mobility management protocols (if any) available to the host's on the mobility management protocols (if any) available to the host's
stack. stack.
5.2.6.5 Multicast Address Configuration 5.2.8.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 If the returning RAs indicate that the host has not moved to a new
link, no further action is required for multicast addresses to which link, no further action is required for multicast addresses to which
the host has subscribed using MLD Report [10]. In particular, the the host has subscribed using MLD Report [17]. In particular, the
host MUST NOT perform MLD signaling for any multicast addresses host MUST NOT perform MLD signaling for any multicast addresses
unless such signaling was not performed prior to movement to the new unless such signaling was not performed prior to movement to the new
point of attachment. For example, if an address is put into the point of attachment. For example, if an address is put into the
"Optimistic" state prior to movement but the MLD Report for the "Optimistic" state prior to movement but the MLD Report for the
Solicited_Node_Multicast_Address is not sent prior to movement to a Solicited_Node_Multicast_Address is not sent prior to movement to a
new point of attachment, the host MUST send the MLD Report on the new new point of attachment, the host MUST send the MLD Report on the new
point of attachment prior to performing optimistic Duplicate Address point of attachment prior to performing optimistic Duplicate Address
Detection. The host SHOULD use the procedure described below for Detection. The host SHOULD use the procedure described below for
sending an MLD Report. sending an MLD Report.
If, on the other hand, the DNA RA indicates that the host has moved If, on the other hand, the DNA RA indicates that the host has moved
to a new link, the host MUST issue a new MLD Report to the router for to a new link, the host MUST issue a new MLD Report to the router for
subscribed multicast addresses. MLD signaling for the subscribed multicast addresses. MLD signaling for the
Solicited_Node_Multicast_Addresses [8] MUST be sent prior to Solicited_Node_Multicast_Addresses [7] MUST be sent prior to
performing signaling for optimistic DAD. performing signaling for optimistic DAD.
To avoid lengthy delays in address reconfiguration, it is RECOMMENDED To avoid lengthy delays in address reconfiguration, it is RECOMMENDED
that the host send the MLD Report for newly configured addresses that the host send the MLD Report for newly configured addresses
immediately, as soon as the addresses have been constructed, rather immediately, as soon as the addresses have been constructed, rather
than waiting for a random backoff. than waiting for a random backoff.
Hosts MUST defer MLD signaling until after the results of DNA have Hosts MUST defer MLD signaling until after the results of DNA have
confirmed whether or not a link change has occurred. confirmed whether or not a link change has occurred.
6. Backward Compatibility 5.3 DNA without a 'link UP' notification
6.1 Non-DNA Host with DNA Routers [Editor's note: Do we need this section? The question is raised in
the issues section of CPL. If we keep this, the section should be
generalised to make it applicable to the whole DNAv6, right now its
specific to CPL only ]
The RS message sent by non-DNA hosts will not contain any of the new If the host implementation does not provide any link-layer event
options defined by this document. The host will receive a Complete notifications [20], and in particular, a link UP notification, the
RA in response to the solicitation message and process it as per RFC host needs additional logic to try to decide whether a received RA
2461. This means that it will drop the unrecognised Learned Prefix applies to the "old" link or a "new" link.
option, but process the included PIOs and non-DNA flags normally.
6.2 DNA Host with Non-DNA Routers In this case there is an increased risk that the host get confused,
thus it isn't clear whether this should be part of the
recommendation, or whether we should just require that hosts which
implement this draft have a 'link UP' notification.
The routers will behave based in the recommendations of RFC 2461 [3] If there is no 'link UP' notification when the host might have moved,
and ignore the new options defined in this memo. Hosts will receive the host would collect the prefixes from multiple links into a single
RA message without the FastRA flag in the RA header set and will DNAHostPrefixList, and would never detect movement.
fallback on CPL for link identification. Obviously, the objective of
receiving fast response for RS message can not be achieved.
This case can occur on a link with no DNA routers or on a link with a Here is an example. The host begins to collect the prefixes on a
mix of the two. In the latter, usually a response from the DNA link. But before the prefix list generation is completed, without
router(s) will be received first and CPL will just be used with the its knowledge, the host moves to a new link. Unaware that now it is
non-DNA Router Advertisement to confirm that no movement has taken at the different link, the host keeps collecting prefixes from the
place since the previous DNA advertisement. received RAs to generate the prefix list. This results in the prefix
list containing prefixes from two different links. If the host uses
this prefix list, it fails to detect a link change.
7. Security Considerations A possible way to prevent this situation for implementations without
a link UP notification, is to treat the arrival of a RA with a
disjoint set of prefixes as a hint, as specified below.
7.1 Attacks on the Token Bucket The implications of treating such an RA as a hint, is that such an RA
would set 'time_last_linkUP_received' to the current time, create a
new Candidate Link object with the information extracted from that
RA, and then send an RS as specified in Section 5.2.6.
However, there is still a risk for confusion because the host can not
tell from the RAs whether they were solicited by the host. (RFC 2461
recommends that solicited RAs be multicast.) The danger is
exemplified by this:
1. Assume the host has a DNAHostPrefixList with prefixes P1 and P2.
2. The host changes link layer attachment, but there is no link UP
notification.
3. The host receives an RA with a disjoint set of prefixes: prefix
P3. This causes the host to form a new DNAHostPrefixList with P3
and send an RS.
4. The host again changes link layer attachment, and no link UP
notification.
5. The host receives one of the periodic multicast RAs on the link,
which contains prefix P4. It can not tell whether this RA was in
response to the RS it send above. The host ends up adding this
to the DNAHostPrefixList, which now has P3 and P4, even though
those prefixes are assigned to different links.
There doesn't appear to be a way to solve this problem without
changes to the routers and the Router Advertisement messages.
However, the probability of this occurring can be limited by limiting
the window of exposure. The simplest approach is for the host to
assume that any RA received within MAX_RA_WAIT seconds after sending
an RS was in response to the RS. Basically this relies on the small
probability of both moving again in that MAX_RA_WAIT second interval,
and receiving one of the periodic RAs. If the periodic RAs are sent
infrequently enough, this might work in practise, but is by no means
bullet-proof.
6. Tentative options for IPv6 ND
6.1 Sending solicitations containing Tentative Options
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.
6.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.
6.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 B.
6.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.
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 B.
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 B.
6.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
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.
6.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.
7. Initiation of DNA Procedures
Link change detection procedures defined in the document are
initiated when "link UP" event notification. This event indicates
that network reachability or configuration is suspect and is called a
hint. In this section, other possible hints that can imply that the
configuration is suspect are presented and discussed. [Editor's
note: Is this section useful?]
Hints MAY be used to update a wireless host's timers or probing
behavior in such a way as to assist detection of network attachment.
Hints SHOULD NOT be considered to be authoritative for detecting IP
configuration change by themselves.
In some cases, hints will carry significant information (for example
a hint indicating PPP IPv6CP open state [8]), although details of the
configuration parameters may be available only after other IP
configuration procedures. Implementers are encouraged to treat hints
as though they may be incorrect, and require confirmation.
Hosts MUST ensure that untrusted hints do not cause unnecessary
configuration changes, or significant consumption of host resources
or bandwidth. In order to achieve this aim, a host MAY implement
hysteresis mechanisms such as token buckets, hint weighting or
holddown timers in order to limit the effect of excessive hints.
7.1 Hints Due to Network Layer Messages
Hint reception may be due to network-layer messages such as
unexpected Router Advertisements, multicast listener queries or
ICMPv6 error messages [3][9][10]. In these cases, the authenticity
of the messages MUST be verified before expending resources to
initiate DNA procedure.
When a host arrives on a new link, hints received due to external IP
packets will typically be due to multicast messages. Actions based
on multicast reception from untrusted sources are dangerous due to
the threat of multicast response flooding. This issue is discussed
further in Section 9.
State changes within the network-layer itself may initiate link-
change detection procedures. Existing subsystems for router and
neighbor discovery, address leasing and multicast reception maintain
their own timers and state variables. Changes to the state of one or
more of these mechanisms may hint that link change has occurred, and
initiate detection of network attachment.
7.2 Handling Hints from Other Layers
Events at other protocol layers may provide hints of link change to
network attachment detection systems. Two examples of such events
are TCP retransmission timeout and completion of link-layer access
procedures [20].
While hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat hints from other
protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be
triggered by untrusted messages, come from compromised sources (for
example 802.11 WEP Encryption [15]) or be inaccurate with regard to
network-layer state.
While these hints come from the host's own stack, such hints may
actually be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to
instigate hint delivery on a host or multiple hosts deliberately, in
order to prompt packet transmission, or configuration modification.
Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers. A host MAY adopt an appropriate
link change detection strategy based upon hints received from other
layers, with suitable caution and hysteresis.
7.3 Timer and Loss Based Hints
Other hints may be received due to timer expiry, particularly In some
cases the expiry of these timers may be a good hint that DNA
procedures are necessary.
Since DNA is likely to be used when communicating with devices over
wireless links, suitable resilience to packet loss SHOULD be
incorporated into the DNA initiation system. Notably, non-reception
of data associated with end-to-end communication over the Internet
may be caused by reception errors at either end or because of network
congestion. Hosts SHOULD NOT act immediately on packet loss
indications, delaying until it is clear that the packet losses aren't
caused by transient events.
Use of the Advertisement Interval Option specified in [6] follows
these principles. Routers sending this option indicate the maximum
interval between successive router advertisements. Hosts receiving
this option monitor for multiple successive packet losses and
initiate change discovery.
7.4 Simultaneous Hints
Some events which generate hints may affect a number of devices
simultaneously.
For example, if a wireless base station goes down, all the hosts on
that base station are likely to initiate link-layer configuration
strategies after losing track of the last beacon or pilot signal from
the base station.
As described in [3][10], a host SHOULD delay randomly before acting
on a widely receivable advertisement, in order to avoid response
implosion.
Where a host considers it may be on a new link and learns this from a
hint generated by a multicast message, the host SHOULD defer 0-1000ms
in accordance with [3][7]. Please note though that a single
desynchronization is required for any number of transmissions
subsequent to a hint, regardless of which messages need to be sent.
In link-layers where sufficient serialization occurs after an event
experienced by multiple hosts, each host MAY avoid the random delays
before sending solicitations specified in [3].
7.5 Hint Management for Inactive Hosts
If a host does not expect to send or receive packets soon, it MAY
choose to defer detection of network attachment. This may preserve
resources on latent hosts, by removing any need for packet
transmission when a hint is received.
These hosts SHOULD delay 0-1000ms before sending a solicitation, and
MAY choose to wait up to twice the advertised Router Advertisement
Interval (plus the random delay) before sending a solicitation [6].
One benefit of inactive hosts' deferral of DNA procedures is that
herd-like host configuration testing is mitigated when base-station
failure or simultaneous motion occur. When latent hosts defer DNA
tests, the number of devices actively probing for data simultaneously
is reduced to those hosts which currently support active data
sessions.
When a device begins sending packets, it will be necessary to test
bidirectional reachability with the router (whose current Neighbor
Cache state is STALE). As described in [3], the host will delay
before probing to allow for the probability that upper layer packet
reception confirms reachability.
8. Complications to Detecting Network Attachment
Detection of network attachment procedures can be delayed or may be
incorrect due to different factors. This section gives some examples
where complications may interfere with DNA processing.
8.1 Packet Loss
Generally, packet loss introduces significant delays in validation of
current configuration or discovery of new configuration. Because
most of the protocols rely on timeout to consider that a peer is not
reachable anymore, packet loss may lead to erroneous conclusions.
Additionally, packet loss rates for particular transmission modes
(multicast or unicast) may differ, meaning that particular classes of
DNA tests have higher chance of failure due to loss. Hosts SHOULD
attempt to verify tests through retransmission where packet loss is
prevalent.
8.2 Router Configurations
Each router can have its own configuration with respect to sending
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 router of the host.
The time needed to discover the new link can then be longer than
expected by the host.
8.3 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.
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.
8.4 Multicast Snooping
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.
8.5 Link Partition
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.
9. Security Considerations
9.1 Attacks on the Token Bucket
A host on the link could easily drain the token bucket(s) of the A host on the link could easily drain the token bucket(s) of the
router(s) on the link by continuously sending RS messages on the router(s) on the link by continuously sending RS messages on the
link. For example, if a host sends one RS message every link. For example, if a host sends one RS message every
UnicastRAInterval, and send a additional RS every third UnicastRAInterval, and send a additional RS every third
UnicastRAInterval, the token bucket in the router(s) on the link will UnicastRAInterval, the token bucket in the router(s) on the link will
drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units.
For the recommended values of UnicastRAInterval and For the recommended values of UnicastRAInterval and
MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear
whether arrival of such RS messages can be recognized by the router whether arrival of such RS messages can be recognized by the router
as a DoS attack. This attack can also be mitigated by aggregating as a DoS attack. This attack can also be mitigated by aggregating
responses. Since only one aggregation is possible in this interval responses. Since only one aggregation is possible in this interval
due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able
protect the tokens in the bucket. protect the tokens in the bucket.
7.2 Attacks on DNA Hosts 9.2 Attacks on DNA Hosts
RFC 3756 outlines a collection of threats involving rouge routers. RFC 3756 outlines a collection of threats involving rouge routers.
Since DNAv6 requires a host to obtain trustworthy responses from Since DNAv6 requires a host to obtain trustworthy responses from
routers, such threats are relevant to DNAv6. In order to counter routers, such threats are relevant to DNAv6. In order to counter
such threats, DNAv6 hosts SHOULD support RFC 3971 (SEND) secure such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure
router discovery. router discovery.
8. IANA Considerations 9.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
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.
9.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.
9.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
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.
9.6 Hint Management Security
Events originating at other protocol layers may provide hints of link
change to network attachment detection systems. Two examples of such
events are TCP retransmission timeout and completion of link-layer
access procedures [20].
While hints from other protocol layers originate from within the
host's own stack, the network layer SHOULD NOT treat hints from other
protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be
triggered by untrusted messages, come from compromised sources (for
example 802.11 WEP Encryption [15]) or be inaccurate with regard to
network-layer state.
While these hints come from the host's own stack, such hints may
actually be due to packet reception or non-reception events at the
originating layers. As such, it may be possible for other devices to
instigate hint delivery on a host or multiple hosts deliberately, in
order to prompt packet transmission, or configuration modification.
Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers. A host MAY adopt an appropriate
link change detection strategy based upon hints received from other
layers, with suitable caution and hysteresis.
10. IANA Considerations
This memo defines two new Neighbor Discovery [3] options, which must This memo defines two new Neighbor Discovery [3] options, which must
be assigned Option Type values within the option numbering space for be assigned Option Type values within the option numbering space for
Neighbor Discovery messages: Neighbor Discovery messages:
1. The Landmark option, described in Section 4.3; and 1. The Landmark option, described in Section 4.3; and
2. The Learned Prefix option, described in Section 4.4. 2. The Learned Prefix option, described in Section 4.4.
9. Acknowledgments 3. The tentative option, described in Section 4.5
11. Open issues
1. The protocol uses only the prefixes with lifetime greater than
1.5 hours. 1.5 hour is decided with the assumption that
MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to
increase the value into hours or even days because it would be
difficult to waken all idle nodes in every 30 mins in cellular
network.
2. There may be a link where no prefix is advertised. For example,
an network administrator may not support stateless address
autoconfiguration for policy reason. Then it won't advertise any
prefix with A-bit set. Also it may want all traffic going
through an AR and not allow direct communication among hosts
because of accounting. Then it won't advertise any prefix with
L-bit set either. As of my knowledge the prefix without any bit
set won't be advertised, which would hurt DNA operation.
3. Third, I propose we do away with 'Landmark Option with Y bit'.
The router can notify no-link change by simply putting the
landmark prefix in either PIO or LPIO. Then we can remove the
check for landmark from Section 5.2.7.
12. 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.
13. Acknowledgments
The design presented in this document grew out of discussions among The design presented in this document grew out of discussions among
the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, the members of the DNA design team (JinHyeock Choi, Tero Kauppinen,
James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland).
The spirited debates on the design, and the advantages and dis- The spirited debates on the design, and the advantages and dis-
advantages of various DNA solutions helped the creation of this advantages of various DNA solutions helped the creation of this
document. document.
Thanks to Syam Madanapalli who co-authored Thanks to Syam Madanapalli who co-authored
draft-jinchoi-dna-protocol2 from which this draft draws ideas, as draft-jinchoi-dna-protocol2 from which this draft draws ideas, as
well as providing feedback on draft-pentland-dna-protocol from which well as providing feedback on draft-pentland-dna-protocol from which
most of the text for this draft comes. most of the text for this draft comes.
Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol 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 and for helping to work out how to merge the two drafts into this
one. one.
Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli,
Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review
of this document. of draft-ietf-dna-protocol-01.
Thanks to Gabriel Montenegro for his review of Thanks to Gabriel Montenegro for his review of
draft-pentland-dna-protocol. draft-pentland-dna-protocol.
Thanks also to other members of the DNA working group for their Thanks also to other members of the DNA working group for their
comments that helped shape this work. comments that helped shape this work.
10. References 14. References
10.1 Normative References 14.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [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.
14.2 Informative References
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, [7] Thomson, S. and T. Narten, "IPv6 Stateless Address
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 Autoconfiguration", RFC2462 2462, December 1998.
(work in progress), July 2004.
[6] Moore, N., "Optimistic Duplicate Address Detection for IPv6", [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
draft-ietf-ipv6-optimistic-dad-05 (work in progress), December 1998.
February 2005.
[7] Daley, G., "Tentative Source Link-Layer Address Options for IPv6 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in Discovery (MLD) for IPv6", RFC 2710, October 1999.
progress), June 2004.
10.2 Informative References [10] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC2463 2463, December 1998.
[8] Thomson, S. and T. Narten, "IPv6 Stateless Address [11] Christensen, M., Kimball, K., and F. Solensky, "Considerations
Autoconfiguration", RFC2462 2462, December 1998. for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12
(work in progress), February 2005.
[9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [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.
[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 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [17] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[11] Choi, J., "Detecting Network Attachment in IPv6 Goals", [18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
draft-ietf-dna-goals-04 (work in progress), December 2004. Addressing Architecture", RFC 3513, April 2003.
[12] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network [19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
Attachment in IPv6 - Best Current Practices", in IPv6", RFC 4135, August 2005.
draft-narayanan-dna-bcp-00 (work in progress), June 2004.
[13] Yamamoto, S., "Detecting Network Attachment Terminology", [20] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-00 (work
in progress), September 2004.
[21] Yamamoto, S., "Detecting Network Attachment Terminology",
draft-yamamoto-dna-term-00 (work in progress), February 2004. draft-yamamoto-dna-term-00 (work in progress), February 2004.
[14] Manner, J. and M. Kojo, "Mobility Related Terminology", [22] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in progress), draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004. February 2004.
[15] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix [23] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress), list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005. April 2005.
[16] Pentland, B., "An Overview of Approaches to Detecting Network
Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
progress), February 2005.
Authors' Addresses 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
James Kempf James Kempf
DoCoMo Communications Labs USA DoCoMo Communications Labs USA
USA USA
Phone: Phone:
Email: kempf@docomolabs-usa.com Email: kempf@docomolabs-usa.com
Sathya Narayanan
Panasonic Digital Networking Lab
Two Research Way, 3rd Floor
Princeton, NJ 08536
USA
Phone: 609 734 7599
Email: sathya@Research.Panasonic.COM
URI:
Erik Nordmark Erik Nordmark
Sun Microsystems, Inc. Sun Microsystems, Inc.
17 Network Circle 17 Network Circle
Mountain View, CA Mountain View, CA
USA USA
Phone: +1 650 786 2921 Phone: +1 650 786 2921
Email: erik.nordmark@sun.com Email: erik.nordmark@sun.com
Brett Pentland (editor)
Brett Pentland
Centre for Telecommunications and Information Engineering Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering Department of Electrical and Computer Systems Engineering
Monash University Monash University
Clayton, Victoria 3800 Clayton, Victoria 3800
Australia Australia
Phone: +61 3 9905 5245 Phone: +61 3 9905 5245
Email: brett.pentland@eng.monash.edu.au Email: brett.pentland@eng.monash.edu.au
JinHyeock Choi JinHyeock Choi
Samsung Advanced Institute of Technology Samsung Advanced Institute of Technology
PO Box 111 PO Box 111
Suwon 440-600 Suwon 440-600
Korea Korea
Phone: +82-31-280-8194 Phone: +82-31-280-8194
Email: jinchoe@samsung.com Email: jinchoe@samsung.com
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. How the Goals are Met? Appendix A. How the Goals are Met?
The DNA goals document [11] contains a list of goals identified by G1 The DNA goals document [19] contains a list of goals identified by G1
to G10. This is also enumerated in the solutions discussion document to G10. This section discusses how the proposed scheme addresses
[16] generated by the DNA design team. This section discusses how each of these goals.
the proposed scheme addresses each of these goals.
G1 The Complete RA contains the complete list of prefixes advertised G1 The Complete RA contains the complete list of prefixes advertised
on the link allowing the host to determine whether link change has on the link allowing the host to determine whether link change has
occurred and to re-configure if necessary. occurred and to re-configure if necessary.
G2 Under normal circumstances the host will receive a RA response G2 Under normal circumstances the host will receive a RA response
within round-trip time and some processing time on the router. If within round-trip time and some processing time on the router. If
the first RA message is lost, if another router is on the link, a the first RA message is lost, if another router is on the link, a
second RA should arrive within a slot time and so on. second RA should arrive within a slot time and so on.
skipping to change at page 35, line 5 skipping to change at page 59, line 22
non-DNA routers and non DNA hosts will still receive the benefit non-DNA routers and non DNA hosts will still receive the benefit
of receiving an RA response from its current router faster than of receiving an RA response from its current router faster than
RFC 2461. RFC 2461.
G10 This technique is carried out on an interface by interface basis. G10 This technique is carried out on an interface by interface basis.
A host with multiple interfaces can get information about changes A host with multiple interfaces can get information about changes
to configuration on each interface, but would need a higher level to configuration on each interface, but would need a higher level
process to decide how the information from the various interfaces process to decide how the information from the various interfaces
relates to each other. relates to each other.
Appendix B. Sending directed advertisements without the neighbour cache
In the case where an entry is unable to be added to the neighbour
cache, a node MAY send responses direct to the link-layer address
specified in the Tentative Option. Also, RS packets sent without a
specificed source address may potentially contain a Tentative Option.
In this case the unicast link-layer address from the solicitation MAY
be extracted from the Tentative Option and used as the destination of
the link-layer frame for a responding Router Advertisment.
Sending such a packet MUST NOT consult the neighbour or destination
caches for address.
Such packets SHOULD scheduled as if they were unicast advertisements
as specified in [3].
If an implementation can not send a Router Advertisement using
information from the Tentative Option i.e, without consulting the
neighbour cache, then it SHOULD behave as if the Tentative Option was
not present in the solicitation message.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 96 change blocks. 
219 lines changed or deleted 1433 lines changed or added

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