draft-ietf-dhc-dna-ipv4-11.txt   draft-ietf-dhc-dna-ipv4-12.txt 
DHC Working Group Bernard Aboba DHC Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation INTERNET-DRAFT Microsoft Corporation
Category: Proposed Standard Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-11.txt> <draft-ietf-dhc-dna-ipv4-12.txt>
12 April 2005 3 June 2005
Detection of Network Attachment (DNA) in IPv4 Detecting Network Attachment (DNA) in IPv4
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2005. This Internet-Draft will expire on December 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society 2005.
Abstract Abstract
The time required to detect movement (or lack of movement) between The time required to detect movement between networks, and to obtain
subnets, and to obtain (or continue to use) a valid IPv4 (or continue to use) an operable IPv4 configuration may be
configuration may be significant as a fraction of the total handover significant as a fraction of the total handover latency in moving
latency in moving between points of attachment. This document between points of attachment. This document specifies a procedure
specifies a procedure for optimizing the detection of network for optimizing detection of network attachment in order to decrease
attachment and IPv4 configuration in order to decrease the handover the handover latency in moving between points of attachment.
latency in moving between points of attachment.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
2. Overview ................................................. 4 2. Overview ................................................. 5
2.1 Most Likely Point of Attachment ................. 5 2.1 Most Likely Attachment Network .................. 6
2.2 Reachability Test ............................... 6 2.2 Reachability Test ............................... 7
2.3 IPv4 Address Acquisition ........................ 9 2.3 IPv4 Address Acquisition ........................ 10
2.4 IPv4 Link-Local Addresses ....................... 9 2.4 IPv4 Link-Local Addresses ....................... 10
3. Constants ................................................ 11 3. Constants ................................................ 12
4. IANA Considerations ...................................... 11 4. IANA Considerations ...................................... 12
5. Security Considerations .................................. 11 5. Security Considerations .................................. 12
6. References ............................................... 11 6. References ............................................... 13
6.1 Normative references ............................ 11 6.1 Normative references ............................ 13
6.2 Informative references .......................... 12 6.2 Informative references .......................... 13
Acknowledgments .............................................. 13 Acknowledgments .............................................. 14
Authors' Addresses ........................................... 13 Authors' Addresses ........................................... 14
Appendix A - Link Layer Hints ................................ 14 Appendix A - Link Layer Hints ................................ 15
A.1 Introduction .................................... 14 A.1 Introduction .................................... 15
A.2 Hints ........................................... 15 A.2 Hints ........................................... 16
Intellectual Property Statement .............................. 16 Intellectual Property Statement .............................. 17
Copyright Statement .......................................... 17 Disclaimer of Validity ....................................... 18
Disclaimer of Validity ....................................... 17 Copyright Statement .......................................... 18
1. Introduction 1. Introduction
The time required to detect movement (or lack of movement) between The time required to detect movement between networks and to obtain
subnets, and to obtain (or continue to use) a valid IPv4 address may (or continue to use) an operable IPv4 configuration may be
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 experience in the deployment of hosts This document synthesizes 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], specifying a procedure for optimizing detection addresses [RFC3927], specifying a procedure for detecting network
of network attachment and IPv4 configuration, in order to minimize attachment and optimizing continued use of an operable IPv4
the handover latency in moving between points of attachment. Since configuration, in order to minimize the handover latency in moving
this procedure is dependent on the ARP protocol, it is not suitable between points of attachment. Since this procedure is dependent on
for use on media that do not support ARP [RFC826]. the ARP protocol, it is not suitable for use on media that do not
support ARP [RFC826].
1.1. Requirements 1.1. 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
[RFC2119]. [RFC2119].
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
ar$sha ar$sha
ARP packet field: Source Hardware Address [RFC826]. The hardware ARP packet field: Source 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: Source Protocol Address [RFC826]. For IP Address ARP packet field: Source Protocol Address [RFC826]. For IP Address
Resolution this is the IPv4 address of the sender of the ARP Resolution this is the IPv4 address of the sender of the ARP
packet. If the sender address is unknown, this is set to 0.0.0.0. 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, or the broadcast (MAC) address of the target of an ARP packet.
address if the target hardware address is unknown.
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.
ARP Probe
An ARP Request packet, broadcast on the local link, with an all-
zero 'sender IP address' (ar$spa). The 'sender hardware address'
(ar$sha) MUST contain the hardware address of the interface sending
the packet. The 'target hardware address' field (ar$tha) is
ignored and SHOULD be set to all zeroes. The 'target IP address'
(ar$tpa) field MUST be set to the address being probed.
ARP Announcement
An ARP Request packet, broadcast on the local link, identical to
the ARP Probe described above, except that both the sender (ar$spa)
and target (ar$tpa) IP address fields contain the IP address being
announced.
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.
Point of Attachment Link A communication facility or medium over which network nodes can
A location within the network where a host may be connected. This communicate. Each link is associated with a minimum of two
attachment point can be characterized by its address prefix and endpoints. Each link endpoint has a unique link-layer identifier.
next hop routing information.
Most Likely Point of Attachment (MLPA) Link Down
The point of attachment heuristically determined by the host to be An event provided by the link layer that signifies a state change
most likely, based on hints from the network. associated with the interface no longer being capable of
communicating data frames; transient periods of high frame loss are
not sufficient. DNAv4 does not utilize "Link Down" indications.
Link Layer
Conceptual layer of control or processing logic that is responsible
for maintaining control of the data link. The data link layer
functions provide an interface between the higher-layer logic and
the data link. The link layer is the layer immediately below IP.
Link Up
An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating
data frames.
Most Likely Attachment Network (MLAN)
The attached network heuristically determined by the host to be
most likely, based on hints.
Point of Attachment
The link endpoint on the link to which the host is currently
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
address other than an IPv4 Link-Local address. This includes IPv4 address other than an IPv4 Link-Local address. This includes
private addresses as specified in [RFC1918]. private addresses as specified in [RFC1918].
Valid address Operable address
In this specification, the term "valid address" refers to either a In this specification, the term "operable address" refers to either
static IPv4 address, or an address assigned via DHCPv4 which has a static IPv4 address, or an address assigned via DHCPv4 which has
not been relinquished, and whose lease has not yet expired. not been relinquished, and whose lease has not yet expired.
2. Overview 2. Overview
DNAv4 consists of three phases: determination of the Most Likely DNAv4 consists of three phases: determination of the Most Likely
Point of Attachment (MLPA), reachability testing, and IPv4 address Attachment Network (MLAN), reachability testing, and IPv4 address
acquisition. acquisition.
On connecting to a new point of attachment, the host responds to On connecting to a new point of attachment, the host responds to a
"Link Up" indications from the link layer by carrying out the DNAv4 "Link Up" indication from the link layer by carrying out the DNAv4
procedure. As noted in Appendix A, hints about the point of procedure. As noted in Appendix A, hints about the network to which
attachment may be available from the link and Internet layers. Based the host has attached may be available from the link and Internet
on these hints, the host determines the "Most Likely Point of layers. Based on these hints, the host determines the "Most Likely
Attachment" (MLPA) and determines whether it has a valid IPv4 Attachment Network" (MLAN) and whether it has an operable IPv4
configuration associated with it. configuration associated with it.
If the host believes that it has attached to a network on which it If the host believes that it has attached to a network on which it
has a valid IPv4 configuration, then it performs a reachability test has an operable IPv4 configuration, then it performs a reachability
in order to confirm that configuration. In contrast to a DHCPv4 test in order to confirm that configuration. In contrast to a DHCPv4
exchange, which may be between a DHCPv4 client and an off-link DHCPv4 exchange, which may be between a DHCPv4 client and an off-link DHCPv4
server, the reachability test is designed to verify bi-directional server, the reachability test is designed to verify bi-directional
connectivity to the default gateway(s) on the MLPA. connectivity to the default gateway(s) on the MLAN.
If the reachability test is successful, the host MAY continue to use If the reachability test is successful, the host MAY continue to use
a valid routable IPv4 address without having to re-acquire it. This an operable routable IPv4 address without having to re-acquire it.
reduces roaming latency by allowing the host to bypass DHCPv4 as well This reduces roaming latency by allowing the host to bypass DHCPv4 as
as subsequent Duplicate Address Detection (DAD). If the host well as Duplicate Address Detection (DAD). If the host believes that
believes that it has attached to a network on which it has no valid it has attached to a network on which it has no operable IPv4
IPv4 configuration, or if the reachability test fails, then the host configuration, or if the reachability test fails, then the host
attempts to obtain an IPv4 configuration using DHCPv4. attempts to obtain an IPv4 configuration using DHCPv4.
Since DNAv4 represents a performance optimization, it is important to Since DNAv4 represents a performance optimization, it is important to
avoid compromising robustness. In some circumstances, DNAv4 may avoid compromising robustness. In some circumstances, DNAv4 may
result in a host successfully verifying an existing IPv4 result in a host successfully verifying an existing IPv4
configuration where attempting to obtain configuration via DHCPv4 configuration where attempting to obtain configuration via DHCPv4
would fail (such as when the DHCPv4 server is down). would fail (such as when the DHCPv4 server is down).
To improve robustness, this document suggests that hosts behave To improve robustness, this document suggests that hosts behave
conservatively with respect to assignment of IPv4 Link-Local conservatively with respect to assignment of IPv4 Link-Local
addresses, configuring them only in situations in which they can do addresses [RFC3927], configuring them only in situations in which
no harm. Experience has shown that IPv4 Link-Local addresses are they can do no harm. Experience has shown that IPv4 Link-Local
often assigned inappropriately, and that inappropriate assignment can addresses are often assigned inappropriately, compromising both
compromise both performance and connectivity. performance and connectivity.
While the performance of DNAv4 is dependent on the reliability of the While the performance of DNAv4 is dependent on the reliability of the
hints provided to the client, the host will ultimately determine the hints provided to the client, the host will ultimately determine the
correct IPv4 configuration even in the presence of misleading hints. correct IPv4 configuration even in the presence of misleading hints.
Where the host mistakenly concludes that it has attached to a network Where the host mistakenly concludes that it has an operable IPv4
on which it has a valid configuration a timeout will occur, providing configuration a timeout will occur, after which the host will
poorer performance than would be experienced by initially attempting eventually obtain the correct configuration using DHCPv4, albeit with
to obtain IPv4 configuration using DHCPv4. However, after timing a performance penalty.
out, the host will obtain its configuration using DHCPv4, so that
the correct configuration will eventually be obtained.
DNAv4 does not increase the likelihood of an address conflict. The DNAv4 does not increase the likelihood of an address conflict. The
DNAv4 procedure is only carried out when the host has a valid IPv4 DNAv4 procedure is only carried out when the host has an operable
configuration on the MLPA, implying that duplicate address detection IPv4 configuration on the MLAN, implying that duplicate address
has previously been completed. Restrictions on sending ARP requests detection has previously been completed. Restrictions on sending ARP
and replies are described in Section 2.2.1. Requests and Responses are described in Section 2.2.1.
2.1. Most Likely Point of Attachment 2.1. Most Likely Attachment Network (MLAN)
In order to determine the MLPA, it is assumed that the host saves to In order to determine the MLAN, it is assumed that the host saves to
stable storage parameters relating to the networks it connects to: stable storage parameters relating to the networks it connects to:
[1] Link and Internet layer hints associated with each [1] Link and Internet layer hints associated with each
network. For details, see Appendix A. network. For details, see Appendix A.
[2] The IPv4 and MAC address of the default gateway(s) on [2] The IPv4 and MAC address of the default gateway(s) on
each network. each network.
[3] The link type, such as whether the link utilizes [3] The link type, such as whether the link utilizes
Ethernet, or 802.11 adhoc or infrastructure mode. Ethernet, or 802.11 adhoc or infrastructure mode.
Appendix A discusses hints useful for the determination of the MLPA. Appendix A discusses hints useful for the determination of the MLAN.
By matching received hints against network parameters previously By matching received hints against network parameters previously
stored, the host makes an an educated guess of which network it has stored, the host makes an an educated guess of which network it has
attached to. In the absence of other information, the MLPA defaults attached to. In the absence of other information, the MLAN defaults
to the network to which the host was most recently attached. to the network to which the host was most recently attached.
Aside from utilizing link layer indications, a host may also be able Aside from utilizing link layer indications, a host may also be able
to utilize Internet layer information in order to determine the MLPA. to utilize Internet layer information in order to determine the MLAN.
IPv4 ICMP Router Discovery messages [RFC1256] provide information IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link, as well as the routers relating to prefix(es) available on the link, as well as the routers
that serve those prefix(es). A host may use ICMP Router Discovery to that serve those prefix(es). A host may use ICMP Router Discovery to
conclude that an advertised prefix is available; however it cannot conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are conclude the converse -- that prefixes not advertised are
unavailable. unavailable.
However, since [RFC1256] is not widely implemented, it is NOT However, since [RFC1256] is not widely implemented, it is NOT
RECOMMENDED that hosts utilize ICMP Router Discovery messages as an RECOMMENDED that hosts utilize ICMP Router Discovery messages as an
alternative to the reachability test outlined in Section 2.2. alternative to the reachability test outlined in Section 2.2.
skipping to change at page 6, line 39 skipping to change at page 7, line 23
Similarly hosts that support routing protocols such as RIP and OSPF Similarly hosts that support routing protocols such as RIP and OSPF
can use these protocols to determine the prefix(es) available on a can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. Full link and the default gateway(s) that serve those prefixes. Full
support is not required to glean this information. A host that support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this passively observes routing protocol traffic may deduce this
information without supporting a fully conformant routing protocol information without supporting a fully conformant routing protocol
implementation. implementation.
2.2. Reachability Test 2.2. Reachability Test
If the host has a valid routable IPv4 address on the MLPA, a host If the host has an operable routable IPv4 address on the MLAN, a host
conforming to this specification SHOULD perform a reachability test, conforming to this specification SHOULD perform a reachability test,
in order to to confirm that it is connected to network on which it in order to to confirm that it is connected to network on which it
has a valid routable IPv4 address. If the reachability test is not has an operable routable IPv4 address. If the reachability test is
successful, the host proceeds to the IPv4 address acquisition phase, not successful, the host proceeds to the IPv4 address acquisition
described in Section 2.3. phase, described in Section 2.3.
The host skips the reachability test and proceeds to the IPv4 address The host skips the reachability test and proceeds to the IPv4 address
acquisition phase if any of the following conditions are true: acquisition phase if any of the following conditions are true:
[a] The host does not have a valid routable IPv4 [a] The host does not have an operable routable IPv4
address on the MLPA. In this case, the reachability address on the MLAN. In this case, the reachability
test cannot confirm that the host has a valid test cannot confirm that the host has an operable
routable IPv4 address, so that completing the routable IPv4 address, so that completing the
reachability test would serve no purpose. reachability test would serve no purpose.
A host MUST NOT use the reachability test to
confirm configuration of an IPv4 Link-Local
address.
[b] The host does not have information on the default [b] The host does not have information on the default
gateway(s) on the MLPA. In this case, insufficient gateway(s) on the MLAN. In this case, insufficient
information is available to carry out the reachability information is available to carry out the reachability
test. test.
[c] Reliable hints are unavailable. Since confirming [c] Reliable hints are unavailable. Since confirming
failure of the reachability test requires a timeout, failure of the reachability test requires a timeout,
mistakes are costly. In the absence of reliable mistakes are costly. In the absence of reliable
hints, a host SHOULD instead send a DHCPREQUEST from hints, a host SHOULD instead send a DHCPREQUEST from
the INIT-REBOOT state, as described in [RFC2131], the INIT-REBOOT state, as described in [RFC2131],
Section 3.2 and 4.3.2. Where reliable hints are Section 3.2 and 4.3.2. Where reliable hints are
unavailable, this will typically complete more unavailable, this will typically complete more
quickly than the reachability test. quickly than the reachability test.
[d] If secure detection of network attachment is required. [d] If secure detection of network attachment is required.
The reachability test utilizes ARP which is insecure, The reachability test utilizes ARP which is insecure,
whereas DHCPv4 can be secured via DHCPv4 authentication, whereas DHCPv4 can be secured via DHCPv4 authentication,
described in [RFC3118]. See Section 5 for details. described in [RFC3118]. See Section 5 for details.
The host MAY probe only the primary default gateway, or it MAY probe [e] If the default gateway address is an IPv4 Link-Local
primary and secondary default gateways in series or in parallel. In address. In this case, it is possible that the
order to ensure configuration validity, the host SHOULD only reachability test could be misinterpreted as
configure default gateway(s) which pass the reachability test. indication of an address conflict. See [RFC3927]
Section 2.2.1 for details.
The host MAY test the reachability of the primary default gateway, or
it MAY test reachability of the primary and secondary default
gateways in series or in parallel. In order to ensure configuration
validity, the host SHOULD only configure default gateway(s) which
pass the reachability test.
2.2.1. Packet Format 2.2.1. Packet Format
The reachability test is performed by sending an ARP Request. The The reachability test is performed by sending an ARP Request. The
ARP Request SHOULD use the host's MAC address as the source, and the ARP Request SHOULD use the host's MAC address as the source, and the
broadcast MAC address as the destination. The host sets the target broadcast MAC address as the destination. The host sets the target
protocol address (ar$tpa) to the IPv4 address of the primary default protocol address (ar$tpa) to the IPv4 address of the default gateway
gateway, and uses its own MAC address in the sender hardware address being tested, and uses its own MAC address in the sender hardware
field (ar$sha). The host sets the target hardware address field address field (ar$sha). The host sets the target hardware address
(ar$tha) to 0. field (ar$tha) to 0.
If the host has a private address as defined in [RFC1918], then it If the host has an operable routable IPv4 address other than a
SHOULD set the sender protocol address field (ar$spa) to the private address on the MLAN, then it SHOULD set the sender protocol
unspecified address (0.0.0.0). This is to avoid a potential address address field (ar$spa) to that address. It is assumed that the host
conflict when the host changes its point of attachment from one had previously done duplicate address detection so that an address
private network to another. conflict is unlikely.
Note: Some routers may refuse to answer an ARP Request sent with If the host has a private address as defined in [RFC1918], then it
the sender protocol address field (ar$spa) set to the unspecified SHOULD send an ARP Probe, setting the sender protocol address field
address (0.0.0.0). In this case the reachability test will fail. (ar$spa) to the unspecified address (0.0.0.0). This is to avoid a
potential address conflict when the host changes its attachment
network from one private network to another.
If the host has a valid routable IPv4 address other than a private Note: Some routers may refuse to answer an ARP Probe, in which
address on the MLPA, then it SHOULD set the sender protocol address case the reachability test will fail. A host also may encounter a
field (ar$spa) to that address. It is assumed that the host had router that utilizes ARP Probes for DAD, as described in [ACD].
previously done duplicate address detection so that an address Such routers will not interpret ARP Probes as an indication of an
conflict is unlikely. address conflict, except where they are themselves doing Duplicate
Address Detection (DAD). To avoid triggering conflict detection
on these routers, a host implementing DNAv4 that receives ARP
Probe from a router SHOULD NOT send ARP Probes to that router as
part of the DNAv4 reachability test.
If a valid ARP Response 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) and the IPv4 address in the sender hardware address field (ar$sha) and the IPv4 address in the sender
protocol address field (ar$spa) are matched against the list of protocol address field (ar$spa) are matched against the list of
networks and associated default gateway parameters. If a match is networks and associated default gateway parameters. If a match is
found, then if the host has a valid routable IPv4 address on the found, then if the host has an operable routable IPv4 address on the
matched network, the host continues to use that IPv4 address, subject matched network, the host continues to use that IPv4 address, subject
to the lease re-acquisition and expiration behavior described in to the lease re-acquisition and expiration behavior described in
[RFC2131], Section 4.4.5. [RFC2131], Section 4.4.5.
Checking for a match on both the IPv4 address and MAC address of the Checking for a match on both the IPv4 address and MAC address of the
default gateway enables the host to confirm reachability even where default gateway enables the host to confirm reachability even where
it has moved between two private networks. In this case the IPv4 it has moved between two private networks. In this case the IPv4
address of the default gateway could remain the same, while the MAC address of the default gateway could remain the same, while the MAC
address would change, so that both addresses need to be checked. address would change, so that both addresses need to be checked.
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
Duplicate Address Detection on the former network does not provide Duplicate Address Detection on the former network does not provide
assurance against an address conflict on the new network. Until a assurance against an address conflict on the new network. Until a
host with a private address has confirmed the validity of its IPv4 host with a private address has confirmed the operability of its IPv4
configuration, it SHOULD NOT respond to ARP requests, and SHOULD NOT configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT
send ARP requests containing its address within the sender protocol send ARP Requests containing its address within the sender protocol
address field (ar$spa). Instead it SHOULD use the unspecified address field (ar$spa). Instead it SHOULD use the unspecified
address, as described above. However, where the host has a valid address, as described above. However, where the host has an operable
routable non-private address on the MLPA, it MAY send ARP requests routable non-private address on the MLAN, it MAY send ARP Requests
using its address within the sender protocol address field (ar$spa) using its address within the sender protocol address field (ar$spa)
prior to confirming its IPv4 configuration, and MAY respond to ARP prior to confirming its IPv4 configuration, and MAY respond to ARP
requests. Requests.
Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
address does not provide the same level of assurance since this may address does not provide the same level of assurance since this may
require an ARP Request/Response exchange. Where the host has moved require an ARP Request/Reply exchange. Where the host has moved
between two private networks, this could result in ARP cache between two private networks, this could result in ARP cache
pollution. pollution.
Where a host moves from one private network to another, an ICMP Echo Where a host moves from one private network to another, an ICMP Echo
Request can result in an ICMP Echo Response even when the default Request can result in an ICMP Echo Response even when the default
gateway has changed, as long as the IPv4 address remains the same. gateway has changed, as long as the IPv4 address remains the same.
This can occur, for example, where a host moves from one home This can occur, for example, where a host moves from one home
network using prefix 192.168/16 to another one. In addition, if the network using prefix 192.168/16 to another one. In addition, if the
ping is sent with TTL > 1, then an ICMP Echo Response can be received ping is sent with TTL > 1, then an ICMP Echo Response can be received
from an off-link gateway. As a result, if the MAC address of the from an off-link gateway. As a result, if the MAC address of the
default gateway is not checked, the host can mistakenly confirm default gateway is not checked, the host can mistakenly confirm
attachment to the MLPA, potentially resulting in an address conflict. attachment to the MLAN, potentially resulting in an address conflict.
As a result, sending of an ICMP Echo Request SHOULD NOT be used as a As a result, sending of an ICMP Echo Request SHOULD NOT be used as a
substitute for the DNAv4 procedure. substitute for the DNAv4 procedure.
If the initial ARP Request does not elicit a Response, the host waits If the initial ARP Request does not elicit a response, the host waits
for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition
phase. If a valid ARP Response is received, but cannot be matched phase. If a valid ARP Reply is received, but cannot be matched
against known networks, the host assumes it does not have a valid against known networks, the host assumes it does not have an operable
IPv4 configuration and moves on to the IPv4 address acquisition IPv4 configuration and moves on to the IPv4 address acquisition
phase. phase.
2.3. IPv4 Address Acquisition 2.3. IPv4 Address Acquisition
If the host has a valid routable IPv4 address on the MLPA but the If the host has an operable routable IPv4 address on the MLAN but the
reachability test fails, the host SHOULD verify the configuration by reachability test fails, the host SHOULD verify the configuration 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 [RFC2131] Section 4.4.2. broadcast address as specified in [RFC2131] Section 4.4.2.
If the host does not have a valid routable IPv4 address on the MLPA, If the host does not have an operable routable IPv4 address on the
the host enters the INIT state and sends a DHCPDISCOVER packet to the MLAN, the host enters the INIT state and sends a DHCPDISCOVER packet
broadcast address, as described in [RFC2131] Section 4.4.1. If the to the broadcast address, as described in [RFC2131] Section 4.4.1.
host supports the Rapid Commit Option [RFC4039], it is possible that If the host supports the Rapid Commit Option [RFC4039], it is
the exchange can be shortened from a 4-message exchange to a possible that the exchange can be shortened from a 4-message exchange
2-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 [RFC2131] Section DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
4.1. 4.1.
As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING
state that knows the address of a DHCP server may use that address in state that knows the address of a DHCP server may use that address in
the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast
address. In the INIT-REBOOT state a DHCPREQUEST is sent to the address. In the INIT-REBOOT state a DHCPREQUEST is sent to the
broadcast address so that the host will receive a response regardless broadcast address so that the host will receive a response regardless
skipping to change at page 9, line 50 skipping to change at page 10, line 50
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.4. IPv4 Link-Local Addresses 2.4. IPv4 Link-Local Addresses
To avoid inappropriate assignment of IPv4 Link-Local addresses, it is To avoid inappropriate assignment of IPv4 Link-Local addresses, it is
recommended that hosts behave conservatively with respect to recommended that hosts behave conservatively, assigning them only
assignment of IPv4 Link-Local addresses. As described in [RFC3927] when they can do no harm. As described in [RFC3927] Section 1.7, use
Section 1.7, use of a routable address is preferred to a IPv4 Link- of a routable address is preferred to a IPv4 Link-Local address
Local address whenever it is available. whenever it is available.
Where the host does not have a valid routable IPv4 address on the Where the host does not have an operable routable IPv4 address on the
MLPA, the host MAY configure an IPv4 Link-Local address prior to MLAN, 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. However, should a routable IPv4 address be described in Section 2.3. However, should a routable IPv4 address be
obtained, the IPv4 Link-Local address is deprecated, as noted in obtained, the IPv4 Link-Local address is deprecated, as noted in
[RFC3927]. [RFC3927].
Where a host has a valid routable IPv4 address on the MLPA, but the Where a host has an operable routable IPv4 address on the MLAN, but
DHCP client does not receive a response after employing the the DHCP client does not receive a response after employing the
retransmission algorithm, [RFC2131] Section 3.2 states that the retransmission algorithm, [RFC2131] Section 3.2 states that the
client MAY choose to use the previously allocated network address and client MAY choose to use the previously allocated network address and
configuration parameters for the remainder of the unexpired lease. configuration parameters for the remainder of the unexpired lease.
Where a host can confirm that it remains connected to a point of Where a host can confirm that it remains connected to a point of
attachment on which it possesses a valid routable IPv4 address, that attachment on which it possesses an operable routable IPv4 address,
address SHOULD be used, rather than assigning a IPv4 Link-Local that address SHOULD be used, rather than assigning a IPv4 Link-Local
address. address.
Since a IPv4 Link-Local address is often configured because a DHCP Since a IPv4 Link-Local address is often configured because a DHCP
server failed to respond to an initial query or is inoperative for server failed to respond to an initial query or is inoperative for
some time, it is desirable to abandon the IPv4 Link-Local address some time, it is desirable to abandon the IPv4 Link-Local address
assignment as soon as a valid IPv4 address lease can be obtained. assignment as soon as an IPv4 address lease can be obtained.
As described in [RFC3927] Appendix A, once a Link-Local IPv4 address As described in [RFC3927] Appendix A, once a Link-Local IPv4 address
is assigned, existing implementations do not query the DHCPv4 server is assigned, existing implementations do not query the DHCPv4 server
again for 5 minutes. This behavior violates [RFC2131] Section 4.1. again for 5 minutes. This behavior violates [RFC2131] Section 4.1.
Where a IPv4 Link-Local address is assigned, experience has shown Where a IPv4 Link-Local address is assigned, experience has shown
that five minutes (see [RFC3927] Appendix A.2) is too long an that five minutes (see [RFC3927] Appendix A.2) is too long an
interval to wait until retrying to obtain a routable IPv4 address interval to wait until retrying to obtain a routable IPv4 address
using DHCP. According to [RFC2131] Section 4.1: using DHCP. According to [RFC2131] Section 4.1:
skipping to change at page 11, line 21 skipping to change at page 12, line 20
value was chosen so as to accommodate the maximum retransmission value was chosen so as to accommodate the maximum retransmission
timer likely to be experienced on an Ethernet network. timer likely to be experienced on an Ethernet network.
4. IANA Considerations 4. IANA Considerations
This specification does not request the creation of any new parameter This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments. registries, nor does it require any other IANA assignments.
5. Security Considerations 5. Security Considerations
Detection of Network Attachment (DNA) is based on ARP and DHCP. ARP Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and
[RFC826] traffic is inherently insecure, so that the reachability DHCP and inherits the security vulnerabilities of these two
test described in Section 1.3 can be easily spoofed by an attacker, protocols.
leading a host to falsely conclude that it is attached to a network
that it is not connected to. Similarly, where DHCP traffic is not
secured, an attacker could masquerade as a DHCP server, in order to
convince the host that it was attached to a particular network.
As a result, it is inadvisable for a host to adjust its security ARP [RFC826] traffic is not secured, so that an attacker gaining
based on which network it believes it is attached to. For example, access to the network can spoof a response to the reachability test
it would be inappropriate for a host to disable its personal firewall described in Section 2.2, leading the querier to falsely conclude
based on the belief that it had connected to a home network. that it is attached to a network that it is not connected to.
Where secure detection of network attachment is required, a host Similarly, where DHCPv4 traffic is not secured, an attacker could
SHOULD skip the reachability test since it cannot be secured, and masquerade as a DHCPv4 server, in order to convince the host that it
instead utilize authenticated DHCP [RFC3118], possibly in combination was attached to a particular network. This and other threats
with the Rapid Commit Option [RFC4039]. relating to DHCPv4 are described in "Authentication for DHCP
Messages" [RFC3118].
The effect of these attacks will typically be limited to denial of
service, unless the host utilizes its IP configuration for other
purposes, such as security configuration or location determination.
For example, a host that disables its personal firewall based on
evidence that it had attached to a home network could be compromised
by spoofing of the DNAv4 reachability test. In general, adjustment
of the security configuration based on DNAv4 is NOT RECOMMENDED.
Hosts that depend on secure IP configuration SHOULD NOT use DNAv4,
but SHOULD instead utilize DHCP authentication [RFC3118], possibly in
combination with the Rapid Commit Option [RFC4039].
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
USC/Information Sciences Institute, September 1981. USC/Information Sciences Institute, September 1981.
[RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or-
Converting Network Addresses to 48-bit Ethernet Address for Converting Network Addresses to 48-bit Ethernet Address for
skipping to change at page 12, line 18 skipping to change at page 13, line 30
[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", 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.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", RFC 3927, March 2005. of IPv4 Link-Local Addresses", RFC 3927, May 2005.
6.2. Informative References 6.2. Informative References
[ACD] Cheshire, S., "IPv4 Address Conflict Detection", draft-
cheshire-ipv4-acd-03.txt, Internet draft (work in progress),
December 2002.
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, Daydreamer, July 1994. 51, RFC 1661, Daydreamer, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and
E. Lear, "Address Allocation for Private Internets", RFC 1918, E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996. February 1996.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
skipping to change at page 13, line 34 skipping to change at page 14, line 50
contributions to this document. contributions to 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 EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 818 4011
Fax: +1 425 936 7329 Fax: +1 425 936 7329
Appendix A - Link Layer Hints Appendix A - Link Layer Hints
A.1 Introduction A.1 Introduction
In order to assist in IPv4 network attachment detection, information In order to assist in detecting network attachment, information
associated with each network may be retained by the host. Based on associated with each network may be retained by the host. Based on
link-layer information, the host may be able to make an educated link-layer information, the host may be able to make an educated
guess as to whether it has moved between subnets, or has remained on guess as to whether it has moved between subnets, or has remained on
the same subnet, as well as whether it has connected to an the same subnet, as well as whether it has connected to an
infrastructure or adhoc network. infrastructure or adhoc network.
If the host is likely to have moved between subnets, it may be If the host is likely to have moved between subnets, it may be
possible to make an educated guess as to which subnet it has moved possible to make an educated guess as to which subnet it has moved
to. Since an educated guess may be incorrect, prior to concluding to. Since an educated guess may be incorrect, prior to concluding
that the host remains on the same subnet, further tests (such as a that the host remains on the same subnet, further tests (such as a
skipping to change at page 14, line 35 skipping to change at page 15, line 35
is substantial. is substantial.
As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME to As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME to
determine if a host has remained on the same subnet, while a determine if a host has remained on the same subnet, while a
reachability test typically completes in REACH_TIME and times out in reachability test typically completes in REACH_TIME and times out in
REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent. REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent.
If a hint that the host has remained on the same subnet is wrong x If a hint that the host has remained on the same subnet is wrong x
fraction of the time, then it is only worth considering if: fraction of the time, then it is only worth considering if:
DHCPREQUEST_TIME = (1 - x) * REACH_TIME + DHCPREQUEST_TIME > (1 - x) * REACH_TIME +
x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME) x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME)
x = DHCPREQUEST_TIME - REACH_TIME x < DHCPREQUEST_TIME - REACH_TIME
---------------------------------------------------- ----------------------------------------------------
REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME
If we assume that DHCPREQUEST_TIME = 100 ms, REACH_TIME = 10 ms, and If we assume that DHCPREQUEST_TIME = 50 ms, REACH_TIME = 10 ms, and
REACHABILITY_TIMEOUT = 1000ms, then: REACHABILITY_TIMEOUT = 200ms, then:
x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent x < (50 - 10)/(200 + 50 - 10) = 16.67 percent
Therefore the hint need only be wrong 8.2 percent of the time before In this example, if the hint is wrong more than one sixth of the
it is not worth considering. time, it is not worth considering.
A.2 Hints A.2 Hints
For networks running IPv4 over PPP [RFC1661], IPv4 parameters For networks running IPv4 over PPP [RFC1661], IPv4 parameters
negotiated in IPCP provide direct information on whether a previously negotiated in IPCP provide direct information on whether a previously
obtained address remains valid on the link. obtained address remains operable on the link.
On media supporting EAP [RFC3748], network identification information On media supporting EAP [RFC3748], network identification information
may be passed within the EAP-Request/Identity or within an EAP method may be passed within the EAP-Request/Identity or within an EAP method
exchange. For example, the EAP-Request/Identity may contain the name exchange. For example, the EAP-Request/Identity may contain the name
of the authenticator. During the EAP method exchange the of the authenticator. During the EAP method exchange the
authenticator may supply information that may be helpful in authenticator may supply information that may be helpful in
identifying the network to which the device is attached. However, identifying the network to which the device is attached. However,
as noted in [RFC3580], it is possible for the VLANID defined in as noted in [RFC3580], it is possible for the VLANID defined in
[IEEE-802.1Q] to be assigned dynamically, so that static [IEEE-802.1Q] to be assigned dynamically, so that static
advertisements may not prove definitive. advertisements may not prove definitive.
skipping to change at page 15, line 32 skipping to change at page 16, line 32
Link Layer Discovery Protocol (LLDP) defined in [IEEE-802.1AB]. LLDP Link Layer Discovery Protocol (LLDP) defined in [IEEE-802.1AB]. LLDP
advertisements can include the chassis ID, which represents the advertisements can include the chassis ID, which represents the
authenticator's chassis identification, enabling a host to determine authenticator's chassis identification, enabling a host to determine
if it has attached to a previously encountered device. However, if it has attached to a previously encountered device. However,
since a device may support dynamic VLANs, re-attachment does not since a device may support dynamic VLANs, re-attachment does not
necessarily imply that the VLAN has remained the same, although this necessarily imply that the VLAN has remained the same, although this
is likely. is likely.
LLDP also enables advertisement of the port's VLAN identifier, as LLDP also enables advertisement of the port's VLAN identifier, as
well as a VLAN name, allowing the host to determine whether it has well as a VLAN name, allowing the host to determine whether it has
attached to a VLAN on which it had previously obtained a valid attached to a VLAN on which it had previously obtained an operable
configuration. Since such an advertisement cannot be heard until IPv4 configuration. Since such an advertisement cannot be heard
802.1X authentication has completed, the advertised VLAN will reflect until 802.1X authentication has completed, the advertised VLAN will
a dynamic VLAN assignment if one has been made, so that it is likely reflect a dynamic VLAN assignment if one has been made, so that it is
to be definitive. likely to be definitive.
In IEEE 802.11 [IEEE-802.11] stations provide information in Beacon In IEEE 802.11 [IEEE-802.11] stations provide information in Beacon
and/or Probe Response messages, such as the SSID, BSSID, and and/or Probe Response messages, such as the SSID, BSSID, and
capabilities, as well as information on whether the station is capabilities, as well as information on whether the station is
operating in Infrastructure or Ad hoc mode. As described in operating in Infrastructure or Ad hoc mode. As described in
[RFC3580], it is possible to assign a Station to a VLAN dynamically, [RFC3580], it is possible to assign a Station to a VLAN dynamically,
based on the results of IEEE 802.1X [IEEE-802.1X] authentication. based on the results of IEEE 802.1X [IEEE-802.1X] authentication.
This implies that a single SSID may offer access to multiple VLANs, This implies that a single SSID may offer access to multiple VLANs,
and in practice most large WLAN deployments offer access to multiple and in practice most large WLAN deployments offer access to multiple
subnets. subnets. While a Station associating to the same SSID may not remain
within the same subnet, a Station associating to a different SSID is
Thus, associating to the same SSID is a necessary, but not likely to have changed subnets.
necessarily a sufficient condition, for remaining within the same
subnet: while a Station associating to the same SSID may not
necessarily remain within the same subnet, a Station associating to a
different SSID is likely to have changed subnets.
In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such
as "default", "linksys" and "tsunami" are often configured by as "default", "linksys" and "tsunami" are often configured by
manufacturers by default. As a result, matching an advertised SSID manufacturers by default. As a result, matching an advertised SSID
against those of previously encountered networks may be misleading. against those of previously encountered networks may be misleading.
Where an SSID known to be configured by default is encountered, it is Where an SSID known to be configured by default is encountered, it is
recommended that the BSSID be stored and subsequently compared recommended that the BSSID be stored and subsequently compared
against the advertised BSSID to determine whether a match exists. against the advertised BSSID to determine whether a match exists.
In order to provide additional guidance on the subnets to which a In order to provide additional guidance on the subnets to which a
given AP offers access, additional subnet-related Information given AP offers access, additional subnet-related Information
Elements (IEs) have been proposed for addition to the IEEE 802.11 Elements (IEs) have been proposed for addition to the IEEE 802.11
Beacon and Probe Response messages. As noted earlier, VLANs may be Beacon and Probe Response messages. As noted earlier, VLANs may be
determined dynamically so that these information elements may not be determined dynamically so that these information elements may not be
reliable. reliable.
In IEEE 802.11, the presence of an IBSS can be used as a hint that a In IEEE 802.11, the presence of an IBSS can be used as a hint that a
point of attachment supports adhoc networking, and therefore that link supports adhoc networking, and therefore that assignment of a
assignment of a IPv4 Link-Local address is likely. When running IPv4 IPv4 Link-Local address is likely. When running IPv4 over PPP, if an
over PPP, if an IPv4 address is not statically configured or IPv4 address is not statically configured or assigned via IPv4CP,
assigned via IPv4CP, this can also be taken as a hint that assignment this can also be taken as a hint that assignment of an IPv4 Link-
of an IPv4 Link-Local address is likely. In addition, certain media Local address is likely. Media such as USB or IEEE 1394 may be
such as USB or IEEE 1394 may be considered inherently more likely to considered inherently more likely to support adhoc operation, so that
support adhoc operation, so that connection to these networks may by attachment to these media may by itself be considered a hint.
itself be considered a hint.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any 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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
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.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
http://www.drizzle.com/~aboba/DNA/dnaissues.html http://www.drizzle.com/~aboba/DNA/
 End of changes. 

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