draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt   draft-ietf-dnsext-ipv6-dns-tradeoffs-01.txt 
Network Working Group R. Austein Network Working Group R. Austein
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt InterNetShare, Inc. draft-ietf-dnsext-ipv6-dns-tradeoffs-01.txt Bourgeois Dilettant
July 2001 May 2002
Tradeoffs in DNS support for IPv6 Tradeoffs in DNS support for IPv6
Status of this document Status of this document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 8, line 39 skipping to change at page 8, line 39
renumbering or GSE-style routing that the A6 RR offers in the main 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 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 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, 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. and if one isn't necessary, the other isn't either.
Other uses have also been proposed for the DNAME RR, but since they 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 are outside the scope of the IPv6 address discussion, they will not
be addressed here. be addressed here.
Other topics ???
Recommendation Recommendation
Distilling the above feature comparisons down to their key elements, Distilling the above feature comparisons down to their key elements,
the important questions appear to be: the important questions appear to be:
(a) Is IPv6 going to do rapid renumber or GSE-like routing? (a) Is IPv6 going to do rapid renumber or GSE-like routing?
(b) Is the reverse mapping tree for IPv6 going to require delegation (b) Is the reverse mapping tree for IPv6 going to require delegation
in the least significant four bits of the address? in the least significant four bits of the address?
Question (a) appears to be the key to the debate. This is really a Question (a) appears to be the key to the debate. This is really a
skipping to change at page 9, line 31 skipping to change at page 9, line 29
and implementation guidelines designed to discourage excessively and implementation guidelines designed to discourage excessively
complex uses of these features; in general, any network that can complex uses of these features; in general, any network that can
be described adequately using A6 0 RRs and without using DNAME be described adequately using A6 0 RRs and without using DNAME
RRs should be described that way, and the enhanced features RRs should be described that way, and the enhanced features
should be used only when absolutely necessary, at least until we should be used only when absolutely necessary, at least until we
have much more experience with them and have a better have much more experience with them and have a better
understanding of their failure modes. understanding of their failure modes.
Security Considerations Security Considerations
??? This note compares two mechanisms with similar security
characteristics, but there are a few security implications to the
choice between these two mechanisms:
(1) The two mechanisms have similar but not identical interactions
with DNSSEC. Please see the section entitled "Interactions with
DNSSEC" (above) for a discussion of these issues.
(2) To the extent that operational complexity is the enemy of
security, the tradeoffs in operational complexity discussed
throughout this note have an impact on security.
(3) To the extent that protocol complexity is the enemy of security,
the additional protocol complexity of [Tweedledum] as compared to
[Tweedledee] has some impact on security.
IANA Considerations IANA Considerations
None, since all of these RR types have already been allocated. None, since all of these RR types have already been allocated.
Acknowledgments Acknowledgments
This note is based on a number of discussions both public and private This note is based on a number of discussions both public and private
over a period of (at least) eight years, but particular thanks go to over a period of (at least) eight years, but particular thanks go to
Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
skipping to change at page 10, line 13 skipping to change at page 10, line 24
Support IPv6 Address Aggregation and Renumbering" RFC 2874, July Support IPv6 Address Aggregation and Renumbering" RFC 2874, July
2000. 2000.
[Sommerfeld] Private message to the author from Bill Sommerfeld dated [Sommerfeld] Private message to the author from Bill Sommerfeld dated
21 March 2001, summarizing the result of experiments he 21 March 2001, summarizing the result of experiments he
performed on a copy of the MIT.EDU zone. performed on a copy of the MIT.EDU zone.
Author's addresses: Author's addresses:
Rob Austein Rob Austein
InterNetShare, Inc.
505 West Olive Ave., Suite 321
Sunnyvale, CA 94086
USA
sra@hactrn.net sra@hactrn.net
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/