• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

tunnelbroker sample commands INCORRECT?!

Started by funtoo, December 23, 2019, 11:12:06 AM

Previous topic - Next topic


Hello all/HE staff,

Correct me if I'm wrong, but I think the commands that the tunnelbroker example config prints out are incorrect, or potentially sub-optimal. For my tunnel, this is what 'example configurations' prints out for linux-net-tools:

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote local ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:39:56::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

I am going to propose that this is wrong, that the "ip addr add" command should have a /128 on the address, and not a /64.

If you are using your /64 and handing out IP addresses via radvd, then your /64 will be local (ie. not on the other side of the he-ipv6 tunnel.) So this route is incorrect.

Using /128 will result in just a route to the ::2 address only. But without, your entire /64 will be assumed to be on the 'wrong' side of the tunnel. This actually does not create problems when you are just setting up routing for a single machine that has a tunnel on it, but if you are advertising routes on your LAN, this route is incorrect.

Using /128, along with radvd, I get the correct routes:

mork ~ # ip -6 route
2001:470:39:56::1 dev brwan proto kernel metric 256 pref medium
2001:470:39:56::2 dev 6to4 proto kernel metric 256 pref medium
2001:470:39:56::/64 dev brwan proto kernel metric 256 expires 30sec pref medium

In this case, I am using radvd on bridge brwan.

I'm relatively new to IPv6, so hopefully I'm not making a fool of myself here, but it seems like correcting the example commands to have /128 will result in a Linux routing configuration that will work for the host *and* bridged devices, whereas the current config just breaks when you have other devices on your LAN utilizing the tunnel.

Looking forward to feedback. Also note -- this /128 fix was what I needed to successfully configure the tunnel on the host as well as for the bridged LAN with radvd.


Our side is configured as /64, so your side is configured /64. This has been working for nearly 20 years now, so yeah...

Only BSD systems wanted the /128 as part of the command, regardless of prefix size.

If you are configuring your LAN with either static/DHCP6/RADVD you should be using your routed /64 or /48, not the link /64. That is true for IPv6 as it is for IPv4. Stop bridging the p2p link allocation, that is silly. We already statically route you subnet(s) for LAN usage.


You have two IPv6 allocations...one is the tunnel /64 that you really shouldn't use other than to create the tunnel and the other is the routed /64 that you use to assign addresses to other hosts in your LAN.  If you have more than one subnet in your LAN, you should request a /64.

So, in short, a second host in your network should NOT have an address in 2001:470:39:56::/64, it should be in your routed /64


But my routed /64 *is* 2001:470:4b:56::/64.

Here is my tunnel configuration straight from the tunnelbroker control panel:

Creation Date:Dec 12, 2019
IPv6 Tunnel Endpoints
Server IPv4 Address:
Server IPv6 Address:2001:470:39:56::1/64
Client IPv4 Address:
Client IPv6 Address:2001:470:39:56::2/64
Routed IPv6 Prefixes
Routed /64:2001:470:4b:56::/64
Routed /48:Assign /48
DNS Resolvers
Anycast IPv6 Caching Nameserver:2001:470:20::2
Anycast IPv4 Caching Nameserver:

I need the /128 route for it to function as I described.

If I'm doing something wrong, I don't understand, so please explain.


Might as well post my radvd.conf as well:

# RADVD with no DHCPd6 configuration
interface brwan {
      AdvSendAdvert on;
      AdvLinkMTU 1480;
      MinRtrAdvInterval 60;
      MaxRtrAdvInterval 180;
      prefix 2001:470:39:56::1/64 {
            AdvOnLink on;
            AdvRouterAddr on;
            AdvPreferredLifetime 600;
            AdvValidLifetime 3600;


OK, I think I see the issue -- 39 vs 4b. I am specifying the wrong network there. I'll see if that resolves it.


OK, I fixed my typo in radvd.conf, moved the /128 back to /64, and it works. Questions:

Is there any harm in using /128 in the config?
That tunnel /64 is just using ::1 and ::2 and the rest of the addresses are unused (and you're just allocating a /64 for two IPs)?
It seems that my /128 workaround demonstrates that the tunnel IPs, even though it's not supposed to be done, can be used successfully. I'm not going to do it but other than it violating the expected use of the IP space (which is sufficient reason NOT to do it), is there any technical reason why this should not be done? (Not looking for excuses, just trying to understand the technical aspects.)




You don't have the ability to do anything with DNS for the tunnel /64, and while that might not be a big deal for you, why bother?   Just use the routed /64 instead.  This might sound wasteful, but you're thinking in terms of IPv4, not IPv6; IPv6 has a full /32 dedicated for documentation alone...