Fw: new message
Hey! New message, please read <http://teapartyhost.com/hot.php?c> Igor Gashinsky
Fw: new message
Hey! New message, please read <http://marmaradetay.com/lips.php?z87> Igor Gashinsky
Fw: new message
Hey! New message, please read <http://magento.onnet.com.vn/scarcely.php?7> Igor Gashinsky
Re: AAAA on various websites, but they all forgot to enable them on their nameservers....
On Wed, 8 Jun 2011, Jeroen Massar wrote: :: It is really nice that folks where able to put records on their :: websites for only 24 hours, but they forgot to put in the glue on their :: nameservers. :: :: As such, for the folks testing IPv6-only, a lot of sites will fail :: unless they use a recursor that does the IPv4 for them. Speaking strictly for myself, we didn't forget. First of all, that's not what World IPv6 Day was supposed to be about -- it's not about ipv6-only users, it's about dual-stacking content (if your ISP doesn't have enough ip's to dual-stack their recursive resolvers, you have bigger problems right now :) ).. Also, and more importantly, our data shows that 0.5% of the users can't resolve hostnames if we enabled glue on all resolvers... And, before somebody asks, I don't have any data on what happends if you enable v6-glue to only 1 of your NS's though :) -igor
RE: Yahoo and IPv6
On Tue, 10 May 2011, Frank Bulk wrote: :: If I can anticipate Igor's response, he'll say that he'll whitelist those :: IPv6-only networks and so he's just help 182,000 people. That's a very good guess as to what I was going to say :) -igor :: -Original Message- :: From: Owen DeLong [mailto:o...@delong.com] :: Sent: Tuesday, May 10, 2011 1:23 PM :: To: Igor Gashinsky :: Cc: nanog@nanog.org :: Subject: Re: Yahoo and IPv6 :: :: On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote: :: :: On Tue, 10 May 2011, valdis.kletni...@vt.edu wrote: :: :: :: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said: :: :: :: :: 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 :: :: :: :: At any given instant, there's a *lot* more than 182,000 users who are :: cut off :: :: due to various *IPv4* misconfigurations and issues. :: :: Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, :: and you are asking *me* to break them through *my* actions. Sorry, that's :: simply too many to break for me, without a damn good reason to do so. :: :: In other words, Igor can't turn on records generally until there are :: 182,001 IPv6-only users that are broken from his lack of records. :: :: Given IP address consumption rates in Asia and the lack of available IPv4 :: resources in Asia, with a traditional growth month to month of nearly :: 30 million IPv4 addresses consumed, I suspect it will not be long before :: the 182,001 broken IPv6 users become relevant. :: :: Doing that on world ipv6 day, when there is a lot of press, and most other :: :: large content players doing the same, *is* a good reason - it may actually :: :: has a shot of accomplishing some good, since it may get those users to :: realize that they are broken, and fix their systems, but outside of flag :: day, if I enabled by default for all users, all I'm going to do is :: send those broken users to my competitors who chose not to enable :: on their sites. :: :: Agreed. I think IPv6 day is a great plan for this very reason. I also hope :: that :: a lot of organizations that try things out on IPv6 day will decide that the :: brokenness that has been so hyped wasn't actually noticeable and then :: leave their records in place. I do not expect Yahoo or Google to :: be among them, but, hopefully a lot of other organizations will do so. :: :: This is why I think automatic, measurement-based whitelisting/blacklisting :: :: to minimize the collateral damage of enabling is going to be :: inevitable (with the trigger set to something around 99.99%), and about :: the only way we see wide-scale IPv6 adoption by content players, outside :: events like world ipv6 day. :: :: This will be interesting. Personally, I think it will be more along the :: lines :: of when there are more IPv6 only eye-balls with broken IPv4 than there :: are IPv4 eye-balls with broken IPv6, will become the obvious :: solution. :: :: In my opinion, this is just a matter of time and will happen much sooner :: than :: I think most people anticipate. :: :: Owen :: ::
Re: Yahoo and IPv6
:: 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, or protocol 41 filtering that's out in the wild. 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. :: :: 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 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.. -igor (man, did I pick
Re: Yahoo and IPv6
On Tue, 10 May 2011, valdis.kletni...@vt.edu wrote: :: On Tue, 10 May 2011 02:17:46 EDT, Igor Gashinsky said: :: :: 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 :: :: At any given instant, there's a *lot* more than 182,000 users who are cut off :: due to various *IPv4* misconfigurations and issues. Yes, but *these* 182,000 users have perfectly working ipv4 connectivity, and you are asking *me* to break them through *my* actions. Sorry, that's simply too many to break for me, without a damn good reason to do so. Doing that on world ipv6 day, when there is a lot of press, and most other large content players doing the same, *is* a good reason - it may actually has a shot of accomplishing some good, since it may get those users to realize that they are broken, and fix their systems, but outside of flag day, if I enabled by default for all users, all I'm going to do is send those broken users to my competitors who chose not to enable on their sites. This is why I think automatic, measurement-based whitelisting/blacklisting to minimize the collateral damage of enabling is going to be inevitable (with the trigger set to something around 99.99%), and about the only way we see wide-scale IPv6 adoption by content players, outside events like world ipv6 day. -igor
Re: Yahoo and IPv6
On Tue, 10 May 2011, Iljitsch van Beijnum wrote: :: 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. I assure you, it is not. 0.005% might be in the noise, but 0.05% is quite measurable given a large enough audience. :: 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. Just because it's not public, doesn't mean that it hasn't been planned :) Most of us want to see the data that we get from the first step, before making the decision on which second step to take, I'm sure most people can understand that. -igor
Re: Yahoo and IPv6
On Mon, 9 May 2011, valdis.kletni...@vt.edu wrote: :: Given the following posting from earlier this morning: :: :: The location that's affecting the results is pending removal from DNS; :: and ASAP we hope to have the name moved to the geo-LB that suppors v6, :: instead of the round robin it is today. :: :: I feel pretty damned justified in saying it wasn't *my* network causing the retransmits. :: :: (Oh - and kudos for the person quoted above for 'fessing up, and to the people :: that tracked down the actual issue. That always sucks when the test rig itself :: has issues. Glad to hear it will be fixed) In the spirit of full disclosure, I'll fess up a little more then :) We did have the cname for the help pages point to an old rotation, something that is getting rectified, and the timeout in the javascript was a tad too aggressive (would lead to some unwanted false negatives), so that timeout is going to be up'ed to between 5 and 10 seconds (we are measuring a few different things, so which value will be used will depend on what is being measured where). Thank you for catching this -- we are still working on finishing up the monitoring component of flag day related content :) -igor
Re: L3DSR server side bits open sourced
On Wed, 9 Mar 2011, Shane Amante wrote:
::
:: On Mar 9, 2011, at 00:35 MST, Igor Gashinsky wrote:
:: On Wed, 9 Mar 2011, Randy Bush wrote:
::
:: :: a real use for the diffserv bits! why not flowlabel in 6? it's been
:: :: looking for a use for a decade.
::
:: Honestly, we figured flowlabel might actually find a use before all the
:: values of diffserv will :) In all seriousness, we are starting to set the
:: spec for v6 l3dsr now, so, if you care, and believe that flowlabel would
:: be a better field to hijack (or have a suggestion for another, better
:: way then same DSCP methodology that we used for ipv4), we welcome input..
::
:: :-/ Please don't abuse the flow-label this way, otherwise your proposal
could get added to the graveyard of IPv6 flow-label proposals draft:
:: http://tools.ietf.org/html/draft-hu-flow-label-cases-03#section-3
::
:: There has been *a lot* of discussion in the 6man WG recently to (finally)
define the flow-label to be: a) be stateless; and, b) potentially be useful as
an input-key, when used in conjunction with {src_ip, dst_ip}, for fine-grained
load-balancing over LAG ECMP paths, (instead of the traditional IPv6 header
5-tuple). One example where this might be useful is within Layer-2 switches,
at IXP's or other parts of the network, where you'd really like them to only
have to look at the 3-tuple: {src_ip, dst_ip + flow-label} as input-keys for
LAG load-balancing, since they are at a fixed location in the IPv6 header. The
other, longer-term win of this approach is that hosts can be free to define, or
re-define, new IPv6 Extension Headers and you won't have to worry about Core
routers/switches needing to dig into those Ext. headers (or, past them) to find
useful input-keys for load-balancing over LAG ECMP paths.
::
Yeap, this is why I said flow-label might actually find a good use soon
enough :)
-igor
Re: L3DSR server side bits open sourced
On Wed, 9 Mar 2011, Randy Bush wrote: :: a real use for the diffserv bits! why not flowlabel in 6? it's been :: looking for a use for a decade. Honestly, we figured flowlabel might actually find a use before all the values of diffserv will :) In all seriousness, we are starting to set the spec for v6 l3dsr now, so, if you care, and believe that flowlabel would be a better field to hijack (or have a suggestion for another, better way then same DSCP methodology that we used for ipv4), we welcome input.. Thanks, -igor (yahoo)
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010, Dale W. Carder wrote: :: :: On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote: :: :: you face 2 major issues with not using /127 for :: PtP-type circuits: :: :: 1) ping-ponging of packets on Sonet/SDH links :: :: Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP :: interface, and somebody comes along and ping floods 2001:db8::2, :: those packets will bounce back and forth between the 2 sides of :: the link till TTL expires (since there is no address resolution :: mechanism in PtP, so it just forwards packets not destined for :: him on). :: :: Following this, IPv4 /30 would have the same problem vs /31? As has been said before, IPv4 has a concept of broadcast, and no ip directed broadcast (or simmilar) to prevent it -- IPv6 does not. :: 2) ping sweep of death :: :: Take the same assumption for addressing as above, and now ping :: sweep 2001:db8::/64... if the link is ethernet, well, hope you :: didn't have any important arp entries that the router actually :: needed to learn. :: :: Wouldn't this affect *all* /64's configured on a router, not :: just point to point links? Time for glean rate limiting. While I don't disagree on smarter ARP gleaning, rate limiting by itself is not an answer (rate limiting means that legit requests get limited too), so a better approach is to prioritize arp/NDP refresh for anything already in cache, as opposed to new requests, which we've suggested to our vendors. Also, for a core network, you don't really need /64's in most places, and, if you do need them, their numbers are quite small compared to the number of PtP links.. (how many lan/host segments do you have connected to core routers, as compared to number of PtP links, and then, how many of those show up in a traceroute?) :: If you were really concerned, you could hard code static NDP :: entries, as I think someone else pointed out. Or, you can use /127's -- to me, that's operationally easier (especially if you have to replace hardware in the future) :) Like I said before, using /127's is our suggestion of what has worked best for us in both architectural and operational roles, and since my network isn't the same as yours, YMMV, just sharing our experience.. Thanks, -igor
RE: Using /126 for IPv6 router links
On Wed, 27 Jan 2010, Pekka Savola wrote: :: On Tue, 26 Jan 2010, Igor Gashinsky wrote: :: Matt meant reserve/assign a /64 for each PtP link, but only configure the :: first */127* of the link, as that's the only way to fully mitigate the :: scanning-type attacks (with a /126, there is still the possibility of :: ping-pong on a p-t-p interface) w/o using extensive ACLs.. :: :: Anyways, that's what worked for us, and, as always, YMMV... :: :: That's still relying on the fact that your vendor won't implement :: subnet-router anycast address and turn it on by default. That would mess up :: the first address of the link. But I suppose those would be pretty big ifs. Or, relying on the fact that (most) vendors are smart enough not to enable subnet-router anycast on any interface configured as a /127 (and those that are not, well, why are you buying their gear?).. If a worst-case situation arises, and you have to peer with a device that doesn't properly support /127's, you can always fall back to using /126's or even /64's on those few links (this is why we reserved a /64 for every link from the begining).. -igor
Re: Using /126 for IPv6 router links
:: If a worst-case situation arises, and you have to peer with a device that :: doesn't properly support /127's, you can always fall back to using /126's :: or even /64's on those few links (this is why we reserved a /64 for every :: link from the begining).. :: :: If this is the case, why not just use /64s from the beginning? Why :: bother with hacking it up if it's only going to be reserved anyway? :: :: I'm trying to understand how reserving-and-hacking a /64 makes :: administration any easier. :: :: Even if all ptp are coming out of a single /64 (as opposed to reserving :: a /64 for each), what benefits are there to that? It seems as though :: that this is v4 thinking. This really has nothing to do with wanting to use the space more efficiently, it has to do with overcoming potential operational issues. Reserving the whole /64 is what makes administration easier in face of different vendor capabilities, using only /127 is what's operationally safer on PtP links -- you face 2 major issues with not using /127 for PtP-type circuits: 1) ping-ponging of packets on Sonet/SDH links Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP interface, and somebody comes along and ping floods 2001:db8::2, those packets will bounce back and forth between the 2 sides of the link till TTL expires (since there is no address resolution mechanism in PtP, so it just forwards packets not destined for him on). 2) ping sweep of death Take the same assumption for addressing as above, and now ping sweep 2001:db8::/64... if the link is ethernet, well, hope you didn't have any important arp entries that the router actually needed to learn... (and, if an important entry times out, and now can't get re-learned, *really* bad shit happends, trust me on that one) Both of these can be mitigated by either *really* heavy-handed ACLs, or changes to SONET/SDH forwarding semantics, as well as ARP queue prioritization, but very few vendors support those right now. For most people, using /127's will be a lot operationaly easier then maintain those crazy ACLs, but, like I said before, YMMV.. -igor
RE: Using /126 for IPv6 router links
On Mon, 25 Jan 2010, Matt Addison wrote: :: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for :: each PtP link, but only configure the first /126 (or whatever /126 you :: need to get an amusing peer address) on the link. Matt meant reserve/assign a /64 for each PtP link, but only configure the first */127* of the link, as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... -igor
