nanog mailing list archives

Re: IPv6 reverse lookup - lame delegation?


From: Mark.Andrews () isc org
Date: Thu, 12 Feb 2004 08:00:03 +1100




Having been present at the meeting that gave rise to the document (at 
the IETF meetings held in London, August 2001), I'd say that the 
material quoted in the document is at fault.  (There was quite a lot 
of controversy at the meeting, perhaps my recollection isn't shared 
with all others.  But this is my story and I'm sticking to it.)

The changes in status of bit labels, the A6, and DNAME were discussed 
in the context of DNS's support of IPv6.  At the time the main debate 
was whether or not DNS records ought to be defined to support 
renumbering (among other features, but renumbering was the star).  A6 
and bit sting labels (forward and reverse) proved to be too much for 
the DNS to handle, the new thought was that such functionality ought 
to be pulled out of DNS and into tools the pre-processed zone 
definitions.  E.g., something that generated AAAA records from a 
database, etc.

DNAME was kind of the "third record in."  The change in it's "status" 
pertained to the role it played in supporting bit sting labels - 
which is why the "reverse tree" is mentioned in the deprecation. 
Looking at the document now, the document ought to have read "the use 
of DNAME RRs in the support of bit string labels is deprecated" - 
based on my memory.

PS - Note that DNAMEs are defined in RFC 2672, not in 2874.  If you 
want to get all "IETF document lawyerish" about it (;)), the quoted 
material is referencing a discussion of DNAME in the context of 
supporting renumbering, not the definition DNAME itself.

RFC 2672: Non-Terminal DNS Name Redirection
RFC 2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering

        Also neither RFC 3363 nor RFC 3364 update RFC 2672.
        
        Note the second paragraph quated from RFC 2672.  DNAME is
        still very much alive.


DNAME RRs

   [RFC2874] also proposes using DNAME RRs as a way of providing the
   equivalent of A6's fragmented addresses in the reverse mapping tree.
   That is, by using DNAME RRs, one can write zone files for the reverse
   mapping tree that have the same ability to cope with rapid
   renumbering or GSE-style routing that the A6 RR offers in the main
   portion of the DNS tree.  Consequently, the need to use DNAME in the
   reverse mapping tree appears to be closely tied to the need to use
   fragmented A6 in the main tree: if one is necessary, so is the other,
   and if one isn't necessary, the other isn't either.

   Other uses have also been proposed for the DNAME RR, but since they
   are outside the scope of the IPv6 address discussion, they will not
   be addressed here.

 
At 14:45 +0200 2/11/04, Pekka Savola wrote:
On Wed, 11 Feb 2004, Mark Andrews wrote:
   RFC 3363 does NOT say that DNAME is deprecated.  All it says
   is that since A6 was moving the exprimental using DNAME to
   support renumbering is deprecated.

Which part of:

                        Therefore, in moving RFC 2874 to experimental,
   the intent of this document is that use of DNAME RRs in the reverse
   tree be deprecated.

do you difficulties in parsing?

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

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

History repeats, therefore my life is a rerun.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews () isc org


Current thread: