この文書はRFC3363の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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)
インターネットプロトコルバージョン６（ＩＰｖ６）アドレスの
ドメインネームシステム（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.
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.
この文書は、ＤＮＳでのＩＰｖ６アドレスの直接マップと逆マップを定義する
ＲＦＣの標準状態を明確にして更新します。この文書は実験状態にＡ６とビッ
トラベル仕様を動かします。
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.
ＩＥＴＦはAAAA[RFC1886]とＡ６[RFC2874]の２つの異なる標準化提案されて
いるＩＰｖ６アドレスフォーマットの標準化手順を開始しました。これは、
どちらを実装すべきかの混乱と対立を導きました。複数の選択を持つことは
ＩＰｖ６の展開に遅れを生じるだろうとの共同体の感じがあるので、このエ
リアで混乱の解明は展開に重要です。この文書のゴールは状態を明確にする
ことです。
This document also discusses issues relating to the usage of Binary
Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
この文書は同じくＩＰｖ６アドレスの逆のマッピングをサポートするための
バイナリラベル[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.
この文書は、種々の適切なワーキンググループメーリングリストと、２００
１年８月の第５１回ＩＥＴＦにおける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].
逆のＩＰｖ６アドレスマップのルートの問題はこの文書の範囲外で、異なる
文書[RFC3152]でカバーされます。
1.1 Standards Action Taken
1.1 標準行動
This document changes the status of RFCs 2673 and 2874 from Proposed
Standard to Experimental.
この文書は提案標準から実験的へRFC2673とRFC2874の状態を変えます。
2. IPv6 Addresses: AAAA RR vs A6 RR
2. ＩＰｖ６アドレス：AAAA資源レコード対Ａ６資源レコード
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レコードがＩＰｖ６展開には今のところ望ましく、。
b) that A6 records have interesting properties that need to be better
understood before deployment.
b) Ａ６レコードは面白い機能を持ち、展開前によりよく理解できていなけれ
ばならない。
c) It is not known if the benefits of A6 outweigh the costs and
risks.
c) Ａ６の利点が、コストや危険性より重要かどうかは周知ではありません。
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資源レコードと異なるＡ６資源レコードの機能から直接生じるいくつか
の可能性がある問題があります：鎖によるアドレス構築能力。
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.
Ａ６資源レコードの連鎖を解決することは、ほぼ独立な一連の問合せを解決
することを伴います。これらの副質問のそれぞれが、答えがたまたますでに
リゾルバのローカルキャッシュにないなら、いくらかのゼロでない時間がか
かります。他のことが同じでも、Ａ６資源レコードのＮリンクチェーンを解
決する際におよそＮ倍かかると思います。我々が持っているわずかなデータ
すべてはユーザーがすでにＩＰｖ４インターネットでＡ資源レコード解決に
かかる時間の長さに我慢できないことを示唆しており、ユーザーがＩＰｖ６
インターネットで長い遅延に忍耐強い可能性が高くないので、速く問合せを
終了させることはリソース浪費とユーザーフラストレーションの両方に必要
です。それで、我々は長いＡ６鎖の無差別な使用がユーザーフラストレーショ
ンを増やす可能性が高いと結論しなければなりません。
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.
一つのＡ６問合せの失敗の可能性はひとつの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.
最後に、Ａ６資源レコードの最も興味深い点が、Ａ６資源レコードのプレ
フィックス名フィールドが、他のＤＮＳゾーンを示すというだけでなく、完
全に異なった組織によって運用されるＡ６資源レコードを指し示す事です。
ゾーン外を示すポインタが本質的に問題ではないが、グルー資源レコードと
IN-ADDR.ARPA木でのPTR資源レコードの経験が共に、他の組織へのポインタ
が、多分同じ組織内のポインタに比べて自動的に処理されていないため、し
ばしば正確に維持されていないことを示唆します。
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 2874を実験的な状態に動か
すが。RFC1886が標準化手続きに留まり進行するのを勧めます。
3. Bitlabels in the Reverse DNS Tree
3. 逆ＤＮＳ木でのビットラベル
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が新しいＤＮＳラベルタイプを定義します。これはRFC1035
[RFC1035]で定義される最初の新しいタイプでした。２６７３の開発によって、
ビットラベルをサポートしないＤＮＳサーバーがフォーマットエラーとして
ビットラベルを含んでいる問合せを拒絶するので、新しいタイプの配置が困
難なことが学ばれました。共同体は同じくこの新しいラベルタイプが逆のア
ドレスマップを表わすことに対して必要とされないことを示しました。
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.
ＩＰｖ６アドレスの１６進数テキスト代表は我々が 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の標準状態がProposedからExperimentalに変えられるはずです。
これらの文書の未来の標準化がDNSEXTワーキンググループあるいはその後
継者によってされるはずです。
4. DNAME in IPv6 Reverse Tree
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.
逆マッピング木でのDNAMEの問題がメイン木で分割されたＡ６を使う必要と
密接に結びつくように思われます：もし１つが必要なら他も必要で、もし１
つが必要ないなら、他も必要ありません。それ故にRFC 2874を実験的にす
る事において、この文書の意志は逆木でのDNAME資源レコードの使用を廃止
することです。
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.
この文書はこの問題に関係している種々のＩＥＴＦワーキンググループの多
くのメンバーからのインプットに基づいています。特別な感謝が、ロンドン
の第５１回ＩＥＴＦでの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。
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.
この文書が行動の進路を指定するから、直接のセキュリティ考慮がありま
せん。Ａ６とDNSSECの間の関係が共同体全体で上手に理解されないという
点で、選択が間接的にセキュリティに影響します、他方AAAAの選択は現在
のＩＰｖ４に類似するＩＰｖ６ネットワークでのDNSSECの使用のモデルが
手がかりになります。
7. IANA Considerations
7. ＩＡＮＡの考慮
None.
なし
Normative References
参照する参考文献
[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.
Informative References
インフォメーションの参考文献
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)", RFC 3364,
August 2002.
Editors' Addresses
著者のアドレス
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
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。