Hurricane Electric stance on NAT64

[kasperd]

I came across this post on Twitter which says Hurricane Electric's stance is that NAT64 hinders IPv6 adoption:
https://twitter.com/treysis/status/1229429649668792320

Does Hurricane Electric have an official stance on NAT64?


I know that Hurricane Electric used to operate a NAT64 gateway. But that is no longer available (though DNS64 is still up.)


I don't believe that NAT64 hinders IPv6 adoption. I am running https://nat64.net/ because I believe that a public NAT64 service has the potential to speed up IPv6 adoption. And I hope there are ISPs and transit providers who are interested in working together on making that happen. At the moment I do have some tunnelbroker.net tunnels among the more active users.

For those reasons I am quite interested in hearing whether the above post is in fact representative of Hurricane Electric's official stance. And if it is, I am wondering if there is anyone I could have dialogue with to understand why we have such different ideas of the effect of NAT64 services.

[tjeske]

It's mainly based on this reply:
https://forums.he.net/index.php?topic=3887.msg21773#msg21773
but also other replies to other requests.

As far as I understand HE is routing IPv6-traffic, not IPv4-traffic. Having a NAT64 would mean they would have to join the IPv4-business as well. So, naturally I believe they want to push IPv6 adoption. Providing the tunnel facilitates this.

However, I do understand how IPv6-only devices have difficulties reaching v4-only, and giving them the option to use NAT64 for that could promote people setting up v6-only devices. But right now that would probably only provide an advantage to hosted servers. Everyone at home having native IPv6 will also still have some way of IPv4, where setting up your own NAT64-gateway is a possibility (I can only imagine some very rare special networks where this would not be possible - I have a v6-only vServer where the company offers IPv4 for extra money, so being able to use a NAT64 is just a thing nice-to-have, so again thank you very much for your service ;) ).

And speaking of providers of server hosting with v6-only hosts (thinking of datacenterlight.ch / ungleich.ch) they do offer their own NAT64-gateway for customers of their v6-only servers. So, I see very little value in providing public NAT64 from HE's PoV.

PS: That doesn't mean I wouldn't like it if they figured out some meaningful way to offer NAT64 in their tunnel endpoint locations around the world :)

PPS: Didn't know they had a NAT64? Didn't even know about the DNS64. So you're saying the DNS64 is still running? Never read about it. Are you really certain about this?

[kasperd]

It's mainly based on this reply:
https://forums.he.net/index.php?topic=3887.msg21773#msg21773

That post mentions some very different reasons than the Twitter posting. The main reason it mentions is abuse. In my NAT64 pool I have taken a few steps to limit the potential for abuse. First of all I have made it such that you cannot hide your IPv6 address behind my NAT64. If the IPv4-only services want to know, they can download an open source daemon which will log all of the IPv6 addresses accessing their service through any of my NAT64. And if they don't like the traffic they receive from me they can send one packet to my NAT64 which will blacklist the server IPv4 address.

Of course it would be better for everyone if those servers would just upgrade to dual stack. Then they would receive the traffic without any NAT involved and would thus see the real IP address of the clients.

The other issues the post mentions are related to the drawbacks of running your IPv6 through a tunnel and then use NAT64 to get back to the IPv4 network. I agree that one has to be pretty fanatic about IPv6 to use that combination. I do use my own NAT64 pool through an IPv6 tunnel today, I do that because I should be relying on my own service, and I am still struggling to get native IPv6 where I live. (I am actually running a local NAT64 on my home network as well, and I am running my IPv6 tunnel through that NAT64. My local NAT64 isn't used for anything other than tunnelling).

As far as I understand HE is routing IPv6-traffic, not IPv4-traffic. Having a NAT64 would mean they would have to join the IPv4-business as well. So, naturally I believe they want to push IPv6 adoption. Providing the tunnel facilitates this.

One thing which NAT64 has in common with a 6in4 tunnel service is that both are transitioning services which speak IPv4 on one side and IPv6 on the other side. As such I say both kinds of services facilitate the transition to IPv6. But they are intended for different networks.

HE already need IPv4 connectivity for the tunnel service. I don't know the specifics of their customer/peering/transit arrangements, so I have no idea if the traffic through their tunnel service is earning them money or costing them money.

If HE had NAT64 gateways which were only used by tunnel users the traffic would indeed only be IPv6 within the HE network and it would be IPv4 on both sides of HE. It could argued that an arrangement like that would not promote IPv6. But if HE could charge transit costs from the IPv4 networks on both sides, then they could potentially promote IPv6 by making IPv6 cheaper for those networks than IPv4.

However, I do understand how IPv6-only devices have difficulties reaching v4-only, and giving them the option to use NAT64 for that could promote people setting up v6-only devices. But right now that would probably only provide an advantage to hosted servers. Everyone at home having native IPv6 will also still have some way of IPv4, where setting up your own NAT64-gateway is a possibility (I can only imagine some very rare special networks where this would not be possible - I have a v6-only vServer where the company offers IPv4 for extra money, so being able to use a NAT64 is just a thing nice-to-have, so again thank you very much for your service ;) ).

There was a time where I was living in a place where I could get native dual stack on fiber. It even included a static IPv4 address at no extra cost. And still I used the provider's NAT64 just so I didn't have to deal with NAT on my home network. That was such a pleasant experience that I want to share with others as much as I can.

Some of the dual stack networks around may not have the same opportunity. It's quite possible that on some of the networks where you get dual stack you'd end up with three layers of NAT if you wanted to use NAT64.

And speaking of providers of server hosting with v6-only hosts (thinking of datacenterlight.ch / ungleich.ch) they do offer their own NAT64-gateway for customers of their v6-only servers. So, I see very little value in providing public NAT64 from HE's PoV.

If your provider has NAT64 there is less reason to use a public NAT64. Though I might beat some of those providers on reliability.

PS: That doesn't mean I wouldn't like it if they figured out some meaningful way to offer NAT64 in their tunnel endpoint locations around the world :)

I wonder if there is anything I can do to help make that happen.

PPS: Didn't know they had a NAT64? Didn't even know about the DNS64. So you're saying the DNS64 is still running? Never read about it. Are you really certain about this?

Absolutely. I verified before posting that the DNS64 is still responding to queries. It's pretty useless at the moment though as it's pointing to a NAT64 which is no longer working.

A long time ago I read a post on this forum mentioning that it existed, but that post didn't mention an address. The IPv6 address of the DNS64 is however easy to guess and the standardized way to learn the NAT64 address is by asking the DNS64. I have used the HE NAT64 a little bit in the past. But it's been out of service for a few years now.