[atlas] IPv4 leading zeroes and weird interface behaviour

On Wed, 25 Oct 2017 22:45:42 +0200
Max Grobecker <max.grobecker at ml.grobecker.info> wrote:

> But: When I lookup this IP address on https://stat.ripe.net/073.000.255.229 the first octet is internally getting swapped to "59".
> This can be explained, if you take "073" as an octal value and convert it to a decimal value.
> It is definitely a octal-to-decimal conversion thing, as for example also the value "010" is getting replaced by "8" and so on.
> 
> Now I'm puzzled: Of course, writing IPv4 octets with leading zeroes is not very common.
> But: Is it officially prohibited or discouraged?
> 
> This weird conversion also happens inside the "geoiplookup" tool by MaxMind and I'm not sure if I'm going to be the moron in this story
> or if I found the same bug inside multiple softwares at once ;-)

There are many ways to write an IP address, and yes, leading zeroes mean the
octal form. Even basic utilities like "ping" use this conversion:

$ ping 010.020.030.040
PING 010.020.030.040 (8.16.24.32) 56(84) bytes of data.
^C
--- 010.020.030.040 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms


Another way is to give a full 32-bit number as integer:

$ ping 728374928
PING 728374928 (43.106.30.144) 56(84) bytes of data.
^C
--- 728374928 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1015ms


Or you can skip zeroes (almost like in IPv6):

$ ping 10.9
PING 10.9 (10.0.0.9) 56(84) bytes of data.
^C
--- 10.9 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1015ms


So what you found is not a bug, but a common behavior. I'm sure all of this is
described in great detail in some 40 year old RFC.

-- 
With respect,
Roman