draft-ietf-dhc-dna-ipv4-08.txt   draft-ietf-dhc-dna-ipv4-09.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-08.txt> <draft-ietf-dhc-dna-ipv4-09.txt>
18 July 2004 14 October 2004
Detection of Network Attachment (DNA) in IPv4 Detection of Network Attachment (DNA) in IPv4
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 31 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 January 2, 2005. This Internet-Draft will expire on April 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The time required to detect movement (or lack of movement) between The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may subnets, and to obtain (or continue to use) a valid IPv4 address may
be significant as a fraction of the total delay in moving between be significant as a fraction of the total delay in moving between
points of attachment. This document synthesizes experience garnered points of attachment. This document synthesizes experience garnered
over the years in the deployment of hosts supporting ARP, DHCP and over the years in the deployment of hosts supporting ARP, DHCP and
Link-Local IPv4 addresses. A procedure is specified for detection of IPv4 Link-Local addresses. A procedure is specified for detection of
network attachment in order to better accommodate mobile hosts. network attachment in order to better accommodate mobile hosts.
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. Framework ................................................ 4 2. Framework ................................................ 4
2.1 Most Likely Point of Attachment ................. 5 2.1 Most Likely Point of Attachment ................. 5
2.2 Reachability Test ............................... 6 2.2 Reachability Test ............................... 6
2.3 IPv4 Address Acquisition ........................ 8 2.3 IPv4 Address Acquisition ........................ 8
2.4 Link-Local IPv4 Addresses ....................... 9 2.4 IPv4 Link-Local Addresses ....................... 9
3. Constants ................................................ 10 3. Constants ................................................ 10
4. IANA Considerations ...................................... 10 4. IANA Considerations ...................................... 10
5. Security Considerations .................................. 10 5. Security Considerations .................................. 10
6. References ............................................... 11 6. References ............................................... 11
6.1 Normative references ............................ 11 6.1 Normative references ............................ 11
6.2 Informative references .......................... 11 6.2 Informative references .......................... 11
Acknowledgments .............................................. 12 Acknowledgments .............................................. 12
Authors' Addresses ........................................... 12 Authors' Addresses ........................................... 12
Appendix A - Link Layer Hints ................................ 13 Appendix A - Link Layer Hints ................................ 13
A.1 Introduction .................................... 13 A.1 Introduction .................................... 13
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1. Introduction 1. Introduction
The time required to detect movement (or lack of movement) between The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may subnets, and to obtain (or continue to use) a valid IPv4 address may
be significant as a fraction of the total delay in moving between be significant as a fraction of the total delay in moving between
points of attachment. As a result, optimizing detection of network points of attachment. As a result, optimizing detection of network
attachment is important for mobile hosts. attachment is important for mobile hosts.
This document synthesizes experience in the deployment of hosts This document synthesizes experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4 supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [IPv4LL], specifying a procedure to be performed for IPv4 addresses [IPv4LL], specifying a procedure to be performed for IPv4
detection of network attachment. The procedure consists of three detection of network attachment. The procedure consists of three
phases: determination of the Most Likely Point of Attachment (MLPA), phases: determination of the Most Likely Point of Attachment (MLPA),
reachability testing, and IPv4 address acquisition. reachability testing, and IPv4 address acquisition.
Since this procedure is dependent on the ARP protocol, it is not Since this procedure is dependent on the ARP protocol, it is not
suitable for use on media that do not support ARP [RFC826]. 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. These words are often capitalized. The key of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document and "OPTIONAL" in this document are to be interpreted as described in
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
skipping to change at page 4, line 6 skipping to change at page 4, line 6
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, or the broadcast
address if the target hardware address is unknown. 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.
DHCP client DHCP client
A DHCP client or "client" is an Internet host using DHCP to obtain A DHCP client or "client" is an Internet host using the Dynamic
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 Point of Attachment
A location within the network where a host may be connected. This A location within the network where a host may be connected. This
attachment point can be characterized by its address prefix and attachment point can be characterized by its address prefix and
next hop routing information. next hop routing information.
Most Likely Point of Attachment (MLPA) Most Likely Point of Attachment (MLPA)
The point of attachment heuristically determined by the host to be The point of attachment heuristically determined by the host to be
most likely, based on hints from the network. most likely, based on hints from the network.
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 Link-Local IPv4 address. This includes address other than an IPv4 Link-Local address. This includes
private addresses as specified in [RFC1918]. private addresses as specified in [RFC1918].
Valid address Valid address
In this specification, the term "valid address" refers to either a In this specification, the term "valid address" refers to either a
static IPv4 address, or an address assigned via DHCPv4 which has 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. Framework 2. Framework
For Detection of Network attachment, the following basic principles For Detection of Network Attachment (DNA), the following basic
are suggested: principles are suggested:
[a] Utilization of hints. Link layers such as IEEE 802 [a] Utilization of hints. As described in Appendix A,
[IEEE802] provide hints whether a host remains link layers may provide hints as to whether a
on the same subnet despite changing its point of host remains on the same subnet, despite changing
attachment, or whether a host is connected to an its point of attachment. Based on these hints,
ad hoc or infrastructure network. Prior to connecting the host determines the "Most Likely Point of
to a new point of attachment, the host uses available Attachment" (MLPA), and the corresponding
hints to determine the "most likely" configuration configuration associated with it. Since
associated with the new point of attachment. Since hints may be misleading, it is important for
hints are not infallible, the host should be capable of the host to make the correct determination even
making the correct determination even in the presence of where hints are misleading.
misleading hints. For details see Appendix A.
[b] Treatment of link-up indications. On connecting [b] Response to "Link Up" indications. On connecting
to a new point of attachment, the host attempts to to a new point of attachment, the host attempts to
verify the "most likely" configuration associated verify the configuration associated with the MLPA.
with the new point of attachment.
[c] Handling of Link-Local IPv4 addresses. Experience has [c] Handling of IPv4 Link-Local addresses. Experience has
shown that Link-Local IPv4 addresses are often assigned shown that IPv4 Link-Local addresses are often assigned
inappropriately. This document suggests that hosts inappropriately. This document suggests that hosts
behave conservatively with respect to assignment of behave conservatively with respect to assignment of
Link-Local IPv4 addresses, configuring them only in IPv4 Link-Local addresses, configuring them only in
situations in which they can do no harm. situations in which they can do no harm.
2.1. Most Likely Point of Attachment 2.1. Most Likely Point of Attachment
In order to determine the MLPA, it is assumed that the host is In order to determine the MLPA, it is assumed that the host saves to
capable of obtaining and writing to stable storage parameters stable storage parameters relating to the networks it connects to:
relating to networks that it connects to, including:
[1] Link layer hints associated with each network. [1] Link layer hints associated with each network.
For details, see Appendix A. 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] Whether a network is an infrastructure or adhoc network. [3] The link type, such as whether the link utilizes
Ethernet, or 802.11 adhoc or infrastructure mode.
By matching the received hints against information previously By matching received hints against network parameters previously
collected, the host may be able to make an educated guess of which stored, the host makes an an educated guess of which network it has
network it has attached to. In the absence of other information, by attached to. In the absence of other information, the MLPA defaults
default the host may assume that the MLPA is the network to which it to the network to which the host was most recently attached.
was most recently attached.
2.1.1. Alternative Mechanisms 2.1.1. Alternative Mechanisms
Aside from utilizing link layer hints, a host may also be able to Aside from utilizing link layer indications, a host may also be able
utilize Internet layer information in order to determine the MLPA. to utilize Internet layer information in order to determine the MLPA.
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, in general, it is However, since [RFC1256] is not widely implemented, in general, it is
NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as
an alternative to the reachability test outlined in Section 2.2. an alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain information Instead, ICMP Router Advertisements can be used to obtain information
on available prefixes and default gateway(s). This can provide on available prefixes and default gateway(s). This can provide
additional resilience in the case where default gateway(s) become additional resilience in the case where default gateway(s) become
unavailable. unavailable.
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. Note that link and the default gateway(s) that serve those prefixes. Full
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 full conforming implementation of information without supporting a fully conformant routing protocol
the routing protocol. implementation.
2.2. Reachability Test 2.2. Reachability Test
If the host has a valid routable IPv4 address on the MLPA, the host If the host has a valid routable IPv4 address on the MLPA, the host
will typically perform a reachability test, in order to to confirm SHOULD perform a reachability test, in order to to confirm that it is
that the host is connected to a network on which it has a valid connected to network on which it has a valid routable IPv4 address.
routable IPv4 address. If the reachability test is not successful, If the reachability test is not successful, the host proceeds to the
the host proceeds to the IPv4 address acquisition phase, described in IPv4 address acquisition phase, described in Section 2.3.
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 a valid routable IPv4
address on the MLPA. In this case, the reachability address on the MLPA. In this case, the reachability
test cannot confirm that the host has a valid test cannot confirm that the host has a valid
routable IPv4 address, so that it is unnecessary. routable IPv4 address, so that completing the
reachability test would serve no purpose.
[b] The host does not have information on the default [b] The host does not have information on the default
gateway(s) for the MLPA. In this case, it is not gateway(s) on the MLPA. In this case, insufficient
possible to carry out the reachability test. information is available to carry out the reachability
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 on average 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 DHCP can be secured via DHCP authentication, whereas DHCP can be secured via DHCP authentication,
described in [RFC3118]. See Section 5 for details. described in [RFC3118]. See Section 5 for details.
The reachability test is performed by attempting to verify In contrast to a DHCP exchange, which may be between a DHCP client
reachability of default gateway(s) on the MLPA. This reduces roaming and an off-link DHCP server, the reachability test is designed to
latency by allowing the host to bypass DHCP as well as subsequent verify bi-directional connectivity to the default gateway(s) on the
Duplicate Address Detection (DAD). In contrast to a DHCP exchange, MLPA.
which may be between a DHCP client and an off-link DHCP server, the
reachability test occurs between a host and its next hop router.
The host may probe only the primary default gateway, or it may probe The host MAY probe only the primary default gateway, or it MAY probe
primary and secondary default gateways, in series or in parallel. If primary and secondary default gateways, in series or in parallel. If
the reachability test is successful, the host may continue to use a the reachability test is successful, the host MAY continue to use a
valid routable IPv4 address without having to re-acquire it. valid routable IPv4 address without having to re-acquire it. This
However, in order to ensure configuration validity, the host SHOULD reduces roaming latency by allowing the host to bypass DHCP as well
only configure default gateway(s) which pass the reachability test. as subsequent Duplicate Address Detection (DAD). 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 primary default
gateway, and uses its own MAC address in the sender hardware address gateway, and uses its own MAC address in the sender hardware address
field (ar$sha). The host sets the target hardware address field field (ar$sha). The host sets the target hardware address field
(ar$tha) to 0. (ar$tha) to 0.
skipping to change at page 7, line 48 skipping to change at page 7, line 48
If a valid ARP Response is received, the MAC address in the sender If a valid ARP Response 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 a valid 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 allows the host to confirm reachability even where default gateway enables the host to confirm reachability even where
the host moves 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.
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 address does not provide the same level of assurance since this
requires an ARP Request/Response to be sent first, and typically does requires an ARP Request/Response to be sent first, and typically does
not allow the MAC address to be checked as well. It therefore SHOULD not allow the MAC address to be checked as well. It therefore SHOULD
NOT be used as a substitute. NOT be used as a substitute.
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
skipping to change at page 8, line 28 skipping to change at page 8, line 28
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 Response is received, but cannot be matched
against known networks, the host assumes it has moved subnets and against known networks, the host assumes it has moved subnets and
moves on to the IPv4 address acquisition phase. moves on to the IPv4 address acquisition 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 a valid routable IPv4 address on the MLPA but the
reachability test fails, then the host SHOULD verify the reachability test fails, the host SHOULD verify the configuration by
configuration by entering the INIT-REBOOT state, and sending a entering the INIT-REBOOT state, and sending a DHCPREQUEST to the
DHCPREQUEST to the broadcast address as specified in [RFC2131] broadcast address as specified in [RFC2131] Section 4.4.2.
Section 4.4.2.
If the host does not have a valid routable IPv4 address on the MLPA, If the host does not have a valid routable IPv4 address on the MLPA,
the host enters the INIT state and sends a DHCPDISCOVER packet to the the host enters the INIT state and sends a DHCPDISCOVER packet to the
broadcast address, as described in [RFC2131] Section 4.4.1. If the broadcast address, as described in [RFC2131] Section 4.4.1. If the
host supports the Rapid Commit Option [RAPID], it is possible that host supports the Rapid Commit Option [RAPID], it is possible that
the exchange can be shortened from a 4-message exchange to a the exchange can be shortened from a 4-message exchange to a
2-message exchange. 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
skipping to change at page 9, line 9 skipping to change at page 9, line 8
broadcast address so that the host will receive a response regardless broadcast address so that the host will receive a response regardless
of whether the previously configured IPv4 address is correct for the of whether the previously configured IPv4 address is correct for the
network to which it has connected. 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.4. Link-Local IPv4 Addresses 2.4. IPv4 Link-Local Addresses
To avoid inappropriate assignment of Link-Local IPv4 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 with respect to
assignment of Link-Local IPv4 addresses. As described in [IPv4LL] assignment of IPv4 Link-Local addresses. As described in [IPv4LL]
Section 1.7, use of a routable address is preferred to a Link-Local Section 1.7, use of a routable address is preferred to a IPv4 Link-
IPv4 address whenever it is available. Local address whenever it is available.
Where the host does not have a valid routable IPv4 address on the Where the host does not have a valid routable IPv4 address on the
MLPA, the host MAY configure an Link-Local IPv4 address prior to MLPA, 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 Link-Local IPv4 address is deprecated, as noted in obtained, the IPv4 Link-Local address is deprecated, as noted in
[IPv4LL]. [IPv4LL].
Where a host has a valid routable IPv4 address on the MLPA, but the Where a host has a valid routable IPv4 address on the MLPA, but the
DHCP client does not receive a response after employing 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 a valid routable IPv4 address, that
address SHOULD be used, rather than assigning a Link-Local IPv4 address SHOULD be used, rather than assigning a IPv4 Link-Local
address. address.
Since a Link-Local IPv4 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 Link-Local IPv4 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 a valid IPv4 address lease can be obtained.
As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address As described in [IPv4LL] 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 is in violation of [RFC2131] again for 5 minutes. This behavior violates [RFC2131] Section 4.1.
Section 4.1.
Where a Link-Local IPv4 address is assigned, experience has shown Where a IPv4 Link-Local address is assigned, experience has shown
that five minutes (see [IPv4LL] Appendix A.2) is too long an interval that five minutes (see [IPv4LL] Appendix A.2) is too long an interval
to wait until retrying to obtain a routable IPv4 address using DHCP. to wait until retrying to obtain a routable IPv4 address using DHCP.
According to [RFC2131] Section 4.1: According to [RFC2131] Section 4.1:
The retransmission delay SHOULD be doubled with The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds. subsequent retransmissions up to a maximum of 64 seconds.
As a result, a DHCP client compliant with [RFC2131] will continue to As a result, a DHCP client compliant with [RFC2131] will continue to
retry every 64 seconds, even after allocating a Link-Local IPv4 retry every 64 seconds, even after allocating a IPv4 Link-Local
address. Should the DHCP client succeed in obtaining a routable address. Should the DHCP client succeed in obtaining a routable
address, then as noted in [IPv4LL], the Link-Local IPv4 address is address, then as noted in [IPv4LL], the IPv4 Link-Local address is
deprecated. deprecated.
Since it is inevitable that hosts will inappropriately configure Since it is inevitable that hosts will inappropriately configure IPv4
Link-Local IPv4 addresses at some point, hosts with routable IPv4 Link-Local addresses at some point, hosts with routable IPv4
addresses SHOULD be able to respond to peers with Link-Local IPv4 addresses SHOULD be able to respond to peers with IPv4 Link-Local
addresses, as per [IPv4LL]. For example, a host configured with a addresses, as per [IPv4LL]. For example, a host configured with a
routable address may receive a datagram from a link-local source routable address may receive a datagram from a link-local source
address. In order to respond, the host will use ARP to resolve the address. In order to respond, the host will use ARP to resolve the
target hardware address and send the datagram directly, not to a target hardware address and send the datagram directly, not to a
router for forwarding. router for forwarding.
3. Constants 3. Constants
The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This
value was chosen so as to accommodate the maximum retransmission value was chosen so as to accommodate the maximum retransmission
skipping to change at page 11, line 29 skipping to change at page 11, line 29
[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.
[IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of Link-Local IPv4 Addresses", Internet draft (work in of IPv4 Link-Local Addresses", RFC 3927, October 2004.
progress), draft-ietf-zeroconf-ipv4-linklocal-17.txt, July
2004.
6.2. Informative References 6.2. Informative References
[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., et al., "Address Allocation for Private [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and
Internets", RFC 1918, February 1996. E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
In User Service (RADIUS) Usage Guidelines", RFC 3580, "IEEE 802.1X Remote Authentication Dial In User Service
September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Aboba, B., et al., "Extensible Authentication Protocol (EAP)", [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
RFC 3748, June 2004. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for [RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
DHCPv4", Internet draft (work in progress), draft-ietf-dhc- DHCPv4", Internet draft (work in progress), draft-ietf-dhc-
rapid-commit-opt-05.txt, June 2004. rapid-commit-opt-05.txt, June 2004.
[IEEE8021AB] [IEEE8021AB]
IEEE Standards for Local and Metropolitan Area Networks: IEEE Standards for Local and Metropolitan Area Networks:
Station and Media Access Control - Connectivity Discovery, Station and Media Access Control - Connectivity Discovery,
IEEE Std 802.1AB/D5, September 2003. IEEE Std 802.1AB/D5, September 2003.
[IEEE8021X] [IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks: Port IEEE Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Std 802.1X-2004, June 2004. based Network Access Control, IEEE Std 802.1X-2004, November
2004.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990. Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021Q] [IEEE8021Q]
IEEE Standards for Local and Metropolitan Area Networks: Draft IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks, P802.1Q, Standard for Virtual Bridged Local Area Networks, P802.1Q,
January 1998. January 1998.
[IEEE80211] [IEEE80211]
skipping to change at page 15, line 14 skipping to change at page 15, line 14
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 point of attachment supports adhoc networking, and therefore that
assignment of a Link-Local IPv4 address is likely. When running IPv4 assignment of a IPv4 Link-Local address is likely. When running IPv4
over PPP, if an IP address is not statically configured or assigned over PPP, if an IP address is not statically configured or assigned
via IPCP, this can also be taken as a hint that assignment of a Link- via IPCP, this can also be taken as a hint that assignment of an IPv4
Local IPv4 address is likely. In addition, certain media such as USB Link-Local address is likely. In addition, certain media such as USB
or IEEE 1394 may be considered inherently more likely to support or IEEE 1394 may be considered inherently more likely to support
adhoc operation, so that connection to these networks may by itself adhoc operation, so that connection to these networks may by itself
be considered a hint. 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 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
 End of changes. 

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