There's a comment above that indicates tunnel brokering can't handle NAT situations (at least CGNAT).

RFC3053[0] seems to indicate this can be a problem as well:

> 3. Known limitations

   This mechanism may not work if the user is using private IPv4
   addresses behind a NAT box.

Are you saying it works even behind a NAT?

EDIT: According to HE's own FAQ[1]:

> If you are using a NAT (Network Address Translation) appliance, please make sure it allows and forwards IP protocol 41.

That doesn't sound like something most ISPs are likely to support. Not sure about home routers but if it has to be configured manually we're back to square one.

[0]: https://tools.ietf.org/html/rfc3053

[1]: https://ipv6.he.net/certification/faq.php

I don't know exactly anymore, because I'm now with a different ISP which natively supports v6. So can't reproduce.

I mean I (probably) could, but don't want to, because now I have IPv4 via CGNAT, but not with a private IP, a public dynamic one probably shared with who knows how many others.

But I can use IPSEC/OpenVPN/Wireguard to somewhere else with that. Though my CPE supports GRE.

Anyways, there are large implementation differences in CGNAT from ISP to ISP and even different access technologies within the same.

Wow, am I getting this right? It handles NAT traversal for you behind the IPV6 address for free??

What do you mean by that exactly? Initially it's just an outgoing tunnel to one of their many exits, to reach any site which is reachable via v6. How you integrate that into your setup is up to you. Since they are (one of?) the pioneers you have many scripts available on many platforms which support that.

When you mean incoming tunnel, it's no different from the many dynamic DNS solutions, where it's again up to you to integrate that. But even for this they have something:

https://dns.he.net/

Yeah, dynamic DNS but for an IPV6 address was what I was meaning. Very interesting.

Have fun. It's cool to have. If only to get acquainted with that v6y stuff.