I am attempting to upgrade from VyOS 1.4-rolling-202402190030 to VyOS 1.5-rolling-202412060007 and am running into trouble with DHCPv6-PD.
Because I am also upgrading hardware, my methodology was as follows:
Install VyOS 1.5-rolling-202412060007 on the new machine.
Carry over the configuration from the old machine to the new via show configuration commands modifying the interfaces as appropriate.
Monitor for errors in the console indicating syntax changes and fix as necessary - I encountered none of this and the config literally worked 1:1 aside from re-labeling interfaces (interface name, interface hardware ID).
Everything on the new box works, except DHCPv6-PD. Doing a tcpdump on the WAN interface shows the box doing DHCPv6 solicitations, but not receiving any response. If I fail back to the VyOS 1.4-rolling-202402190030 box, DHCPv6-PD works just fine.
I initially thought maybe my ISP (Verizon) was handling the MAC address change stupidly, so I spoofed the MAC address of the old machine and that did not make any difference.
Here is the relevant DHCPv6-PD configuration that is in place on both machines. The only difference is the WAN interface on one machine is eth0 and the other is eth10.
Firewall Rule permitting DHCPv6 and ICMPv6 inbound:
set firewall ipv6 name INET-TO-LOCAL-V6 default-action 'drop'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 1 action 'accept'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 1 state 'established'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 1 state 'related'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 2 action 'drop'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 2 state 'invalid'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 10 action 'accept'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 10 description 'Allow ICMPv6'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 10 protocol 'icmpv6'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 20 action 'accept'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 20 description 'Allow DHCPv6'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 20 destination port '546'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 20 protocol 'udp'
set firewall ipv6 name INET-TO-LOCAL-V6 rule 20 source port '547'
Firewall rule permitting everything outbound:
set firewall ipv6 name LOCAL-TO-INET-V6 default-action 'accept'
The only thing I haven’t tried is downgrading the new box to VyOS 1.4-rolling-202402190030. I may give that a shot. However, I would really like to figure this out
P.S. - I wish I could still build 1.4 as I would try building the latest and testing to see if this is a problem with both.
It looks like you have the exact opposite problem I’m having with Verizon. I can get a DHCP-PD response, but I’m not getting a WAN ipv6 address.
Looking over your config, I wonder if this could be an issue?
set interfaces ethernet eth0 dhcpv6-options no-release
I think this only applies to your WAN address, but if it also carries over to the ipv6 prefix delegation, maybe Verizon isn’t assigning a new one since it thinks you have one already.
You could try running the old router, delete/commit the no-release option, then shut down the router. Or maybe there’s an explicit operation command to release the prefix delegation, although I’m not sure what that would be.
Also, I think I read with Verizon, the prefix delegations have to be renewed every 2 hours (although I’m not sure), so this might clear up on its own once your old delegation expires.
Spoofing the old MAC address on the new WAN interface might also be another option.
FWIW, I have just this on my WAN interface right now:
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 address 'dhcpv6'
set interfaces ethernet eth0 description 'WAN'
set interfaces ethernet eth0 dhcpv6-options pd 0 interface eth1 address '65535'
set interfaces ethernet eth0 dhcpv6-options pd 0 interface eth1 sla-id '1'
set interfaces ethernet eth0 dhcpv6-options pd 0 length '56'
set interfaces ethernet eth0 hw-id '--:--:--:01:db:1d'
set interfaces ethernet eth0 offload gro
set interfaces ethernet eth0 offload gso
set interfaces ethernet eth0 offload sg
set interfaces ethernet eth0 offload tso
set interfaces ethernet eth0 dhcpv6-options no-release
Is not the problem. That was not in the original config. I tried a bunch of stuff in lock step on both instances to ensure I wasn’t breaking things. That was one of the items that I forgot to clean up.
I should mention that I started this project yesterday and left the new VyOS instance “in production” overnight. No DHCPv6-PD addresse at all come the morning.
I also spoofed the MAC address of the WAN interface of the old instance and that didn’t change anything.
FWIW I have never received a WAN IPv6 address from Verzion, so what I did was set up a “dummy” interface and had a prefix delegated to it. It’s sole use is for WAN to LOCAL stuffs and seems to work, but it’s not super useful as Verizon (in my service area anyway) will re-issue you a new /56 any time the WAN interface bounces (which is quite annoying).
I’ve just re-installed VyOS 1.4-rolling-202402190030 and moved the config over, but still need to re-rack the new box. I am going to start by not spoofing the WAN interface MAC address and see what happens.
Welp, even after installing the same version and the config as identical as possible (just changing interface names and hardware-ids) still no DHCPv6-PD addressing.
I even spoofed the MAC address of the WAN interface from the old router.
@wanderingstar I wonder if you’re on to something where I need to have the old router gracefully release the prefix delegation. I am simply moving cables between boxes, so whether or not no-release is set doesn’t apply since the old box has no opportunity to send a client release message. However, I would expect that even after spoofing the MAC (show interfaces reflects the expected MAC for the WAN interface) that Verizon’s side would know no different…but I wonder if there is some additional client identifier(s) that are different outside of simple MAC address. The source link-local address would likely be different, so I bet that may be a factor.
Yep. I upgraded to 1.5-rolling-202412060007. I was still spoofing the WAN MAC from the old box, but the dhcp6c DUID file was replaced. I copied the DUID file back over from the old box and DHCPv6-PD from Verizon works.
I suspect I may need to stop spoofing the MAC and just wait 24 or so hours, or attempt to call them and see if they can clear DHCPv6 on their side (if the tech even knows what I’m talking about).
And after a ~24 hour wait, DHCPv6 cleared and things are better. Good learning experience for sure. I’ll need to note that if I change hardware it’ll be ~24 hours until I get IPv6 prefix delegations again .
.