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 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. > > Any host that sends its AAAA 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 AAAA 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 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 >
========================================= 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
