[bug-inetutils] Re: ping: Discard single octets as host name.

[Simon Josefsson]

Mats Erik Andersson <address@hidden> writes:

> tisdag den  7 december 2010 klockan 13:22 skrev Simon Josefsson detta:
>> Mats Erik Andersson <address@hidden> writes:
>> 
>> > Hello again,
>> >
>> > there is an old bug report [1] filed with Debian, which makes much sense.
>> > It is a wish that the call
>> >
>> >     ping 10
>> >
>> > should return an error, since no host can consist of a single octet,
>> > and neither is an IPv4 address with initial octet 0 possible.
>> 
>> Isn't this traditional behaviour of BSD ping?
>
> Do you mean to say that "ping 10" being equivalent to
> "actively and stubbornly have a go at 'ping 0.0.0.10'",
> that this is the traditional behaviour?
>
> This is what OpenBSD 4.6 and FreeBSD 8.0 do this very day,
> which still is a daft way to act. This is also the behaviour
> of present day Inetutils.

Thus there is a long tradition in this behaviour, and I don't see the
harm it causes.  I see this single-integer format used from time to
time, and it tends to work in programs.

> The differing behaviour boils down to believing the output
> of inet_aton(3), or not to do so. This old library call
> transforms

Isn't a good fix then to use getaddrinfo or getnameinfo instead of
inet_aton?  If that fixes it, I'm all for it, but if getnameinfo behaves
the same way as inet_aton here, I think that is a strong argument for
keeping the behaviour.

This behaviour is documented in the inet_aton man page:

       inet_aton() converts the Internet host address cp from  the  IPv4  num‐
       bers-and-dots  notation  into  binary  form (in network byte order) and
       stores it in the structure that inp  points  to.   inet_aton()  returns
       nonzero  if the address is valid, zero if not.  The address supplied in
       cp can have one of the following forms:

       a.b.c.d   Each of the four  numeric  parts  specifies  a  byte  of  the
                 address;  the  bytes  are  assigned in left-to-right order to
                 produce the binary address.

       a.b.c     Parts a and b specify the  first  two  bytes  of  the  binary
                 address.   Part  c  is  interpreted  as  a  16-bit value that
                 defines the rightmost two bytes of the binary address.   This
                 notation  is  suitable for specifying (outmoded) Class B net‐
                 work addresses.

       a.b       Part a specifies the first byte of the binary address.   Part
                 b is interpreted as a 24-bit value that defines the rightmost
                 three bytes of the binary address.  This notation is suitable
                 for specifying (outmoded) Class C network addresses.

       a         The  value  a is interpreted as a 32-bit value that is stored
                 directly into the binary address without any byte  rearrange‐
                 ment.

       In  all  of  the  above  forms, components of the dotted address can be
       specified in decimal, octal (with a leading 0), or hexadecimal, with  a
       leading  0X).   Addresses in any of these forms are collectively termed
       IPV4 numbers-and-dots notation.  The form that uses exactly four  deci‐
       mal  numbers  is  referred to as IPv4 dotted-decimal notation (or some‐
       times: IPv4 dotted-quad notation).

> In comparison "ping6 10" aborts also in BSD with an error.
> Therefore, it would be consistent and sensible to implement
> this also for IPv4 pinging.

It could be argued either way.  Since ping was there before ping6, it
seems more natural to me for ping6 to be consistent with the former, not
vice versa.  However given the rationale behind single integer addresses
(converting a 32-bit integer into an IP address) it doesn't seem useful
to support something like it for IPv6 but it does for IPv4.

Just my $.01,
/Simon