All IP Addresses Are Equal? "dot-zero" Addresses Are Less EqualIn theory, all IP addresses are the same, and you can allocate them at random without a problem. 192.168.1.2 is certainly not better or worse than 192.168.1.15, right? But, in practice, certain IP addresses are regarded as "special" by some implementations and do not yield the same user experience. This is the case for the "dot-zero", IPv4 addresses in which the last byte is zero.https://labs.ripe.net/Members/stephane_bortzmeyer/all-ip-addresses-are-equal-dot-zero-addresses-are-less-equalhttps://labs.ripe.net/logo.png

All IP Addresses Are Equal? "dot-zero" Addresses Are Less Equal

In theory, all IP addresses are the same, and you can allocate them at random without a problem. 192.168.1.2 is certainly not better or worse than 192.168.1.15, right? But, in practice, certain IP addresses are regarded as "special" by some implementations and do not yield the same user experience. This is the case for the "dot-zero", IPv4 addresses in which the last byte is zero.

Introduction

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
.

Methodology

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.

Results

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

Conclusion

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.

Did you actually test, for instance with the public Web site I just mentioned? You know that end users are bad at reporting problem (specially when the failure rate is low and it can be easily dismissed as "a few unconfirmed reports").That's why massive testing with many Atlas probes is important.

Tassos
says:

11 Jul, 2013 09:58 PM

We also have been using dot.zero and dot.255 addresses for more than 3 years and we haven't heard any complaints.I had a look at last month's accounting records for such users and i didn't notice any strange pattern; all users had sessions with long durations and enough download volume.I guess if a user had a major issue, he would probably try to reconnect and get a new address.

Ray Bellis
says:

12 Jul, 2013 01:10 PM

This is old news. In my previous job as an ISP around 10 years ago we found we had to exclude .0 and .255 from assignment to end-user /32 addresses because those users were unable to reach certain website (including microsoft.com) because over-zealous firewall admins assumed that those addresses were not legal if the IP address came from the old "Class C" classfull range of 192.0.0.0 to 223.255.255.255.

I never said it was new, but, as far as I know, it has never been measured quantitatively. My tests show that, although not new, it is still prevalent.

Brian Johnson
says:

13 Jul, 2013 04:54 AM

I believe this issue is limited to a last mile gear and CPE issue. Some of this gear is unable to handle the masking correctly. This is likely due to programmers who mistakenly worked under the assumption of a classful model.

We experienced this with some older last-mile gear, but have since replaced that gear and have had no known issues since. I did test this and was unable to produce different results with a .0 address.

Another example of broken software: xinetd which assumes that addressing is classful. Man page says "numeric address in the form of %d.%d.%d.%d. If the rightmost components are 0, they are treated as wildcards (for example, 128.138.12.0 matches all hosts on the 128.138.12 subnet)."

Samir
says:

16 Dec, 2016 11:50 PM

Major ISPs are even assigning these addresses (Comcast/Xfinity). I'm having all sorts of problems getting a site-to-site vpn working again that was working previously with a different ISP on the .0 end. Never had an issue with the previous IP address.

Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacy policy. You can accept our cookies either by clicking here or by continuing to use the site.