Problems with removing NAT from a network

Mon Jan 10 05:51:56 UTC 2011

On Jan 8, 2011, at 10:46 PM, Matthew Kaufman wrote:

> On 1/8/2011 3:16 AM, Leen Besselink wrote:
>> 
>> Hello Mr. Kaufman,
>> 
>> In the upcoming years, we will have no IPv6 in some places and badly
>> performing IPv4 (CGN, etc.) with working IPv6 in others.
> Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers".
> 
> I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet".
> 
NAT44 perhaps, but, the problem is that most CGNs proposed aren't NAT44, they're at best NAT444 and likely more like NAT44444 or worse in the real world.

Today, we have NAT44->Internet<-NAT44 in many sessions (Skype, VOIP, etc.) which connect to each other via STUN, UPnP, etc.

Once you move from NAT44 to NAT444, most of the working traversal mechanisms break in interesting ways and at NAT44444, virtually nothing peer-to-peer-ish gets through at all as you simply can't abstract UPnP or anything else through that many layers at either end.

With CGN, the details look more like:

NAT44->ISP->NAT44->Internet<-NAT44<-ISP<-NAT44
Giving us NAT44444.

> Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above)
> 
I think this "*very* long time" will be much shorter than you think for meaningful values of "whole lot of places".

>> If I was Skype I would make really sure that all my relay nodes and
>> login servers have IPv6 with enough bandwidth or can easily upgrade the
>> bandwidth where neede. And make sure atleast IPv6-client and
>> IPv6-servers communication works everywhere where there is IPv6.
> Clearly that would be needed to serve the IPv6-only users well.

I think this is definitely the ideal first step, but, I confess I don't know the inner workings of Skype. Even this is probably
a large effort in their codebase, so, I hope they've started working on it.
>> 
>> For your customers it is really easy. When Skype does not work, people
>> will jump ship where they can and maybe use Google Talk or whatever.
> Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around.

I'm betting Skype breaks just as bad in many CGN environments and that
the most likely candidate to actually work will be B4/AFTR or DS-Lite.

However, there are different problems that come up there as well.

>> I suggest making sure you include both IPv4 and IPv6 addresses in your
>> protocol, maybe it needs to be extended. So that the client at the other
>> end can choose what IP-version to use. Or can try both. Maybe the
>> login-server can help to decide for the client. But those login servers
>> will need to have good IPv6 connectivity to be able to do so.
> But none of that solves the problem of talking from an IPv6 client that has broken IPv4 access (NAT64) to a an IPv4 client that has no IPv6 access.
> 
Nor will anything else and broken IPv4 access is an apt term to describe
any of:
	NAT64
	DS-LITE/B4/AFTR
	CGN/LSN

They each have their own brand of broken IPv4. Let's face it, while the
existing IPv4 internet isn't going to suddenly break when we run out of
available addresses, it is going to slowly suffer from increased breakage
as we attempt to recycle those addresses in ever more creative and
unintended ways.

>> I'm sorry if it sounds a bit like fear mongering, but to me it sounds
>> like common sense that if a business is not prepared when the
>> environment that business operates in changes and that business does not
>> adapt to the changes in time that business might suffer.
> But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it?
> 
Yep.

Owen