On Apr 7, 2013, at 00:31 , Mikael Abrahamsson <swm...@swm.pp.se> wrote:
> On Sun, 7 Apr 2013, Fabien Delmotte wrote: > >> CGN is just a solution to save time, it is not a transition mechanism >> through IPv6 >> At the end (IPv6 at home) you will need at list : >> Dual stack or NAT64/ DNS64 > > CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the > water without other mechanisms (464XLAT or alike). > True... But... Resources deploying/maintaining all of these keep IPv4-limping along technologies are resources taken away from IPv6 deployment. > My point is that people seem to scoff at CGN. There is nothing stopping > anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address > exhaustion), then giving dual stack for end users can be done at any time. > Not really... > Face it, we're running out of IPv4 addresses. For basic Internet > subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a > completely different problem that has little bearing on CGN or not for IPv4. > DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also > CGN. > No, it really isn't. Sufficient IPv6 deployment at the content side would actually allow the subscriber side to be IPv4 or dual-stack for existing customers with new customers receiving IPv6-only. The missing piece there is actually the set-top coversion unit for IPv4-only devices. (Ideally, a dongle which can be plugged into the back of an IPv4-only device with an IPv6-only jack on the other side. Power could be done a number of ways, including POE (with optional injector), USB, or other. > I'm ok with people complaining about lack of IPv6 deployment, but I don't > understand people complaining about CGN. What's the alternative? IPv6 deployment _IS_ the alternative. They are not orthogonal. Owen
