[ih] 13 the unlucky number

[Michael Kjörling]

On 11 Aug 2020 18:50 +0200, from internet-history at elists.isoc.org (Carsten Bormann via Internet-history):
> $ ping 010.010.010.010
> PING 010.010.010.010 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.35 ms
> $ ping 134744072
> PING 134744072 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.31 ms
> $ ping 01002004010
> PING 01002004010 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.31 ms
> $ ping 0x8080808
> PING 0x8080808 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.30 ms
> 
> Does anyone remember how this misfeature crept into the C library?
> (I seem to remember seeing it all the way back to 4.2BSD.  
> It no longer works with macOS, but still does on the Linuxes I tried.)

Just for fun, I looked at the source code for _ping_ in Debian Buster
(because I could do that easily).

It uses getaddrinfo() to map from the target given on the command line
to an IP address (either IPv4 or IPv6, depending on usage). In the
version packaged as 3:20180629-2+deb10u1, this appears to happen in
ping.c on lines 482 and 512.

getaddrinfo(), in turn, is specified[1] to accept "address strings
using Internet standard dot notation as specified in inet_addr".

inet_addr(), next, actually specifies[2] four different forms of "IPv4
dotted decimal notation": a.b.c.d, a.b.c, a.b and a.

Excluding the first ("010.010.010.010"), your examples above all
correspond to "a" (just a single numerical value), so:

> When only one part is given, the value shall be stored directly in
> the network address without any byte rearrangement.

Also,

> All numbers supplied as parts in IPv4 dotted decimal notation may be
> decimal, octal, or hexadecimal, as specified in the ISO C standard
> (that is, a leading 0x or 0X implies hexadecimal; otherwise, a
> leading '0' implies octal; otherwise, the number is interpreted as
> decimal).

One might make a reasonable argument that it's unexpected that this is
exposed all the way to the end user, but _not_ exposing this behavior
would seem to require using something other than a POSIX-compliant
getaddrinfo() and/or inet_addr() to parse and resolve the address
given. Doing so would _probably_ increase complexity, and increasing
complexity _usually_ causes the introduction of bugs.

 [1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html
 [2]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”