1. Introduction
The time required to detect movement between networks and to obtain
(or to continue to use) an operable IPv4 configuration may be
significant as a fraction of the total handover latency in moving
between points of attachment.
This document synthesizes, from experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [RFC3927], a set of steps known as Detecting Network
Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of
re-attachment to a network that one has been connected to previously
by attempting to re-use a previous (but still valid) configuration,
reducing the re-attachment time on LANs to a few milliseconds. Since
this procedure is dependent on the ARP protocol, it is not suitable
for use on media that do not support ARP.
1.1. Applicability
DHCP is an effective and widely adopted mechanism for a host to
obtain an IP address for use on a particular network link, or to
re-validate a previously obtained address via DHCP's INIT-REBOOT
mechanism [RFC2131].
When obtaining a new address, DHCP specifies that the client SHOULD
use ARP to verify that the offered address is not already in use.
The process of address conflict detection [ACD] can take as much as
seven seconds. In principle, this time interval could be shortened,
with the obvious trade-off: the less time a host spends waiting to
see if another host is already using its intended address, the
greater the risk of inadvertent address conflicts.
Where the client successfully re-validates a previously obtained
address using the INIT-REBOOT mechanism, the DHCP specification does
not require the client to perform address conflict detection, so this
seven-second delay does not apply. However, the DHCP server may be
slow to respond or may be down and not responding at all, so hosts
could benefit from having an alternative way to quickly determine
that a previously obtained address is valid for use on this
particular link.
When the client moves between networks, the address re-validation
attempt may be unsuccessful; a DHCPNAK may be received in response to
a DHCPREQUEST, causing the client to restart the configuration
process by moving to the INIT state. If an address previously
obtained on the new network is still operable, DNAv4 enables the host
to confirm the new configuration quickly, bypassing restart of the
configuration process and conflict detection.
The alternative mechanism specified by this document applies when a
host has a previously allocated DHCP address, which was not returned
to the DHCP server via a DHCPRELEASE message, and which still has
time remaining on its lease. In this case, the host may determine
whether it has re-attached to the logical link where this address is
valid for use, by sending a unicast ARP Request packet to a router
previously known for that link (or, in the case of a link with more
than one router, by sending one or more unicast ARP Request packets
to one or more of those routers).
The use of unicast ARP has a number of benefits. One benefit is that
unicast packets impose less burden on the network than broadcast
packets, particularly on 802.11 networks where broadcast packets may
be sent at rates as low as 1 Mb/sec. Another benefit is that if the
host is not on the link it hoped to find itself on, a broadcast ARP
Request could pollute the ARP caches of peers on that link. When
using private addresses [RFC1918], another device could be
legitimately using the same address, and a broadcast ARP Request
could disrupt its communications, causing TCP connections to be
broken, and similar problems. Also, using a unicast ARP packet
addressed to the MAC address of the router the host is expecting to
find means that if the host is not on the expected link there will be
no device with that MAC address, and the ARP packet will harmlessly
disappear into the void without doing any damage.
These issues that define the applicability of DNAv4 lead us to a
number of conclusions:
o DNAv4 is a performance optimization. Its purpose is to speed
up a process that may require as much as a few hundred
milliseconds (DHCP INIT-REBOOT), as well as to reduce multi-
second conflict detection delays when a host changes networks.
o As a performance optimization, it must not sacrifice
correctness. In other words, false positives are not
acceptable. DNAv4 must not conclude that a host has returned
to a previously visited link where it has an operable IP
address if this is not in fact the case.
o As a performance optimization, false negatives are acceptable.
It is not an absolute requirement that this optimization
correctly recognize a previously visited link in all possible
cases. For example, if a router ignores unicast ARP Requests,
then DNAv4 will not be able to detect that it has returned to
the same link in the future. This is acceptable because the
host still operates correctly as it did without DNAv4, just
without the performance benefit. Users and network operators
who desire the performance improvement offered by DNAv4 can
upgrade their routers to support DNAv4.
o As a performance optimization, where DNAv4 fails to provide a
benefit, it should add little or no delay compared to today's
DHCP processing. In practice, this implies that DHCP
processing needs to proceed in parallel. Waiting for DNAv4 to
fail before beginning DHCP processing can greatly increase
total processing time, the opposite of the desired effect.
o Trials are inexpensive. DNAv4 performs its checks using small
unicast packets. An IPv4 ARP packet on Ethernet is just 42
octets, including the Ethernet header. This means that the
cost of an unsuccessful attempt is small, whereas the cost of a
missed opportunity (having the right address available as a
candidate and choosing not to try it for some reason) is large.
As a result, the best strategy is often to try all available
candidate configurations, rather than try to determine which
candidates, if any, may be correct for this link, based on
heuristics or hints. For a heuristic to offer the prospect of
being a potentially useful way to eliminate inappropriate
configurations from the candidate list, that heuristic has to
(a) be fast and inexpensive to compute, as compared to sending
a 42-octet unicast packet, and (b) have high probability of not
falsely eliminating a candidate configuration that could be
found to be the correct one.
o Time is limited. If DNAv4 is to be effective in enabling low
latency handoffs, it needs to complete in less than 10 ms.
This implies that any heuristic used to eliminate candidate
configurations needs to take at most a few milliseconds to
compute. This does not leave much room for heuristics based on
observation of link-layer or Internet-layer traffic.
In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
1.3. Terminology
This document uses the following terms:
ar$sha
ARP packet field: Sender Hardware Address [RFC826]. The hardware
(MAC) address of the originator of an ARP packet.
ar$spa
ARP packet field: Sender Protocol Address [RFC826]. For IP
Address Resolution, this is the IPv4 address of the sender of the
ARP packet.
ar$tha
ARP packet field: Target Hardware Address [RFC826]. The hardware
(MAC) address of the target of an ARP packet.
ar$tpa
ARP packet field: Target Protocol Address [RFC826]. For IPv4
Address Resolution, the IPv4 address for which one desires to know
the hardware address.
DHCP client
A DHCP client or "client" is an Internet host using the Dynamic
Host Configuration Protocol (DHCP) [RFC2131] to obtain
configuration parameters, such as a network address.
DHCP server
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
Link
A communication facility or medium over which network nodes can
communicate. Each link is associated with a minimum of two
endpoints. Each link endpoint has a unique link-layer identifier.
Link Down
An event provided by the link layer that signifies a state change
associated with the interface's no longer being capable of
communicating data frames; transient periods of high frame loss
are not sufficient. DNAv4 does not utilize "Link Down"
indications.
Link Layer
Conceptual layer of control or processing logic that is
responsible for maintaining control of the data link. The data
link layer functions provide an interface between the higher-layer
logic and the data link. The link layer is the layer immediately
below IP.
Link Up
An event provided by the link layer that signifies a state change
associated with the interface's becoming capable of communicating
data frames.
Point of Attachment
The link endpoint on the link to which the host is currently
connected.
Routable address
In this specification, the term "routable address" refers to any
unicast IPv4 address other than an IPv4 Link-Local address. This
includes private addresses as specified in "Address Allocation for
Private Internets" [RFC1918].
Operable address
In this specification, the term "operable address" refers either
to a static IPv4 address, or an address assigned via DHCPv4 that
has not been returned to the DHCP server via a DHCP RELEASE
message, and whose lease has not yet expired.
