All of lore.kernel.org
 help / color / mirror / Atom feed
* Getting the IPv6 'prefix_len' for DHCP6 assigned addresses.
@ 2022-02-02 16:58 David Laight
  2022-02-02 18:54 ` Dan Williams
  0 siblings, 1 reply; 5+ messages in thread
From: David Laight @ 2022-02-02 16:58 UTC (permalink / raw)
  To: netdev; +Cc: David Ahern

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?

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)


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Getting the IPv6 'prefix_len' for DHCP6 assigned addresses.
  2022-02-02 16:58 Getting the IPv6 'prefix_len' for DHCP6 assigned addresses David Laight
@ 2022-02-02 18:54 ` Dan Williams
  2022-02-02 22:31   ` David Laight
  0 siblings, 1 reply; 5+ messages in thread
From: Dan Williams @ 2022-02-02 18:54 UTC (permalink / raw)
  To: David Laight, netdev; +Cc: David Ahern

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)
> 



^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Getting the IPv6 'prefix_len' for DHCP6 assigned addresses.
  2022-02-02 18:54 ` Dan Williams
@ 2022-02-02 22:31   ` David Laight
  2022-02-03 14:51     ` Dan Williams
  0 siblings, 1 reply; 5+ messages in thread
From: David Laight @ 2022-02-02 22:31 UTC (permalink / raw)
  To: 'Dan Williams', netdev; +Cc: David Ahern

From: Dan Williams
> Sent: 02 February 2022 18:55
> 
> 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.

That's what I'd gathered.

> 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.

They are being sent, because if I enable "autoconf" I get the prefix
address based on my MAC address.
But I don't want that "autoconf" addreess, I only want the dhcp6 address.

It has to be said I was probably looking at the output from 'ip addr'
not 'ip route show'.
Checking things on the test system is a bit of a PITA due to its
limited userspace, but at least I've stopped dhcp6 deleting the IPv4
address!

But I (probably) found the code that adds the "autoconf" address and
route - it has a check that the prefix_len is 64.

It may well be that you need to use dhcp6 with a /80 prefix because
your isp has only decided to give you a single /64 address.

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

Indeed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Getting the IPv6 'prefix_len' for DHCP6 assigned addresses.
  2022-02-02 22:31   ` David Laight
@ 2022-02-03 14:51     ` Dan Williams
  2022-02-03 18:37       ` David Laight
  0 siblings, 1 reply; 5+ messages in thread
From: Dan Williams @ 2022-02-03 14:51 UTC (permalink / raw)
  To: David Laight, netdev; +Cc: David Ahern

On Wed, 2022-02-02 at 22:31 +0000, David Laight wrote:
> From: Dan Williams
> > Sent: 02 February 2022 18:55
> > 
> > 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.
> 
> That's what I'd gathered.
> 
> > 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.
> 
> They are being sent, because if I enable "autoconf" I get the prefix
> address based on my MAC address.
> But I don't want that "autoconf" addreess, I only want the dhcp6
> address.

You can update your radvd config to turn off the autoconf for that
prefix. eg, you want:

prefix 2001:db8:1:0::/80
{
  AdvOnLink on;
  AdvAutonomous off;
}

This should tell clients not to do SLAAC, but the kernel will still
take the route that DHCP addresses would use.

Or set /proc/sys/net/ipv6/conf/all/autoconf to 0. That will prevent
generation of the address, but should still allow the on-link routes to
be created by the kernel.

> 
> It has to be said I was probably looking at the output from 'ip addr'
> not 'ip route show'.
> Checking things on the test system is a bit of a PITA due to its
> limited userspace, but at least I've stopped dhcp6 deleting the IPv4
> address!
> 
> But I (probably) found the code that adds the "autoconf" address and
> route - it has a check that the prefix_len is 64.

IIRC SLAAC is always /64 for various reasons. It seems people are
thinking about changing that for prefix delegation at least, eg see
https://www.ietf.org/id/draft-mishra-v6ops-variable-slaac-problem-stmt-03.html
and Dmytro Shytyi's recent patches:

"net: Variable SLAAC: SLAAC with prefixes of arbitrary length in PIO"

> 
> It may well be that you need to use dhcp6 with a /80 prefix because
> your isp has only decided to give you a single /64 address.

Doesn't that work already? If you get a /64 from your ISP, then your
local radvd can take /80 of that for advertising a PIO, and your DHCPv6
server can serve from that /80. The addresses will be /128 of course,
but addrconf_prefix_rcv() should take that /80 prefix from radvd and
add a route. And everything will be OK.

Bonus for you, the kernel won't create a SLAAC address for that prefix
because it's "smaller" than /64.

Dan

> 
> > I'm sure David will be along to correct me soon though...
> 
> Indeed.
> 
>         David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)



^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Getting the IPv6 'prefix_len' for DHCP6 assigned addresses.
  2022-02-03 14:51     ` Dan Williams
@ 2022-02-03 18:37       ` David Laight
  0 siblings, 0 replies; 5+ messages in thread
From: David Laight @ 2022-02-03 18:37 UTC (permalink / raw)
  To: 'Dan Williams', netdev; +Cc: David Ahern

From: Dan Williams
> Sent: 03 February 2022 14:52
> > > 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.

Today it was working.
Not sure what was going on last time I tried.

But I do have to look very hard to find the IPv6 routes.
Running:
   ip route show table all
does give them, but nothing else seems to.

The busybox netstat doesn't grok -6.
But I've the full version of 'ip' to get namespace support.

Talking of namespaces, is it possible to mount the namespace
version of /proc/sys/net somewhere in the filesystem?
I've got programs that really want to open nodes in the
'init' namespace and a named one.

I can use:
	ip netns exec namespace program 3</proc/sys/net and
then use openat(3, "path") to get items in the 'init' namespace.
But it is a bit horrid.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-02-03 18:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-02 16:58 Getting the IPv6 'prefix_len' for DHCP6 assigned addresses David Laight
2022-02-02 18:54 ` Dan Williams
2022-02-02 22:31   ` David Laight
2022-02-03 14:51     ` Dan Williams
2022-02-03 18:37       ` David Laight

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.