Detecting Network Attachment in IPv4 (DNAv4)
Extracted elements (25)
DHCP processing MUST proceed in parallel with DNAv4 reachability tests, not after, because waiting for DNAv4 to fail before beginning DHCP can greatly increase total processing time—the opposite of the desired effect.
DNAv4 does not apply to IPv4 Link-Local addresses because they are not issued by an authoritative server and have no guaranteed usable lifetime; a host's claim is only valid while it remains connected and actively defending the address.
DNAv4 is explicitly a performance optimization where false positives are unacceptable but false negatives are acceptable. If a router ignores unicast ARP Requests, DNAv4 will fail to detect re-attachment, but the host still operates correctly via normal DHCP processing.
DNAv4 targets completion in less than 10 ms for effective low-latency handoffs. An IPv4 ARP packet on Ethernet is just 42 octets including the Ethernet header, making unsuccessful trials inexpensive, so the best strategy is to try all candidate configurations rather than apply heuristics.
DNAv4 uses unicast ARP rather than broadcast ARP to test reachability because broadcast ARP imposes greater burden on 802.11 networks, can pollute ARP caches of peers, and when using private addresses could disrupt communications of another device legitimately using the same address. Unicast ARP addressed to the router's MAC address harmlessly disappears if the host is not on the expected link.
DNAv4 is not suitable for use on media that do not support ARP, since the reachability test procedure depends entirely on the ARP protocol.
If a router ignores unicast ARP Requests, DNAv4 will always produce false negatives for that link, making it impossible to detect re-attachment; network operators who desire the performance improvement must upgrade their routers to respond to unicast ARP.
A host wishing to reclaim a previously used IPv4 Link-Local address MUST perform the full probing and announcement process required by RFC3927 and MUST NOT attempt to use DNAv4 as a shortcut to bypass that process, since Link-Local address claims are only valid while the host remains actively connected and defending the address.
If both DNAv4 and DHCP are used on the same link and reachability test completes first but DHCP later returns a different result, the implementation SHOULD abandon the reachability test results and use the DHCP result instead, unless the confirmed address was manually assigned.
If the host has an operable routable IPv4 address and DHCPv4 is enabled, the host SHOULD attempt DHCPv4 in parallel with reachability tests by entering INIT-REBOOT state and sending a DHCPREQUEST to the broadcast address per RFC2131 Section 4.4.2.
If the reachability test is successful, the host SHOULD continue to use the operable routable IPv4 address associated with the confirmed network without re-acquiring it. Once a valid reachability test response is received, validation is complete and additional responses SHOULD be discarded.
It is RECOMMENDED that a DNAv4 implementation retransmit no more than twice, and it is RECOMMENDED that the DNAv4 procedure be carried out no more than once a second to provide damping against spurious 'Link Up' indications.
It is RECOMMENDED that the host attempt to obtain IPv4 configuration via DHCPv4 in parallel with reachability tests, using the first answer returned, to ensure DNAv4 adds no delay when reachability tests fail.
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is not appropriate because if the client has moved to another subnet, the DHCP server response cannot be routed back since the DHCPREQUEST bypasses the relay and contains an invalid source address.
Sending an ICMP Echo Request SHOULD NOT be used as a substitute for the ARP reachability test because it does not verify MAC address correspondence and can yield false positives when a host moves between private networks using overlapping prefixes or when TTL > 1 allows off-link routers to respond.
The host SHOULD skip the reachability test when: (a) no operable routable IPv4 address exists for that network, (b) no test node addresses are known, (c) DHCP authentication (RFC3118) is configured, or (d) the DHCP Client Identifier the client used differs from what it intends to present now.
The host SHOULD use the addresses of local routers (preferably default gateways) as test nodes. In order to ensure configuration validity, the host SHOULD only configure routes for which the next hop address passes the reachability test; other routes SHOULD be re-learned.
Until the host has confirmed its IPv4 configuration via the reachability test, it SHOULD NOT respond to ARP Requests and SHOULD NOT broadcast ARP Requests containing its address in ar$spa, to avoid address conflicts especially when moving between private networks.
Use of DNAv4 to confirm manually assigned addresses SHOULD NOT be enabled by default, because where the manually assigned address falls within a DHCP server's scope, a conflict may arise if the host was unavailable when the DHCP server last checked for conflicts.
When validating an ARP Reply, the MAC address in ar$sha of the reply MUST be matched against ar$tpa of the request, and the IPv4 address in ar$spa of the reply MUST be matched against ar$tpa of the request; only if both match does the host continue using that IPv4 address.
DNAv4 procedure is triggered by a 'Link Up' event from the link layer. For each network with an operable IPv4 address, the host selects candidate configurations and performs a reachability test. The host saves to stable storage: (1) IPv4 and MAC address of test nodes per network, and (2) IPv4 configuration parameters including DHCP client identifier, assigned address, and lease expiration time.
Adjusting security configuration (e.g., disabling a personal firewall) based on DNAv4 results is NOT RECOMMENDED, since a spoofed reachability test response could trick the host into lowering its security posture on an untrusted network.
DNAv4 inherits ARP's lack of security: an attacker on the network can spoof a reachability test response, causing the host to falsely conclude it is attached to a known network. Similarly, a rogue DHCPv4 server can convince a host it is on a particular network.
Hosts that depend on secure IP configuration SHOULD NOT use DNAv4 but SHOULD instead use DHCP authentication (RFC3118), possibly combined with the Rapid Commit Option (RFC4039). The effect of ARP/DHCP spoofing attacks is typically limited to denial of service unless the IP configuration is used for security or location determination.
The reachability test sends a unicast ARP Request where ar$tpa is set to the test node's IPv4 address, ar$spa is the host's candidate IPv4 address, ar$sha is the host's MAC address, ar$tha is set to 0, and the Ethernet destination is the test node's MAC address. An IPv4 ARP packet on Ethernet is 42 octets including the Ethernet header.