[ih] 13 the unlucky number

[Jack Haverty]

At the time these conventions were congealing, we were all used to
working with the ARPANET, and in particular with the TIPs, which were
the machines you connected your terminal to in order to Telnet to work
on some host computer on the ARPANET.

To connect to, for example, host 1 on IMP 6 (MIT-DM, where I was at the
time), you would type "@l 70"  -- i.e., Host#* 64 + IMP#   It was
sometimes tedious to do the arithmetic.  But there weren't that many
IMPs, an each could have only 4 hosts, so not too bad.

The early Internet systems explored different ways of specifying the
address.   One I especially remember was the TIU (Terminal Interface
Unit).   You had to specify your target address in decimal.  Not dotted
quad decimal, but 32-bit decimal.  Converting a typical IP address
(10.0.0.5 was BBN-E) was a pain, and resulted in a many-digit
unmemorable decimal number that you had to type correctly.

People had different notions of what was the right way to specify IP
addresses.  The "dotted-quad" notion was nice (no 10-digit decimal
numbers), and mapped easily into the bytes we were used to dealing with
inside packets and computers. But the individual numbers of the quad
were still controversial.   So, IIRC, allowing any of hex/decimal/octal
in the dotted-quad was a compromise that ended the discussions.   I'm
not sure, but my recollection is that JonP was in the middle of all
that, working hard to reach "consensus and running code".

/Jack


On 8/11/20 12:06 PM, Michael Kjörling via Internet-history wrote:
> 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
>