Re: there _is_ IPv6 NAT - just look for it

[Brian E Carpenter <[e-mail]>]

On 15/03/2014 10:29, Alexandru Petrescu wrote:
> Le 13/03/2014 15:27, Lorenzo Colitti a écrit :
> [...]
>> It's true that those that want IPv6 to be exactly like IPv4 are
>> disappointed, because IPv6 is not IPv4. No, you can't do routing without
>> RAs. No, you can't "save addresses" by making host subnets /120s (at
>> least not easily). No, there is no RFC1918. No, ULAs are not the same as
>> RFC1918. No, there is no NAT.
> 
> Yes there is IPv6 NAT an dit works just like in IPv4.

We can't make it illegal, but we have already made it unnecessary.

  Brian

> 
> Alex
> 
> 
>  But I think that in a lot of scenarios
>> those are advantages, not disadvantages.
>>
>> When people say that IPv6 can't be deployed in ISPs, in enterprise
>> networks, in content providers, in home networks, or in mobile networks
>> because it lacks feature X, we'd do well to remember that there are
>> large deployments of IPv6 in all these areas. I know, because I've
>> personally been involved in all of the above. In my experience, excuses
>> for not deploying IPv6 are, to a great extent, just that: excuses. They
>> have no relationship to the actual reason for not deploying it, which
>> is, and has always been, "we see no benefit" (or, to a lesser extent,
>> "our code doesn't support it", and "our code has bugs" -- both of which
>> are temporary). These excuses mislead the IETF into thinking that the
>> lack of IPv6 deployment means that there is somehow something wrong with
>> the protocol. This in turn causes hand-wringing and standards-writing,
>> but in my experience, that doesn't help: when we remove an excuse,
>> people move on to another excuse -- because the excuse wasn't the real
>> reason anyway.
>>
>> Continued tinkering with IPv6 - especially tinkering with it to make it
>> look more and more like IPv4 in order to reduce imagined "barriers to
>> adoption" - will just erode IPv6's long-term advantages by eliminating
>> the simplification, robustness, and benefits that IPv6 as it is today
>> *does* provide -- and it won't lead to adoption anyway, because lack of
>> adoption is not a technical issue.
>>
>> What we need to do now is stick to the protocols as designed and wait
>> until the combination of ever-increasing pain caused by IPv4 exhaustion,
>> and exponentially-increasing IPv6 deployment in the Internet at large
>> (or at least in the consumer space), change the "there's no benefit"
>> equation. That *does* have the power to cause deployment in a way which
>> changing the standards will never have -- and as you put it, the more we
>> change now, the more we *delay* deployment, by causing vendors to write
>> code that then needs to be waited for, tested, and debugged before
>> operators can deploy.
>>
>> Personally, I think 6man has the duty to ensure that no radical changes
>> go into the core protocols until *real deployment experience* -- not of
>> the "I can't deploy because..." kind, but only of the "I deployed *and
>> it didn't work because...*" kind -- shows that there is really a gap in
>> functionality, and even then, to think extremely carefully whether the
>> long-term effects will be beneficial or not. We're hoping that this IPv6
>> thing is going to last us for the next 30 years. Let's not get too hung
>> up on the next 3.
>>
>>
>> Cheers,
>> Lorenzo
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>