netdev - Re: Getting the IPv6 'prefix_len' for DHCP6 assigned addresses.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 02 Feb 2022 12:54:57 -0600
From:   Dan Williams <dcbw@...hat.com>
To:     David Laight <David.Laight@...LAB.COM>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     David Ahern <dsahern@...nel.org>
Subject: Re: Getting the IPv6 'prefix_len' for DHCP6 assigned addresses.

On Wed, 2022-02-02 at 16:58 +0000, David Laight wrote:
> I'm trying to work out how DHCP6 is supposed to work.
> 
> I've a test network with the ISC dhcp6 server and radvd running.
> If I enable 'autoconf' I get a nice address with the prefix from
> radvd and the last 8 bytes from my mac address, prefix_len 64.
> I get a nice address from dhcp6 (busybox udhcpc6) with the same prefix.
> 
> udhcpc6 runs my scripts and 'ip add $ipv6 dev $interface' adds the
> address.
> But the associated prefix_len is /128.
> 
> All the documentation for DHCP6 says the prefix_len (and probably the
> default route - but I've not got that far) should come from the network
> (I think from RA messages).
> 
> But I can't get it to work, and google searches just seem to show
> everyone else having the same problem.
> 
> The only code I've found that looks at the prefix_len from RA messages
> is that which adds to 'autoconf' addresses - and that refuses to do
> anything unless the prefix_len is 64.
> 
> I can't see anything that would change the prefix_len of an address
> that dhcp6 added.
> 
> Has something fallen down a big crack?

I'm far from an expert, but I don't think anything has fallen down a
crack. I'm sure David Ahern or somebody else will correct me, but here
goes:

Things are working as intended.

DHCPv6 is not a complete IPv6 addressing solution. It must be used in
combination with Router Advertisements to do generally useful things.

https://datatracker.ietf.org/doc/html/rfc8415#section-21.6

21.6.  IA Address Option

      IPv6-address         An IPv6 address.  A client MUST NOT form an
                           implicit prefix with a length other than 128
                           for this address.  A 16-octet field.

DHCPv6 intentionally doesn't tell you who your IPv6 router (gateway in
v4-land) is. That's what the Router Advertisement is for.

DHCPv6 intentionally doesn't tell you anything about what prefixes are
"on-link" like what the subnet mask implies for IPv4. That's what the
Router Advertisement is for.

If the router sends an RA with a Prefix Information Option (PIO) with
the "on-link" (L) bit set then the kernel should install on-link routes
for that prefix. If your DHCPv6-provided address falls within one of
those prefixes then kernel routing takes over and packets go where they
should regardless of the /128.

If you don't have RAs, or don't have those routes installed because the
router wasn't sending a PIO+L for the DHCP-provided prefixes, then yeah
things aren't going to work like you might expect.

I'm sure David will be along to correct me soon though...

Dan

> Kernel is 5.10.84 (LTS) - but I don't think anything relevant
> will have changed.
> 
>         David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)
>