draft-ietf-dhc-dna-ipv4-04.txt   draft-ietf-dhc-dna-ipv4-05.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-04.txt> <draft-ietf-dhc-dna-ipv4-05.txt>
21 October 2003 26 January 2004
Detection of Network Attachment (DNA) in IPv4 Detection of Network Attachment (DNA) in IPv4
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
or to cite them other than as "work in progress." 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). 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 specification synthesizes experience points of attachment. This specification synthesizes experience
garnered over the years in the deployment of hosts supporting ARP, garnered over the years in the deployment of hosts supporting ARP,
DHCP and IPv4 Link-Local addresses, in order to optimize detection of DHCP and IPv4 Link-Local addresses, in order to optimize detection of
network attachment by mobile hosts. network attachment by mobile hosts.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements .................................... 4 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 3
2. Framework ................................................ 5 2. Framework ................................................ 4
2.1 Reachability test ............................... 5 2.1 Most likely point of attachment ................. 5
2.2 Packet format ................................... 6 2.2 Reachability test ............................... 5
2.3 IPv4 Address Acquisition ........................ 7 2.3 IPv4 Address Acquisition ........................ 8
3. Constants ................................................ 8 3. Constants ................................................ 9
4. IANA Considerations ...................................... 9 4. IANA Considerations ...................................... 9
5. Security Considerations .................................. 9 5. Security Considerations .................................. 9
6. References ............................................... 9 6. References ............................................... 10
6.1 Normative references ............................ 9 6.1 Normative references ............................ 10
6.2 Informative references .......................... 10 6.2 Informative references .......................... 10
Acknowledgments .............................................. 11 Acknowledgments .............................................. 11
Authors' Addresses ........................................... 11 Authors' Addresses ........................................... 11
Appendix A - Hints ........................................... 12 Appendix A - Hints ........................................... 12
Intellectual Property Statement .............................. 13 Intellectual Property Statement .............................. 13
Full Copyright Statement ..................................... 13 Full Copyright Statement ..................................... 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 Link-Local IPv4
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, phases: determination of the "most likely" point of attachment,
reachability testing, and IPv4 address acquisition. reachability testing, and IPv4 address acquisition.
On disconnection from a network, there is no need to take action
until the host is reconnected, since it is typically not possible for
a host to communicate until it has obtained connectivity. Therefore,
contrary to [RFC2131] Section 3.7, no action need be taken on network
disconnection.
For Detection of Network attachment, the following basic principles
are suggested:
[a] Utilization of link layer hints. Link layers such as
IEEE 802 [IEEE802] provide hints about whether a host
remains on the same subnet despite changing its point of
attachment, or even whether the host is connected to an
adhoc or infrastructure network. Where available, these
hints can be used to guide host behavior - with the
understanding that they are not infallible and therefore
that the host should be capable of making the correct
determination even in the presence of misleading hints.
Link layer hints are described in more detail in
Appendix A.
[b] Link-Local IPv4 addressing as a mechanism of last resort.
Experience has shown that Link-Local IPv4 addresses are
often assigned inappropriately. For example, an IPv4 host
assigning an Link-Local IPv4 address may not be connected
to any network, in which case assignment of a Link-Local
IPv4 address does no good; or the host may be attached to a
network with a DHCPv4 server but may not receive a response
to a DHCPREQUEST or DHCPDISCOVER. As described in Appendix A
of [IPv4LL] once a Link-Local IPv4 address is assigned,
existing implementations do not query the DHCPv4 server
again for 5 minutes. As noted in Section 2.3, this behavior
is in violation of [RFC2131] Section 4.1. For hosts changing
their point of attachment more frequently than this,
inappropriate assignment of an Link-Local IPv4 address can
result in an ongoing inability to connect. As a result,
this document suggests that hosts behave conservatively with
respect to assignment of Link-Local IPv4 addresses, using
them only as a last resort.
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. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [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 IP Address of the sender of the ARP packet. Resolution this is the IPv4 address of the sender of the ARP
If the sender address is unknown, this is set to 0.0.0.0. packet. If the sender address is unknown, this is set to 0.0.0.0.
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, 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 IP Address ARP packet field: Target Protocol Address [RFC826]. For IPv4
Resolution, the IP address for which one desires to know the Address Resolution, the IPv4 address for which one desires to know
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 DHCP 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.
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 address other than an IPv4 Link-Local address. This includes
private addresses as specified in [RFC1918]. private addresses as specified in [RFC1918].
Valid address
In this specification, the term "valid address" refers to either a
static IPv4 address, or an address assigned via DHCPv4 which has
not been relinquished, and whose lease has not yet expired.
2. Framework 2. Framework
On connecting to a new point of attachment, the host attempts to For Detection of Network attachment, the following basic principles
determine the "most likely" configuration associated with the new are suggested:
[a] Treatment of link-down/up indications. On disconnection
from a network, there is no need to take action until the
host is reconnected, since it is typically not possible
for a host to communicate until it has obtained connectivity.
Therefore, contrary to [RFC2131] Section 3.7, no action
need be taken on network disconnection. On connecting
to a new point of attachment, the host attempts to determine
the "most likely" configuration associated with the new
point of attachment. point of attachment.
[b] Utilization of hints. Link layers such as IEEE 802
[IEEE802] provide hints about whether a host remains
on the same subnet despite changing its point of
attachment, or even whether the host is connected to an
ad hoc or infrastructure network. On connecting to a new
point of attachment, the host attempts to use available
hints to determine the "most likely" configuration
associated with the new point of attachment. Since
hints are not infallible, the host should be capable of
making the correct determination even in the presence of
misleading hints. For details see Appendix A.
[c] Link-Local IPv4 addressing as a mechanism of last resort.
Experience has shown that Link-Local IPv4 addresses are
often assigned inappropriately. For example, an IPv4 host
assigning an Link-Local IPv4 address may not be connected
to any network, in which case assignment of a Link-Local
IPv4 address does no good; or the host may be attached to a
network with a DHCPv4 server but may not receive a response
to a DHCPREQUEST or DHCPDISCOVER. As described in [IPv4LL]
Appendix A once a Link-Local IPv4 address is assigned,
existing implementations do not query the DHCPv4 server
again for 5 minutes. As noted in Section 2.3, this behavior
is in violation of [RFC2131] Section 4.1. For hosts changing
their point of attachment more frequently than this,
inappropriate assignment of an Link-Local IPv4 address can
result in an ongoing inability to connect. As a result,
this document suggests that hosts behave conservatively with
respect to assignment of Link-Local IPv4 addresses, using
them only as a last resort.
2.1. Most likely point of attachment
In order to determine the "most likely" point of attachment it is In order to determine the "most likely" point of attachment it is
assumed that the host is capable of obtaining and writing to stable assumed that the host is capable of obtaining and writing to stable
storage parameters relating to networks that it connects to, storage parameters relating to networks that it connects to,
including: including:
[1] IP and link layer hints associated with each network. For [1] IP and link layer hints associated with each network.
details, see Appendix A. For details, see Appendix A.
[2] The IP and MAC address of the primary default gateway on
[2] The IPv4 and MAC address of the default gateway(s) on
each network. each network.
By matching the received hints against information previously By matching the received hints against information previously
collected, the host may be able to make an educated guess of which collected, the host may be able to make an educated guess of which
network it has attached to. Where no additional information is network it has attached to. In the absence of other information, by
available, by default the host assumes that the "most likely" point default the host assumes that the "most likely" point of attachment
of attachment is the network to which it was most recently connected. is the network to which it was most recently attached.
If the host has a valid routable IPv4 address on the "most likely" If the host has a valid routable IPv4 address on the "most likely"
point of attachment, the host performs a reachability test as point of attachment, the host performs a reachability test as
described below. If the reachability test is not successful, or if described in Section 2.2. If the reachability test is not
the host does not have a valid routable IPv4 address on the "most successful, or if the host does not have a valid routable IPv4
likely" point of attachment, the host proceeds to the IPv4 address address on the "most likely" point of attachment, the host proceeds
acquisition phase. to the IPv4 address acquisition phase, described in Section 2.3.
2.1. Reachability Test 2.2. Reachability Test
The purpose of the reachability test is to determine whether the host The purpose of the reachability test is to determine whether the host
is connected to a network on which it had previously obtained a still is connected to a network on which it has a valid routable IPv4
valid routable IPv4 address. The test is performed by attempting to address.
verify reachability of a previously configured primary default
gateway on a former point of attachment. If the test is successful,
the host may continue to use a valid routable IPv4 address without
having to re-acquire it. This reduces roaming latency by allowing
the host to bypass the DHCP exchange as well as subsequent Duplicate
Address Detection (DAD). In contrast to a DHCP exchange, which may
be between a DHCP client and an offlink DHCP server, the reachability
test occurs between a host and its next hop router.
The host skips the reachability test and proceeds to the address The host skips the reachability test in the following circumstances:
acquisition phase in the following circumstances:
[a] If the host does not have information on the default [a] If the host does not have a valid routable IPv4
gateway on the network. address on the "most likely" point of attachment.
[b] If the host does not have a valid routable IPv4 address
on the network. A Link-Local IPv4 address does not
count as a valid routable IPv4 address.
2.2. Packet Format [b] If no hints are available. Since confirming failure of
the reachability test requires considerable latency,
mistakes are costly. In the absence of hints, a
host SHOULD instead send a DHCPREQUEST
from the INIT-REBOOT state, as described in [RFC2131],
Section 3.2 and 4.3.2.
To perform the reachability test, an ARP Request SHOULD be sent, [c] If the host does not have information on the default
using the host's MAC address as the source, and the broadcast MAC gateway(s) for the "most likely" point of attachment.
address as the destination. The host sets the target protocol
address (ar$tpa) to the IPv4 address of the primary default gateway,
and uses its own MAC address in the sender hardware address field
(ar$sha). The host sets the target hardware address field (ar$tha)
to 0.
If the host has a valid globally routable IP address on the most [d] If secure detection of network attachment is required.
likely point of attachment, then it SHOULD set the sender protocol See Section 5 for details.
address field (ar$spa) to that address. It is assumed that the host
had previously done duplicate address detection so that an address The reachability test is performed by attempting to verify
reachability of default gateway(s) on the "most likely" point of
attachment. This reduces roaming latency by allowing the host to
bypass DHCP as well as subsequent Duplicate Address Detection (DAD).
In contrast to a DHCP exchange, which may be between a DHCP client
and an offlink 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
primary and secondary default gateways, in series or in parallel. If
the reachability test is successful, the host may continue to use a
valid routable IPv4 address without having to re-acquire it.
However, in order to ensure configuration validity, the host SHOULD
only configure default gateway(s) which pass the reachability test.
2.2.1. Packet Format
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
broadcast MAC address as the destination. The host sets the target
protocol address (ar$tpa) to the IPv4 address of the primary default
gateway, and uses its own MAC address in the sender hardware address
field (ar$sha). The host sets the target hardware address field
(ar$tha) to 0.
If the host has a valid routable IPv4 address on the most likely
point of attachment, then it SHOULD set the sender protocol address
field (ar$spa) to that address. It is assumed that the host had
previously done duplicate address detection so that an address
conflict is unlikely. conflict is unlikely.
However if the host has a private address as defined in [RFC1918], However if the host has a private address as defined in [RFC1918],
then it SHOULD set the sender protocol address field (ar$spa) to the then it SHOULD set the sender protocol address field (ar$spa) to the
unspecified address (0.0.0.0). This is to avoid an address conflict unspecified address (0.0.0.0). This is to avoid an address conflict
in the case where the host has changed its point of attachment from in the case where the host has changed its point of attachment from
one private network to another. one private network to another.
Note: Some routers may refuse to answer an ARP Request sent with Note: Some routers may refuse to answer an ARP Request sent with
the sender protocol address field (ar$spa) set to the unspecified the sender protocol address field (ar$spa) set to the unspecified
address (0.0.0.0). In this case the reachability test will fail. address (0.0.0.0). In this case the reachability test will fail.
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 IPv4 address lease 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 and MAC addresses 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 allows the host to confirm reachability even where
the host moves between two private networks. In this case the IPv4 the host moves 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. Where a host moves from one private NOT be used as a substitute.
network to another, an ICMP Echo Request can result in an ICMP Echo
Response even when the default gateway has changed, as long as the Where a host moves from one private network to another, an ICMP Echo
IPv4 address remains the same. This can occur, for example, where a Request can result in an ICMP Echo Response even when the default
host moves from one home network using prefix 192.168/16 to another gateway has changed, as long as the IPv4 address remains the same.
one. In addition, if the ping is sent with TTL > 1, then an ICMP This can occur, for example, where a host moves from one home
Echo Response can be received from an off-link gateway. 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
from an off-link gateway.
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_TIMER and then sends another ARP Request. If no ARP for REACHABILITY_TIMER and then sends another ARP Request. If no ARP
Response is received in response to this second Request, the host Response is received in response to this second Request, the host
proceeds to the IPv4 address acquisition phase. If a valid ARP proceeds to the IPv4 address acquisition phase. If a valid ARP
Response is received, but cannot be matched against known networks, Response is received, but cannot be matched against known networks,
the host assumes it has moved subnets and moves on to the address the host assumes it has moved subnets and moves on to the address
acquisition phase. acquisition phase.
2.3. IPv4 Address Acquisition 2.3. IPv4 Address Acquisition
If the host has a valid cached configuration on the "most likely" If the host has a valid routable IPv4 address on the "most likely"
point of attachment, but is unable to confirm reachability to the point of attachment, but the reachability test fails, then the host
primary default gateway, then the host seeks to verify the cached seeks to verify the configuration by entering the INIT-REBOOT state,
configuration by entering the INIT-REBOOT state, and sending a and sending a DHCPREQUEST to the broadcast address as specified in
DHCPREQUEST to the broadcast address as specified in [RFC2131] [RFC2131] Section 4.4.2.
Section 4.4.2.
If the host does not have a valid cached configuration, or had not If the host does not have a valid routable IPv4 address on the "most
previously obtained a routable IPv4 address on the "most likely" likely" point of attachment, the host enters the INIT state and sends
point of attachment, then the host enters the INIT state and sends a a DHCPDISCOVER packet to the broadcast address, as described in
DHCPDISCOVER packet to the broadcast address, as described in
[RFC2131] Section 4.4.1. If the host does not receive a response to [RFC2131] Section 4.4.1. If the host does not receive a response to
a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in
[RFC2131] Section 4.1. [RFC2131] Section 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 IP broadcast address. the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast
In the INIT-REBOOT state a DHCPREQUEST is sent to the broadcast address. In the INIT-REBOOT state a DHCPREQUEST is sent to the
address so that the host will receive a response regardless of broadcast address so that the host will receive a response regardless
whether the cached IP address is correct for the network to which it of whether the previously configured IPv4 address is correct for the
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 client has moved to another subnet, a not appropriate, since if the DHCP client has moved to another
DHCP server response cannot be routed back to the client since the subnet, a DHCP server response cannot be routed back to the client
DHCPREQUEST will bypass the DHCP relay and will contain an invalid since the DHCPREQUEST will bypass the DHCP relay and will contain an
source address. invalid source address.
As described in [IPv4LL] Section 1.7, use of a routable address is As described in [IPv4LL] Section 1.7, use of a routable address is
preferred to a Link-Local IPv4 address whenever it is available. preferred to a Link-Local IPv4 address whenever it is available.
[RFC2131] Section 3.2 states that if the host possesses a valid [RFC2131] Section 3.2 states that if the DHCP client does not receive
routable IPv4 address on the "most likely" network and does not a response after employing the retransmission algorithm, the client
receive a response after employing the retransmission algorithm, the 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.
This is preferable to assigning a Link-Local IPv4 address if the host This is preferable to assigning a Link-Local IPv4 address if the host
has good reason to believe that it remains connected to a network on has good reason to believe that it remains connected to a network on
which it possesses a valid IPv4 address lease. This would be the which it possesses a valid routable IPv4 address. See Appendix A for
case, for example, where a host has received hints that it believes details.
to be "strong". See Appendix A for details.
If the host does not have a valid IPv4 address lease on the "most If the host does not have a valid IPv4 address lease on the "most
likely" network and does not receive a response after employing the likely" network and does not receive a response after employing the
retransmission algorithm, it MAY assign a Link-Local IPv4 address. retransmission algorithm, it MAY assign a Link-Local IPv4 address.
Since a Link-Local IPv4 address is often configured because a DHCP Since a Link-Local IPv4 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 Link-Local IPv4 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.
Where a Link-Local IPv4 address is assigned, experience has shown Where a Link-Local IPv4 address is assigned, experience has shown
skipping to change at page 8, line 46 skipping to change at page 9, line 24
retry every 64 seconds, even after allocating a Link-Local IPv4 retry every 64 seconds, even after allocating a Link-Local IPv4
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 Link-Local IPv4 address is
deprecated. In order to avoid inappropriate assignment of an IPv4 deprecated. In order to avoid inappropriate assignment of an IPv4
Link-Local address, it is RECOMMENDED that such an address not be Link-Local address, it is RECOMMENDED that such an address not be
assigned until the DHCP client has retransmitted at least 3 times. assigned until the DHCP client has retransmitted at least 3 times.
3. Constants 3. Constants
The suggested default value of REACHABILITY_TIMER is 200 ms. This value The suggested default value of REACHABILITY_TIMER is 200 ms. This value
was chosen so as to accomodate the maximum retransmission timer likely was chosen so as to accommodate the maximum retransmission timer likely
to be experienced on an Ethernet network. to be experienced on an Ethernet network.
4. IANA Considerations 4. IANA Considerations
Guidelines for IANA considerations are specified in [RFC2434]. This Guidelines for IANA considerations are specified in [RFC2434]. This
specification does not request the creation of any new parameter 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 typically insecure, so that Detection of Network Attachment (DNA) is typically insecure, so that
it is inadvisable for a host to adjust its security based on which it is inadvisable for a host to adjust its security based on which
network it believes it is attached to. For example, it would be network it believes it is attached to. For example, it would be
inappropriate for a host to disable its personal firewall based on inappropriate for a host to disable its personal firewall based on
the belief that it had connected to a home network. the belief that it had connected to a home network.
ARP [RFC826] traffic is inherently insecure, so that the reachability ARP [RFC826] traffic is inherently insecure, so that the reachability
test described in Section 1.3 can be easily spoofed by an attacker, test described in Section 1.3 can be easily spoofed by an attacker,
leading a host to conclude that it remained attached to a former leading a host to falsely conclude that it is attached to a network
network. Similarly, where DHCP [RFC2131] traffic is not secured, an that it is not connected to. Similarly, where DHCP traffic is not
attacker could masquerade as a DHCP server, in order to convince the secured, an attacker could masquerade as a DHCP server, in order to
host that it was attached to a particular network. convince the host that it was attached to a particular network.
Where secure detection of network attachment is required, a host MAY Where secure detection of network attachment is required, a host
wish to skip the ARP-based reachability test entirely since it cannot SHOULD skip the reachability test since it cannot be secured, and
be secured, and go immediately to the IPv4 address acquisition phase, instead utilize authenticated DHCP [RFC3118].
utilizing authenticated DHCP [RFC3118].
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 10, line 10 skipping to change at page 10, line 31
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 [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", Internet draft (work in of IPv4 Link-Local Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October progress), draft-ietf-zeroconf-ipv4-linklocal-12.txt, January
2003. 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., et al., "Address Allocation for Private
Internets", RFC 1918, February 1996. Internets", RFC 1918, February 1996.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial [RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial
In User Service (RADIUS) Usage Guidelines", RFC 3580, In User Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003. September 2003.
[RFC2284bis]
Blunk, L., et al., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-08.txt, Internet draft (work in
progress), February 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-2001, June 2001. based Network Access Control, IEEE Std 802.1X-2001, June 2001.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
skipping to change at page 12, line 11 skipping to change at page 12, line 11
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 706 6605
Fax: +1 425 936 7329 Fax: +1 425 936 7329
Appendix A - Hints Appendix A - Hints
In order to assist in IPv4 network attachment detection, information In order to assist in IPv4 network attachment detection, 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
IP and link-layer information, the host may be able to make an IP and link-layer information, the host may be able to make an
educated guess as to whether it has moved between subnets, or educated guess as to whether it has moved between subnets, or
remained on the same subnet. If it is likely to have moved between remained on the same subnet.
subnets, the host may have an educated guess as to which subnet it
has moved to. The term "strong hint" refers to information which If the host is likely to have moved between subnets, it may be
provides an unambiguous indication of the network to which a host has possible to make an educated guess as to which subnet it has moved
connected. "Weak hints" involve information which is inconclusive. to. Since an educated guess may be incorrect, prior to concluding
that the host remains on the same subnet, further tests (such as a
reachability test or a DHCPREQUEST sent from the INIT-REBOOT state)
are REQUIRED.
IPv4 ICMP Router Discovery messages [RFC1256] provide information IPv4 ICMP Router Discovery messages [RFC1256] provide information
directly relevant to determining the network to which a host has relating to prefix(es) available on the link. A host may use such a
connected. As such, information gleaned from Router Advertisements message to conclude that an advertised prefix is available; however
can be considered a "strong" hint. it cannot conclude the converse -- that prefixes not advertised are
unavailable.
For networks running over PPP [RFC1661], "weak" hints include the For networks running over PPP [RFC1661], IP parameters negotiated in
link characteristics negotiated in LCP, and the associated phone IPCP provide direct information on whether a previously obtained
number. The IP parameters negotiated in IPCP are considered a address remains valid on the link.
"strong" hint.
On IEEE 802 [IEEE802] wired networks, hints include link-layer On IEEE 802 [IEEE802] wired networks, hints include link-layer
discovery traffic as well as information exchanged as part of IEEE discovery traffic as well as information exchanged as part of IEEE
802.1X authentication [IEEE8021X]. Link-layer discovery traffic 802.1X authentication [IEEE8021X].
includes Link Layer Discovery Protocol (LLDP) [IEEE8021AB] traffic as
well as network identification information passed in the EAP-
Request/Identity or within an EAP method exchange, as defined in EAP
[RFC2284].
For example, LLDP advertisements can provide information on the IP Link-layer discovery traffic includes Link Layer Discovery Protocol
address or VLANs supported by the device. These hints, if provided, (LLDP) [IEEE8021AB] traffic as well as network identification
are considered "strong". When used with IEEE 802.1X authentication information passed in the EAP-Request/Identity or within an EAP
method exchange, as defined in EAP [RFC2284bis].
For example, LLDP advertisements can provide information on VLANs
supported by the device. When used with IEEE 802.1X authentication
[IEEE8021X], the EAP-Request/Identity exchange may contain the name [IEEE8021X], the EAP-Request/Identity exchange may contain the name
of the authenticator, also providing information on the potential of the authenticator, also providing information on the potential
network. Similarly, during the EAP method exchange the authenticator network. Similarly, during the EAP method exchange the authenticator
may supply information that may be helpful in identifying the network may supply information that may be helpful in identifying the network
to which the device is attached. However, as noted in [RFC3580], it to which the device is attached. However, as noted in [RFC3580], it
is possible for the VLANID defined in [IEEE8021Q] to be assigned is possible for the VLANID defined in [IEEE8021Q] to be assigned
dynamically, so this static information may not prove definitive. As dynamically, so that static advertisements may not prove definitive.
a result, these hints are considered "weak".
In IEEE 802.11 [IEEE80211] stations provide information in Beacon In IEEE 802.11 [IEEE80211] 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 Adhoc mode. As described in operating in Infrastructure or Adhoc 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 [IEEE8021X] authentication. This based on the results of IEEE 802.1X [IEEE8021X] authentication. This
implies that a single SSID may offer access to multiple VLANs, and in implies that a single SSID may offer access to multiple VLANs, and in
practice most large WLAN deployments offer access to multiple practice most large WLAN deployments offer access to multiple
subnets. subnets.
Thus, associating to the same SSID is a necessary, but not Thus, associating to the same SSID is a necessary, but not
necessarily a sufficient condition, for remaining within the same necessarily a sufficient condition, for remaining within the same
subnet: while a Station associating to the same SSID may not subnet: while a Station associating to the same SSID may not
necessarily remain within the same subnet, a Station associating to a necessarily remain within the same subnet, a Station associating to a
different SSID is likely to have changed subnets. different SSID is likely to have changed subnets.
In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such
as "default", "linksys" and "tsunami" are often configured by
manufacturers by default. As a result, matching an advertised SSID
against those of previously encountered networks may be misleading.
Where an SSID known to be configured by default is encountered, it is
recommended that the BSSID be stored and subsequently compared
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. Such hints are considered Beacon and Probe Response messages. As noted earlier, VLANs may be
"strong"; all other IEEE 802.11 hints are considered "weak". determined dynamically so that these information elements may not be
reliable.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property 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
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 13, line 44 skipping to change at page 14, line 7
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
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 which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 14, line 28 skipping to change at page 14, line 39
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/dnaissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dhc-dna-ipv4-04.txt>, and expires This memo is filed as <draft-ietf-dhc-dna-ipv4-05.txt>, and expires
April 22, 2004. August 22, 2004.
 End of changes. 

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