Re: [DNSOP] FYI: DNSOPS presentation
Le 2 avr. 2010 à 07:54, Igor Gashinsky a écrit : I, for one, get pretty damn pissed when my vendors roll out new features (most of which I could care less about) while breaking existing things that I use -- I tend to not deploy those things into production. That's precisely the reason why it *must not* become a rule that DNS servers would everywhere refuse to respond s when queried in IPv4. This is in use today and works well. So, why is it that we think that our users are any different? Remember, to them IPv6 is meaningless, they just want the web to work. Fortunately, there is already at least one large ISP whose users who have IPv6 enabled ignore in general whether they work in IPv4 or IPv6, and don't suffer from IPv6 being enabled. There should therefore be a solution to your problem. So, we are absolutely going to need to fix the underlying problems to make sure that things are not going to get worse and to make sure that they can get better over time (some of that is under way now). The first thing to do is to understand why some operators have problems with IPv6, or anticipate to have such problems, while some others haven't. This is why we are going to have whitelists, and, on top of whitelists, we are going to need other measures to drop those numbers significantly (like filter-, or anything better that people come up with) in order to get more ipv6 adoption (by several orders of magnitude).. A suggestion could be that ISPs start with sending s *only* to sites to which they provide native IPv6. These sites shouldn't have problems, as the experience acquired by Free has shown. If these sites can be recognized with some specific IPv4 prefixes, distinguishing them would be much easier than with a white list containing individual addresses. Note that Free didn't need to recognize these sites, because in its case *all* customers have Free's CPEs, and these CPEs offer native IPv6 prefixes if IPv6 is activated. (In Free's case, these prefixes are statelessly derived from IPv4 addresses with 6rd, which makes it particularly easy to deploy). Thought? Regards, RD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
Hi Igor, * Igor Gashinsky First of all, I'd like to say thank you for this data, it is *extremely* useful! So, we now that we have 2 different tests that show the same ballpark of breakage. Some questions in-line... I'm glad you find it interesting! One question on this awesome data -- if the browser gets , hangs on connecting to it, then goes into a time-out retry state, gets the A, and hits the site over ipv4, say, 75 seconds later, does your method still concider that connect successfull, or have you controlled for that via time-outs in javascript or something? If you concider that to be successful, do you have any way of re-doing the calculation to say if it took you longer then 10 seconds to connect, you are also broken? There's no timeout with the current numbers, no. The methology is as follows (I've anonymised the hostnames to prevent spiders and such from skewing my results): - There's a (hidden) IFRAME with src=http://exp.foo.no/linkgen.php in the HTML of the web site the end user is visiting. - The linkgen.php script spits out two IMG links: a) http://ds.foo.no/1x1,png?uuid=random:unixtimesrc=v4 src addr b) http://v4.foo.no/1x1.png?uuid=random:unixtimesrc=v4 src addr The ordering of the links in the generated HTML is random. - All of the hostnames mentioned point to different IPv4 addresses, and the ds one to a IPv6 address also. However they're all found on the same test server, served by the same Apache process. (There's only one copy of 1x1.png on the sever.) - The DNS TTL for all hostnames are 5 seconds. So basically what I do is to parse the logs, and count the following (numbers in parenthesis are from yesterday, April 1st): * N - number of hits to linkgen.php 1986244 * Ns - number of hits to 1x1.png via the v4 virtual host 1971340 * Nd - number of hits to 1x1.png via the ds virtual host 1970605 = Client loss: 100 / N * (Ns - Nd) 0.037% There's no timeout of any sort, the only hits I discard are duplicates, that is any 1x1.png request that comes in with an UUID I've already seen on that virtual host. But it would absolutesly be interesting to see how a timeout would affect the numbers, thanks for the suggestion! Since the time when the linkgen script ran in is embedded in the 1x1.png link, that was trivial to implement, and I've just run the numbers for March with a timeout of ten seconds, like you suggested. Results for VG: - Overall client loss: 0.122% - With Opera 10.50 on Windows and Mac OS X excluded: 0.015% - IOW, Opera/Mac OS X accounts for 88.056% of the client loss. So the root cause is for client loss is still overwhelmingly unnecessary use of transitional IPv6 connectivity. I will attempt to look more into the set of hits that arrive more than 10 seconds late on the dualstack host to see if I can uncover any other sources of client loss there, other than the ones I already know about. By the way, it would be fantastic if you/Yahoo would (in addition to pursuing the proposed DNS solution) help make an effort to help get rid off the known problems, by for example talking to Apple about their getaddrinfo() implementation, and warning users with old versions of Opera to upgrade - at least if you measure bad IPv6 connectivity from them. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
Le 2 avr. 2010 à 00:38, Mark Andrews a écrit : Indeed, providing end users with native IPv6 will make the problematic transitional techniques obsolete. However, this is not something that content providers such as Yahoo or myself have much influence over. At least, they should: - get native IPv6 addresses - make sure they advertise both a native-IPv6 and 6to4 addresses. They shouldn't need a 6to4 address. They should however configure the exit routers to gateway the 6to4 destined traffic onto IPv4. What you propose: - does guarantee a good path from Yahoo servers to 6to4 clients, you are right - but doesn't guarantee a good path from 6to4 clients to Yahoo servers = it is not sufficient. Without Yahoo 6to4 routers operated by Yahoo, paths from 6to4 clients depend on a 6to4 Relay Router being reachable from them, which is not guaranteed. On the contrary, by operating its own 6to4 Routers (and embedding their IPv4 address in Yahoo-server 6to4 addresses), IPv6 packets always go directly from 6to4-client sites to Yahoo-server sites (encapsulated in IPv4 from client 6to4 router to Yahoo 6to4 router), i.e. without depending on any Relay Router. ISP's, in general, should be providing 6to4 gateways even if they are not offering IPv6 native to their customers. They MAY not do it, though (taking obviously gateways as meaning, in RFC 3056 and RFC 3964 terminology, Relay Routers) Reality is that 6to4 guarantees connectivity *between two 6to4 sites* (in RFC 3056, the Simple scenario of section 5.1), but not between 6to4 sites and native-IPv6 sites (the Mixed scenario of section 5.2). Note that RFC 3964 says about Security Considerations for 6to4 (emphasis added): There are mainly four classes of potential problem sources: 1. 6to4 routers not being able to identify whether RELAYS are legitimate ... The first is the TOUGHEST PROBLEM, still UNDER RESEARCH. While CPE equipment that supports IPv6 is still hard to get, there really is no excuse for ISP's to not be doing this any longer. Reasons ISPs may have for not providing 6to4 Relay Routers include: - Relay Routers encourage use of 6to4 in scenarios others than those where connectivity is guaranteed, which is bad for IPv6 in general - An ISP 6to4 Relay Router can be used for traffic that concerns none of its customers. - The wish to not depend on a subject under research (the RFC 3964 quotation above). They are all IMHO legitimate. I hope this helps to understand that there are precautions that CAN be taken, and that, this being done, the FUD about IPv6 in general may dissipate faster. Regards, RD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
