[arin-ppml] IPv6 in the Economist

Tue Jun 10 18:25:53 EDT 2008

Lets try to get the substantive discussion going again.

Leo Bicknell asserted that 99% of resolvers are EDNSO capable. I
disputed this and asserted that even if true, 1% failure is too much to
consider as stable.

In fact, http://www.ripe.net/docs/ripe-352.html reports some (2005) 
statistic on EDNSO. Particularly, table 2 shows statistics for k root, 
and shows that about 34.5% of the queries contain the EDNSO option.  I 
think this probably represents the percentage of EDNSO-capable recursive 
nameservers.

It is interesting that ns-pri.ripe.net reports 70% queries with EDNSO
option. This server responds to the people going to RIPE's web pages,
and is probably more heavily weighted to the comparative 'DNS
cognoscenti' who frequent the pages and services of RIPE-NCC.  Even the 
DNS elites don't support EDNSO very well. Hmm.

This paper by ICANN (2007) reports ICANNs view:
http://www.icann.org/committees/security/sac018.pdf 
 I think this document glosses over some of the problems, oversimplifies
some of the issues, and ignores some obvious alternatives. The document
considers only two alternatives and ignores any other possible
alternative, particularly the alternative of separating IPv6 name
resolution from IPv4 name resolution. For some reason, that alternative
wasn't even considered.

		--Dean

On Fri, 6 Jun 2008, Dean Anderson wrote:

> On Fri, 6 Jun 2008, Leo Bicknell wrote:
> 
> > In a message written on Fri, Jun 06, 2008 at 02:38:05PM -0400, Dean Anderson wrote:
> > > > Fortunately DNS has also moved on.  RFC 2671 specifies EDNS0, an
> > > > extension to DNS to allow for larger packets.  This was later
> > > > required in RFC 3226 for all DNSSEC and A6 aware servers and
> > > > resolvers.  RFC 2874 may also be of interest.
> > > 
> > > Most resolvers aren't DNSSEC or EDNSO aware.
> > 
> > While technically correct I believe this statement is misleading.
> 
> Well, let's see:
> 
> > Virtually none of the end-user resolver libraries (e.g. the stuff
> > you get with your Windows, Linux, OSX or other distro) are DNSSEC
> > or EDNS0 aware out of the box.  
> 
> Yep.
> 
> > However, those end user resolvers
> > are often crippled in much more significant ways, such as the
> > complete and total inability to walk up and down the DNS tree.  In
> > short, most are incapable of even knowing they need to ask the DNS
> > root anything, much less being able to construct the query.
> 
> Yes, all in all, things are indeed a little worse than I described, but
> this other breakage has been here for a while.  In fact, the other
> breakage is just another reason that a separate IPv6 resolver would have
> been a good idea. There are a lot of uglies in DNS protocol that could
> have been wholesale dumped with a new resolver and slightly different
> protocol---minus the old uglies and plus the new stuff. These facts you
> cite enhance and improve my argument that wrong decisions were made on
> IPv6 DNS. These facts you cite hardly make my statements misleading.
> 
> > in it.  A very large percentage of those caching recursive name
> > servers have DNSSEC and EDNS0 capability.
> 
> I'm not sure I agree. I think (also without checking the code), that
> djbDNS dnscache doesn't do DNSSEC or EDNSO.  Indeed, perhaps the latest
> versions of several popular DNS caching servers do support DNSSEC. Of
> course, many people still run older versions of those servers that don't
> have support for DNSSEC. That affects the actual percentages.
> 
> > In short, yes, 99% of end user resolvers can't make a EDNS0 query,
> > however those same resolvers always ask a caching server to make the
> > query for them, and 99% of the time the caching server is capable and
> > performing those queries on behalf of the user.
> 
> Except the resolver still gets truncated data, and the supposed 1% of
> clients that fail is still too much to be considered reliable. I think
> the real unsupported percentage is probably much higher, but I won't
> make up numbers---there should be a way to measure this. The result is
> that, as I said originally:
> 
> Dean Anderson wrote:
> > DNS is very severely broken in IPv6. This non-technical reason is that
> > certain root operators want to keep their monopolies on anycast sales,
> > and so (for technically inexplicable reasons), they have advocated
> > mixing IPv6 and IPv4, and silenced dissent in apparent violations of
> > anti-trust law.  So, there are no IPv6 root nameservers. Instead, one
> > mixes IPv6 DNS records with IPv4 DNS records on the same nameserver.
> > This totally unnecessary mixing creates stability problems for both
> > IPv4 and IPv6.  One has to remove IPv4 NS records to make room for
> > IPv6 records, so any effort to deploy IPv6 comes at the expense of
> > IPv4 stability. While bad enough, that isn't the worst part.
> > 
> > What's worse is that the DNS resolver implementations are broken as
> > well. One can't just create IPv6 root nameservers because the
> > resolvers don't do the right thing--there is no IPv6-specific resolver
> > which could use different root nameservers for IPv6. IPv4 and IPv6
> > have to be mixed at the roots on down.  Until this is fixed, IPv6
> > won't really be very useful or else both won't be stable.  Altering
> > and updating resolvers on every computer is a very time-consuming job
> > to say the least. So, I think IPv6 won't be taking over in 3 years,
> > and IPv4 won't be going away in 3 years.
> 
> Having drilled into the details quite a bit, my statement above still
> stands.  None of my statements have been misleading or incorrect.
> 
> Others can minimize facts to support their view, and maximize other
> facts, but they shouldn't be allowed to alter the facts to the point of
> creating a false impression that IPv6 is ready for deployment as is. The
> current DNS approach is fraught with avoidable problems that negatively
> affect the stability of IPv4.  The current DNS root operators and DNS
> protocol definers, in fact, haven't been doing such a good job.
> 
> > And I believe this is likely to be my last reply on the topic, as
> > we are now quite far from anything that is ARIN related.
> 
> Altering the technical details are indeed beyond the scope of PPML---we
> can't fix any of these problems directly. But the _policy_ affected by
> the technical details and problems isn't beyond the scope of PPML.  
> Policy makers ought to understand the technical details---that's
> necessary to make good policy. The policy makers just can't change the
> technical details; that's the job of others, as Leo points out.
> 
> Those claiming that IPv6 is ready for widespread deployment now are
> simply not giving a reliable picture of the true status of IPv6; They do
> not cite the dissent to their view; they do not explain the problems yet
> to be overcome, nor do they even imply that there are significant
> obstacles to be overcome.  We cannot adopt IPv6 policy on the basis of
> near-deceptions about the state of IPv6.  People cannot be allowed to
> make unsubstantiated claims about IPv6 and its various impacts on IPv4
> without being refuted. Policies cannot be adopted on the basis of such
> unsubstantiated assertions.
> 
> My (high level) statement [quoted above] just illuminates problems that
> do indeed exist and usually aren't acknowledged by IPv6 promoters. [kind
> of like Bush Admin. didn't acknowledge dissents in intelligence data
> about Iraq---Indeed, NY Times today has a story that I can just about
> rewrite word for word, only changing a few key terms and names.]
> 
> 
> > For those who want to continue the discussion elsewhere, any or all
> > of these may be appropriate:
> 
> Err, IPv6 public policy remains appropriate to PPML. So the high level
> discussion is appropriate. The lists you cite are appropriate for some
> kinds of discussion---perhaps actually fixing the problems I cite. But
> the lists you cite are not policy lists, and don't decide IPv6 policy at
> ARIN. IPv6 policy at ARIN is for PPML.
> 
> > http://www.ietf.org/html.charters/dnsext-charter.html
> 	^^^^ DNS Protocol definition. Our discussion isn't protocol
> definition. Ours is policy in light of protocol flaws. 
> 
> > http://www.ietf.org/html.charters/dnsop-charter.html
>         ^^^^ Formerly included DNS root operations. There is a current
> effort to remove Root DNS operations from the charter.  This charter
> change effort started in response to Anycast issues, to try to assert
> and then define than DNS Root Anycast problems are off-topic for DNSOP.
> 
> > http://www.icann.org/committees/dns-root/
>         ^^^^ aka the RSSAC, closed except to root operators.
> 
> 
> Have a good weekend, 
> 
> 		--Dean
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   