draft-ietf-dhc-dna-ipv4-01.txt   draft-ietf-dhc-dna-ipv4-02.txt 
DHC Working Group Bernard Aboba DHC Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation INTERNET-DRAFT Microsoft Corporation
Category: Best Current Practice Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-01.txt> <draft-ietf-dhc-dna-ipv4-02.txt>
11 September 2003 28 September 2003
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 35 skipping to change at page 1, line 35
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 (2003). All Rights Reserved.
Abstract Abstract
This specification attempts to synthesize experience garnered over the The time required to detect movement (or lack of movement) between
years in the deployment of hosts supporting ARP, DHCP and IPv4 Link- subnets, and to obtain (or continue to use) a valid IPv4 address may
Local addresses. Given this experience, this document suggests be significant as a fraction of the total delay in moving between
optimizations for detection of network attachment in IPv4 as well as points of attachment. This specification synthesizes experience
heuristics for determining when assignment of an IPv4 Link-Local address garnered over the years in the deployment of hosts supporting ARP,
is appropriate. DHCP and IPv4 Link-Local addresses, in order to optimize detection of
network attachment by mobile hosts.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 4
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 4
2. Framework ................................................ 4 2. Framework ................................................ 4
2.1 Most Likely Point of Attachment ................. 4 2.1 Reachability test ............................... 5
2.2 Reachability test ............................... 5 2.2 Packet format ................................... 5
2.3 IPv4 Address Acquisition ........................ 6 2.3 IPv4 Address Acquisition ........................ 6
3. Constants ................................................ 8 3. IANA Considerations ...................................... 8
4. IANA Considerations ...................................... 8 4. Security Considerations .................................. 8
5. Security Considerations .................................. 8 5. References ............................................... 8
6. References ............................................... 8 5.1 Normative references ............................ 8
6.1 Normative references ............................ 8 5.2 Informative references .......................... 9
6.2 Informative references .......................... 9
Acknowledgments .............................................. 10 Acknowledgments .............................................. 10
Authors' Addresses ........................................... 10 Authors' Addresses ........................................... 10
Appendix A - Hints ........................................... 12 Appendix A - Hints ........................................... 11
Intellectual Property Statement .............................. 13 Intellectual Property Statement .............................. 12
Full Copyright Statement ..................................... 13 Full Copyright Statement ..................................... 12
1. Introduction 1. Introduction
This draft attempts to synthesize experience garnered over the years in The time required to detect movement (or lack of movement) between
the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and subnets, and to obtain (or continue to use) a valid IPv4 address may
Link-Local IPv4 addresses [IPv4LL]. Experience has indicated the be significant as a fraction of the total delay in moving between
importance of several goals in detection of network attachment: points of attachment. As a result, optimizing detection of network
attachment is important for mobile hosts.
[a] Avoiding inappropriate assignment of Link-Local IPv4 addresses. This document synthesizes experience in the deployment of hosts
Experience has shown that in the vast majority of cases, the supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4
assignment of Link-Local IPv4 addresses is inappropriate. That addresses [IPv4LL], specifying a procedure to be performed for IPv4
is, the IPv4 host assigning an Link-Local IPv4 address either detection of network attachment. The procedure consists of three
is not connected to a network at all, in which case assignment phases: determination of the "most likely" point of attachment,
of an Link-Local IPv4 address does no good; or the host is in reachability testing, and IPv4 address acquisition.
fact present on a network with a DHCPv4 server but for one
reason or another does not receive a response to a DHCPREQUEST
or DHCPDISCOVER.
[b] Latency Optimization. The time required to detect movement (or On disconnection from a network, there is no need to take action
lack of movement) between subnets, and to obtain (or continue to until the host is reconnected, since it is typically not possible for
use) a valid IPv4 address represents a significant fraction of a host to communicate until it has obtained connectivity. Therefore,
the overall latency resulting from movement between points of contrary to [RFC2131] Section 3.7, no action need be taken on network
attachment on the network. As a result, optimization of disconnection.
detection of network attachment in IPv4 hosts is helpful, to the
extent that it is achievable.
In order to achieve these goals, this document specifies For Detection of Network attachment, the following basic principles
procedures conducted on connection to a network. On are suggested:
disconnection from a network, there is no need to take action
until the host is reconnected, since it is typically not [a] Utilization of link layer hints. Link layers such as
possible for a host to communicate until it has obtained IEEE 802 [IEEE802] provide hints about whether a host
connectivity. Therefore, contrary to [RFC2131] Section 3.7, no remains on the same subnet despite changing its point of
action need be taken on network disconnection. 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 of In this document, several words are used to signify the requirements
the specification. These words are often capitalized. The key words of the specification. These words are often capitalized. The key
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
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:
DHCP client DHCP client
A DHCP client or "client" is an Internet host using DHCP to A DHCP client or "client" is an Internet host using DHCP to obtain
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].
2. Framework 2. Framework
This document specifies a procedure to be performed for IPv4 network
attachment detection that depends on three phases: determination of the
"most likely" point of attachment, a reachability test phase, and an
IPv4 address acquisition phase.
The following basic principles are suggested:
[1] 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.
[2] Link-Local IPv4 addressing as a mechanism of last resort. In
existing implementations of [IPv4LL], once a Link-Local IPv4
address is assigned, the DHCPv4 server may not be queried again
for 5 minutes. As a result, the inappropriate assignment of a
Link-Local IPv4 address results in an extended period of limited
connectivity. For a host that may change its point of
attachment more frequently than every 5 minutes, the
inappropriate assignment of an Link-Local IPv4 address is more
than just an annoyance - it 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
On connecting to a new point of attachment, the host attempts to On connecting to a new point of attachment, the host attempts to
determine the "most likely" configuration associated with the new point determine the "most likely" configuration associated with the new
of attachment. 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, including: storage parameters relating to networks that it connects to,
including:
[1] IP and link layer hints associated with each network. For [1] IP and link layer hints associated with each network. For
details, see Appendix A. details, see Appendix A.
[2] The IP and MAC address of the primary default gateway on
[2] The IP and MAC address of 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 collected, the host may be able to make an educated guess of which
which network it has attached to. Where no additional network it has attached to. Where no additional information is
information is available, by default the host assumes that the available, by default the host assumes that the "most likely" point
"most likely" point of attachment is the network to which it was of attachment is the network to which it was most recently connected.
most recently connected.
If the host has a valid routable IPv4 address on the "most If the host has a valid routable IPv4 address on the "most likely"
likely" point of attachment, the host performs a reachability point of attachment, the host performs a reachability test as
test as described below. If the reachability test is not described below. If the reachability test is not successful, or if
successful, or if the host does not have a valid routable IPv4 the host does not have a valid routable IPv4 address on the "most
address on the "most likely" point of attachment, the host likely" point of attachment, the host proceeds to the IPv4 address
proceeds to the IPv4 address acquisition phase. acquisition phase.
2.2. Reachability Test 2.1. Reachability Test
The purpose of the reachability test is for the host to quickly The purpose of the reachability test is to determine whether the host
determine whether it is connected to a network on which it had is connected to a network on which it had previously obtained a still
previously obtained a still valid routable IPv4 address. The test is valid routable IPv4 address. The test is performed by attempting to
performed by attempting to verify reachability of a previously verify reachability of a previously configured primary default
configured primary default gateway on a former point of attachment. If gateway on a former point of attachment. If the test is successful,
the test is successful, the host may continue to use a valid routable the host may continue to use a valid routable IPv4 address without
IPv4 address without having to re-acquire it. 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 and proceeds to the address
acquisition phase in the following circumstances: acquisition phase in the following circumstances:
[a] If the host does not have information on the default gateway on [a] If the host does not have information on the default
the network. gateway on the network.
[b] If the host does not have a valid routable IPv4 address
[b] If the host does not have a valid routable IPv4 address on the on the network. Since Link-Local IPv4 addresses are a
network. Since Link-Local IPv4 addresses are a last resort, last resort, these addresses do not count as a valid
these addresses do not count as a valid routable IPv4 address. routable IPv4 address.
2.2.1. Packet Format 2.2. Packet Format
To perform the reachability test, an ARP Request SHOULD be sent, using To perform the reachability test, an ARP Request SHOULD be sent,
the host's MAC address as the source, and the broadcast MAC address as using the host's MAC address as the source, and the broadcast MAC
the destination. The host sets the target protocol address (ar$tpa) to address as the destination. The host sets the target protocol
the IPv4 address of the primary default gateway, and uses its own MAC 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). Since the host has not yet confirmed the subnet on which
it is attached, it MUST set the sender protocol address field
(ar$spa) to 0.0.0.0. This prevents poisoning of the ARP cache with a
(potentially invalid) sender IPv4 address.
address in the sender hardware address field (ar$sha). Since the host Since the ARP Response is sent to the sender hardware address, the
has not yet confirmed the subnet on which it is attached, it MUST set contents of the sender protocol address field do not affect delivery
the sender protocol address field (ar$spa) to 0.0.0.0. This prevents of the ARP Response. Since existing implementations do not create an
poisoning of the ARP cache with a (potentially invalid) sender IPv4 ARP cache entry for 0.0.0.0, using this as the sender protocol
address. address is harmless.
If a valid ARP Response is received, the MAC address in the target If a valid ARP Response is received, the MAC address in the target
hardware address field (ar$tha) and the IPv4 address in the target hardware address field (ar$tha) and the IPv4 address in the target
protocol address field (ar$tpa) are matched against the list of networks protocol address field (ar$tpa) are matched against the list of
and associated default gateway parameters. If a match is found, then networks and associated default gateway parameters. If a match is
if the host has a valid IPv4 address lease on the matched network, the found, then if the host has a valid IPv4 address lease on the
host continues to use that IPv4 address, subject to the lease re- matched network, the host continues to use that IPv4 address, subject
acquisition and expiration behavior described in [RFC2131], Section to the lease re-acquisition and expiration behavior described in
4.4.5. [RFC2131], Section 4.4.5.
Checking for a match on both the IPv4 and MAC addresses of the default Checking for a match on both the IPv4 and MAC addresses of the
gateway allows the host to confirm reachability even where the host default gateway allows the host to confirm reachability even where
moves between two private networks. In this case the IPv4 address of the host moves between two private networks. In this case the IPv4
the default gateway could remain the same, while the MAC address would address of the default gateway could remain the same, while the MAC
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 to the default gateway IPv4 address does Sending an ICMP Echo Request to the default gateway IPv4 address does
not provide the same level of assurance since this requires an ARP not provide the same level of assurance since this requires an ARP
Request/Response to be sent first, and typically does not allow the MAC Request/Response to be sent first, and typically does not allow the
address to be checked as well. It therefore SHOULD NOT be used as a MAC address to be checked as well. It therefore SHOULD NOT be used
substitute. Where a host moves from one private network to another, an as a substitute. Where a host moves from one private network to
ICMP Echo Request can result in an ICMP Echo Response even when the another, an ICMP Echo Request can result in an ICMP Echo Response
default gateway has changed, as long as the IPv4 address remains the even when the default gateway has changed, as long as the IPv4
same. This can occur, for example, where a host moves from one home address remains the same. This can occur, for example, where a host
network using prefix 192.168/16 to another one. In addition, if the moves from one home network using prefix 192.168/16 to another one.
ping is sent with TTL > 1, then an ICMP Echo Response can be received In addition, if the ping is sent with TTL > 1, then an ICMP Echo
from an off-link gateway. 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
200ms and then sends another ARP Request. If no ARP Response is 200ms and then sends another ARP Request. If no ARP Response is
received in response to this second Request, the host proceeds to the received in response to this second Request, the host proceeds to the
IPv4 address acquisition phase. If a valid ARP Response is received, IPv4 address acquisition phase. If a valid ARP Response is received,
but cannot be matched against known networks, the host assumes it has but cannot be matched against known networks, the host assumes it has
moved subnets and moves on to the address acquisition phase. moved subnets and moves on to the address acquisition phase.
2.3. IPv4 Address Acquisition 2.3. IPv4 Address Acquisition
If the host has a valid cached configuration on the "most likely" point If the host has a valid cached configuration on the "most likely"
of attachment, but is unable to confirm reachability to the primary point of attachment, but is unable to confirm reachability to the
default gateway, then the host seeks to verify the cached configuration primary default gateway, then the host seeks to verify the cached
by 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 a valid cached configuration, or had not If the host does not have a valid cached configuration, or had not
previously obtained a routable IPv4 address on the "most likely" point previously obtained a routable IPv4 address on the "most likely"
of attachment, then the host enters the INIT state and sends a point of attachment, then the host enters the INIT state and sends a
DHCPDISCOVER packet to the broadcast address, as described in [RFC2131] DHCPDISCOVER packet to the broadcast address, as described in
Section 4.4.1. If the host does not receive a response to a DHCPREQUEST [RFC2131] Section 4.4.1. If the host does not receive a response to
or DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in
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 IP broadcast address.
However, sending a DHCPREQUEST to the unicast address when in INIT- However, sending a DHCPREQUEST to the unicast address when in INIT-
REBOOT state is not appropriate since it is possible that the client has REBOOT state is not appropriate since it is possible that the client
moved to another subnet, and therefore the DHCPREQUEST needs to be has moved to another subnet, and therefore the DHCPREQUEST needs to
forwarded to and from the DHCP server by a DHCP Relay so that the be forwarded to and from the DHCP server by a DHCP Relay so that the
response can be broadcast. This ensures that the host will receive a response can be broadcast. This ensures that the host will receive a
response regardless of whether the cached IP address is correct for the response regardless of whether the cached IP address is correct for
network to which it has connected. the network to which it has connected.
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 use of a Link-Local IPv4 address. [RFC2131] Section 3.2 preferred to a Link-Local IPv4 address whenever it is available.
states that if the host possesses a valid routable IPv4 address on the [RFC2131] Section 3.2 states that if the host possesses a valid
"most likely" network and does not receive a response after employing routable IPv4 address on the "most likely" network and does not
the retransmission algorithm, the client MAY choose to use the receive a response after employing the retransmission algorithm, the
previously allocated network address and configuration parameters for client MAY choose to use the previously allocated network address and
the remainder of the unexpired lease. This is preferable to assigning a configuration parameters for the remainder of the unexpired lease.
Link-Local IPv4 address if the host has good reason to believe that it This is preferable to assigning a Link-Local IPv4 address if the host
remains connected to a network on which it possesses a valid IPv4 has good reason to believe that it remains connected to a network on
address lease. This would be the case, for example, where a host has which it possesses a valid IPv4 address lease. This would be the
received "hints" that it believes to be "strong". 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 some server failed to respond to an initial query or is inoperative for
time, it is desirable to abandon the Link-Local IPv4 address assignment some time, it is desirable to abandon the Link-Local IPv4 address
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 that Where a Link-Local IPv4 address is assigned, experience has shown
five minutes (see [IPv4LL] Appendix A.2) was too long an interval to that five minutes (see [IPv4LL] Appendix A.2) is too long an interval
wait and try to obtain a routable IPv4 address via DHCP. A host which to wait until retrying to obtain a routable IPv4 address using DHCP.
has been configured with a Link-Local IPv4 address SHOULD periodically According to [RFC2131] Section 4.1:
attempt to obtain a routable IPv4 address via DHCP. The recommended
policy is to attempt to obtain an address via DHCP after waiting for
RECONF_INTERVAL, plus a random number of seconds, uniformly distributed,
between zero to RECONF_JITTER seconds.
3. Constants The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds.
RECONF_INTERVAL 30 seconds As a result, a DHCP client compliant with [RFC2131] will continue to
RECONF_JITTER 10 seconds retry every 64 seconds, even after allocating a Link-Local IPv4
address. Should the DHCP client succeed in obtaining a routable
address, then as noted in [IPv4LL], the Link-Local IPv4 address is
deprecated. In order to avoid inappropriate assignment of an IPv4
Link-Local address, it is RECOMMENDED that such an address not be
assigned until the DHCP client has retransmitted at least 3 times.
4. IANA Considerations 3. IANA Considerations
This specification does not request the creation of any new parameter Guidelines for IANA considerations are specified in [RFC2434]. This
registries, not does it require any other IANA assignments specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments.
5. Security Considerations 4. Security Considerations
Detection of Network Attachment (DNA) is typically insecure, so that it Detection of Network Attachment (DNA) is typically insecure, so that
is inadvisable for a host to adjust its security based on which network it is inadvisable for a host to adjust its security based on which
it believes it is attached to. For example, it would be inappropriate network it believes it is attached to. For example, it would be
for a host to disable its personal firewall based on the believe that it inappropriate for a host to disable its personal firewall based on
had connected to a home network. the believe 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 conclude that it remained attached to a former
network. Similarly, where DHCP [RFC2131] traffic is not secured, an network. Similarly, where DHCP [RFC2131] traffic is not secured, an
attacker could masquerade as a DHCP server, in order to convince the attacker could masquerade as a DHCP server, in order to convince the
host that it was attached to a particular network. 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 MAY
wish to skip the ARP-based reachability test entirely since it cannot be wish to skip the ARP-based reachability test entirely since it cannot
secured, and go immediately to the IPv4 address acquisition phase, be secured, and go immediately to the IPv4 address acquisition phase,
utilizing authenticated DHCP [RFC3118]. utilizing authenticated DHCP [RFC3118].
6. References 5. References
6.1. Normative References
[RFC791] Postel, J., "Internet Protocol", RFC 791, USC/Information 5.1. Normative References
Sciences Institute, September 1981.
[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 Converting Network Addresses to 48-bit Ethernet Address for
for Transmission on Ethernet Hardware", STD 37, RFC 826, Transmission on Ethernet Hardware", STD 37, RFC 826, November
November 1982. 1982.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
Xerox PARC, September 1991. PARC, September 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
2131, March 1997. March 1997.
[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, Silicon Graphics, Inc.,
Bucknell University, March 1997.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", Internet
draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-09.txt, September 2003.
6.2. Informative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Facilities", STD 13, RFC 1034, USC/Information Sciences Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell
Institute, November 1987. University, March 1997.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Specification", STD 13, RFC 1035, USC/Information Considerations Section in RFCs", BCP 26, RFC 2434, October
Sciences Institute, November 1987. 1998.
[RFC1058] Hedrick, C.L., "Routing Information Protocol", RFC 1058, [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
Rutgers University, June 1, 1988. RFC 3118, June 2001.
[RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
Merit, May 1992. of IPv4 Link-Local Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October
2003.
[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 5.2. Informative References
STD 51, RFC 1661, Daydreamer, July 1994.
[RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
Extensions for Name Server Addresses", RFC 1877, December 51, RFC 1661, Daydreamer, July 1994.
1995.
[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 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Authentication Protocol (EAP)", RFC 2284, March 1998. Protocol (EAP)", RFC 2284, March 1998.
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: [RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial
Port based Network Access Control, IEEE Std 802.1X-2001, In User Service (RADIUS) Usage Guidelines", RFC 3580,
June 2001. September 2003.
[IEEE8021AB]
IEEE Standards for Local and Metropolitan Area Networks:
Station and Media Access Control - Connectivity Discovery,
IEEE Std 802.1AB/D5, September 2003.
[IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks: Port
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:
Overview and Architecture, ANSI/IEEE Std 802, 1990. Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: [IEEE8021Q]
Draft Standard for Virtual Bridged Local Area Networks, IEEE Standards for Local and Metropolitan Area Networks: Draft
P802.1Q, January 1998. Standard for Virtual Bridged Local Area Networks, P802.1Q,
January 1998.
[IEEE8023] ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 3: Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications, (also ANSI/IEEE Std 802.3-
1996), 1996.
[IEEE80211] Information technology - Telecommunications and [IEEE80211]
information exchange between systems - Local and Information technology - Telecommunications and information
metropolitan area networks - Specific Requirements Part exchange between systems - Local and metropolitan area
11: Wireless LAN Medium Access Control (MAC) and networks - Specific Requirements Part 11: Wireless LAN Medium
Physical Layer (PHY) Specifications, IEEE Std. Access Control (MAC) and Physical Layer (PHY) Specifications,
802.11-1999, 1999. IEEE Std. 802.11-1999, 1999.
Acknowledgments Acknowledgments
The authors would like to acknowledge Erik Guttman and Erik Nordmark of The authors would like to acknowledge Erik Guttman and Erik Nordmark
Sun Microsystems, Ted Lemon of Nominum and Thomas Narten of IBM for of Sun Microsystems, Ted Lemon of Nominum and Thomas Narten of IBM
contributions to this document. for contributions to this document.
Authors' Addresses Authors' Addresses
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Phone: +1 425 706 6605 Phone: +1 425 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 IP associated with each network may be retained by the host. Based on
and link-layer information, the host may be able to make an educated IP and link-layer information, the host may be able to make an
guess as to whether it has moved between subnets, or remained on the educated guess as to whether it has moved between subnets, or
same subnet. If it is likely to have moved between subnets, the host remained on the same subnet. If it is likely to have moved between
may have an educated guess as to which subnet it has moved to. The term subnets, the host may have an educated guess as to which subnet it
"strong hint" refers to information which provides an unambiguous has moved to. The term "strong hint" refers to information which
indication of the network to which a host has connected. "Weak hints" provides an unambiguous indication of the network to which a host has
involve information which is inconclusive. connected. "Weak hints" involve information which is inconclusive.
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 directly relevant to determining the network to which a host has
connected. As such, information gleaned from Router Advertisements can connected. As such, information gleaned from Router Advertisements
be considered a "strong" hint. can be considered a "strong" hint.
For networks running over PPP [RFC1661], "weak" hints include the link For networks running over PPP [RFC1661], "weak" hints include the
characteristics negotiated in LCP, and the associated phone number. The link characteristics negotiated in LCP, and the associated phone
IP parameters negotiated in IPCP are considered a "strong" hint. number. The IP parameters negotiated in IPCP are considered a
"strong" hint.
On IEEE 802 wired networks, hints include link-layer discovery traffic On IEEE 802 [IEEE802] wired networks, hints include link-layer
as well as information exchanged as part of IEEE 802.1X authentication. discovery traffic as well as information exchanged as part of IEEE
Link-layer discovery traffic includes Link Layer Discovery Protocol 802.1X authentication [IEEE8021X]. Link-layer discovery traffic
[LLDP] traffic as well as network identification information passed in includes Link Layer Discovery Protocol [IEEE8021AB] traffic as well
the EAP-Request/Identity or within an EAP method exchange. 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 For example, LLDP advertisements can provide information on the IP
address or VLANs supported by the device. These hints, if provided, are address or VLANs supported by the device. These hints, if provided,
considered "strong"; all other hints are considered "weak". When used are considered "strong". When used with IEEE 802.1X authentication
with IEEE 802.1X authentication, the EAP-Request/Identity exchange may [IEEE8021X], the EAP-Request/Identity exchange may contain the name
contain the name of the authenticator, also providing information on the of the authenticator, also providing information on the potential
potential network. Similarly, during the EAP method exchange the network. Similarly, during the EAP method exchange the authenticator
authenticator may supply information that may be helpful in identifying may supply information that may be helpful in identifying the network
the network to which the device is attached. to which the device is attached. However, as noted in [RFC3580], it
is possible for the VLANID defined in [IEEE8021Q] to be assigned
dynamically, so this static information may not prove definitive. As
a result, these hints are considered "weak".
In IEEE 802.11 [IEEE80211] stations provide information in Beacon and/or In IEEE 802.11 [IEEE80211] stations provide information in Beacon
Probe Response messages, such as the SSID, BSSID, and capabilities, as and/or Probe Response messages, such as the SSID, BSSID, and
well as information on whether the station is operating in capabilities, as well as information on whether the station is
Infrastructure or Adhoc mode. As described in [Congdon], it is possible operating in Infrastructure or Adhoc mode. As described in
to assign a Station to a VLAN dynamically, based on the results of IEEE [RFC3580], it is possible to assign a Station to a VLAN dynamically,
802.1X [IEEE8021X] authentication. This implies that a single SSID may based on the results of IEEE 802.1X [IEEE8021X] authentication. This
offer access to multiple VLANs, and in practice most large WLAN implies that a single SSID may offer access to multiple VLANs, and in
deployments offer access to multiple subnets. practice most large WLAN deployments offer access to multiple
subnets.
Thus, associating to the same SSID is a necessary, but not necessarily a Thus, associating to the same SSID is a necessary, but not
sufficient condition, for remaining within the same subnet. While a necessarily a sufficient condition, for remaining within the same
Station associating to the same SSID may not necessarily remain within subnet. While a Station associating to the same SSID may not
necessarily remain within the same subnet; on the other hand, a
Station associating to a different SSID is likely to have changed
subnets.
the same subnet; on the other hand, a Station associating to a In order to provide additional guidance on the subnets to which a
different SSID is likely to have changed subnets. In order to provide given AP offers access, additional subnet-related Information
additional guidance on the subnets to which a given AP offers access, Elements (IEs) have been proposed for addition to the IEEE 802.11
additional subnet-related Information Elements (IEs) have been proposed Beacon and Probe Response messages. Such hints are considered
for addition to the IEEE 802.11 Beacon and Probe Response messages. "strong"; all other IEEE 802.11 hints are considered "weak".
Such hints are considered "strong"; all other IEEE 802.11 hints are
considered "weak".
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 pertain intellectual property or other rights that might be claimed to
to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might or this document or the extent to which any license under such rights
might not be available; neither does it represent that it has made any might or might not be available; neither does it represent that it
effort to identify any such rights. Information on the IETF's has made any effort to identify any such rights. Information on the
procedures with respect to rights in standards-track and standards- IETF's procedures with respect to rights in standards-track and
related documentation can be found in BCP-11. Copies of claims of standards-related documentation can be found in BCP-11. Copies of
rights made available for publication and any assurances of licenses to claims of rights made available for publication and any assurances of
be made available, or the result of an attempt made to obtain a general licenses to be made available, or the result of an attempt made to
license or permission for the use of such proprietary rights by obtain a general license or permission for the use of such
implementors or users of this specification can be obtained from the proprietary rights by implementors or users of this specification can
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 rights copyrights, patents or patent applications, or other proprietary
which may cover technology that may be required to practice this rights which may cover technology that may be required to practice
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 (2003). 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 or others, and derivative works that comment on or otherwise explain it
assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are included kind, provided that the above copyright notice and this paragraph are
on all such copies and derivative works. However, this document itself included on all such copies and derivative works. However, this
may not be modified in any way, such as by removing the copyright notice document itself may not be modified in any way, such as by removing
or references to the Internet Society or other Internet organizations, the copyright notice or references to the Internet Society or other
except as needed for the purpose of developing Internet standards in Internet organizations, except as needed for the purpose of
which case the procedures for copyrights defined in the Internet developing Internet standards in which case the procedures for
Standards process must be followed, or as required to translate it into copyrights defined in the Internet Standards process must be
languages other than English. The limited permissions granted above are followed, or as required to translate it into languages other than
perpetual and will not be revoked by the Internet Society or its English. The limited permissions granted above are perpetual and
successors or assigns. This document and the information contained will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Open issues Open issues
Open issues relating to this specification are tracked on the following Open issues relating to this specification are tracked on the
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-01.txt>, and expires This memo is filed as <draft-ietf-dhc-dna-ipv4-02.txt>, and expires
February 22, 2004. February 22, 2004.
 End of changes. 

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