Reverse DNS for IPv6 tunnel

Advanced feature discussion, beta programs and unsupported "Labs" features.
12 posts Page 2 of 2
by matt.kinkele » Mon Jun 17, 2024 12:20 pm
Hello there,

Thanks for the PCAP!
I've sent you an email with some specific troubleshooting steps, but to update the thread here as well, my first suspicion is that you may be encountering the problematic behavior described by Tomoc in this thread.

In brief: When requesting both an IA_NA and a PD, the server processing your requests requires either both of these options to be requested in a single solicit, or for subsequent requests to have distinct DUIDs. If two solicits are sent with the same DUID, the latter will not be able to assign an address. This behavior has been acknowledged by the vendor, but we don't currently know when it will be changed.

There are two ways to dodge this behavior: using a DUID type that ensures each solicit has a unique DUID, or ensuring both options are requested in the initial solicit. If you're using networkd, you should be able to choose DUID type 1 (link-layer + time) to ensure uniqueness. Let me know if you're able to give that a try.
by gutschke » Thu Jun 20, 2024 10:55 am
Thank you to Matt for reaching out. That's truly exception customer service.

My only open issue is that I still can't get reverse DNS, but maybe that isn't supported for IPv6? Or I don't know where to look for documentation.

With the details provided in Matt's e-mail, I was able to make more sense of what was happening with regards to setting up native IPv6 service. Before doing anything else, I upgraded to systemd-networkd version 255. Not sure whether that was technically necessary, but leaving this detail here just in case anybody else looks at this thread.

I then enabled prefix delegation. That was the bit that I had been missing. For some reason, if requesting just a single address, networkd would never be able to get an IA_NA assigned from Sonic. This had thrown me for a loop, as I expected it to be the easiest first step to complete when transitioning away from the tunnel. I suspect, Sonic subscribers who start from scratch and who don't already have a tunnel configured are less likely to run into this issue. So, this could very well become a non-issue for anybody going forward.

Just for the record, my router now receives an IPv6 router advertisement (RA) from Sonic. The "managed" flag is set in the received packet, which causes networkd to automatically start its DHCPv6 client. This works, even if networkd is configured to otherwise ignore DHCP. In the DHCPv6 response, there will be a prefix delegation from Sonic for a ::/56. Networkd assigns an address from this prefix for the WAN interface, and can then send suitable RA to machines on the LAN.

I hope this summary is helpful, and again, thank you so much to Matt for reaching out.
12 posts Page 2 of 2

Who is online

In total there are 2 users online :: 0 registered, 0 hidden and 2 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: No registered users and 2 guests