comments on ipv6-transport-guidelines-00

[Pekka Savola <pekkas@netcore.fi>]

Hi,

A few comments on the new DNS IPv6 transport guidelines document.

substantial
-----------

==> first as there are no references to the prior work, or any mention of 
it, I think it would be both appropriate and useful to add an 
"Acknowledgements" section which could begin with a paragraph dedicated to 
summarizing how this document came to be.

   In order to preserve name space continuity, the following administrative
   policies are RECOMMENDED:
      - every recursive DNS server SHOULD be either IPv4-only or dual
      stack,
      - every single DNS zone SHOULD be served by at least one IPv4
      reachable DNS server.
                                                                                                  
   This rules out IPv6-only DNS servers performing full recursion and
   DNS zones served only by IPv6-only DNS servers.

==> as was noted in my comment in a related subject in v6ops earlier (just 
rehashing here with a different audience), this is not entirely accurate, 
especially with all the interpretations of "recursive DNS server".  That 
is, it would be entirely OK to have an IPv6-only resolver point to a few 
IPv6-only DNS servers which would be configured to recurse from some other 
servers (ad infinitum) until a dual-stack recursive DNS resolver is found.

Some might say that such a dummy DNS resolver is not really recursive but
a forwarder but I might disagree..

So, I think we need to both clarify the terminology and decide what 
exactly we want to recommend or allow.  (Note, if someone deploys 
IPv6-only networks with "first-hop DNS resolvers", being able to deploy 
IPv6-only recursive servers might be beneficial.)

==> the other thing to clarify might be "dual stack".  Again, if one 
wanted to be entirely accurate, the question is about whether the DNS 
server software is programmed (and enabled) for the both IP versions while 
the node is dual-stack.  I'm not sure how important this clarification is.

   In order to enforce the second point, the zone validation process
   SHOULD ensure that there is at least one IPv4 address record
   available for the name servers of any child delegations within the
   zone.


==> what is this "zone validation process"?  where is it defined?  where 
is it done (dns regisrars, dns software etc.)?

5. Security considerations
                                                                                                  
   Being a critical piece of the Internet infrastructure, the DNS is a
   potential value target and thus should be protected.  Great care
   should be taken not to weaken the security of DNS while introducing
   IPv6 operation.
                                                                                                  
   The RECOMMENDED guidelines are compatible with the operation of
   DNSsec and do not introduce any new security issues.

==> add something like below after the first paragraph:

   Keeping the DNS name space from fragmenting is a critical thing for the 
   availability and the operation of the Internet; this memo addresses 
   this issue by clear and simple operational guidelines.


semi-editorial
--------------

Abstract
                                                                                                  
   This memo provides guidelines and best common practice to operate DNS
   in a mixed world of IPv4 and IPv6 transport.

==> the abstract should be longer, and include e.g. the summary of those 
guidelines (if possible).

==> note: is the goal for this Informational or BCP?  If Info, reword to 
remove reference to BCP [sic].

   Today there are only a few DNS "zones" on the public Internet that
   are  available over IPv6 transport, and they can mostly be regarded
   as "experimental". However, as soon as there is a root name server
   available over IPv6 transport it is reasonable to expect that it will
   become more common to have zones served by IPv6 servers over time.

==> The " as soon as there is a root name server available over IPv6
transport" is unrelated and irrelevant in this context, for the whole
purpose of this document, please remove!  (transport!=data; one could add
IPv6 glue in root, gtld's or cctld's before those are available over IPv6)

   The RECOMMENDED approach to maintain name space continuity is to use
   administrative policies.

==> the curious reader now (before looking down a bit) begins to wonder, 
"OK, _what_ administrative policies??".  Fix: s/policies./policies, as 
described in the next section./ :-)




editorial
---------

Internet Engineering Task Force                     Alain Durand
INTERNET-DRAFT                             SUN Microsystems,inc.
June, 17, 2003                                       Johan Ihren

==> s/Alain/A./, s/Johan/J./

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [2119].

==> should avoid references in the I-D boilerplate.

Abstract
                                                                                                  
   This memo provides guidelines and best common practice to operate DNS
   in a mixed world of IPv4 and IPv6 transport.

==> spell out DNS?
==> s/best common practice/Best Current Practice/ ?
==> "IPv4 and IPv6 _transport_" could be clarified.  It's OK for those 
who're used to the terminology but begs questions like "transport for 
what?  transport over what?"  (same in terminology)

2. Introduction to the problem of name space fragmentation:
     following the referral chain

==> s/problem/Problem/ etc. for section titles etc.

   The caching resolver that tries to lookup a name starts out at the
 
==> s/lookup/look up/

If somewhere down the chain of
   referrals it is referred to a nameserver that is only accessible over
   a type of transport that is unavailable, a traditional nameserver is
   unable to finish the task.

==> s/a type of transport that is unavailable/an unavailable type of transport/

   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
   only a matter of time until this starts to happen and the complete
   DNS hierarchy starts to fragment into a graph where authoritative
   nameservers for certain nodes are only accessible over a certain
   transport. What is feared is that a node using only a particular
   version of IP, querying information about another node using the same
   version of IP can not do it because, somewhere in the chain of
   servers accessed during the resolution process, one or more of them
   will only be accessible with the other version of IP.

==> This paragraph only includes two (2!) long sentences, especially the 
latter.  It might be a bit more user-friendly broken down to shorter 
ones.. :-)

   However, the second situation will not arise in a foreseeable time.
   Instead, it is expected that the transition will be from IPv4 only to
   a mixture of IPv4 and IPv6, with DNS data of theoretically three
   categories depending on whether it is available only over IPv4
   transport, only over IPv6 or both.
                                                                                                  
   The latter is the best situation, and a major question is how to
   ensure that it as quickly as possible becomes the norm. [...]

==> the "latter" is a big ambiguous referral, perhaps just say "Having DNS 
data available on both transports is the best situation, ..." ?

3. Policy based avoidance of name space fragmentation.
                                                                                                  
==> s/ion./ion/ (similar for section header for section 4)

  DNSsec and do not introduce any new security issues.
                                                                                                  
==>s/DNSsec/DNSSEC/ ?

7. References

==> rename to "Normative References".

8. Full Copyright Statement

==> add the standard IPR boilerplate section prior to this one



-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.