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
[DNSOP] Ugly Hack, Step 4: Solution Options
4 - After we understand Problem Definition, Problem Detection, and Problem Scope, then you can arrive at possible solutions. Seems like in this case we sort of *started* here, which concerns me and I think we need to be careful that discussion thus far does not constrain development of a full list of Solution Options. I further believe we will need to encourage the pursuit of multiple solutions simultaneously. Lastly, just because end user software upgrades may be difficult doesn't mean we shouldn't do them and shouldn't focus just as much energy on those than other options. Thoughts but only after 1, 2, 3 are answered? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Ugly Hack, Step 3: Scope/Scale of Problem
3 - Then, after we have agreement on Problem Definition and Problem Detection, we can measure the problem to understand what the scope or scale of the problem is. 0.074% of users? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Ugly Hack, Step 2: Detection of Problem
2 - Describe all the various methods and tactics by which end user "brokenness" can be detected. This may include website-based detection, DNS-query-based detection, or a variety of other methods. Suggestions: (Nick Weaver I think had one pasted below) Also, you can make an EASY in-browser Javascript check. Load 3 images in a hidden DIV. These images should ideally be set to be non-cached and have a cache-buster in the URL (akin to how Google Analytic's hidden GIF is loaded: it contains a cache-buster in the URL). One is hosted on an IPv4 only site, one on a IPv4/IPv6 dual stack, and one on a IPv6 only site, and bind onload/onerror to Javascript for reporting. If the first two load, the host is a successful V4 host. If only the first loads, the host has the described problem with a link local V6, and needs to be patched: have the Javascript notify the user. If only the second and third loads, the host is V6 only (HA!). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Ugly Hack, Step 1: Problem Definition
1 - Develop a clear problem statement that outlines (1) how "broken" users are defined and (2) what effects this "brokenness" has on these end users (or other parts of the Internet). Suggestion from Tore Anderson - 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.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
I've not seen much attempt yet to spell all this out, so I'll attempt to solicit some responses... > It seems that have the cart before the horse, so to speak. IMHO, we need to > do the following (and there's no reason they cannot occur rapidly): > > 1 - Develop a clear problem statement that outlines (1) how "broken" users > are defined and (2) what effects this "brokenness" has on these end users > (or other parts of the Internet). > > 2 - Describe all the various methods and tactics by which end user > "brokenness" can be detected. This may include website-based detection, > DNS-query-based detection, or a variety of other methods. > > 3 - Then, after we have agreement on Problem Definition and Problem > Detection, we can measure the problem to understand what the scope or scale > of the problem is. > > 4 - After we understand Problem Definition, Problem Detection, and Problem > Scope, then you can arrive at possible solutions. Seems like in this case > we sort of *started* here, which concerns me and I think we need to be > careful that discussion thus far does not constrain development of a full > list of Solution Options. I further believe we will need to encourage the > pursuit of multiple solutions simultaneously. Lastly, just because end user > software upgrades may be difficult doesn't mean we shouldn't do them and > shouldn't focus just as much energy on those than other options. > > Jason > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery
> The bottom line is, that if a given provider's users send in too many > complaints about connectivity problems, the business folks will push for > dewhitelisting. That's bad for both the content and access provider sides > for a variety of reasons. Or, you could just refer them back to their ISP for support, which is how things work in the v4 world today. This is certainly my preference. Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
>> It would probably cost be far more money to roll out this separate DNS >> server view, have folks monitor it and troubleshoot it, test >> and certify it in the lab, etc. than just calling and fixing >> the "broken" users. > > There is a way for the ISP to detect IPv6-broken users? (Who can > then be called and convinced to fix whatever is broken.) Sounds as if there may be*, but I think that all depends upon what "broken" means. I'd love to have some discussion on that topic, so we can see if people are all on the same page. Igor - How do you define broken? And what technical issues do you believe underlie this condition? * I am assuming there is and that an ISP could as readily host the web page with the detection logic as Yahoo or Google could. As well, if we could make this widely available then presumably regulators could put it on their sites, SDOs could, news sites could, etc., and there could be a general awareness and detection campaign organized. I suspect there may well be other methods to detect the condition, which is why I think we should ensure there is clear agreement and understanding of the underlying condition so we can then find our way to detection. Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
> On Mar 31, 2010, at 12:28 AM, Igor Gashinsky wrote: >> >> You are absolutely right -- it's not a DNS problem, it *is* a host >> behavior problem. The issue is that it takes *years* to fix a host >> behavior problem, and we need to engineer and deploy a fix much sooner >> then that (hopefully about a year before the v4 exhaustion date). Given >> that, is there something other then DNS that can address it better/faster? > > Except that, since it IS a host problem, why not focus on improved detection > and debugging > > EG, yahoo is one of the big pushes behind it. THey could easily add > auto-debugging to their homepgae would would detect this condition and NOTIFY > the users that this will be a problem, same for google. > > This to me seems like a "cure" worse than the disease. That is also a concern I share. It seems that have the cart before the horse, so to speak. IMHO, we need to do the following (and there's no reason they cannot occur rapidly): 1 - Develop a clear problem statement that outlines (1) how "broken" users are defined and (2) what effects this "brokenness" has on these end users (or other parts of the Internet). 2 - Describe all the various methods and tactics by which end user "brokenness" can be detected. This may include website-based detection, DNS-query-based detection, or a variety of other methods. 3 - Then, after we have agreement on Problem Definition and Problem Detection, we can measure the problem to understand what the scope or scale of the problem is. 4 - After we understand Problem Definition, Problem Detection, and Problem Scope, then you can arrive at possible solutions. Seems like in this case we sort of *started* here, which concerns me and I think we need to be careful that discussion thus far does not constrain development of a full list of Solution Options. I further believe we will need to encourage the pursuit of multiple solutions simultaneously. Lastly, just because end user software upgrades may be difficult doesn't mean we shouldn't do them and shouldn't focus just as much energy on those than other options. Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
>> :: It seems solvably operationally, by asking ISPs to point their >> :: IPv4-only subscribers at an ISP-operated DNS server which >> :: purposefully breaks responses (returns empty answer), and >> :: to point their dual-stack subscribers at an ISP-operated DNS >> :: server which functions normally. > [jjmb] Solvable perhaps, however, there are operational impacts that are > non-trivial. Not to mention provisioning and in some cases financial > implications. +1 It would probably cost be far more money to roll out this separate DNS server view, have folks monitor it and troubleshoot it, test and certify it in the lab, etc. than just calling and fixing the "broken" users. Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] IPv6 & recursive resolvers: data question
Regarding this presentation, it sounded as if that data cited on slide 2 is available for the community to review and understand better (which I was not aware of). Can someone on this list please advise where this data can be found, in order to better understand the problem? Thanks Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
