[odhcp6c] Preserve DHCPv6-PD over reboot?

Is there a way to "dump" the state of odhcp6c [1], so the router can pretend to just renew a prefix-delegation, but not request a new one? My ISP gives out new addresses and a new prefix when requested, but as long as the router runs, and assignments are just renewed, addresses and PD stays the same.

Thanks for any hints...

[1] That's the component not only requesting an address for wan, but also do the prefix-delegation, right?

What you're describing is not to IPv6 specifications.

Nonetheless, it wouldn't work, as the upstream router wouldn't know to route traffic to you anymore.

That's not quite how IPv6 RA/DHCPv6 works. Your description sounds more like DHCPv4.

Perhaps you could write a script to assign the last prefix, but I don't think this will work either. This would test the theory.


Why? Please point me to the RFCs...
Because... https://www.rfc-editor.org/rfc/rfc8415#section-6.3

Why? If my router has the same address on WAN as before, then routing-wise nothing changes... from the ISP perspective.

As far as I know RA has nothing to do with DHCPv6-PD...
How does it work then?

Do you set the norelease option already in you network config?

uci set network.wan6.norelease="1"
uci commit network
service network restart
1 Like
  • You cannot receive a PD without DHCPv6
  • You cannot get a route without RA

I'm not sure why you posted that, can you explain?

Did you post it to demonstrate you agree it won't work?

How does that relate to RA?

AH, I did not have known about this yet.
Have you this setting in use? I see it should work as long as the router is up, but the wan interfaces changes state, and address and prefix are still assigned, but it will not help in the reboot scenario, doesn't it?

I have not stated anything different.

  1. AFAIK PPPoE has its own way to inform the client about a default route.
    (And my ISP is using PPPoE and DHCPv6)
  2. There are implementations available to inform an DHCPv6 client about the presents of a default-route.
  3. Even without RA or DHCPv6 I can build a network and inform routers about the presents of a default route (or even many), using a Routing Protocol...

Because if someone just says: OH MY GOD THIS WILL NOT WORK, and provides zero details, then I want to see where in the RFCs it is discussed. (DRAFTS are fine, too)

You have read the quote, have you? Because: "the lifetimes on a delegated prefix".
The updated RFC for DHCPv6 (RFC 8415)[1] states that an address AND a prefix-delegation has a timer. And the lifetime can be exceeded if the requested asks for it.

Whats your issue with RA here anyway!? I still don't get it. (You have introduced RA to the discussion in your first post.)
RA just informs a host on a link about a prefix and its flags, and if the sender of the RA is able to act as a default router. But this has nothing to do with my question:
Is it possible with odhcp6c to simulate/preserve an old state, so that after a reboot of my router, the router is not requesting a new address and not requesting a new prefix, and just acts as there was a minor glitch on the link. (Just because you have lost carrier does not mean that you will need a new address or a new prefix.)

[1] That an address AND a prefix has a lifetime was present on the first versions, too.

You never mentioned PPPoE. As you mentioned, that changes things.

Sorry, carry on.

What does it make for a difference in your opinion? (I have found a hint that odhcp6c can just fake a default route in case there is RA on the link, but what else? Now I'm curious...)

If you wanna "fake" a default route. that's fine; but you then quoted/mentioned RFCs - as if this is some standard. (that may relate to configuring a corresponding static route on another interface). My apologies if that caused confusion.

On a standard Ethernet/IP link, the route comes from the RA. From your description in further posts, it seems like you're not concerned about that - additionally you mentioned PPPoE. I noted that you can test to see if this works by simply assigning the previous prefix/IP in range and verifying if the test works by obtaining IPv6 connectivity.

Lastly - your faking/making some default route doesn't guarantee that the ISP's route back to you is still established (this is why I suggested a test). :wink:

If the DHCPv6 client does not send a RELEASE then from the ISPs view, nothing has changed. The lifetime of the prefix and address is still valid, and was not removed because no RELEASE.

And yes, I can probably try this manually or even hack a shitty sh-script, but this will maybe conflict with other moving parts on OpenWRT, that's why my (first) idea was, if it is possible to dump the state of odhcp6c and reload this state after reboot.

1 Like

That makes sense - TBH I'm not familiar with the nuances of IPv6 over PPPoE (and I'm not sure how Neighbor packets relate in this case).

I would definitely test the theory first by simply assigning it statically first - I don't see how this simple test would "conflict with other moving parts".