Sonic.net

I'm a new Sonic Gigabit Fiber customer, and would like to use the IPv6 tunnel in the labs. I tried setting it up using my current IP address as the tunnel endpoint, and everything works as expected.

However, since I don't have a static IPv4 address (and as a Fiber customer, that's apparently not an option), as soon as my IP address changes, the tunnel endpoint becomes wrong and my packets land... somewhere else.

So, what to do? Assuming that that endpoint address cannot update automatically based on what I got through DHCP, is there some REST API or something that I can use to change the tunnel endpoint address programmatically?

I have tried this, and it worked:
https://help.sonic.com/hc/en-us/article ... _or_5268ac
However, I ended up turning it off because it was an undue bottleneck on the gigabit connection.

Thanks Daniel, I am aware of the separate 6RD tunneling, and it indeed works. However, I would like to use the static tunnel as well.

By the way, I gauged out the MTU of the 6RD tunnel, and after seeing that it seems to be 1472 (I don't know where the additional 8 byte added onto the IPv4 header overhead of 20 bytes come from, but this works for me) and clamping the MSS to the appropriate value (1412 bytes: 40 bytes vor the IPv6 header, 20 bytes for the TCP header), the 6RD tunnel does not seem to be much of a bottleneck on my Gigabit Fiber connection.

If you are testing the MTU with different-sized payloads to Ping, the ICMP packet you are attaching the payloads to are where the additional 8 bytes come from, and you should adjust the payload size accordingly, or you will force packets to be oversized every time.

No, it's not the ICMP header. The maximum *packet* that can go out through the tunnel interface is 1472 bytes. Adding the GIF IPv4 header (20 bytes), that means that the maximum packet size that can go to the tunnel server is 1492. That is 8 bytes less than expected, and I have other tunnels that have the expected 1480 MTU on the tunnel interface without problem.

My guess is that the packets somehow get sent on at sonic with a protocol that adds 8 byte overhead (after it went out on my end, so I don't see it). It's not really a problem for me, though, just interesting.