広告
広告
https://www.7key.jp/rfc/rfc3363.html#sourcehttps://www.7key.jp/rfc/rfc3363.html#translationThis memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
当文書はインターネットコミュニティに役立つであろう情報を提供するものであり、これによって標準的なインターネット像をでっちあげようとするものではない。また、当メモは配布に関しての制限を設けていない。
Copyright (C) The Internet Society (2002). All Rights Reserved.
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は、標準化提案のなされているAAAA[RFC1886]及びA6[RFC2874]とのIPv6アドレス用の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アドレスの逆マッピングをサポートするためのバイナリラベル[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]でカバーされる。
This document changes the status of RFCs 2673 and 2874 from Proposed Standard to Experimental.
当文書は、標準提案から実験的RFCへRFC2673及び2874の状態を変更するものである。
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.
DNSEXT及びNGTRANSワーキンググループの議長によって認識されているワーキンググループの総意は次の通り：
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リソースレコードと異なる特徴から直接生じるA6リソースレコードによるいくつかの潜在的な問題がある。連鎖法によるアドレス構築能力。
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リソースレコード連鎖の解決は、ほぼ独立なクエリの連続を解決することを伴う。既に答えがリゾルバのローカルキャッシュにないのであれば、これらのサブクエリのそれぞれはいくらかの時間を費やすこととなる。他の情報が等しくても、A6リソースレコードのNリンク連鎖を解決するためにおよそN倍の時間を費やすことになると予想する。ユーザはIPv4インターネットでAリソースレコードを解決するために費やす時間に我慢ができないことを我々の持つ全てのデータが示唆しており、ユーザが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リンク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リソースレコードの最も興味深い潜在的なアプリケーションのいくつかは、A6リソースレコードのプレフィックス名フィールドが他のDNSゾーンを含むA6リソースレコードを示すだけでなく、完全に異なる組織によって運用されるA6リソースレコードを示すということである。ゾーンを示すポインタは本質的な問題ではないが、他の組織へのポインタはおそらく同じ組織内のポインタとは違い自動的に処理されないため、グルーリソースレコードとIN-ADDR.ARPAツリーでのPTRリソースレコードの事例によって正確に維持されないこともあることが示唆される。
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へと変更するが、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の開発によって、ビットラベルをサポートしない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を用いる必要と密接に結びつくと想定される。もし1つ必要となれば他も必要となり、1つが必要なければ他も必要ない。そのため、RFC 2874を実験的にすることにおいて、当文書では逆ツリーでのDNAMEリソースレコードの使用を廃止することを目的とする。
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ワーキンググループ共同ミーティングの資料を準備頂いた、Rob Austein氏、Dan Bernstein氏、Matt Crawford氏、Jun-ichiro itojun Hagino氏、Christian Huitema氏に多大なる謝辞を述べる。またこの問題について、Andrew W. Barclay氏、Robert Elz氏、Johan Ihren氏、Edward Lewis氏、Bill Manning氏、Pekka Savola氏、Paul Vixie氏を始めとする多数の方々からメーリングリストにて多くのコメントを頂いた。
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の関係がコミュニティを通して理解されないとの点で選択の間接的なセキュリティインパクトがある。
None.
なし。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, December 1995.
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
August 2001.
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)", RFC 3364,
August 2002.
Randy Bush EMail: randy@psg.com Alain Durand EMail: alain.durand@sun.com Bob Fink EMail: fink@es.net Olafur Gudmundsson EMail: ogud@ogud.com Tony Hain EMail: hain@tndh.net
Copyright (C) The Internet Society (2003). 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 implmentation 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.
当文書とそれに含む情報は無保証で提供され、そしてインターネット学会とIETFは――明示的にも暗黙的にも――この情報の利用が権利を侵害しないことや、特別の目的への利用に適当であることの保証を含め、全ての保証を拒否するものである。
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC編集者の職務に対する資金供給は、現在インターネット学会から提供されている。
広告