[HN Gopher] An Introduction to NAT64
___________________________________________________________________
An Introduction to NAT64
Author : telmich
Score : 33 points
Date : 2021-03-09 16:47 UTC (1 days ago)
(HTM) web link (ungleich.ch)
(TXT) w3m dump (ungleich.ch)
| xmichael0 wrote:
| I see no reason to use NAT64 over NAT. Am I wrong here?
| mrkurt wrote:
| They're different things. NAT64 is useful for bridging between
| ipv6 and ipv4 networks, it's just a way of encoding ipv4
| addresses in ipv6 addresses. It's more straightforward than
| ipv4 nat because there's no port rewriting.
| xmichael0 wrote:
| NAT64 requires port rewriting.
| snuxoll wrote:
| NAT64 still needs port translation, it's doing the same job
| an IPv4 NAT gateway has to do, but additionally translating
| IPv6 addresses to IPv4 ones.
| [deleted]
| MayeulC wrote:
| NAT64 is useful to allow IPv4 services to work in an IPv6-only
| environment. It's nice to only have one stack to administrate,
| and IPv6 is generally more flexible, but you often need to fall
| back to IPv4.
|
| NAT64 is more and more used instead of CGNAT (well, it's still
| CGNAT to an extent), but I don't really see one being
| advantageous over the other. Only that there are only IPv6
| semantics when using NAT64, so stuff like roaming, privacy
| extensions, etc. works, and you don't have to rely on dual-
| stack.
|
| I think _the_ big advantage to NAT64 is identifying the pain
| points (incompatible equipment, applications, etc) in an
| IPv6-only world. And it really is a clear transition path to
| IPv6.
| xmichael0 wrote:
| Thank you for your comprehensive and thoughtful answer. I
| agree with everything you said, except for the idea that we
| are transitioning, we will always live in a hybrid ipv4 ipv6
| world (;
| betterunix2 wrote:
| I doubt that we will _always_ live in a hybrid world. IPv4
| address space exhaustion is a growing problem and NAT is at
| best a partial solution. As more ISPs resort to things like
| NAT64 and 464XLAT the shortcomings of NAT (of whatever
| form) will become a larger problem and developers will
| start writing IPv6-only applications. After enough time
| IPv4 service will become optional, and shortly thereafter
| irrelevant.
| MayeulC wrote:
| Ah, but those who live behind NAT64 are already living in
| an IPv6-only world ;)
|
| Do _you_ really think there will never be IPv6-exclusive
| services? I personally think it 's bound to happen, if only
| some private websites here and there. Maybe some country
| will make a bit push? At this point, _not_ having IPv6
| connectivity starts being a liability.
|
| Going forward, whether everyone adopts IPv6 or not doesn't
| really matter I think. Legacy equipment will carry on under
| IPv4, even if it is just NATed IPv6. Servers, intranets and
| VPN can keep on using v4 if they prefer, but servers will
| need to be dual-stack if they need to contact IPv6 hosts
| (databases, APIs, websites). NAT64 (with a dedicated IPv4)
| is a clean way to handle dual-stack, I wonder if it will
| be, or is already available in datacenters?
|
| Thinking more about it, these semi-public API endpoints is
| where the transition might happen first: some services
| already leverage IPv6, like smart power meters. If both
| endpoints are controlled by the same entity, it's quite
| easy to make them IPv6-only, especially if public access is
| possible, but not a priority.
|
| Keep in mind those are my opinions, I am not a network
| professional!
|
| ---
|
| I wonder how much longer it will take for publicly
| available IPv6-only services to appear? 10 years? 20 years?
| Once they start appearing, how long will most ISPs take to
| deploy IPv6? 5 years? What if, say Belgium mandates its ISP
| to provide IPv6 connectivity? Would that boost adoption in
| the Netherlands?
|
| _In the end, it 's easy to contact IPv4 hosts if you only
| have IPv6, but the opposite isn't true_, because only one
| can encapsulate the other.
|
| If IPv6+NAT64 starts being a viable and widely adopted
| option, will we have a surplus of IPv4 addresses? Will
| websites start to block IPv4 due to spam issues?
|
| If enough people like me are eager to transition, we will
| transition somewhat... due to network effects :)
| betterunix2 wrote:
| Avoiding dual-stack is one big reason. NAT64 is also a key
| component of 464XLAT, which is technically superior to NAT444
| as it only requires one NAT gateway instead of two.
| kgersen wrote:
| sound is too low.
| sigio wrote:
| Another video on NAT64 by ungleich:
| https://www.youtube.com/watch?v=IoYKNE4kSrA on their
| implementation using p4
| moonbug wrote:
| Typically paired with 464xlat in an IPv6-only environment, for
| programs that are hard-coded for IPv4.
|
| An excellent `just-works` example is
| https://github.com/toreanderson/clatd
| andrewshadura wrote:
| Back in the day I wrote tnat64, a simple tsocks-like wrapper to
| redirect IPv4-only applications to a NAT64 gateway. It even
| worked with Skype to a degree: it'd log in and then repeatedly
| reconnect every minute or so.
| fmitga wrote:
| Oooh, I actually have a use for this. Any interest in open
| sourcing it?
| andrewshadura wrote:
| It has been open source since the very beginning:
|
| https://github.com/andrewshadura/tnat64
|
| https://tracker.debian.org/pkg/tnat64
| slindsey wrote:
| Such a pet peeve of mine. Define it, at least on the page. From
| wikipedia.
|
| > NAT64 is an IPv6 transition mechanism that facilitates
| communication between IPv6 and IPv4 hosts by using a form of
| network address translation (NAT). The NAT64 gateway is a
| translator between IPv4 and IPv6 protocols, for which function it
| needs at least one IPv4 address and an IPv6 network segment
| comprising a 32-bit address space.
| andrewshadura wrote:
| Fun fact: I wrote the initial version of that page. I taught
| networking lessons at a university, IPv6 transition mechanisms
| were one of the topics we covered, and this one didn't have an
| article, so I wrote it. It was quite funny when one of the
| students realised it was who wrote it when they went to
| Wikipedia wanting to learn more :)
| zamadatix wrote:
| It's a follow up to the second part and covered in the first
| minute of the video as review anyways.
___________________________________________________________________
(page generated 2021-03-10 23:02 UTC)