[要約] RFC 3363は、IPv6アドレスをDNSで表現するための方法を提案しています。目的は、IPv6アドレスを効果的にDNSに統合し、インターネット上のネットワーク通信をサポートすることです。
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)
インターネットプロトコルを表すバージョン6（IPv6）ドメイン名システム（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.
Copyright（c）The Internet Society（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およびビットラベルの仕様を実験ステータスに移動します。
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.
IETFは、IPv6アドレスAAAA [RFC1886]およびA6 [RFC2874]の2つの異なるアドレス形式の標準化プロセスを開始し、両方とも提案されている標準です。これにより、展開する混乱と対立が生まれました。コミュニティには、複数の選択肢があると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].
Reverse IPv6アドレスマップのルートの問題は、このドキュメントの範囲外であり、別のドキュメント[RFC3152]で説明されています。
This document changes the status of RFCs 2673 and 2874 from Proposed Standard to Experimental.
このドキュメントは、提案された標準から実験的にRFCS 2673および2874のステータスを変更します。
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の利点がコストとリスクを上回るかどうかは不明です。
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 RRSとは異なる機能に直接由来するA6 RRSには、チェーンを介してアドレスを構築する機能を備えたいくつかの潜在的な問題があります。
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 RRSのチェーンを解決するには、ほぼ独立したクエリのシリーズを解決することが含まれます。回答がすでにリゾルバーのローカルキャッシュに含まれていない限り、これらのサブQuerieはそれぞれゼロ以外の時間がかかります。他のことは平等であると予想されますが、A6 RRSのNリンクチェーンを解決するのにかかる時間はNにほぼ比例します。ユーザーがRRSを解決するのにかかる時間にすでに焦りがちであることを示唆しています。IPv4インターネットでは、ユーザーはIPv6インターネットの大幅な遅延が患者である可能性が高いことを示唆していますが、クエリを時期尚早に終了することは、リソースの無駄とユーザーのフラストレーションのソースの両方です。したがって、長い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-Link 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 RRSの最も興味深い潜在的なアプリケーションのいくつかには、A6 RRのプレフィックス名フィールドがA6 RRを含むDNSゾーンの外側だけでなく、異なる組織によって完全に管理されるターゲットを指している状況が含まれます。ゾーンからのポインターはそれ自体問題ではありませんが、接着剤RRSとIn-ADDR.ARPAツリーのPTR RRの両方での経験は、おそらく自動化の影響を受けにくいため、他の組織へのポインターが適切に維持されないことが多いことを示唆しています。単一の組織内のポインターよりも。
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 2874を実験ステータスに移動しながら、RFC 1886の標準軌道に留まり、進歩することを推奨しています。
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サーバーがビットラベルを含むクエリを奇形で拒否するため、新しいタイプの展開は困難であることがわかりました。コミュニティはまた、この新しいラベルタイプが逆アドレスをマッピングするために必要ではないことを示しています。
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逆ツリーで使用されると予想されるすべての委任スキームを表現できるようです。
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ワーキンググループまたはその後継者によって行われます。
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.
逆マッピングツリーのDNAMEの問題は、メインツリーで断片化されたA6を使用する必要性と密接に結びついているように見えます。。したがって、RFC 2874を実験的に移動する際に、このドキュメントの意図は、逆ツリーでのDNAME RRの使用が非推奨であることです。
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で開催された共同DNSEXTとNGTRANSワーキンググループ会議の読書資料を準備してくれた人々に感謝します。他の人の数は、アンドリュー・W・バークレイ、ロバート・エルツ、ヨハン・イーレン、エドワード・ルイス、ビル・マニング、ペッカ・サヴォラ、ポール・ビクシーなど、この問題についてメーリングリストに多くのコメントをしています。
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.
このドキュメントは一連の行動を指定するため、直接的なセキュリティ上の考慮事項はありません。A6とDNSSECの関係はコミュニティ全体で十分に理解されていないという点で、この選択には間接的なセキュリティへの影響がありますが、AAAAの選択は、現在のIPv4プラクティスに似ているIPv6ネットワークでのDNSSECを使用するモデルにつながります。
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.
[RFC1886] Thompson、S。およびC. Huitema、「IPバージョン6をサポートするDNS拡張」、RFC 1886、1995年12月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673] Crawford、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] Crawford、M。およびC. Huitema、「IPv6アドレスの集約と変更をサポートするDNS拡張」、RFC 2874、2000年7月。
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152 August 2001.
[RFC3152] Bush、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。、「インターネットプロトコルバージョン6（IPv6）のドメイン名システム（DNS）サポートのトレードオフ」、RFC 3364、2002年8月。
Editors' Addresses
編集者のアドレス
Randy Bush EMail: randy@psg.com
ランディブッシュメール：randy@psg.com
Alain Durand EMail: alain.durand@sun.com
Alain Durandメール：alain.durand@sun.com
Bob Fink EMail: fink@es.net
Bob Finkメール：fink@es.net
Olafur Gudmundsson EMail: ogud@ogud.com
Olafur Gudmundssonメール：ogud@ogud.com
Tony Hain EMail: hain@tndh.net
Tony Hain Email：hain@tndh.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。