RFC3363 日本語訳
3363 Representing Internet Protocol version 6 (IPv6) Addresses in theDomain Name System (DNS). R. Bush, A. Durand, B. Fink, O.Gudmundsson, T. Hain. August 2002. (Format: TXT=11055 bytes) (Updates RFC2673, RFC2874) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループR.ブッシュの要求をネットワークでつないでください: 3363のA.ジュランドアップデート: 2673、2874B.密告者カテゴリ: 情報のO.グドムンソンT.ハインエディターズ2002年8月
Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
プロトコルバージョン6(IPv6)がドメインネームシステムで記述するインターネットを表します。(DNS)
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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アドレスの地図をダイレクトに定義して、覆すRFCsの規格状態をはっきりさせて、アップデートします。 このドキュメントはA6とBitラベル仕様を実験状態に動かします。
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.
IETFはIPv6アドレスのAAAA[RFC1886]とA6[RFC2874]のために2つの異なったアドレス形式を標準化するプロセスを開始して、ともに提案された標準にあります。 これは展開する混乱と闘争に通じました。 展開に、この領域でのどんな混乱も解決されるのは、重要です、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アドレスの逆のマッピングを支持するためにBinary Labels[RFC2673]の使用法に関連する問題について議論します。
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月の第51IETFで様々な関連ワーキンググループメーリングリストの大規模な技術面の協議、共同DNSEXT、およびNGTRANSミーティングに基づいています。 このドキュメントは、議論の感覚を得て、共同体のコンセンサスを表すために本書ではそれらを反映するのを試みます。
Bush, et. al. Informational [Page 1] RFC 3363 Representation of IPv6 Addresses in DNS August 2002
etブッシュ、アル。 DNS2002年8月のIPv6アドレスの情報[1ページ]のRFC3363表現
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.
このドキュメントはRFCs2673と2874年の状態をProposed StandardからExperimentalに変えます。
2. IPv6 Addresses: AAAA RR vs A6 RR
2. IPv6アドレス: AAAA RR対A6 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) そしてIPv6の生産展開に、AAAA記録が現在望ましい。
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 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のチェーンを決議するのは、何に関するシリーズがほとんど独立している質問であるかと決議することを伴います。 それぞれのこれらのサブ質問はいくらかの非ゼロ時間がかかります、リゾルバのローカルなキャッシュに答えがたまたま既にない場合。 他のものが等しくて、私たちは、それが私たちが持っているN.Whatデータに比例しているとA6 RRsのN-リンク・チェーンがおよそなる決議するわざわざが、ユーザが既にユーザがIPv6インターネットのかなり長い遅れに我慢強い傾向がないと示唆するIPv4インターネットでA RRsを決議するにはかかる時間の長さにせっかちであると示唆すると予想しますが、早まって質問を終えるのは、リソースの浪費とユーザフラストレーションの別の源の両方です。 したがって、私たちは、長いA6チェーンの広範囲な使用に増加するユーザフラストレーションに通じそうであるとやむを得ず結論を下します。
Bush, et. al. Informational [Page 2] RFC 3363 Representation of IPv6 Addresses in DNS August 2002
etブッシュ、アル。 DNS2002年8月のIPv6アドレスの情報[2ページ]のRFC3363表現
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.
また、N-リンクA6チェーンを決議する過程の間の失敗の確率はおよそNに比例しているように見えます、A6チェーンを決議するのにかかわるそれぞれの質問がただ一つのAAAA質問としての失敗のおよそ同じ確率を持っているので。
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とPTR RRsのIN-ADDR.ARPA木の経験は、他の組織へのポインタがしばしば適切に維持されるというわけではないのを示します、恐らく彼らが単純組織の中のポインタであるだろうよりオートメーションに影響されやすくないので。
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.
知覚されたコンセンサスに基づいて、このドキュメントはRFC2874をExperimental状態に動かしている間、RFC1886が標準化過程の上にいて、高度であることを推薦します。
3. Bitlabels in the Reverse DNS Tree
3. 逆のDNS木の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.
RFC2673は新しいDNSラベル形式を定義します。 これはRFC1035[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.
RFC2673の標準の状態はProposedからExperimentalに変えることです。 これらのドキュメントの将来の規格化はDNSEXTワーキンググループかその後継者によって行われることです。
Bush, et. al. Informational [Page 3] RFC 3363 Representation of IPv6 Addresses in DNS August 2002
etブッシュ、アル。 DNS2002年8月のIPv6アドレスの情報[3ページ]のRFC3363表現
4. DNAME in IPv6 Reverse Tree
4. IPv6の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.
逆のマッピング木のDNAMEが、密接に使用する必要性に結ばれるように見えるので、問題は主な木でA6を断片化しました: 1つが必要であるなら、もう片方もそうです、そして、1つは必要でないなら、もう片方がどちらかではありません。 したがって、RFC2874を実験的に動かすのにおいて、このドキュメントの意図は逆の木におけるDNAME RRsの使用が非難されるということです。
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ワーキンググループの多くのメンバーからの入力に基づいています。 特別な感謝は共同DNSEXTとNGTRANSワーキンググループミーティングのためにロンドン、ロブAustein、ダン・バーンスタイン、マット・クロフォードにおける第51IETFで読み物を準備した人々のものになります、6月-ichiro itojun Hagino、クリスチャンのHuitema。 アンドリュー・W.バークレーを含んでいて、他の人々の数はこの問題に関するメーリングリストでコメントの数を作りました、ロバートElz、ジョハンIhren、エドワード・ルイス、ビル・マニング、ペッカSavola、ポールVixie。
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.
このドキュメントが行動を指定するとき、どんなダイレクトセキュリティ問題もありません。 選択の間接的なセキュリティ影響があります、A6とDNSSECとの関係が共同体中でよく理解されていないので、AAAAの選択はIPv6ネットワークにおけるDNSSECの現在のIPv4習慣に沿う使用のためにモデルに導きますが。
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.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.
IPを支持してください。[RFC1886] トンプソン、S.、およびC.Huitema、「DNS Extensions、バージョン6インチ、RFC1886、1995インチ年12月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673] クロフォード、M.、「ドメインネームシステムにおける2進のラベル」、RFC2673、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、「IPv6アドレス集合を支持して、番号を付け替えることへのDNS拡張子」、RFC2874、2000年7月。
Bush, et. al. Informational [Page 4] RFC 3363 Representation of IPv6 Addresses in DNS August 2002
etブッシュ、アル。 DNS2002年8月のIPv6アドレスの情報[4ページ]のRFC3363表現
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152 August 2001.
[RFC3152] ブッシュ、R.、「IP6.ARPAの代表団」、BCP49、RFC3152 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)サポートにおける見返り」、RFC3364、2002年8月。
Editors' Addresses
エディタのアドレス
Randy Bush EMail: randy@psg.com
ランディブッシュEMail: randy@psg.com
Alain Durand EMail: alain.durand@sun.com
アランジュランドEMail: alain.durand@sun.com
Bob Fink EMail: fink@es.net
ボブ密告者メール: fink@es.net
Olafur Gudmundsson EMail: ogud@ogud.com
OlafurグドムンソンEMail: ogud@ogud.com
Tony Hain EMail: hain@tndh.net
トニーハインEMail: hain@tndh.net
Bush, et. al. Informational [Page 5] RFC 3363 Representation of IPv6 Addresses in DNS August 2002
etブッシュ、アル。 DNS2002年8月のIPv6アドレスの情報[5ページ]のRFC3363表現
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Bush, et. al. Informational [Page 6]
etブッシュ、アル。 情報[6ページ]
一覧
スポンサーリンク