draft-ietf-dna-protocol-08.txt   draft-ietf-dna-protocol-09.txt 
DNA Working Group S. Narayanan, Ed. DNA Working Group S. Narayanan, Ed.
Internet-Draft iTCD/CSUMB Internet-Draft iTCD/CSUMB
Expires: January 11, 2009 July 10, 2008 Intended status: Experimental November 30, 2009
Expires: June 2, 2010
Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 Design Alternative for Detecting Network Attachment in IPv6 Networks
Design) (DNAv6 Design Alternative)
draft-ietf-dna-protocol-08.txt draft-ietf-dna-protocol-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 11, 2009. This Internet-Draft will expire on June 2, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
Efficient detection of network attachment in IPv6 needs the following In this memo, a mechanism that was developed for detection of network
three components: a method for hosts to detect link change in the attachement is documented for future reference. This memo is an
presence of unmodified (non-DNAv6) routers, a method for the host to informational document and thus does not define a new standard. The
query routers on the link to identify the link (Link Identification) mechanism proposed in this experimental RFC requires the hosts to
and a method for the routers on the link to consistently respond to monitor all the prefixes advertised on the link and use it for link
such a query with minimal delay (Fast RA). Solving the link identification in the presence of non-DNAv6 routers is presented. A
identification based strictly on RFC 2461 is difficult because of the more efficient link-identification mechanism requiring the DNAv6
flexibility offered to routers in terms of prefixes advertised in a routers to monitor the link for advertised prefixes to assist the
router advertisement (RA) message. Similarly, the random delay in hosts in link identification combined with a fast router
responding to router solicitation messages imposed by RFC 2461 makes advertisement mechanism that selects the order of response for the
it difficult to receive an RA quickly. In this memo, a mechanism router deterministically is also presented.
that was developed for detection of network attachement is documented
for future reference. This memo is an informational document and
thus does not define a new standard. The mechanism proposed in this
informational RFC requires the hosts to monitor all the prefixes
advertised on the link and use it for link identification in the
presence of non-DNAv6 routers is presented. A more efficient link-
identification mechanism requiring the DNAv6 routers to monitor the
link for advertised prefixes to assist the hosts in link
identification combined with a fast router advertisement mechanism
that selects the order of response for the router deterministically
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Link Identification . . . . . . . . . . . . . . . . . . . 6 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 6
3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 8 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 26 skipping to change at page 3, line 26
4.1 New Flags . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 New Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10
4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 10 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 10
5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 10 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 10 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 10
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 10 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 10
5.1.2 Bootstrapping DNA Data Structures . . . . . . . . . . 11 5.1.2 Bootstrapping DNA Data Structures . . . . . . . . . . 11
5.1.3 Processing Router Advertisements . . . . . . . . . . . 12 5.1.3 Processing Router Advertisements . . . . . . . . . . . 12
5.1.4 Processing Router Solicitations . . . . . . . . . . . 12 5.1.4 Processing Router Solicitations . . . . . . . . . . . 12
5.1.5 Complete Router Advertisements . . . . . . . . . . . . 14 5.1.5 Complete Router Advertisements . . . . . . . . . . . . 13
5.1.6 Inclusion of a common prefixes . . . . . . . . . . . . 14 5.1.6 Inclusion of a common prefixes . . . . . . . . . . . . 14
5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 16 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 15
5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 17 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 16
5.1.9 Removing a Prefix from an Interface . . . . . . . . . 17 5.1.9 Removing a Prefix from an Interface . . . . . . . . . 16
5.1.10 Prefix Reassignment . . . . . . . . . . . . . . . . 18 5.1.10 Prefix Reassignment . . . . . . . . . . . . . . . . 17
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 18 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 18
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 18 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 18
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 19 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 18
5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 19 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 19
5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 20 5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 19
5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 20 5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 20
5.2.6 Processing Router Advertisements . . . . . . . . . . . 21 5.2.6 Processing Router Advertisements . . . . . . . . . . . 21
5.2.7 DNA and Address Configuration . . . . . . . . . . . . 26 5.2.7 DNA and Address Configuration . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . 29
6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 29 6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 29
6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 30 6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 30
6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 30 6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 30
6.4 Authorization and Detecting Network Attachment . . . . . . 31 6.4 Authorization and Detecting Network Attachment . . . . . . 31
6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 31 6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33
10. Informative References . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1 Normative References . . . . . . . . . . . . . . . . . . 34
10.2 Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . 38
1. Introduction 1. Introduction
An efficient but complex mechanism to achieve the goals for detecting An efficient but complex mechanism to achieve the goals for detecting
network attachment (DNA) [20] is documented in this memo. As the network attachment (DNA) [1] is documented in this memo. As the
community decided to simplify the goals of DNA, this document was community decided to simplify the goals of DNA, this document was
modified to be an informational RFC for archival purpose only. modified to be an informational RFC for archival purpose only.
Hence, this document MUST NOT be considered to be making Hence, this document MUST NOT be considered to be making
recommendation for the behavior of IPv6 hosts or routers. A simplied recommendation for the behavior of IPv6 hosts or routers. A simplied
solution to achieve detection of network attachment can be found at solution to achieve detection of network attachment can be found at
[6]. [8].
This memo documents the mechanism for an IPv6 host to detect link- This memo documents the mechanism for an IPv6 host to detect link-
change in the presence of unmodified (non-DNAv6) routers and change in the presence of unmodified (non-DNAv6) routers and
proposes new extensions to "IPv6 Neighbor Discovery" [3] to increase proposes new extensions to "IPv6 Neighbor Discovery" [2] to increase
the efficiency of link-change detection in the presence of DNAv6 the efficiency of link-change detection in the presence of DNAv6
enabled routers. The proposed mechanism defines the construct that enabled routers. The proposed mechanism defines the construct that
identifies a link, proposes an algorithm for the routers on the link identifies a link, proposes an algorithm for the routers on the link
to send a quick RA response without randomly waiting for upto to send a quick RA response without randomly waiting for upto
MAX_RA_DELAY_TIME seconds as specified in RFC2461 [3]. This memo MAX_RA_DELAY_TIME seconds as specified in RFC4861 [2].
also defines a mechanism to exchange Source Link-Layer Address
without affecting the neighbor caches when the host is performing
Optimistic DAD.
The rest of the document refers to the proposed mechanisms by the The rest of the document refers to the proposed mechanisms by the
term "DNAv6". term "DNAv6".
2. Terms and Abbreviations 2. Terms and Abbreviations
The term "link" is used as defined in RFC 2460 [2]. NOTE: this is The term "link" is used as defined in RFC 2460 [7]. 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.
Attachment: The process of establishing a layer-2 connection. Attachment: The process of establishing a layer-2 connection.
Attachment (and detachment) may cause a link-change. Attachment (and detachment) may cause a link-change.
DNA Hint: An indication from other subsystems or protocol layers that DNA Hint: An indication from other subsystems or protocol layers that
link-change may have occurred. link-change may have occurred.
Link-Change: Link-Change occurs when a host moves from a point-of- Link-Change: Link-Change occurs when a host moves from a point-of-
attachment on a link, to another point-of-attachment where it is attachment on a link, to another point-of-attachment where it is
unable to reach devices belonging to the previous link, without unable to reach devices belonging to the previous link, without
being forwarded through a router. being forwarded through a router.
Point-of-Attachment: A link-layer base-station, VLAN or port through Point-of-Attachment: A link-layer base-station, VLAN or port through
which a device attempts to reach the network. Changes to a which a device attempts to reach the network. Changes to a
host's point-of-attachment may cause link-change. host's point-of-attachment may cause link-change.
Reachability Detection: Determination that a device (such as a Reachability Detection: Determination that a device (such as a
router) is currently reachable. This is typically achieved using router) is currently reachable. This is typically achieved using
Neighbor Unreachability Detection procedure [3]. Neighbor Unreachability Detection procedure [2].
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 4861 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 RS-RA pair in the presence of of their current link from a single RS-RA pair in the presence of
either DNAv6 enabled routers and/or non-DNAv6 routers. either DNAv6 enabled routers and/or non-DNAv6 routers.
DNAv6 assumes that the host's link interface software and hardware is DNAv6 assumes that the host's link interface software and hardware is
capable of delivering a 'link up' event notification when layer 2 on capable of delivering a 'link up' event notification when layer 2 on
the host is configured and sufficiently stable for IP traffic. This the host is configured and sufficiently stable for IP traffic. This
event notification acts as a DNA Hint to the layer 3 DNA procedures event notification acts as a DNA Hint to the layer 3 DNA procedures
skipping to change at page 7, line 7 skipping to change at page 6, line 51
incorrect behaviour, and will also recover in case where a prefix is incorrect behaviour, and will also recover in case where a prefix is
reassigned without following the draft recommendations. reassigned without following the draft recommendations.
DNAv6 is based on using a Router Solicitation/Router Advertisement DNAv6 is based on using a Router Solicitation/Router Advertisement
exchange to both verify whether the host has changed link, and if it exchange to both verify whether the host has changed link, and if it
has, provide the host with the configuration information for the new has, provide the host with the configuration information for the new
link. The base method for detecting link change involves getting link. The base method for detecting link change involves getting
routers to listen to all of the prefixes that are being advertised by routers to listen to all of the prefixes that are being advertised by
other routers on the link. They can then respond to solicitations other routers on the link. They can then respond to solicitations
with complete prefix information. This information consists of the with complete prefix information. This information consists of the
prefixes a router would advertise itself as per RFC 2461, and also, prefixes a router would advertise itself as per RFC 4861, 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 router on a new link. a router on a new link.
skipping to change at page 8, line 19 skipping to change at page 8, line 14
Router Advertisements. By selecting a common prefix on the link to Router Advertisements. By selecting a common prefix on the link to
be the representative for the entire set of prefixes on the link, and be the representative for the entire set of prefixes on the link, and
making sure that it is included in every advertisement, it is making sure that it is included in every advertisement, it is
possible to omit some prefixes. The smallest prefix on the link is possible to omit some prefixes. The smallest prefix on the link is
selected as the common prefix. Such advertisements will not inform a selected as the common prefix. Such advertisements will not inform a
host of all of the prefixes at once, but in general these unsolicited host of all of the prefixes at once, but in general these unsolicited
advertisements will not be the first advertisement received on a advertisements will not be the first advertisement received on a
link. Inclusion of the smallest prefix simply ensures that there is link. Inclusion of the smallest prefix simply ensures that there is
overlap in the information advertised by each router on a link and overlap in the information advertised by each router on a link and
that hosts will thus not incorrectly interpret one of these that hosts will thus not incorrectly interpret one of these
incomplete RAs as an indication of movement. Even though this incomplete RAs as an indication of movement.
document recommends the use of a prefix as the representative of the
link, future specifications can use the Learned Prefix Option to
include a non-prefix identifier as long as this identifier is 128 bit
long to avoid collision with any currently assigned prefix. So, any
future non-prefix link identifier MUST be 128 bits long.
The Router Advertisement messages are, in general, larger than the 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 4861. 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.
3.2 Fast Router Advertisement 3.2 Fast Router Advertisement
According to RFC 2461 a solicited Router Advertisement should have a According to RFC 4861 a solicited Router Advertisement should have a
random delay between 0 and MAX_RA_DELAY_TIME, to avoid the random delay between 0 and MAX_RA_DELAY_TIME, 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 4861 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. This modified mechanism replaces the rate limit on responses
to RS required by [2]
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 3.1 to determine all the the same RAs that are used in Section 3.1 to determine all the
prefixes assigned to the link), the link-local addresses of all the prefixes assigned to the link), the link-local addresses of all the
other routers on the link. With this loosely consistent list, each other routers on the link. With this loosely consistent list, each
router can independently compute some function of the (link-local) router can independently compute some function of the (link-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.
4. Data Structures 4. Data Structures
This memo defines two new flags and three new options. This memo defines two new flags and three new options. The flags
and the options MUST be implemented using Router Advertisement Flags
option specified in RFC 5075 [21].
4.1 New Flags 4.1 New Flags
This document defines two new flags to be exchanged between the This document defines two new flags to be exchanged between the
router and hosts. One to indicate that the router sending the router and hosts. One to indicate that the router sending the
message is participating in the proposed protocol as well as a flag message is participating in the proposed protocol as well as a flag
to indicate the completeness of the set of prefixes included in its to indicate the completeness of the set of prefixes included in its
messages. messages.
DNAAware (D) DNAAware (D)
skipping to change at page 10, line 44 skipping to change at page 10, line 35
The routers maintain a set of conceptual data structures for each The routers maintain a set of conceptual data structures for each
interface to track the prefixes advertised by other routers on the interface to track the prefixes advertised by other routers on the
link, and also the set of DNA routers (the routers that will quickly link, and also the set of DNA routers (the routers that will quickly
respond to RSs) on the link. respond to RSs) on the link.
For each interface, routers maintain a list of all prefixes learned For each interface, routers maintain a list of all prefixes learned
from other routers on the link but not explicitly configured on the from other routers on the link but not explicitly configured on the
router's own interface. The list will be referred to in this router's own interface. The list will be referred to in this
document as "DNARouterLearnedPrefixList". Prefixes are learned by document as "DNARouterLearnedPrefixList". Prefixes are learned by
their reception within Prefix Information Options [3] in Router their reception within Prefix Information Options [2] in Router
Advertisements. Prefixes in Learned Prefix Options (see Section 4.3) Advertisements. Prefixes in Learned Prefix Options (see Section 4.3)
MUST NOT update the contents of DNARouterLearnedPrefixList. For each MUST NOT update the contents of DNARouterLearnedPrefixList. For each
prefix the router MUST store sufficient information to identify the prefix the router MUST store sufficient information to identify the
prefix and to know when to remove the prefix entry from the list. prefix and to know when to remove the prefix entry from the list.
This may be achieved by storing the following information: This may be achieved by storing the following information:
1. Prefix 1. Prefix
2. Prefix length 2. Prefix length
skipping to change at page 11, line 26 skipping to change at page 11, line 14
lifetime, whichever is earlier. lifetime, whichever is earlier.
For each interface, routers also maintain a list of the other routers For each interface, routers also maintain a list of the other routers
advertising on the link. The list will be referred to in this memo advertising on the link. The list will be referred to in this memo
as "DNARouterList". For each router from which a Router as "DNARouterList". For each router from which a Router
Advertisement is received with the DNAAware flag set, the following Advertisement is received with the DNAAware flag set, the following
information MUST be stored: information MUST be stored:
1. Link-local source address of advertising router 1. Link-local source address of advertising router
2. Token equal to the first 64 bits of an SHA-1 hash of the above 2. Expiry time
address
3. Expiry time
Each router MUST include itself in the DNARouterList and generate a Each router MUST include itself in the DNARouterList based on the
token for itself as described above based on the link-local address link-local address used in its RA messages.
used in its RA messages.
The expiry time for entries in DNARouterList is LEAST_VALID_LIFETIME The expiry time for entries in DNARouterList is LEAST_VALID_LIFETIME
after the last received Router Advertisement affecting the entry. after the last received Router Advertisement affecting the entry.
5.1.2 Bootstrapping DNA Data Structures 5.1.2 Bootstrapping DNA Data Structures
As per RFC 2461 [3], when an interface on a host first starts up, it As per RFC 4861 [2], when an interface on a host first starts up, it
SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations
separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of
the routers and prefixes active on the link. DNAv6 requires the the routers and prefixes active on the link. DNAv6 requires the
router to follow the same steps when its interface first starts up. router to follow the same steps when its interface first starts up.
Upon startup, a router interface SHOULD also send a few unsolicited Upon startup, a router interface SHOULD also send a few unsolicited
Router Advertisements as recommended in Section 6.2.4 of RFC 2461 Router Advertisements as recommended in Section 6.2.4 of RFC 4861
[3], in order to inform others routers on the link of its presence. [2], in order to inform others routers on the link of its presence.
During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) *
RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface RTR_SOLICITATION_INTERVAL + RetransTimer [2]), a router interface
both sends unsolicited Router Advertisements and responds to Router both sends unsolicited Router Advertisements and responds to Router
Solicitations, but the Router Advertisements MUST NOT include any DNA Solicitations, but the Router Advertisements MUST NOT include any DNA
specific options except for setting the DNAAware flag. The DNAAware specific options except for setting the DNAAware flag. The DNAAware
flag is set so that other routers will know to include this router in flag is set so that other routers will know to include this router in
their timing calculations for fast RA transmission. Other DNA their timing calculations for fast RA transmission. Other DNA
options are omitted because the router may have incomplete options are omitted because the router may have incomplete
information during bootstrap. information during bootstrap.
During the bootstrap period, the Complete flag in Router During the bootstrap period, the Complete flag in Router
Advertisements MUST NOT be set. Advertisements MUST NOT be set.
During the bootstrap period, the timing of Router Advertisement During the bootstrap period, the timing of Router Advertisement
transmission is as specified in RFC 2461. transmission is as specified in RFC 4861.
5.1.3 Processing Router Advertisements 5.1.3 Processing Router Advertisements
When a router receives a Router Advertisement, it first validates the When a router receives a Router Advertisement, it first validates the
RA as per the rules in RFC 2461, and then performs the actions RA as per the rules in RFC 4861, and then performs the actions
specified in RFC 2461. In addition, each valid Router Advertisement specified in RFC 4861. In addition, each valid Router Advertisement
is processed as follows: is processed as follows:
If the DNAAware flag is set in the RA, the router checks if there is If the DNAAware flag is set in the RA, the router checks if there is
an entry in its DNARouterList by looking up the source address of the an entry in its DNARouterList by looking up the source address of the
RA in that list. If not found, a new entry is added to RA in that list. If not found, a new entry is added to
DNARouterList, including the source address and a token equal to the DNARouterList, including the source address. The entry's expiry time
first 64 bits of an SHA-1 hash of the source address. The entry's is updated.
expiry time is updated.
Regardless of the state of the DNAAware flag, each PIO in the RA is Regardless of the state of the DNAAware flag, each PIO in the RA is
examined. If the prefix is not in the router's examined. If the prefix is not in the router's
DNARouterLearnedPrefixList and not in the router's AdvPrefixList [3], DNARouterLearnedPrefixList and not in the router's AdvPrefixList [2],
the prefix is added to the DNARouterLearnedPrefixList, and its expiry the prefix is added to the DNARouterLearnedPrefixList, and its expiry
time is set. time is set.
5.1.4 Processing Router Solicitations 5.1.4 Processing Router Solicitations
The usual response to a Router Solicitation SHOULD be a unicast RA. The usual response to a Router Solicitation SHOULD be a unicast RA.
However, to keep control of the rate of unicast RAs sent, a token However, to keep control of the rate of unicast RAs sent, a token
bucket is used. The token bucket is filled at one token every bucket is used. The token bucket is filled at one token every
UNICAST_RA_INTERVAL. A maximum of MAX_UNICAST_RA_BURST tokens are UNICAST_RA_INTERVAL. A maximum of MAX_UNICAST_RA_BURST tokens are
stored. stored.
skipping to change at page 13, line 11 skipping to change at page 12, line 44
that the following conditions to be met: that the following conditions to be met:
o A unicast send token is available. o A unicast send token is available.
o The source address of the Router Solicitation is NOT the o The source address of the Router Solicitation is NOT the
unspecified address (::). unspecified address (::).
If a unicast response is possible and the Router Solicitation If a unicast response is possible and the Router Solicitation
contains a Landmark Option whose prefix is present in contains a Landmark Option whose prefix is present in
DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send
an abbreviated Router Advertisement.This abbreviated advertisement an abbreviated Router Advertisement. This abbreviated advertisement
includes the Landmark prefix in a PIO if the prefix is in the includes the Landmark prefix in a PIO if the prefix is in the
AdvPrefixList or in a LPO if the prefix is found in the AdvPrefixList or in a LPO if the prefix is found in the
DNAROuterLearnedPrefixList, plus the base RA header and any SEND DNAROuterLearnedPrefixList, plus the base RA header and any SEND
options as appropriate. The DNAAware flag MUST be set. The Complete options as appropriate. The DNAAware flag MUST be set. The Complete
flag MUST NOT be set. This is the one exception where the common flag MUST NOT be set. This is the one exception where the common
prefix (i.e. the smallest prefix) MAY be omitted. prefix (i.e. the smallest prefix) MAY be omitted.
If there is NO Landmark Option in the received Router Solicitation or If there is NO Landmark Option in the received Router Solicitation or
it contains a Landmark Option whose prefix is NOT present in it contains a Landmark Option whose prefix is NOT present in
DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is
skipping to change at page 14, line 17 skipping to change at page 13, line 43
| Abbreviated RA| Landmark prefix present| Never | | Abbreviated RA| Landmark prefix present| Never |
| | on the link | | | | on the link | |
+---------------+--+----+-----+-----+----+-----+----+-----+----+ +---------------+--+----+-----+-----+----+-----+----+-----+----+
| Complete RA |No LO in RS or Landmark |No token available in| | Complete RA |No LO in RS or Landmark |No token available in|
| |prefix NOT present | the token bucket. | | |prefix NOT present | the token bucket. |
| | on the link. | | | | on the link. | |
+---------------+--+----+-----+-----+----+-----+----+-----+----+ +---------------+--+----+-----+-----+----+-----+----+-----+----+
5.1.5 Complete Router Advertisements 5.1.5 Complete Router Advertisements
A CompleteRA is formed as follows: A Complete RA is formed as follows:
Starting with a Router Advertisement with all fixed options (MTU, Starting with a Router Advertisement with all fixed options (MTU,
Advertisement Interval, flags, etc.), the DNAAware flag is set. As Advertisement Interval, flags, etc.), the DNAAware flag is set. As
many Prefix Information Options for explicitly configured prefixes as many Prefix Information Options for explicitly configured prefixes as
will fit are added to the Router Advertisement. If there is will fit are added to the Router Advertisement. If there is
sufficient room, a Learned Prefix Option as defined in Section 4.3 sufficient room, a Learned Prefix Option as defined in Section 4.3
containing as many of the learned prefixes as will fit is added. containing as many of the learned prefixes as will fit is added.
It may not be possible to include all of the prefixes in use on the It may not be possible to include all of the prefixes in use on the
link due to MTU or administrative limitations. If all Prefix link due to MTU or administrative limitations. If all Prefix
skipping to change at page 15, line 22 skipping to change at page 14, line 48
The router MUST pick the smallest prefix of all the prefixes The router MUST pick the smallest prefix of all the prefixes
configured on the routers on the link as the common prefix. The configured on the routers on the link as the common prefix. The
selection is made from among the prefixes whose valid lifetime is selection is made from among the prefixes whose valid lifetime is
greater than LEAST_VALID_LIFETIME, and learned prefixes which were greater than LEAST_VALID_LIFETIME, and learned prefixes which were
received within LEAST_VALID_LIFETIME. received within LEAST_VALID_LIFETIME.
For comparing prefixes, they are padded to the right with zeros to For comparing prefixes, they are padded to the right with zeros to
make them 128 bit unsigned integers. Note that this smallest prefix make them 128 bit unsigned integers. Note that this smallest prefix
is the smallest of all the prefixes configured on the routers on the is the smallest of all the prefixes configured on the routers on the
link and may not be the smallest prefix used in the link through link and may not be the smallest prefix used in the link through
stateful address configuration. stateful address configuration. Although, at the time of the writing
of this memo, prefixes used even for stateful address
autoconfiguration come from RAs.
When a router receives a new prefix in PIO, if the prefix is smaller When a router receives a new prefix in PIO or new prefix is
than the current common prefix and has valid lifetime greater than configured on the router, if the prefix is smaller than the current
common prefix and has valid lifetime greater than
LEAST_VALID_LIFETIME, the router selects that new prefix as a new LEAST_VALID_LIFETIME, the router selects that new prefix as a new
common prefix. In case a new prefix smaller than the current common common prefix. In case a new prefix smaller than the current common
prefix is advertised in LPIO, the router doesn't change the common prefix is advertised in LPIO, the router doesn't change the common
prefix. prefix.
5.1.6.2 Advertising the common prefix 5.1.6.2 Advertising the common prefix
Whenever a router sends an RA, whether solicited or unsolicited, it Whenever a router sends an RA, whether solicited or unsolicited, it
MUST include the common prefix in it. Hence, all RAs MUST carry the MUST include the common prefix in it. Hence, all RAs MUST carry the
common prefix except the abbreviated RA message sent in response to a common prefix except the abbreviated RA message sent in response to a
skipping to change at page 16, line 18 skipping to change at page 15, line 48
the change, the old common prefix MUST be included in RAs for the the change, the old common prefix MUST be included in RAs for the
following LEAST_VALID_LIFETIME. If the common prefix changes following LEAST_VALID_LIFETIME. If the common prefix changes
multiple times within LEAST_VALID_LIFETIME time window, the RA SHOULD multiple times within LEAST_VALID_LIFETIME time window, the RA SHOULD
include all of the previous common prefixes that were advertised include all of the previous common prefixes that were advertised
during that time window. during that time window.
For the purposes of propagating information, it is reasonable to For the purposes of propagating information, it is reasonable to
assume that after three advertisements of the change, all routers assume that after three advertisements of the change, all routers
have been made aware of it. have been made aware of it.
5.1.6.3.1 Using non-prefix identifier as common prefix
Although this memo only discusses the use of prefixes as common
identifier among multiple RA messages, a future specification or
ammendment may describe a mechanism to select a "link identifier"
that is not a prefix.
Sinice information from the Learned Prefix Option is only stored in
DNAHostPrefixList, and is only used for DNA purposes and because a
length field is used in LPIO, it is possible to carry any variable
length identifier less than or equal to 128 bits in an LPIO and store
it in DNAHostPrefixList (Section 5.2.1). To avoid any collision to
prefixes, an future non-prefix link identifier MUST be 128 bits long
and can be included in the LPIO of a RA message.
Future specifications are advised NOT to treat the information in an
LPIO as prefixes such as they would the prefixes found in a Prefix
Information Option. Future specifications are also advised NOT to
assume that the entries in a host's DNAHostPrefixList are actual
prefixes in use on the link.
5.1.7 Scheduling Fast Router Advertisements 5.1.7 Scheduling Fast Router Advertisements
RAs may need to be delayed to avoid collisions in the case that there RAs may need to be delayed to avoid collisions in the case that there
is more than one router on a link. The delay is calculated by is more than one router on a link. The delay is calculated by
determining a ranking for the router for the received RS, and determining a ranking for the router for the received RS, and
multiplying that by RA_SEPARATION. multiplying that by RA_SEPARATION.
A Host Token is needed from the RS to calculate the router's ranking. A Host identifier is needed from the RS to calculate the router's
The first 64 bits of an SHA-1 hash of the source address of the RS ranking. The first 64 bits of an SHA-1 hash of the source address of
MUST be used as the RS host token. the RS MUST be used as the RS host identifier.
A router's ranking is determined by taking the XOR of the RS Host A router's ranking is determined by taking the XOR of the RS Host
Token and each of the stored Router Tokens. The results of these XOR identifier and first 64 bits of an SHA-1 hash of the link local
operations are sorted lowest to highest. The router corresponding to source address of the router to be used in the RA. The results of
the first entry in the sorted list is ranked zero, the second, one, these XOR operations are sorted lowest to highest. The router
and so on. corresponding to the first entry in the sorted list is ranked zero,
the second, one, and so on.
Note: it is not necessary for a router to actually sort the whole Note: it is not necessary for a router to actually sort the whole
list. Each router just needs to determine its own position in the list. Each router just needs to determine its own position in the
sorted list. sorted list.
If Rank < FAST_RA_THRESHOLD, then the RA MUST be scheduled for If Rank < FAST_RA_THRESHOLD, then the RA MUST be scheduled for
transmission in Rank * RA_SEPARATION milliseconds. When the router transmission in Rank * RA_SEPARATION milliseconds. When the router
is ranked as zero, the resulting delay is zero, thus the RA SHOULD be is ranked as zero, the resulting delay is zero, thus the RA SHOULD be
sent immediately. sent immediately.
If Rank >= FAST_RA_THRESHOLD, then the RA MUST be replaced with a If Rank >= FAST_RA_THRESHOLD, then the RA MUST be replaced with a
Complete RA, if there is not one already, and scheduled for multicast Complete RA, if there is not one already, and scheduled for multicast
transmission as in RFC 2461. transmission as in RFC 4861.
5.1.8 Scheduling Unsolicited Router Advertisements 5.1.8 Scheduling Unsolicited Router Advertisements
Unsolicited router advertisements MUST be scheduled as per RFC 2461. Unsolicited router advertisements MUST be scheduled as per RFC 4861.
The "D" flag in the RA header MUST be set. The "D" flag in the RA header MUST be set.
They MAY be Complete RAs or MAY include only a subset of the They MAY be Complete RAs or MAY include only a subset of the
configured prefixes, but MUST include the common prefix as discussed configured prefixes, but MUST include the common prefix as discussed
in Section 5.1.6. in Section 5.1.6.
This ensures that there will be overlap in the sets of prefixes This ensures that there will be overlap in the sets of prefixes
contained in consecutive RAs on a link from DNA routers, and thus an contained in consecutive RAs on a link from DNA routers, and thus an
absence of that overlap can be used to infer link change. absence of that overlap can be used to infer link change.
skipping to change at page 18, line 49 skipping to change at page 18, line 13
scheme. It is up to the host to decide which scheme to use. 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 advertised on the link Hosts collect information about the prefixes advertised on the link
to facilitate change detection. 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 4861 "Prefix List" and will be referred to
here as the "DNAHostPrefixList". All prefixes SHOULD be stored, here as the "DNAHostPrefixList". All prefixes SHOULD be stored,
however an upper bound MUST be placed on the number stored to prevent however an upper bound MUST be placed on the number stored to prevent
overflow. For each prefix stored the host MUST store the following overflow. For each prefix stored the host MUST store the following
information: information:
1. Prefix 1. Prefix
2. Prefix length 2. Prefix length
3. Expiry time 3. Expiry time
skipping to change at page 21, line 6 skipping to change at page 20, line 17
the preferred lifetime of the current landmark prefix changes. the preferred lifetime of the current landmark prefix changes.
5.2.5 Sending Router Solicitations 5.2.5 Sending Router Solicitations
Upon the occurrence of a Layer 2 link-up event notification, hosts Upon the occurrence of a Layer 2 link-up event notification, hosts
SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting
and/or hysteresis to this behaviour as appropriate to the link and/or hysteresis to this behaviour as appropriate to the link
technology subject to the reliability of the DNA Hints. technology subject to the reliability of the DNA Hints.
Editor's note: The following two paragraph are talking about behavior Editor's note: The following two paragraph are talking about behavior
specified by 2461. Do we want to keep these? specified by 4861. Do we want to keep these?
The host also uses this to trigger sending an RS, subject to the rate The host also uses this to trigger sending an RS, subject to the rate
limitations in [3]. Since there is no natural limit on how limitations in [2]. Since there is no natural limit on how
frequently the link UP notifications might be generated, we take the frequently the link UP notifications might be generated, we take the
conservative approach that even if the host establishes new link conservative approach that even if the host establishes new link
layer connectivity very often, under no circumstances should it send layer connectivity very often, under no circumstances should it send
Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL
as specified by RFC 2461 [3]. as specified by RFC 4861 [2].
If the RS does not result in the host receiving at least one RA with If the RS does not result in the host receiving at least one RA with
at least one valid prefix, then the host can retransmit the RS. It at least one valid prefix, then the host can retransmit the RS. It
is allowed to multicast up to MAX_RTR_SOLICITATIONS RS messages is allowed to multicast up to MAX_RTR_SOLICITATIONS RS messages
spaced RTR_SOLICITATION_INTERVAL apart as per RFC 2461 [3]. spaced RTR_SOLICITATION_INTERVAL apart as per RFC 4861 [2].
Note that if link-layer notifications are reliable, a host can reset Note that if link-layer notifications are reliable, a host can reset
the number of sent Router Solicitations to 0, while still maintaining the number of sent Router Solicitations to 0, while still maintaining
RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is
necessary so that after each link up notification, the host is necessary so that after each link up notification, the host is
allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, allowed to send MAX_RTR_SOLICITATIONS to reliably discover the,
possibly new, prefix list. possibly new, prefix list.
Hosts SHOULD include a Landmark Option (LO) in the RS message with Hosts SHOULD include a Landmark Option (LO) in the RS message with
the landmark prefix chosen based on the rules in Section 5.2.4. the landmark prefix chosen based on the rules in Section 5.2.4.
skipping to change at page 23, line 4 skipping to change at page 22, line 16
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
IF (Receive RA is a CompleteRA) THEN IF (Receive RA is a CompleteRA) THEN
{ {
/* We already checked if there are any matching prefix before. /* We already checked if there are any matching prefix before.
Since this is a CompleteRA, implies link-change.*/ Since this is a CompleteRA, implies link-change.*/
Link change has occured. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} }
IF (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. Link change has occured.
RETURN; // Don't have to do the following checks. RETURN; // Don't have to do the following checks.
} --> }
IF (DNAHostPrefixList is marked as complete (i.e. the completeness Increment variable 'numberOfReceivedRAsSinceLastLinkUPEvent.
criteria is already met)) THEN
IF (numberOfReceivedRAsSinceLastLinkUPEvent IS EQUAL TO
NUM_RS_RA_COMPLETE), THEN
{ {
/* We already checked if there are any matching prefix before. /* numberOfReceivedRAsSinceLastLinkUPEvent is a variable that
Since the DNAHostPrefixList is complete, implies link-change.*/ tracks the number of RA received since last link up event.
Previous link UP event here refers to the link UP received before
the current link UP event that lead to this processing */
Link change has occured. Set numberOfReceivedRAsSinceLastLinkUPEvent to zero.
RETURN; // Don't have to do the following checks. IF (One of the received RA contains a prefix matching a prefix in
DNAHostPrefixList from before the current link UP event), THEN
{
No link change has occured
}
ELSE
{
link change has occured.
}
} }
Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done ELSE
since the previous link UP event (Previous link UP event here refers
to the link UP received before the current link UP event that lead to
this processing).
IF (One of the received RA contains a prefix matching a prefix in {
DNAHostPrefixList from before the current link UP event), THEN No
link change has occured ELSE link change has occured. No Decision. Wait for more RAs to collect NUM_RS_RA_COMPLETE
number of RS/RA exchanges.
}
5.2.6.2 Maintaining the DNAHostPrefixList 5.2.6.2 Maintaining the DNAHostPrefixList
The host should maintain a current DNAHostPrefixList with the The host should maintain a current DNAHostPrefixList with the
prefixes learned after the current link UP event and a previous prefixes learned after the current link UP event and a previous
DNAHostPrefixList with prefixes learned prior to the link UP event. DNAHostPrefixList with prefixes learned prior to the link UP event.
These data structures are maintained per interface. These data structures are maintained per interface.
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 current DNAHostPrefixList match the contents of the make the current DNAHostPrefixList match the contents of the
skipping to change at page 25, line 15 skipping to change at page 25, line 6
5.2.6.3 Router Reachability Detection and Default Router Selection 5.2.6.3 Router Reachability Detection and Default Router Selection
The receipt of a unicast RA from a router in response to a multicast The receipt of a unicast RA from a router in response to a multicast
RS indicates that the host has bi-directional reachability with the RS indicates that the host has bi-directional reachability with the
routers that responded. Such reachability is necessary for the host routers that responded. Such reachability is necessary for the host
to use a router as a default router, in order to have packets routed to use a router as a default router, in order to have packets routed
off the host's current link. It is notable that the choice of off the host's current link. It is notable that the choice of
whether the messages are addressed to multicast or unicast address whether the messages are addressed to multicast or unicast address
will have different reachability implications. The reachability will have different reachability implications. The reachability
implications from the hosts' perspective for the four different implications from the hosts' perspective for the four different
message exchanges defined by RFC 2461 [3] are presented in the table message exchanges defined by RFC 4861 [2] are presented in the table
below. The host can confirm bi-directional reachability from the below. The host can confirm bi-directional reachability from the
neighbor discovery or router discovery message exchanges except when neighbor discovery or router discovery message exchanges except when
a multicast RA is received at the host for its RS message. In this a multicast RA is received at the host for its RS message. In this
case, using IPv6 Neighbour Discovery procedures, the host cannot know case, using IPv6 Neighbour Discovery procedures, the host cannot know
whether the multicast RA is in response to its solicitation message whether the multicast RA is in response to its solicitation message
or whether it is a periodic un-solicited transmission from the router or whether it is a periodic un-solicited transmission from the router
[3]. [2].
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| Exchanges: |Upstream |Downstream| | Exchanges: |Upstream |Downstream|
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| multicast NS/NA | Y | Y | | multicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| unicast NS/NA | Y | Y | | unicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
| RS/multicast RA | N | Y | | RS/multicast RA | N | Y |
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
skipping to change at page 25, line 44 skipping to change at page 25, line 35
+-----------------+----+----+----+-----+ +-----------------+----+----+----+-----+
If the destination address of the received RA is a unicast address, If the destination address of the received RA is a unicast address,
the host knows the router heard its RS, and therefore that the host the host knows the router heard its RS, and therefore that the host
has reachability with the router. 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 [2] 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
default router list, the host SHOULD use the information in the RA to default router list, the host SHOULD use the information in the RA to
update the Default Route List entry with the new information. The update the Default Route List entry with the new information. The
host SHOULD add entries to the Default Router List for any routers host SHOULD add entries to the Default Router List for any routers
returning RAs that are not on the list. The host SHOULD confine returning RAs that are not on the list. The host SHOULD confine
selection of a router from the Default Router List to those routers selection of a router from the Default Router List to those routers
whose Neighbor Cache entries are in the REACHABLE state. Note that whose Neighbor Cache entries are in the REACHABLE state. Note that
the Default Router List SHOULD be updated as described here the Default Router List SHOULD be updated as described here
regardless of whether the RA indicates that the host has changed to a regardless of whether the RA indicates that the host has changed to a
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 host 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.7 DNA and Address Configuration 5.2.7 DNA and Address Configuration
When a host moves to a new point of attachment, a potential exists When a host moves to a new point of attachment, a potential exists
for a change in the validity of its unicast and multicast addresses for a change in the validity of its unicast and multicast addresses
on that network interface. In this section, host processing for on that network interface. In this section, host processing for
address configuration is specified. The section considers both address configuration is specified. The section considers both
statelessly and statefully configured addresses. statelessly and statefully configured addresses.
5.2.7.1 Duplicate Address Detection 5.2.7.1 Duplicate Address Detection
A DNA host MUST support optimistic Duplicate Address Detection [5] A DNA host MUST support optimistic Duplicate Address Detection [5]
for autoconfiguring unicast link local addresses. If a DNA host uses for autoconfiguring unicast link local addresses. If a DNA host uses
address autoconfiguration [8] for global unicast addresses, the DNA address autoconfiguration [3] 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.7.2 DNA and the Address Autoconfiguration State Machine 5.2.7.2 DNA and the Address Autoconfiguration State Machine
When a link level event occurs on a network interface indicating that When a link level event occurs on a network interface indicating that
the host has moved from one point of attachment to another, it is the host has moved from one point of attachment to another, it is
possible that a change in the reachability of the addresses possible that a change in the reachability of the addresses
associated with that interface may occur. Upon detection of such a associated with that interface may occur. Upon detection of such a
link event and prior to sending the RS initiating a DNA exchange, a link event and prior to sending the RS initiating a DNA exchange, a
DNA host MUST change the state of addresses associated with the DNA host MUST change the state of addresses associated with the
interface in the following way (address state designations follow RFC interface in the following way (address state designations follow RFC
2461): 4861):
o Addresses in the "Preferred" state are moved to the "Optimistic" o Addresses in the "Preferred" state are moved to the "Optimistic"
state, but the host defers sending out an NS to initiate Duplicate state, but the host defers sending out an NS to initiate Duplicate
Address Detection. Address Detection.
o Addresses in the "Optimistic" state remain in the "Optimistic" o Addresses in the "Optimistic" state remain in the "Optimistic"
state, but the host defers sending out an NS to initiate Duplicate state, but the host defers sending out an NS to initiate Duplicate
Address Detection. Address Detection.
o Addresses in the "Deprecated" state remain in the "Deprecated" o Addresses in the "Deprecated" state remain in the "Deprecated"
skipping to change at page 28, line 10 skipping to change at page 27, line 52
"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.7.3 DNA and Statefully Configured Addresses 5.2.7.3 DNA and Statefully Configured Addresses
The DHCPv6 specification [17] requires hosts to send a DHCPv6 CONFIRM The DHCPv6 specification [18] 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 [17] rather use the DHCPv6 CONFIRM message as described in RFC 3315 [18] 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 RFC 4861 [2]. That is, if an RA is received with
is received with the 'M' flag set, then the 'M' flag value is copied the 'M' flag set, then the 'M' flag value is copied into the
into the ManagedFlag, and if the ManagedFlag changes from False to ManagedFlag, and if the ManagedFlag changes from False to True the
True the host should run DHCPv6, but if the ManagedFlag changes from host should run DHCPv6, but if the ManagedFlag changes from True to
True to False, the host should continue to run DHCPv6. If, however, False, the host should continue to run DHCPv6. If, however, the
the value of the ManagedFlag remains the same both before and after value of the ManagedFlag remains the same both before and after the
the change in point of attachment on the same link has been change in point of attachment on the same link has been confirmed, it
confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain is NOT RECOMMENDED that the host run DHCPv6 to obtain new addresses,
new addresses, since the old addresses will continue to be valid. 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 [17], the host SHOULD use the host supports the Rapid Commit Option [18], 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.7.4 Packet Delivery During DNA 5.2.7.4 Packet Delivery During DNA
The specification of packet delivery before, during, and immediately The specification of packet delivery before, during, and immediately
after DNA when a change in point of attachment occurs is out of scope after DNA when a change in point of attachment occurs is out of scope
for this document. The details of how packets are delivered depends for this document. The details of how packets are delivered depends
on the mobility management protocols (if any) available to the host's on the mobility management protocols (if any) available to the host's
stack. stack.
5.2.7.5 Multicast Address Configuration 5.2.7.5 Multicast Address Configuration
Multicast routers on a link are aware of which groups are in use Multicast routers on a link are aware of which groups are in use
within a link. This information is used to undertake initiation of within a link. This information is used to undertake initiation of
multicast routing for off-link multicast sources to the link multicast routing for off-link multicast sources to the link
[10][18]. [11][19].
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 [18]. In particular, the the host has subscribed using MLD Report [19]. 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 [3] 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.
skipping to change at page 31, line 32 skipping to change at page 31, line 25
messages are digitally signed, and may not be easily modified, replay messages are digitally signed, and may not be easily modified, replay
attacks will contain the same Nonce option, as was used in the attacks will contain the same Nonce option, as was used in the
original solicitation. original solicitation.
6.4 Authorization and Detecting Network Attachment 6.4 Authorization and Detecting Network Attachment
When a host is determining if link change has occurred, it may When a host is determining if link change has occurred, it may
receive messages from devices with no advertised security mechanisms receive messages from devices with no advertised security mechanisms
purporting to be routers, nodes sending signed router advertisements purporting to be routers, nodes sending signed router advertisements
but with unknown delegation, or routers whose credentials need to be but with unknown delegation, or routers whose credentials need to be
checked [13]. Where a host wishes to configure an unsecured router, checked [14]. Where a host wishes to configure an unsecured router,
it SHOULD confirm bidirectional reachability with the device, and it it SHOULD confirm bidirectional reachability with the device, and it
MUST mark the device as unsecured as described in [4]. MUST mark the device as unsecured as described in [4].
In any case, a secured router SHOULD be preferred over an unsecured In any case, a secured router SHOULD be preferred over an unsecured
one, except where other factors (unreachability) make the router one, except where other factors (unreachability) make the router
unsuitable. Since secured routers' advertisement services may be unsuitable. Since secured routers' advertisement services may be
subject to attack, alternative (secured) reachability mechanisms from subject to attack, alternative (secured) reachability mechanisms from
upper layers, or secured reachability of other devices known to be on upper layers, or secured reachability of other devices known to be on
the same link may be used to check reachability in the first the same link may be used to check reachability in the first
instance. instance.
6.5 Addressing 6.5 Addressing
While a DNA host is checking for link-change, and observing DAD, it While a DNA host is checking for link-change, and observing DAD, it
may receive a DAD defense NA from an unsecured source. may receive a DAD defense NA from an unsecured source.
SEND says that DAD defenses MAY be accepted even from non SEND nodes According to the SEND specification (RFC 3971 [4]) DAD defenses MAY
for the first configured address [4]. 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 While deconfiguring the address is a valid action in the case where a
host collides with another address owner after arrival on a new link, host collides with another address owner after arrival on a new link,
In the case that the host returns immediately to the same link, such In the case that the host returns immediately to the same link, such
a DAD defense NA message may be a denial-of-service attempt. a DAD defense NA message may be a denial-of-service attempt.
7. Constants 7. Constants
NUM_RS_RA_COMPLETE NUM_RS_RA_COMPLETE
skipping to change at page 34, line 20 skipping to change at page 34, line 15
Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli,
Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review
of draft-ietf-dna-protocol-01. of draft-ietf-dna-protocol-01.
Thanks to Gabriel Montenegro for his review of Thanks to Gabriel Montenegro for his review of
draft-pentland-dna-protocol. draft-pentland-dna-protocol.
Thanks also to other members of the DNA working group for their Thanks also to other members of the DNA working group for their
comments that helped shape this work. comments that helped shape this work.
10. Informative References 10. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 10.1 Normative References
Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [1] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
Specification", RFC 2460, December 1998. in IPv6", RFC 4135, August 2005.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor
for IP Version 6 (IPv6)", RFC 2461, December 1998. Discovery for IP Version 6 (IPv6)", RFC 4861, December 1998.
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Neighbor Discovery (SEND)", RFC 3971, March 2005. Autoconfiguration", RFC2462 2462, December 1998.
[5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
IPv6", RFC 4429, April 2006. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[6] Krishnan, S. and SG. Daley, "Simple procedures for Detecting [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, April 2006.
10.2 Informative References
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[8] Krishnan, S. and SG. Daley, "Simple procedures for Detecting
Network Attachment in IPv6", draft-ietf-dna-simple-01 (work in Network Attachment in IPv6", draft-ietf-dna-simple-01 (work in
progress), July 2008. progress), July 2008.
[7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[8] Thomson, S. and T. Narten, "IPv6 Stateless Address [10] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
Autoconfiguration", RFC2462 2462, December 1998.
[9] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998. December 1998.
[10] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [11] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[11] Conta, A. and S. Deering, "Internet Control Message Protocol [12] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC2463 2463, December 1998. Specification", RFC2463 2463, December 1998.
[12] Christensen, M., Kimball, K., and F. Solensky, "Considerations [13] Christensen, M., Kimball, K., and F. Solensky, "Considerations
for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12
(work in progress), February 2005. (work in progress), February 2005.
[13] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [14] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[14] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, [15] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim,
"Candidate Access Router Discovery (CARD)", RFC 4066, "Candidate Access Router Discovery (CARD)", RFC 4066,
July 2005. July 2005.
[15] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, [16] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005. July 2005.
[16] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control [17] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE
Std 802.11, 1999. Std 802.11, 1999.
[17] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [18] 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.
[18] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [19] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[19] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [20] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[20] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment [21] Haberman, B. and R. Hinden, "IPv6 Router Advertisement Flags
in IPv6", RFC 4135, August 2005. Option", RFC 5175, March 2008.
[21] Yegin, A., "Link-layer Event Notifications for Detecting [22] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-00 (work Network Attachments", draft-ietf-dna-link-information-00 (work
in progress), September 2004. in progress), September 2004.
[22] Manner, J. and M. Kojo, "Mobility Related Terminology", [23] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in progress), draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004. February 2004.
[23] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix [24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress), list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005. April 2005.
Authors' Addresses Authors' Addresses
Sathya Narayanan (editor) Sathya Narayanan (editor)
School of Information Technology and Communications Design School of Information Technology and Communications Design
California State University, Monterey Bay California State University, Monterey Bay
3110, Inter-Garrison Road, Building 18, Room 150 3110, Inter-Garrison Road, Building 18, Room 150
Seaside, CA 93955 Seaside, CA 93955
USA USA
Phone: +1 (831) 582-33411 Phone: +1 (831) 582-33411
Email: sathya_narayanan@csumb.edu Email: snarayanan@csumb.edu
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
Erik Nordmark Erik Nordmark
Sun Microsystems, Inc. Sun Microsystems, Inc.
skipping to change at page 38, line 4 skipping to change at line 1653
Illkirch 67400 Illkirch 67400
FRANCE FRANCE
Phone: (33) 3 90 24 45 87 Phone: (33) 3 90 24 45 87
Email: montavont@dpt-info.u-strasbg.fr Email: montavont@dpt-info.u-strasbg.fr
URI: http://www-r2.u-strasbg.fr/~montavont/ URI: http://www-r2.u-strasbg.fr/~montavont/
Nick 'Sharkey' Moore Nick 'Sharkey' Moore
Email: sharkey@zoic.org Email: sharkey@zoic.org
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 99 change blocks. 
193 lines changed or deleted 196 lines changed or added

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