Production-scale NAT64

Mailman List Mirror (Read Only)
21

> 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.

But you only need to hit the NAT64 gateway "if" you are IPv6-only.

  Sure...

  For DS, I could send IPv6 native and IPv4 via NAT. I suspect this
actually the most common home setup at this point. It's certainly the
way mine looks.

  I have noticed that IPv4 "feels" slow on my t-mobile usa connected
devices. This is only a problem when interacting with legacy players on the
network, eg: financials, opensrs, airlines. I suspect this is a 64 CGN tax.

  Waiting to see my other devices/sims see IPv6 on them via VZ and AT&T.

If you're dual-stacked, your route to an A record will not hit the NAT64
gateway.

  Sure, but your v4 is likely to have issues regardless and face this
penalty/tax.

  - Jared

22

  Sure...

  For DS, I could send IPv6 native and IPv4 via NAT. I suspect this
actually the most common home setup at this point. It's certainly the
way mine looks.

  I have noticed that IPv4 "feels" slow on my t-mobile usa connected
devices. This is only a problem when interacting with legacy players on the
network, eg: financials, opensrs, airlines. I suspect this is a 64 CGN tax.

  Waiting to see my other devices/sims see IPv6 on them via VZ and AT&T.

If your IPv4 is public, you should not "feel slow". Of course, if your
IPv4 is private, then yes, some NAT44 may happen somewhere along the path.

  Sure, but your v4 is likely to have issues regardless and face this
penalty/tax.

But that would be a function of NAT44 if you're on private IPv4, and
have nothing to do with the NAT64.

In our deployment, we do not offer customers private IPv4 addresses. I
suppose we can afford to do this because a) we still have lots of public
IPv4, b) we are not a mobile carrier. So any of our customers with IPv4
will never hit the NAT64 gateway.

When we do run out of public IPv4 addresses (and cannot get anymore from
AFRINIC), all new customers will be assigned IPv6 addresses. These will
hit a NAT64 gateway if they want to talk to legacy resources on the
Internet.

Mark.

23

Hi Mark,

* Mark Tinka <mark.tinka@seacom.mu>

In our deployment, we do not offer customers private IPv4 addresses. I
suppose we can afford to do this because a) we still have lots of
public IPv4, b) we are not a mobile carrier. So any of our customers
with IPv4 will never hit the NAT64 gateway.

When we do run out of public IPv4 addresses (and cannot get anymore
from AFRINIC), all new customers will be assigned IPv6 addresses.

Why wait until then?

Any particular reason why you cannot already today provide IPv6
addresses to your [new] customers in parallel with IPv4?

Tore

24

Why wait until then?

I didn't say that we're waiting :-)...

Any particular reason why you cannot already today provide IPv6
addresses to your [new] customers in parallel with IPv4?

As a standard delivery of service, all our customers (BGP- and
non-BGP-based) are assigned IPv6 addresses by default. Point-to-point
for the BGP-based customers, and point-to-point + onward LAN assignments
for the non-BGP-based customers.

We do (and configure) this regardless of whether customers have asked
for it or not. In reality, 70% of the time it's like pulling teeth
getting customers to configure their end of the IPv6 point-to-point
address, much less turn-up an IPv6 BGP session. Reasons range from, "We
do not have a /32 IPv6 allocation yet", "Our router does not support
IPv6 yet", "We shall get to it in time, we are busy with other things
now", "It is not important to us", "We only have one interface in our
whole network with IPv6, so let's forget about it for now", "What is
IPv6? Oh, that - no thanks", and so on and so on.

30% of the time, however, we are dealing with a switched-on customer
that is happy to turn it up, and would even chase us for the same. We
like these types of customers.

You won't find a customer order or port in our network that does not
have IPv6 enabled. It's just all about getting their side sorted out.
And the team have been going out of their way to help them turn-up,
e.g., recommending the minimum software they should upgrade to to
support IPv6, helping them reach out to AFRINIC to apply for their /32
IPv6 allocation, helping them set things up on their end, nagging them
weekly on when they will get their side up, e.t.c. It's never-ending work.

Same things goes for peering - we always ask peers to turn-up both IPv4
and IPv6 at the same time. For the majority of peers, once the IPv4
session is up, they disappear. But we keep nagging, and nagging and
nagging, and many times we are successful in getting IPv6 going.
Sometimes, however, it's all falling on deaf ears. But it is good work,
so we do not let up.

All I was saying before is that when we can no longer hand out public
IPv4 addresses to new customers in the future, those customers will
require the NAT64 gateway to speak to IPv4-only resources. Hopefully, by
the time that happens, the demand on the NAT64 gateways is as close to
0% as possible.

Mark.

25

Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T
all of which are better solutions than NAT64. NAT64 + DNS64 which
breaks DNSSEC.

26

Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after the
dust settles.

There is value in that.

Mark.

27

* Mark Tinka <mark.tinka@seacom.mu>

>
> Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T
> all of which are better solutions than NAT64. NAT64 + DNS64 which
> breaks DNSSEC.

Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after the
dust settles.

Hi Mark,

There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in
this respect, the way I see it. In all cases you need four things:

0) Native IPv6.
1) A central component connected to the IPv4 internet and the IPv6.
   access network (464XLAT: "PLAT", MAP-*: "BR", DS-Lite/lw4o6: "AFTR")
2) Signalling to client that #1 exists and can be used (464XLAT: DNS64,
   others: DHCPv6 options).
3) A distributed component at the customer premise/nodes that acts on
   #2 and connects an isolated IPv4 network to the IPv6 access network
   (464XLAT: "CLAT", MAP-*: "CE", DS-Lite/lw4o6: "B4").

The necessary "undo work" in all cases is to disable #2. At that point
components #1 and #3 will become un-used and can be removed if you
care. My guess is that you'll care about removing #1 because it
probably uses power and space in your PoP, but that you won't care
about #3 because that's just an unused software function residing in a
customer device you might not even have management access to.

I'll grant you that with NAT64/DNS64 *without* 464XLAT there is no #3
to remove as part of your "undo work", but as I mentioned above I doubt
you'll care about that particular distinction. Besides, since a CLAT is
included by default in multiple client platforms, you can't really
prevent your users from using 464XLAT if you're providing NAT64/DNS64
to begin with, unless you're doing something really weird like
disabling DNS64 for the "ipv4only.arpa." hostname specifically.

Tore

28

Agree that with 464XLAT, the situation is not that different.

The issue with 464XLAT for a service provider such as ourselves is that
the majority of our customer's CPE and terminal equipment does not have
464XLAT support. You are mostly seeing 464XLAT support in mobile phones,
and on specific mobile OS's (iOS does not support 464XLAT today, for
example - unless this has changed or is changing).

In that situation, our particular use-case could use more DNS64 for the
signaling than 464XLAT or equivalent.

You can't have it all - each network will have to choose the least of
the various evils that can apply to it.

Mark.

29

The question I have not seen the answer yet to is “why?”

Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps?

Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance?

Is it about middle nodes?

Has anyone done the research on this?

30

The life of an IPv4 packet on the Internet is very likely to undergo
some NAT at some point in its travels.

I haven't yet heard of many doing NAT66, hence IPv6 not undergoing NAT
means any slow-downs caused by NAT44 are missed (gladly) on IPv6.

This might not necessarily be immediately visible on regular networks,
but the large content players could count this quite easily due to the
significant volumes of traffic their networks are having to aggregate
and process.

Mark.

31

I too do not know, and i do not care.

Looking in the rear view mirror at why NAT encumbered IPv4 sucks is not a
priority of mine, but may be an interesting pedantic project for internet
historians. We know that NAT causes very minor latency (session setup and
matching per packet) and very minor loss (state management chaos), but i
can hardly believe that is a 20-40% speedup. Then again, TCP is a sensitive
thing.

Either way, Twitter and Amazon seem a tad slow... perhaps they should
enable IPv6. Or maybe they have plenty of IPv4 and don't care much about
the 20-40% performance gain that Facebook has seen.

CB

32

I strongly advise you to not assume that just because an IPv4 address is "public" (which I'm reading as RFC1918) means that it's not NATed.

I learned the hard way that Tmobile, for one, squats on other organization's public IP space on their mobile network and NATs it to address space they are actually assigned. What you really mean is if your IPv4 is not NATed, then it should not "feel slow", the type of address isn't necessarily an indicator.

33

If we're being pedantic, yes.

Mark.

34

in my experience, differences in latency between ipv4 and ipv6 are
mostly due to non-congruent peering/transit. sometimes, one or the
other has to actually go farther.

randy