Iproute2 v5.16.0 "ip address" issue

Iproute2 v5.16.0 "ip address" issue

[Vadim Priluzkiy]

Hi ppl!

RFC 6943 (https://datatracker.ietf.org/doc/html/rfc6943#section-3.1.1) say:

"In specifying the inet_addr() API, the Portable Operating System
   Interface (POSIX) standard [IEEE-1003.1] defines "IPv4 dotted decimal
   notation" as allowing not only strings of the form "10.0.1.2" but
   also allowing octal and hexadecimal, and addresses with less than
   four parts.  For example, "10.0.258", "0xA000102", and "012.0x102"
   all represent the same IPv4 address in standard "IPv4 dotted decimal"
   notation.  We will refer to this as the "loose" syntax of an IPv4
   address literal."

Also "man 3 inet" say:

"inet_aton()  converts  the  Internet host address cp from the IPv4
numbers-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 network 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 A network addresses.

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

     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 decimal
numbers  is  referred to as IPv4 dotted-decimal notation (or
sometimes: IPv4 dotted-quad notation)."


Okay! I know that many utilities (ping, curl, tracepath, browsers etc)
support int, octal, hexadecimal notations very well.
I tried assigning an address to an interface using "ip address" using
various notations and that's what happened (test address: 10.8.0.5,
removed after every test):

Octal dotted notation:
# ip a add 012.010.000.005/24 dev dummy0
# ip a show dev dummy0
6: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group
default qlen 1000
    inet 10.8.0.5/24 scope global dummy0

Hexadecimal dotted notation:
# ip a add 0xA.0x8.0x0.0x5/24 dev dummy0
                                                               # ip -4
a show dev dummy0

6: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group
default qlen 1000
    inet 10.8.0.5/24 scope global dummy0

Hexadecimal notation:
# ip a add 0xA080005/24 dev dummy0

 Error: any valid prefix is expected rather than "0xA080005/24".

Int notation:
# ip a add 168296453/24 dev dummy0

Error: any valid prefix is expected rather than "168296453/24".

Hmm... Okay, let's try something simple. For example address 0.0.0.1:
# ip a add 0x1/24 dev dummy0

 # ip -4 a show dev dummy0
                                                              6:
dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
qlen 1000
    inet 1.0.0.0/24 scope global dummy0

(similar effect on "ip a add 1/24 dev dummy0")

WTF?
ip, instead of counting values from the last octet, counts them from the first!
Perhaps somewhere mixed up little/big endian?

Testcase: Manjaro Linux, kernel version 5.15.16, iproute2 version 5.16.0

PS: Legacy ifconfig works fine with any notation and assigns the
address correctly.

-- 
Vadim (Oxyd) Priluzkiy

Re: Iproute2 v5.16.0 "ip address" issue

[Stephen Hemminger]

On Fri, 28 Jan 2022 01:13:36 +0300
Vadim Priluzkiy <oxyd76@gmail.com> wrote:

> Hi ppl!
> 
> RFC 6943 (https://datatracker.ietf.org/doc/html/rfc6943#section-3.1.1) say:
> 
> "In specifying the inet_addr() API, the Portable Operating System
>    Interface (POSIX) standard [IEEE-1003.1] defines "IPv4 dotted decimal
>    notation" as allowing not only strings of the form "10.0.1.2" but
>    also allowing octal and hexadecimal, and addresses with less than
>    four parts.  For example, "10.0.258", "0xA000102", and "012.0x102"
>    all represent the same IPv4 address in standard "IPv4 dotted decimal"
>    notation.  We will refer to this as the "loose" syntax of an IPv4
>    address literal."
> 
> Also "man 3 inet" say:
> 
> "inet_aton()  converts  the  Internet host address cp from the IPv4
> numbers-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 network 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 A network addresses.
> 
>        a         The value a is interpreted as a 32-bit value that is
> stored directly into the binary address without any byte
> rearrangement.
> 
>      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 decimal
> numbers  is  referred to as IPv4 dotted-decimal notation (or
> sometimes: IPv4 dotted-quad notation)."
> 
> 
> Okay! I know that many utilities (ping, curl, tracepath, browsers etc)
> support int, octal, hexadecimal notations very well.
> I tried assigning an address to an interface using "ip address" using
> various notations and that's what happened (test address: 10.8.0.5,
> removed after every test):
> 
> Octal dotted notation:
> # ip a add 012.010.000.005/24 dev dummy0
> # ip a show dev dummy0
> 6: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
>     inet 10.8.0.5/24 scope global dummy0
> 
> Hexadecimal dotted notation:
> # ip a add 0xA.0x8.0x0.0x5/24 dev dummy0
>                                                                # ip -4
> a show dev dummy0
> 
> 6: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
>     inet 10.8.0.5/24 scope global dummy0
> 
> Hexadecimal notation:
> # ip a add 0xA080005/24 dev dummy0
> 
>  Error: any valid prefix is expected rather than "0xA080005/24".
> 
> Int notation:
> # ip a add 168296453/24 dev dummy0
> 
> Error: any valid prefix is expected rather than "168296453/24".
> 
> Hmm... Okay, let's try something simple. For example address 0.0.0.1:
> # ip a add 0x1/24 dev dummy0
> 
>  # ip -4 a show dev dummy0
>                                                               6:
> dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
> qlen 1000
>     inet 1.0.0.0/24 scope global dummy0
> 
> (similar effect on "ip a add 1/24 dev dummy0")
> 
> WTF?
> ip, instead of counting values from the last octet, counts them from the first!
> Perhaps somewhere mixed up little/big endian?
> 
> Testcase: Manjaro Linux, kernel version 5.15.16, iproute2 version 5.16.0
> 
> PS: Legacy ifconfig works fine with any notation and assigns the
> address correctly.

You are the first to care in many years, and Iproute2 (before the current maintainers)
decided to make the choice that 10.8 would get parsed as 10.8.0.0 no 10.0.0.8.
This is a choice that was made early on, and changing would break other users.

A previous attempt to change this caused backlash, not revisiting it.

commit cafa6c8ec1d6e4bddde190edb742be864ce3f9b3 (tag: v2.6.27)
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Mon Oct 27 10:27:27 2008 -0700

    Restore old address parsing but with checking
    
    Go back to original address parsing for compatability, but
    document it and add more stringent checking.

commit 94afda752956ddc6ff1accf931bc3d03c070bb18
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Tue Oct 14 15:02:16 2008 -0700

    Compatiable network abbreviation support
    
    Handle 10/8 as 10.0.0.0/8 and check for bogus values like 256/8.
    This is a comprimise between original iproute2 parsing and standard BSD
    parsing of abbreviated IPV4 addresses.