Use dhcpcd only for DHCPv6 PD without assigning addresses

[Ionic]

Hi.

My ISP requires DHCPv6 PD in order to actually route an IPv6 prefix. Without a lease, the whole prefix is not routed at all and you're blackholed, even if the configuration itself is sane. They also don't support requesting specific addresses for interfaces. For static prefixes, like I have, this is stupid and doesn't make sense, but it's not my network and I can't change it, thus have to live with it.

This leaves me in a bit of a pickle with dhcpcd, though, since I can't configure it the way I need it. Maybe I just messed it up, so at least there's some hope.

I currently run this setup, calling dhcpcd in single-interface mode via pppd'sip-up/ip-down scriptlets (I'm aware that this will likely not be supported with dhcpcd 11+, which actually is an issue for my setup, since I don't use DHCP on any other interface, but that's just a side track):

hostname
duid
persistent
option rapid_commit
option interface_mtu
require dhcp_server_identifier
slaac private
nohook resolv.conf, yp, hostname, ntp
timeout 0
background
noipv6rs
ipv6only
interface ppp0
  ipv6rs
  iaid 1
  nogateway
  ia_pd 2/::/56 -

Unfortunately, it doesn't work the way I need it to work.

Let's detangle it a bit: I'm only interested in IPv6, and only for the interface ppp0. To that account, I disable hooks that try to change nameservers, the hostname or other things. The rapid_commit option is mandated by the ISP. For ppp0, I request a /56 IPv6 prefix delegation, enable RS (although RAs don't help me any since they don't contain a prefix) and, also crucially, tell dhcpcd to not touch the default route, since this is managed by pppd via IPCPv6, setting a default route via link-local addresses.

Fetching and assigning a prefix delegation works fine with this setup, but only initially.

Since the DHCPv6 server does not support assigning individual addresses, I have to use timeout 0, so that dhcpcd doesn't just time out trying to fetch an address to assign to the interface after some time, and, because the timeout is now infinite, background so that it backgrounds immediately instead of waiting for the first assigned address. Note that I'm explicitly not setting wait 6, since that wouldn't make any sense - I don't want or need any address to be assigned to the requested interface!

My issue lies in what happens next: nothing.

Even though dhcpcd acquires a lease for the prefix, it won't renew the lease after the advertised renew timeout, most likely because it's still hopelessly waiting for an address to be assigned first, which will never happen:

Sep  3 03:25:08 src@valery dhcpcd[96627]: forked to background, child pid 96629
Sep  3 03:25:08 src@valery dhcpcd[96629]: DUID 00:04:17:08:68:f8:a6:e4:11:de:b0:bb:00:19:d1:59:b7:dd
Sep  3 03:25:08 src@valery dhcpcd[96629]: ppp0: IAID 00:00:00:01
Sep  3 03:25:08 src@valery dhcpcd[96629]: ppp0: IA type 25 IAID 00:00:00:02
Sep  3 03:25:08 src@valery dhcpcd[96629]: ppp0: rebinding prior DHCPv6 lease
Sep  3 03:25:08 src@valery dhcpcd[96629]: ppp0: soliciting an IPv6 router
Sep  3 03:25:08 src@valery dhcpcd[96629]: ppp0: Router Advertisement from fe80::2a31:52ff:fe58:d8bc
Sep  3 03:25:08 src@valery dhcpcd[96629]: ppp0: no global addresses for default route
Sep  3 03:25:18 src@valery dhcpcd[96629]: ppp0: failed to rebind prior delegation
Sep  3 03:25:18 src@valery dhcpcd[96629]: ppp0: soliciting a DHCPv6 lease
Sep  3 03:25:20 src@valery dhcpcd[96629]: ppp0: ADV 2a00:11:fb41:7a00::/56 from fe80::2a31:52ff:fe58:d8bc
Sep  3 03:25:20 src@valery dhcpcd[96629]: ppp0: REPLY6 received from fe80::2a31:52ff:fe58:d8bc
Sep  3 03:25:20 src@valery dhcpcd[96629]: ppp0: renew in 86400, rebind in 138240, expire in 259200 seconds
Sep  3 03:25:20 src@valery dhcpcd[96629]: lo: adding reject route to 2a00:11:fb41:7a00::/56
Sep  3 03:25:20 src@valery dhcpcd[96629]: ppp0: delegated prefix 2a00:11:fb41:7a00::/56

Naturally I've waited for 24 hours (and longer) to see if it renews correctly, but so far, it has done nothing. I'm pretty sure that the lease will eventually expire and dhcpcd will do nothing about it - although both rebind and expire timers are rather large, so I haven't hit them yet.

So, in short, is there any way to tell dhcpcd to handle the DHCPv6 PD only, renewing this lease only, without caring for or trying to assign individual addresses?

[rsmarples]

What makes you think the renew didn't happen?

Sep 3 03:25:18 src@valery dhcpcd[96629]: ppp0: failed to rebind prior delegation
This is a clue that dhcpcd couldn't rebind and likely cannot renew either.
What is interesting is that dhcpcd solicited and received a reply.

Add the debug directive to your dhcpcd.conf and restart dhcpcd. You should then see dhcpcd starting the renew process after 86400 seconds of acquiring the delegation.

I currently run this setup, calling dhcpcd in single-interface mode via pppd'sip-up/ip-down scriptlets (I'm aware that this will likely not be supported with dhcpcd 11+, which actually is an issue for my setup, since I don't use DHCP on any other interface, but that's just a side track):

And this could actually be the issue. Because single interface mode requires binding to addresses and raw sockets just to support running more than one instance of single interface mode dhcpcd can get picking the source address wrong and the message could go nowhere. And because of how delegation and managing the route table needs to work it needs to look at all the interfaces anyway.
In manager mode, dhcpcd binds to the any address which means no other process can (ie, only one instance of dhcpcd runs which we then need to restrict to a single interface) then dhcpcd can sent the reply as the network stack intended and it stands a better chance of working.

If you're starting it in a script like dhcpcd ppp0, please try dhcpcd -M ppp0

[rsmarples]

ppp0: no global addresses for default route

I pushed a commit to remove this warning when you don't want a default route installed.
6462734

[Ionic]

What makes you think the renew didn't happen?

There were no log messages 86400 seconds later.

This is a clue that dhcpcd couldn't rebind and likely cannot renew either.
What is interesting is that dhcpcd solicited and received a reply.

Yeah, I don't know why this happened. I've started dhcpcd quite a few times while working on the configuration and never had the rebinding fail, but then again I also always made sure to kill other dhcpcd processes.

In any case, I assumed that it worked, since it received a valid reply.

Add the debug directive to your dhcpcd.conf and restart dhcpcd. You should then see dhcpcd starting the renew process after 86400 seconds of acquiring the delegation.

Okay, will do this.

[Explanation regarding single-interface mode]
If you're starting it in a script like dhcpcd ppp0, please try dhcpcd -M ppp0

I've been thinking about this as well and will definitely try it. Since single-interface mode implies --waitip, it's goes against what I need anyway, so using master mode might actually resolve this issue for me - and as an added bonus, I might be able to drop timeout 0 and background as well. In general, I should be able to use dhcpcd in master mode without specifying an interface by using allowinterfaces and denyinterfaces.

[rsmarples]

If you don't want to wait you can always use the -b option to send it straight to the background.

[Ionic]

I've since changed my setup to ignore all interfaces but ppp0 via:

denyinterfaces !(ppp0)
allowinterfaces ppp0

disabled timeout 0 and background and started dhcpcd in master and multi-interface mode (i.e., without specifying any interface).

Seems like this is doing exactly what I want.

It delegated the prefix, backgrounded by itself and renewing is also working fine.

Thank you for the invaluable pointer!

On a personal note, I hope you're doing reasonably well.