draft-ietf-dhc-dna-ipv4-07.txt   draft-ietf-dhc-dna-ipv4-08.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-07.txt> <draft-ietf-dhc-dna-ipv4-08.txt>
14 April 2004 18 July 2004
Detection of Network Attachment (DNA) in IPv4 Detection of Network Attachment (DNA) in IPv4
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3667. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2004. This Internet-Draft will expire on January 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The time required to detect movement (or lack of movement) between The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may subnets, and to obtain (or continue to use) a valid IPv4 address may
be significant as a fraction of the total delay in moving between be significant as a fraction of the total delay in moving between
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.2 Reachability Test ............................... 6 2.2 Reachability Test ............................... 6
2.3 IPv4 Address Acquisition ........................ 8 2.3 IPv4 Address Acquisition ........................ 8
2.4 Link-Local IPv4 Addresses ....................... 9 2.4 Link-Local IPv4 Addresses ....................... 9
3. Constants ................................................ 10 3. Constants ................................................ 10
4. IANA Considerations ...................................... 10 4. IANA Considerations ...................................... 10
5. Security Considerations .................................. 10 5. Security Considerations .................................. 10
6. References ............................................... 11 6. References ............................................... 11
6.1 Normative references ............................ 11 6.1 Normative references ............................ 11
6.2 Informative references .......................... 11 6.2 Informative references .......................... 11
Acknowledgments .............................................. 12 Acknowledgments .............................................. 12
Authors' Addresses ........................................... 13 Authors' Addresses ........................................... 12
Appendix A - Link Layer Hints ................................ 14 Appendix A - Link Layer Hints ................................ 13
A.1 Introduction .................................... 14 A.1 Introduction .................................... 13
A.2 Hints ........................................... 15 A.2 Hints ........................................... 14
Intellectual Property Statement .............................. 16 Intellectual Property Statement .............................. 15
Full Copyright Statement ..................................... 17 Disclaimer of Validity ....................................... 15
Copyright Statement .......................................... 16
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 (MLPA),
reachability testing, and IPv4 address acquisition. reachability testing, and IPv4 address acquisition.
This document concerns the interaction of mechanisms used by IPv4 Since this procedure is dependent on the ARP protocol, it is not
protocol stacks. Network attachment detection and its interaction suitable for use on media that do not support ARP [RFC826].
with interface configuration is considered elsewhere, for example in
Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless Address
Autoconfiguration [RFC2462] and Mobility Support in IPv6 [MIPv6].
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
skipping to change at page 4, line 18 skipping to change at page 4, line 13
the hardware address. the hardware address.
DHCP client DHCP client
A DHCP client or "client" is an Internet host using DHCP to obtain A DHCP client or "client" is an Internet host using 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.
Point of Attachment
A location within the network where a host may be connected. This
attachment point can be characterized by its address prefix and
next hop routing information.
Most Likely Point of Attachment (MLPA)
The point of attachment heuristically determined by the host to be
most likely, based on hints from the network.
Routable address Routable address
In this specification, the term "routable address" refers to any In this specification, the term "routable address" refers to any
address other than an Link-Local IPv4 address. This includes address other than an Link-Local IPv4 address. This includes
private addresses as specified in [RFC1918]. private addresses as specified in [RFC1918].
Valid address Valid address
In this specification, the term "valid address" refers to either a In this specification, the term "valid address" refers to either a
static IPv4 address, or an address assigned via DHCPv4 which has static IPv4 address, or an address assigned via DHCPv4 which has
not been relinquished, and whose lease has not yet expired. not been relinquished, and whose lease has not yet expired.
skipping to change at page 4, line 50 skipping to change at page 5, line 5
associated with the new point of attachment. Since associated with the new point of attachment. Since
hints are not infallible, the host should be capable of hints are not infallible, the host should be capable of
making the correct determination even in the presence of making the correct determination even in the presence of
misleading hints. For details see Appendix A. misleading hints. For details see Appendix A.
[b] Treatment of link-up indications. On connecting [b] Treatment of link-up indications. On connecting
to a new point of attachment, the host attempts to to a new point of attachment, the host attempts to
verify the "most likely" configuration associated verify the "most likely" configuration associated
with the new point of attachment. with the new point of attachment.
[c] Treatment of link-down indications. On disconnection [c] Handling of Link-Local IPv4 addresses. Experience has
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.
[d] Handling of Link-Local IPv4 addresses. Experience has
shown that Link-Local IPv4 addresses are often assigned shown that Link-Local IPv4 addresses are often assigned
inappropriately. This document suggests that hosts inappropriately. This document suggests that hosts
behave conservatively with respect to assignment of behave conservatively with respect to assignment of
Link-Local IPv4 addresses, configuring them only in Link-Local IPv4 addresses, configuring them only in
situations in which they can do no harm. situations in which they can do no harm.
2.1. Most Likely Point of Attachment 2.1. Most Likely Point of Attachment
In order to determine the "most likely" point of attachment it is In order to determine the MLPA, it is assumed that the host is
assumed that the host is capable of obtaining and writing to stable capable of obtaining and writing to stable storage parameters
storage parameters relating to networks that it connects to, relating to networks that it connects to, including:
including:
[1] Link layer hints associated with each network. [1] Link layer hints associated with each network.
For details, see Appendix A. For details, see Appendix A.
[2] The IPv4 and MAC address of the default gateway(s) on [2] The IPv4 and MAC address of the default gateway(s) on
each network. each network.
[3] Whether a network is an infrastructure or adhoc network. [3] Whether a network is an infrastructure or adhoc 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. In the absence of other information, by network it has attached to. In the absence of other information, by
default the host may assume that the "most likely" point of default the host may assume that the MLPA is the network to which it
attachment is the network to which it was most recently attached. was most recently attached.
2.1.1. Alternative Mechanisms 2.1.1. Alternative Mechanisms
Aside from utilizing link layer hints, a host may also be able to Aside from utilizing link layer hints, a host may also be able to
utilize Internet layer information in order to determine the "most utilize Internet layer information in order to determine the MLPA.
likely" point of attachment.
IPv4 ICMP Router Discovery messages [RFC1256] provide information IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link, as well as the routers relating to prefix(es) available on the link, as well as the routers
that serve those prefix(es). A host may use ICMP Router Discovery to that serve those prefix(es). A host may use ICMP Router Discovery to
conclude that an advertised prefix is available; however it cannot conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are conclude the converse -- that prefixes not advertised are
unavailable. unavailable.
However, since [RFC1256] is not widely implemented, in general, it is However, since [RFC1256] is not widely implemented, in general, it is
NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as
skipping to change at page 6, line 4 skipping to change at page 5, line 47
IPv4 ICMP Router Discovery messages [RFC1256] provide information IPv4 ICMP Router Discovery messages [RFC1256] provide information
relating to prefix(es) available on the link, as well as the routers relating to prefix(es) available on the link, as well as the routers
that serve those prefix(es). A host may use ICMP Router Discovery to that serve those prefix(es). A host may use ICMP Router Discovery to
conclude that an advertised prefix is available; however it cannot conclude that an advertised prefix is available; however it cannot
conclude the converse -- that prefixes not advertised are conclude the converse -- that prefixes not advertised are
unavailable. unavailable.
However, since [RFC1256] is not widely implemented, in general, it is However, since [RFC1256] is not widely implemented, in general, it is
NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as
an alternative to the reachability test outlined in Section 2.2. an alternative to the reachability test outlined in Section 2.2.
Instead, ICMP Router Advertisements can be used to obtain information Instead, ICMP Router Advertisements can be used to obtain information
on available prefixes and default gateway(s). This can provide on available prefixes and default gateway(s). This can provide
additional resilience in the case where default gateway(s) become additional resilience in the case where default gateway(s) become
unavailable. unavailable.
Similarly, hosts that support routing protocols such as RIP and OSPF Similarly hosts that support routing protocols such as RIP and OSPF
can use these protocols to determine the prefix(es) available on a can use these protocols to determine the prefix(es) available on a
link and the default gateway(s) that serve those prefixes. link and the default gateway(s) that serve those prefixes. Note that
full support is not required to glean this information. A host that
passively observes routing protocol traffic may deduce this
information without supporting a full conforming implementation of
the routing protocol.
2.2. Reachability Test 2.2. Reachability Test
If the host has a valid routable IPv4 address on the "most likely" If the host has a valid routable IPv4 address on the MLPA, the host
point of attachment, the host will typically perform a reachability will typically perform a reachability test, in order to to confirm
test, as described in this section. The purpose of the reachability that the host is connected to a network on which it has a valid
test is to confirm whether the host is connected to a network on routable IPv4 address. If the reachability test is not successful,
which it has a valid routable IPv4 address. the host proceeds to the IPv4 address acquisition phase, described in
Section 2.3.
If the reachability test is not successful, or if the host does not The host skips the reachability test and proceeds to the IPv4 address
have a valid routable IPv4 address on the "most likely" point of acquisition phase, if any of the following conditions are true:
attachment, the host proceeds to the IPv4 address acquisition phase,
described in Section 2.3.
The host skips the reachability test in the following circumstances: [a] The host does not have a valid routable IPv4
address on the MLPA. In this case, the reachability
test cannot confirm that the host has a valid
routable IPv4 address, so that it is unnecessary.
[a] If the host does not have a valid routable IPv4 [b] The host does not have information on the default
address on the "most likely" point of attachment. gateway(s) for the MLPA. In this case, it is not
possible to carry out the reachability test.
[b] If reliable hints are unavailable. Since confirming [c] Reliable hints are unavailable. Since confirming
failure of the reachability test requires a timeout, failure of the reachability test requires a timeout,
mistakes are costly. In the absence of reliable mistakes are costly. In the absence of reliable
hints, a host SHOULD instead send a DHCPREQUEST from hints, a host SHOULD instead send a DHCPREQUEST from
the INIT-REBOOT state, as described in [RFC2131], the INIT-REBOOT state, as described in [RFC2131],
Section 3.2 and 4.3.2. Section 3.2 and 4.3.2. Where reliable hints are
unavailable, this will on average complete more
[c] If the host does not have information on the default quickly than the reachability test.
gateway(s) for the "most likely" point of attachment.
[d] If secure detection of network attachment is required. [d] If secure detection of network attachment is required.
See Section 5 for details. The reachability test utilizes ARP which is insecure,
whereas DHCP can be secured via DHCP authentication,
described in [RFC3118]. See Section 5 for details.
The reachability test is performed by attempting to verify The reachability test is performed by attempting to verify
reachability of default gateway(s) on the "most likely" point of reachability of default gateway(s) on the MLPA. This reduces roaming
attachment. This reduces roaming latency by allowing the host to latency by allowing the host to bypass DHCP as well as subsequent
bypass DHCP as well as subsequent Duplicate Address Detection (DAD). Duplicate Address Detection (DAD). In contrast to a DHCP exchange,
In contrast to a DHCP exchange, which may be between a DHCP client which may be between a DHCP client and an off-link DHCP server, the
and an off-link DHCP server, the reachability test occurs between a reachability test occurs between a host and its next hop router.
host and its next hop router.
The host may probe only the primary default gateway, or it may probe The host may probe only the primary default gateway, or it may probe
primary and secondary default gateways, in series or in parallel. If primary and secondary default gateways, in series or in parallel. If
the reachability test is successful, the host may continue to use a the reachability test is successful, the host may continue to use a
valid routable IPv4 address without having to re-acquire it. valid routable IPv4 address without having to re-acquire it.
However, in order to ensure configuration validity, the host SHOULD However, in order to ensure configuration validity, the host SHOULD
only configure default gateway(s) which pass the reachability test. only configure default gateway(s) which pass the reachability test.
2.2.1. Packet Format 2.2.1. Packet Format
skipping to change at page 8, line 23 skipping to change at page 8, line 23
gateway has changed, as long as the IPv4 address remains the same. gateway has changed, as long as the IPv4 address remains the same.
This can occur, for example, where a host moves from one home This can occur, for example, where a host moves from one home
network using prefix 192.168/16 to another one. In addition, if the network using prefix 192.168/16 to another one. In addition, if the
ping is sent with TTL > 1, then an ICMP Echo Response can be received ping is sent with TTL > 1, then an ICMP Echo Response can be received
from an off-link gateway. 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_TIMEOUT and proceeds to the IPv4 address acquisition for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition
phase. If a valid ARP Response is received, but cannot be matched phase. If a valid ARP Response is received, but cannot be matched
against known networks, the host assumes it has moved subnets and against known networks, the host assumes it has moved subnets and
moves on to the address acquisition phase. moves on to the IPv4 address acquisition phase.
2.3. IPv4 Address Acquisition 2.3. IPv4 Address Acquisition
If the host has a valid routable IPv4 address on the "most likely" If the host has a valid routable IPv4 address on the MLPA but the
point of attachment, but the reachability test fails, then the host reachability test fails, then the host SHOULD verify the
SHOULD 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 routable IPv4 address on the "most If the host does not have a valid routable IPv4 address on the MLPA,
likely" point of attachment, the host enters the INIT state and sends the host enters the INIT state and sends a DHCPDISCOVER packet to the
a DHCPDISCOVER packet to the broadcast address, as described in broadcast address, as described in [RFC2131] Section 4.4.1. If the
[RFC2131] Section 4.4.1. host supports the Rapid Commit Option [RAPID], it is possible that
the exchange can be shortened from a 4-message exchange to a
2-message exchange.
If the host does not receive a response to a DHCPREQUEST or If the host does not receive a response to a DHCPREQUEST or
DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
4.1. 4.1.
As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING
state that knows the address of a DHCP server may use that address in state that knows the address of a DHCP server may use that address in
the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast
address. In the INIT-REBOOT state a DHCPREQUEST is sent to the address. In the INIT-REBOOT state a DHCPREQUEST is sent to the
broadcast address so that the host will receive a response regardless broadcast address so that the host will receive a response regardless
skipping to change at page 9, line 16 skipping to change at page 9, line 18
2.4. Link-Local IPv4 Addresses 2.4. Link-Local IPv4 Addresses
To avoid inappropriate assignment of Link-Local IPv4 addresses, it is To avoid inappropriate assignment of Link-Local IPv4 addresses, it is
recommended that hosts behave conservatively with respect to recommended that hosts behave conservatively with respect to
assignment of Link-Local IPv4 addresses. As described in [IPv4LL] assignment of Link-Local IPv4 addresses. As described in [IPv4LL]
Section 1.7, use of a routable address is preferred to a Link-Local Section 1.7, use of a routable address is preferred to a Link-Local
IPv4 address whenever it is available. IPv4 address whenever it is available.
Where the host does not have a valid routable IPv4 address on the Where the host does not have a valid routable IPv4 address on the
"most likely" point of attachment, the host MAY configure an Link- MLPA, the host MAY configure an Link-Local IPv4 address prior to
Local IPv4 address prior to entering the INIT state and sending a entering the INIT state and sending a DHCPDISCOVER packet, as
DHCPDISCOVER packet, as described in Section 2.3. However, should a described in Section 2.3. However, should a routable IPv4 address be
routable IPv4 address be obtained, the Link-Local IPv4 address is obtained, the Link-Local IPv4 address is deprecated, as noted in
deprecated, as noted in [IPv4LL]. [IPv4LL].
Where a host has a valid routable IPv4 address on the "most likely" Where a host has a valid routable IPv4 address on the MLPA, but the
point of attachment, but the DHCP client does not receive a response DHCP client does not receive a response after employing the
after employing the retransmission algorithm, [RFC2131] Section 3.2 retransmission algorithm, [RFC2131] Section 3.2 states that the
states that the client MAY choose to use the previously allocated client MAY choose to use the previously allocated network address and
network address and configuration parameters for the remainder of the configuration parameters for the remainder of the unexpired lease.
unexpired lease. Where a host can confirm that it remains connected Where a host can confirm that it remains connected to a point of
to a point of attachment on which it possesses a valid routable IPv4 attachment on which it possesses a valid routable IPv4 address, that
address, that address SHOULD be used, rather than assigning a Link- address SHOULD be used, rather than assigning a Link-Local IPv4
Local IPv4 address. 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.
As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address
is assigned, existing implementations do not query the DHCPv4 server is assigned, existing implementations do not query the DHCPv4 server
again for 5 minutes. This behavior is in violation of [RFC2131] again for 5 minutes. This behavior is in violation of [RFC2131]
Section 4.1. Section 4.1.
skipping to change at page 10, line 25 skipping to change at page 10, line 28
router for forwarding. router for forwarding.
3. Constants 3. Constants
The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This
value was chosen so as to accommodate the maximum retransmission value was chosen so as to accommodate the maximum retransmission
timer likely to be experienced on an Ethernet network. timer likely to be experienced on an Ethernet network.
4. IANA Considerations 4. IANA Considerations
Guidelines for IANA considerations are specified in [RFC2434]. This 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 based on ARP and DHCP. ARP
it is inadvisable for a host to adjust its security based on which [RFC826] traffic is inherently insecure, so that the reachability
network it believes it is attached to. For example, it would be
inappropriate for a host to disable its personal firewall based on
the belief that it had connected to a home network.
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 falsely conclude that it is attached to a network leading a host to falsely conclude that it is attached to a network
that it is not connected to. Similarly, where DHCP traffic is not that it is not connected to. Similarly, where DHCP traffic is not
secured, an attacker could masquerade as a DHCP server, in order to secured, an attacker could masquerade as a DHCP server, in order to
convince the host that it was attached to a particular network. convince the host that it was attached to a particular network.
As a result, 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 inappropriate for a host to disable its personal firewall
based on the belief that it had connected to a home network.
Where secure detection of network attachment is required, a host Where secure detection of network attachment is required, a host
SHOULD skip the reachability test since it cannot be secured, and SHOULD skip the reachability test since it cannot be secured, and
instead utilize authenticated DHCP [RFC3118]. instead utilize authenticated DHCP [RFC3118], possibly in combination
with the Rapid Commit Option [RAPID].
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 11, line 31 skipping to change at page 11, 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 Link-Local IPv4 Addresses", Internet draft (work in of Link-Local IPv4 Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, April progress), draft-ietf-zeroconf-ipv4-linklocal-17.txt, July
2004. 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.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[MIPv6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.
[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.
[RFC3748] Blunk, L., et al., "Extensible Authentication Protocol (EAP)", [RFC3748] Aboba, B., et al., "Extensible Authentication Protocol (EAP)",
RFC 3748, March 2004. RFC 3748, June 2004.
[RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
DHCPv4", Internet draft (work in progress), draft-ietf-dhc-
rapid-commit-opt-05.txt, June 2004.
[IEEE8021AB] [IEEE8021AB]
IEEE Standards for Local and Metropolitan Area Networks: IEEE Standards for Local and Metropolitan Area Networks:
Station and Media Access Control - Connectivity Discovery, Station and Media Access Control - Connectivity Discovery,
IEEE Std 802.1AB/D5, September 2003. IEEE Std 802.1AB/D5, September 2003.
[IEEE8021X] [IEEE8021X]
IEEE Standards for Local and Metropolitan Area Networks: Port IEEE Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Std 802.1X-2004, June 2004. based Network Access Control, IEEE Std 802.1X-2004, June 2004.
skipping to change at page 12, line 37 skipping to change at page 12, line 27
[IEEE8021Q] [IEEE8021Q]
IEEE Standards for Local and Metropolitan Area Networks: Draft IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks, P802.1Q, Standard for Virtual Bridged Local Area Networks, P802.1Q,
January 1998. January 1998.
[IEEE80211] [IEEE80211]
Information technology - Telecommunications and information Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area exchange between systems - Local and metropolitan area
networks - Specific Requirements Part 11: Wireless LAN Medium networks - Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications, Access Control (MAC) and Physical Layer (PHY) Specifications,
IEEE Std. 802.11-1999, 1999. IEEE Std. 802.11-2003, 2003.
Acknowledgments Acknowledgments
The authors would like to acknowledge Greg Daley of Monash The authors would like to acknowledge Greg Daley of Monash
University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted
Lemon of Nominum and Thomas Narten of IBM for contributions to this Lemon of Nominum and Thomas Narten of IBM for contributions to this
document. document.
Authors' Addresses Authors' Addresses
skipping to change at page 16, line 22 skipping to change at page 15, line 22
In IEEE 802.11, the presence of an IBSS can be used as a hint that a In IEEE 802.11, the presence of an IBSS can be used as a hint that a
point of attachment supports adhoc networking, and therefore that point of attachment supports adhoc networking, and therefore that
assignment of a Link-Local IPv4 address is likely. When running IPv4 assignment of a Link-Local IPv4 address is likely. When running IPv4
over PPP, if an IP address is not statically configured or assigned over PPP, if an IP address is not statically configured or assigned
via IPCP, this can also be taken as a hint that assignment of a Link- via IPCP, this can also be taken as a hint that assignment of a Link-
Local IPv4 address is likely. In addition, certain media such as USB Local IPv4 address is likely. In addition, certain media such as USB
or IEEE 1394 may be considered inherently more likely to support or IEEE 1394 may be considered inherently more likely to support
adhoc operation, so that connection to these networks may by itself adhoc operation, so that connection to these networks may by itself
be considered a hint. be considered a hint.
Intellectual Property Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
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
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at page 17, line 5 skipping to change at page 15, line 44
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
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 Disclaimer of Validity
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
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
This memo is filed as <draft-ietf-dhc-dna-ipv4-07.txt>, and expires
October 22, 2004.
 End of changes. 

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