by stromson » Thu Jan 28, 2021 1:00 pm
I have Sonic IPv6 at home, and have so far been unable to get packets destined for the /60 "network" subnet provided by Sonic to show up on the gif0 interface. Packets destined to my end of the /127 "transport" subnet do however appear. I have however been able to get to work, though with additional latency.

Here is the config provided by

Transport:: 2001:05a8:0000:0001:0000:0000:0000:28aa/127
Network:: 2001:05a8:0004:0320:0000:0000:0000:0000/60
Your current tunnel endpoint is: 135.180.27.X
Master DNS Server IP (More Info): 135.180.27.X

I am attempting to provide a /64 for both internal interfaces (igb0 and em0), so here is the output of my setup script:

Code: Select all

+ ifconfig igb0 inet6 2001:5a8:4:320::1 prefixlen 64
+ ifconfig em0 inet6 2001:5a8:4:321::1 prefixlen 64
+ ifconfig gif0 destroy
+ ifconfig gif0 create
+ ifconfig gif0 tunnel 135.180.27.X
+ ifconfig gif0 inet6 2001:05a8:0000:0001:0000:0000:0000:28ab/127
+ route -n add -inet6 default 2001:05a8:0000:0001:0000:0000:0000:28aa
+ ifconfig gif0 up

When run in this configuration,I’m able to ping, and the packets show up with a source address of gif0, which is my end of Sonic’s /127 transport subnet:

Code: Select all

12:38:44.953375 IP6 2001:5a8:0:1::28ab > ICMP6, echo request, seq 8, length 16
12:38:44.961627 IP6 > 2001:5a8:0:1::28ab: ICMP6, echo reply, seq 8, length 16

I can also confirm that is able to access my host using 2001:5a8:0:1::28ab

Code: Select all

12:41:28.404969 IP6 2610:a0:3:9::b > 2001:5a8:0:1::28ab: ICMP6, echo request, seq 1, length 64
12:41:28.405014 IP6 2001:5a8:0:1::28ab > 2610:a0:3:9::b: ICMP6, echo reply, seq 1, length 64

But, what about the two interfaces I have attached to the /60 network? As best as I can tell, the /60 is not routed at all. Sending ICMP packets from the world to either internal interface, 2001:5a8:4:320::1 (igb0) or 2001:5a8:4:321::1 (em0), do not result in the packets showing up on gif0. The traceroute from to 2001:5a8:4:320::1 (igb0) seems to end at 2001:5a8:0:6::2

Code: Select all

5 (2001:5a8:5:3a::9:a)  116.307 ms *  146.668 ms
16 (2001:5a8:5:3a::a:a)  113.874 ms *  113.668 ms
17  * * 2001:5a8:0:6::2 (2001:5a8:0:6::2)  107.531 ms
18  * * *
19  * * *
20  * * *

This has forced me to come to the conclusion that either I am misunderstanding that Sonic provides a /60 for users to split into separate /64's, or that Sonic is not routing the /60 to my end of the tunnel.

To test my opinion, I modified my script to setup a tunnel to Hurricane Electric, which provides a /48, and it worked instantly without any routing issues. One interesting note was that there was a prefixlen of 128 instead of 127 for my end of the tunnel.

Code: Select all

+ ifconfig igb0 inet6 2001:470:803d:1024::1 prefixlen 64
+ ifconfig em0 inet6 2001:470:803d:cafe::1 prefixlen 64
+ ifconfig gif0 destroy
+ ifconfig gif0 create
+ ifconfig gif0 tunnel 135.180.27.X
+ ifconfig gif0 inet6 2001:470:803d::2 2001:470:803d::1 prefixlen 128
+ route -n add -inet6 default 2001:470:803d::1
+ ifconfig gif0 up

I would stick with Hurricane Electric, but using the nearest endpoint (Fremont) adds a tremendous 19ms of ICMP latency to Google. I haven’t attempted to benchmark the real-world impact, but it is worrying.

Here is the script I have written to toggle between Sonic & as 6in4 providers: ... 0ba30f8f2a

Thank you for your help!