[arin-ppml] IPv6 in the Economist

[Dean Anderson]

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