draft-ietf-dhc-dna-ipv4-12.txt   draft-ietf-dhc-dna-ipv4-13.a.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-12.txt> <draft-ietf-dhc-dna-ipv4-13.txt>
3 June 2005 27 June 2005
Detecting 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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
This Internet-Draft will expire on December 10, 2005. This Internet-Draft will expire on December 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. Copyright (C) The Internet Society 2005.
Abstract Abstract
The time required to detect movement between networks, and to obtain The time required to detect movement between networks, and to obtain
(or continue to use) an operable IPv4 configuration may be (or continue to use) an IPv4 configuration may be significant as a
significant as a fraction of the total handover latency in moving fraction of the total handover latency in moving between points of
between points of attachment. This document specifies a procedure attachment. This document synthesizes experience in the deployment
for optimizing detection of network attachment in order to decrease of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses to
the handover latency in moving between points of attachment. define a set of steps known as Detecting Network Attachment for IPv4
(DNAv4), in order to decrease the handover 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 ................................................. 5 2. Overview ................................................. 5
2.1 Most Likely Attachment Network .................. 6 2.1 Most Likely Network ............................. 6
2.2 Reachability Test ............................... 7 2.2 Reachability Test ............................... 6
2.3 IPv4 Address Acquisition ........................ 10 2.3 IPv4 Address Acquisition ........................ 9
2.4 IPv4 Link-Local Addresses ....................... 10 2.4 IPv4 Link-Local Addresses ....................... 10
3. Constants ................................................ 12 3. Constants ................................................ 11
4. IANA Considerations ...................................... 12 4. IANA Considerations ...................................... 11
5. Security Considerations .................................. 12 5. Security Considerations .................................. 11
6. References ............................................... 13 6. References ............................................... 12
6.1 Normative references ............................ 13 6.1 Normative references ............................ 12
6.2 Informative references .......................... 13 6.2 Informative references .......................... 13
Acknowledgments .............................................. 14 Acknowledgments .............................................. 14
Authors' Addresses ........................................... 14 Authors' Addresses ........................................... 14
Appendix A - Link Layer Hints ................................ 15 Appendix A - Hints ........................................... 15
A.1 Introduction .................................... 15 A.1 Introduction .................................... 15
A.2 Hints ........................................... 16 A.2 Link Layer Hints ................................ 16
Intellectual Property Statement .............................. 17 A.3 Internet Layer Hints ............................ 17
Intellectual Property Statement .............................. 18
Disclaimer of Validity ....................................... 18 Disclaimer of Validity ....................................... 18
Copyright Statement .......................................... 18 Copyright Statement .......................................... 18
1. Introduction 1. Introduction
The time required to detect movement between networks and to obtain The time required to detect movement between networks and to obtain
(or continue to use) an operable IPv4 configuration may be (or continue to use) an operable IPv4 configuration may be
significant as a fraction of the total handover latency in moving significant as a fraction of the total handover latency in moving
between points of attachment. between points of attachment.
This document synthesizes 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 detecting network addresses [RFC3927] to define a set of steps known as Detecting
attachment and optimizing continued use of an operable IPv4 Network Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common)
configuration, in order to minimize the handover latency in moving case of reattachment to a network that one has been connected to
between points of attachment. Since this procedure is dependent on previously by attemping to re-use a previous (but still valid)
the ARP protocol, it is not suitable for use on media that do not configuration, reducing the reattachment time to a few milliseconds
support ARP [RFC826]. on LANs. Since this procedure is dependent on 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: Sender Hardware Address [RFC826]. The hardware
(MAC) address of the originator of an ARP packet. (MAC) address of the originator of an ARP packet.
ar$spa ar$spa
ARP packet field: Source Protocol Address [RFC826]. For IP Address ARP packet field: Sender 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. packet.
ar$tha ar$tha
ARP packet field: Target Hardware Address [RFC826]. The hardware ARP packet field: Target Hardware Address [RFC826]. The hardware
(MAC) address of the target of an ARP packet. (MAC) address of the target of an ARP packet.
ar$tpa ar$tpa
ARP packet field: Target Protocol Address [RFC826]. For IPv4 ARP packet field: Target Protocol Address [RFC826]. For IPv4
Address Resolution, the IPv4 address for which one desires to know Address Resolution, the IPv4 address for which one desires to know
skipping to change at page 4, line 46 skipping to change at page 4, line 49
Conceptual layer of control or processing logic that is responsible Conceptual layer of control or processing logic that is responsible
for maintaining control of the data link. The data link layer for maintaining control of the data link. The data link layer
functions provide an interface between the higher-layer logic and functions provide an interface between the higher-layer logic and
the data link. The link layer is the layer immediately below IP. the data link. The link layer is the layer immediately below IP.
Link Up Link Up
An event provided by the link layer that signifies a state change An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating associated with the interface becoming capable of communicating
data frames. data frames.
Most Likely Attachment Network (MLAN) Most Likely Network (MLN)
The attached network heuristically determined by the host to be The attached network heuristically determined by the host to be
most likely, based on hints. most likely, based on hints.
Point of Attachment Point of Attachment
The link endpoint on the link to which the host is currently The link endpoint on the link to which the host is currently
connected. connected.
Routable address Routable address
In this specification, the term "routable address" refers to any In this specification, the term "routable address" refers to any
IPv4 address other than an IPv4 Link-Local address. This includes IPv4 address other than an IPv4 Link-Local address. This includes
private addresses as specified in [RFC1918]. private addresses as specified in [RFC1918].
Operable address Operable address
In this specification, the term "operable address" refers to either In this specification, the term "operable address" refers to either
a 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
Attachment Network (MLAN), reachability testing, and IPv4 address Attachment Network (MLN), reachability testing, and IPv4 address
acquisition. acquisition.
On connecting to a new point of attachment, the host responds to a On connecting to a new point of attachment, the host responds to a
"Link Up" indication from the link layer by carrying out the DNAv4 "Link Up" indication from the link layer by carrying out the DNAv4
procedure. As noted in Appendix A, hints about the network to which procedure. As noted in Appendix A, hints about the network to which
the host has attached may be available from the link and Internet the host has attached may be available from the link and Internet
layers. Based on these hints, the host determines the "Most Likely layers. Based on these hints, the host determines the "Most Likely
Attachment Network" (MLAN) and whether it has an operable IPv4 Attachment Network" (MLN) 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 an operable IPv4 configuration, then it performs a reachability has an operable IPv4 configuration, then it performs a reachability
test 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 MLAN. connectivity to the default gateway(s) on the MLN.
If the reachability test is successful, the host MAY continue to use If the reachability test is successful, the host SHOULD continue to
an operable routable IPv4 address without having to re-acquire it. use an operable routable IPv4 address without having to re-acquire
This reduces roaming latency by allowing the host to bypass DHCPv4 as it. This reduces roaming latency by allowing the host to bypass
well as Duplicate Address Detection (DAD). If the host believes that DHCPv4 as well as Duplicate Address Detection (DAD). If the host
it has attached to a network on which it has no operable IPv4 believes that it has attached to a network on which it has no
configuration, or if the reachability test fails, then the host operable IPv4 configuration, or if the reachability test fails, then
attempts to obtain an IPv4 configuration using DHCPv4. the host 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 [RFC3927], configuring them only in situations in which addresses [RFC3927], configuring them only in situations in which
skipping to change at page 6, line 20 skipping to change at page 6, line 22
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 an operable IPv4 Where the host mistakenly concludes that it has an operable IPv4
configuration a timeout will occur, after which the host will configuration a timeout will occur, after which the host will
eventually obtain the correct configuration using DHCPv4, albeit with eventually obtain the correct configuration using DHCPv4, albeit with
a performance penalty. a performance penalty.
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 an operable DNAv4 procedure is only carried out when the host has an operable
IPv4 configuration on the MLAN, implying that duplicate address IPv4 configuration on the MLN, implying that duplicate address
detection has previously been completed. Restrictions on sending ARP detection has previously been completed. Restrictions on sending ARP
Requests and Responses are described in Section 2.2.1. Requests and Responses are described in Section 2.2.1.
2.1. Most Likely Attachment Network (MLAN) 2.1. Most Likely Attachment Network (MLN)
In order to determine the MLAN, it is assumed that the host saves to In order to determine the MLN, 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 MLAN. Appendix A discusses hints useful for the determination of the MLN.
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 as to which network it
attached to. In the absence of other information, the MLAN defaults has attached to. In the absence of other information, the MLN
to the network to which the host was most recently attached. defaults to the network to which the host was most recently attached.
Aside from utilizing link layer indications, a host may also be able
to utilize Internet layer information in order to determine the MLAN.
IPv4 ICMP Router Discovery messages [RFC1256] provide information
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
conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are
unavailable.
However, since [RFC1256] is not widely implemented, it is NOT
RECOMMENDED that hosts utilize ICMP Router Discovery messages as an
alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain information
on available prefixes and default gateway(s). This can provide
additional resilience in the case where default gateway(s) become
unavailable.
Similarly hosts that support routing protocols such as RIP and OSPF
can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. Full
support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this
information without supporting a fully conformant routing protocol
implementation.
2.2. Reachability Test 2.2. Reachability Test
If the host has an operable routable IPv4 address on the MLAN, a host If the host has an operable routable IPv4 address on the MLN, 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 confirm that it is connected to a network on which it has
has an operable routable IPv4 address. If the reachability test is an operable routable IPv4 address. If the reachability test is not
not successful, the host proceeds to the IPv4 address acquisition successful, the host proceeds to the IPv4 address acquisition phase,
phase, described in Section 2.3. 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 an operable routable IPv4 [a] The host does not have an operable routable IPv4
address on the MLAN. In this case, the reachability address on the MLN. In this case, the reachability
test cannot confirm that the host has an operable test cannot confirm that the host has an operable
routable IPv4 address, so that completing the routable IPv4 address, so completing the
reachability test would serve no purpose. reachability test would serve no purpose.
A host MUST NOT use the reachability test to A host MUST NOT use the reachability test to
confirm configuration of an IPv4 Link-Local confirm configuration of an IPv4 Link-Local
address. 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 MLAN. In this case, insufficient gateway(s) on the MLN. 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
skipping to change at page 8, line 35 skipping to change at page 8, line 16
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 default gateway protocol address (ar$tpa) to the IPv4 address of the default gateway
being tested, and uses its own MAC address in the sender hardware being tested, and uses its own MAC address in the sender hardware
address field (ar$sha). The host sets the target hardware address address field (ar$sha). The host sets the target hardware address
field (ar$tha) to 0. field (ar$tha) to 0.
If the host has an operable routable IPv4 address other than a If the host has an operable routable IPv4 address other than a
private address on the MLAN, then it SHOULD set the sender protocol private address on the MLN, then it SHOULD set the sender protocol
address field (ar$spa) to that address. It is assumed that the host address field (ar$spa) to that address. It is assumed that the host
had previously done duplicate address detection so that an address had previously done duplicate address detection so that an address
conflict is unlikely. conflict is unlikely.
If the host has a private address as defined in [RFC1918], then it If the host has a private address as defined in [RFC1918], then it
SHOULD send an ARP Probe, setting the sender protocol address field SHOULD send an ARP Probe, setting the sender protocol address field
(ar$spa) to the unspecified address (0.0.0.0). This is to avoid a (ar$spa) to the unspecified address (0.0.0.0). This is to avoid a
potential address conflict when the host changes its attachment potential address conflict when the host changes its attachment
network from one private network to another. network from one private network to another.
skipping to change at page 9, line 32 skipping to change at page 9, line 12
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 operability 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 an operable address, as described above. However, where the host has an operable
routable non-private address on the MLAN, it MAY send ARP Requests routable non-private address on the MLN, 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/Reply 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 MLAN, potentially resulting in an address conflict. attachment to the MLN, 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 Reply 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 an operable 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 an operable routable IPv4 address on the MLAN but the If the host has an operable routable IPv4 address on the MLN but the
reachability test fails, the host SHOULD verify the configuration by reachability test fails, the host SHOULD attempt to revalidate the
entering the INIT-REBOOT state, and sending a DHCPREQUEST to the configuration by entering the INIT-REBOOT state, and sending a
broadcast address as specified in [RFC2131] Section 4.4.2. DHCPREQUEST to the broadcast address as specified in [RFC2131]
Section 4.4.2.
If the host does not have an operable routable IPv4 address on the If the host does not have an operable routable IPv4 address on the
MLAN, the host enters the INIT state and sends a DHCPDISCOVER packet MLN, the host enters the INIT state and sends a DHCPDISCOVER packet
to the broadcast address, as described in [RFC2131] Section 4.4.1. to the broadcast address, as described in [RFC2131] Section 4.4.1.
If the host supports the Rapid Commit Option [RFC4039], it is If the host supports the Rapid Commit Option [RFC4039], it is
possible that the exchange can be shortened from a 4-message exchange possible that the exchange can be shortened from a 4-message exchange
to a 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
skipping to change at page 11, line 7 skipping to change at page 10, line 36
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, assigning them only recommended that hosts behave conservatively, assigning them only
when they can do no harm. As described in [RFC3927] Section 1.7, use when they can do no harm. As described in [RFC3927] Section 1.7, use
of a routable address is preferred to a IPv4 Link-Local address of a routable address is preferred to a IPv4 Link-Local address
whenever it is available. whenever it is available.
Where the host does not have an operable routable IPv4 address on the Where the host does not have an operable routable IPv4 address on the
MLAN, the host MAY configure an IPv4 Link-Local address prior to MLN, 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 an operable routable IPv4 address on the MLAN, but Where a host has an operable routable IPv4 address on the MLN, but
the 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 an operable routable IPv4 address, attachment on which it possesses an operable routable IPv4 address,
that 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
skipping to change at page 13, line 38 skipping to change at page 13, line 14
[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, May 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- [ACD] Cheshire, S., "IPv4 Address Conflict Detection", draft-
cheshire-ipv4-acd-03.txt, Internet draft (work in progress), cheshire-ipv4-acd-03.txt, Internet draft (work in progress),
December 2002. December 2002.
[DNALINK] Yegin, A., Njedjou, E., Veerepalli, S., Montavont, N. and T.
Noel, "Link-layer Event Notifications for Detecting Network
Attachments", draft-ietf-dna-link-information-01.txt, February
2005.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June
1988.
[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.
[RFC2453] Malkin, G., "RIP Version 2", RFC 2453, STD 56, November 1998.
[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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the
Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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 818 4011 Phone: +1 425 818 4011
Fax: +1 425 936 7329 Fax: +1 425 936 7329
Appendix A - Link Layer Hints Appendix A - Hints
A.1 Introduction A.1 Introduction
In order to assist in detecting network attachment, 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 Internet and link-layer information, the host may be able to make an
guess as to whether it has moved between subnets, or has remained on educated guess as to whether it has moved between network, or has
the same subnet, as well as whether it has connected to an remained on the same network, as well as whether it has connected to
infrastructure or adhoc network. an 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 networks, 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 network 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 network, further tests (such as a
reachability test or a DHCPREQUEST sent from the INIT-REBOOT state) reachability test or a DHCPREQUEST sent from the INIT-REBOOT state)
are REQUIRED. are REQUIRED.
In practice, it is necessary for hints to be highly reliable before In practice, it is necessary for hints to be highly reliable before
they are worth considering, if the penalty paid for an incorrect hint they are worth considering, if the penalty paid for an incorrect hint
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 network, 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 network cannot be
fraction of the time, then it is only worth considering if: confirmed x fraction of the time, then it 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 = 50 ms, REACH_TIME = 10 ms, and If we assume that DHCPREQUEST_TIME = 50 ms, REACH_TIME = 10 ms, and
REACHABILITY_TIMEOUT = 200ms, then: REACHABILITY_TIMEOUT = 200ms, then:
x < (50 - 10)/(200 + 50 - 10) = 16.67 percent x < (50 - 10)/(200 + 50 - 10) = 16.67 percent
In this example, if the hint is wrong more than one sixth of the In this example, if the hint cannot be confirmed more than one sixth
time, it is not worth considering. of the time, it is not worth considering. A hint may not be
confirmable because it is wrong (the host has changed networks) or
because of packet loss in the reachability test.
A.2 Hints A.2 Link-Layer Hints
"Link-layer Event Notifications for Detecting Network Attachments"
[DNALINK] discusses the definition of link layer events on various
media. Therefore this section focuses solely on hints useful in
determining the MLN.
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 operable 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
skipping to change at page 17, line 25 skipping to change at page 17, line 30
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
link supports adhoc networking, and therefore that assignment of a link supports adhoc networking, and therefore that assignment of a
IPv4 Link-Local address is likely. When running IPv4 over PPP, if an IPv4 Link-Local address is likely. When running IPv4 over PPP, if an
IPv4 address is not statically configured or assigned via IPv4CP, IPv4 address is not statically configured or assigned via IPv4CP,
this can also be taken as a hint that assignment of an IPv4 Link- this can also be taken as a hint that assignment of an IPv4 Link-
Local address is likely. Media such as USB or IEEE 1394 may be Local address is likely. Media such as USB or IEEE 1394 may be
considered inherently more likely to support adhoc operation, so that considered inherently more likely to support adhoc operation, so that
attachment to these media may by itself be considered a hint. attachment to these media may by itself be considered a hint.
A.3 Internet Layer Hints
Aside from utilizing link layer indications, a host may also be able
to utilize Internet layer information in order to determine the MLN.
IPv4 ICMP Router Discovery messages [RFC1256] provide information
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
conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are
unavailable.
However, since [RFC1256] is not widely implemented, it is NOT
RECOMMENDED that hosts utilize ICMP Router Discovery messages as an
alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain information
on available prefixes and default gateway(s). This can provide
additional resilience in the case where default gateway(s) become
unavailable.
Similarly hosts that support routing protocols such as RIP [RFC2453]
can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. Full
support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this
information without supporting a fully conformant routing protocol
implementation. For a description of "Silent RIP", see [RFC1058]
Section 3.1.
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 Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

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