draft-ietf-dhc-dna-ipv4-18.txt   rfc4436.txt 
DHC Working Group Bernard Aboba Network Working Group B. Aboba
INTERNET-DRAFT Microsoft Corporation Request for Comments: 4436 Microsoft Corporation
Category: Proposed Standard James Carlson Category: Standards Track J. Carlson
<draft-ietf-dhc-dna-ipv4-18.txt> Sun Microsystems Sun Microsystems
1 December 2005 Stuart Cheshire S. Cheshire
Apple Computer Apple Computer
March 2006
Detecting Network Attachment in IPv4 (DNAv4) Detecting Network Attachment in IPv4 (DNAv4)
By submitting this Internet-Draft, each author represents that any Status of This Memo
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 10, 2006. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. Copyright (C) The Internet Society (2006).
Abstract Abstract
The time required to detect movement between networks, and to obtain The time required to detect movement between networks and to obtain
(or continue to use) an IPv4 configuration may be significant as a (or to continue to use) an IPv4 configuration may be significant as a
fraction of the total handover latency in moving between points of fraction of the total handover latency in moving between points of
attachment. This document synthesizes from experience in the attachment. This document synthesizes, from experience in the
deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local
addresses a set of steps known as Detecting Network Attachment for addresses, a set of steps known as Detecting Network Attachment for
IPv4 (DNAv4), in order to decrease the handover latency in moving IPv4 (DNAv4), in order to decrease the handover latency in moving
between points of attachment. between points of attachment.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction ....................................................2
1.1 Applicability ................................... 3 1.1. Applicability ..............................................2
1.2 Requirements .................................... 5 1.2. Requirements ...............................................5
1.3 Terminology ..................................... 5 1.3. Terminology ................................................5
2. Overview ................................................. 7 2. Overview ........................................................6
2.1 Reachability Test ............................... 8 2.1. Reachability Test ..........................................8
2.2 IPv4 Address Acquisition ........................ 10 2.1.1. Packet Format .......................................9
2.3 IPv4 Link-Local Addresses ....................... 11 2.2. IPv4 Address Acquisition ..................................10
2.4 Manually Assigned Addresses ..................... 12 2.3. IPv4 Link-Local Addresses .................................11
3. IANA Considerations ...................................... 13 2.4. Manually Assigned Addresses ...............................12
4. Security Considerations .................................. 13 3. Security Considerations ........................................12
5. References ............................................... 13 4. References .....................................................13
5.1 Normative references ............................ 13 4.1. Normative References ......................................13
5.2 Informative references .......................... 14 4.2. Informative References ....................................13
Acknowledgments .............................................. 14 5. Acknowledgements ...............................................14
Authors' Addresses ........................................... 14
Intellectual Property Statement .............................. 15
Disclaimer of Validity ....................................... 15
Copyright Statement .......................................... 16
1. Introduction 1. Introduction
The time required to detect movement between networks and to obtain The time required to detect movement between networks and to obtain
(or continue to use) an operable IPv4 configuration may be (or to continue to use) an operable IPv4 configuration may be
significant as a fraction of the total handover latency in moving significant as a fraction of the total handover latency in moving
between points of attachment. between points of attachment.
This document synthesizes from experience in the deployment of hosts This document synthesizes, from experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [RFC3927] a set of steps known as Detecting Network addresses [RFC3927], a set of steps known as Detecting Network
Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of
re-attachment to a network that one has been connected to previously re-attachment to a network that one has been connected to previously
by attempting to re-use a previous (but still valid) configuration, by attempting to re-use a previous (but still valid) configuration,
reducing the re-attachment time to a few milliseconds on LANs. Since reducing the re-attachment time on LANs to a few milliseconds. Since
this procedure is dependent on the ARP protocol, it is not suitable this procedure is dependent on the ARP protocol, it is not suitable
for use on media that do not support ARP. for use on media that do not support ARP.
1.1. Applicability 1.1. Applicability
DHCP is an effective and widely adopted mechanism for a host to DHCP is an effective and widely adopted mechanism for a host to
obtain an IP address for use on a particular network link, or to re- obtain an IP address for use on a particular network link, or to
validate a previously obtained address via DHCP's INIT-REBOOT re-validate a previously obtained address via DHCP's INIT-REBOOT
mechanism [RFC2131]. mechanism [RFC2131].
When obtaining a new address, DHCP specifies that the client SHOULD When obtaining a new address, DHCP specifies that the client SHOULD
use ARP to verify that the offered address is not already in use. use ARP to verify that the offered address is not already in use.
The process of address conflict detection [ACD] can take as much as The process of address conflict detection [ACD] can take as much as
seven seconds. In principle this time interval could be shortened, seven seconds. In principle, this time interval could be shortened,
with the obvious trade-off: the less time a host spends waiting to with the obvious trade-off: the less time a host spends waiting to
see if another host is already using its intended address, the see if another host is already using its intended address, the
greater the risk of inadvertent address conflicts. greater the risk of inadvertent address conflicts.
Where the client successfully re-validates a previously obtained Where the client successfully re-validates a previously obtained
address using the INIT-REBOOT mechanism, the DHCP specification does address using the INIT-REBOOT mechanism, the DHCP specification does
not require the client to perform address conflict detection, so this not require the client to perform address conflict detection, so this
seven-second delay does not apply. However, the DHCP server may be seven-second delay does not apply. However, the DHCP server may be
slow to respond, or may be down and not responding at all, so hosts slow to respond or may be down and not responding at all, so hosts
could benefit from having an alternative way to quickly determine could benefit from having an alternative way to quickly determine
that a previously obtained address is valid for use on this that a previously obtained address is valid for use on this
particular link. particular link.
When the client moves between networks, the address re-validation When the client moves between networks, the address re-validation
attempt may be unsuccessful; a DHCPNAK may be received in response attempt may be unsuccessful; a DHCPNAK may be received in response to
to a DHCPREQUEST, causing the client to restart the configuration a DHCPREQUEST, causing the client to restart the configuration
process by moving to the INIT state. If an address previously process by moving to the INIT state. If an address previously
obtained on the new network is still operable, DNAv4 enables the host obtained on the new network is still operable, DNAv4 enables the host
to quickly confirm the new configuration, bypassing restart of the to confirm the new configuration quickly, bypassing restart of the
configuration process as well as conflict detection. configuration process and conflict detection.
The alternative mechanism specified by this document applies when a The alternative mechanism specified by this document applies when a
host has a previously-allocated DHCP address, which was not returned host has a previously allocated DHCP address, which was not returned
to the DHCP server via a DHCPRELEASE message, and which still has to the DHCP server via a DHCPRELEASE message, and which still has
time remaining on its lease. In this case, the host may determine time remaining on its lease. In this case, the host may determine
whether it has re-attached to the logical link where this address is whether it has re-attached to the logical link where this address is
valid for use, by sending a unicast ARP Request packet to a router valid for use, by sending a unicast ARP Request packet to a router
previously known for that link (or in the case of a link with more previously known for that link (or, in the case of a link with more
than one router, by sending one or more unicast ARP Request packets than one router, by sending one or more unicast ARP Request packets
to one or more of those routers). to one or more of those routers).
The use of unicast ARP has a number of benefits. One benefit is that The use of unicast ARP has a number of benefits. One benefit is that
unicast packets impose less burden on the network than broadcast unicast packets impose less burden on the network than broadcast
packets, particularly on 802.11 networks where broadcast packets may packets, particularly on 802.11 networks where broadcast packets may
be sent at rates as low as 1 Mb/sec. Another benefit is that if the be sent at rates as low as 1 Mb/sec. Another benefit is that if the
host is not on the link it hoped to find itself on, a broadcast ARP host is not on the link it hoped to find itself on, a broadcast ARP
Request could pollute the ARP caches of peers on that link. When Request could pollute the ARP caches of peers on that link. When
using private addresses [RFC1918] another device could be using private addresses [RFC1918], another device could be
legitimately using the same address, and a broadcast ARP Request legitimately using the same address, and a broadcast ARP Request
could disrupt its communications, causing TCP connections to be could disrupt its communications, causing TCP connections to be
broken, and similar problems. By using a unicast ARP packet instead, broken, and similar problems. Also, using a unicast ARP packet
addressed to the MAC address of the router the host is expecting to addressed to the MAC address of the router the host is expecting to
find, if the host is not on the expected link, then there will be no find means that if the host is not on the expected link there will be
device with that MAC address, and the ARP packet will harmlessly no device with that MAC address, and the ARP packet will harmlessly
disappear into the void without doing any damage. disappear into the void without doing any damage.
These issues that define the applicability of DNAv4 lead us to a These issues that define the applicability of DNAv4 lead us to a
number of conclusions: number of conclusions:
o DNAv4 is a performance optimization. Its purpose is to speed o DNAv4 is a performance optimization. Its purpose is to speed
up a process that may require as much as a few hundred up a process that may require as much as a few hundred
milliseconds (DHCP INIT-REBOOT), as well as to reduce milliseconds (DHCP INIT-REBOOT), as well as to reduce multi-
multi-second conflict detection delays when a host changes second conflict detection delays when a host changes networks.
networks.
o As a performance optimization, it must not sacrifice o As a performance optimization, it must not sacrifice
correctness. In other words, false positives are not correctness. In other words, false positives are not
acceptable. DNAv4 must not conclude that a host that has acceptable. DNAv4 must not conclude that a host has returned
returned to a previously-visited link where it has an operable to a previously visited link where it has an operable IP
IP address if this is not in fact the case. address if this is not in fact the case.
o As a performance optimization, false negatives are acceptable. o As a performance optimization, false negatives are acceptable.
It is not an absolute requirement that this optimization It is not an absolute requirement that this optimization
correctly recognize a previously-visited link in all possible correctly recognize a previously visited link in all possible
cases. For example, if a router ignores unicast ARP Requests cases. For example, if a router ignores unicast ARP Requests,
then DNAv4 will not be able to detect that it has returned to then DNAv4 will not be able to detect that it has returned to
the same link in future. This is acceptable because the host the same link in the future. This is acceptable because the
still operates correctly as it did without DNAv4, just without host still operates correctly as it did without DNAv4, just
the performance benefit. Users and network operators who without the performance benefit. Users and network operators
desire the performance improvement offered by DNAv4 can who desire the performance improvement offered by DNAv4 can
upgrade their routers to support DNAv4. upgrade their routers to support DNAv4.
o As a performance optimization, where DNAv4 fails to provide a o As a performance optimization, where DNAv4 fails to provide a
benefit, it should add little or no delay compared to today's benefit, it should add little or no delay compared to today's
DHCP processing. In practice, this implies that DHCP DHCP processing. In practice, this implies that DHCP
processing needs to proceed in parallel. Waiting for DNAv4 processing needs to proceed in parallel. Waiting for DNAv4 to
to fail before beginning DHCP processing can greatly increase fail before beginning DHCP processing can greatly increase
total processing time, the opposite of the desired effect. total processing time, the opposite of the desired effect.
o Trials are inexpensive. DNAv4 performs its checks using small o Trials are inexpensive. DNAv4 performs its checks using small
unicast packets. An IPv4 ARP packet on Ethernet is just 42 unicast packets. An IPv4 ARP packet on Ethernet is just 42
octets, including the Ethernet header. This means that the octets, including the Ethernet header. This means that the
cost of an unsuccessful attempt is small, whereas the cost of a cost of an unsuccessful attempt is small, whereas the cost of a
missed opportunity (having the right address available as a missed opportunity (having the right address available as a
candidate and choosing not to try it for some reason) is large. candidate and choosing not to try it for some reason) is large.
As a result, the best strategy is often to try all available As a result, the best strategy is often to try all available
candidate configurations, rather than trying to determine which candidate configurations, rather than try to determine which
candidates, if any, may be correct for this link, based on candidates, if any, may be correct for this link, based on
heuristics or hints. For a heuristic to usefully eliminate a heuristics or hints. For a heuristic to offer the prospect of
configuration from the candidate list, it has to (a) be fast being a potentially useful way to eliminate inappropriate
and inexpensive to compute, compared to sending a 42-octet configurations from the candidate list, that heuristic has to
unicast packet, and (b) have high probability of not falsely (a) be fast and inexpensive to compute, as compared to sending
eliminating a candidate configuration that could be found to be a 42-octet unicast packet, and (b) have high probability of not
the correct one. falsely eliminating a candidate configuration that could be
found to be the correct one.
o Time is limited. If DNAv4 is to be effective in enabling low o Time is limited. If DNAv4 is to be effective in enabling low
latency handoffs, it needs to complete in less than 10 ms. latency handoffs, it needs to complete in less than 10 ms.
This implies that any heuristic used to eliminate candidate This implies that any heuristic used to eliminate candidate
configurations needs to take at most a few milliseconds to configurations needs to take at most a few milliseconds to
compute. This does not leave much room for heuristics based compute. This does not leave much room for heuristics based on
on observation of link layer or Internet layer traffic. observation of link-layer or Internet-layer traffic.
1.2. Requirements 1.2. Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
1.3. Terminology 1.3. Terminology
This document uses the following terms: This document uses the following terms:
ar$sha ar$sha
ARP packet field: Sender Hardware Address [RFC826]. The hardware ARP packet field: Sender Hardware Address [RFC826]. The hardware
(MAC) address of the originator of an ARP packet. (MAC) address of the originator of an ARP packet.
ar$spa ar$spa
ARP packet field: Sender Protocol Address [RFC826]. For IP Address ARP packet field: Sender Protocol Address [RFC826]. For IP
Resolution this is the IPv4 address of the sender of the ARP Address Resolution, this is the IPv4 address of the sender of the
packet. ARP packet.
ar$tha ar$tha
ARP packet field: Target Hardware Address [RFC826]. The hardware ARP packet field: Target Hardware Address [RFC826]. The hardware
(MAC) address of the target of an ARP packet. (MAC) address of the target of an ARP packet.
ar$tpa ar$tpa
ARP packet field: Target Protocol Address [RFC826]. For IPv4 ARP packet field: Target Protocol Address [RFC826]. For IPv4
Address Resolution, the IPv4 address for which one desires to know Address Resolution, the IPv4 address for which one desires to know
the hardware address. the hardware address.
DHCP client DHCP client
A DHCP client or "client" is an Internet host using the Dynamic A DHCP client or "client" is an Internet host using the Dynamic
Host Configuration protocol (DHCP) [RFC2131] to obtain Host Configuration Protocol (DHCP) [RFC2131] to obtain
configuration parameters such as a network address. configuration parameters, such as a network address.
DHCP server DHCP server
A DHCP server or "server" is an Internet host that returns A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients. configuration parameters to DHCP clients.
Link A communication facility or medium over which network nodes can Link
A communication facility or medium over which network nodes can
communicate. Each link is associated with a minimum of two communicate. Each link is associated with a minimum of two
endpoints. Each link endpoint has a unique link-layer identifier. endpoints. Each link endpoint has a unique link-layer identifier.
Link Down Link Down
An event provided by the link layer that signifies a state change An event provided by the link layer that signifies a state change
associated with the interface no longer being capable of associated with the interface's no longer being capable of
communicating data frames; transient periods of high frame loss are communicating data frames; transient periods of high frame loss
not sufficient. DNAv4 does not utilize "Link Down" indications. are not sufficient. DNAv4 does not utilize "Link Down"
indications.
Link Layer Link Layer
Conceptual layer of control or processing logic that is responsible Conceptual layer of control or processing logic that is
for maintaining control of the data link. The data link layer responsible for maintaining control of the data link. The data
functions provide an interface between the higher-layer logic and link layer functions provide an interface between the higher-layer
the data link. The link layer is the layer immediately below IP. logic and the data link. The link layer is the layer immediately
below IP.
Link Up Link Up
An event provided by the link layer that signifies a state change An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating associated with the interface's becoming capable of communicating
data frames. data frames.
Point of Attachment Point of Attachment
The link endpoint on the link to which the host is currently The link endpoint on the link to which the host is currently
connected. connected.
Routable address Routable address
In this specification, the term "routable address" refers to any In this specification, the term "routable address" refers to any
IPv4 address other than an IPv4 Link-Local address. This includes unicast IPv4 address other than an IPv4 Link-Local address. This
private addresses as specified in "Address Allocation for Private includes private addresses as specified in "Address Allocation for
Internets" [RFC1918]. Private Internets" [RFC1918].
Operable address Operable address
In this specification, the term "operable address" refers to either In this specification, the term "operable address" refers either
a static IPv4 address, or an address assigned via DHCPv4 which has to a static IPv4 address, or an address assigned via DHCPv4 that
not been returned to the DHCP server via a DHCP RELEASE message, has not been returned to the DHCP server via a DHCP RELEASE
and whose lease has not yet expired. message, and whose lease has not yet expired.
2. Overview 2. Overview
On connecting to a new point of attachment, the host responds to a On connecting to a new point of attachment, the host responds to a
"Link Up" indication from the link layer by carrying out the DNAv4 "Link Up" indication from the link layer by carrying out the DNAv4
procedure. procedure.
For each network that it connects to, it is assumed that the host For each network that it connects to, it is assumed that the host
saves to stable storage the following parameters: saves the following parameters to stable storage:
[1] The IPv4 and MAC address of one or more test nodes [1] The IPv4 and MAC address of one or more test nodes on the
on the network network.
[2] The IPv4 configuration parameters, including [2] The IPv4 configuration parameters, including the DHCP client
the DHCP client identifier, assigned address and identifier, assigned address, and lease expiration time.
lease expiration time
From the set of networks which have operable IPv4 address(es) From the set of networks that have operable IPv4 addresses associated
associated with them, the host selects a subset, and attempts to with them, the host selects a subset and attempts to confirm the
confirm the configuration for each network, using the reachability configuration for each network, using the reachability test described
test described in Section 2.1. in Section 2.1.
For a particular network, the host SHOULD use the addresses of local For a particular network, the host SHOULD use the addresses of local
routers (preferably default gateways) as its test nodes. If more routers (preferably default gateways) as its test nodes. If more
than one address is known, those addresses may be tested in parallel. than one address is known, those addresses may be tested in parallel.
In order to ensure configuration validity, the host SHOULD only In order to ensure configuration validity, the host SHOULD only
configure routes for which the next hop address passes the configure routes for which the next hop address passes the
reachability test. Other routes SHOULD be re-learned. reachability test. Other routes SHOULD be re-learned.
DNAv4 does not significantly increase the likelihood of an address DNAv4 does not significantly increase the likelihood of an address
conflict. The reachability test is only carried out for a network conflict. The reachability test is only carried out for a network
when the host has previously completed conflict detection as when the host has previously completed conflict detection as
recommended in Section 2.2 of the DHCP specification [RFC2131], and recommended in Section 2.2 of the DHCP specification [RFC2131] and
obtained an operable IPv4 configuration on that network. obtained an operable IPv4 configuration on that network.
Restrictions on sending ARP Requests and Responses are described in Restrictions on sending ARP Requests and Responses are described in
Section 2.1.1. Section 2.1.1.
One case where DNAv4 does increase the likelihood of an address One case where DNAv4 does increase the likelihood of an address
conflict is when: conflict is when:
o a DHCP server hands out an address lease o a DHCP server hands out an address lease,
o the host with that lease leaves the network
o the DHCP server is power-cycled, or crashes and is rebooted o the host with that lease leaves the network,
o the DHCP server is power-cycled or crashes and is rebooted,
o the DHCP server, having failed to save leases to stable o the DHCP server, having failed to save leases to stable
storage, assigns that same address to another host storage, assigns that same address to another host, and
o the first host returns, and having a still-valid lease
with time remaining, proceeds to use its assigned o the first host returns and, having a still-valid lease with
address, conflicting with the new host that is now time remaining, proceeds to use its assigned address,
using that same address conflicting with the new host that is now using that same
address.
While Section 4 of the DHCP specification [RFC2131] assumes that DHCP While Section 4 of the DHCP specification [RFC2131] assumes that DHCP
servers save their leases in persistent storage, almost no consumer- servers save their leases in persistent storage, almost no consumer-
grade NAT gateway does so. Short DHCP lease lifetimes can mitigate grade NAT gateway does so. Short DHCP lease lifetimes can mitigate
this risk, though this also limits the operable candidate this risk, though this also limits the operable candidate
configurations available for DNAv4 to try. configurations available for DNAv4 to try.
2.1. Reachability Test 2.1. Reachability Test
The host skips the reachability test for a network if any of the The host skips the reachability test for a network if any of the
following conditions are true: following conditions are true:
[a] The host does not have an operable routable IPv4 [a] The host does not have an operable routable IPv4 address on that
address on that network. In this case, the reachability network. In this case, the reachability test cannot confirm that
test cannot confirm that the host has an operable the host has an operable routable IPv4 address, so completing the
routable IPv4 address, so completing the
reachability test would serve no purpose. reachability test would serve no purpose.
[b] The host does not know the addresses of any test nodes [b] The host does not know the addresses of any test nodes on that
on that network. In this case, insufficient information network. In this case, insufficient information is available to
is available to carry out the reachability test. carry out the reachability test.
[c] If DHCP authentication [RFC3118] is configured. The [c] If DHCP authentication [RFC3118] is configured. The reachability
reachability test utilizes ARP which is insecure. test utilizes ARP, which is insecure. Hosts that have been
Hosts that have been configured to attempt DHCP configured to attempt DHCP authentication SHOULD NOT utilize the
authentication SHOULD NOT utilize the reachability reachability test. Security issues are discussed in Section 4.
test. Security issues are discussed in Section 4.
[d] The contents of the DHCP Client Identifier option the client [d] The contents of the DHCP Client Identifier option that the client
used to obtain the candidate configuration is different from used to obtain the candidate configuration is different from the
the DHCP Client Identifier option the client intends to DHCP Client Identifier option the client intends to present on
present on the interface in question. In this case, it is the interface in question. In this case, it is anticipated that
anticipated that a DHCP server would NAK any request made a DHCP server would NAK any request made by the client to acquire
by the client to acquire or extend the candidate configuration, or extend the candidate configuration, since the two interfaces
since the two interfaces are presenting differing identities. are presenting differing identities.
If the reachability test is successful, the host SHOULD continue to If the reachability test is successful, the host SHOULD continue to
use the operable routable IPv4 address associated with the confirmed use the operable routable IPv4 address associated with the confirmed
network, without needing to re-acquire it. Once a valid reachability network, without needing to re-acquire it. Once a valid reachability
test response is received, validation is complete, and additional test response is received, validation is complete, and additional
responses should be discarded. responses should be discarded.
If a DHCPv4 client is operational, it is RECOMMENDED that the host If a DHCPv4 client is operational, it is RECOMMENDED that the host
attempt to obtain IPv4 configuration via DHCPv4 in parallel with the attempt to obtain IPv4 configuration via DHCPv4 in parallel with the
reachability tests, with the host using the first answer returned. reachability tests, with the host using the first answer returned.
This ensures that the DNAv4 procedure will not result in additional This ensures that the DNAv4 procedure will not result in additional
delay in the case where reachability test(s) fail, or where sending a delay in the case where reachability tests fail, or where sending a
DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2 DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2
and 4.3.2 of the DHCP specification [RFC2131], completes more quickly and 4.3.2 of the DHCP specification [RFC2131], completes more quickly
than the reachability test(s). than the reachability tests.
In situations where both DNAv4 and DHCP are used on the same link, it In situations where both DNAv4 and DHCP are used on the same link, it
is possible that the reachability test will complete successfully, is possible that the reachability test will complete successfully,
and then DHCP will complete later with a different result. If this and then DHCP will complete later with a different result. If this
happens, the implementation SHOULD abandon the reachability test happens, the implementation SHOULD abandon the reachability test
results and use the DHCP result instead, unless the address confirmed results and use the DHCP result instead, unless the address confirmed
via the reachability test has been manually assigned (see Section via the reachability test has been manually assigned (see Section
2.4). 2.4).
Where the reachability test does not return an answer, this is Where the reachability test does not return an answer, this is
typically because the host is not attached to the network whose typically because the host is not attached to the network whose
configuration is being tested. In such circumstances, there is configuration is being tested. In such circumstances, there is
typically little value in aggressively retransmitting reachability typically little value in aggressively retransmitting reachability
tests that do not elicit a response. tests that do not elicit a response.
Where DNAv4 and DHCP are tried in parallel, one strategy is to Where DNAv4 and DHCP are tried in parallel, one strategy is to
forsake reachability test retransmissions, allowing only the DHCP forsake reachability test retransmissions and to allow only the DHCP
client to retransmit. In order to reduce competition between DNAv4 client to retransmit. In order to reduce competition between DNAv4
and DHCP retransmissions, a DNAv4 implementation that retransmits may and DHCP retransmissions, a DNAv4 implementation that retransmits may
utilize the retransmission strategy described in Section 4.1 of the utilize the retransmission strategy described in Section 4.1 of the
DHCP specification [RFC2131], scheduling DNAv4 retransmissions DHCP specification [RFC2131], scheduling DNAv4 retransmissions
between DHCP retransmissions. between DHCP retransmissions.
If a response is received to any reachability test or DHCP message, If a response is received to any reachability test or DHCP message,
pending retransmissions are canceled. It is RECOMMENDED that a DNAv4 pending retransmissions are canceled. It is RECOMMENDED that a DNAv4
implementation retransmit no more than twice. To provide damping in implementation retransmit no more than twice. To provide damping in
the case of spurious "Link Up" indications, it is RECOMMENDED that the case of spurious "Link Up" indications, it is RECOMMENDED that
the DNAv4 procedure be carried out no more than once a second. the DNAv4 procedure be carried out no more than once a second.
2.1.1. Packet Format 2.1.1. Packet Format
The reachability test is performed by sending a unicast ARP Request. The reachability test is performed by sending a unicast ARP Request.
The host MUST set the target protocol address (ar$tpa) to the IPv4 The host MUST set the target protocol address (ar$tpa) to the IPv4
address of the node being tested, and the sender protocol address address of the node being tested, and the sender protocol address
field (ar$spa) to its own candidate IPv4 address. The ARP Request field (ar$spa) to its own candidate IPv4 address. The ARP Request
MUST use the host MAC address as the source, and the test node MAC MUST use the host MAC address as the source, and the test node MAC
address as the destination. The host includes its MAC address in the address as the destination. The host includes its MAC address in the
sender hardware address field (ar$sha), and sets the target hardware sender hardware address field (ar$sha) and sets the target hardware
address field (ar$tha) to 0. address field (ar$tha) to 0.
If a valid ARP Reply is received, the MAC address in the sender If a valid ARP Reply is received, the MAC address in the sender
hardware address field (ar$sha) in the ARP Reply is matched against hardware address field (ar$sha) in the ARP Reply is matched against
the target hardware address field (ar$tpa) in the ARP Request, and the target hardware address field (ar$tpa) in the ARP Request, and
the IPv4 address in the sender protocol address field (ar$spa) of the the IPv4 address in the sender protocol address field (ar$spa) of the
ARP Reply is matched against the target protocol address field ARP Reply is matched against the target protocol address field
(ar$tpa) in the ARP Request. If a match is found, then the host (ar$tpa) in the ARP Request. If a match is found, then the host
continues to use that IPv4 address, subject to the lease re- continues to use that IPv4 address, subject to the lease re-
acquisition and expiration behavior described in Section 4.4.5 of the acquisition and expiration behavior described in Section 4.4.5 of the
skipping to change at page 10, line 30 skipping to change at page 10, line 11
The risk of an address conflict is greatest when the host moves The risk of an address conflict is greatest when the host moves
between private networks, since in this case the completion of between private networks, since in this case the completion of
conflict detection on the former network does not provide assurance conflict detection on the former network does not provide assurance
against an address conflict on the new network. Until a host has against an address conflict on the new network. Until a host has
confirmed the operability of its IPv4 configuration by receipt of a confirmed the operability of its IPv4 configuration by receipt of a
response to the reachability test, it SHOULD NOT respond to ARP response to the reachability test, it SHOULD NOT respond to ARP
Requests and SHOULD NOT broadcast ARP Requests containing its address Requests and SHOULD NOT broadcast ARP Requests containing its address
within the sender protocol address field (ar$spa). within the sender protocol address field (ar$spa).
Sending an ICMP Echo Request [RFC792] would not be an acceptable way Sending an ICMP Echo Request [RFC792] would not be an acceptable way
of testing a candidate configuration since sending any IP packet of testing a candidate configuration, since sending any IP packet
generally requires an ARP Request/Reply exchange, and as explained generally requires an ARP Request/Reply exchange and, as explained
above, ARP packets may not be broadcast safely until after the above, ARP packets may not be broadcast safely until after the
candidate configuration has been confirmed. Also where a host moves candidate configuration has been confirmed. Also, where a host moves
from one private network to another, an ICMP Echo Request can result from one private network to another, an ICMP Echo Request can result
in an ICMP Echo Response even when the MAC address has changed, as in an ICMP Echo Response even when the MAC address has changed, as
long as the IPv4 address remains the same. This can occur, for long as the IPv4 address remains the same. This can occur, for
example, where a host moves from one home network using prefix example, where a host moves from one home network using prefix
192.168/16 to another one. In addition, if the ping is sent with TTL 192.168/16 to another one. In addition, if the ping is sent with TTL
> 1, then an ICMP Echo Response can be received from an off-link > 1, then an ICMP Echo Response can be received from an off-link
router. As a result, if the MAC address of the test node is not router. As a result, if the MAC address of the test node is not
checked, the host can mistakenly confirm attachment, potentially checked, the host can mistakenly confirm attachment, potentially
resulting in an address conflict. As a result, sending of an ICMP resulting in an address conflict. As a result, sending an ICMP Echo
Echo Request SHOULD NOT be used as a substitute for the reachability Request SHOULD NOT be used as a substitute for the reachability test.
test.
2.2. IPv4 Address Acquisition 2.2. IPv4 Address Acquisition
If the host has an operable routable IPv4 address on one or more If the host has an operable routable IPv4 address on one or more
networks, and DHCPv4 is enabled on the interface, the host SHOULD networks, and if DHCPv4 is enabled on the interface, the host SHOULD
attempt to acquire an IPv4 configuration using DHCPv4, in parallel attempt to acquire an IPv4 configuration using DHCPv4, in parallel
with one or more reachability tests. This is accomplished by with one or more reachability tests. This is accomplished by
entering the INIT-REBOOT state, and sending a DHCPREQUEST to the entering the INIT-REBOOT state and sending a DHCPREQUEST to the
broadcast address as specified in Section 4.4.2 of the DHCP broadcast address, as specified in Section 4.4.2 of the DHCP
specification [RFC2131]. specification [RFC2131].
If the host does not have an operable routable IPv4 address on any If the host does not have an operable routable IPv4 address on any
network, the host enters the INIT state and sends a DHCPDISCOVER network, the host enters the INIT state and sends a DHCPDISCOVER
packet to the broadcast address, as described in Section 4.4.1 of the packet to the broadcast address, as described in Section 4.4.1 of the
DHCP specification [RFC2131]. If the host supports the Rapid Commit DHCP specification [RFC2131]. If the host supports the Rapid Commit
Option [RFC4039], it is possible that the exchange can be shortened Option [RFC4039], it is possible that the exchange can be shortened
from a 4-message exchange to a 2-message exchange. from a 4-message exchange to a 2-message exchange.
If the host does not receive a response to a DHCPREQUEST or If the host does not receive a response to a DHCPREQUEST or
DHCPDISCOVER, then it retransmits as specified in Section 4.1 of the DHCPDISCOVER, then it retransmits as specified in Section 4.1 of the
DHCP specification [RFC2131]. DHCP specification [RFC2131].
As discussed in Section 4.4.4 of the DHCP specification [RFC2131], a As discussed in Section 4.4.4 of the DHCP specification [RFC2131], a
host in INIT or REBOOTING state that knows the address of a DHCP host in INIT or REBOOTING state that knows the address of a DHCP
server may use that address in the DHCPDISCOVER or DHCPREQUEST rather server may use that address in the DHCPDISCOVER or DHCPREQUEST rather
than the IPv4 broadcast address. In the INIT-REBOOT state a than the IPv4 broadcast address. In the INIT-REBOOT state, a
DHCPREQUEST is sent to the broadcast address so that the host will DHCPREQUEST is sent to the broadcast address so that the host will
receive a response regardless of whether the previously configured receive a response regardless of whether the previously configured
IPv4 address is correct for the network to which it has connected. IPv4 address is correct for the network to which it has connected.
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is
not appropriate, since if the DHCP client has moved to another not appropriate, since if the DHCP client has moved to another
subnet, a DHCP server response cannot be routed back to the client subnet, a DHCP server response cannot be routed back to the client
since the DHCPREQUEST will bypass the DHCP relay and will contain an since the DHCPREQUEST will bypass the DHCP relay and will contain an
invalid source address. invalid source address.
2.3. IPv4 Link-Local Addresses 2.3. IPv4 Link-Local Addresses
DNAv4 applies only to previously-configured addresses that had some DNAv4 applies only to previously configured addresses that had some
lease lifetime associated with them, during which lifetime the lease lifetime associated with them, during which lifetime the
address may be legitimately regarded as being reserved for exclusive address may be legitimately regarded as being reserved for exclusive
use by the assigned host. DHCP-assigned addresses fit this use by the assigned host. DHCP-assigned addresses fit this
description, but IPv4 Link-Local address [RFC3927] do not, since IPv4 description, but IPv4 Link-Local address [RFC3927] do not, since IPv4
Link-Local addresses are not handed out by an authoritative server, Link-Local addresses are not handed out by an authoritative server
and do not come with any guaranteed usable lifetime. and do not come with any guaranteed usable lifetime.
A host's claim on an IPv4 Link-Local address is valid only as long as A host's claim on an IPv4 Link-Local address is valid only as long as
that host remains connected to the link, actively defending against that host remains connected to the link, actively defending against
probes for its chosen address. As soon as a host shuts down, sleeps, probes for its chosen address. As soon as a host shuts down, sleeps,
or otherwise disconnects from a link, it immediately relinquishes any or otherwise disconnects from a link, it immediately relinquishes any
claim it may have had on any IPv4 Link-Local address on that link. A claim it may have had on any IPv4 Link-Local address on that link. A
host wishing to reclaim a previously-used IPv4 Link-Local address host wishing to reclaim a previously used IPv4 Link-Local address
MUST perform the full probing and announcement process required by MUST perform the full probing and announcement process required by
"Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927], and "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] and
MUST NOT attempt to use DNAv4 as a shortcut to bypass that process. MUST NOT attempt to use DNAv4 as a shortcut to bypass that process.
Where the host does not have an operable routable IPv4 address on any Where the host does not have an operable routable IPv4 address on any
network, the host MAY configure an IPv4 Link-Local address prior to network, the host MAY configure an IPv4 Link-Local address prior to
entering the INIT state and sending a DHCPDISCOVER packet, as entering the INIT state and sending a DHCPDISCOVER packet, as
described in Section 2.3 of the DHCP specification [RFC2131]. Where described in Section 2.3 of the DHCP specification [RFC2131]. Where
a host can confirm that it remains connected to a network on which it a host can confirm that it remains connected to a network on which it
possesses an operable routable IPv4 address, that address should be possesses an operable routable IPv4 address, that address should be
used and the IPv4 Link-Local address is deprecated, as noted in used, and the IPv4 Link-Local address is deprecated, as noted in
Section 1.9 of the IPv4 Link-Local specification [RFC3927]. Section 1.9 of the IPv4 Link-Local specification [RFC3927].
Where a host has an operable routable IPv4 address on one or more Where a host has an operable routable IPv4 address on one or more
networks, but the reachability test cannot confirm the configuration networks but the reachability test cannot confirm the configuration
and the DHCPv4 client does not receive a response after employing the and the DHCPv4 client does not receive a response after employing the
retransmission algorithm, Section 3.2 of the DHCP specification retransmission algorithm, Section 3.2 of the DHCP specification
[RFC2131] states that the client MAY choose to use the previously [RFC2131] states that the client MAY choose to use the previously
allocated network address and configuration parameters for the allocated network address and configuration parameters for the
remainder of the unexpired lease. remainder of the unexpired lease.
2.4. Manually Assigned Addresses 2.4. Manually Assigned Addresses
An implementation may use DNAv4 to confirm the configuration of An implementation may use DNAv4 to confirm the configuration of
manually assigned addresses. However, special consideration is manually assigned addresses. However, special consideration is
required for this to produce reliable results, so that it SHOULD NOT required for this to produce reliable results, so it SHOULD NOT be
be enabled by default. enabled by default.
For the purposes of DNAv4, manually assigned addresses may be treated For the purposes of DNAv4, manually assigned addresses may be treated
as equivalent to DHCP-assigned addresses with an infinite lifetime. as equivalent to DHCP-assigned addresses with an infinite lifetime.
This does not significantly increase the probability of an address This does not significantly increase the probability of an address
conflict as long as the manually assigned address is reserved by the conflict as long as the manually assigned address is reserved by the
DHCP server or is outside the scope of addresses assigned by a DHCP DHCP server or is outside the scope of addresses assigned by a DHCP
server. However, where the manually assigned address is within an server. However, where the manually assigned address is within an
address scope utilized by a DHCP server, it is possible that the host address scope utilized by a DHCP server, it is possible that the host
will be unavailable when the DHCP server checks for a conflict prior will be unavailable when the DHCP server checks for a conflict prior
to assigning the conflicting address. In this case, a host utilizing to assigning the conflicting address. In this case, a host utilizing
DNAv4 could confirm an address that had been assigned to another DNAv4 could confirm an address that had been assigned to another
host. host.
Typically an address is manually assigned on a network because a Typically, an address is manually assigned on a network because a
dynamically assigned address was not suitable for some reason. dynamically assigned address was not suitable for some reason.
Therefore where both DNAv4 and DHCP are run in parallel and DNAv4 Therefore, where DNAv4 and DHCP are run in parallel and DNAv4
confirms a manual configuration, it may be undesirable to allow this confirms a manual configuration, it may be undesirable to allow this
configuration to be overridden by DHCP, as described in Section 2.1. configuration to be overridden by DHCP, as described in Section 2.1.
However, packet loss may cause the reachability test to fail while However, packet loss may cause the reachability test to fail while
DHCP completes successfully, resulting in the host obtaining a DHCP completes successfully, resulting in the host obtaining a
dynamic address where a static address is desired. In order to dynamic address where a static address is desired. In order to
provide for reliable reconfirmation of manually assigned addresses, provide for reliable reconfirmation of manually assigned addresses,
reachability tests for manual configurations require a more reachability tests for manual configurations require a more
aggressive retransmission strategy than that detailed in Section 4.1 aggressive retransmission strategy than that detailed in Section 4.1
of the DHCP specification [RFC2131]. For example, shorter of the DHCP specification [RFC2131]. For example, shorter
retransmission intervals and more persistent retransmissions may be retransmission intervals and more persistent retransmissions may be
required. required.
3. IANA Considerations 3. Security Considerations
This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments.
4. Security Considerations
Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and
DHCP and inherits the security vulnerabilities of these two DHCP and inherits the security vulnerabilities of these two
protocols. protocols.
ARP [RFC826] traffic is not secured, so that an attacker gaining ARP [RFC826] traffic is not secured, so an attacker gaining access to
access to the network can spoof a response to the reachability test the network can spoof a response to the reachability test described
described in Section 2.1, leading the querier to falsely conclude in Section 2.1, leading the querier to conclude falsely that it is
that it is attached to a network that it is not connected to. attached to a network that it is not connected to.
Similarly, where DHCPv4 traffic is not secured, an attacker could Similarly, where DHCPv4 traffic is not secured, an attacker could
masquerade as a DHCPv4 server, in order to convince the host that it masquerade as a DHCPv4 server, in order to convince the host that it
was attached to a particular network. This and other threats was attached to a particular network. This and other threats
relating to DHCPv4 are described in "Authentication for DHCP relating to DHCPv4 are described in "Authentication for DHCP
Messages" [RFC3118]. Messages" [RFC3118].
The effect of these attacks will typically be limited to denial of The effect of these attacks will typically be limited to denial of
service, unless the host utilizes its IP configuration for other service, unless the host utilizes its IP configuration for other
purposes, such as security configuration or location determination. purposes, such as security configuration or location determination.
For example, a host that disables its personal firewall based on For example, a host that disables its personal firewall based on
evidence that it had attached to a home network could be compromised evidence that it had attached to a home network could be compromised
by spoofing of the DNAv4 reachability test. In general, adjustment by spoofing of the DNAv4 reachability test. In general, adjustment
of the security configuration based on DNAv4 is NOT RECOMMENDED. of the security configuration based on DNAv4 is NOT RECOMMENDED.
Hosts that depend on secure IP configuration SHOULD NOT use DNAv4, Hosts that depend on secure IP configuration SHOULD NOT use DNAv4 but
but SHOULD instead utilize DHCP authentication [RFC3118], possibly in SHOULD instead utilize DHCP authentication [RFC3118], possibly in
combination with the Rapid Commit Option [RFC4039]. combination with the Rapid Commit Option [RFC4039].
5. References 4. References
5.1. Normative References 4.1. Normative References
[RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Addresses to 48-bit Ethernet Address for converting network protocol addresses to 48.bit Ethernet
Transmission on Ethernet Hardware", STD 37, RFC 826, November address for transmission on Ethernet hardware", STD 37, RFC
1982. 826, November 1982.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
5.2. Informative References 4.2. Informative References
[ACD] Cheshire, S., "IPv4 Address Conflict Detection", Internet [ACD] Cheshire, S., "IPv4 Address Conflict Detection", Work in
draft (work in progress), draft-cheshire-ipv4-acd-04.txt, July Progress, July 2005.
2005.
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
USC/Information Sciences Institute, September 1981. 792, September 1981.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
E. Lear, "Address Allocation for Private Internets", RFC 1918, and E. Lear, "Address Allocation for Private Internets",
February 1996. BCP 5, RFC 1918, February 1996.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
of IPv4 Link-Local Addresses", RFC 3927, May 2005. Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC the Dynamic Host Configuration Protocol version 4
4039, March 2005. (DHCPv4)", RFC 4039, March 2005.
Acknowledgments 5. Acknowledgements
The authors would like to acknowledge Greg Daley of Monash The authors would like to acknowledge Greg Daley of Monash
University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ralph University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ralph
Droms of Cisco Systems, Ted Lemon of Nominum, John Loughney of Nokia, Droms of Cisco Systems, Ted Lemon of Nominum, John Loughney of Nokia,
Thomas Narten of IBM and David Hankins of ISC for contributions to Thomas Narten of IBM and David Hankins of ISC for contributions to
this document. this document.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 818 4011 Phone: +1 425 818 4011
Fax: +1 425 936 7329 Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
James Carlson James Carlson
Sun Microsystems, Inc Sun Microsystems, Inc
1 Network Drive 1 Network Drive
Burlington, MA 01803-2757 Burlington, MA 01803-2757
USA USA
Phone: +1 781 442 2084 Phone: +1 781 442 2084
Fax: +1 781 442 1677 Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com EMail: james.d.carlson@sun.com
Stuart Cheshire Stuart Cheshire
Apple Computer, Inc. Apple Computer, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014, USA Cupertino, California 95014, USA
Phone: +1 408 974 3207 Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org EMail: rfc@stuartcheshire.org
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
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 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 15, line 43 skipping to change at page 15, line 45
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.
Disclaimer of Validity Acknowledgement
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Open issues
Open issues relating to this specification are tracked
on the following web site:
http://www.drizzle.com/~aboba/DNA/ Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 89 change blocks. 
237 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/