[ipv6-wg] Implications of NAT/NAT64 and similar

Transition mechanisms have the attribute of being transitional by definition. So they bridge gaps.  That is exactly what NAT was originally designed for - bridge a gap until real solution is at hand.
We have waited far too long with deploying IPv6, and now we have to live with the fact that IPv4 ran out.
We are all paying the price and many have been predicting just that - but there weren't many that listened

So let's hope we learned from the NAT issue
We live in a free world and the Internet is VERY diverse. What is good for the ones is bad for others.
If T-Mobile feels XLAT and NAT64 solves an issue, they and their customers must live with it. They can have an IPv6-only backbone and they can assign IPv6-only at the edge. Not bad. Maybe that helps the market to migrate the IPv4-legacy apps and design apps optimized for IPv6?   :-)
I do not believe in IETF or whoever else dictating the market how to do it.
I think we should offer different transitional solutions solving different issues and let the actors in the market decide, what combination works best for them.

My two cents
Silvia


-----Ursprüngliche Nachricht-----
Von: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] Im Auftrag von Benedikt Stockebrand
Gesendet: Sonntag, 17. Mai 2015 18:49
An: ipv6-wg at ripe.net IPv6
Betreff: Re: [ipv6-wg] Implications of NAT/NAT64 and similar

Hi Silvia and list,

Silvia Hagen <silvia.hagen at sunny.ch> writes:

> Hi Benedikt
>
> But in combination with 464XLAT it seems to do the job well enough to 
> support millions of IPv6-only users for T-Mobile. And thereby allows 
> them to deploy v6-only at the edge, where address consumption is 
> highest.
>
> So maybe it would be good to differentiate a bit more and not throw 
> out the baby with the bathwater.

fair enough, but even then 464XLAT is a transition technology which following your reasoning causes a long term problem that software developers can't rely on end-to-end connectivity even with IPv6.  In other words, while it helps in the short term, we'll pay dearly for it in the long run.

Yes, of course you are right that this is a complex issue, but there's a widespread tendency to carry the old limitations of today's IPv4 to IPv6 even if there's no real need to do so.  And Marc calling NAT64 a working solution despite the fact that it breaks IPv6 the same way NAT broke
IPv4 really asks to be balanced by a similarly oversimplified statement going the other way:-)

So the real question is: How do we deal with exactly that risk, i.e. that some transition technologies burden the IPv6 world with otherwise unnecessary legacy issues?


Cheers,

    Benedikt

-- 
Benedikt Stockebrand,                   Stepladder IT Training+Consulting
Dipl.-Inform.                           http://www.stepladder-it.com/

          Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/