[162264] in North American Network Operators' Group
Re: Verizon DSL moving to CGN
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Apr 8 01:43:53 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAD_uLpOfu4xVWzLz=aY1FszYR+bH7QNEhXvE-Tsg-yD2V79yHg@mail.gmail.com>
Date: Sun, 7 Apr 2013 22:36:01 -0700
To: Oliver Garraux <oliver@g.garraux.net>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Apr 7, 2013, at 15:43 , Oliver Garraux <oliver@g.garraux.net> wrote:
> If I'm an ISP deploying a network for users today, I effectively have =
to provide some mechanism to allow those users to get to IPv4 only =
content. There is way too much stuff out there that is IPv4 only today.
>=20
Agreed... However...
> Yes, content providers should provide IPv6 access....but if I'm an =
ISP, I can't really control that aspect. If I provide users with a =
service that isn't able to connect to 80% of websites (to say nothing of =
VPN's, corporate email services, etc, that people may need), I'm not =
going to have a whole lot of business.
>=20
I was responding to Mikael's claim that pushing content providers to =
deploy IPv6 was orthogonal to the need for CGN.
Clearly your statement here indicates that you see my point that it is =
NOT orthogonal, but, in fact the failure of content providers to deploy =
IPv6 _IS_ the driving cause for CGN.
> Now - I completely agree that ISP's must start deploying IPv6 =
natively. Legacy equipment that doesn't support IPv6 is not an =
acceptable excuse....its just evidence of poor decision making and =
short-sighed purchasing decisions. CGN clearly isn't ideal and doesn't =
mitigate the need for native IPv6 connectivity. But right now, native =
IPv6 connectivity is still not a substitute for some level of IPv4 =
connectivity, even if its CGN'ed.
I don't disagree. You are actually making the exact point I was =
attempting to make. The need for CGN is not divorced from the failure to =
deploy IPv6, it is caused by it.
Owen
>=20
> Oliver
>=20
> -------------------------------------
>=20
> Oliver Garraux
> Check out my blog: blog.garraux.net
> Follow me on Twitter: twitter.com/olivergarraux
>=20
>=20
> On Sun, Apr 7, 2013 at 4:06 PM, Owen DeLong <owen@delong.com> wrote:
>=20
> On Apr 7, 2013, at 00:31 , Mikael Abrahamsson <swmike@swm.pp.se> =
wrote:
>=20
> > 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).
> >
>=20
> True... But... Resources deploying/maintaining all of these keep =
IPv4-limping along technologies are resources taken away from IPv6 =
deployment.
>=20
> > 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.
> >
>=20
> Not really...
>=20
> > 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.
> >
>=20
> 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.
>=20
> > I'm ok with people complaining about lack of IPv6 deployment, but I =
don't understand people complaining about CGN. What's the alternative?
>=20
> IPv6 deployment _IS_ the alternative. They are not orthogonal.
>=20
> Owen
>=20
>=20
>=20
