Transcript DNA for IPv4

Detection of Network
Attachment (DNA) in
IPv4
Bernard Aboba
Microsoft
Draft-aboba-dhc-nad-ipv4-00.txt
DNA BOF
IETF 57
Vienna, Austria
Monday, July 15, 2003
http://www.drizzle.com/~aboba/IETF57/DNA/
Why the Interest in DNAv4?

Discussion in ZEROCONF WG on use of IPv4 linklocal
addresses
 Today’s hosts are often mobile




May or may not implement Mobile IP.
IP configuration latency a significant fraction of total roaming latency
(>50%)
Assignment of an IPv4 linklocal address typically the result of a
bug in the host or a network fault, not detection of an adhoc
network
How do we make address assignment more resilient?




Less likely to assign IPv4 linklocal addresses inappropriately
Able to recover from an IPv4 LL assignment
Able to quickly recognize when they have reattached to the same
subnet
Able to quickly obtain an address & configuration when they have
connected to a new subnet
DNAv4 Model

“Hints” – non-definitive indications whether the host has
connected to a previously encountered subnet



“Most Likely” point of attachment (POA)



Best guess, based on hints
By default: previous point of attachment
Reachability detection



L2 hints: 802.11 SSID, Infrastructure/Adhoc, IEEE 802 LLDP
traffic
L3 hints: IRDP
ARP Request sent to “most likely” default gateway
If “most likely” POA was autoconf, then ARP Request sent to
an autoconf neighbor
Address re-acquisition


Used only if client retains a valid lease
DHCPREQUEST sent in INIT-REBOOT state
DNAv4 Strawman Proposal

Formulate “most likely” point of attachment
 Is IPv4 LL ever “most likely” ?


Maybe, if previous POA was autoconf
Check for valid IP address lease (<T1)
 If valid, perform reachability detection on default gateway of
“most likely” network

If reachability succeeds, reuse address




Note: To handle movement between private networks, need to match
*both* IP address and MAC address of default gateway
If reachability fails send DHCPREQUEST in INIT-REBOOT state
If no valid IP address lease, or no response to DHCPREQUEST
after retransmission, go to INIT state
If DHCP fails, do we allocate IPv4 LL address?
 Empirical evidence is that this is invalid much of the time, but it
could be required.
 If IPv4LL is allocated, how often do we attempt to obtain a
routable IP address?
What RFC 2131 Says (1)

Section 2.2:


“As a consistency check, the allocating server SHOULD
probe the reused address before allocating the address,
e.g., with an ICMP echo request, and the client SHOULD
probe the newly received address, e.g., with ARP.”
Section 3.1:

The client should choose to retransmit the
DHCPREQUEST enough times to give adequate
probability of contacting the server without causing the
client (and the user of that client) to wait overly long before
giving up; e.g., a client retransmitting as described in
section 4.1 might retransmit the DHCPREQUEST message
four times, for a total delay of 60 seconds, before restarting
the initialization procedure.
What RFC 2131 Says (2)

Section 3.2:



“If the client receives neither a DHCPACK or a DHCPNAK message
after employing the retransmission algorithm, the client MAY choose
to use the previously allocated network address and configuration
parameters for the remainder of the unexpired lease.”
“Note that in this case, where the client retains its network address
locally, the client will not normally relinquish its lease during a
graceful shutdown.”
Section 3.7:


“A client SHOULD use DHCP to reacquire or verify its IP address
and network parameters whenever the local network parameters
may have changed; e.g., at system boot time or after a
disconnection from the local network, as the local network
configuration may change without the client's or user's knowledge.
If a client has knowledge of a previous network address and is
unable to contact a local DHCP server, the client may continue to
use the previous network address until the lease for that address
expires. If the lease expires before the client can contact a DHCP
server, the client must immediately discontinue use of the previous
network address and may inform local users of the problem.
What draft-ietf-zeroconfIPv4-Linklocal-08 Says

Section 1.6:

“While [RFC2131] indicates that a DHCP client SHOULD probe a
newly received address with ARP, this is not mandatory. Similarly,
while [RFC2131] recommends that a DHCP server SHOULD
probe an address using an ICMP Echo Request before allocating
it, this is also not mandatory, and even if the server does this, LinkLocal IPv4 addresses are not routable, so a DHCP server not
directly connected to a link cannot detect whether a host on that
link is already using the desired Link-Local IPv4 address.”
A Bad Idea if Taken Literally

Section 2.2


“After it has selected a Link-Local IPv4 address, a host MUST test
to see if the Link-Local IPv4 address is already in use before
beginning to use it. When a network interface transitions from an
inactive to an active state, the host does not have knowledge of
what Link-Local IPv4 addresses may currently be in use on that
link, since the network interface may have been inactive when a
conflicting address was claimed.”
Implications




Host connects to an adhoc POA, selects IPv4LL address
Host moves to another (configured) POA
 Performs IPv4LL claim and defend
 Uses selected IPv4LL address
Host never obtains a routable address!
Solution
 Don’t “select” an IPv4LL as a first resort OR
 Test reachability of autoconf neighbor(s) first
Summary

Detecting Network Attachment (DNA) is an
important aspect of mobility

Poor implementation can result in mobile hosts that
are never connected!




802.1X + pre-mature DHCP + LLv4 + 5 minute timeout
Naïve IPv4LL implementation
Some grey areas in RFC 2131, IPv4 LL
specifications
Question: Where should this work be handled?
Feedback?