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

[Pekka Savola <pekkas@netcore.fi>]

I'm not on the list, so please keep Cc:.

On Thu, 24 Jan 2002 Internet-Drafts@ietf.org wrote:
> 	Title		: IPv4-to-IPv6 migration and DNS name space 
>                           fragmentation
> 	Author(s)	: J. Ihren
> 	Filename	: draft-ietf-dnsop-v6-name-space-fragmentation-00.txt
> 	Pages		: 
> 	Date		: 23-Jan-02
> 	
> This memo documents some problems forseen in transitioning from a
> IPv4-only DNS hierarchy via a long period of mixture to an
> IPv6-mostly situation sometime in the future. The mixture period is
> expected to be very long, and hence design choices should very much
> take this into account, rather than just regard the transition as a
> relatively short period of pain.

A few comments.

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.

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.

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.

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.

==> I support AAAA records myself but is it sensible to make a "political 
statement" here ? :-)

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

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?

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?

   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.

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