Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is
not appropriate, since if the DHCP client has moved to another
subnet, a DHCP server response cannot be routed back to the client
since the DHCPREQUEST will bypass the DHCP relay and will contain an
invalid source address.
2.3. IPv4 Link-Local Addresses
DNAv4 applies only to previously configured addresses that had some
lease lifetime associated with them, during which lifetime the
address may be legitimately regarded as being reserved for exclusive
use by the assigned host. DHCP-assigned addresses fit this
description, but IPv4 Link-Local address [RFC3927] do not, since IPv4
Link-Local addresses are not handed out by an authoritative server
and do not come with any guaranteed usable lifetime.
A host’s claim on an IPv4 Link-Local address is valid only as long as
that host remains connected to the link, actively defending against
probes for its chosen address. As soon as a host shuts down, sleeps,
or otherwise disconnects from a link, it immediately relinquishes any
claim it may have had on any IPv4 Link-Local address on that link. A
host wishing to reclaim a previously used IPv4 Link-Local address
MUST perform the full probing and announcement process required by
"Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] and
MUST NOT attempt to use DNAv4 as a shortcut to bypass that process.
Where the host does not have an operable routable IPv4 address on any
network, the host MAY configure an IPv4 Link-Local address prior to
entering the INIT state and sending a DHCPDISCOVER packet, as
described in Section 2.3 of the DHCP specification [RFC2131]. Where
a host can confirm that it remains connected to a network on which it
possesses an operable routable IPv4 address, that address should be
used, and the IPv4 Link-Local address is deprecated, as noted in
Section 1.9 of the IPv4 Link-Local specification [RFC3927].
Where a host has an operable routable IPv4 address on one or more
networks but the reachability test cannot confirm the configuration
and the DHCPv4 client does not receive a response after employing the
retransmission algorithm, Section 3.2 of the DHCP specification
[RFC2131] states that the client MAY choose to use the previously
allocated network address and configuration parameters for the
remainder of the unexpired lease.
2.4. Manually Assigned Addresses
An implementation may use DNAv4 to confirm the configuration of
manually assigned addresses. However, special consideration is
required for this to produce reliable results, so it SHOULD NOT be
enabled by default.
For the purposes of DNAv4, manually assigned addresses may be treated
as equivalent to DHCP-assigned addresses with an infinite lifetime.
This does not significantly increase the probability of an address
conflict as long as the manually assigned address is reserved by the
DHCP server or is outside the scope of addresses assigned by a DHCP
server. However, where the manually assigned address is within an
address scope utilized by a DHCP server, it is possible that the host
will be unavailable when the DHCP server checks for a conflict prior
to assigning the conflicting address. In this case, a host utilizing
DNAv4 could confirm an address that had been assigned to another
host.
Typically, an address is manually assigned on a network because a
dynamically assigned address was not suitable for some reason.
Therefore, where DNAv4 and DHCP are run in parallel and DNAv4
confirms a manual configuration, it may be undesirable to allow this
configuration to be overridden by DHCP, as described in Section 2.1.
However, packet loss may cause the reachability test to fail while
DHCP completes successfully, resulting in the host obtaining a
dynamic address where a static address is desired. In order to
provide for reliable reconfirmation of manually assigned addresses,
reachability tests for manual configurations require a more
aggressive retransmission strategy than that detailed in Section 4.1
of the DHCP specification [RFC2131]. For example, shorter
retransmission intervals and more persistent retransmissions may be
required.
3. Security Considerations
Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and
DHCP and inherits the security vulnerabilities of these two
protocols.
ARP [RFC826] traffic is not secured, so an attacker gaining access to
the network can spoof a response to the reachability test described
in Section 2.1, leading the querier to conclude falsely that it is
attached to a network that it is not connected to.
Similarly, where DHCPv4 traffic is not secured, an attacker could
masquerade as a DHCPv4 server, in order to convince the host that it
was attached to a particular network. This and other threats
relating to DHCPv4 are described in "Authentication for DHCP
Messages" [RFC3118].
The effect of these attacks will typically be limited to denial of
service, unless the host utilizes its IP configuration for other
purposes, such as security configuration or location determination.
For example, a host that disables its personal firewall based on
evidence that it had attached to a home network could be compromised
by spoofing of the DNAv4 reachability test. In general, adjustment
of the security configuration based on DNAv4 is NOT RECOMMENDED.
Hosts that depend on secure IP configuration SHOULD NOT use DNAv4 but
SHOULD instead utilize DHCP authentication [RFC3118], possibly in
combination with the Rapid Commit Option [RFC4039].
4. References
4.1. Normative References
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, RFC
826, November 1982.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
4.2. Informative References
[ACD] Cheshire, S., "IPv4 Address Conflict Detection", Work in
Progress, July 2005.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
the Dynamic Host Configuration Protocol version 4
(DHCPv4)", RFC 4039, March 2005.
5. Acknowledgements
The authors would like to acknowledge Greg Daley of Monash
University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ralph
Droms of Cisco Systems, Ted Lemon of Nominum, John Loughney of Nokia,
Thomas Narten of IBM and David Hankins of ISC for contributions to
this document.
Authors’ Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 818 4011
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
James Carlson
Sun Microsystems, Inc
1 Network Drive
Burlington, MA 01803-2757
USA
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino, California 95014, USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).