[140338] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Yahoo and IPv6

daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Tue May 10 06:05:16 2011

From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <120501cc0e81$0222b1e0$066815a0$@net>
Date: Tue, 10 May 2011 12:03:44 +0200
To: Tony Hain <alh-ietf@tndh.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On 9 mei 2011, at 21:40, Tony Hain wrote:

>> Publicly held corporations are responsible to their shareholders to =
get
>> eyeballs on their content. *That* is their job, not promoting cool =
new
>> network tech. When you have millions of users hitting your site every
>> day losing 1/2000 is a large chunk of revenue.

Nonsense. 0.05% is well below the noise margin for anything that =
involves humans.

>> The fact that the big
>> players are doing world IPv6 day at all should be celebrated, =
promoted,
>> and we should all be ready to take to heart the lessons learned from
>> it.

I applaud the first step, but I'm bothered by the fact that no second =
step is planned.

>> The content providers are not to be blamed for the giant mess that =
IPv6
>> deployment has become. If 6to4 and Teredo had never happened, in all
>> likelihood we wouldn't be in this situation today.

> The entire point of those technologies you are complaining about was =
to
> break the stalemate between content and network, because both sides =
will
> always wait and blame the other.

You're both somewhat right: there's nothing wrong with having 6to4 and =
Teredo available as an option for people who want/need easy IPv6, which =
is too hard to get otherwise for most people. The big mistake was to =
enable it by default. That ALWAYS ends badly. (See for instance HTTP =
pipelining, good idea but it got tainted by buggy implementations on the =
client side that made it impossible to enable on the server side.)

> The fact that the content side chose to
> wait until the last possible minute to start is where the approach =
falls
> down. Expecting magic to cover for lack of proactive effort 5-10 years =
ago
> is asking a bit much, even for the content mafia.=20

The content people don't feel the address crunch and they have no =
incremental deployment: either you AAAA or you don't AAAA. The opposite =
is true for the eyeball people, so they are the ones that will have to =
get this ball rolling.

> In any case, the content side can mitigate all of the latency related =
issues
> they complain about in 6to4 by putting in a local 6to4 router and =
publishing
> the corresponding 2002:: prefix based address in DNS for their =
content.

That wouldn't help people behind firewalls that block protocol 41 (which =
is way too common) and it's harmful to those with non-6to4 connectivity =
but no (good) RFC 3484 support so they connect to those 2002:: =
addresses. (I'm looking at you, MacOS. Try for yourself here: =
http://6to4test3.runningipv6.net/ )

> We are about the witness the most expensive, complex, blame-fest of a
> transition that one could have imagined 10 years ago. This is simply =
due to
> the lack of up-front effort that both sides have demonstrated in =
getting to
> this point. Now that time has expired, all that is left to do is sit =
back
> and watch the fireworks.

I love fireworks.

I don't think it'll be all that bad, though. Pretty much all the pieces =
are in place now, it's mostly a question of simply enabling IPv6. Yes, =
people will whine but how else would we know the NANOG list is still =
working between operational issues?=


home help back first fref pref prev next nref lref last post