IPv4LL Compliance Testing

I’ve been working on a compliance test suite for implementations of RFC3927 IPv4 Link-Local Address Selection, also known as AutoIP. It should prove useful to anyone implementing IP4vLL address selection on an embedded device by simulating a network environment with existing IPv4LL devices which the device will need to interoperate with in terms of address selection and conflict resolution.

The suite confirms that an IPv4LL implementation generates RFC3927-compliant packets such as appropriately formatted probes and announcements, observes the recommended timings and participates in conflict resolution exactly as described by RFC3927.

I’ve included here a taster module, autoip_hoard.py, which stress tests a device’s conflict resolution under the difficult situation of finding another device on the network is repeatedly claiming the same IPv4LL address, even after reselection. It hoards any IPv4LL addresses which other devices on the network are attempting to claim and use, causing repeated conflicts and repeated address reselection in other devices on the link. This particular component of the suite does not test for RFC-compliance in terms of the number of responses, timings between packets etc, but rather is expected to be run as a daemon on one device in a network while observing the ability of the target device to cope with the situation. It is written in Python and will run on any platform supported by Scapy.

With the 169.254/16 range at your disposal, it is highly unlikely that you will find such constant address-reselection events occurring, but if you wish to test the theoretical possibility, or you wish to stress-test the reselection code, then this automated test is a great deal easier than generating such events by hand. You could also consider it as a test of your IPv4LL implementation’s behaviour in the event of a DoS (Denial of Service) attack via address conflicts, though this particular attack is only available to those with access to the local link.

Full instructions are provided within the sources, and its behaviour can be configured by various command-line options, but the default operation with no command-line parameters should generally be the correct way to instantiate it:

# sudo ./autoip_hoard.py

The module listens on the link for any ARPs containing IPv4LL source addresses, such as claim announcements during address selection. Any IPv4LL source addresses seen in such ARP packets are used to generate new ARP packets where the same IPv4LL source address is present as the source, thus indicating to the sender of the original ARP that the address is already in use, and pushing it into address defense and address reselection. When that device selects a new address and sends claim announcements, the module begins creating conflicts on the new address, causing the device into defense and reselection again. It continues repeatedly in this fashion, hoarding any IPv4LL address which other devices attempt to use, until stopped via Ctrl-C. During this time, target devices can be observed to monitor their behaviour when put under the stress of a constant address-conflict situation.

Moving on to some of the command-line options, if you wish to hoard only those addresses claimed by a single device then you can target only that device using the –mac option. For example to only cause conflicts against addresses claimed by the device with MAC address 00:01:02:03:04:05 you can use:

# sudo ./autoip_hoard.py –mac 00:01:02:03:04:05

The module will then ignore other devices and only push the specified target into address conflict resolution.

Another useful option is –nudge. The module does nothing until ARPs with IPv4LL source addresses are seen on the wire, so if the target device has already gone through the IPv4LL address claim procedure it may not be sending any further ARPs on the link and the module will be waiting without causing any conflicts. Once an ARP is eventually seen, the test will come to life, repeatedly causing address reselections. If you wish to speed up the initial startup, however, and you know the target’s current IPv4LL address, you can request that the module send an initial nudge at startup. This will attempt to push the target into sending out a defensive ARP or otherwise going into address reselection, which results in several further ARPs being sent. This kicks the module into action, after which point it will be continually putting the target device through address reselection. You may be happy to wait for an ARP from the target, but the nudge makes sure that the test gets to work sooner. To send an initial nudge to target device 169.254.232.30 use: