Yahoo and IPv6

Tue May 10 02:04:42 UTC 2011

On Mon, May 9, 2011 at 3:57 PM, Jeff Wheeler <jsw at inconcepts.biz> wrote:

I do take issue with your suggestion that /64 LANs are in any way
> smart in the datacenter.  They are not.  I have some slides on this
> topic: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf

There are ways of mitigating this (the easiest is to use ACLs or firewalls
to limit traffic into a subnet from untrusted sources so that only
legitimate traffic is allowed).

As for IPv6 in general, for other posters, I have a lot more concern about
things like missing routes in routing tables, lack of residential IPv6 (one
place where it would be *very* useful - think VoIP, P2P, etc), and lack of
any good tunnel broker options.

I've also had plenty of trouble getting IPv6 in data centers (4 different
providers of caged data center space, none of which provided it, including
one Tier 1 who advertised that all their business customers got free IPv6
with IPv4 transit from them; I guess they didn't think someone renting caged
space and redundant ethernet in one of their data centers was a business
customer, but I digress...)

I'd settle for a good tunnel at this point.

What do I mean by good tunnel option?  The following:

1) Provider treats it like production, not as a tool for business leverage
or a service only used for "testing"

2) Provider that has full routing table.  A provider couldn't stay in
business in the IPv4 world if they lacked connectivity to one or more
default free networks.  Yet in IPv6, it's the norm.

3) Provider that provides support for it - first through top level

4) Provider has redundancy at all levels

5) Provider makes it quick and simple to sign up, with rates posted on their
website based on bandwidth desired (for residential and small business
customers).  I don't want to talk to a sales guy if I'm just setting up a
tunnel for a DSL site!

6) Provider has an access location somewhere within, say, 1000 miles of my
location.  Ideally at a major exchange point in the metro.

7) Provider's network doesn't route me through Tokyo or Frankfurt to get
from Denver to Chicago - regardless of who's network in Chicago I'm trying
to connect to.

This doesn't exist - it's wishful thinking.  So this leaves native
connectivity.  Of course native connectivity is problematic, as it doesn't
always come with full routing tables, isn't necessarily available on the
circuit you have, and doesn't really give you all that much.  That's
assuming you can find it at all.  After all, it's only been around for most
of the time of the web.