draft-ietf-dna-simple-14.txt   draft-ietf-dna-simple-15.txt 
Network Working Group S. Krishnan Network Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track G. Daley Intended status: Standards Track G. Daley
Expires: August 18, 2010 NetStar Networks Expires: February 10, 2011 NetStar Networks
February 14, 2010 August 9, 2010
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-14 draft-ietf-dna-simple-15
Abstract Abstract
Detecting Network Attachment allows hosts to assess if its existing Detecting Network Attachment allows hosts to assess if its existing
addressing or routing configuration is valid for a newly connected addressing or routing configuration is valid for a newly connected
network. This document provides simple procedures for detecting network. This document provides simple procedures for detecting
network attachment in IPv6 hosts, and procedures for routers to network attachment in IPv6 hosts, and procedures for routers to
support such services. support such services.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on February 10, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Link Identification model . . . . . . . . . . . . . . . . 4 2.3. Link Identification model . . . . . . . . . . . . . . . . 4
2.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6 4. The Simple DNA Address Table (SDAT) . . . . . . . . . . . . . 7
4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 5. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. SDAT Maintenance . . . . . . . . . . . . . . . . . . . 6 5.1. On receipt of a Router Advertisement . . . . . . . . . . . 7
4.2. Steps involved in detecting link change . . . . . . . . . 7 5.2. After assignment of a DHCPv6 address . . . . . . . . . . . 8
4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7 5.3. Steps involved in detecting link change . . . . . . . . . 8
4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7 5.4. Link-Layer Indication . . . . . . . . . . . . . . . . . . 8
4.5. Contents of the Neighbor Discovery messages . . . . . . . 9 5.5. Sending Neighbor Discovery probes . . . . . . . . . . . . 9
4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 9 5.5.1. Sending Router Solicitations . . . . . . . . . . . . . 9
4.5.2. Router Solicitation messages . . . . . . . . . . . . . 9 5.5.2. Sending Neighbor Solicitations . . . . . . . . . . . . 9
4.6. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 10 5.5.3. Concurrent sending of RS and NS probes . . . . . . . . 9
4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 10 5.5.4. Initiating DHCPv6 exchange . . . . . . . . . . . . . . 9
4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 11 5.6. Contents of the Neighbor Discovery messages . . . . . . . 11
4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11 5.6.1. Neighbor Solicitation messages . . . . . . . . . . . . 11
4.9. Recommended retransmission behavior . . . . . . . . . . . 12 5.6.2. Router Solicitation messages . . . . . . . . . . . . . 11
5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13 5.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 12
6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.7.1. Receiving Neighbor Advertisements . . . . . . . . . . 12
7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15 5.7.2. Receiving Router Advertisements . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5.7.3. Conflicting results . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.8. Further Host Operations . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 5.9. On connecting to a new point of attachment . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.10. Periodic Maintenance of the SDAT . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 5.11. Recommended retransmission behavior . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 15
Appendix A. Issues with confirming manually assigned addresses . 17 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Issues with confirming manually assigned addresses . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Hosts require procedures to simply and reliably identify if they have Hosts require procedures to simply and reliably identify if they have
skipping to change at page 4, line 41 skipping to change at page 4, line 41
routers, prefixes and configuration parameters was considered to be routers, prefixes and configuration parameters was considered to be
valid. The Simple DNA protocol follows an alternate approach where valid. The Simple DNA protocol follows an alternate approach where
it relies on probing each previously known router to determine it relies on probing each previously known router to determine
whether to use information learnt from THAT router. This allows whether to use information learnt from THAT router. This allows
simple DNA to probe routers learnt from multiple earlier attachments simple DNA to probe routers learnt from multiple earlier attachments
to optimize movement between a known set of links. to optimize movement between a known set of links.
2.4. DNA Overview 2.4. DNA Overview
Detecting Network Attachment is performed by hosts after detecting a Detecting Network Attachment is performed by hosts after detecting a
link-layer "up" indication. The host simultaneously sends multicast link-layer "up" indication. The host uses a combination of unicast
Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) Neighbor Solicitations (NSs), multicast Router Solicitations (RSs)
in order to determine whether previously encountered routers are and DHCPv6 message exchanges in order to determine whether previously
present on the link. encountered routers are present on the link, and if they are not,
acquire the new configuration information.
Hosts implementing simple DNA may also send DHCPv6 packets, as Hosts implementing simple DNA may also send DHCPv6 packets, as
described in Section 4.6. Since simple DNA does not modify the described in Section 5.5.4. Since simple DNA does not modify the
DHCPv6 protocol or state machine, the operation of DHCPv6 is DHCPv6 protocol or state machine, the operation of DHCPv6 is
unchanged. unchanged.
Routers that follow the standard neighbor discovery procedure Routers that follow the standard neighbor discovery procedure
described in [RFC4861] will delay the router advertisement by a described in [RFC4861] will delay the router advertisement by a
random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms)
as described in Section 6.2.6 of [RFC4861]. Hosts implementing as described in Section 6.2.6 of [RFC4861]. In addition, consecutive
simple DNA can detect the presence of a previously encountered router RAs sent to the all-nodes multicast address are rate limited to no
using unicast Neighbor Solicitations. As a result, where the host more than one advertisement every MIN_DELAY_BETWEEN_RAS (defined to
with a valid configuration is returning to a previously encountered be 3 seconds). This will result in a worst-case delay of 3.5 seconds
link, delays in the sending of a Router Advertisement (RA) will not in the absence of any packet loss.
delay configuration as long as NS probing is successful. However in
situations where the host is attaching to a link for the first time, Hosts implementing simple DNA can detect the presence of a previously
or where it does not have a valid IP address on the link, it will be encountered router using unicast Neighbor Solicitations. As a
dependent on the receipt of an RA for stateless auto-configuration. result, where the host with a valid configuration is returning to a
In these situations delays in the receipt of an RA can be significant previously encountered link, delays in the sending of a Router
and may result in service disruption. Advertisement (RA) will not delay configuration as long as NS probing
is successful. However in situations where the host is attaching to
a link for the first time, or where it does not have a valid IP
address on the link, it will be dependent on the receipt of an RA for
stateless auto-configuration. In these situations delays in the
receipt of an RA can be significant and may result in service
disruption.
2.5. Working Assumptions 2.5. Working Assumptions
There are a series of assumptions about the network environment which There are a series of assumptions about the network environment which
underpin these procedures. underpin these procedures.
o The combination of the link layer address and the link local IPv6 o The combination of the link layer address and the link local IPv6
address of a router is unique across links. address of a router is unique across links.
o Hosts receive indications when a link-layer comes up. Without o Hosts receive indications when a link-layer comes up. Without
skipping to change at page 5, line 45 skipping to change at page 6, line 15
3. Terminology 3. Terminology
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Term | Definition | | Term | Definition |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Valid IPv6 address | An IPv6 address configured on the node that | | Valid IPv6 address | An IPv6 address configured on the node that |
| | has a valid lifetime greater than zero. | | | has a valid lifetime greater than zero. |
| | | | | |
| Operable IPv6 | An IPv6 address configured on the node that | | Operable IPv6 | An IPv6 address configured on the node that |
| address | can be used safely on the current link. | | address | can be used safely on the current link. |
| | |
| Router identifier | Identifier formed using the link-local |
| | address of a router along with its |
| | link-layer address. |
| | |
| D-Flag | Flag indicating whether the address was |
| | obtained using SLAAC or DHCPv6. If it is |
| | set to 0, then SLAAC was used to configure |
| | the address. If it is set to 1, then DHCPv6 |
| | was used to configure the address. |
| | |
| O-Flag | Flag indicating whether the address is |
| | operable. If it is set to 0, the address is |
| | inoperable. If it is set to 1, the address |
| | is operable. |
| | |
| S-Flag | Flag indicating whether SEND [RFC3971] was |
| | used in the Router Advertisement that |
| | resulted in the creation/modification of |
| | this SDAT entry. If it is set to 0, then |
| | SEND was not used. If it is set to 1, then |
| | SEND was used. |
| | |
| Candidate Router | A router address in the SDAT that is |
| Address | associated with at least one valid address. |
| | |
| Candidate Router | A set of router addresses that has been |
| Set | identified for NS based probing. |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 1: Simple DNA Terminology Table 1: Simple DNA Terminology
4. Host Operations 4. The Simple DNA Address Table (SDAT)
On connecting to a new point of attachment, the host performs the
detecting network attachment procedure in order to determine whether
the existing addressing and configuration information are still
valid.
4.1. Host data structures
In order to correctly perform the procedure described in this In order to correctly perform the procedure described in this
document the host needs to maintain a data structure called the document the host needs to maintain a data structure called the
Simple DNA address table (SDAT). The host needs to maintain this Simple DNA address table (SDAT). The host needs to maintain this
data structure for each interface on which it performs Simple DNA. data structure for each interface on which it performs Simple DNA.
Each entry in the SDAT table consists of at least the following Each entry in the SDAT table will be indexed by the router identifier
parameters. (link-local + link layer address of the router) and consists of at
least the following parameters. Fields tagged as [S] are used for
addresses configured using SLAAC. Fields tagged as [D] are used for
addresses obtained using DHCPv6. Fields tagged as [S+D] are used in
both cases.
o IPv6 address and its related parameters like valid lifetime, o [S+D]Link-local IPv6 address of the router(s)
preferred lifetime etc.
o Prefix from which the address was formed. o [S+D]Link-layer (MAC) address of the router(s)
o Link-local IPv6 address(es) of the router(s) that advertised the o [S+D]Flag indicating whether the address was obtained using SLAAC
prefix. or DHCPv6.(The D-Flag)
o Link-layer (MAC) address(es) of the router(s) that advertised the o [S+D]IPv6 address and its related parameters like valid lifetime,
prefix. preferred lifetime etc.
o Flag indicating whether the address was obtained using SLAAC or o [S]Prefix from which the address was formed.
DHCPv6.
o DHCP specific information in case DHCPv6 [RFC3315] was used to o [S]Flag indicating whether SEND was used.(The S-Flag)
o [D]DHCP specific information in case DHCPv6 [RFC3315] was used to
acquire the address. This information includes DUID, IA_ID, a acquire the address. This information includes DUID, IA_ID, a
flag indicating IA_NA/IA_TA, configuration information such as DNS flag indicating IA_NA/IA_TA, configuration information such as DNS
server address, NTP server address etc. server address, NTP server address etc.
4.1.1. SDAT Maintenance o [S+D]Flag indicating whether the address is operable.(The O-Flag)
The host SHOULD maintain the SDAT table by periodically cleaning out 5. Host Operations
entries whose valid lifetimes have expired. The host MAY also
maintain the table by allowing SDAT entries from "n" previously
visited links. When the host attaches to a previously unknown link
and the SDAT already contains entries from the previous "n" attached
links,it will discard all the SDAT entries corrsponding to the least
recently attached link.
4.2. Steps involved in detecting link change On connecting to a new point of attachment, the host performs the
detecting network attachment procedure in order to determine whether
the existing addressing and configuration information are still
valid.
5.1. On receipt of a Router Advertisement
When the host receives a Router Advertisement and the router
identifier of the sending router is not present in the SDAT, the host
processes the Router Advertisement as specified in Section 6.3.4. of
[RFC4861]. Additionally, the host performs the following operations.
If the Router Advertisement is protected by SEND the S-Flag MUST be
set to 1 in the SDAT entries created/modified by this RA.
o The host configures addresses out of the autoconfigurable prefixes
advertised in the RA, as specified in [RFC4862]. The host MUST
add an SDAT entry (indexed by this router identifier) for each
such address the host configures.
o The host might have already configured addresses out of the
autoconfigurable prefixes advertised in the RA. This could be a
result of receiving the prefix in an RA from another router on the
same link. The host MUST add an SDAT entry (indexed by this
router identifier) for each such address the host had already
configured.
o The host might have DHCPv6 assigned addresses that are known to be
operable on the link. The host MUST add an SDAT entry (indexed by
this router identifier) for each such DHCPv6 address.
5.2. After assignment of a DHCPv6 address
After the host is assigned an address by a DHCPv6 server, it needs to
associate the address with the routers on link. The host MUST create
one SDAT entry for each of the on-link routers associated with the
DHCPv6 assigned address.
5.3. Steps involved in detecting link change
The steps involved in basic detection of network attachment are: The steps involved in basic detection of network attachment are:
o Link-Layer Indication o Link-Layer Indication
o Sending of neighbor discovery and/or DHCPv6 probes o Sending of neighbor discovery and/or DHCPv6 probes
o Response gathering and assessment o Response gathering and assessment
These steps are described below. These steps are described below.
4.3. Link-Layer Indication 5.4. Link-Layer Indication
In order to start Detection of network attachment procedures, a host In order to start Detection of network attachment procedures, a host
typically requires a link-layer indication that the medium has become typically requires a link-layer indication that the medium has become
available [RFC4957]. available [RFC4957].
After the indication is received, the host considers all currently After the indication is received, the host MUST mark all currently
configured (non-tentative) IP addresses to be deprecated until the configured (non-tentative) IP addresses as inoperable until the
change detection process completes. It MUST also set all Neighbor change detection process completes. It MUST also set all Neighbor
Cache entries for the routers on its Default Router List to STALE. Cache entries for the routers on its Default Router List to STALE.
This is done to speed up the acquisition of a new default router when
link change has occurred.
4.4. Sending Neighbor Discovery probes This is done to speed up the acquisition of a new default router in
case the host attaches to a previously unvisited link.
5.5. Sending Neighbor Discovery probes
5.5.1. Sending Router Solicitations
When a host receives a link-layer "up" indication, it SHOULD When a host receives a link-layer "up" indication, it SHOULD
immediately send both a Router Solicitation (as specified in as immediately send a Router Solicitation (as specified in as specified
specified in section 6.3.7 of [RFC4861]) and if it retains at least in section 6.3.7 of [RFC4861]). The Router Solicitation is sent to
one valid IPv6 address, one or more unicast Neighbor Solicitations. the All-routers multicast address using a link-local address as the
The Router Solicitation is sent to the All-routers multicast address source address [RFC4861]. Even if the host is in possession of more
using a link-local address as the source address [RFC4861]. Even if than one valid IPv6 address, it MUST send only one router
the host is in possession of more than one valid IPv6 address, it solicitation using a valid link-local address as the source address.
MUST send only one router solicitation using a valid link-local
address as the source address.
For each of the addresses in the SDAT, the host looks up the SDAT to 5.5.2. Sending Neighbor Solicitations
find out the link-local and MAC addresses of the router(s) that
advertised the prefix used to form the address. It then sends an
unicast Neighbor Solicitations to each router's link-local address it
obtained from the lookup on the SDAT. The host MUST NOT send unicast
Neighbor Solicitations to a test node corresponding to an IPv6
address that is no longer valid.
Please note that the Neighbor Solicitations SHOULD be sent in The host iterates through the SDAT to identify a set of candidate
parallel with the Router Solicitation. Since sending NSs is just an routers for NS based probing. Each router in the SDAT that is
optimization, doing the NSs and the RS in parallel ensures that the associated with at least one valid address is added to the candidate
procedure does not run slower than it would if it only used an RS. router set exactly once. For each router in the candidate router set
the host MUST send an unicast Neighbor Solicitation to the router's
link-local address it obtained from the lookup on the SDAT. The host
MUST set link-layer destination address in each of these neighbor
solicitations to the link-layer address of the router stored in the
SDAT. The host MUST NOT send unicast Neighbor Solicitations to a
router that is not associated to a valid address in the SDAT. If at
least one entry in the SDAT for a given router had the S-Flag set,
the host SHOULD use SEND to secure the NS probe being sent to the
router.
NOTE: A Simple DNA implementation SHOULD limit its probing to at most 5.5.3. Concurrent sending of RS and NS probes
six previously seen routers
4.5. Contents of the Neighbor Discovery messages The host SHOULD send the Neighbor Solicitation based unicast probes
in parallel with the multicast Router Solicitation. Since sending
NSs is just an optimization, doing the NSs and the RS in parallel
ensures that the procedure does not run slower than it would if it
only used an Router Solicitation.
4.5.1. Neighbor Solicitation messages NOTE: A Simple DNA implementation SHOULD limit its NS based probing
to at most six previously seen routers
5.5.4. Initiating DHCPv6 exchange
On receiving a link-layer "up" indication, the host will initiate a
DHCPv6 exchange when and as specified in [RFC3315] in order to verify
whether the addresses and configuration obtained using DHCPv6 are
still usable on the link. Note that DHCPv6, as specified today, only
attempts to confirm addresses obtained on the most recently attached
link.
5.6. Contents of the Neighbor Discovery messages
5.6.1. Neighbor Solicitation messages
This section describes the contents of the neighbor solicitation This section describes the contents of the neighbor solicitation
probe messages sent during the probing procedure. probe messages sent during the probing procedure.
Source Address: A link-local address assigned to the Source Address: A link-local address assigned to the
probing host. probing host.
Destination Address: The link-local address of the router being Destination Address: The link-local address of the router being
probed as learnt from the SDAT. probed as learned from the SDAT.
Hop Limit: 255 Hop Limit: 255
ND Options: ND Options:
Target Address: The link-local address of the router being Target Address: The link-local address of the router being
probed as learnt from the SDAT. probed as learnt from the SDAT.
Link Layer Header: Link Layer Header:
Destination Address: The link-layer (MAC) address of the router Destination Address: The link-layer (MAC) address of the router
being probed as learnt from the SDAT. being probed as learnt from the SDAT.
The probing node SHOULD include the Source link-layer address option The probing node SHOULD include the Source link-layer address option
in the probe messages. in the probe messages.
4.5.2. Router Solicitation messages 5.6.2. Router Solicitation messages
This section describes the contents of the router solicitation probe This section describes the contents of the router solicitation probe
message sent during the probing procedure. message sent during the probing procedure.
Source Address: A link-local address assigned to the Source Address: A link-local address assigned to the
probing host. probing host.
Destination Address: The all-routers multicast address. Destination Address: The all-routers multicast address.
Hop Limit: 255 Hop Limit: 255
The probing node SHOULD NOT include the Source link-layer address The probing node SHOULD NOT include the Source link-layer address
option in the probe messages. option in the probe messages.
4.6. DHCPv6 operation 5.7. Response Gathering
Simple DNA does not require a host to implement DHCPv6, nor does it
imply any changes to the DHCPv6 protocol or state machine. Hosts MAY
attempt to obtain IPv6 configuration via DHCPv6 in parallel with
simple DNA probing. This ensures that the simple DNA procedure will
not result in additional delay in the case where reachability tests
fail, or where a DHCPv6 exchange completes more quickly than the
reachability tests.
In situations where both simple DNA and DHCPv6 are used on the same 5.7.1. Receiving Neighbor Advertisements
link, it is possible that simple DNA probing will complete
successfully, and then DHCPv6 will complete later with a different
result. If this happens, the procedure described in Section 4.7.1
are utilized.
The host attempts to verify its DHCPv6-obtained information in When a Neighbor Advertisement is received from a router in response
parallel with simple DNA. On receiving a link-layer "up" indication, to a NS probe, the host MUST verify that both the IPv6 and link layer
it will initiate a DHCPv6 exchange when and as specified in [RFC3315] (MAC) addresses of the router match the expected values before
in order to verify whether the addresses and configuration obtained utilizing the configuration associated with the detected network
using DHCPv6 are still usable on the link. (prefixes, MTU etc.). The host MUST then go through the SDAT and
mark the addresses associated with the router as operable.
4.7. Response Gathering 5.7.2. Receiving Router Advertisements
When a responding Neighbor Advertisement is received from a test On reception of a Router Advertisement the host MUST go through the
node, the host MUST verify that both the IPv6 and link layer (MAC) SDAT and mark all the addresses associated with the router as
addresses of the test node match the expected values before utilizing inoperable. The host MUST then process the Router Advertisement as
the configuration associated with the detected network (prefixes, MTU specified in Section 6.3.4. of [RFC4861].
etc.).
On reception of a Router Advertisement that contains prefixes that 5.7.3. Conflicting results
intersect with those previously advertised by a known router, the
host utilizes the addresses in the SDAT associated with the detected
network.
If the host receives a router advertisement from a router containing 5.7.3.1. Conflicting results between RS and NS probes
only prefixes that are disjoint from the prefixes associated with the
same router in the SDAT, then the host MUST conclude that the IPv6
addresses corresponding to that router are no longer valid. Since
any NS probes to that router will no longer provide useful
information, further probing of that router MUST be aborted.
Furthermore, the host MUST remove all the SDAT entries corresponding
to this router.
Where the conclusions obtained from the Neighbor Solicitation/ Where the conclusions obtained from the Neighbor Solicitation/
Advertisement from a given router and the RS/RA exchange with the Advertisement from a given router and the RS/RA exchange with the
same router differ, the results obtained from the RS/RA will be same router differ, the results obtained from the RS/RA will be
considered definitive. In case the Neighbor Advertisement was considered definitive. In case the Neighbor Advertisement was
secured using SEND and the Router Advertisement was not, the host secured using SEND and the Router Advertisement was not, the host
MUST wait for SEND_NA_GRACE_TIME to see if a SEND-secured RA is MUST wait for SEND_NA_GRACE_TIME to see if a SEND-secured RA is
received. If a SEND-secured RA is not received, the conclusions received. If a SEND-secured RA is not received, the conclusions
obtained from the NS/NA exchange will be considered definitive. obtained from the NS/NA exchange will be considered definitive.
When the host receives a Router Advertisement from a given router, 5.7.3.2. Conflicting results between DHCPv6 and NS probes
the host MUST look for a Neighbor Cache entry for the sending router
and MUST mark that router's Neighbor Cache Entry as REACHABLE if one
was found. The host MUST add a new Neighbor Cache Entry in the
REACHABLE state for the sending router if one does not currently
exist.
4.7.1. Conflicting results
In situations where Neighbor Solicitation probes and Router Where the conclusions obtained from the Neighbor Solicitation/
Solicitation probes are used on the same link, it is possible that Advertisement for a given DHCPv6-assigned address and the conclusions
the NS probe will complete successfully, and then the RS probe will obtained from the DHCPv6 exchange differ, the results obtained from
complete later with a different result. If this happens, the the DHCPv6 exchange will be considered definitive.
implementation SHOULD abandon the results obtained from the NS probe
of the router that responded to the RS and the implementation SHOULD
behave as if the NS probe did not successfully complete.
4.8. Further Host Operations 5.8. Further Host Operations
Operations subsequent to detecting network attachment depend upon Operations subsequent to detecting network attachment depend upon
whether or not the host has reconnected to a previously visited whether or not the host has reconnected to a previously visited
network. network.
After confirming the reachability of the associated router using an After confirming the reachability of the associated router using an
NS/NA pair, the host performs the following steps. NS/NA pair, the host performs the following steps.
o The host SHOULD rejoin any solicited nodes' multicast groups for o The host SHOULD rejoin any solicited nodes' multicast groups for
addresses it continues to use. addresses it continues to use.
skipping to change at page 12, line 5 skipping to change at page 13, line 21
If the host has determined that it has reattached to a previously If the host has determined that it has reattached to a previously
visited link, it SHOULD NOT perform duplicate address detection on visited link, it SHOULD NOT perform duplicate address detection on
the addresses that have been confirmed to be operable. the addresses that have been confirmed to be operable.
If the NS based probe with a router did not complete or if the RS If the NS based probe with a router did not complete or if the RS
based probe on the same router completed with different prefixes than based probe on the same router completed with different prefixes than
the ones in the SDAT the host MUST begin address configuration the ones in the SDAT the host MUST begin address configuration
techniques, as indicated in a received Router Advertisement techniques, as indicated in a received Router Advertisement
[RFC4861][RFC4862]. [RFC4861][RFC4862].
4.9. Recommended retransmission behavior 5.9. On connecting to a new point of attachment
A host usually maintains SDAT entries from some number of previously
visited networks. When the host attaches to a previously unknown
network it MAY need to discard some older SDAT entries.
5.10. Periodic Maintenance of the SDAT
The host SHOULD maintain the SDAT table by removing entries when the
valid lifetime for the prefix and address expires, that is, at the
same as as the prefix is removed from the Prefix List in [RFC4861].
The host SHOULD also remove a router from a SDAT entry when that
router stops advertising a particular prefix. When three consequtive
RAs from a particular router have not included a prefix, then the
router should be removed from the corresponding SDAT entry.
Likewise, if a router starts advertising a prefix for which there
already exists a SDAT entry then that router should be added to the
SDAT entry.
5.11. Recommended retransmission behavior
Where the NS probe does not complete successfully, it usually implies Where the NS probe does not complete successfully, it usually implies
that the host is not attached to the network whose configuration is that the host is not attached to the network whose configuration is
being tested. In such circumstances, there is typically little value being tested. In such circumstances, there is typically little value
in aggressively retransmitting unicast neighbor solicitations that do in aggressively retransmitting unicast neighbor solicitations that do
not elicit a response. not elicit a response.
Where unicast Neighbor Solicitations and Router Solicitations are Where unicast Neighbor Solicitations and Router Solicitations are
sent in parallel, one strategy is to forsake retransmission of sent in parallel, one strategy is to forsake retransmission of
Neighbor Solicitations and to allow retransmission only of Router Neighbor Solicitations and to allow retransmission only of Router
skipping to change at page 13, line 5 skipping to change at page 15, line 5
[RFC3315], scheduling DNAv6 retransmissions between Router [RFC3315], scheduling DNAv6 retransmissions between Router
Solicitations or DHCPv6 retransmissions. Solicitations or DHCPv6 retransmissions.
If a response is received to any unicast Neighbor Solicitation or If a response is received to any unicast Neighbor Solicitation or
Router Solicitation message, pending retransmissions MUST be Router Solicitation message, pending retransmissions MUST be
canceled. A Simple DNA implementation SHOULD NOT retransmit a canceled. A Simple DNA implementation SHOULD NOT retransmit a
Neighbor Solicitation more than twice. To provide damping in the Neighbor Solicitation more than twice. To provide damping in the
case of spurious Link Up indications, the host SHOULD NOT perform the case of spurious Link Up indications, the host SHOULD NOT perform the
Simple DNA procedure more than once a second. Simple DNA procedure more than once a second.
5. Pseudocode for Simple DNA 6. Pseudocode for Simple DNA
/* Link up indication received on INTERFACE */ /* Link up indication received on INTERFACE */
/* Start Simple DNA process */ /* Start Simple DNA process */
/* Mark All Addresses as deprecated */ /* Mark All Addresses as inoperable */
Configured_Address_List=Get_Address_List(INTERFACE); Configured_Address_List=Get_Address_List(INTERFACE);
foreach Configured_Address in Configured_Address_List foreach Configured_Address in Configured_Address_List
{ {
if (Get_Address_State(Configured_Address)!=AS_TENTATIVE) if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
{ {
Set_Address_State(Configured_Address,AS_DEPRECATED); Set_Address_State(Configured_Address,AS_INOPERABLE);
} }
} }
/* Mark all routers' NC entries as STALE to speed up */ /* Mark all routers' NC entries as STALE to speed up */
/* acquisition of new router if link change has occurred */ /* acquisition of new router if link change has occurred */
foreach Router_Address in DEFAULT_ROUTER_LIST foreach Router_Address in DEFAULT_ROUTER_LIST
{ {
NCEntry=Get_Neighbor_Cache_Entry(Router_Address); NCEntry=Get_Neighbor_Cache_Entry(Router_Address);
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE); Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE);
} }
/* Thread A : Send Router Solicitation */ /* Thread A : Send Router Solicitation */
RS_Target_Address=FF02::2; RS_Target_Address=FF02::2;
RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
Send_Router_Solicitation(RS_Source_Address,RS_Target_Address); Send_Router_Solicitation(RS_Source_Address,RS_Target_Address);
/* Thread B : Send Neighbor Solicitation(s) */ /* Thread B : Send Neighbor Solicitation(s) */
Previously_Known_Router_List=Get_Router_List_from_SDAT(); Previously_Known_Router_List=Get_Router_List_from_SDAT();
NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE); NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
foreach Router_Address in Previously_Known_Router_List foreach Router_Address in Previously_Known_Router_List
{ {
if (Get_Any_Valid_Address_from_SDAT(Router_Address)) if (Get_Any_Valid_Address_from_SDAT(Router_Address))
{ {
Send_Neighbor_Solicitation(NS_Source_Address,Router_Address); Send_Neighbor_Solicitation(NS_Source_Address,Router_Address.L3_Address,
} Router_Address.L2_Address);
} }
}
/* Thread C : Response collection */ /* Thread C : Response collection of RAs */
/* Received Router Advertisement processing */ /* Received Router Advertisement processing */
/* Only for RAs received as response to DNA RSs */ /* Only for RAs received from routers in the SDAT */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE); L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE); L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
foreach SDAT_Entry in SDAT_Entry_List
{
if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry)))
{
/* Address is operable. Configure on Interface */
/* Rejoin solicited-node multicast group for address */
}
else
{
/* If address is configured on interface, remove it */
/* This could be because of a NA arriving before RA */
}
}
/* Mark router as reachable */ /* Mark all the addresses associated with the router as inoperable */
NCEntry=Get_Neighbor_Cache_Entry(L3_Source); foreach SDAT_Entry in SDAT_Entry_List
if (NCEntry is not NULL) {
{ Set_Address_State(SDAT_Entry,AS_INOPERABLE);
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE); }
}
else
{
Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE);
}
/* Ignore further NAs from this router */ /* Ignore further NAs from this router */
Add_Router_to_NA_Ignore_List(L3_Source); /* after delaying for x milliseconds */
Add_Router_to_NA_Ignore_List(L3_Source,SEND_NA_GRACE_PERIOD);
/* Received Neighbor Advertisement processing */ /* Perform Standard RA processing as per RFC4861/RFC4862 */
/* Only for NAs received as response to DNA NSs */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE); /* Thread D : Response collection of NAs */
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
if (Is_Router_on_NA_Ignore_List(L3_Source)) { /* Received Neighbor Advertisement processing */
/* Ignore message and wait for next message */ /* Only for NAs received as response to DNA NSs */
continue;
}
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
foreach SDAT_Entry in SDAT_Entry_List if (Is_Router_on_NA_Ignore_List(L3_Source)) {
{ /* Ignore message and wait for next message */
/* Address is operable. Configure on Interface */ continue;
} }
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
foreach SDAT_Entry in SDAT_Entry_List
{
/* Address is operable. */
Set_Address_State(SDAT_Entry,AS_OPERABLE);
/* Configure on Interface */
}
Figure 1: Pseudocode for Simple DNA Figure 1: Pseudocode for Simple DNA
NOTE: This section does not include any pseudo-code for sending of NOTE: This section does not include any pseudo-code for sending of
the DHCPv6 packets since the DHCPv6 exchange is orthogonal to the the DHCPv6 packets since the DHCPv6 exchange is orthogonal to the
simple DNA process. simple DNA process.
6. Constants 7. Constants
SEND_NA_GRACE_TIME SEND_NA_GRACE_TIME
Definition: An optional period to wait after Neighbor Definition: An optional period to wait after Neighbor
Solicitation before adopting a non-SEND RA's link change Solicitation before adopting a non-SEND RA's link change
information. information.
Value: 40 milliseconds Value: 40 milliseconds
7. Relationship to DNAv4 8. Relationship to DNAv4
DNAv4 [RFC4436] specifies a set of steps that optimize the (common) DNAv4 [RFC4436] specifies a set of steps that optimize the (common)
case of re-attachment to an IPv4 network that one has been connected case of re-attachment to an IPv4 network that one has been connected
to previously by attempting to re-use a previous (but still valid) to previously by attempting to re-use a previous (but still valid)
configuration. This document shares the same goal as DNAv4 (that of configuration. This document shares the same goal as DNAv4 (that of
minimizing the handover latency in moving between points of minimizing the handover latency in moving between points of
attachment) but differs in the steps it performs to achieve this attachment) but differs in the steps it performs to achieve this
goal. Another difference is that this document also supports goal. Another difference is that this document also supports
stateless autoconfiguration of addresses in addition to addresses stateless autoconfiguration of addresses in addition to addresses
configured using DHCPv6. configured using DHCPv6.
8. IANA Considerations 9. IANA Considerations
There are no changes to IANA registries required in this document. There are no changes to IANA registries required in this document.
9. Security Considerations 10. Security Considerations
A host may receive Router Advertisements from non-SEND devices, after A host may receive Router Advertisements from non-SEND devices, after
receiving a link-layer indications. While it is necessary to assess receiving a link-layer indications. While it is necessary to assess
quickly whether a host has moved to another network, it is important quickly whether a host has moved to another network, it is important
that the host's current secured SEND [RFC3971] router information is that the host's current secured SEND [RFC3971] router information is
not replaced by an attacker which spoofs an RA and purports to change not replaced by an attacker which spoofs an RA and purports to change
the link. the link.
As such, the host SHOULD send a Neighbor Solicitation to the existing As such, the host SHOULD send a Neighbor Solicitation to the existing
SEND router upon link-up indication as described above in SEND router upon link-up indication as described above in
Section 4.3. The host SHOULD then ensure that unsecured router Section 5.4. The host SHOULD then ensure that unsecured router
information does not cause deletion of existing SEND state, within information does not cause deletion of existing SEND state, within
MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to
respond. respond.
If the current default router is a SEND-secured router, the host If the current default router is a SEND-secured router, the host
SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a
new default router. new default router.
Even if SEND signatures on RAs are used, it may not be immediately Even if SEND signatures on RAs are used, it may not be immediately
clear if the router is authorized to make such advertisements. As clear if the router is authorized to make such advertisements. As
skipping to change at page 16, line 26 skipping to change at page 18, line 19
the DNA procedure does not in itself provide positive, secure the DNA procedure does not in itself provide positive, secure
authentication of the router(s) on the network, or authentication of authentication of the router(s) on the network, or authentication of
the network itself, as e.g. would be provided by mutual the network itself, as e.g. would be provided by mutual
authentication at the link layer. Therefore when such assurance is authentication at the link layer. Therefore when such assurance is
not available, the host MUST NOT make any security-sensitive not available, the host MUST NOT make any security-sensitive
decisions based on the DNA procedure alone. In particular, it MUST decisions based on the DNA procedure alone. In particular, it MUST
NOT decide that it has moved from an untrusted to a trusted network, NOT decide that it has moved from an untrusted to a trusted network,
and MUST NOT make any security decisions that depend on the and MUST NOT make any security decisions that depend on the
determination that such a transition has occurred. determination that such a transition has occurred.
10. Acknowledgments 11. Acknowledgments
This document is the product of a discussion the authors had with This document is the product of a discussion the authors had with
Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF
69. The authors would like to thank them for clearly detailing the 69. The authors would like to thank them for clearly detailing the
requirements of the solution and the goals it needed to meet and for requirements of the solution and the goals it needed to meet and for
helping to explore the solution space. The authors would like to helping to explore the solution space. The authors would like to
thank the authors and editors of the complete DNA specification for thank the authors and editors of the complete DNA specification for
detailing the overall problem space and solutions. The authors would detailing the overall problem space and solutions. The authors would
like to thank Jari Arkko for driving the evolution of a simple and like to thank Jari Arkko for driving the evolution of a simple and
probabilistic DNA solution. The authors would like to thank Bernard probabilistic DNA solution. The authors would like to thank Bernard
Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier, Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier,
Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes, Frederic Rossi, Ralph Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes, Frederic Rossi, Ralph
Droms, Ted Lemon, Erik Nordmark, Lars Eggert, Brian Carpenter and Droms, Ted Lemon, Erik Nordmark, Lars Eggert, Brian Carpenter and
Yaron Sheffer for performing reviews on the document and providing Yaron Sheffer for performing reviews on the document and providing
valuable comments to drive the document forward. valuable comments to drive the document forward.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
11.2. Informative References 12.2. Informative References
[I-D.ietf-dna-protocol] [I-D.ietf-dna-protocol]
Narayanan, S., "Detecting Network Attachment in IPv6 Narayanan, S., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol (work in Networks (DNAv6)", draft-ietf-dna-protocol (work in
progress), June 2007. progress), June 2007.
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
and A. Yegin, "Link-Layer Event Notifications for and A. Yegin, "Link-Layer Event Notifications for
Detecting Network Attachments", RFC 4957, August 2007. Detecting Network Attachments", RFC 4957, August 2007.
skipping to change at page 18, line 20 skipping to change at page 20, line 11
also engage in a DHCPv6 exchange. In a situation where the host also engage in a DHCPv6 exchange. In a situation where the host
moves to NET1 and the NS probes are lost and in addition an RA is moves to NET1 and the NS probes are lost and in addition an RA is
not received, the host will not be able to confirm that it not received, the host will not be able to confirm that it
attached to NET1, and therefore that it should use the manual attached to NET1, and therefore that it should use the manual
configuration for that network. As a result, if DHCPv6 is enabled configuration for that network. As a result, if DHCPv6 is enabled
on NET1, then the host could mistakenly obtain a dynamic address on NET1, then the host could mistakenly obtain a dynamic address
and configuration instead of using the manual configuration. To and configuration instead of using the manual configuration. To
prevent this problem, simple DNA probing needs to continue even prevent this problem, simple DNA probing needs to continue even
after the DHCPv6 exchange has completed, and DNA probes need to after the DHCPv6 exchange has completed, and DNA probes need to
take precedence over DHCPv6, contrary to the advice provided in take precedence over DHCPv6, contrary to the advice provided in
Section 4.7.1 Section 5.7.3
Given these issues, it is NOT RECOMMENDED to use manual addressing Given these issues, it is NOT RECOMMENDED to use manual addressing
with Simple DNA. with Simple DNA.
Authors' Addresses Authors' Addresses
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
 End of changes. 72 change blocks. 
259 lines changed or deleted 322 lines changed or added

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