draft-ietf-dnsext-ipv6-addresses-02.txt   rfc3363.txt 
DNSEXT Working Group Randy Bush (ed.) Network Working Group R. Bush
Alain Durand (ed.) Request for Comments: 3363 A. Durand
Bob Fink (ed.) Updates: 2673, 2874 B. Fink
Olafur Gudmundsson (ed.) Category: Informational O. Gudmundsson
Tony Hain (ed.) T. Hain
Editors
<draft-ietf-dnsext-ipv6-addresses-02.txt> August 2002
Updates: RFC 1886, RFC 2673, RFC 2874
Representing IPv6 addresses in DNS. Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC 2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 December 31, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All rights reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document clarifies and updates the standards status of RFCs that This document clarifies and updates the standards status of RFCs that
define direct and reverse map of IPv6 addresses in DNS. This document define direct and reverse map of IPv6 addresses in DNS. This
moves the A6 and Bit label specifications to experimental status. document moves the A6 and Bit label specifications to experimental
status.
1 - Introduction 1. Introduction
The IETF had begun the process of standardizing two different address The IETF had begun the process of standardizing two different address
formats for IPv6 addresses AAAA[RFC1886] and A6[RFC2874] and both are formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
at proposed standard. This had led to confusion and conflicts on are at proposed standard. This had led to confusion and conflicts on
which one to deploy. It is important for deployment that any 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 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 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 deployment of IPv6. The goal of this document is to clarify the
situation. situation.
This document also discusses issues relating to the usage of Binary This document also discusses issues relating to the usage of Binary
Labels [RFC 2673] to support the reverse mapping of IPv6 addresses. Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
This document is based on extensive technical discussion on various This document is based on extensive technical discussion on various
relevant working groups mailing lists and a joint DNSEXT and NGTRANS relevant working groups mailing lists and a joint DNSEXT and NGTRANS
meeting at the 51st IETF in August 2001. This document attempts to meeting at the 51st IETF in August 2001. This document attempts to
capture the sense of the discussions and reflect them in this capture the sense of the discussions and reflect them in this
document to represent the consensus of the community. document to represent the consensus of the community.
The main arguments and the issues are covered in a separate The main arguments and the issues are covered in a separate document
document[Tradeoff] that reflects the current understanding of the [RFC3364] that reflects the current understanding of the issues.
issues. This document summarizes the outcome of these discussions. This document summarizes the outcome of these discussions.
The issue of the root of reverse IPv6 address map is outside the The issue of the root of reverse IPv6 address map is outside the
scope of this document and is covered in a different scope of this document and is covered in a different document
document[RFC3152]. [RFC3152].
1.1 Standards action taken 1.1 Standards Action Taken
This document changes the status of RFCs 2673 and 2874 from Proposed This document changes the status of RFCs 2673 and 2874 from Proposed
Standard to Experimental. Standard to Experimental.
2 - IPv6 addresses: AAAA RR vs A6 RR 2. IPv6 Addresses: AAAA RR vs A6 RR
Working group consensus as perceived by the chairs of the DNSEXT and Working group consensus as perceived by the chairs of the DNSEXT and
NGTRANS working groups is that: NGTRANS working groups is that:
a) AAAA records are preferable at the moment for production a) AAAA records are preferable at the moment for production
deployment of IPv6, and deployment of IPv6, and
b) that A6 records have interesting properties that need to be b) that A6 records have interesting properties that need to be better
better understood before deployment. understood before deployment.
c) It is not known if the benefits of A6 outweigh the costs and c) It is not known if the benefits of A6 outweigh the costs and
risks. risks.
2.1 Rationale 2.1 Rationale
There are several potential issues with A6 RRs that stem directly There are several potential issues with A6 RRs that stem directly
from the feature that makes them different from AAAA RRs: the ability from the feature that makes them different from AAAA RRs: the ability
to build up addresses via chaining. to build up addresses via chaining.
skipping to change at page 4, line 11 skipping to change at page 3, line 20
Last, several of the most interesting potential applications for A6 Last, several of the most interesting potential applications for A6
RRs involve situations where the prefix name field in the A6 RR 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 points to a target that is not only outside the DNS zone containing
the A6 RR, but is administered by a different organization entirely. the A6 RR, but is administered by a different organization entirely.
While pointers out of zone are not a problem per se, experience both 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 with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
pointers to other organizations are often not maintained properly, pointers to other organizations are often not maintained properly,
perhaps because they're less susceptible to automation than pointers perhaps because they're less susceptible to automation than pointers
within a single organization would be. within a single organization would be.
2.2 Recommended standard action 2.2 Recommended Standard Action
Based on the perceived consensus, this document recommend that RFC Based on the perceived consensus, this document recommends that RFC
1886 stay on standards track and be advanced, while moving RFC 2874 1886 stay on standards track and be advanced, while moving RFC 2874
to Experimental status. to Experimental status.
3 - Bitlabels in the reverse DNS tree 3. Bitlabels in the Reverse DNS Tree
RFC 2673 defines a new DNS label type. This was the first new type 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 defined since RFC 1035 [RFC1035]. Since the development of 2673 it
been learned that deployment of a new type is difficult since DNS has been learned that deployment of a new type is difficult since DNS
servers that do not support bitlabels reject queries containing bit servers that do not support bitlabels reject queries containing bit
labels as being malformed. The community has also indicated that this labels as being malformed. The community has also indicated that
new label type is not needed for mapping reverse addresses. this new label type is not needed for mapping reverse addresses.
3.1 Rationale 3.1 Rationale
The hexadecimal text representation of IPv6 addresses appears to be The hexadecimal text representation of IPv6 addresses appears to be
capable of expressing all of the delegation schemes that we expect to capable of expressing all of the delegation schemes that we expect to
be used in the DNS reverse tree. be used in the DNS reverse tree.
3.2 Recommended standard action 3.2 Recommended Standard Action
RFC 2673 standard status is to be changed from Proposed to RFC 2673 standard status is to be changed from Proposed to
Experimental. Future standardization of these documents is to be done Experimental. Future standardization of these documents is to be
by the DNSEXT working group or its successor. done by the DNSEXT working group or its successor.
4 DNAME in IPv6 reverse tree 4. DNAME in IPv6 Reverse Tree
The issues for DNAME in the reverse mapping tree appears to be The issues for DNAME in the reverse mapping tree appears to be
closely tied to the need to use fragmented A6 in the main tree: if 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 one is necessary, so is the other, and if one isn't necessary, the
other isn't either. Therefore, in moving RFC 2874 to experimental, other isn't either. Therefore, in moving RFC 2874 to experimental,
the intent of this document is that use of DNAME RRs in the reverse the intent of this document is that use of DNAME RRs in the reverse
tree be deprecated. tree be deprecated.
5 Acknowledgments 5. Acknowledgments
This document is based on input from many members of the various IETF This document is based on input from many members of the various IETF
working groups involved in this issues. Special thanks go to the working groups involved in this issues. Special thanks go to the
people that prepared reading material for the joint DNSEXT and people that prepared reading material for the joint DNSEXT and
NGTRANS working group meeting at the 51st IETF in London, Rob NGTRANS working group meeting at the 51st IETF in London, Rob
Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino, Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
Christian Huitema. Number of other people have made number of Christian Huitema. Number of other people have made number of
comments on mailing lists about this issue including Andrew W. comments on mailing lists about this issue including Andrew W.
Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
Savola, Paul Vixie. Savola, Paul Vixie.
6 - Security Considerations: 6. Security Considerations
As this document specifies a course of action, there are no direct As this document specifies a course of action, there are no direct
security considerations. There is an indirect security impact of the security considerations. There is an indirect security impact of the
choice, in that the relationship between A6 and DNSSEC is not well choice, in that the relationship between A6 and DNSSEC is not well
understood throughout the community, while the choice of AAAA does understood throughout the community, while the choice of AAAA does
leads to a model for use of DNSSEC in IPv6 networks which parallels leads to a model for use of DNSSEC in IPv6 networks which parallels
current IPv4 practice. current IPv4 practice.
7 - IANA Considerations: 7. IANA Considerations
None. None.
Normative References: Normative References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification'' STD 13, RFC 1035, November 1987. Specification", STD 13, RFC 1035, November 1987.
[RFC1886] S. Thompson, C. Huitema, ``DNS Extensions to support IP [RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP
version 6'', RFC 1886, December 1995. version 6", RFC 1886, December 1995.
[RFC2673] M. Crawford ``Binary Labels in the Domain Name System``, RFC [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
2673, August 1999. RFC 2673, August 1999.
[RFC2874] M. Crawford, C. Huitema, ``DNS Extensions to Support IPv6 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
Address Aggregation and Renumbering'', RFC 2874, July 2000. IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
[RFC3152] R. Bush, ``Delegation of IP6.ARPA'', RFC 3152 also BCP0049, [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
August 2001, August 2001.
Informative References Informative References
[Tradeoff] R. Austein, ``Tradeoffs in DNS support for IPv6'', Work in [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
progress, draft-ietf-dnsext-ipv6-dns-tradeoffs-xx.txt, June Support for Internet Protocol version 6 (IPv6)", RFC 3364,
2002. August 2002.
Editors Address Editors' Addresses
Randy Bush <randy@psg.com> Randy Bush
Alain Durand <alain.durand@sun.com> EMail: randy@psg.com
Bob Fink <fink@es.net>
Olafur Gudmundsson <ogud@ogud.com> Alain Durand
Tony Hain <hain@tndh.net> EMail: alain.durand@sun.com
Bob Fink
EMail: fink@es.net
Olafur Gudmundsson
EMail: ogud@ogud.com
Tony Hain
EMail: hain@tndh.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
skipping to change at page 6, line 39 skipping to change at page 6, line 31
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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