Re: there _is_ IPv6 NAT - just look for it

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

On 16/03/2014 07:54, Alexandru Petrescu wrote:
> Le 15/03/2014 08:31, Brian E Carpenter a écrit :
>> 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.
> 
> Hi Brian,
> 
> I agree with this in a sense: IPv6 address space is huge and hence the
> IPv4 NAT is unnecessary.  IPv6 being embraced in more and more places is
> a witness of this success.  It solves the IPv4 depletion problem in a
> more Internet way than the architecturally e2e impossible way of NAT IPv4.
> 
> But, until cellular and some DSL operators provide something shorter
> than a single /64 to a single SIM end user, 

Yes, that is a shocking error in the 3GPP world, but that doesn't
mean that the IETF should legitimise it.

    Brian

> or alternatively the
> SLAAC/WiFi changes its EUI-64/64 IID stance, the IPv6 NAT is a viable
> solution.
> 
> I consider it seriously when connecting any mobile network to the
> Internet - like a multi-subnet LAN of a cheap vehicle, or a WPAN, or a
> fixed sensor network, or a fixed hotspot in a remote area.
> 
> Alex
> 
>>
>> 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
>>> --------------------------------------------------------------------
>>>
>>
>>>
>>
>>
> 
> 
>