Feature-Request: Rename tunnel manually

[rekire]

I have two tunnels at the moment in the meanwhile I had a third one which I have deleted.

If I take some time I will change my settings to use not longer username-1.tunnel.xxx.yyy.ipv6.he.net and instat username-3.tunnel.xxx.yyy.ipv6.he.net.

The xxx is the tunnel-server and yyy the server number. See also this list.

So I've got then the "-3" in the rDNS entry. Is it possible to change it so something else? Maybe gatway.mygreatcompany.xxx.yyy.he.net? I mean that would be unique enough that the connection was transmitted there. And also it looks in a traceroot my opinion a little cooler that the username with an index.

[kasperd]

There is another option. You can assign an additional address to the tunnel interface for which you control the reverse DNS. Then you just need to make sure that the address for which you control the reverse DNS is the preferred address for ICMP packets send on that interface.

[rekire]

Correct me if I am wrong but I think that you mixed up the two ip-rages per "tunnel". The first one is the first ipv6 hop of he.net and the second one is the client net which you can control like you want.

$ dig -x 2001:470:xxxx:be2::1 +short
username-1.tunnel.xxx.yyy.ipv6.he.net.
$ dig -x 2001:470:xxxx:be2::2 +short
username-1-pt.tunnel.xxx.yyy.ipv6.he.net.

The [...]::1 in there the ipv6 gateway and [...]::2 your interface IP.

[broquea]

You don't get to edit or change the rDNS on the tunnels point-to-point /64. You can ONLY modify rDNS entries for the routed /64 and /48.

[rekire]

Yes I know this is a feature request.

[kasperd]

Correct me if I am wrong but I think that you mixed up the two ip-rages per "tunnel".

I didn't mix them up. I suggested a different way to make use of them. If you were to follow my suggestion the configuration of the two ends of the tunnel would be slightly out of sync. However that won't be a problem because the packets actually flowing over the link between them will be perfectly compliant and valid with either of the two configurations.

I am aware that what you want to achieve won't happen with the default configuration of the tunnel interface, unless HE implements an additional feature as you requested. However you can make traceroute from the Internet towards your network look the way you want them two even with the functionality that HE provides today.

Let me sketch how it can be done. First let me describe how it could be done if you have a routed /48, since it is a bit simpler in that case.

You have one /64 for the tunnel interface. Under this /64 ::1 and ::2 are allocated and the rest is unused. You don't control RDNS for this /64, so you don't want it to be visible to the traceroute from the Internet.

In IPv6 you can assign as many IPs to an interface as you wish. So you can allocate another /64 out of your routed /48 and use this additional /64 for the tunnel interface as well. With this additional /64 you now have two IPv6 addresses on the tunnel interface at your end of the tunnel. The HE end of the tunnel only has one of the two.

When your gateway needs to send an ICMP response it must use an IPv6 address assigned to the interface it received the packet on. With the configuration I suggest that interface will have two IPv6 addresses, so it can make a choice. You just need to ensure that it prefers the one for which you control RDNS.

The fact that your end of the tunnel has two /64s and the end on the tunnel server only has a single /64 doesn't become a problem. Packets flowing from the tunnel server to you will use the one /64 which it has, and it is one of the two assigned to your end, so no problems. Packets flowing from your end to the tunnel server will use the /64 which the tunnel server doesn't have on its interface, but that is not a problem either because the tunnel server will simply assume it was forwarded by your gateway as the source IP address will be part of your routed /64. In fact only ICMP responses generated by one end of the tunnel will ever carry one of the IP addresses assigned to the tunnel interfaces. Normal traffic flowing through the tunnel and not triggering an ICMP response doesn't even use the IPs assigned to the tunnel at all.

It may seem like a bit of waste to request a full /48 just because you want one more IP address for which you control RDNS yourself. With a bit of tweaking you should be able to make it work with just the routed /64 and no routed /48. In this configuration you cannot create a /64 for your LAN and an extra /64 for the tunnel interface. So what you do is to allocate the full /64 to the LAN and a subset of it to the tunnel interface. Those two will overlap, but that won't be a problem if you just configure them correctly.

You can assign a /126, /127, or even /128 as the extra address on the tunnel interface. Using a /128 will avoid some potential problems, so that is the best if the software on your gateway supports it. To ensure that the address doesn't get used by another node on the LAN and to ensure that other nodes on the LAN can send packets to this IP address, you should assign it as an extra IP address on the LAN interface as well. That way this extra IP address will have been assigned to both interfaces on the router, with each interface having a normal IP address as well.

Can a configuration like this be made to work?
Yes, definitely.

Can I guarantee that the software on your router can handle it?
Of course not.

Is it possible to mess up the configuration such that something breaks?
Of course it is.

I hope this is enough details that you can understand what I am suggesting, and why it will achieve the functionality that you requested. It is up to you if the feature is desirable enough for you to tolerate the risk of messing up the configuration. You can also wait and see if your feature request is going to be accepted, as that would be the only way to get what you want without changing the configuration of your tunnel endpoint. Personally I like to be in control over RDNS for IP addresses I use to communicate with the world. I don't care much about RDNS for intermediate hops in a traceroute output. I wouldn't want to change the configuration of my tunnels just for that.

[rekire]

Thank you kasperd for your highly detailed answer. It gave me a deep look into the possibilities of routing in order to implement such gimmicks.