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