+++ /dev/null
-
-
-DNSEXT Working Group Randy Bush (ed.)
- Alain Durand (ed.)
- Bob Fink (ed.)
- Olafur Gudmundsson (ed.)
- Tony Hain (ed.)
-INTERNET-DRAFT March 2002
-
-<draft-ietf-dnsext-ipv6-addresses-01.txt>
-
-Updates: RFC 1886, RFC 2673, RFC 2874
-
-
-
- Representing IPv6 addresses in DNS.
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Comments should be sent to the authors or the DNSEXT WG mailing list
- namedroppers@ops.ietf.org
-
- This draft expires on September 1, 2002.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2002). All rights reserved.
-
-
-
-
-
-
-Expires 1/September/2002 DNSEXT [Page 1]
-
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. March 2002
-
-
-Abstract
-
- This document clarifies and updates the standards status of RFCs that
- define direct and reverse map of IPv6 addresses in DNS. This document
- moves the A6 and Bit label specifications to experimental status.
-
-
-
-
-1 - Introduction
-
- The IETF had begun the process of standardizing two different address
- formats for IPv6 addresses AAAA[RFC1886] and A6[RFC2874] and both are
- at proposed standard. This had led to confusion and conflicts on
- which one to deploy. It is important for deployment that any
- confusion in this area be cleared up, as there is a feeling in the
- community that having more than one choice will lead to delays in the
- deployment of IPv6. The goal of this document is to clarify the
- situation.
-
- This document is based on extensive technical discussion on various
- relevant working groups mailing lists and a joint DNSEXT and NGTRANS
- meeting at the 51st IETF in August 2001. This document attempts to
- capture the sense of the discussions and reflect them in this
- document to represent the consensus of the community.
-
- The main arguments and the issues are covered in a separate
- document[Tradeoff] that reflects the current understanding of the
- issues. This document summarizes the outcome of these discussions.
-
- The issue of the root of reverse IPv6 address map is outside the
- scope of this document and is covered in a different
- document[RFC3152].
-
-1.1 Standards action taken
-
- This document changes the status of RFCs 2673 and 2874 from Proposed
- Standard to Experimental.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires 1/September/2002 DNSEXT [Page 2]
-
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. March 2002
-
-
-2 - IPv6 addresses: AAAA RR vs A6 RR
-
- Working group consensus as perceived by the chairs of the DNSEXT and
- NGTRANS working groups is that:
-
- a) AAAA records are preferable at the moment for production
- deployment of IPv6, and
-
- b) that A6 records have interesting properties that need to be
- better understood before deployment.
-
- c) It is not known if the benefits of A6 outweigh the costs and
- risks.
-
-
-2.1 Rationale
-
- There are several potential issues with A6 RRs that stem directly
- from the feature that makes them different from AAAA RRs: the ability
- to build up addresses via chaining.
-
- Resolving a chain of A6 RRs involves resolving a series of what are
- nearly-independent queries. Each of these sub-queries takes some
- non-zero amount of time, unless the answer happens to be in the
- resolver's local cache already. Other things being equal, we expect
- that the time it takes to resolve an N-link chain of A6 RRs will be
- roughly proportional to N. What data we have suggests that users are
- already impatient with the length of time it takes to resolve A RRs
- in the IPv4 Internet, which suggests that users are not likely to be
- patient with significantly longer delays in the IPv6 Internet, but
- terminating queries prematurely is both a waste of resources and
- another source of user frustration. Thus, we are forced to conclude
- that indiscriminate use of long A6 chains is likely to lead to
- increased user frustration.
-
- The probability of failure during the process of resolving an N-link
- A6 chain also appears to be roughly proportional to N, since each of
- the queries involved in resolving an A6 chain has roughly the same
- probability of failure as a single AAAA query.
-
- Last, several of the most interesting potential applications for A6
- RRs involve situations where the prefix name field in the A6 RR
- points to a target that is not only outside the DNS zone containing
- the A6 RR, but is administered by a different organization entirely.
- While pointers out of zone are not a problem per se, experience both
- with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
- pointers to other organizations are often not maintained properly,
- perhaps because they're less susceptible to automation than pointers
-
-
-
-Expires 1/September/2002 DNSEXT [Page 3]
-
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. March 2002
-
-
- within a single organization would be.
-
-2.2 Recommended standard action
-
- Based on the perceived consensus, this document recommend that RFC
- 1886 stay on standards track and be advanced, while moving RFC 2874
- to Experimental status.
-
-3 - Bitlabels in the reverse DNS tree
-
- RFC 2673 defines a new DNS label type. This was the first new type
- defined since RFC 1035[RFC1035]. Since the development of 2673 it has
- been learned that deployment of a new type is difficult since DNS
- servers that do not support bitlabels reject queries containing bit
- labels as being malformed. The community has also indicated that this
- new label type is not needed for mapping reverse addresses.
-
-3.1 Rationale
-
- The hexadecimal text representation of IPv6 addresses appears to be
- capable of expressing all of the delegation schemes that we expect to
- be used in the DNS reverse tree.
-
-3.2 Recommended standard action
-
- RFC 2673 standard status is to be changed from Proposed to
- Experimental. Future standardization of these documents is to be done
- by the DNSEXT working group or its successor.
-
-4 DNAME in IPv6 reverse tree
-
- The issues for DNAME chaining in the reverse tree are substantially
- identical to the issues for A6 chaining in the forward tree.
- Therefore, in moving RFC 2874 to experimental, the intent of this
- document is that use of DNAME RRs in the reverse tree be deprecated.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires 1/September/2002 DNSEXT [Page 4]
-
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. March 2002
-
-
-5 Acknowledgments
-
- This document is based on input from many members of the various IETF
- working groups involved in this issues. Special thanks go to the
- people that prepared reading material for the joint DNSEXT and
- NGTRANS working group meeting at the 51st IETF in London, Rob
- Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
- Christian Huitema. Number of other people have made number of
- comments on mailing lists about this issue including Andrew W.
- Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
- Savola, Paul Vixie.
-
-6 - Security Considerations:
-
- As this document specifies a course of action, there are no direct
- security considerations. There is an indirect security impact of the
- choice, in that the relationship between A6 and DNSSEC is not well
- understood throughout the community, while the choice of AAAA does
- leads to a model for use of DNSSEC in IPv6 networks which parallels
- current IPv4 practice.
-
-
-7 - IANA Considerations:
-
- None.
-
-References:
-
-[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
- Specification'' STD 13, RFC 1035, November 1987.
-
-[RFC1886] S. Thompson, C. Huitema, ``DNS Extensions to support IP
- version 6'', RFC 1886, December 1995.
-
-[RFC2673] M. Crawford ``Binary Labels in the Domain Name System``, RFC
- 2673, August 1999.
-
-[RFC2874] M. Crawford, C. Huitema, ``DNS Extensions to Support IPv6
- Address Aggregation and Renumbering'', RFC 2874, July 2000.
-
-[RFC3152] R. Bush, ``Delegation of IP6.ARPA'', RFC 3152 also BCP0049,
- August 2001,
-
-[Tradeoff] R. Austein, ``Tradeoffs in DNS support for IPv6'', Work in
- progress, draft-ietf-dnsext-ipv6-dns-tradeoffs-xx.txt, July
- 2001.
-
-
-
-
-
-Expires 1/September/2002 DNSEXT [Page 5]
-
-INTERNET-DRAFT Representation of IPv6 addresses in DNS. March 2002
-
-
-Editors Address
-
- Randy Bush <randy@psg.com>
- Alain Durand <alain.durand@sun.com>
- Bob Fink <fink@es.net>
- Olafur Gudmundsson <ogud@ogud.com>
- Tony Hain <hain@tndh.net>
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires 1/September/2002 DNSEXT [Page 6]
-
projects / thirdparty / bind9.git / commitdiff
