Re: I-D ACTION:draft-ietf-dnsop-v6-name-space-fragmentation-00.txt

[Pekka Savola <pekkas@netcore.fi>]

On 9 Feb 2002, Johan Ihren wrote:
> > 2. Introduction to the problem of name space fragmentation
> > 
> >    With all DNS data only available over IPv4 transport everything is
> >    simple. IPv4 resolvers can use the intended mechanism of following
> >    referrals from the root and down while IPv6 resolvers have to work
> >    through a "translator", i.e. they have to use a second name server
> >    on a so-called "dual stack" host as a "forwarder" since they cannot
> >    access the DNS data directly. This is not a scalable solution.    
> > 
> > ==> The last sentence is completely false; the truth is exactly the
> > opposite.  This makes an assumption that there would be only a few
> > "forwarding" servers: IMO, _every ISP_ providing IPv6-only service should
> > provide this capability.  This is very scalable.
> 
> Well, that's not the entire problem. "Forwarding" is something you
> configure statically to get help from someone else with resolution.
> Because of this (and other reasons) you configure your forwarder as an
> IP address, not a name.
> 
> Over time we expect to have hundreds of thousands (or more) of caching
> resolvers on v6 transport. Given a traditional forwarding solution all
> of them will then need statically configured v6 addresses to the ISP
> forwarding services. This will have to be maintained over a very long
> term (tens of years), with ISPs coming and going, ISPs having to
> restructure their services (i.e. moving the forwarders), etc, etc. 

This seems to be no different from having to renumber your site; if you 
have to renumber, I suspect changing this also is not all that fatal thing 
to do.
 
> Deploying a few forwarders to be used by a few caching resolvers for a
> few months is easy. Deploying massive numbers of forwarders to be used
> by even larger numbers of clients for tens of years *with no location
> mechanism* is definitely a problem.
> 
> Since it becomes a problem as we scale it up I see it as a scalability
> problem. That is not to say that it is a *performance* problem. It is
> a *maintenance* problem that does not scale.

Nothing prevents defining e.g. IPv6 anycast addresses to be (also) used
for this specific purpose (or well known addresses, in IPv4 anycast
-style), to be deployed everywhere in the world.  This avoids the
maintenance problem.
 
> > 4. Policy based avoidance of name space fragmentation.
> > 
> >    Today there are only a few DNS "zones" on the public Internet that 
> >    are only available over v6 transport, and they can mostly be  
> >    regarded as "experimental". However, as soon as there is a root
> >    name server available over v6 transport it is reasonable to expect
> >    that it will become more common with v6-only zones over time.
> 
> > ==> wrong assumption: I don't believe making root v6-enabled makes
> > v6-_only_ zones any more common.  People can shoot themselves in the
> > foot now, and could then too, of course.
> 
> Look at this in a really long term perspective: today we have all the
> zones available over v4 transport and (in practice) zero over *only*
> v6 transport. At some point in the future we expect the Internet to be
> mostly v6, with large portions of the net in all likelihood v6-only.

I agree, but the text dramatizes this: v6-only servers would not happen
any time soon, at least from people who care.  The text seems to paint a
picture that v6-only servers would start popping up soon after v6 root.
 
> For domainholders in these future v6-only parts only deploying over v6
> transport is not so much a question of shooting at one's feet as it is
> a quistion of optimizing for local needs at the expense of global. And
> such things will happen.

Those v6-only people who care at all about IPv4 world (I'd say about 
99.99% of them), will provide a secondary on IPv4-only transport for a 
long time, unless some BCP gives other reasons for this (see below).
 
> > 4.2. Zone validation for non-recursive servers.
> > 
> >    Non-recursive authoritative servers are name servers that run
> >    without ever asking questions. A change in the zone validation
> >    requirements that force them to query for the addresses of name
> >    servers that are part of delegations in the zone change this, since
> >    they now have to query for these addresses. 
> > 
> >    However, the main reason that it is important to be able to run
> >    without asking questions is to avoid "caching" possibly bogus  
> >    answers. This need can be managed by requiring that a non recursive
> >    name server throw away the looked up address information after
> >    having used it for validation of the delegations in the zone. 
> > 
> > ==> validation needs only be done when zone is loaded: this does not mean 
> > the records queried (for this specific purpose) will have to be cached -- 
> > so I don't see problems here.
> 
> Exactly.
> 
> The real problem is of course that validation is costly, and that
> large, delegation-dense zones would have immense problems doing
> validation at all. But for smaller zones it would work, and may be a
> useful tool to sites further down in the hierarchy.

If you have so many delegations that it would matter (e.g. 1000's,
10.000's etc.) I'd expect the checks would be done externally, over time
(e.g. check this when zones are delegated, when appropriate records are
updated (this might be unnecessary), etc.), not immediately after loading
up the zone.

> > 4.3. Future requirement of IPv6 address for at least one name server.
> > 
> >    The immediate need for clarified policies for delegation is to 
> >    ensure that IPv4 name space does not start to fragment. Over time, 
> >    however, it is reasonable to expect that it may become important to
> >    add a similar requirement to IPv6 name space.
> > 
> >    I.e. an even more refined policy possible at some point in the 
> >    future would be:
> > 
> >         "Every delegation point should have at least one name server
> > 	for the child zone reachable over IPv4 transport (i.e. should
> >         have an A record) and at least one name server reachable over
> > 	IPv6 transport (i.e. should have an AAAA record)".
> > 
> > ==> in (far) future, I'll expect there will have to be similar kind of 
> > forwarders as now with IPv6; no big deal.
> 
> Hmm. I don't understand this comment. Can you elaborate?

If, in 10 years, there would only be 1% of IPv4-only sites, we _could_
define a mechanism that they must configure a dual-stack server to act as
their forwarder (e.g. with IPv4 anycast address).  At this point, IPv4
_could_ probably also be removed from root (also forces the people to make
this change :-).

Or, this could be the mechanism for being able to query v6-only zones even 
though root and the delegation path would still be dual stack.

> > ==> I support AAAA records myself but is it sensible to make a "political 
> > statement" here ? :-)
> 
> Well, I'm in favour of A6 myself, but that doesn't matter much
> here. The AAAA is the standards track mechanism for v6 name-to-address
> mapping and I see no political controversy in using it. Should the
> tides at some point in the future go in another direction we'll have
> to update.

RFC2874 is also Standards track, and even though it doesn't obsolete 
FC1886 it makes a few statements about A6 being used instead.
  
(note: I was only suggesting adding something like "e.g." where AAAA is 
mentioned.)

> > 5. Overview of suggested transition method.
> > 
> >    By following the steps outlined below it will be possible to
> >    transition without outages or lack of service.
> > 
> > ==> this seems to destroy the credibility of this "comparison".
> 
> Please elaborate.

If you wish to compare two mechanisms, you should not slip in remarks that 
might be viewed as propaganda against the other mechanism.
 
> > 6. How to deploy DNS hierarchy in v6 space.
> > [...]
> >    c) a way of verififying the correctness of the resulting configuration
> > 
> > ==> this was not covered in this draft any further(others were) -- as this 
> > intentional?

Did you miss this ?
 
> > 6.2. How to deploy DNS data.
> > [...]
> >    a) identify all name servers that will serve the DNS domain, with
> >    their IPv4 and/or IPv6 addresses
> > 
> >    b) arrange for a suitable method of zone synchronization
> > 
> > ==> does one need to "dramatize" master/slave zone transfers?
> 
> Well, you probably know as well as I do that surprising numbers of
> zones manage to botch zone transfers when master and slave share
> transport. I think it is a safe guess that this will increase when the
> master and slave does not share any transport.

This seems to mostly depend on the assumption that they don't share 
transport.

> >    It is recommended that the name servers run on single stack
> >    machines, i.e. machines that are only able to utilize either IPv4
> >    transport or IPv6 transport, but not both.
> > 
> > ==> more elaboration why this is good would be nice.
> 
> Yes, but that will have to be a topic for some other document.

Yes, but this fact seems to be depended on in this draft, like above.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords