CGN and CDN (was Re: what about the users re: NAT444 or ?)
a.harrowell at gmail.com
Fri Sep 9 16:06:37 UTC 2011
On Friday 09 Sep 2011 16:25:35 Valdis.Kletnieks at vt.edu wrote:
> On Fri, 09 Sep 2011 11:09:38 EDT, Jean-
Francois.TremblayING at videotron.com said:
> > A very interesting point. In order to save precious CGN resources,
> > it would not be surprising to see some ISPs asking CDNs to provide
> > a private/non-routed behind-CGN leg for local CDN nodes.
The actual problem here is that everyone assumes it'll be donkey's years
before every last web server in the world is on IPv6.
If you're a CDN, though, you can solve this problem for your own network
right now by deploying IPv6! Akamai says that you need 650 AS to cover
90% of Internet traffic. I propose that effort getting content networks
to go dual stack is better used than effort used to work around NAT444.
Further, if making your hosting network IPv6 is hard, the answer is
surely to give the job to a CDN operator with v6 clue. I actually rather
think CDNs are an important way of getting content onto the IPv6
In my view CDNing (and its sister, application acceleration) is so
important to delivering the heavy video and complex web apps that
dominate the modern Internet that this should be a killer.
Still, breaking the BBC, Hulu, Level(3), Akamai, Limelight, and Google's
video services will probably reduce your transit and backhaul bills
significantly. Can't say it'll help with customer retention.
> > For this to work, the CGN users would probably have a different
> > set of DNS servers (arguably also with a private/non-routed
> > leg) or some other way to differentiate these CGN clients. Lots
> > of fun in the future debugging that.
> Especially once you have 10 or 15 CDNs doing this, all of which have
> rules of engagement. "Akamai requires us to do X, Hulu wants Y, Foobar
> and specifically NOT-X..." ;)
> And then Cogent will get into another peering spat and.... :)
The only thing worse than e-mail disclaimers...is people who send e-mail
to lists complaining about them
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the NANOG