All IP Addresses Are Equal? "dot-zero" Addresses Are Less Equal
The problem described here has initially been brought by Xavier Beaudouin: If a provider assigns a dot-zero IP address to a customer, is this a disservice to the customer? The last byte of a dot-zero IPv4 address is null. It is not a network address, unless the prefix length happens to be 24. For instance, in the prefix 10.1.128.0/23, the address 10.1.129.0 is a host address, It is a dot-zero address, but not a network address. In theory, this address is perfectly legitimate and should work without any problem. But is it?
IPv4 addresses ending in ".255" can raise similar questions as described in this Windows bug .
We developed the following methodology: We took a list of networks of which each network had a dot-zero IPv4 address and a "normal" one (not ending in .0 or .255) in the same /24. Some networks also had a .255 address. All addresses must respond to ICMP echoes (ping). Those devices that didn't, were automatically excluded from the results.
We then asked a set of RIPE Atlas probes (chosen at random by RIPE Atlas) to ping these targets. (The same set was used for all the addresses of a same network.) In theory, we expected a success rate of 100 % for all address. A run is defined as success when at least one of the packets sent by the probe (3 packets for each test) came back with a positive answer (an echo reply).
Note that it is not easy to find stable targets for these measurements. For each network, one needs a dot-zero address and a "normal" one which work. After various inquiries, I found less than ten networks and not all of them work 24x7. If you have an idea on how to find more networks, I would be glad to hear it. In the meantime, measurements have been done with between 5 and 7 networks, which is small. See public measurements #1012094 to #1012105.
Some RIPE Atlas probes have a dot-zero address themself (as you can find in the "from" field of the result, not the "src_addr" which is the local address and which can be a private one). They were automatically excluded from the measurements, to make sure we only tested one end of the communication.
We also found that many devices have a rate-limiter for ICMP echo, which is sometimes global, not per source IP address. So, when a thousand RIPE Atlas probes query the target at more or less the same time, we get many failures which do not appear if the pool of test probes is smaller. As far as I know, it is not possible to create oneoff measurements in RIPE Atlas that allow deliberate jitter in the probes, which would avoid this unfortunate stampede.
The success rate for the "normal" addresses were indeed close to 100%. For instance, in a run with five networks and two hundred probes requested, I got 983 successes for one failure.
For the dot-zero addresses, the success rate varied from 96 to 98%. So, there is indeed a statistically significant (test on 200 probes) problem, although it is relatively small which makes it difficult to pinpoint. Since the vast majority of probes can ping dot-zero addresses, I assume there is no problem in the Atlas network code and the trouble lies in the path (the CPE router?)
The important discovery is that it seems that there is a difference between targets whose IP addresses are in the former class C space (from 192.* to 223.*). In these cases, the failure rate is 4%, where it is only 2% for the other addresses. So, whatever the bugs are, they seem related to classful code.
Results of measurements restricted to France for non-class C addresses are the same as above (a big ISP in France apparently shipped CPE boxes with a broken firmware). For "former class C" addresses the failure rate seems higher in France, around 6%.
So, no, not all IP addresses are equal. Having a dot-zero address is a disadvantage, specially when it comes out of former class C space. One may wonder if network administrators should avoid these addresses.
The code to run and to analyse these measurements is available in the RIPE Atlas contrib repository , file connectivity-dot-zero.py.
Thanks to Jean-Philippe Pick for discussions on this survey.