Yahoo and IPv6

Tue May 10 14:08:08 UTC 2011

Igor Gashinsky wrote:
> :: >> 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. They
> :: >> choose to hold their breath and turn blue, blaming the network
> for the lack
> :: >> of 5-9's access to the eyeballs when they hold at least part of a
> solution
> :: >> in their own hands.
> :: >
> :: > Looking at that from the content provider side for a second, what
> is their motivation for doing it? The IETF created 6to4, and some
> foolish OS and/or hardware vendors enabled it by default. So you're
> saying that it's up to the content providers to spend money to fix a
> problem they didn't create, when the easy/free solution is simply not
> to turn on IPv6 at all? I completely fail to see an incentive for the
> content providers to do this, but maybe I'm missing something.
> :: >
> 
> So, just for the record, I am not speaking for my employer, and am
> speaking strictly for myself here, and I'm going to try to keep this my
> one and only message about finger-pointing :)
> 
> The time for finger-pointing is over, period, all we are all trying to
> do
> now is figure out how to deal with the present (sucky) situation. The
> current reality is that for a non-insignificant percentage of users
> when
> you enable dual-stack, they are gong to drop off the face of the
> planet.
> Now, for *you*, 0.026% may be insignificant (and, standalone, that
> number
> is insignificant), but for a global content provider that has ~700M
> users,
> that's 182 *thousand* users that *you*, *through your actions* just
> took
> out.. 182,000 - that is *not* insignificant
> 
> *That* is what world ipv6 day is about to me -- getting enough
> attention
> at the problem so that all of us can try to move the needle in the
> right
> direction. If enough users realize that they are broken, and end up
> "fixing themselves", then it will be a resounding success. And, yes, to
> me, disabling broken ipv6 *is* "fixing themselves". If they turn broken
> ipv6 into working ipv6, even better, I just hope all the access
> networks
> staffed up their helpdesk to deal with the call volumes..
> 
> And, if the breakage stats remain bad, well, that's what DNS
> "whitelists/blacklists" are going to be for..
> 
> :: While we're not directly a content provider, we do host several of
> them and we do
> :: run the largest network of 6to4 relays that I am aware of. In our
> experience at HE,
> :: this has dramatically improved the IPv6 experience for our clients.
> As such, I would
> :: think that providing a better user experience should serve as
> reasonable motivation
> :: for any rational content provider. It's not like running 6to4 relays
> is difficult or
> :: expensive.
> 
> No, running *return* 6to4 relays is not difficult at all, in fact, some
> content providers have a ton of them up right now. The problem is that
> content providers can't control the forward relays, 

So take the relays out of the path by putting up a 6to4 router and a 2002::
prefix address on the content servers. Longest match will cause 6to4
connected systems to prefer that prefix while native connected systems will
prefer the current prefix. The resulting IPv4 path will be exactly what it
is today door-to-door. Forcing traffic through a third party by holding to a
purity principle for dns, and then complaining about the results is not
exactly the most productive thing one could do.

> or protocol 41
> filtering that's out in the wild. 

Putting 2002:: in dns will not fix this, but it is not clear to me where
this comes from. The argument is that enterprise firewalls are blocking it,
but that makes no sense because many/most enterprises are in 1918 space so
6to4 will not be attempted to begin with, and for those that have public
space internally the oft-cited systems that are domain members will have
6to4 off by default. To get them to turn it on would require the IT staff to
explicitly enable it for the end systems but then turn around and block it
at the firewall ... Not exactly a likely scenario.

The most likely source of public space for non-domain joined systems would
be universities, but no one that is complaining about protocol 41 filtering
has shown that the source addresses are coming from those easily
identifiable places. 

That leaves the case of networks that use public addresses internally, but
nat those at the border. This would confuse the client into thinking 6to4
should be viable, only to have protocol 41 blocked by the nat. These
networks do exist, and the only way to detect them would be to have an
instrumented 6to4 router or relay that compared the IPv4-bits in the source
address between the two headers. They don't have to match exactly because a
6to4 router would use its address as a source, but if the embedded bits said
25.25.25.25 while the external IPv4 header said 18.25.25.25 one might
suspect there was a nat in the path.

> Also, not all breakage is caused by
> 6to4, there are still quite a few cases of other breakage, and *that*
> is
> what's pushing us towards whitelisting.
> 
> See:
> http://www.getipv6.info/index.php/Customer_problems_that_could_occur
> 
> :: > And can we please stop pretending that this is an easy thing for
> the content providers to do? Big content networks like Yahoo! have
> dozens of POPs, and hundreds of address ranges. The IETF is *still*
> working on tweaking 6to4, so even if the content providers put up these
> relays today, and somehow figure out how to test them, their work is
> not done.

Then stop focusing on the relays, as they are only necessary to get between
the 6to4 prefix and the non-6to4 prefix address ranges. They are explicitly
not in the path of any 6to4 -> 6to4 conversation.

In any case the relays should not be the responsibility of the content side,
they are rightly the responsibility of the access networks who wouldn't need
to deploy them if they had native access in place. The 6rd hack is nothing
more than 6to4 in a different prefix to get around the one-liner that should
be ignored in the original RFC that said to only publish the /16 into IPv6
bgp. I can already hear the screams about routing table, but there is no
difference between the impact of a 6rd specific announcement and a
deaggregate of 2002::  

> :: >
> :: It is relatively easy to do, even with dozens of POPs. There isn't
> anything special you
> :: have to do for the hundreds of address ranges, really, so I don't
> buy that as being a
> :: meaningful part of the argument.
> 
> I think this is a red herring - return relays were never *the* problem.
> 
> :: > I do agree with you that pointing fingers at this stage is really
> not helpful. I continue to maintain that being supportive of those
> content networks that are willing to wade in is the right answer.
> :: >
> :: Agreed, but, it's also important to point out when they're starting
> to swim in directions
> :: that are counterproductive, such as having help sites that advise
> users to turn off
> :: IPv6 with fixing their IPv6 capabilities as a secondary option.
> 
> "We recommend disabling IPv6 or seeking assistance in order to fix your
> system's IPv6 configuration through your ISP or computer manufacturer"

It would be most helpful to rearrange that statement to take the focus off
of 'disabling'. When the first thing people see is turn it off they will do
that rather than get to the point that there might be something that is
fixable.

> 
> So, your problem is that a help page gives the user 2 options,
> the first one of them being a quick and easy fix that a user can do
> himself in less then a minute, and suggesting contacting the ISP or
> manufacturer *second* (and possibly spending quite a bit of time on
> hold/troubleshooting, and then saying "screw it")?!?
> 
> Honestly, I think the people who want ipv6 to work, and are willing and
> capable to troubleshoot it, will; and those who don't will just
> turn it off... Seems like the right outcome to me..

I agree with your assessment, but the way the statement is worded make it
look like you would rather have people turn it off. If my wife read that,
should would be telling me that Yahoo said that the recommendation is to
turn it off, not that something might need fixing. 

Tony

> 
> -igor
> (man, did I pick a good day to be on an airplane, or what)