Network Working Group                                            R. Bush
Request for Comments: 3363                                     A. Durand
Updates: 2673, 2874                                              B. Fink
Category: Informational                                   O. Gudmundsson
                                                                 T. Hain
                                                                 Editors
                                                             August 2002
        
            Representing Internet Protocol version 6 (IPv6)
               Addresses in the Domain Name System (DNS)
        

Status of this Memo

このメモの位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2002). All Rights Reserved.

著作権(C)インターネット協会(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.

このドキュメントは明確にし、直接定義し、DNSでIPv6アドレスのマップを逆にRFCの標準ステータスを更新します。この文書では、実験的なステータスにA6とビットラベル仕様を移動します。

1. Introduction
1. はじめに

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.

IPv6はAAAA [RFC1886]およびA6 [RFC2874]を解決するためのIETFは、二つの異なるアドレスフォーマットを標準化するプロセスを開始したとの両方が提案された標準です。これは混乱して展開する1上の紛争につながっていました。これは、複数の選択肢を持つことがIPv6導入の遅れにつながることをコミュニティの感覚があるとして、この分野での混乱は、アップクリアされ、展開するために重要です。このドキュメントの目標は、状況を明らかにすることです。

This document also discusses issues relating to the usage of Binary Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.

この文書はまた、IPv6アドレスの逆のマッピングをサポートするために、バイナリラベル[RFC 2673]の使用に関連する問題について説明します。

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.

この文書は、2001年8月に第51回IETFでのリストと共同DNSEXTとNGTRANS会議を郵送する様々な関連するワーキンググループに関する広範な技術的な議論に基づいています。この文書では、議論の感覚をキャプチャし、コンセンサスを表現するには、この文書に反映しようとしますコミュニティの。

The main arguments and the issues are covered in a separate document [RFC3364] that reflects the current understanding of the issues. This document summarizes the outcome of these discussions.

主な議論と問題は、問題の現在の理解を反映した別の文書[RFC3364]でカバーされています。この文書では、これらの議論の結果をまとめました。

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].

逆のIPv6アドレスマップのルートの問題は、この文書の範囲外であり、別の文書[RFC3152]で覆われています。

1.1 Standards Action Taken
1.1標準アクション撮影

This document changes the status of RFCs 2673 and 2874 from Proposed Standard to Experimental.

この文書では、実験的に標準化提案からのRFC 2673および2874のステータスを変更します。

2. IPv6 Addresses: AAAA RR vs A6 RR
2. IPv6アドレス:A6 RR対AAAAのRR

Working group consensus as perceived by the chairs of the DNSEXT and NGTRANS working groups is that:

DNSEXTとNGTRANSワーキンググループの議長によって知覚されるワーキンググループのコンセンサスは、次のとおりです。

a) AAAA records are preferable at the moment for production deployment of IPv6, and

A)AAAAレコードは、IPv6の運用展開のため、現時点で好ましく、

b) that A6 records have interesting properties that need to be better understood before deployment.

b)はA6レコードは、より良い展開の前に理解する必要がある興味深い性質を持っていること。

c) It is not known if the benefits of A6 outweigh the costs and risks.

C)それは、A6の利点は、コストとリスクを上回る場合には知られていません。

2.1 Rationale
2.1理論的根拠

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.

チェーンを経由してアドレスを構築する能力:AAAAのRRから彼らは違う機能から直接幹A6のRRにはいくつかの潜在的な問題があります。

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.

A6 RRの連鎖を解決することはほとんど依存しないクエリであるかのシリーズを解決含まれます。答えはすでにリゾルバのローカルキャッシュにあることを起こる場合を除き、これらのサブクエリのそれぞれは、時間のいくつかの非ゼロ量を要します。他の物事が等しい、我々はそれがA6 RRのN-リンクチェーンを解決するのにかかる時間は、我々が持っているどのようなデータNにほぼ比例なることを期待して、ユーザーが既にそれはRRを解決するのにかかる時間の長さにせっかちであることを示唆していますユーザーがIPv6インターネットで有意に長い遅延と患者である可能性が高いではないですが、途中でクエリを終了すると、資源の浪費とユーザーフラストレーションの別のソースの両方であることを示唆しているIPv4インターネット、インチしたがって、我々は長いA6連鎖の無差別使用が増加し、ユーザーの不満につながる可能性があると結論することを余儀なくされています。

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.

A6チェーンの解決に関与するクエリの各々が単一のAAAAクエリとして故障のほぼ同じ確率を有するので、N-リンクA6鎖を解決するプロセスの間に故障の確率も、Nにほぼ比例するように思われます。

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 within a single organization would be.

最後に、A6のRRのための最も興味深い潜在的なアプリケーションのいくつかだけでなく、A6 RRを含むDNSゾーンの外にあるが、全く別の組織によって管理されたターゲットへのA6のRRポイントでのプレフィックス名フィールド状況を伴います。ゾーンのうちポインタはそれ自体が問題ではありませんが、IN-ADDR.ARPAツリーに接着剤のRRとRRとPTR RRの両方経験し、彼らが自動化の影響を受けにくくしているかもしれないので、他の団体へのポインタが、多くの場合、適切に維持されていないことを示唆しています単一の組織内でのポインタは次のようになりより。

2.2 Recommended Standard Action
2.2推奨標準アクション

Based on the perceived consensus, this document recommends that RFC 1886 stay on standards track and be advanced, while moving RFC 2874 to Experimental status.

認知コンセンサスに基づくと、この文書は、規格上のRFC 1886の滞在が追跡し、実験的なステータスにRFC 2874を動かしながら、前進することをお勧めします。

3. Bitlabels in the Reverse DNS Tree
リバースDNSツリーの3 Bitlabels

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.

RFC 2673には、新しいDNSラベルタイプを定義します。これは、RFC 1035 [RFC1035]以来、定義された最初の新しいタイプでした。 2673年の開発以来、bitlabelsをサポートしていないDNSサーバが不正な形式であるとしてビットラベルを含むクエリを拒否するため、新しいタイプの展開が困難であることを学習されています。コミュニティはまた、この新しいラベルタイプが逆のアドレスをマッピングするために必要とされていないことが示されました。

3.1 Rationale
3.1理論的根拠

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.

IPv6アドレスを16進テキスト表現は、私たちがDNSの逆ツリーに使用されることを期待委任スキームの全てを表現することができるように表示されます。

3.2 Recommended Standard Action
3.2推奨標準アクション

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.

実験的に提案からRFC 2673個の標準的なステータスが変更されます。これらの文書の今後の標準化がDNSEXTワーキンググループまたはその後継で行う必要があります。

4. DNAME in IPv6 Reverse Tree
IPv6の逆ツリーの4 DNAME

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 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, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated.

ので、他で、1が必要な場合、もう1つは必要でない場合は、他のいずれかではありません。逆マッピング木でDNAMEについての問題は密接にメインツリーに断片化されたA6を使用する必要性に結びついているように見えます。したがって、実験的にRFC 2874を移動させる際に、この文書の目的は、逆ツリー内のDNAME RRの使用は推奨されていることがあります。

5. Acknowledgments
5.謝辞

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.

この文書では、この問題に関与する様々なIETFワーキンググループの多くのメンバーからの入力に基づいています。特別な感謝は、第51回ロンドンでIETF、ロブAusteinと、ダン・バーンスタイン、マット・クロフォード、Jun-ichiro itojun Haginoは、クリスチャンのHuitemaで共同DNSEXTとNGTRANSワーキンググループ会議用の資料を読んで準備人々に行きます。他の人の数は、アンドリュー・W・バークレー、ロバート・エルツ、ヨハンIhren、エドワード・ルイス、ビル・マニング、ペッカSavola、ポール・ヴィクシーを含め、この問題についてのメーリングリスト上でコメントの数を作りました。

6. Security Considerations
6.セキュリティの考慮事項

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.

この文書は、アクションのコースを指定すると、は直接セキュリティ上の考慮事項はありません。選択肢の間接的なセキュリティへの影響はAAAAの選択は、現在のIPv4の練習に匹敵するIPv6ネットワークでのDNSSECの使用のためのモデルにリードを行いながら、その中でA6とDNSSECとの間の関係はよく、コミュニティ全体に理解されていない、があります。

7. IANA Considerations
7. IANAの考慮事項

None.

無し。

Normative References

引用規格

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。

[RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.

"IPバージョン6をサポートするためのDNS拡張機能" [RFC1886]トンプソン、S.とC.のHuitema、RFC 1886、1995年12月。

[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.

[RFC2673]クロフォード、M.、 "ドメインネームシステムにおけるバイナリラベル"、RFC 2673、1999年8月。

[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.

[RFC2874]クロフォード、M.とC.のHuitemaは、RFC 2874、2000年7月 "DNSの拡張機能は、IPv6アドレスの集約とリナンバリングを支援します"。

[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152 August 2001.

[RFC3152]ブッシュ、R.、 "IP6.ARPAの委任"、BCP 49、RFC 3152 2001年8月。

Informative References

参考文献

[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.

[RFC3364] Austeinと、R.、 "ドメインネームシステム(DNS)でのトレードオフのインターネットプロトコルバージョン6(IPv6)のサポート"、RFC 3364、2002年8月。

Editors' Addresses

エディタのアドレス

Randy Bush EMail: randy@psg.com

ランディブッシュEメール:randy@psg.com

Alain Durand EMail: alain.durand@sun.com

アラン・デュランEメール:alain.durand@sun.com

Bob Fink EMail: fink@es.net

ボブ・フィンクEメール:fink@es.net

Olafur Gudmundsson EMail: ogud@ogud.com

オラフルグドムンソンEメール:ogud@ogud.com

Tony Hain EMail: hain@tndh.net

トニーハインEメール:hain@tndh.net

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

著作権(C)インターネット協会(2002)。全著作権所有。

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.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。