|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: IPv6 reverse lookup - lame delegation?
> 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: [email protected]
|