Unfortunately, I suspect many organizations will be following that approach. I hope that some will instead see this as a great opportunity for the last step in making their public services IPv6 reachable *... and that they also start/continue/complete taking IPv6 within their internal networks as well.* /TJ On Mon, May 9, 2011 at 04:19, Michael Painter <tvhawaii@shaka.com> wrote:

Franck Martin wrote:

...

http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html "Will IPv6 become a permanent change on June 8, 2011? No. World IPv6 day is a 24-hour trial period in which we will publish our content on both the IPv4 and IPv6 servers. Yahoo! is participating in order to help prepare our services (as well as your hardware) to help ensure a smooth transition for when the IPv4 addresses run out. "

Huh… I thought IPv4 addresses had run out already….

At IANA level and now for anyone in the AP region at least.

http://www.apnic.net/policy/add-manage-policy#9.10

On Mon, May 9, 2011 at 11:01, Joel Jaeggli <joelja@bogus.com> wrote:

On 5/9/11 5:06 AM, TJ wrote:

...

Unfortunately, I suspect many organizations will be following that approach.

I hope that some will instead see this as a great opportunity for the last step in making their public services IPv6 reachable *... and that they also start/continue/complete taking IPv6 within their internal networks as well.*

my ipv6 peering with yahoo came up like 8 months ago...

Sure, but peering is not the same as publicly/universally reachable services. I hope that World IPv6 Day raises enough awareness, and yields enough success stories, that we make some noticeable progress in the near future.

I don't think there's anything particularly unfortunate about what major content providers are doing with ipv6, give them customers and they wil support them.

It is unfortunate (to me), because content providers being accessible is an important step in breaking this chicken-egg scenario. We need the service providers and content providers to make this "IPv6 thing" usable/relevant - and (just IMHO) the sooner the better. /TJ

On Mon, May 9, 2011 at 8:16 AM, Arie Vayner <ariev@vayner.net> wrote:

Actually, I have just noticed a slightly more disturbing thing on the Yahoo IPv6 help page...

I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and it says: "We detected an issue with your IPv6 configuration. On World IPv6 Day, you will have issues reaching Yahoo!, as well as your other favorite web sites. We recommend disabling IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>, or seeking assistance in order to fix your system's IPv6 configuration through your ISP or computer manufacturer."

What disturbs me is the piece saying "We recommend disabling IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html> ", with a very easy link...

No IPv6 is better than broken* IPv6. *broken being defined as: you go to www.yahoo.com with your broken IPv6 connection (6to4?) and www.yahoo.com fails to load within your margin of acceptable latency, then you go to a competitor's web site. The point of IPv6 day is that we "shake out" the issues together as one community. If it works great, that is great and we can make solid decisions based on real world data on how to fix and move forward. As an operator of a soon to be production launched IPv6-only + NAT64 service, nobody is more eager for native IPv6 content than me. That said, this is the right path for the content guys to dip their toes in. ================================= T-Mobile USA IPv6 Beta http://bit.ly/9s0Ed3 =================================

On Mon, 9 May 2011, Arie Vayner wrote:

What disturbs me is the piece saying "We recommend disabling IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html> ", with a very easy link...

Even more disturbing than that is that when I run a test from here it says that I have broken v6. But I don't have broken v6 and test-v6.com proves it with a 10/10. This Yahoo tool doesn't seem to even give a hint as to what it thinks is broken. Can anyone from Yahoo shed some light on what this tool is doing and how to get it to tell us what it thinks is broken? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss

On 05/31/2011 05:31 PM, Voll, Toivo wrote:

Going to http://help.yahoo.com/l/us/yahoo/ipv6/ and hitting "Start IPv6 Test" I get: "Your system will continue to work for you on World IPv6 day. However, we found that your server only supports IPv4 at this time. You'll simply continue to use IPv4 to reach your favorite web sites."

Netalyzr (http://n3.netalyzr.icsi.berkeley.edu/analysis) finds no issues with my IPv6 status, but alerts me to the fact (since confirmed by switching to IE) that Google Chrome defaults to IPv4 rather than IPv6, and consequently a lot of the testing tools claim that my IPv6 is broken.

Toivo Voll Network Administrator Information Technology Communications University of South Florida

-----Original Message----- From: Brandon Ross [mailto:bross@pobox.com] Sent: Monday, May 09, 2011 12:25 To: Arie Vayner Cc: nanog@nanog.org Subject: Re: Yahoo and IPv6

Even more disturbing than that is that when I run a test from here it says that I have broken v6. But I don't have broken v6 and test-v6.com proves it with a 10/10. This Yahoo tool doesn't seem to even give a hint as to what it thinks is broken.

Can anyone from Yahoo shed some light on what this tool is doing and how to get it to tell us what it thinks is broken?

Interesting - must be a windows issue, Google Chrome on Linux works fine at http://help.yahoo.com/l/us/yahoo/ipv6/ -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com

On 2011-Jun-01 13:18, Tim Chown wrote:

On 31 May 2011, at 22:31, Voll, Toivo wrote:

...

Netalyzr (http://n3.netalyzr.icsi.berkeley.edu/analysis) finds no issues with my IPv6 status, but alerts me to the fact (since confirmed by switching to IE) that Google Chrome defaults to IPv4 rather than IPv6, and consequently a lot of the testing tools claim that my IPv6 is broken.

I'm a little confused there - the current Chrome prefers IPv6, and also now includes code to allow fast failover to IPv4 in the event IPv6 connectivity is down/slow (300ms headstart).

I had some issues with Netalyzer detecting my dual-stack status, which the chaps there are helping with.

Netalyzer is Java-based, thus it uses the Java stack and not the Javascript/ECMAScript stack that Chrome provides. As such it just bypasses all of that and the coolest thing is that you might not even have an IPv6-capable Java stack for your host. The 1.6.0_25-b06 Oracle/Sun version on Windows that I have here seems to do IPv6 just fine btw in combination with Netalyzr. Apparently in my home case I have a slow DNS lookup (odd, never had issues with that, maybe it has to do with me having to click 'accept' on the windows firewall UI ;) 8<----------------------------------------------- It takes 239 ms for your computer to fetch a response from our test server using IPv6, while it takes 7289 ms for the same host to fetch a response using IPv4 from the same server. ----------------------------------------------->8 Definitely has to do with clicking 'ok' on the firewall button ;) Greets, Jeroen

On Wed, 01 Jun 2011 07:54:28 EDT, Atticus said:

Disable the firewall and try again or all results are worthless.

On the other hand, if you have a firewall you need to disable in order for it to get valid IPv6 results, you don't actually have a working IPv6 configuration, do you?

On Wed, 01 Jun 2011 19:14:43 +0200, Jeroen Massar said:

On 2011-Jun-01 18:36, Valdis.Kletnieks@vt.edu wrote:

...

On the other hand, if you have a firewall you need to disable in order for it to get valid IPv6 results, you don't actually have a working IPv6 configuration, do you?

The standard Windows Firewall on XP asks the user if it is okay if a program, in this case java, is allowed to open a listen socket.

That's reconfiguring the firewall, not disabling it entirely...

But all of that is not really operational....

Your help desk will probably say it's an operation issue for them this time next week. ;)

From: Valdis.Kletnieks@vt.edu Date: Mon, 09 May 2011 12:25:55 -0400

On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:

...

Actually, I have just noticed a slightly more disturbing thing on the Yahoo IPv6 help page...

I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and it says: "We detected an issue with your IPv6 configuration. On World IPv6 Day, you will have issues reaching Yahoo!, as well as your other favorite web sites.

The *really* depressing part is that it says the same thing for me, on a *known* working IPv6 network.

And then when I retry it a few minutes later, with a tcpdump running, it works.

And then another try says it failed, though tcpdump shows it seems to work.

For what it's worth, the attempted download file is:

% wget http://v6test.yahoo.com/eng/test/eye-test.png --2011-05-09 11:44:39-- http://v6test.yahoo.com/eng/test/eye-test.png Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ... Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [image/png] Saving to: `eye-test.png.1'

[ <=> ] 2,086 --.-K/s in 0s

2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]

Looking at the Javascript that drives the test, it appears the *real* problem is that they set a 3 second timeout on the download - which basically means that if you have to retransmit either the DNS query or the TCP SYN, you're dead as far as the test is concerned.

I have talked to Yahoo engineers about this and they say that their testing has shown that, if it takes more than 3 seconds for a site to load, they start to lose significant traffic. Hence the 3 second timeout. Sadly, I'm afraid that they have a point, but at the same time I suspect that they are assuring failure for almost everyone. A 5 second timeout would probably be more reasonable, but is probably unacceptable to Yahoo management. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

On 05/09/2011 10:27, Jared Mauch wrote:

I do feel the bar that Yahoo is setting is too high. There are a lot of network elements that are broken, either DNS servers, home 'gateway/nat' devices, or other elements in the delegation chain.

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. 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. 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. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/

On 05/09/2011 12:40, Tony Hain wrote:

...

-----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us] Sent: Monday, May 09, 2011 12:11 PM To: Jared Mauch Cc: nanog@nanog.org; Arie Vayner Subject: Re: Yahoo and IPv6

On 05/09/2011 10:27, Jared Mauch wrote:

...

I do feel the bar that Yahoo is setting is too high. There are a lot of network elements that are broken, either DNS servers, home 'gateway/nat' devices, or other elements in the delegation chain.

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. 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.

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.

Which situation ??? The one where the content can demonstrate how broken the networks really are? Or the one where the content sites are exposed for their lack of prior planning?

I disagree with your attempt to scope the problem. :)

The entire point of those technologies you are complaining about was to break the stalemate between content and network,

I also disagree with this statement, but there is very little point in arguing about it at this stage.

because both sides will always wait and blame the other. 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.

One could also argue that the fact that the IPv6 protocol is still not fully mature, and that the IPv6 intelligentsia are only recently coming to the point where they are willing to give both the content and eyeball networks what they've been asking for all along (PI and robust DHCPv6 being top of the respective lists) has led to the situation we're in now. Of course the truth is probably somewhere in the middle, but it's definitely not all on one side.

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. 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. 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. Doug (mafia? seriously?) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/

On May 9, 2011, at 4:26 PM, Jeff Wheeler wrote:

On Mon, May 9, 2011 at 3:58 PM, Doug Barton <dougb@dougbarton.us> wrote:

...

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.

[...]

This problem is, and always has been, on the access side. Point your fingers that way.

While I agree with Jeff, I agree with Doug more. Unfortunately, finger-pointing will not fix the problem. We have identified many of the problems, and hopefully June 8 will shine a very bright light on any that are left. Let's work on fixing the problems, and let the historians figure out whose "fault" it was. -- TTFN, patrick P.S. As an aside, and since the finger was pointed in my general direction, I'd just like to say chicken and egg problems always suck. However, when the largest sites on the 'Net have enabled v6, yet are forced to whitelist or lose millions of dollars because the other end is broken, I don't see how any rational person can seriously call this the "content mafia's" fault. On May 9, 2011, at 4:26 PM, Jeff Wheeler wrote:

On Mon, May 9, 2011 at 3:58 PM, Doug Barton <dougb@dougbarton.us> wrote:

...

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.

Frankly, I think the finger is simply pointing in the wrong direction. I have zero choices for native IPv6 at home, and I'm sure that is true for the majority of us. SOHO CPE support barely exists because access networks haven't been asking for it. Call centers are certainly not equipped to evaluate "traceroute tickets" or assist users in any practical way, which is why we see "disable IPv6 and try again" as the cookie-cutter answer to any problem when the end-user has IPv6.

The expectation that content providers should rush to publish AAAA records by default (instead of white-listing, etc.) at a time when even motivated end-users can't get IPv6 without resorting to tunnels is ridiculous. Let's be glad that these content providers have done all the necessary prep work, such as deploying appropriate network infrastructure and updating their software, so that they can choose to send AAAA responses when they want to.

This problem is, and always has been, on the access side. Point your fingers that way.

-- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts

On May 9, 2011, at 4:26 PM, Jeff Wheeler wrote:

This problem is, and always has been, on the access side. Point your fingers that way.

<aol>+1</aol> I think we're in a stage where the access networks are playing catch-up. The CPE marketplace is going to see some significant growth in sales in the short term as well. I'll say that enabling IPv6 in the datacenter and the core is "easy". Any modern hardware worth the cash you spend on it does native IPv6. (If the hardware does not, eg: firewalls, etc, please re-read the prior statement). Putting IPv6 in a datacenter or on a lan is easy. You put a /64 there, let the host use SLAAC and let the RA magic work. You talk to the nameserver over your dual-stack (IPv4) side and it's all set. While there are concerns about people sending bogus RA's and other things, the same is true for anyone putting the router IP address on the main ethernet of a server too. These all cause problems. The routing protocols are all there, either with ISIS or OSPFv3. BGP is there too. You can even skip over non-IPv6 enabled nodes by doing 6PE if you have MPLS in your network. I'm hopeful that nobody will see the problems out there on IPv6 day. They've been dealt with in the 99%+ of the cases already. The fact that we're talking about something past the decimal point is good IMHO. I've observed that the top-million sites can't get it better than 99.4% right for a DNS query. I can break that out by the top-10, 100, 1k, 10k, 100k and show a graph if that's useful. I think it's "good enough". I'd like to call out those with broken network elements and suggest they fix them. I'd like to have native IPv6 at home, but my provider is not ready yet. "Soon" is my hope. The fact that it's there in many other places means it's possible. I'd like to see more progress getting there than finger pointing. I expect the next 30 days to be a lot of fun getting to IPv6 day, and it to be far less eventful than we worry it will be. - Jared

On Mon, May 9, 2011 at 3:57 PM, Jeff Wheeler <jsw@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.

On 5/10/2011 12:57 AM, Jeff Wheeler wrote:

Your suggestion has two main disadvantages: 1) it doesn't work on some platforms, because input ACL won't stop ND learn/solicit -- obviously this is bad 2) it requires you to configure a potentially large input ACL on every single interface on the box, and adjust that ACL whenever you provision more IPv6 addresses for end-hosts -- kinda like not having a control-plane filter, only worse

Might need to rewrite some portion of ND to do this, but can't a cookie be encoded in the ND packet and no state kept? That should reduce the problem to one of a packet flood which everyone already deals with now. Sorry if this has been suggested/shot down before. The ND problems keep being mentioned and I never see this proposed and it seems like an obvious solution. Robert

:: >> 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 a good day to be on an airplane, or what)

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)

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. Let's keep a sense of proportion, shall we?

On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote:

On Tue, 10 May 2011, Valdis.Kletnieks@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 AAAA records generally until there are 182,001 IPv6-only users that are broken from his lack of AAAA 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 AAAA by default for all users, all I'm going to do is send those "broken" users to my competitors who chose not to enable AAAA 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 AAAA 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 AAAA 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, AAAA 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

On May 10, 2011, at 6:03 PM, Matthew Palmer wrote:

On Tue, May 10, 2011 at 11:22:54AM -0700, Owen DeLong wrote:

...

On May 10, 2011, at 9:32 AM, Igor Gashinsky wrote:

...

On Tue, 10 May 2011, Valdis.Kletnieks@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 AAAA records generally until there are 182,001 IPv6-only users that are broken from his lack of AAAA records.

There may be something stupid I haven't considered about this, but wouldn't a v6-only end user be making their DNS requests over v6 (at least to their ISP's resolver), and if their provider was nice enough to continue that v6ness up the chain, wouldn't it be fairly simple (to the point of "I'd be stunned if everyone wasn't already doing this") to say to Yahoo/Google/whatever's ultra-smart whitelisting DNS servers, "v6-whitelist all v6 DNS requests"?

Not necessarily and almost entirely irrelevant. Yahoo may or may not get the query from the ISP's resolver directly. An IPv6-only client might have a private IPv4 address that reaches an IPv4 resolver within their local network that may or may not have public IPv4 connectivity. There is no clean or reliable way to infer anything about the protocol stack on the client from an authoritative DNS server.

That way, v6-only people are guaranteed to get the AAAA records they so badly crave, without making an excessive mess for anyone else.

Another beautiful theory murdered by a brutal gang of facts.

I know this falls down if your v6-only-providing ISP takes your recursive DNS requests on IPv6 and sends them out via IPv4 even if AAAA records were available, but why would anyone be that dumb? Since the initial request would come in via v6, anything whitelisting in this fashion would be sending the AAAA records out, so you should never have to fall back to v4 unless someone isn't providing DNS via v6 at all, and who would willingly have their site v6 enabled without v6 enabling the DNS? (Yes, I'm aware of registrars who don't accept v6 glue, but get your whacking sticks out and keep whackin' 'til they fix it -- and kudos to gkg.net for having that sorted *before* I put my first v6 site up).

It's not a matter of dumb. There are all kinds of reasons this might occur. For example, an IPv6-only host behind an HE Tunnel on a network that gets IPv4 only service from another ISP, but, is out of IPv4 addresses. Owen

On Wed, May 11, 2011 at 23:10, Franck Martin <fmartin@linkedin.com> wrote:

I think the yahoo test should just differentiate between no IPv6 and IPv6 is slow (test between 3s and 10s). Like:

We have detected that you have IPv6 and will be able to access our site on IPv6 day, but your user experience may not be as good as with IPv4, you may consider disabling IPv6.

Measurements during the experiment won't be directly comparable to those before/after, at least as far as I can see. So they will be informative, but its the slope of the brokenness line before/after that will determine when IPv6 is not an impediment to itself. -Scott

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. Frank -----Original Message----- From: Owen DeLong [mailto:owen@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.Kletnieks@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 AAAA records generally until there are 182,001 IPv6-only users that are broken from his lack of AAAA 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 AAAA by default for all users, all I'm going to do is send those "broken" users to my competitors who chose not to enable AAAA 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 AAAA 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 AAAA 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, AAAA 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

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. Frank -----Original Message----- From: Owen DeLong [mailto:owen@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.Kletnieks@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 AAAA records generally until there are 182,001 IPv6-only users that are broken from his lack of AAAA 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 AAAA by default for all users, all I'm going to do is send those "broken" users to my competitors who chose not to enable AAAA 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 AAAA 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 AAAA 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, AAAA 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

On May 14, 2011, at 2:12 AM, Lorenzo Colitti wrote:

On Tue, May 10, 2011 at 11:22 AM, Owen DeLong <owen@delong.com> wrote:

...

In other words, Igor can't turn on AAAA records generally until there are 182,001 IPv6-only users that are broken from his lack of AAAA records.

There will be no IPv6-only users. There will only be users with better IPv6 connectivity than IPv4 connectivity.

My Desktop is not able to make any IPv4 socket connections anymore. I get "Protocol not supported". So there are IPv6-only users, already bitten by no AAAA. So that's -1 from me. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.

My Desktop is not able to make any IPv4 socket connections anymore. I get "Protocol not supported". So there are IPv6-only users, already bitten by no AAAA. So that's -1 from me.

i choose to only run decnet ii, and the world should fix my connectivity problem. randy

On May 13, 2011, at 9:09 PM, Bjoern A. Zeeb wrote:

On May 14, 2011, at 2:12 AM, Lorenzo Colitti wrote:

...

On Tue, May 10, 2011 at 11:22 AM, Owen DeLong <owen@delong.com> wrote:

...

In other words, Igor can't turn on AAAA records generally until there are 182,001 IPv6-only users that are broken from his lack of AAAA records.

There will be no IPv6-only users. There will only be users with better IPv6 connectivity than IPv4 connectivity.

My Desktop is not able to make any IPv4 socket connections anymore. I get "Protocol not supported". So there are IPv6-only users, already bitten by no AAAA. So that's -1 from me.

/bz

-- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.

Unfortunately, Igor may not see your message since he doesn't have an IPv6 AAAA record for his MX. ;-) Owen

...

...

My Desktop is not able to make any IPv4 socket connections anymore. I get "Protocol not supported". So there are IPv6-only users, already bitten by no AAAA. So that's -1 from me.

Sounds to me like you're not on The Internet any more. Matthew Kaufman

On May 14, 2011 9:28 AM, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote:

On May 14, 2011, at 3:41 PM, Matthew Kaufman wrote:

...

...

My Desktop is not able to make any IPv4 socket connections anymore. I

get

...

...

"Protocol not supported". So there are IPv6-only users, already bitten by no AAAA. So that's -1 from me.

Sounds to me like you're not on The Internet any more.

Haha. I might still do UUCP and listen to a talk from Eric Allman currently, yet I can send you Email and that's supposed to be over the Internet only these days, I just heard. So I am clearly online.

I assume you don't understand the options some people have or how much content might be available on IPv6 already and might have been for years.

/bz

Ipv6-only is a highly functional reality when enabled with nat64/dns64, there are several empirical accounts on the web. I have be running a beta service of it for over a year and my experience is that it works very well for web and email and nearly everything I do on smartphone , but not all things for sure. Cb —--------------- http://bit.ly/igQBx4 -- T-Mobile USA ipv6 beta.

-- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.

On Sat, May 14, 2011 at 11:10:00AM -0700, Matthew Kaufman wrote:

On 5/14/2011 10:19 AM, Cameron Byrne wrote:

...

Ipv6-only is a highly functional reality when enabled with nat64/dns64, there are several empirical accounts on the web.

For a version of "highly functional" that does not include Skype, BitTorrent, SIP phones, and anything Flash Player app using RTMFP to reach peers, sure.

As has been mentioned here, the lack of reaching any of these can be seen as a plus, including the various advert networks. Instead of loading that flash video iframe you might get content. And it's much better now then when you were using wais/gopher/cern httpd in the day. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On 5/14/2011 6:41 PM, Jima wrote:

On 2011-05-14 13:10, Matthew Kaufman wrote:

...

On 5/14/2011 10:19 AM, Cameron Byrne wrote:

...

Ipv6-only is a highly functional reality when enabled with nat64/dns64, there are several empirical accounts on the web.

For a version of "highly functional" that does not include Skype, BitTorrent, SIP phones, and anything Flash Player app using RTMFP to reach peers, sure.

1. There are SIP phones that support IPv6, e.g., http://wiki.snom.com/Networking/IPv6

Sure, but NAT64 doesn't let SIP phones on an IPv6-only network talk to SIP phones on an IP4-only network.

2. Exactly whose fault is it that RTMFP can't reach peers via IPv6? (Granted, I'm not sure RTMFP is the best argument for your point anyway, since apparently symmetric NAT monkey-wrenches it, too: http://forums.adobe.com/message/3602495 )

RTMFP can reach peers via IPv6... but it can't talk between an IPv6-only peer that is behind a NAT64 and an IPv4-only peer. And that would be the fault of NAT64, which for all of the applications I mentioned (and more) made the seriously wrong assumption that every IPv4 address is looked up in a DNS server. Matthew Kaufman

On 5/15/2011 6:49 AM, Cameron Byrne wrote:

On May 14, 2011 9:30 PM, "Matthew Kaufman" <matthew@matthew.at <mailto:matthew@matthew.at>> wrote:

...

...

Sure, but NAT64 doesn't let SIP phones on an IPv6-only network talk

to SIP phones on an IP4-only network.

...

Right, that is why we have SBC / b2bue for the cases we want to work.

Ok, so you concede that NAT64 requires yet another device at the edge to make the SIP phones work...

We have agreed to disagree on the value of this before. Sorry your not so popular protocol is going the way of EGP .... it's just not fit for the evolving internet and will be subject to natural deselction. I am sure you will disagree with that and insist every end user must always support ipv4 because rtmfp is top of mind for so many users .... but we can leave it at that ....please

...and we'll agree to disagree on this one (RTMFP)... and users will just be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks you're building, I suppose? Matthew Kaufman

On 2011-05-15 10:28, Matthew Kaufman wrote:

On 5/15/2011 6:49 AM, Cameron Byrne wrote:

...

We have agreed to disagree on the value of this before. Sorry your not so popular protocol is going the way of EGP .... it's just not fit for the evolving internet and will be subject to natural deselction. I am sure you will disagree with that and insist every end user must always support ipv4 because rtmfp is top of mind for so many users .... but we can leave it at that ....please

...and we'll agree to disagree on this one (RTMFP)... and users will just be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks you're building, I suppose?

BitTorrent tends to be an evolving protocol, with lots of clients competing for mindshare; I'm not certain that limitation will remain. As for Skype, it seems like that is potentially a business decision on Microsoft's behalf. With the money they may be sinking into the technology, I would contend they have something to lose by not making it work. As has been discussed at length on this list, this is NOT an unfixable issue. Jima

On May 15, 2011, at 8:28 AM, Matthew Kaufman wrote:

On 5/15/2011 6:49 AM, Cameron Byrne wrote:

...

On May 14, 2011 9:30 PM, "Matthew Kaufman" <matthew@matthew.at <mailto:matthew@matthew.at>> wrote:

...

...

Sure, but NAT64 doesn't let SIP phones on an IPv6-only network talk to SIP phones on an IP4-only network.

Right, that is why we have SBC / b2bue for the cases we want to work.

Ok, so you concede that NAT64 requires yet another device at the edge to make the SIP phones work...

...

We have agreed to disagree on the value of this before. Sorry your not so popular protocol is going the way of EGP .... it's just not fit for the evolving internet and will be subject to natural deselction. I am sure you will disagree with that and insist every end user must always support ipv4 because rtmfp is top of mind for so many users .... but we can leave it at that ....please

...and we'll agree to disagree on this one (RTMFP)... and users will just be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks you're building, I suppose?

Matthew Kaufman

Uh, BitTorrent works just fine for me on IPv6. Owen

-----Original Message----- From: Matthew Kaufman [mailto:matthew@matthew.at] Sent: Sunday, May 15, 2011 8:56 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: Yahoo and IPv6

On 5/15/2011 7:08 PM, Owen DeLong wrote:

...

On May 15, 2011, at 8:28 AM, Matthew Kaufman wrote:

...

...and we'll agree to disagree on this one (RTMFP)... and users will just be ok with BitTorrent and Skype not working on the v6-only + NAT64 networks you're building, I suppose?

Matthew Kaufman Uh, BitTorrent works just fine for me on IPv6.

And how many v4-only nodes are you reaching from your v6-only client through a NAT64?

Should be able to reach all of them if it is combined with DNS64

On 16 mei 2011, at 9:31, Owen DeLong wrote:

I believe that the BitTorrent clients are smart enough to discard the IPv4 nodes reached through NAT64 and will, instead, just use the native IPv6 nodes. I don't see this as a problem and I"m not sure why you do.

Because that way the IPv4 and IPv6 swarms remain disconnected in the absence of some dual stack peers. (I.e., if the swarm is small and you're the only IPv6 participant.) It would be much better if you could go from IPv6 to IPv4 through a NAT64.

On May 16, 2011, at 2:10 AM, George Bonser wrote:

...

Because that way the IPv4 and IPv6 swarms remain disconnected in the absence of some dual stack peers. (I.e., if the swarm is small and you're the only IPv6 participant.)

It would be much better if you could go from IPv6 to IPv4 through a NAT64.

The problem is when the client is handed an explicit address rather than a host name. In that case, there needs to be some standard environment variable for "IPv64 Prefix" that applications can query.

For a browser this might be something like the configured proxy. Maybe an OS such as Windows might have a registry value for this. Maybe Linux and other unix-like variations could have a sysctl for that.

It shouldn't be a sysctl. It should be more like resolv.conf at worst.

There should be some standard way for a native v6 host to determine the v6 to v4 prefix to use in a NAT64 environment.

This assumes some standard way to do NAT64. Owen

On May 16, 2011, at 1:56 AM, Iljitsch van Beijnum wrote:

On 16 mei 2011, at 9:31, Owen DeLong wrote:

...

I believe that the BitTorrent clients are smart enough to discard the IPv4 nodes reached through NAT64 and will, instead, just use the native IPv6 nodes. I don't see this as a problem and I"m not sure why you do.

Because that way the IPv4 and IPv6 swarms remain disconnected in the absence of some dual stack peers. (I.e., if the swarm is small and you're the only IPv6 participant.)

It would be much better if you could go from IPv6 to IPv4 through a NAT64.

Meh, a very short term problem at worst. Owen

e have agreed to disagree on the value of this before. Sorry your not so popular protocol is going the way of EGP .... it's just not fit for the evolving internet and will be subject to natural deselction. I am sure you will disagree with that and insist every end user must always support ipv4 because rtmfp is top of mind for so many users .... but we can leave it at that ....please

Which not-so-popular protocol are you referring to here? SIP? Skype? The protocol behind most Flash Players? Jabber? I think many of those are relatively popular and are unlikely to experience this natural deselection of which you speak. I think deprecation of IPv4 is going to happen simply because it will hit several walls in terms of scaling and the cost of continuing to support it will exceed the utility, but, this will have little to do with any particular subset of IPv4 uses and more to do with the overall picture. Owen

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.

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?

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

On 10 mei 2011, at 22:31, Warren Kumari wrote:

...

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

Igor is right on both counts here -- 0.05% is definitely noticeable at these sorts of scale,

Ok, removed my infamatory reply. But tell me how 0.05% is visible in the up/down motions of traffic as it starts raining, there is something especially good/bad on TV, people have to reboot because of a Windows update or whatever. Earlier today I tracerouted the top 1000 websites as per Alexa. I couldn't resolve the DNS for 6 of them. The internet is never 100% up.

I'm also a little surprised that you figured that there were no plans past the event -- much of the point of this is for data gathering -- did you figure folk were just going to gather the data and then ignore it?

I asked the ISOC press people about this after they sent me their press release but they never replied (they may have replied to my message but not with an answer to the question). There is nothing on the ISOC site that mentions anything happening after june 8. Of course I'm assuming individual participants will do stuff, but that doesn't change that this IPv6 day as it stands now is a one-off event, not the first step towards the Ultimate Goal.

Of course I'm assuming individual participants will do stuff, but that doesn't change that this IPv6 day as it stands now is a one-off event, not the first step towards the Ultimate Goal.

The intent is to get folks together after we digest the data, to talk about next steps. Date is not yet picked. I'm hoping we collectively prove there is no broken user problem. I realistically expect we'll have another "v6d" - either as 24h, or as a roll-on-and-stick. But, until we get through the day, and analyze the data, any decisions on what to do next are premature. The NANOG following v6d should be interesting; I'm hoping a number of folks from both access and content are willing to share any early stats they have.

On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote:

For the record Apple's current iChat (the OS (10.6.7) is completely up to date) fails such a test. It will try IPv6 and not fallback to IPv4. End users shouldn't be seeing these sorts of errors.

Is that possibly a failure of the underlying resolver library? Do other applications on the same platform behave correctly? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

On 11 mei 2011, at 2:39, Karl Auer wrote:

On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote:

...

For the record Apple's current iChat (the OS (10.6.7) is completely up to date) fails such a test. It will try IPv6 and not fallback to IPv4. End users shouldn't be seeing these sorts of errors.

Hm, I've had a very hard time finding any IPv6-capable servers to let my iChat talk to...

Is that possibly a failure of the underlying resolver library? Do other applications on the same platform behave correctly?

Apple's Mail application used to do this, but after many years they fixed this, it will now fall back to IPv4 without trouble. This isn't a resolver issue, as the resolver can't know whether IPv6 connectivity does or doesn't work. The resolver simply gives applications that don't explicitly ask for a particular address type all of the addresses of all types for which the system currently has connectivity, I think as determined by the presence of a default route, maybe the presence of an address also matters. What applications need to do when they connect to a remote server is to try the next address when the first one fails and cycle through all addresses before giving up. Of course with IPv4 having multiple addresses is extremely rare so IPv4 applications typically don't bother with this, so it has to be addressed when IPv6ifying applications.

On Tue, May 10, 2011 at 1:58 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

On 10 mei 2011, at 22:31, Warren Kumari wrote:

...

I'm also a little surprised that you figured that there were no plans past the event -- much of the point of this is for data gathering -- did you figure folk were just going to gather the data and then ignore it?

I asked the ISOC press people about this after they sent me their press release but they never replied (they may have replied to my message but not with an answer to the question). There is nothing on the ISOC site that mentions anything happening after june 8.

Of course I'm assuming individual participants will do stuff, but that doesn't change that this IPv6 day as it stands now is a one-off event, not the first step towards the Ultimate Goal.

Speaking only for myself, and not for anybody at all, I wouldn't be terribly surprised if the 24 hour experiment goes smoothly to see it followed up by a week-long trial round the next time. If it doesn't go well, I imagine there will be much data analysis, figuring out what needs to be fixed, and a "24 hour trial, take 2" once a sufficient level of fixage has occurred. Matt

On May 9, 2011, at 9:25 AM, Valdis.Kletnieks@vt.edu wrote:

On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:

...

Actually, I have just noticed a slightly more disturbing thing on the Yahoo IPv6 help page...

I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and it says: "We detected an issue with your IPv6 configuration. On World IPv6 Day, you will have issues reaching Yahoo!, as well as your other favorite web sites.

The *really* depressing part is that it says the same thing for me, on a *known* working IPv6 network.

FWIW, it is happy with my connection and consistently reports positive results. I'm running my own addresses through HE tunnels and tunnels to Layer42. The tunnels ride over Comcast and Raw Bandwidth DSL.

And then when I retry it a few minutes later, with a tcpdump running, it works.

And then another try says it failed, though tcpdump shows it seems to work.

For what it's worth, the attempted download file is:

% wget http://v6test.yahoo.com/eng/test/eye-test.png --2011-05-09 11:44:39-- http://v6test.yahoo.com/eng/test/eye-test.png Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ... Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [image/png] Saving to: `eye-test.png.1'

[ <=> ] 2,086 --.-K/s in 0s

2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]

Looking at the Javascript that drives the test, it appears the *real* problem is that they set a 3 second timeout on the download - which basically means that if you have to retransmit either the DNS query or the TCP SYN, you're dead as far as the test is concerned.

Well, if you're having to retransmit those intermittently, then, it does seem you have some level of brokenness with your network, no? Owen

On May 9, 2011, at 6:28 PM, Mark Andrews wrote:

In message <24499CC4-64A1-419C-AB06-08A82D535B10@delong.com>, Owen DeLong write s:

...

Well, if you're having to retransmit those intermittently, then, it does seem you have some level of brokenness with your network, no?

No. The point of retransmission is to provide reliable service over a unreliable transport. Some level of retransmission is normal.

...

Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

No, it isn't. The transport is failing if you are having to retransmit more than once in a blue moon. Yes, retransmission helps overcome such failures in the transport, but, that does not mean that the transport isn't broken. Owen

On May 9, 2011, at 7:15 PM, Warren Kumari wrote:

On May 9, 2011, at 9:14 PM, Owen DeLong wrote:

...

On May 9, 2011, at 9:25 AM, Valdis.Kletnieks@vt.edu wrote:

...

On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said:

...

Actually, I have just noticed a slightly more disturbing thing on the Yahoo IPv6 help page...

I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and it says: "We detected an issue with your IPv6 configuration. On World IPv6 Day, you will have issues reaching Yahoo!, as well as your other favorite web sites.

The *really* depressing part is that it says the same thing for me, on a *known* working IPv6 network.

FWIW, it is happy with my connection and consistently reports positive results.

I'm running my own addresses through HE tunnels and tunnels to Layer42.

The tunnels ride over Comcast and Raw Bandwidth DSL.

Yup -- while not perfect, the Yahoo! testing has been working well for me.

Yahoo has to tread a very careful line between giving too little and too much information -- I have tried walking a few non-technical folk through troubleshooting their v6 connectivity by phone and it is really very hard to do, and that is interactively. Writing something that someone can download, print and then follow is nigh impossible. No matter how well this guide is written, a number of folk will manage to screw it up, and of *course* that will be Yahoo's fault....

Gathering a list of IPv6 resources that people could refer to and publishing them would be better than saying "Meh, turn it off." Saying "It's broken, you should work with your ISP to correct the problem. A technical detailed description of what went wrong is available <here>(should be a link)." would be preferable. There are lots of better options that don't require Yahoo to actually do more than they are doing now.

Jason's page at http://test-ipv6.com/ gives way way more information (and the page at http://ipv6-test.com/ also gives some more), both of these pages are much too complex for the average user.

True... I'm not saying Yahoo should go that way. I'm just taking issue with the idea of them suggesting users turn off IPv6 as a preferred alternative over fixing it. Owen

W

...

...

And then when I retry it a few minutes later, with a tcpdump running, it works.

And then another try says it failed, though tcpdump shows it seems to work.

For what it's worth, the attempted download file is:

% wget http://v6test.yahoo.com/eng/test/eye-test.png --2011-05-09 11:44:39-- http://v6test.yahoo.com/eng/test/eye-test.png Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ... Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [image/png] Saving to: `eye-test.png.1'

[ <=> ] 2,086 --.-K/s in 0s

2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086]

Looking at the Javascript that drives the test, it appears the *real* problem is that they set a 3 second timeout on the download - which basically means that if you have to retransmit either the DNS query or the TCP SYN, you're dead as far as the test is concerned.

Well, if you're having to retransmit those intermittently, then, it does seem you have some level of brokenness with your network, no?

Owen

On Mon, 9 May 2011, Valdis.Kletnieks@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

Actually, I have just noticed a slightly more disturbing thing on the Yahoo IPv6 help page...

Not speaking in any official capacity, but .. thanks. 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.

On May 9, 2011, at 11:16 AM, Arie Vayner wrote:

Actually, I have just noticed a slightly more disturbing thing on the Yahoo IPv6 help page...

I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to run the "Start IPv6 Test" tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and it says: "We detected an issue with your IPv6 configuration. On World IPv6 Day, you will have issues reaching Yahoo!, as well as your other favorite web sites. We recommend disabling IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html>, or seeking assistance in order to fix your system's IPv6 configuration through your ISP or computer manufacturer."

Weird as I also use the HE tunnel and the yahoo report for me was clean. Tom

On May 19, 2011, at 4:21 PM, Matthew Kaufman wrote:

On 5/9/2011 8:16 AM, Arie Vayner wrote:

...

What disturbs me is the piece saying "We recommend disabling IPv6<http://us.lrd.yahoo.com/_ylt=ArHGqIAYvt_4fpp3N3vLzmNRJ3tG/SIG=11vv8jc1f/**http%3A//help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-09.html> ", with a very easy link...

And I was just sent this link from our very own NSA: http://www.nsa.gov/ia/_files/factsheets/macosx_10_6_hardeningtips.pdf

Disable IPv6 and AirPort when Not Needed Open the Network pane in System Preferences. For every network interface listed: • If it is an AirPort interface but AirPort is not required, click "Turn AirPort off." • Click "Advanced." Click on the TCP/IP tab and set "Configure IPv6:" to "Off" if not needed. If it is an AirPort interface, click on the AirPort tab and enable "Disconnect when logging out."

Matthew Kaufman

Proving that the NSA is behind the times like any other government institution. No real surprise. Owen

On May 9, 2011, at 5:40 PM, Owen DeLong wrote:

On May 8, 2011, at 11:54 PM, Franck Martin wrote:

...

http://help.yahoo.com/l/us/yahoo/ipv6/general/ipv6-05.html "Will IPv6 become a permanent change on June 8, 2011? No. World IPv6 day is a 24-hour trial period in which we will publish our content on both the IPv4 and IPv6 servers. Yahoo! is participating in order to help prepare our services (as well as your hardware) to help ensure a smooth transition for when the IPv4 addresses run out. "

Huh… I thought IPv4 addresses had run out already….

At IANA level and now for anyone in the AP region at least.

IANA is out of IPv4. APNIC is into their austerity policy which covers their entire last /8. RIPE-NCC is probably next and I expect they will likely run out next month. I suspect ARIN's free pool will probably last until October-ish, give or take.

LACNIC and AfriNIC are kind of wildcards. If consumption remains within their regions, they probably have addresses for some time.

If organizations from the other regions start pillaging their address space, it could evaporate in weeks, depending on how they react.

It'd certainly be interesting to watch and see how many things that might be in the APNIC region are actually getting ARIN assignments over the next few weeks/months. Matthew Kaufman