> -----Original Message----- > From: John Jason Brzozowski > [mailto:john_brzozow...@cable.comcast.com] > Sent: Wednesday, March 31, 2010 9:23 PM > To: Dan Wing; Igor Gashinsky > Cc: Andrew Sullivan; dnsop@ietf.org > Subject: Re: [DNSOP] FYI: DNSOPS presentation > > On 3/31/10 5:12 PM, "Dan Wing" <dw...@cisco.com> wrote: > > >> -----Original Message----- > >> From: John Jason Brzozowski > >> [mailto:john_brzozow...@cable.comcast.com] > >> Sent: Wednesday, March 31, 2010 1:57 PM > >> To: Igor Gashinsky; Dan Wing > >> Cc: Andrew Sullivan; dnsop@ietf.org > >> Subject: Re: [DNSOP] FYI: DNSOPS presentation > >> > >> On 3/31/10 4:37 PM, "Igor Gashinsky" <i...@gashinsky.net> wrote: > >> > >>> On Wed, 31 Mar 2010, Dan Wing wrote: > >>> > >>> :: Users running IE6 today are IPv4-only users. If/when they go > >>> :: to IPv6, they will be running Windows 7 and whatever browser > >>> :: is shipped by Microsoft. > >> [jjmb] this is not what the Free people have indicated. I > >> think this is a > >> flawed assumption. > >>> > >>> Why do you say that? As far as I know, IE6 is an > >> ipv6-capable browser, > >>> as long as it's going to FQDN's.. So, what about IE6/XP users who > >>> installed bittorent clients (or spyware/trojans) that > >> enabled ipv6 for > >>> them without the user knowing about it? > >> [jjmb] Again from first hand experience, I can tell you there were > >> unexpected non-trivial increase in P2P over IPv6 traffic. > >>> > >>> :: It seems solvably operationally, by asking ISPs to point their > >>> :: IPv4-only subscribers at an ISP-operated DNS server which > >>> :: purposefully breaks AAAA 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. > >>> :: > >>> :: Advanced IPv4-only users wanting to do AAAA queries (e.g., > >>> :: Teredo users, 6to4 users, etc.) should be sufficiently advanced > >>> :: to point themselves at the ISP's normal nameserver or a > >>> :: public DNS server on the Internet (e.g., Hurricane > >>> :: Electric's, Google's, etc.). That won't affect users running > >>> :: uTorrent (which uses Teredo to provide IPv6 connectivity) > >>> :: because it doesn't do AAAA queries to find peers. > >> [jjmb] what percentage of broadband users fall into the > >> advanced category > >> and will that be adequate to facilitate IPv6 adoption. I > >> suspect no and > >> this is not really an option in most cases for non-advanced users. > > > > Sorry, it appears I was not clear. > > > > I will describe it another way. There are two categories of ISP > > subscribers: > > > > 1. If subscriber is provisioned for IPv6, they are pointed at > > the ISP's DNS server which responds to AAAA normally -- > > this is the ISP's "normal" nameserver. All is well. > > DNSSEC works, even if the validation is done by the client. > > No muss, no fuss. > > > > 2. If subscriber is NOT provisioned for IPv6, they are > > pointed at the ISP's DNS server which responds to AAAA > > with an empty answer. This helps with the transition > > without losing eyeballs. DNSSEC breaks if the client > > queries AAAA and the client does DNSSEC validation. > > > > An advanced subscriber might be in this category (not > > provisioned for IPv6). But that advanced user might want > > to query AAAA and get an answer. That advanced user can > > use the ISP's "normal" DNS server, or Google's, or > > HE's, or opendns.org's, or whatever. An advanced > > subscriber might want to do that to *purposefully* > > run Teredo, or to analyze a packet trace that > > includes IPv6 traffic (and do DNS reverse queries > > on the packet trace), get full results from the 'host' > > command, etc. > > > > Clearer? > > > > -d > [jjmb] I see how you categorize things, the clarification > does not, however, > change some of my points. Having advanced users (people like > us) manually > configure their DNS servers to point to HE (for example) will > pertain to a > small percentage of the overall Internet using population > that must start > using IPv6 without special configurations. The former > assumes there is a > separate infrastructure in place with in the service > providers which, as > mentioned earlier, has non-trivial challenges.
Yes, I heard that from you and Jason: running another DNS server costs the ISP money. I understand nothing new comes for free. Content providers don't want to lose money (viewers), and they currently seem reluctant to provide AAAA records to ISPs. An impasse. I am trying to see how we might might provide Igor's requested functionality without breaking the DNS protocol. That is -- how operationally we could achieve the requested functionality. This is the DNS ops list, afterall. -d > > > >>> This is *exactly* what we are proposing -- the feature to > >> return empty > >>> answers would be needed for ipv4-only subscribers in order > >> to keep them > >>> ipv4-only. Also, if a fully ipv6-capable user visits that > >> person's home, > >>> the recursor would then be able to make the call on if they > >> should pass > >>> through AAAA to that particular user or not... I am by no > >> means advocating > >>> to make this behavior a default, just a feature. > >>> > >>> Thanks > >>> -igor > >>> _______________________________________________ > >>> 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 > >> ========================================= > >> > > > > ========================================= > 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
