draft-ietf-dna-protocol-07.txt   draft-ietf-dna-protocol-08.txt 
DNA Working Group S. Narayanan, Ed. DNA Working Group S. Narayanan, Ed.
Internet-Draft iTCD/CSUMB Internet-Draft iTCD/CSUMB
Expires: August 27, 2008 Feb 24, 2008 Expires: January 11, 2009 July 10, 2008
Detecting Network Attachment in IPv6 Networks (DNAv6) Design document for Detecting Network Attachment in IPv6 Networks (DNAv6
draft-ietf-dna-protocol-07.txt Design)
draft-ietf-dna-protocol-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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 August 27, 2008. This Internet-Draft will expire on January 11, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Efficient detection of network attachment in IPv6 needs the following Efficient detection of network attachment in IPv6 needs the following
three components: a method for hosts to detect link change in the three components: a method for hosts to detect link change in the
presence of unmodified (non-DNAv6) routers, a method for the host to presence of unmodified (non-DNAv6) routers, a method for the host to
query routers on the link to identify the link (Link Identification) query routers on the link to identify the link (Link Identification)
and a method for the routers on the link to consistently respond to and a method for the routers on the link to consistently respond to
such a query with minimal delay (Fast RA). Solving the link such a query with minimal delay (Fast RA). Solving the link
identification based strictly on RFC 2461 is difficult because of the identification based strictly on RFC 2461 is difficult because of the
flexibility offered to routers in terms of prefixes advertised in a flexibility offered to routers in terms of prefixes advertised in a
router advertisement (RA) message. Similarly, the random delay in router advertisement (RA) message. Similarly, the random delay in
responding to router solicitation messages imposed by RFC 2461 makes responding to router solicitation messages imposed by RFC 2461 makes
it difficult to receive an RA quickly. In this memo, a mechanism it difficult to receive an RA quickly. In this memo, a mechanism
that requires the hosts to monitor all the prefixes advertised on the that was developed for detection of network attachement is documented
link and use it for link identification in the presence of non-DNAv6 for future reference. This memo is an informational document and
routers is presented. A more efficient link-identification mechanism thus does not define a new standard. The mechanism proposed in this
requiring the DNAv6 routers to monitor the link for advertised informational RFC requires the hosts to monitor all the prefixes
prefixes to assist the hosts in link identification combined with a advertised on the link and use it for link identification in the
fast router advertisement mechanism that selects the order of presence of non-DNAv6 routers is presented. A more efficient link-
response for the router deterministically is also presented. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 6
3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 8
3.3 Tentative Source Link-Layer Address option (TO) . . . . . 8
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 9 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 9 4.1 New Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10
4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 11 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 10
4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 12
5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 13
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 13
5.1.2 Bootstrapping DNA Data Structures . . . . . . . . . . 14
5.1.3 Processing Router Advertisements . . . . . . . . . . . 15
5.1.4 Processing Router Solicitations . . . . . . . . . . . 15
5.1.5 Complete Router Advertisements . . . . . . . . . . . . 17
5.1.6 Inclusion of a common prefixes . . . . . . . . . . . . 17
5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 19
5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 20
5.1.9 Removing a Prefix from an Interface . . . . . . . . . 20
5.1.10 Prefix Reassignment . . . . . . . . . . . . . . . . 20
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22
5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 22
5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 23
5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 23
5.2.6 Processing Router Advertisements . . . . . . . . . . . 24
5.2.7 DNA and Address Configuration . . . . . . . . . . . . 29
5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 32
5.3.1 Sending solicitations containing Tentative Options . . 32
5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 33
5.3.3 Sending directed advertisements without the
neighbour cache . . . . . . . . . . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . 36
6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 36
6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 36
6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 36
6.4 Authorization and Detecting Network Attachment . . . . . . 38
6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 38
9. Changes since -05 . . . . . . . . . . . . . . . . . . . . . 40
10. Changes since -04 . . . . . . . . . . . . . . . . . . . . . 40
11. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 41
12. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 41 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 10
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 10
5.1.2 Bootstrapping DNA Data Structures . . . . . . . . . . 11
5.1.3 Processing Router Advertisements . . . . . . . . . . . 12
5.1.4 Processing Router Solicitations . . . . . . . . . . . 12
5.1.5 Complete Router Advertisements . . . . . . . . . . . . 14
5.1.6 Inclusion of a common prefixes . . . . . . . . . . . . 14
5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 16
5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 17
5.1.9 Removing a Prefix from an Interface . . . . . . . . . 17
5.1.10 Prefix Reassignment . . . . . . . . . . . . . . . . 18
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 18
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 18
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 19
5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 19
5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 20
5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 20
5.2.6 Processing Router Advertisements . . . . . . . . . . . 21
5.2.7 DNA and Address Configuration . . . . . . . . . . . . 26
13. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . 29
6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 29
6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 30
6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 30
6.4 Authorization and Detecting Network Attachment . . . . . . 31
6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 32
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33
16.1 Normative References . . . . . . . . . . . . . . . . . . 43 10. Informative References . . . . . . . . . . . . . . . . . . . 34
16.2 Informative References . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . 38
1. Introduction 1. Introduction
This memo defines a mechanism for an IPv6 host to detect link-change An efficient but complex mechanism to achieve the goals for detecting
in the presence of unmodified (non-DNAv6) routers and proposes new network attachment (DNA) [20] is documented in this memo. As the
extensions to "IPv6 Neighbor Discovery" [3] to increase the community decided to simplify the goals of DNA, this document was
efficiency of link-change detection in the presence of DNAv6 enabled modified to be an informational RFC for archival purpose only.
routers. The proposed mechanism define the construct that identifies Hence, this document MUST NOT be considered to be making
a link, proposes an algorithm for the routers on the link to send a recommendation for the behavior of IPv6 hosts or routers. A simplied
quick RA response without randomly waiting for upto MAX_RA_DELAY_TIME solution to achieve detection of network attachment can be found at
seconds as specified in RFC2461 [3]. This memo also defines a [6].
mechanism to exchange Source Link-Layer Address without affecting the
neighbor caches when the host is performing Optimistic DAD. This memo documents the mechanism for an IPv6 host to detect link-
change in the presence of unmodified (non-DNAv6) routers and
proposes new extensions to "IPv6 Neighbor Discovery" [3] to increase
the efficiency of link-change detection in the presence of DNAv6
enabled routers. The proposed mechanism defines the construct that
identifies a link, proposes an algorithm for the routers on the link
to send a quick RA response without randomly waiting for upto
MAX_RA_DELAY_TIME seconds as specified in RFC2461 [3]. This memo
also defines a mechanism to exchange Source Link-Layer Address
without affecting the neighbor caches when the host is performing
Optimistic DAD.
The rest of the document refers to the proposed mechanisms by the 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 [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.
Attachment: The process of establishing a layer-2 connection. Attachment: The process of establishing a layer-2 connection.
skipping to change at page 8, line 17 skipping to change at page 9, line 30
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.
3.3 Tentative Source Link-Layer Address option (TO) 4. Data Structures
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 use of Source Link-Layer Address options
(SLLAOs) in Router and Neighbour Solicitation messages from a
tentative address (while Duplicate Address Detection is occurring).
This is because receiving a Neighbour Solicitation (NS) or Router
Solicitation (RS) containing an SLLAO would otherwise overwrite an
existing cache entry, even if the cache entry contained the
legitimate address owner, and the solicitor was a duplicate address.
Neighbour Advertisement (NA) messages don't have such an issue, since
the Advertisement message contains a flag which explicitly disallows
overriding of existing cache entries, by the target link-layer
address option carried within.
The effect of preventing SLLAOs for tentative addresses is that
communications with these addresses are difficult for the tentative
period. Sending solicitations without these options causes an
additional round-trip for neighbour discovery if the advertiser does
not have an existing neighbour cache entry for the solicitor. In
some cases, multicast advertisements will be scheduled, where
neighbour discovery is not possible on the advertiser.
A new option, called Tentative Option (TO), is defined that functions
in the same role as the Source Link-Layer Address option defined by
[3], but it MUST NOT override an existing neighbour cache entry.
The differing neighbour cache entry MUST NOT be affected by the
reception of the Tentative Option. This ensures that tentative
addresses are unable to modify legitimate neighbour cache entries.
In the case where an entry is unable to be added to the neighbour
cache, a node MAY send responses direct to the link-layer address
specified in the TO.
4. Message Formats
This memo defines two new flags for inclusion in the router
advertisement message and three new options.
4.1 Router Advertisement This memo defines two new flags and three new options.
DNAv6 modifies the format of the Router Advertisement message by 4.1 New Flags
defining a bit to indicate that the router sending the message is
participating in the DNAv6 protocol as well as a flag to indicate the
completeness of the set of prefixes included in the Router
Advertisement. The new message format is as follows:
0 1 2 3 This document defines two new flags to be exchanged between the
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 router and hosts. One to indicate that the router sending the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ message is participating in the proposed protocol as well as a flag
| Type | Code | Checksum | to indicate the completeness of the set of prefixes included in its
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ messages.
| Cur Hop Limit |M|O|H|Pr |D|C|R| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
DNAAware (D) DNAAware (D)
The DNAAware (D) bit indicates that the router sending the RA is The DNAAware (D) bit indicates that the router sending the message
participating in the DNAv6 protocol. Other routers should include is participating in the protocol documented in this memo. Other
this router in calculating response delay tokens. routers should include this router in calculating response delay
tokens.
Complete (C) Complete (C)
The Complete (C) bit indicates that the Router Advertisement The Complete (C) bit indicates that the Router Advertisement
contains PIOs for all prefixes explicitly configured on the contains PIOs for all prefixes explicitly configured on the
sending router, and, if other routers on the link are advertising sending router, and, if other routers on the link are advertising
additional prefixes, a Learned Prefix Option containing all additional prefixes, a Learned Prefix Option containing all
additional prefixes that the router has heard from other routers additional prefixes that the router has heard from other routers
on the link. on the link.
Reserved (R)
The reserved field is reduced from 3 bits to 1 bit.
4.2 Landmark Option 4.2 Landmark Option
The Landmark Option is used by hosts in a Router Solicitation message The Landmark Option is used by hosts in a Router Solicitation message
to ask the routers on a link if the specified prefix is being to ask the routers on a link if the specified prefix is being
advertised by some router on the link. advertised by some router on the link.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pref Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Landmark Prefix ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length of the option in
units of 8 octets. Set to 2 or 3.
Pref Length
An 8 bit unsigned integer representing the number of bits in the
prefix to be used for matching.
Reserved
A 38 bit unused field. It MUST be initialised to zero by the
sender, and ignored by the receiver.
Prefix
A prefix being used by the host currently for a global IPv6
address, padded at the right with zeros. If the prefix length is
less than 65 bits, only 64 bits need be included, otherwise 128
bits are included.
4.3 Learned Prefix Option 4.3 Learned Prefix Option
The Learned Prefix Option (LPO) is used by a router to indicate The Learned Prefix Option (LPO) is used by a router to indicate
prefixes that are being advertised by other routers on the link, but prefixes that are being advertised by other routers on the link, but
not by itself. not by itself.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Prefix Len N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix N +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length of the option in
units of 8 octets.
Prefix Len
One or more fields (N) each consisting of an 8-bit unsigned
integer representing the prefix lengths of the following prefixes.
The Prefix Len fields are ordered the same as the Prefix fields so
that the first Prefix Len field represents the prefix length of
the prefix contained in the first prefix field, and so on.
Padding
Zero padding sufficient to align the following prefix field on an
8-octet boundary.
Prefix
One or more fields (N) each containing a 128-bit address
representing a prefix that has been heard on the link but is not
explicitly configured on this router.
Description
This option MUST only be included in a Router Advertisement. This
option contains prefixes that are being advertised on the link but
are not explicitly configured on the sending router. The router
MUST NOT include any prefixes with a zero valid lifetime in the
LPO.
4.4 Tentative option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (Requires IANA Allocation) suggest 17 (0x11)
Length
The length of the option (including the type and length fields) in
units of 8 octets.
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
The routers maintain a set of conceptual data structures for each The routers maintain a set of conceptual data structures for each
skipping to change at page 24, line 17 skipping to change at page 21, line 32
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.
Hosts SHOULD include a tentative source link layer address option Hosts SHOULD include a tentative source link layer address option
(TO) in the RS message Section 5.3. The router solicitation message (TO) in the RS message. The router solicitation message is sent to
is sent to the All_Routers_Multicast address and the source address the All_Routers_Multicast address and the source address MUST be the
MUST be the link local address of the host. link local address of the host.
The host MUST consider its link local address to be in the The host MUST consider its link local address to be in the
"Optimistic" state for duplicate address detection [5] until either "Optimistic" state for duplicate address detection [5] until either
the returned RA confirms that the host has not switched to a new link the returned RA confirms that the host has not switched to a new link
or, if an link change has occurred, until the host has performed or, if an link change has occurred, until the host has performed
optimistic duplicate address detection for the address. optimistic duplicate address detection for the address.
5.2.6 Processing Router Advertisements 5.2.6 Processing Router Advertisements
When the host receives a Router Advertisement, the host checks for When the host receives a Router Advertisement, the host checks for
skipping to change at page 29, line 17 skipping to change at page 26, line 30
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 [7] for global unicast addresses, the DNA address autoconfiguration [8] for global unicast addresses, the DNA
host MUST support optimistic Duplicate Address Detection for host MUST support optimistic Duplicate Address Detection for
autoconfiguring global unicast addresses. autoconfiguring global unicast addresses.
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
skipping to change at page 30, line 45 skipping to change at page 28, line 10
"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 [16] requires hosts to send a DHCPv6 CONFIRM The DHCPv6 specification [17] requires hosts to send a DHCPv6 CONFIRM
message when a change in point of attachment is detected. Since the message when a change in point of attachment is detected. Since the
DNA protocol provides the same level of movement detection as the DNA protocol provides the same level of movement detection as the
DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the
DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive
signaling. If, however, a non-DNA RA is received, the host SHOULD signaling. If, however, a non-DNA RA is received, the host SHOULD
use the DHCPv6 CONFIRM message as described in RFC 3315 [16] rather use the DHCPv6 CONFIRM message as described in RFC 3315 [17] 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 31, line 30 skipping to change at page 28, line 43
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 [16], the host SHOULD use the host supports the Rapid Commit Option [17], 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 [9][17]. multicast routing for off-link multicast sources to the link
[10][18].
If the returning RAs indicate that the host has not moved to a new If the returning RAs indicate that the host has not moved to a new
link, no further action is required for multicast addresses to which link, no further action is required for multicast addresses to which
the host has subscribed using MLD Report [17]. In particular, the the host has subscribed using MLD Report [18]. In particular, the
host MUST NOT perform MLD signaling for any multicast addresses host MUST NOT perform MLD signaling for any multicast addresses
unless such signaling was not performed prior to movement to the new unless such signaling was not performed prior to movement to the new
point of attachment. For example, if an address is put into the point of attachment. For example, if an address is put into the
"Optimistic" state prior to movement but the MLD Report for the "Optimistic" state prior to movement but the MLD Report for the
Solicited_Node_Multicast_Address is not sent prior to movement to a Solicited_Node_Multicast_Address is not sent prior to movement to a
new point of attachment, the host MUST send the MLD Report on the new new point of attachment, the host MUST send the MLD Report on the new
point of attachment prior to performing optimistic Duplicate Address point of attachment prior to performing optimistic Duplicate Address
Detection. The host SHOULD use the procedure described below for Detection. The host SHOULD use the procedure described below for
sending an MLD Report. sending an MLD Report.
If, on the other hand, the DNA RA indicates that the host has moved If, on the other hand, the DNA RA indicates that the host has moved
to a new link, the host MUST issue a new MLD Report to the router for to a new link, the host MUST issue a new MLD Report to the router for
subscribed multicast addresses. MLD signaling for the subscribed multicast addresses. MLD signaling for the
Solicited_Node_Multicast_Addresses [7] MUST be sent prior to Solicited_Node_Multicast_Addresses [8] MUST be sent prior to
performing signaling for optimistic DAD. performing signaling for optimistic DAD.
To avoid lengthy delays in address reconfiguration, it is RECOMMENDED To avoid lengthy delays in address reconfiguration, it is RECOMMENDED
that the host send the MLD Report for newly configured addresses that the host send the MLD Report for newly configured addresses
immediately, as soon as the addresses have been constructed, rather immediately, as soon as the addresses have been constructed, rather
than waiting for a random backoff. than waiting for a random backoff.
Hosts MUST defer MLD signaling until after the results of DNA have Hosts MUST defer MLD signaling until after the results of DNA have
confirmed whether or not a link change has occurred. confirmed whether or not a link change has occurred.
5.3 Tentative options for IPv6 ND
5.3.1 Sending solicitations containing Tentative Options
Tentative Options may be sent in Router and Neighbour Solicitations,
as described below.
In a case where it is safe to send a Source Link-Layer Address
Option, a host SHOULD NOT send a TO, since the message may be
misinterpreted by legacy nodes.
Importantly, a node MUST NOT send a Tentative Option in the same
message where a Source Link-Layer Address Option is sent.
5.3.1.1 Sending Neighbour Solicitations with Tentative Options
Neighbour Solicitations sent to unicast addresses MAY contain a
Tentative Option.
5.3.1.2 Sending Router Solicitations with Tentative Options
Any Router Solicitation from a Preferred, Deprecated or Optimistic
address MAY be sent with a Tentative Option [5].
An extension which allows Router Solicitations to be sent with a TO
from the unspecified address is described in Section 5.3.3.
5.3.2 Receiving Tentative Options
Receiving a Tentative Option allows nodes to unicast responses to
solicitations without performing neighbour discovery.
It does this by allowing the solicitation to create STALE neighbour
cache entries if one doesn't exist, but only update an entry if the
link-layer address in the option matches the entry.
Additionally, messages containing TO may be used to direct
advertisements to particular link-layer destinations without updating
neighbour cache entries. This is described in Section 5.3.3.
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
Section 5.3.3.
5.3.2.1 Receiving Neighbour Solicitations containing Tentative Options
The Tentative Option is 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.
5.3.2.2 Receiving Router Solicitations containing Tentative Options
In IPv6 Neighbour Discovery [3], responses to Router Solicitations
are either sent to the all-nodes multicast address, or may be sent to
the solicitation's source address if it is a unicast address.
Including a Tentative Option in the solicitation allows a router to
choose to send a packet directly to the link-layer address even in
situations where this would not normally be possible.
For Router Solicitations with unicast source addresses, neighbour
caches SHOULD be updated with the link-layer address from a Tentative
Option if there is no differing neighbour cache entry. In this case,
Router Advertisement continues as in Section 6.2.6 of [3].
For received solicitations with a differing link-layer address to
that stored in the neighbour cache, the node processes the
solicitation as defined in Section 6.2.6 of [3], except that the
Neighbour Cache entry MUST NOT be modified.
5.3.3 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.
Each router can have its own configuration with respect to sending
RA, and the treatment of router and neighbor solicitations.
Different timers and constants might be used by different routers,
such as the delay between Router Advertisements or delay before
replying to an RS. If a host is changing its IPv6 link, the new
router on that link may have a different configuration and may
introduce more delay than the previous default r < title="Overlapping
Coverage"> If a host can be attached to different links at the same
time with the same interface, the host will probably listen to
different routers, at least one on each link. To be simultaneously
attached to several links may be very valuable for a MN when it moves
from one access network to another. If the node can still be
reachable through its old link while configuring the interface for
its new link, packet loss can be minimized.
Such a situation may happen in a wireless environment if the link
layer technology allows the MN to be simultaneously attached to
several points of attachment and if the coverage area of access
points are overlapping.
For the purposes of DNA, it is necessary to treat each of these
points-of-attachment separately, otherwise incorrect conclusions of
link-change may be made even if another of the link-layer connections
is valid.
When a host is participating in DNA on a link where multicast
snooping is in use, multicast packets may not be delivered to the
LAN-segment to which the host is attached until MLD signaling has
been performed [9][17] [11]. Where DNA relies upon multicast packet
delivery (for example, if a router needs to send a Neighbor
Solicitation to the host), its function will be degraded until after
an MLD report is sent.
Where it is possible that multicast snooping is in operation, hosts
MUST send MLD group joins (MLD reports) for solicited nodes'
addresses swiftly after starting DNA procedures.
Link partitioning occurs when a link's internal switching or relaying
hardware fails, or if the internal communications within a link are
prevented due to topology changes or wireless propagation.
When a host is on a link which partitions, only a subset of the
addresses or devices it is communicating with may still be available.
Where link partitioning is rare (for example, with wired
communication between routers on the link), existing router and
neighbor discovery procedures may be sufficient for detecting change.
6. Security Considerations 6. Security Considerations
6.1 Attacks on the Token Bucket 6.1 Attacks on the Token Bucket
A host on the link could easily drain the token bucket(s) of the A host on the link could easily drain the token bucket(s) of the
router(s) on the link by continuously sending RS messages on the router(s) on the link by continuously sending RS messages on the
link. For example, if a host sends one RS message every link. For example, if a host sends one RS message every
UNICAST_RA_INTERVAL, and send a additional RS every third UNICAST_RA_INTERVAL, and send a additional RS every third
UNICAST_RA_INTERVAL, the token bucket in the router(s) on the link UNICAST_RA_INTERVAL, the token bucket in the router(s) on the link
will drain within MAX_UNICAST_RA_BURST * UNICAST_RA_INTERVAL * 3 will drain within MAX_UNICAST_RA_BURST * UNICAST_RA_INTERVAL * 3
skipping to change at page 38, line 11 skipping to change at page 31, line 32
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 [12]. Where a host wishes to configure an unsecured router, checked [13]. 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.
skipping to change at page 38, line 36 skipping to change at page 32, line 10
may receive a DAD defense NA from an unsecured source. may receive a DAD defense NA from an unsecured source.
SEND says that DAD defenses MAY be accepted even from non SEND nodes SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [4]. for the first configured address [4].
While deconfiguring the address is a valid action in the case where a While deconfiguring the address is a valid action in the case where a
host collides with another address owner after arrival on a new link, host collides with another address owner after arrival on a new link,
In the case that the host returns immediately to the same link, such In the case that the host returns immediately to the same link, such
a DAD defense NA message may be a denial-of-service attempt. a DAD defense NA message may be a denial-of-service attempt.
7. IANA Considerations 7. Constants
This memo defines three new Neighbor Discovery [3] options, which
must be assigned Option Type values within the option numbering space
for Neighbor Discovery messages:
1. The Landmark option, described in Section 4.2; and
2. The Learned Prefix option, described in Section 4.3.
3. The tentative option, described in Section 4.4
8. Constants
NUM_RS_RA_COMPLETE NUM_RS_RA_COMPLETE
Definition: Number of RS/RA exchange messages necessary to declare Definition: Number of RS/RA exchange messages necessary to declare
the prefix list to be complete. the prefix list to be complete.
Value: 2 Value: 2
MIN_RA_WAIT MIN_RA_WAIT
Definition: Minimum time the host will have to wait before Definition: Minimum time the host will have to wait before
skipping to change at page 40, line 18 skipping to change at page 33, line 25
Value: 3 Value: 3
LEAST_VALID_LIFETIME LEAST_VALID_LIFETIME
Definition: The time for which received prefix can be considered Definition: The time for which received prefix can be considered
valid for use in link indentification. valid for use in link indentification.
Value: LEAST_VALID_LIFETIME Value: LEAST_VALID_LIFETIME
9. Changes since -05 8. Contributors
o Removed DNARAReceivedFlag and related text. The RA processing is
very simple now: Check for prefix overlap, else if check if
completeRA, else fall back on CPL.
o Changed Router Configuration variables to constants.
o Remove "Complete Prefix List Generation" subsection from the
"Overview" section. The text was not adding that much value to
the document. We talk further about CPL generation in seciton
"Maintaining the DNAHostPrefixList".
o Added a table to explain the conditions for different type of
router advertisement, a table was added to Section 5.1.4.
o All "link change" decisions were made "MUSTs" and "no link change"
decision "SHOULDs" in the process RA message section of the host
operation.
o Revised "Maintained the DNAHostPrefixList" section.
o Revised "Inclusion of the common prefix" section (JinHyeock).
o Thorough review of the whole document.
10. Changes since -04
o Edited the document to improve readability and clarity.
o Edited the document to make the distinction between what is
recommended by RFC 2461 and what is modified behavior for DNA.
(The flash renumbering sections were not touchted.)
11. Changes since -03
o A global replace of "1.5 hours" with "3 times maximum of
MaxRtrAdvInterval".
o Removed Y/N bit from the landmark option and modified the text to
remove all references to the Y/N bit. The description in
Section 3.1 was twicked to explain the semantics of Yes and No.
o Removed MaxCacheTime and reference to use of prior link
information.
o Made NUM_RS_RA_COMPLETE a constant with value 2, MIN_RA_WAIT a
constant with value 4 seconds.
o Removed reference to the terminology draft as there was nothing
important to be transferred.
o Removed sections on Link indication, complications and DNA without
link UP notifications.
o Removed reference to linkID and replaced with smallest prefix.
Which requires a DNARAReceivedFlag to be added to the conceptual
values maintained by the host.
o Included sentence to mandate the configuration of atleast one
prefix on each routers even when stateful address configuration is
used. The change was made in Section 5.1.6.
12. Changes since -02
o Changed the Router Advertisment processing in Section 5.2.6 and
Section 5.2.6.1 to fix a mistake in the logic.
o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT,
MAX_CACHE_TIME to NUM_RS_RA_COMPLETE, MIN_RA_WAIT, MaxCacheTIme.
Added an open issue whether these should be variables or
constants.
o Fixed some typos.
13. Open issues
1. Is my re-write of Section 5.2.6.2 right?
2. Is Section 5.3 still too long?
14. Contributors
This document is the result of merging four different working group This document is the result of merging four different working group
documents. The draft-ietf-dna-protocol-01.txt authored by James documents. The draft-ietf-dna-protocol-01.txt authored by James
Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock
Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02
authored by JinHyeock Choi and Erik Normark provided the idea/text authored by JinHyeock Choi and Erik Normark provided the idea/text
for the complete prefix list mechanism described in this document. for the complete prefix list mechanism described in this document.
The best current practice for hosts draft (draft-ietf-dna-hosts-03) The best current practice for hosts draft (draft-ietf-dna-hosts-03)
authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and
the tentative options (draft-ietf-dna-tentative-00) authored by Greg the tentative options (draft-ietf-dna-tentative-00) authored by Greg
Daley, Erik Normark and Nick Moore were also adopted into this Daley, Erik Normark and Nick Moore were also adopted into this
document. document.
15. Acknowledgments 9. Acknowledgments
The design presented in this document grew out of discussions among The design presented in this document grew out of discussions among
the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, the members of the DNA design team (JinHyeock Choi, Tero Kauppinen,
James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland).
The spirited debates on the design, and the advantages and dis- The spirited debates on the design, and the advantages and dis-
advantages of various DNA solutions helped the creation of this advantages of various DNA solutions helped the creation of this
document. document.
Thanks to Syam Madanapalli who co-authored Thanks to Syam Madanapalli who co-authored
draft-jinchoi-dna-protocol2 from which this draft draws ideas, as draft-jinchoi-dna-protocol2 from which this draft draws ideas, as
skipping to change at page 43, line 5 skipping to change at page 34, line 20
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.
16. References 10. Informative References
16.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, April 2006. IPv6", RFC 4429, April 2006.
16.2 Informative References [6] Krishnan, S. and SG. Daley, "Simple procedures for Detecting
Network Attachment in IPv6", draft-ietf-dna-simple-01 (work in
progress), July 2008.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address [8] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462 2462, December 1998. Autoconfiguration", RFC2462 2462, December 1998.
[8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, [9] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998. December 1998.
[9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [10] 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.
[10] Conta, A. and S. Deering, "Internet Control Message Protocol [11] 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.
[11] Christensen, M., Kimball, K., and F. Solensky, "Considerations [12] 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.
[12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [13] 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.
[13] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, [14] 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.
[14] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, [15] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005. July 2005.
[15] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control [16] 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.
[16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [17] 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.
[17] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [18] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [19] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment [20] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005. in IPv6", RFC 4135, August 2005.
[20] Yegin, A., "Link-layer Event Notifications for Detecting [21] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-00 (work Network Attachments", draft-ietf-dna-link-information-00 (work
in progress), September 2004. in progress), September 2004.
[21] 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.
[22] 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.
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
skipping to change at page 47, line 29 skipping to change at page 38, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Statement Disclaimer of Validity
Copyright (C) The IETF Trust (2008). 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.
This document is subject to the rights, licenses and restrictions Copyright Statement
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an Copyright (C) The IETF Trust (2008). This document is subject to the
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS rights, licenses and restrictions contained in BCP 78, and except as
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 62 change blocks. 
610 lines changed or deleted 137 lines changed or added

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