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

Stéphane Bortzmeyer — Jul 03, 2013 11:00 AM
Filed under: ,
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.

Appendix

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.

10 Comments

Stéphane Bortzmeyer
Stéphane Bortzmeyer says:
Jul 04, 2013 02:33 PM
Here is a discussion (in French) about the problem with some firmware versions of the CPE shipped by a French ISP : http://www.forum-orange.com/forums/viewtopic.php?id=52554
Stéphane Bortzmeyer
Stéphane Bortzmeyer says:
Jul 04, 2013 02:34 PM
And here is a problem with dot-zero addresses on a host (Microsoft Windows) http://support.microsoft.com/kb/241657/en-us
Stéphane Bortzmeyer
Stéphane Bortzmeyer says:
Jul 04, 2013 02:37 PM
A public Web site with such an address, to test: http://www.gcu-squad.org/
Emanuel Popa
Emanuel Popa says:
Jul 04, 2013 02:51 PM
We've been using "dot-zero" IPv4 addresses for our PPPoE customers for a long time and haven't had any reports of connectivity problems so far.
Stéphane Bortzmeyer
Stéphane Bortzmeyer says:
Jul 04, 2013 04:44 PM
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
Tassos says:
Jul 11, 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
Ray Bellis says:
Jul 12, 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.
bortzmeyer+ripe@nic.fr
Stéphane Bortzmeyer says:
Jul 25, 2013 10:39 PM
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
Brian Johnson says:
Jul 13, 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.
bortzmeyer+ripe@nic.fr
Stéphane Bortzmeyer says:
Jul 25, 2013 10:41 PM
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)."
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Related Items
Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

Modifications to the IP Analyser to Reflect New Policy

We are in the process of implementing the policy regarding Post Depletion Adjustment of Procedures ...

RIPE Atlas: Improved Probe Pages

We've made it much easier to get an overview of the history and measurements for all the public ...

RIPE Atlas Fun: Map a RIPE Atlas Anchor

View maps based on RIPE Atlas traceroute measurements. Compare the maps to the ISP's description of ...

more ...