[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: there _is_ IPv6 NAT - just look for it (was: A Plea for Architectural & Specification Stability 
From:       Alexandru Petrescu <alexandru.petrescu () gmail ! com>
Date:       2014-03-14 21:29:49
Message-ID: 532374CD.3040100 () gmail ! com
[Download RAW message or body]

Le 13/03/2014 15:27, Lorenzo Colitti a =E9crit :
[...]
> 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.

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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]