Re: [DNSOP] Ugly DNS ack
On Apr 19, 2010, at 11:02 AM, Edward Lewis wrote: But the problem with IPv6 connectivity testing is that the granularity (needed for tailoring) is not very consistent. While I somewhat entertained this whole idea at first, that's the conclusion I came to. I think there are too many corner cases where determining whether the client system making the original query has v6 connectivity or not is just not possible. That's not the only issue with this idea but I think a significant one. -b ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
Jason Livingood wrote: This thread seems to have died out. As I already summarized, the problem is that: The problem is lack of support of TCP/IP for hosts with multiple addresses. Its scope is not limited to IPv6 nor HTTP but TCP/IP in general. A host with two IPv4 addresses also suffers, when one of its addresses is sometimes unreachable from its peer. and the short and long term approaches to the solution are: that The solution can be properly constructed not at the connectionless IP layer but at the lowest layer above IP to support connection, which means TCP needs a major revision. Or, you can say SCTP, though it may also need a major revision to be really usable against the problem. and that When almost all hosts have single IPv4 addresses (and single IPv6 addresses), the most practical tentative solution is not to deploy IPv6. Long term solutions need drastic changes on treatment of multihomed ISPs and address allocation policies, which also excludes, with RFC2374 obsoleted, IPv6. That's all. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
This thread seems to have died out. But I will note that it appears to be on the agenda at the upcoming ISOC IPv6 workshop (from 16:30 - 18:00 - see https://www.isoc.org/isoc/conferences/registration/index.php?id=7ce20e4c88b7 e328). It is also addressed in a short whitepaper some colleagues and I put together in advance of that meeting (available at http://www.comcast6.net/IPv6_DNS_Whitelisting_Concerns_20100416.pdf) Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
At 12:28 -0400 4/19/10, Jason Livingood wrote: This thread seems to have died out. But I will note that it appears to be on the agenda at the upcoming ISOC IPv6 workshop (from 16:30 - 18:00 - see https://www.isoc.org/isoc/conferences/registration/index.php?id=7ce20e4c88b7 e328). It is also addressed in a short whitepaper some colleagues and I put together in advance of that meeting (available at http://www.comcast6.net/IPv6_DNS_Whitelisting_Concerns_20100416.pdf) After reading the white paper I can think of a lot of things to say, but not much related to DNS operations. What comes to mind is something that could make use of this proposal: http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-00 That is not a savior here, I don't propose it to be. What I wanted to point out is that while that proposal is talking about conveying addressing information in support of tailoring answers, the white paper is talking about the design of the tailoring. In some cases, responses can be tailored according to a simple design - all addresses in North America get these servers, in Europe those servers, in Asia those servers, and so on. But the problem with IPv6 connectivity testing is that the granularity (needed for tailoring) is not very consistent. It depends on whether the matter is that an entire /LIR's with of addresses can't be reached from the provider or just those clients using 6to4 or just a particular client behind a cable modem still running from June 1942. I used to think the problem was how to get around discontinuous IPv6 routing when I have a local global address. Now it seems like it's a problem of scattered and varied (to use the same ill-defined word) brokenness sprinkled all over the place. What's this got to do with DNS operations? I can't see...how the DNS can really be of help in this matter. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? ___ 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
Re: [DNSOP] Ugly DNS ack
I wanted to clarify a couple things on this thread. Our concern is more than just os issues. Many apps today already ask for A/. The bigger issue to me is related to when the host tries connecting to the IPv6 address, using a route that exists but is either broken or suffers serious performance problems. Users see that as Site Down. The percentage is high [see #1]; our business people would never let us deploy IPv6 unless we can mitigate it by things like selectively enabling IPv6 towards specific operators and end users that appear to have IPv6 for real. Re: getting clients to use and prefer IPv6 resolvers: this issue is not lost on us. Today, we don't have a clear solution on this issue that works for everyone.However, the access providers we talked to seemed to think this would become a resolvable issue (no pun intended). This may be via access provider specific means, or perhaps standards updates (and product updates) have happen by the time IPv6 gains significance on the internet. As to when the filter- hack works, there are very limited conditions: 1: Extra build option for the resolver. Not compiled by default. 2: Enabled in the configuration. By default, disabled. 3: Query is for . 4: Query arrived from client via INET, not INET6. 5: Results have both A and . Perform an A lookup if needed to satisfy this request. 6: Results are not signed. IPv6 only web sites, will still return the . Any site that is DNSSEC signed, will return results *unaltered*. We don't want to see DNSSEC broken. Yes, there is a filter- break-dnssec; option. We see it being useful in very limited cases (enterprise or lab networks where V6 routes might exist, but not public connected yet). It is just a tool; shoot your foot at your own risk. When DNSSEC is involved, we absolutely do not want to break any trust (or functionality). I look forward to the day when the majority of users are protected by DNSSEC. Hope this helps, -jfesler [#1] http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Colitti-IPv6atGoogle-RIPE58.pdf publicly shows this as 0.1%. Thanks, Lorenzo. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
On Wed, 31 Mar 2010, Jason Fesler wrote: I wanted to clarify a couple things on this thread. Our concern is more than just os issues. Many apps today already ask for A/. The bigger issue to me is related to when the host tries connecting to the IPv6 address, using a route that exists but is either broken or suffers serious performance problems. Users see that as Site Down. The percentage is high [see #1]; our business people would never let us deploy IPv6 unless we can mitigate it by things like selectively enabling IPv6 towards specific operators and end users that appear to have IPv6 for real. Re: getting clients to use and prefer IPv6 resolvers: this issue is not lost on us. Today, we don't have a clear solution on this issue that works for everyone.However, the access providers we talked to seemed to think this would become a resolvable issue (no pun intended). This may be via access provider specific means, or perhaps standards updates (and product updates) have happen by the time IPv6 gains significance on the internet. As to when the filter- hack works, there are very limited conditions: 1: Extra build option for the resolver. Not compiled by default. 2: Enabled in the configuration. By default, disabled. 3: Query is for . 4: Query arrived from client via INET, not INET6. 5: Results have both A and . Perform an A lookup if needed to satisfy this request. 6: Results are not signed. IPv6 only web sites, will still return the . Any site that is DNSSEC signed, will return results *unaltered*. We don't want to see DNSSEC broken. Yes, there is a filter- break-dnssec; option. We see it being useful in very limited cases (enterprise or lab networks where V6 routes might exist, but not public connected yet). It is just a tool; shoot your foot at your own risk. When DNSSEC is involved, we absolutely do not want to break any trust (or functionality). I look forward to the day when the majority of users are protected by DNSSEC. Hope this helps, -jfesler [#1] http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Colitti-IPv6atGoogle-RIPE58.pdf publicly shows this as 0.1%. Thanks, Lorenzo. I still cannot see, how can you assses the quality of IPv6 connectivity of someone, based on a DNS query. DNS queries mostly are coming from the ISP public DNS servers. They are nothing to do with IPv6 connectivity of the end-users. Will it be effective? Best Regards, Janos Mohacsi ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
The intention is not signal the recursive name server to use a specific transport with authoritative name servers. The intention is to use the transport to determine how the recursive name server responds to the original query. On 4/1/10 1:41 AM, Patrick W. Gilmore patr...@ianai.net wrote: On Apr 1, 2010, at 12:29 AM, John Jason Brzozowski wrote: Not necessarily, if a dual stack hosts communicates with a recursive name server over both IPv4 and IPv6 and other conditions are met then I believe it would be fine based on what was presented. What other conditions need to be met? I did not think there was any way for a host to signal a recursive NS to use v6 or v4 transport. -- TTFN, patrick On 3/31/10 5:12 PM, John Payne j...@sackheads.org wrote: On Mar 31, 2010, at 3:19 PM, Dan Wing wrote: Any host that sends its queries over IPv4 would lose IPv6 connectivity. Isn't this a misdirection? I suspect it's more like: any (address family agnostic) clients of a dual stacked nameserver will (non?) deterministically lose IPv6 connectivity to DNS-determined destinations. ie, even if I only send DNS over IPv6 to my recursive nameserver, if it is dual stacked (often beyond my control), and for this specific query it prefers IPv4, then I will not get an answer for my under this proposal. = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
I think you missed something slightly. Based on the proposal the connectivity to the recursive name server from the client is being leveraged as *partial* indicator, not the connectivity from the recursive name server to the authoritative name server(s). John On 4/1/10 6:41 AM, Mohacsi Janos moha...@niif.hu wrote: On Wed, 31 Mar 2010, Jason Fesler wrote: I wanted to clarify a couple things on this thread. Our concern is more than just os issues. Many apps today already ask for A/. The bigger issue to me is related to when the host tries connecting to the IPv6 address, using a route that exists but is either broken or suffers serious performance problems. Users see that as Site Down. The percentage is high [see #1]; our business people would never let us deploy IPv6 unless we can mitigate it by things like selectively enabling IPv6 towards specific operators and end users that appear to have IPv6 for real. Re: getting clients to use and prefer IPv6 resolvers: this issue is not lost on us. Today, we don't have a clear solution on this issue that works for everyone.However, the access providers we talked to seemed to think this would become a resolvable issue (no pun intended). This may be via access provider specific means, or perhaps standards updates (and product updates) have happen by the time IPv6 gains significance on the internet. As to when the filter- hack works, there are very limited conditions: 1: Extra build option for the resolver. Not compiled by default. 2: Enabled in the configuration. By default, disabled. 3: Query is for . 4: Query arrived from client via INET, not INET6. 5: Results have both A and . Perform an A lookup if needed to satisfy this request. 6: Results are not signed. IPv6 only web sites, will still return the . Any site that is DNSSEC signed, will return results *unaltered*. We don't want to see DNSSEC broken. Yes, there is a filter- break-dnssec; option. We see it being useful in very limited cases (enterprise or lab networks where V6 routes might exist, but not public connected yet). It is just a tool; shoot your foot at your own risk. When DNSSEC is involved, we absolutely do not want to break any trust (or functionality). I look forward to the day when the majority of users are protected by DNSSEC. Hope this helps, -jfesler [#1] http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Colitti-IPv6a tGoogle-RIPE58.pdf publicly shows this as 0.1%. Thanks, Lorenzo. I still cannot see, how can you assses the quality of IPv6 connectivity of someone, based on a DNS query. DNS queries mostly are coming from the ISP public DNS servers. They are nothing to do with IPv6 connectivity of the end-users. Will it be effective? Best Regards, Janos Mohacsi = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
John, Thanks for the detailed reaction. Further comments below. Le 31 mars 2010 à 19:38, John Jason Brzozowski a écrit : I hope you do not mind, I have take the liberty to pull some text from your original post [rd] No problem at all. and will reply to them here: On 3/31/10 10:20 AM, Rémi Després remi.desp...@free.fr wrote: ... = If there are indeed OS bugs that break connectivity, they should justify quick patches like those that concern security. [jjmb] anyone who has had to deal with releasing software can certainly attest to the fact that these sort of fixes/enhancements may not occur in a timely manner. [rd] Aren't security patches quickly dispatched? Wouldn't a modification of all recursive DNS servers be an even more difficult task? There are things we need to be doing now to advance IPv6, the ability to wait for a release is not always an option. I do agree that the issues should be properly documented in fact, [rd] Yes. That's the key. I fully expect to contribute to the work and share data from my point of view. [rd] Agreeing on what is the proper behavior OF HOSTS is IMHO most urgent, for the remainder of the discussion to start on solid grounds. Observed broken IPv6 connectivities shouldn't exist between communicating hosts (clients and/or servers) that apply these NATURAL RULES: a) Send packets to an IPv6 public address only from a public IPv6 source address. Otherwise, the return path will be broken. b) Send IPv6 packets from a 6to4 address only to destinations that are also a 6to4 addresses. Otherwise, return paths may be inexistent. c) By default, send IPv6 packets that don't exceed the guaranteed PMTU in IPv6, i.e. 1280 octets. Otherwise, some packets may be systematically discarded on their way because of their size. (Note that TCP/IP stacks that can determine than larger PMTUs exist on some identified e2e paths, by PMTUD or otherwise, may send larger packets on these paths, but this is far more sophisticated, and can remain optional.) ... = As a minimum, what the problem really is should be documented before proposing to adopt any solution to solve it, in particular if it is ugly. [jjmb] some of us have been gathering data and have experiences that are insightful. I believe the intention here minimally is to document the same so the community can review and comment. I do not believe there is a large population of people that have attempted these sort of activities in scale, I can assure that scale does matter. [rd] Agreed: scale does matter, and documenting observed facts is very precious. I look forward to what you have gathered. 3. Only way of knowing the user has working IPv6 connectivity, is if the query came over IPv6! = This DOESN'T WORK : - Today, dual-stack hosts on Free's network query Free's DNS in IPv4 (at the only DNS address they know, received in DHCPv4) - These hosts, because they have valid IPv6 addresses (i.e. have IPv6 enabled), ask for both As and s. - For maps.google.fr, for example, BOTH types of RRs are in the DNS. - They are included in DNS responses - Hosts then use IPv6 (preferred in case of choice). [jjmb] it is not perfect but it is an indicator. The hosts on the Free network are clearly not fully dual stack capable, if they were the transport could be used as an indicator of IPv6 reachability. [rd] - My host has OS X, which makes it IPv6 capable. Since it gets a native IPv6 address (with the IPv6 prefix it receives from Free's CPE), it becomes IPv6 enabled. As it also works in IPv4 as usual, it is AFAIKT fully dual stack. - Note that, so far, the dual-stack model keeps the DNS application layer independent from the IP layer, so that DNS servers may provide both As and s even if reached in IPv4. Changing this as would be a step backward. Return 0 answers for if, and only if: - Query comes over Ipv4; - “A” record exists for same name; - DNSSEC is not used. = This hack would NOT ONLY be ugly (as acknowledged by their proponents), BUT ALSO would BREAK some of the IPv6 connectivities that are available today !!! [jjmb] I do not see how this would break IPv6 connectivity. [rd] As I said, dual-stack hosts on Free's network query Free's DNS in IPv4 (at the only DNS address they know, received in DHCPv4). The DNS server returns available addresses, IPv4 and/or IPv6. This has worked satisfactorily for more than two years, and is used extensively, in particular to reach Google and IETF servers. If Free's DNS server would stop returning IPv6 addresses, as proposed in the hack being discussed, its dual-stack hosts would no longer reach Google and IETF in IPv6. I can tell you from first hand experience over the past several months there are some enigmas here and that issues with 6to4 and other transition technologies present challenges to readying infrastructure for real broadband IPv6 traffic. [rd] Being a long time user of IPv6, and having at
Re: [DNSOP] Ugly DNS ack
Hi Rémi, * Rémi Després = If there are indeed OS bugs that break connectivity, they should justify quick patches like those that concern security. I think this is wishful thinking, unfortunately. For example, the 30th of October last year I reported an IPv6-related bug in the Opera web browser. After a considerable amount of nagging and pestering, even on their public user forums, a fixed version was finally released on the 2nd of March this year. That was a new major version. IPv6-related issues did not appear to be a priority for them, and it certainly seemed out of the question to back-port the fix to the older maintenance-only branches. I don't expect other vendors to behave much differently. And even if vendors would fix bugs rapidly in new releases, there's still the issue of making end users upgrade to them. Now a month has passed since the Opera bug was fixed, but it continues to be a major cause of client loss. Gashinsky adds that Yahoo is conducting its own analysis of broken IPv6 connectivity, which it will share with the Internet engineering community in June. = As a minimum, what the problem really is should be documented before proposing to adopt any solution to solve it, in particular if it is ugly. It would certainly be useful to see the conclusions from Yahoo's measurements - if we know what actually causes the client loss, we might try to fix the actual problems instead of working around it with DNS magic. To that end, I've been running my own measurement for quite some time now. It's very regional in scope (Norwegian end users mostly), so it is very likely that Yahoo, with their global audience, are observing problems that I do not, but I'll try to make a summary of my conclusions from March: - Total client loss to the dualstacked host is at 0.074%. - (At least) 95% of the client loss is due to clients choosing to use inherently unreliable transitional IPv6 (6to4/Teredo) instead of IPv4. - I've identifed three groups of clients that behave in this way: 1) Users of Opera 10.50, which did not use the RFC 3484-compliant getaddrinfo() call, at least on Windows. It would prefer any form of IPv6 connectivity above IPv4. This is especially a problem on Windows Vista and 7, where 6to4 and/or Teredo are enabled by default. This accounts for about half of the 95%. 2) Dualstacked Mac OS X users with RFC 1918 IPv4 addresses (using NAT) and transitional IPv6 addresses. In this case, getaddrinfo() will sort the IPv6 address above the IPv4 address, causing the transitional connectivity to be used. This accounts for the other half of the 95%. 3) Dualstacked Linux users with RFC 1918 IPv4 addresses and transitional IPv6 addresses, as GNU libc's getaddrinfo() implementation behaves exactly like the one in Mac OS X. However, the overall client loss caused by this is miniscule compared to #1 and #2 (I have problems measuring any at all). - When disregarding all hits from users in problem groups #1 and #2, the total client loss is at 0.003% - this is, in my opinion, low enough to accept. (Of course, other content providers might feel differently.) I've informed the vendors in question about the problems (and I understand others have too, before me). While the Opera issue is already fixed, the other two reports are here: http://lists.apple.com/archives/Ipv6-dev/2010/Mar/msg3.html http://sourceware.org/bugzilla/show_bug.cgi?id=11438 In the first case, there's no responses from anyone posting from @apple.com, in the second case, there's no response at all. If the vendors are considering IPv6 issues a priority, they're not telling. You can read my entire March report here: http://lists.cluenet.de/pipermail/ipv6-ops/2010-April/003272.html Only way of knowing the user has working IPv6 connectivity, is if the query came over IPv6! = This DOESN'T WORK : I agree, not in all cases at least. Your example of IPv6-capable clients using IPv4 for its DNS queries is one valid case, another would be when the clients' end stations are not querying the ISPs recursive resolvers directly, but instead a (caching) DNS forwarder embedded in their CPE/SOHO device. This kind of setup is very common here in Norway. There's no guarantee that the DNS forwarder will use the same IP version as the client did when forwarding the query to the ISP's recursive resolver - which could either cause a broken end station to see the records, or vice verca, that a IPv6 capable end station will only be presented with A records. The best way to know if the user has working IPv6 connectivity is to actually test it as he's visiting a IPv4-only web site. A few days ago I made a attempt of making such a test, inspired by the so-called «Norwegian IE6 Spring Cleaning», you can try it here: http://ajaxtest.fud.no/test.php It's only partially working, but then again I have no real skills when it comes to web
Re: [DNSOP] Ugly DNS ack
Tore, Many thanks for the detailed information you disclose. Further comments below. Le 1 avr. 2010 à 15:42, Tore Anderson a écrit : It would certainly be useful to see the conclusions from Yahoo's measurements - if we know what actually causes the client loss, we might try to fix the actual problems instead of working around it with DNS magic. To that end, I've been running my own measurement for quite some time now. It's very regional in scope (Norwegian end users mostly), so it is very likely that Yahoo, with their global audience, are observing problems that I do not, but I'll try to make a summary of my conclusions from March: - Total client loss to the dualstacked host is at 0.074%. - (At least) 95% of the client loss is due to clients choosing to use inherently unreliable transitional IPv6 (6to4/Teredo) instead of IPv4. - I've identifed three groups of clients that behave in this way: 1) Users of Opera 10.50, which did not use the RFC 3484-compliant getaddrinfo() call, at least on Windows. It would prefer any form of IPv6 connectivity above IPv4. This is especially a problem on Windows Vista and 7, where 6to4 and/or Teredo are enabled by default. This accounts for about half of the 95%. 2) Dualstacked Mac OS X users with RFC 1918 IPv4 addresses (using NAT) and transitional IPv6 addresses. In this case, getaddrinfo() will sort the IPv6 address above the IPv4 address, causing the transitional connectivity to be used. This accounts for the other half of the 95%. 3) Dualstacked Linux users with RFC 1918 IPv4 addresses and transitional IPv6 addresses, as GNU libc's getaddrinfo() implementation behaves exactly like the one in Mac OS X. However, the overall client loss caused by this is miniscule compared to #1 and #2 (I have problems measuring any at all). - When disregarding all hits from users in problem groups #1 and #2, the total client loss is at 0.003% - this is, in my opinion, low enough to accept. (Of course, other content providers might feel differently.) These 95%+ problems, being related to 6to4 and Teredo, don't concern ISPs that offer native IPv6 addresses (independently from whether they offer them with 6rd, like Free did in 2007, or otherwise). Note that this is consistent with Free's users not encountering such problems. Would you have some information about the 5%- remaining losses? Only way of knowing the user has working IPv6 connectivity, is if the query came over IPv6! = This DOESN'T WORK : I agree, not in all cases at least. A way of knowing that doesn't work all the time is not a real way of knowing, right? If and when the mentioned OS problems are documented, it will be possible to fix them with patches in OSes, where they belong. In that regard I hope you have found my measurements useful. I did, and thanks again. To the Yahoo people: The sooner we know what the problems are, the sooner we can start to fix them. Could you provide us with some preliminary results from your measurements before June? +1 Regards, RD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
Hi again, * Rémi Després These 95%+ problems, being related to 6to4 and Teredo, don't concern ISPs that offer native IPv6 addresses (independently from whether they offer them with 6rd, like Free did in 2007, or otherwise). Note that this is consistent with Free's users not encountering such problems. 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. We can (and obviously want to!) dual-stack our content, but as the end-users can still reach it over IPv4 just as well, even if we did is not a big incentive for end-users ISPs to get their IPv6 deployment going. I'm hoping it's a small one, though. I applaud Free and yourself, if all ISPs were as progressive as you've been, we'd have very few problems. Would you have some information about the 5%- remaining losses? I haven't been able pinpoint any common denominator(s). I have some ideas, but it's mostly speculation. In no particular order: 1) Higher latency with IPv6, less developed peerings, etc. If a client navigates away from the test page exactly when the IPv4 PNG has loaded, but while the IPv6 request is for instance 50ms away from completion, he will be (falsely) counted as a lost client. 2) Linux clients with 6to4/RFC 1918 as described in my previous message. 3) Users with CPEs/SOHO routers that do evil things to DNS responses containing records. 4) Tunnels (HE, SixXS, etc.) that the user configured and forgot about, and that broke at some point for some reason (like his IPv4 address changed). 5) Software that (like Opera did earlier) does not behave according to RFC 3484 and prefers transitional/any IPv6 connectivity over IPv4. In any case it's hard to determine it accurately. Also I think I'm approaching the statistical margin of error (on some days the client loss measurement turns out negative). Oh, and by the way - #3 in the list over could conceivably be a big problem for Yahoo or other global players, since there could be huge geographical differences. For instance, if an ISP in some other country far away from here distributes have distributed a CPE to all its subscribers that breaks responses, it would hardly be noticable for me. But again, that is pure speculation. I'll be sure to let you know if I do discover more problems, though. A way of knowing that doesn't work all the time is not a real way of knowing, right? I'd call it a heuristic estimation or something like that. 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
In message 8b34241d-66cc-4622-93c1-cdb5e7f00...@free.fr, =?iso-8859-1?Q?R=E9m i_Despr=E9s?= writes: Le 1 avr. 2010 =E0 17:31, Tore Anderson a =E9crit : Hi again, = * R=E9mi Despr=E9s = These 95%+ problems, being related to 6to4 and Teredo, don't concern ISPs that offer native IPv6 addresses (independently from whether they offer them with 6rd, like Free did in 2007, or otherwise). Note that this is consistent with Free's users not encountering such problems. = 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. ISP's, in general, should be providing 6to4 gateways even if they are not offering IPv6 native to their customers. 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. You only need to advertise the route internally. This distributes the load and gets optimal routing for their customers that are using 6to4. - transmit IPv6 packets not exceeding 1280 octets. Note also that the proposed hack, which is in ISP DNS servers, in not more = in Yahoo's hands. Would you have some information about the 5%- remaining losses? = I haven't been able pinpoint any common denominator(s). I have some ideas, but it's mostly speculation. In no particular order: = 1) Higher latency with IPv6, less developed peerings, etc. If a client navigates away from the test page exactly when the IPv4 PNG has loaded, but while the IPv6 request is for instance 50ms away from completion, he will be (falsely) counted as a lost client. 2) Linux clients with 6to4/RFC 1918 as described in my previous message. 3) Users with CPEs/SOHO routers that do evil things to DNS responses containing records. 4) Tunnels (HE, SixXS, etc.) that the user configured and forgot about, and that broke at some point for some reason (like his IPv4 address changed). 5) Software that (like Opera did earlier) does not behave according to RFC 3484 and prefers transitional/any IPv6 connectivity over IPv4. = In any case it's hard to determine it accurately. Also I think I'm approaching the statistical margin of error (on some days the client loss measurement turns out negative). Thanks, I will think about these. Oh, and by the way - #3 in the list over could conceivably be a big problem for Yahoo or other global players, since there could be huge geographical differences. For instance, if an ISP in some other country far away from here distributes have distributed a CPE to all its subscribers that breaks responses, it would hardly be noticable for me. But again, that is pure speculation. = I'll be sure to let you know if I do discover more problems, though. Thanks. A way of knowing that doesn't work all the time is not a real way of knowing, right? = I'd call it a heuristic estimation or something like that. Right, and to increase operational costs, nothing is better than heuristics= , especially if they are supposed to solve ill identified problems, and are= known to create new ones for sure! Regards, RD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
Tore, 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... On Thu, 1 Apr 2010, Tore Anderson wrote: :: To that end, I've been running my own measurement for quite some time :: now. It's very regional in scope (Norwegian end users mostly), so it is :: very likely that Yahoo, with their global audience, are observing :: problems that I do not, but I'll try to make a summary of my conclusions :: from March: :: :: - Total client loss to the dualstacked host is at 0.074%. :: - (At least) 95% of the client loss is due to clients choosing to use :: inherently unreliable transitional IPv6 (6to4/Teredo) instead of IPv4. :: - I've identifed three groups of clients that behave in this way: :: 1) Users of Opera 10.50, which did not use the RFC 3484-compliant :: getaddrinfo() call, at least on Windows. It would prefer any form :: of IPv6 connectivity above IPv4. This is especially a problem on :: Windows Vista and 7, where 6to4 and/or Teredo are enabled by :: default. This accounts for about half of the 95%. :: 2) Dualstacked Mac OS X users with RFC 1918 IPv4 addresses (using :: NAT) and transitional IPv6 addresses. In this case, getaddrinfo() :: will sort the IPv6 address above the IPv4 address, causing the :: transitional connectivity to be used. This accounts for the other :: half of the 95%. :: 3) Dualstacked Linux users with RFC 1918 IPv4 addresses and :: transitional IPv6 addresses, as GNU libc's getaddrinfo() :: implementation behaves exactly like the one in Mac OS X. However, :: the overall client loss caused by this is miniscule compared to :: #1 and #2 (I have problems measuring any at all). 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? :: - When disregarding all hits from users in problem groups #1 and #2, :: the total client loss is at 0.003% - this is, in my opinion, low :: enough to accept. (Of course, other content providers might feel :: differently.) Honestly, I'd prefer the loss to be 0.001% to be comfortable with it, but I have a feeling that you are right, and 0.003% will have to be sufficient, provided that those numbers include the unacceptable latency people. :: In that regard I hope you have found my measurements useful. To the :: Yahoo people: The sooner we know what the problems are, the sooner we :: can start to fix them. Could you provide us with some preliminary :: results from your measurements before June? When we have some preliminary data to share, we will absolutely do so.. Thank you again for your data, extremely useful! -igor ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
Le 31 mars 2010 à 17:43, Ted Lemon a écrit : On Mar 31, 2010, at 8:32 AM, Rémi Després wrote: == This hack MUST therefore be flatly rejected. Unfortunately we don't have any control over what Yahoo or Google do to their name servers. I agree with you completely on what we SHOULD do, but if Igor decides to filter s on IPv4 queries, we can't stop him. Sure, and that's fair. But it has to remains his problem, not an IETF specification problem. We can refuse to endorse his solution, but really what's going on here is that Igor (and Google before him) have come to us in good faith to tell us about hacks they've done that they feel are necessary. We shouldn't discourage them from doing that, Agreed. My strong reaction is only against this particular hack because: - it is based on the idea that OSes cannot be patched where they are bugged - it destroys legitimate connectivity for OSes that aren't bugged. even if we do discourage them from doing the hacks. So to my mind, the question is whether or not we want to (and can!) have some say in what these hacks look like, We do want it. (That's what I did in the technical explanation.) not whether or not we should forbid them. Flatly rejecting the hack, as I proposed, doesn't mean forbidding it. (Vendor makes its own choices anyway.) It just means, in my understanding, a clear refusal to endorse it. Regards, RD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
Remi, I hope you do not mind, I have take the liberty to pull some text from your original post and will reply to them here: On 3/31/10 10:20 AM, Rémi Després remi.desp...@free.fr wrote: 1. Yahoo's worry is that some operating systems issue quad-A records by default, even if the user has broken IPv6 connectivity and needs single A records to access IPv4-based content. Work with OS/app vendors to fix IPv6 issues Awful long lead times/upgrade cycles This is a really ugly hack, but it may be necessary to get widespread IPv6 adoption, = If there are indeed OS bugs that break connectivity, they should justify quick patches like those that concern security. [jjmb] anyone who has had to deal with releasing software can certainly attest to the fact that these sort of fixes/enhancements may not occur in a timely manner. There are things we need to be doing now to advance IPv6, the ability to wait for a release is not always an option. I do agree that the issues should be properly documented in fact, I fully expect to contribute to the work and share data from my point of view. 2. Gashinsky adds that Yahoo is conducting its own analysis of broken IPv6 connectivity, which it will share with the Internet engineering community in June. = As a minimum, what the problem really is should be documented before proposing to adopt any solution to solve it, in particular if it is ugly. [jjmb] some of us have been gathering data and have experiences that are insightful. I believe the intention here minimally is to document the same so the community can review and comment. I do not believe there is a large population of people that have attempted these sort of activities in scale, I can assure that scale does matter. 3. Only way of knowing the user has working IPv6 connectivity, is if the query came over IPv6! = This DOESN'T WORK : - Today, dual-stack hosts on Free's network query Free's DNS in IPv4 (at the only DNS address they know, received in DHCPv4) - These hosts, because they have valid IPv6 addresses (i.e. have IPv6 enabled), ask for both As and s. - For maps.google.fr, for example, BOTH types of RRs are in the DNS. - They are included in DNS responses - Hosts then use IPv6 (preferred in case of choice). [jjmb] it is not perfect but it is an indicator. The hosts on the Free network are clearly not fully dual stack capable, if they were the transport could be used as an indicator of IPv6 reachability. 4. Return 0 answers for if, and only if: - Query comes over Ipv4; - ³A² record exists for same name; - DNSSEC is not used. = This hack would NOT ONLY be ugly (as acknowledged by their proponents), BUT ALSO would BREAK some of the IPv6 connectivities that are available today !!! [jjmb] I do not see how this would break IPv6 connectivity. I do agree that there will likely be an impact to DNSSEC. == This hack MUST therefore be flatly rejected. [jjmb] I see a number of people agree that this should be rejected. I can tell you from first hand experience over the past several months there are some enigmas here and that issues with 6to4 and other transition technologies present challenges to readying infrastructure for real broadband IPv6 traffic. And these challenges are likely not temporary. I suggest deferring rejection until the issues, challenges, and documentation have been documented. If and when the mentioned OS problems are documented, it will be possible to fix them with patches in OSes, where they belong. Le 31 mars 2010 à 17:43, Ted Lemon a écrit : On Mar 31, 2010, at 8:32 AM, Rémi Després wrote: == This hack MUST therefore be flatly rejected. Unfortunately we don't have any control over what Yahoo or Google do to their name servers. I agree with you completely on what we SHOULD do, but if Igor decides to filter s on IPv4 queries, we can't stop him. Sure, and that's fair. But it has to remains his problem, not an IETF specification problem. We can refuse to endorse his solution, but really what's going on here is that Igor (and Google before him) have come to us in good faith to tell us about hacks they've done that they feel are necessary. We shouldn't discourage them from doing that, Agreed. My strong reaction is only against this particular hack because: - it is based on the idea that OSes cannot be patched where they are bugged - it destroys legitimate connectivity for OSes that aren't bugged. [jjmb] see my point above, do you really assume the turn around time here is short? even if we do discourage them from doing the hacks. So to my mind, the question is whether or not we want to (and can!) have some say in what these hacks look like, We do want it. (That's what I did in the technical explanation.) not whether or not we should forbid them. Flatly rejecting the hack, as I proposed, doesn't mean forbidding it. (Vendor makes its own choices anyway.) It just means, in my
Re: [DNSOP] Ugly DNS ack
On 3/31/10 3:19 PM, Dan Wing dw...@cisco.com wrote: -Original Message- From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of John Jason Brzozowski Sent: Wednesday, March 31, 2010 10:38 AM To: Rémi Després; dnsop Cc: Ted Lemon; Jason Fesler; Igor Gashinsky Subject: Re: [DNSOP] Ugly DNS ack Remi, I hope you do not mind, I have take the liberty to pull some text from your original post and will reply to them here: ... 4. Return 0 answers for if, and only if: - Query comes over Ipv4; - ³A² record exists for same name; - DNSSEC is not used. = This hack would NOT ONLY be ugly (as acknowledged by their proponents), BUT ALSO would BREAK some of the IPv6 connectivities that are available today !!! [jjmb] I do not see how this would break IPv6 connectivity. Any host that sends its queries over IPv4 would lose IPv6 connectivity. That includes common configurations of hosts doing 6to4, Teredo, Windows XP, ISATAP, and any that -- for whatever reasons -- are using an IPv4 DNS server instead of an IPv6 DNS server. On many OSs, the DNS server list is just a simple list and all DNS queries are sent to the same DNS server. This is an issue with split-zone DNS and multiple interfaces (in the MIF working group), but split-zone DNS is another topic for another time. Igor's proposal requires, effectively, accelerating host modifications to perform A queries over an IPv4 interface and queries over an IPv6 interface, which MIF is working on. How IPv6 DNS servers are configured is another problem with RFC5006 being experimental (which is being fixed) and lack of RFC5006 implementations in routers (I know Cisco, and perhaps others, lack RFC5006). -d [jjmb] some might consider this a feature given the issues and challenges with some of the transition technologies you mention. Support for RFC5006 from a residential point of view requires the home gateway/router to support the same. DHCPv6 (RFC3315) addresses this as well. I do agree that there will likely be an impact to DNSSEC. == This hack MUST therefore be flatly rejected. [jjmb] I see a number of people agree that this should be rejected. I can tell you from first hand experience over the past several months there are some enigmas here and that issues with 6to4 and other transition technologies present challenges to readying infrastructure for real broadband IPv6 traffic. And these challenges are likely not temporary. I suggest deferring rejection until the issues, challenges, and documentation have been documented. If and when the mentioned OS problems are documented, it will be possible to fix them with patches in OSes, where they belong. Le 31 mars 2010 à 17:43, Ted Lemon a écrit : On Mar 31, 2010, at 8:32 AM, Rémi Després wrote: == This hack MUST therefore be flatly rejected. Unfortunately we don't have any control over what Yahoo or Google do to their name servers. I agree with you completely on what we SHOULD do, but if Igor decides to filter s on IPv4 queries, we can't stop him. Sure, and that's fair. But it has to remains his problem, not an IETF specification problem. We can refuse to endorse his solution, but really what's going on here is that Igor (and Google before him) have come to us in good faith to tell us about hacks they've done that they feel are necessary. We shouldn't discourage them from doing that, Agreed. My strong reaction is only against this particular hack because: - it is based on the idea that OSes cannot be patched where they are bugged - it destroys legitimate connectivity for OSes that aren't bugged. [jjmb] see my point above, do you really assume the turn around time here is short? even if we do discourage them from doing the hacks. So to my mind, the question is whether or not we want to (and can!) have some say in what these hacks look like, We do want it. (That's what I did in the technical explanation.) not whether or not we should forbid them. Flatly rejecting the hack, as I proposed, doesn't mean forbidding it. (Vendor makes its own choices anyway.) It just means, in my understanding, a clear refusal to endorse it. Regards, RD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net
Re: [DNSOP] Ugly DNS ack
On Mar 31, 2010, at 3:19 PM, Dan Wing wrote: Any host that sends its queries over IPv4 would lose IPv6 connectivity. Isn't this a misdirection? I suspect it's more like: any (address family agnostic) clients of a dual stacked nameserver will (non?) deterministically lose IPv6 connectivity to DNS-determined destinations. ie, even if I only send DNS over IPv6 to my recursive nameserver, if it is dual stacked (often beyond my control), and for this specific query it prefers IPv4, then I will not get an answer for my under this proposal. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
Not necessarily, if a dual stack hosts communicates with a recursive name server over both IPv4 and IPv6 and other conditions are met then I believe it would be fine based on what was presented. John On 3/31/10 5:12 PM, John Payne j...@sackheads.org wrote: On Mar 31, 2010, at 3:19 PM, Dan Wing wrote: Any host that sends its queries over IPv4 would lose IPv6 connectivity. Isn't this a misdirection? I suspect it's more like: any (address family agnostic) clients of a dual stacked nameserver will (non?) deterministically lose IPv6 connectivity to DNS-determined destinations. ie, even if I only send DNS over IPv6 to my recursive nameserver, if it is dual stacked (often beyond my control), and for this specific query it prefers IPv4, then I will not get an answer for my under this proposal. = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
On Apr 1, 2010, at 12:29 AM, John Jason Brzozowski wrote: Not necessarily, if a dual stack hosts communicates with a recursive name server over both IPv4 and IPv6 and other conditions are met then I believe it would be fine based on what was presented. What other conditions need to be met? I did not think there was any way for a host to signal a recursive NS to use v6 or v4 transport. -- TTFN, patrick On 3/31/10 5:12 PM, John Payne j...@sackheads.org wrote: On Mar 31, 2010, at 3:19 PM, Dan Wing wrote: Any host that sends its queries over IPv4 would lose IPv6 connectivity. Isn't this a misdirection? I suspect it's more like: any (address family agnostic) clients of a dual stacked nameserver will (non?) deterministically lose IPv6 connectivity to DNS-determined destinations. ie, even if I only send DNS over IPv6 to my recursive nameserver, if it is dual stacked (often beyond my control), and for this specific query it prefers IPv4, then I will not get an answer for my under this proposal. = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ugly DNS ack
On Wed, Mar 31, 2010 at 10:41 PM, Patrick W. Gilmore patr...@ianai.net wrote: On Apr 1, 2010, at 12:29 AM, John Jason Brzozowski wrote: Not necessarily, if a dual stack hosts communicates with a recursive name server over both IPv4 and IPv6 and other conditions are met then I believe it would be fine based on what was presented. What other conditions need to be met? I did not think there was any way for a host to signal a recursive NS to use v6 or v4 transport. It seems to me that you'll need to: (at least) 1) ask for a from the client - recursive resolver 2) dual-stack the recursive resolver 3) provide 's with 'better' latency/response than the A records associated with the NS's for your domain (the domian being looked up) 4) decide to answer queries over ipv6 transport from these NS hosts. 5) also reply with A (and other normal records) when asked for them over either transport Just because 'if the query comes over ipv6, auto-whitelist + answer' there's nothing stopping the server from responding to A queries over ipv6 with ipv4 addresses. The NS here has no real idea about the original requestor, only what the recursive resolver decides to use for a transport. you can suppose that if a recursive resolver has 'better' ipv6 transport it should be used 'more', and that potentially the AS/customer-set represented by it will have 'better' (or at least 'good enough') ipv6 transport, but that's not guaranteed. All that said, I think I like Igor's idea, I'm not sure I'd implement it without some research first... the same issues that keep large-content-providers from adding blanket records would likely also affect DNS queries over ipv6 transport. -Chris On 3/31/10 5:12 PM, John Payne j...@sackheads.org wrote: On Mar 31, 2010, at 3:19 PM, Dan Wing wrote: Any host that sends its queries over IPv4 would lose IPv6 connectivity. Isn't this a misdirection? I suspect it's more like: any (address family agnostic) clients of a dual stacked nameserver will (non?) deterministically lose IPv6 connectivity to DNS-determined destinations. ie, even if I only send DNS over IPv6 to my recursive nameserver, if it is dual stacked (often beyond my control), and for this specific query it prefers IPv4, then I will not get an answer for my under this proposal. = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
