Re: IPv6 woes - RFC

[Nick Hilliard <nick () foobar org>]

Valdis Klētnieks wrote on 26/09/2021 01:44:
> 19:17:38  0 [~] ping 2130706433
> PING 2130706433 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms
> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms
> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
> ^C
> --- 2130706433 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time84ms
> rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
>
> Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.

this is a good example of "might work but don't depend on it".  The fact 
that it works at all is a historical curiosity which happened because 
the text format for ipv4 addresses was never formally specified, so when 
some of the tcp/ip code was originally written for bsd, it accepted 
unusual formats in some places, including: integers, octal, hex, binary 
and assuming zeros when the address is incompletely specified, among 
other things.

The octal representation was a real problem because rfc790 specified 
decimal dotted quad notation with leading zeros, leading to a whole bag 
of pain for parsers because there is no way of knowing what a leading 
zero means in practice, and for 3-digit numbers where each digit is <= 
7, there is no a-priori way of determining whether it's octal 
representation or decimal.

Nick