Re: [whatwg] IPv4 parsing

On Wed, Jun 24, 2015 at 1:50 PM, Tim Streater <tim@clothears.org.uk> wrote:

> On 24 Jun 2015 at 20:15, Peter Kasting <pkasting@google.com> wrote:
>
> > 1.66 = 1.0.0.66
> > 1.256 = 1.0.1.0
> > 1.2.66 = 1.2.0.66
> > 1.256.66 = invalid
>
> This makes no sense at all.
>

https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02#section-2.1.1
explains why

Quoth the text

>    Meanwhile, a very popular implementation of IP networking went off in
>    its own direction.  4.2BSD introduced a function inet_aton(), whose
>    job was to interpret character strings as IP addresses.  It
>    interpreted both of the syntaxes mentioned in [MTP] (see above): a
>    single number giving the entire 32-bit address, and dot-separated
>    octet values.  It also interpreted two intermediate syntaxes: octet-
>    dot-octet-dot-16bits, intended for class B addresses, and octet-
>    dot-24bits, intended for class A addresses.  It also allowed some
>    flexibility in how the individual numeric parts were specified: it
>    allowed octal and hexadecimal in addition to decimal, distinguishing
>    these radices by using the C language syntax involving a prefix "0"
>    or "0x", and allowed the numbers to be arbitrarily long.
>    The 4.2BSD inet_aton() has been widely copied and imitated, and so is
>    a de facto standard for the textual representation of IPv4 addresses.
>    Nevertheless, these alternative syntaxes have now fallen out of use
>    (if they ever had significant use).  The only practical use that they
>    now see is for deliberate obfuscation of addresses: giving an IPv4
>    address as a single 32-bit decimal number is favoured among people
>    wishing to conceal the true location that is encoded in a URL.  All
>    the forms except for decimal octets are seen as non-standard (despite
>    being quite widely interoperable) and undesirable.

Received on Wednesday, 24 June 2015 20:57:17 UTC