[arin-ppml] IPv6 in the Economist

[Dean Anderson]

On Fri, 6 Jun 2008, Lee Dilkie wrote:

> Dean,
> 
> I'm unsure why you think IPv6 is broken simply because the DNS 
> infrastructure isn't completely rolled out yet or is designed in a 
> fashion not to your liking.

Read on, then. You may want to re-read my original message more closely.

Leo Bicknell is right that the technical details are far too technical
for this list. Probably far to technical for a few emails, even.  We'll
take a shot, though.

One thing that Leo states that I think needs some clarification is this:

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

There is a current proposal in the DNSEXT WG to change standards so that
either TCP or EDNSO will be required.  DNS standards may have moved on,
or more specifically, may move on in the future.  Implmentations take
many years to catch up.


Of course, if there are separate resolvers for IPv4 and IPv6, things get
much easier to handle. Just like migrating IPv4 and Novell can mix on
the same physical media without interference. Creating a separate IPv6
resolver would have allowed DNS standards to progress much faster, since
you don't have upgrade IPv4 resolvers for IPv6 packet size increases,
etc. Like Novell and IPv4, separate resolvers and infrastructure enable
one to can access separate networks without conflicts. You shouldn't
have to alter the old network to be able to use the new network.  
Turning off the old network shouldn't break the new network.

On Fri, 6 Jun 2008, Michael Loftis wrote:

> 
> 
> --On June 6, 2008 10:25:45 AM -0400 Dean Anderson <dean at av8.com> wrote:
> 
> > On Fri, 6 Jun 2008, Owen DeLong wrote:
> >
> >> Except you can't do name resolution if you turn off IPv4.
> >>
> >> I would say that's not full IPv6 support.
> >>
> >> I'd say that's minimal sort-of support at best.
> >
> > 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
> 
> If you can get the tens of thousands of ASs to switch to v6 on a given 
> 0-hour then you must be closer to some God than any of us mortals.  A 
> solution without mixed v4/v6 is impossible right now because there are 
> still many people who are in the v6 world on an island compared to certain 
> other destinations

This is mixing at a different level. Running Novell and IPv4 on the same
ethernet is mixing, too. Howeverr, Novell doesn't depend on IPv4 to
work.  That's the problem: IPv6 depends on IPv4 to work.  The IPv6 stack
uses IPv4 resources. Remove, or significantly alter those resources, and
breakage occurs.

A clean IPv6 stack would have a separate resolver, separate servers,
etc, and mix only like Novell and IP mix, now. On the physical media. A
0-hour switch is not a necessity to avoid the bad kind of mixing of
stacks, any more than a migration from Novell to IPv4 must be 0-hour.

> anycast is a technical solution to providing more reliable, higher 
> performance services, and has not a damn thing to do with address space 
> depletion and IPv4 limitations. 

In properly administered root DNS and IPv6, Anycast shouldn't (as in
'ought not to') have anything to with IPv6 DNS architecture.  However,
the (broken) IPv6 DNS approach does in fact keep exactly the same 13 DNS
servers as before.  Keeping these same servers is the only benefit of
the current (broken) approach, and it only benefits the root DNS
Operators who are selling Anycast DNS services.  Creating a separate
resolver would have allowed DNS standards to progress much faster, since
you don't have upgrade IPv4 resolvers for IPv6 packet size increases,
etc.


Your assertion that Anycast is 'more reliable' or 'higher performance'
is also not something that can be proven to be true in every DNS case,
and has been proven to be false in some DNS cases.  At best, the subject
is controversial.  The reason for the confusion is that most advocates
of Anycast read RFC1546, and assert that DNS is a stateless UDP
protocol. In small part, DNS is a stateless UDP protocol.  However, DNS
is not limited to stateless UDP service. Root servers in particular have
to offer TCP services. Anycast is not reliable with TCP.  This fact was
plainly stated in RFC1546.  In fact, Anycast is not reliable with ENDSO
for similar reasons: As with TCP, ENDSO requires that state be
maintained on the server end-to-end for Path MTU discovery.  But RFC1546
is correct: Anycast is only suitable for stateless UDP protocols, and
can benefit stateless UDP protocols.

RFC3226 states:
   All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
   fragmented IPv4 and IPv6 UDP packets.

As Illjitsch van Beijnum pointed out a long time ago, a lost fragment
due to PMTUD reply not reaching the original Anycast server is deadly to
the packet.

Usually people who advocate Anycast DNS or Anycast anything,
particularly those who say "I'm doing anycast with no problem" are using
only the stateless protocol configuration.  There is more, but I'll
refer you to http://www.av8.net/IETF-watch/DNSRootAnycast/History.html
[This page needs to be updated with current events, and links were
broken when the IETF moved some mailing list archives.]


> > anti-trust law.  So, there are no IPv6 root nameservers. Instead, one
> 
> Uh?
> $ dig +short aaaa f.root-servers.net
> 2001:500:2f::f

f.root-servers.net is an IPv4 nameservers returning an IPv6 addresses. 
As Leo points out,
adding all the NS records for . requires a packet > 512 bytes.  So what
TLD operators have tried, and reported on DNSOP, is removing IPv4 A
records until the packets are <=512 bytes. This affects stability of
IPv4, since you are removing IPv4 nameservers for the zone. There are
some problems to requiring TCP or EDNSO. Besides resolvers that don't
expect >512 EDNSO responses, Anycast root servers aren't reliable for
TCP or EDNSO.

An IPv6 nameserver would only serve IPv6. If you change IPv6 to 
"Novell", you will find more sensible arguments, and you won't be so 
confused by IPv4

> And you've spouted that OSI CLNS as a solution....Except last I checked the 
> same problem would exist, worse, there's almost nothing outside of routers 
> that actually supports OSI CLNS.

That's true. In some cases client stacks have to be written. But there
is a stable OSI implementation to work out interoperability problems.
IPv6 client stacks still have some interoperability problems, as Randy
reported.  Of course, one way around this problem, as is true of IPv6, 
is to proxy to interior IPv4 networks transparently, so the IPv4 client 
never knows its talking to OSI services.

		--Dean


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