Problems with removing NAT from a network
matthew at matthew.at
Mon Jan 10 13:18:29 CST 2011
On 1/9/2011 9:51 PM, Owen DeLong wrote:
> 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.
Well yes, at the very least it'll be NAT444 because people won't throw
their home boxes out just because their carrier can now give them more
synthetic IPv4 space.
> 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.
Maybe. It really depends on where you have nodes that can provide useful
information about the topology. But yes, it gets uglier and uglier,
eventually to the point of not working in some cases.
But NAT64 is NAT too *and* makes the (incorrect) assumption that there's
no good reason to pass IPv4 addresses around except in DNS.
>> 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".
Should we make a short list of countries and coffee shops and go test it
out in two years?
>>> 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.
This is probably a correct assessment. All NAT64 will fail unless
there's discovery *and* the NAT64 behaves in a useful way, some CGN
environments will fail and more so as both ends end up on different
CGNs, and things like DS-Lite will do fairly well. At least that's how
it looks to me, based on analysis I did for a different peer-to-peer
protocol and these cases.
> Nor will anything else and broken IPv4 access is an apt term to describe
> any of:
True. Though you get to choose in what way it is broken in each.
> 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?
So which technology are you choosing? :)
More information about the NANOG