Detection of Network Attachment (DNA) in IPv4

1. 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/

2. 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

3. DNAv4 Model • “Hints” – non-definitive indications whether the host has connected to a previously encountered subnet • L2 hints: 802.11 SSID, Infrastructure/Adhoc, IEEE 802 LLDP traffic • L3 hints: IRDP • “Most Likely” point of attachment (POA) • Best guess, based on hints • By default: previous point of attachment • Reachability detection • 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

4. 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?

5. 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.

6. 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.

7. What draft-ietf-zeroconf-IPv4-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, Link-Local 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.”

8. 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

9. 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?

10. Feedback?