Who out there is using production-scale NAT64? What solution are you using?
Thanks,
Jawaid
OK, I'll bite - what definition of "production-scale" are you using?
Production use for how many digits worth of simultaneous users?
The ALU 7750 MS-ISA card can handle 10Gbps of NAT64 traffic and supports
464XLAT as well.
You used "NAT64" and "production" in the same sentence. Good one.
Seriously though, if you want to run a v6-only network and still
support access to IPv4 Internet resources, consider 464XLAT or
DS-Lite.
Regards,
Bill Herrin
> Who out there is using production-scale NAT64? What solution are you
using?You used "NAT64" and "production" in the same sentence. Good one.
Seriously though, if you want to run a v6-only network and still
support access to IPv4 Internet resources, consider 464XLAT or
DS-Lite.
NAT64 is a required component of 464XLAT.
And, it runs at very meaningful production scale in non-trivial network
deployments.
CB
Sort of, technically, but not really.
NAT64 on its own implies DNS64 and IPv6 client software. Funky
gyrations in the DNS64 server cause the IPv6 software on the client to
originate with IPv6 addresses that the NAT64 server knows how to
convert to IPv4 addresses.
464XLAT does not require DNS64 and provides client software with an
IPv4 interface. IPv4 software that has no idea IPv6 exists sends IPv4
packets which get translated to IPv6 packets. Those packets are routed
to the carrier NAT box which then translates these specially crafted
IPv6 packets back to IPv4 packets.
Functionally, 464XLAT is an IPv6 VPN between your IPv4 client software
and an IPv4 carrier NAT box. Don't let the fact that it's
double-translating instead of encapsulating and decapsulating fool you
-- it's a VPN.
Regards,
Bill Herrin
NAT64/DNS64 on Cisco ASR1006's distributed across the network.
Boxes deployed, traffic minimal as we still have IPv4 addresses as well
(AFRINIC region).
Mark.
We're doing NAT64/DNS64 with Cisco ASR1002s, although it's for a
IPv6-only server network, not for user eyeballs. The biggest downside
has been the lack of SNMP (or similar) support for monitoring the
NAT64 traffic and pool usage, at least on the IOS XE versions we're
running.
-Tom
* William Herrin
>> Seriously though, if you want to run a v6-only network and still
>> support access to IPv4 Internet resources, consider 464XLAT or
>> DS-Lite.
>
> NAT64 is a required component of 464XLAT.Sort of, technically, but not really.
Yes really. See below.
464XLAT does not require DNS64 and provides client software with an
IPv4 interface. IPv4 software that has no idea IPv6 exists sends IPv4
packets which get translated to IPv6 packets. Those packets are routed
to the carrier NAT box which then translates these specially crafted
IPv6 packets back to IPv4 packets.
What do you think the «carrier NAT box» in 464XLAT is, exactly?
No need to guess, we can check the 464XLAT specification:
http://tools.ietf.org/html/rfc6877#section-2
PLAT: PLAT is provider-side translator (XLAT) that complies with
[RFC6146]. It translates N:1 global IPv6 addresses to global
IPv4 addresses, and vice versa.
Let's check that reference:
http://tools.ietf.org/html/rfc6146#section-1
This document specifies stateful NAT64, a mechanism for IPv4-IPv6
transition and IPv4-IPv6 coexistence.
Lo and behold! Your 464XLAT «carrier NAT box» (a.k.a. «PLAT») *is* a
NAT64 box. Thus, if you intend to deploy 464XLAT in production, you'll
going to need a production scale NAT64 implementation.
To answer the Jawaid's original question, I'm very happy with Jool
(http://jool.mx) for my NAT64 (and SIIT) needs, which is a open-source
Linux-based software solution. It has no problems handling several Gb/s
of traffic using a couple of years old x86 server without any tuning,
so if the capacity required is moderate this might be a cost-effective
alternative to a dedicated boxes from the one of the router/network
appliance vendors.
Tore
Yes, I'm curious about this too. I'd like a solid list of providers to
avoid.
NAT64 is opt-in.
It will mostly be used for customers that can no longer obtain IPv4
addresses.
Service providers do not like NAT64 anymore than you do, but there needs
to be some way to bridge both protocols in the interim.
What you should be more interested in is which service providers have
deployed it at scale where it is not causing problems, as those are the
ones you want to be connected to when the IPv4-hell hiteth the faneth!
Mark.
Another relevant metric, less than 25% of my mobile subscribers traffic
require NAT64 translating. 75+% of bits flows through end-to-end IPv6
(thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
This for me is an important note, because if your site only gives out an A address,
it’s going to be slowed by the NAT process. I have noticed the IPv4 penalty getting
worse with many locations.
- Jared
And trust me, Cameron knows what's on about...
And just in case it's not obvious, fewer and fewer bits will need to hit
the NAT64 gateways as more and more of the Internet turns up IPv6.
And the beauty of it all, NAT64-based service providers don't have to
decommission anything in the future; this is one of the key points
around using NAT64 as transition tech.
Mark.
But you only need to hit the NAT64 gateway "if" you are IPv6-only.
If you're dual-stacked, your route to an A record will not hit the NAT64
gateway.
Mark.
So I'm guessing that 75% of the traffic flows with better latency than
the 25% IPvhorse-n-buggy traffic? 
Facebook says IPv6 is 20-40% faster
Another way to look at it, IPv4 is 20-40% slower than IPv6.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
So I'm guessing that 75% of the traffic flows with better latency than
the 25% IPvhorse-n-buggy traffic?
Practically, when we've tested NAT64 at reasonable scale, it does not
add any noticeable slow-down provided your hardware is decent and you're
operating the forwarding plane within the limits supported by the vendor.
Yes, I know this can quickly become a cost run-away problem, but for
better or worse, that is what separates the wheat from the other thing...
The point is you need a transition tech. solution if you are serious
about providing a service to your customers. Assuming you don't is
living in denial.
Mark.
Actually, the point is that if you're a content provider, there's a good
chance that turning up IPv6 will result in happier eyeballs, which can
probably be leveraged into a competitive advantage. And the more content
providers do that, the smaller your transition problem becomes.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256