Re: there _is_ IPv6 NAT - just look for it

[Alexandru Petrescu <[e-mail]>]

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, 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
>> --------------------------------------------------------------------
>>
>
>>
>
>