DHCPv6 PD advertisements are not propagated reliably to tracked interfaces

[kevemueller]

My provider enabled IPv6 with prefix delegation. OpnSense has everything to configure this on the gateway. The provider sends a ::/64 subnet to the gateway and if asked a different second ::/64 for a local network. The setup is straightforward (although it took me several hours to figure...): WAN/IPv4 PPPoE WAN/IPv6 DHCPv6 WAN/DHCPv6 Use IPv4 connectivity WAN/DHCPv6 Request only a IPv6 prefix

LAN/IPv4 Static LAN/IPv6 Track interface LAN/Track interface/interface WAN LAN/Track interface/ID 0

In a "Connect" scenario, the PPPoE interface comes up. The first IPv6 prefix is assigned to the WAN interface, an autoconfigured IPv6 is picked. The second IPv6 prefix is assigned to the LAN interface, and autoconfigured IPv6 is picked. RADVD is promoting the prefix on LAN, autoconfiguration happens. All shiny.

In a "Reconnect"/"Update" scenario: The provider sends new prefixes (they visibly move together) WAN interface picks up the new prefix and picks a new autoconfigured address on this prefix. The new secondary prefix is NOT propagated to the LAN interface, it retains its address from the old prefix. RADVD configuration /var/etc/radvd.conf is not rewritten with the new prefix. The LAN machines continue to use their old prefix addresses. The gateway still has IPv6, but downstream everything is broken.

Some diagnostics: Update of the GW prefix works, because this comes in as a RA and rtsold handles it. Update of the LAN prefix fails, because this comes in as a dhcp6 advertise. DHCP logs a lot, but does not reveal any address information in the log which would give a hint on what is going on.

Any help on how to continue is appreciated.

[kevemueller]

This one is easier. The problem is not with dhcp6c. OpnSense ends up running two instances of dhcp6c on the same interface which of course messes things.

To reproduce: Enter Interfaces/WAN configuration Click on DHCPv6/Configuration mode => Advanced. Enable Debug if it was unchecked, Disable it if it was checked. Click on DHCPv6/Configuration mode => Basic

Apply the changes.

You will end up having two dhcp6c running on the same interface.

The problem seems to be stemming from the fact that dhcp6c takes a long time to die. OpnSense does not wait for it to finish. When the new dhcp6c starts, the old dhcp6 sometimes zombifies. Causing the problem described above (prefixes not propagated).

[fichtner]

I've added a patch, but I can't test right now so I will ask for feedback when it's verified, thanks!

[fichtner]

@kevemueller could not reproduce the process race, but I've tightened the code according to your suggestion. Seems to generate the same results and should work better for you know. Give it a go via the command line:

# opnsense-patch c852405

(rerunning the patch command will revert back to the original state)

With your ok this can go into 16.7.6.

Cheers, Franco

[kevemueller]

Hi Franco, I have applied the patch, rebooted. IPv6 came up well. Tested the reload by flipping Debug flag. The new behaviour is

• much faster convergence to a defined state
• withdrawal of the IPv6 PD on the "slave" interface
• proper renewal of the of the IPv6 PD on the slave - after a while.

Looks like a perfect improvement to me.

Thanks for the great work! Cheers,

[fichtner]

@kevemueller thanks! queued up for 16.7.6 :)