IPv6 foot-dragging

George Bonser gbonser at seven.com
Wed May 11 18:39:00 UTC 2011


> So what's the alternative? Never change anything?

Of course not.  But the best course forward is going to be different for
different folks.  What might work best for me might not (probably WILL
not) work best for everyone else.  One has to look at their situation
and plan the best path for their business with their architecture and
the resources they have available to them.  I suggested one option but
that might not work for others.  Others might see a strict white
listing, or maybe some combination of the two.  But there is so much
brokenness out there right now that I would hesitate to trust an AAAA
request that arrives over v4 when there is a v6 name server available.

> 
> Remember, this is al extremely trivial stuff: most things won't even
> completely stop working. And a few mouseclicks (yes, you have to know
> which ones so the helpdesks better start figuring that out) and you're
> back to normal. Compare this to turning off analog TV transmitters
that
> have been running for decades where people have to buy converter boxes
> and sometimes even install antennas on their roof to keep using the
> service.

It depends.  There are other things to take into account.  If you
increase the time it takes a mobile device to complete a transaction by
only a couple of seconds,  if you multiply those couple of seconds by
all of the users in a large metro area, you end up with devices
increased use of network resources (and increased battery drain on the
devices themselves).  Anything that can be done to speed transactions up
and get those transmitters shut off as quickly as possible is a win.  If
you don't have a lot of mobile clients hitting your site, then maybe
that isn't a problem.  Every network has their own set of resources and
their own set of challenges and all of that has to fit within the
network architecture they have deployed and their business model.

Basically, there is no "magic bullet".





More information about the NANOG mailing list