この文書はRFC3364の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group R. Austein
Request for Comments: 3364 Bourgeois Dilettant
Updates: 2673, 2874 August 2002
Category: Informational
Tradeoffs in Domain Name System (DNS) Support
for Internet Protocol version 6 (IPv6)
インターネットプロトコルバージョン６（ＩＰｖ６）に対する
ドメインネームシステム（ＤＮＳ）サポートでのトレードオフ
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
概要
The IETF has two different proposals on the table for how to do DNS
support for IPv6, and has thus far failed to reach a clear consensus
on which approach is better. This note attempts to examine the pros
and cons of each approach, in the hope of clarifying the debate so
that we can reach closure and move on.
ＩＥＴＦはＩＰｖ６に対するＤＮＳサポートする異なる２つの提案を持って
いて、これまでのところどちらのアプローチが良いかについて明確な意見一
致に達することに失敗しました。このメモは各アプローチへの賛否両論を調
べる試みで、我々が討論を明確にして討論終結に達して、前進するこ希望を
試みます。
Introduction
はじめに
RFC 1886 [RFC1886] specified straightforward mechanisms to support
IPv6 addresses in the DNS. These mechanisms closely resemble the
mechanisms used to support IPv4, with a minor improvement to the
reverse mapping mechanism based on experience with CIDR. RFC 1886 is
currently listed as a Proposed Standard.
RFC 1886 [RFC1886]はＤＮＳでＩＰｖ６アドレスをサポートするための率直な
メカニズムを指定しました。これらのメカニズムはＩＰｖ４をサポートするた
めに使われた機構に似ていて、ＣＩＤＲの経験に基づいて逆のマップ作成メカ
ニズムへのマイナーな改良をしています。RFC 1886が現在Proposed Standard
と記録されます。
RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
addresses in the DNS. These mechanisms provide new features that
make it possible for an IPv6 address stored in the DNS to be broken
up into multiple DNS resource records in ways that can reflect the
network topology underlying the address, thus making it possible for
the data stored in the DNS to reflect certain kinds of network
topology changes or routing architectures that are either impossible
or more difficult to represent without these mechanisms. RFC 2874 is
also currently listed as a Proposed Standard.
RFC 2874 [RFC2874]はＤＮＳでＩＰｖ６アドレスをサポートする拡張メカニズ
ムを指定しました。これらのメカニズムは新しい特徴を供給します、この方法
はＤＮＳに登録されたＩＰｖ６アドレスを、アドレス配布のネットワークトポ
ロジーを反映する様に、多数のＤＮＳ資源レコードの中に入れ、それによりＤ
ＮＳにストアされたデータに特定の種類のネットワークトポロジーやルー
ティング構成の変更の反映を可能にし、これは他のメカニズムでは不可能か極
めて実現が難しいです。RFC 2874が現在同じくProposed Standardと記録され
ます。
Both of these Proposed Standards were the output of the IPNG Working
Group. Both have been implemented, although implementation of
[RFC1886] is more widespread, both because it was specified earlier
and because it's simpler to implement.
これらの両方のProposed StandardがIPNGワークグループのアウトプットで
す。[RFC1886]の方が早くて提案されてシンプルなため広く実装されているが、
両方ともは実装されています。
There's little question that the mechanisms proposed in [RFC2874] are
more general than the mechanisms proposed in [RFC1886], and that
these enhanced mechanisms might be valuable if IPv6's evolution goes
in certain directions. The questions are whether we really need the
more general mechanism, what new usage problems might come along with
the enhanced mechanisms, and what effect all this will have on IPv6
deployment.
小さな問題があります、[RFC2874]で提案されたメカニズムは[RFC1886]で提案
したメカニズムより一般的か、そして、もしＩＰｖ６の進展がある特定の方向
に行くなら、拡張されたメカニズムは高価かもしれない。問題は、拡張メカニ
ズムで現われるかもしれな新しい使い方の問題を含めて我々が本当に一般的メ
カニズムを必要とするかどうか、そしてこれがＩＰｖ６展開上にどのような効
果を持つかどうかです。
The one thing on which there does seem to be widespread agreement is
that we should make up our minds about all this Real Soon Now.
広範囲にわたる合意であるように思われる事は、我々が直ぐに決心すべきで
あるという事です。
Main Advantages of Going with A6
Ａ６に付随する主な利点
While the A6 RR proposed in [RFC2874] is very general and provides a
superset of the functionality provided by the AAAA RR in [RFC1886],
many of the features of A6 can also be implemented with AAAA RRs via
preprocessing during zone file generation.
[RFC2874]の提案した資源レコードが非常に一般的であり、[RFC1886]のAAAA
資源レコードの供給した機能のスーパーセットを供給するが、Ａ６の機能の
多くが同じくゾーンファイル生成の間の事前処理によるAAAA資源レコードと
一緒に実装できます。
There is one specific area where A6 RRs provide something that cannot
be provided using AAAA RRs: A6 RRs can represent addresses in which a
prefix portion of the address can change without any action (or
perhaps even knowledge) by the parties controlling the DNS zone
containing the terminal portion (least significant bits) of the
address. This includes both so-called "rapid renumbering" scenarios
(where an entire network's prefix may change very quickly) and
routing architectures such as the former "GSE" proposal [GSE] (where
the "routing goop" portion of an address may be subject to change
without warning). A6 RRs do not completely remove the need to update
leaf zones during all renumbering events (for example, changing ISPs
would usually require a change to the upward delegation pointer), but
careful use of A6 RRs could keep the number of RRs that need to
change during such an event to a minimum.
Ａ６資源レコードで供給できるがAAAA資源レコードを使って供給できない事
があります：Ａ６資源レコードはアドレスのプレフィックス部を、アドレスの
端末部分（下位ビット）を含むＤＮＳゾーンの管理者によって、他の操作なし
で（多分知識もなしで）変更できます。これは「素早いリナンバリング」シナ
リオ（ネットワーク全体のプレフィックスが非常に速く変化するかもしれな
い）と、（アドレスの「ルーティンググループ」部が警告しないで変化するか
もしれない）「GSE」提案[GSE]のようなルーティングアーキテクチャ両方を含
みます。Ａ６資源レコードは完全にリナンバリングイベントで末端ゾーンの変
更を完全になくすのではありませんが（例えば、ＩＳＰを変えると、通常、上
位の委任ポインタに対する変更を必要とするであろう）、Ａ６資源レコードの
注意深い使用がこのようなイベントでの変更が必要なＲＲの数を最小化します。
Note that constructing AAAA RRs via preprocessing during zone file
generation requires exactly the sort of information that A6 RRs store
in the DNS. This begs the question of where the hypothetical
preprocessor obtains that information if it's not getting it from the
DNS.
ゾーンファイル生成時の事前処理でAAAA資源レコードを作ることは、正確に
Ａ６資源レコードがＤＮＳに登録する種類の情報を必要とすることを注意を
払ってください。これは仮プリプロセッサが、もしＤＮＳから情報を得ていな
いなら、情報を得る所の問題を発生します。
Note also that the A6 RR, when restricted to its zero-length-prefix
form ("A6 0"), is semantically equivalent to an AAAA RR (with one
"wasted" octet in the wire representation), so anything that can be
done with an AAAA RR can also be done with an A6 RR.
同じくＡ６資源レコードが、ゼロ長プレフィックス形式（「A6 0」）に制限さ
れると、これは（ワイヤ表現で１つの「無駄な」オクテットを伴いますが）
意味的にAAAA資源レコードに等しくなり、それでAAAA資源レコードででき
る事はＡ６資源レコードでもできることに注意してください。
Main Advantages of Going with AAAA
AAAAに付随する主な利点
The AAAA RR proposed in [RFC1886], while providing only a subset of
the functionality provided by the A6 RR proposed in [RFC2874], has
two main points to recommend it:
[RFC1886]で提案されたAAAA資源レコードが、[RFC2874]で提案されたＡ６
資源レコードの機能的な下位グループだけを供給するが、AAAAを勧める２
つの主なポイントがあります：
- AAAA RRs are essentially identical (other than their length) to
IPv4's A RRs, so we have more than 15 years of experience to help
us predict the usage patterns, failure scenarios and so forth
associated with AAAA RRs.
- AAAA資源レコードは本質的に（長さ以外）ＩＰｖ４のＡ資源レコードと
まったく同じで、15年以上の経験がAAAA資源レコードと関連する使用パ
ターンや誤り例などを予測するのを助けます。
- The AAAA RR is "optimized for read", in the sense that, by storing
a complete address rather than making the resolver fetch the
address in pieces, it minimizes the effort involved in fetching
addresses from the DNS (at the expense of increasing the effort
involved in injecting new data into the DNS).
- AAAA資源レコードは、リゾルバがアドレスの破片を集めるのではなく完全
なアドレスを登録することでＤＮＳからアドレスを得るための努力を最小
にする事で、（ＤＮＳに新しいデータを入れる場合に必要な努力を増やすと
いう出費があるが）、「読み込みに最適化」されます。
Less Compelling Arguments in Favor of A6
Ａ６に賛成する説得力のない根拠
Since the A6 RR allows a zone administrator to write zone files whose
description of addresses maps to the underlying network topology, A6
RRs can be construed as a "better" way of representing addresses than
AAAA. This may well be a useful capability, but in and of itself
it's more of an argument for better tools for zone administrators to
use when constructing zone files than a justification for changing
the resolution protocol used on the wire.
Ａ６資源レコードがゾーン管理者に、アドレス表現がネットワークトポロジー
に由来するゾーンファイルを書かせる事で、Ａ６資源レコードががAAAAより
「良い」アドレス表現方法であると解釈できます。これは有用な能力である
でしょうが、ワイヤで使用する解決プロトコルの変更ではなく、ゾーン管理者
がゾーンファイルを組み立てる時使うべきもっと良いツールを作るべきです。
Less Compelling Arguments in Favor of AAAA
AAAAに賛成する説得力のない根拠
Some of the pressure to go with AAAA instead of A6 appears to be
based on the wider deployment of AAAA. Since it is possible to
construct transition tools (see discussion of AAAA synthesis, later
in this note), this does not appear to be a compelling argument if A6
provides features that we really need.
Ａ６の代わりにAAAAを使いたいとの圧力のいくらかがAAAAがより広く用い
られているからだと思われます。移行ツールを組み立てる事が可能なので
（このメモで後のAAAA合成の論議を見て下さい）、これはＡ６が我々が本当に
必要とする機能を供給するなら説得的な論拠であるように思われません。
Another argument in favor of AAAA RRs over A6 RRs appears to be that
the A6 RR's advanced capabilities increase the number of ways in
which a zone administrator could build a non-working configuration.
While operational issues are certainly important, this is more of
argument that we need better tools for zone administrators than it is
a justification for turning away from A6 if A6 provides features that
we really need.
他のＡ６資源レコードよりAAAA資源レコードを賛成する議論がＡ６資源レコー
ドの進歩した能力がゾーン管理者が動作しない設定を作る方法の数を増やすと
いうことだと思われます。運用上の問題が確かに重要であるが、もしＡ６が本
当に必要な機能を供給するなら、Ａ６から顔をそむけるのは正当ではなく、ゾー
ン管理者の良いツールを必要とする議論です。
Potential Problems with A6
Ａ６における潜在的な問題
The enhanced capabilities of the A6 RR, while interesting, are not in
themselves justification for choosing A6 if we don't really need
those capabilities. The A6 RR is "optimized for write", in the sense
that, by making it possible to store fragmented IPv6 addresses in the
DNS, it makes it possible to reduce the effort that it takes to
inject new data into the DNS (at the expense of increasing the effort
involved in fetching data from the DNS). This may be justified if we
expect the effort involved in maintaining AAAA-style DNS entries to
be prohibitive, but in general, we expect the DNS data to be read
more frequently than it is written, so we need to evaluate this
particular tradeoff very carefully.
Ａ６資源レコードの拡張された能力は面白いが、もし我々が本当にそれらの
能力を必要としないなら、Ａ６を選択するのは正当でありません。Ａ６資源
レコードは、（ＤＮＳからデータを引き出すのに関する労力を増やすが）、
ＩＰｖ６を分解してＤＮＳに登録可能にしＤＮＳに新しいデータを登録する
労力を簡単にする意味で、「書込みに最適化」されます、。これは、もしAAAA
様式のＤＮＳエントリを維持するための努力が禁止的なら正当かもしれませ
んが、一般的にＤＮＳデータは書かれるより読まれる事が多いので、我々は
非常に慎重にこのトレードオフを評価する必要があります。
There are also several potential issues with A6 RRs that stem
directly from the feature that makes them different from AAAA RRs:
the ability to build up address via chaining.
同じくAAAA資源レコードとは異なるＡ６機能から直接生じるいくつかの問題
の可能性があります：アドレス連鎖の能力増強。
Resolving a chain of A6 RRs involves resolving a series of what are
almost independent queries, but not quite. 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. Assuming that resolving an
AAAA RR takes time T as a baseline, we can guess that, on the
average, it will take something approaching time N*T to resolve an
N-link chain of A6 RRs, although we would expect to see a fairly good
caching factor for the A6 fragments representing the more significant
bits of an address. This leaves us with two choices, neither of
which is very good: we can decrease the amount of time that the
resolver is willing to wait for each fragment, or we can increase the
amount of time that a resolver is willing to wait before returning
failure to a client. What little data we have on this subject
suggests that users are already impatient with the length of time it
takes to resolve A RRs in the IPv4 Internet, which suggests that they
are not likely to be patient with significantly longer delays in the
IPv6 Internet. At the same time, 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 problems.
一連のＡ６資源レコードの確認が、ほとんど他に依存しないがまったくでは
ない一連の質問をします。これらの副質問のそれぞれで、答えがたまたます
でにリゾルバのローカルキャッシュにあるのでないなら、あるゼロでない時
間がかかります。AAAA資源レコード解決に基本的に時間Ｔがかかるとすると、
アドレスの上位ビットがキャッシュされている可能性が高いと予想されとは
いえ、平均的にＮリンクのＡ６レコードは約Ｎ×Ｔ時間がかかります。これ
は、いずれも非常に良くない、２つの選択を示します：リゾルバが各破片を
待つために必要な時間の総量を減少させるか、リゾルバがクライアントに故
障を返す前に待つ時間の総量を増やすかです。我々がこの問題に間して持つ
わずかなデータは、ユーザーがすでにＩＰｖ４インターネットでＡ資源レコー
ド解決の時間の長さに我慢できないことを示唆するもので、これはＩＰｖ６
インターネットでより長い遅延に忍耐強い可能性が高くないことを提案しま
す。早く質問を終えることはリソースの浪費とユーザーフラストレーション
の両方の同時の問題です。そのため長いＡ６連鎖の無差別な使用は問題を生
じる可能性が高いと結論することを強いられます。
To make matters worse, the places where A6 RRs are likely to be most
critical for rapid renumbering or GSE-like routing are 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 (for example, in the case of
an end user's site, the prefix name will most likely point to a name
belonging to an ISP that provides connectivity for the site). While
pointers out of zone are not a problem per se, pointers to other
organizations are somewhat more difficult to maintain and less
susceptible to automation than pointers within a single organization
would be. Experience both with glue RRs and with PTR RRs in the IN-
ADDR.ARPA tree suggests that many zone administrators do not really
understand how to set up and maintain these pointers properly, and we
have no particular reason to believe that these zone administrators
will do a better job with A6 chains than they do today. To be fair,
however, the alternative case of building AAAA RRs via preprocessing
before loading zones has many of the same problems; at best, one can
claim that using AAAA RRs for this purpose would allow DNS clients to
get the wrong answer somewhat more efficiently than with A6 RRs.
悪いことに、Ａ６ 資源レコードの素早いリナンバリングやＧＳＥのような
ルーティングの最も批判的な点は、Ａ６資源レコードのプレフィックス名フィー
ルドが、Ａ６資源レコードを含むＤＮＳゾーン外を指し示すだけでなく、他の
組織によって管理されているところを指し示すことです（例えば、エンドユー
ザのサイトの場合ケースで、プレフィックス名がサイトに接続性を提供するＩ
ＳＰに属している名前を指し示す可能性が最も高い）。ゾーン外へのポインタ
が問題ではないが、他の組織へのポインタはひとつの組織の中のポインタより
維持管理が難しく、自動化の影響を受けやすいです。グルー資源レコードと
IN-ADDR.ARPA木のPTR資源レコードの経験から、多くのゾーン管理者が正確に
これらのポインタを保守する方法を理解する準備をしていないことを示唆し、
これらのゾーン管理者がＡ６鎖に対して現在よりより良い仕事をすると信じる
理由がありません。公正に言うと、ゾーンを読み込む前の前処理としてAAAA
資源レコードを作る場合、同様の問題を持ちます；AAAA資源レコードをこの
目的にを使うことはＡ６資源レコードよりも効率的であるが間違った答えを
得る事になるだろうとの主張があります。
Finally, assuming near total ignorance of how likely a query is to
fail, the probability of failure with an N-link A6 chain would appear
to be roughly proportional to N, since each of the queries involved
in resolving an A6 chain would have the same probability of failure
as a single AAAA query. Note again that this comment applies to
failures in the the process of resolving a query, not to the data
obtained via that process. Arguably, in an ideal world, A6 RRs would
increase the probability of the answer a client (finally) gets being
right, assuming that nothing goes wrong in the query process, but we
have no real idea how to quantify that assumption at this point even
to the hand-wavey extent used elsewhere in this note.
最終的に、どれぐらい問合せが失敗するかの完全な知識がないと仮定しても、
Ａ６鎖の１つを解決する際の問合せの失敗の可能性がひとつのAAAA問合せと
同じぐらいであろうから、ＮリンクＡ６鎖を持つ失敗の可能性はＮ倍のよう
に思われるでしょう。このコメントは問合せ解決プロセスの失敗についてで、
プロセスから得られるデータの誤りについてではありません。多分、理想で世
界、問合せ処理で何も失敗がないと想定しすれば（最終的に）Ａ６資源レコー
ドがクライアントが正しい答えを得る可能性を増やすでしょう、しかし我々は
現時点でこのノート以外、大雑把にも仮定を数量化する方法の考えがありませ
ん。
One potential problem that has been raised in the past regarding A6
RRs turns out not to be a serious issue. The A6 design includes the
possibility of there being more than one A6 RR matching the prefix
name portion of a leaf A6 RR. That is, an A6 chain may not be a
simple linked list, it may in fact be a tree, where each branch
represents a possible prefix. Some critics of A6 have been concerned
that this will lead to a wild expansion of queries, but this turns
out not to be a problem if a resolver simply follows the "bounded
work per query" rule described in RFC 1034 (page 35). That rule
applies to all work resulting from attempts to process a query,
regardless of whether it's a simple query, a CNAME chain, an A6 tree,
or an infinite loop. The client may not get back a useful answer in
cases where the zone has been configured badly, but a proper
implementation should not produce a query explosion as a result of
processing even the most perverse A6 tree, chain, or loop.
Ａ６資源レコードに関して過去に上げられた１つの問題の可能性は、重大な問
題ではないことが分かります。Ａ６デザインは末端Ａ６資源レコードのプレフィッ
クス名に一致する複数のＡ６資源レコードをの可能性を含みます。すなわち、
Ａ６鎖が単純なつながれたリストではないかもしれず、実際は木、つまり分岐
が可能なプレフィックスを表すかもしれません。あるＡ６の批判家がこれが問
合せの爆発になることを心配しました、しかしもしリゾルバがRFC1034の３５
ページで記述された「問合せ毎の境界の仕事」規則に従うなら問題ではないこ
とが分かります。この規則は、単純な問合せ、 CNAME鎖、 Ａ６木、あるいは
無限ループのどれでも、すべての問合せを処理する試みの結果として生じてい
る仕事に当てはまります。クライアントはゾーンが間違って設定された場合に
利用可能な答えを得てはなりませんが、適切な実装は最もつむじ曲がりのＡ６
木や鎖やあるいはループの処理の結果としてでも問合せ爆発を作り出すべきで
はありません。
Interactions with DNSSEC
DNSSECとの相互作用
One of the areas where AAAA and A6 RRs differ is in the precise
details of how they interact with DNSSEC. The following comments
apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
semantically equivalent to AAAA RRs).
AAAAとＡ６資源レコードが異なる事の１つがDNSSECと相互作用する方法の
正確な細部です。次のコメントはゼロ以外のプレフィックスのＡ６資源レコー
ドにだけ当てはまります（もう一度繰り返しますが、A６ ０の資源レコード
はAAAA資源レコードと意味的に等価です）。
Other things being equal, the time it takes to re-sign all of the
addresses in a zone after a renumbering event is longer with AAAA RRs
than with A6 RRs (because each address record has to be re-signed
rather than just signing a common prefix A6 RR and a few A6 0 RRs
associated with the zone's name servers). Note, however, that in
general this does not present a serious scaling problem, because the
re-signing is performed in the leaf zones.
他のことが同じとして、リナンバリングイベントの後にゾーンのアドレスのす
べてを再署名するために要する時間はＡ６資源レコードよりAAAA資源レコー
ドの方が長いです（なぜなら、全てのアドレスレコードを再署名するより、共
通プレフィックスＡ６資源レコードとゾーンネームサーバのA６ ０の資源レ
コード だけを再署名する方が早いからです）。しかしながら、一般にこれが重
大なスケーラビリティ問題をおこさないことに注意してください、なぜなら再
署名は末端で行われるからです。
Other things being equal, there's more work involved in verifying the
signatures received back for A6 RRs, because each address fragment
has a separate associated signature. Similarly, a DNS message
containing a set of A6 address fragments and their associated
signatures will be larger than the equivalent packet with a single
AAAA (or A6 0) and a single associated signature.
他のことが同じとして、Ａ６資源レコードのアドレス片がそれぞれ署名を持
つから、Ａ６資源レコードを受取った際の署名の検証にはより多くの手間が
かかります。同様に、Ａ６アドレス片とそれに関連づした署名を含むＤＮＳ
メッセージが、ひとつのAAAA（あるいはＡ６ ０）と関連する証明をを持つ
同様なパケットより大きいでしょう。
Since AAAA RRs cannot really represent rapid renumbering or GSE-style
routing scenarios very well, it should not be surprising that DNSSEC
signatures of AAAA RRs are also somewhat problematic. In cases where
the AAAA RRs would have to be changing very quickly to keep up with
prefix changes, the time required to re-sign the AAAA RRs may be
prohibitive.
AAAA資源レコードが素早いリナンバリングやＧＳＥスタイルルーチングを
うまく扱えないので、AAAA資源レコードのDNSSEC署名が幾分問題が多いこ
とは驚くべきではありません。AAAA資源レコードがプレフィックス変更に
負けずについていくために非常に速く変化していなければならない場合、
AAAA資源レコードを再署名する要求は禁止的かもしれません。
Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
1024-bit RSA signatures per second. Extrapolating from this,
assuming one A RR, one AAAA RR, and one NXT RR per host, this
suggests that it would take this laptop a few hours to sign a zone
listing 10**5 hosts, or about a day to sign a zone listing 10**6
hosts using AAAA RRs.
Bill Sommerfeldの経験的なテスト[Sommerfeld]が128KB L2キャッシュの
333MHz Celeronで64MBメモリのラップトップでNetBSD下でBIND-9の
DNSSEC署名ゾーンプログラムを走らせた結果、毎秒約４０の１０２４ビット
のRSA署名を生成することができることを示唆します。これから推定すると、
ホストが１つのＡ資源レコードと１つのAAAA資源レコードと１つのNXT資源
レコードを持つと仮定すると、10万のホストの署名にこのラップトップで数
時間かかり、AAAA資源レコードを使用するホスト１００万の署名におよそ
1日かかることになります。
This suggests that the additional effort of re-signing a large zone
full of AAAA RRs during a re-numbering event, while noticeable, is
only likely to be prohibitive in the rapid renumbering case where
AAAA RRs don't work well anyway.
これは、リナンバリングのイベントの再にAAAA資源レコードでいっぱいの
大きいゾーンを再署名する事は、AAAA資源レコードが素早いリナンバリン
グに向かないので、禁止的である事を示唆します。
Interactions with Dynamic Update
ダイナミック更新との相互作用
DNS dynamic update appears to work equally well for AAAA or A6 RRs,
with one minor exception: with A6 RRs, the dynamic update client
needs to know the prefix length and prefix name. At present, no
mechanism exists to inform a dynamic update client of these values,
but presumably such a mechanism could be provided via an extension to
DHCP, or some other equivalent could be devised.
AAAAあるいはＡ６資源レコード かＤＮＳダイナミックな更新が、１つのマイ
ナーな例外を除き、等しく機能するように思われます：Ａ６資源レコードで、
ダイナミック更新クライアントはプレフィックス長とプレフィックス名を知
る必要があります。目下これらの値をダイナミックな更新クライアントに知ら
せるメカニズムが存在しませんが、多分このようなメカニズムはＤＨＣＰの拡
張や等価な方法で供給できます。
Transition from AAAA to A6 Via AAAA Synthesis
AAAAからＡ６までAAAA統合による移行
While AAAA is at present more widely deployed than A6, it is possible
to transition from AAAA-aware DNS software to A6-aware DNS software.
A rough plan for this was presented at IETF-50 in Minneapolis and has
been discussed on the ipng mailing list. So if the IETF concludes
that A6's enhanced capabilities are necessary, it should be possible
to transition from AAAA to A6.
現在AAAAがＡ６より広く実装されるが、AAAAのＤＮＳソフトウェアをＡ６
のＤＮＳソフトウェアに移行は可能です。これのラフな計画がミネアポリス
のIETF-50で提出され、ipngメーリングリスト上で論じられました。それ
でもしIETFがＡ６の拡張された能力が必要であると結論するなら、AAAAか
らＡ６に移行を可能にするべきです。
The details of this transition have been left to a separate document,
but the general idea is that the resolver that is performing
iterative resolution on behalf of a DNS client program could
synthesize AAAA RRs representing the result of performing the
equivalent A6 queries. Note that in this case it is not possible to
generate an equivalent DNSSEC signature for the AAAA RR, so clients
that care about performing DNSSEC validation for themselves would
have to issue A6 queries directly rather than relying on AAAA
synthesis.
この移行の細部は別の文書に任せられました、しかし一般的なアイデアは
ＤＮＳクライアントプログラムのために反復の導出を行うリゾルバがＡ６
の問合せをの結果からAAAA資源レコードを合成できたということです。
この場合AAAA資源レコードのDNSSEC署名を生成することが可能ではない
ことに注意を払ってください、それでDNSSEC検証に関心を持つクライアン
トはAAAA合成に頼るのではなく直接Ａ６の質問を行わなければなりません。
Bitlabels
ビットラベル
While the differences between AAAA and A6 RRs have generated most of
the discussion to date, there are also two proposed mechanisms for
building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
ADDR.ARPA tree).
AAAAとＡ６資源レコードの間の相違が今日までの論議の大部分ですが、逆の
マップ作成の木（ＩＰｖ４のIN-ADDR.ARPAと同等のＩＰｖ６用の木）を作
ることに対しても同じく２つの提案された機構があります。
[RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
mechanism used for IPv4 addresses: the RR name is the hexadecimal
representation of the IPv6 address, reversed and concatenated with a
well-known suffix, broken up with a dot between each hexadecimal
digit. The resulting DNS names are somewhat tedious for humans to
type, but are very easy for programs to generate. Making each
hexadecimal digit a separate label means that delegation on arbitrary
bit boundaries will result in a maximum of 16 NS RRsets per label
level; again, the mechanism is somewhat tedious for humans, but is
very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one
place where this scheme is weak is in handling delegations in the
least significant label; however, since there appears to be no real
need to delegate the least significant four bits of an IPv6 address,
this does not appear to be a serious restriction.
[RFC1886]がＩＰｖ４アドレスのために使われたIN-ADDR.ARPAメカニズムに
非常に類似している機構を提案します：資源レコード名は、ＩＰｖ６アドレ
スの１６進数表現を、反転し、既知の接尾辞をつけ、各１６進数の間を点で
分断したものです。結果として生じているＤＮＳ名は人が入力するには幾分
退屈ですが、プログラムで生成することが非常に容易です。１６進数の桁毎
に分けることは任意のビット境界での委任は最大１６のＮＳ資源レコード集
合をもたらすでしょう；これも、メカニズムは人にとって退屈ですが、プロ
グラムは非常に容易です。ＩＰｖ４のIN-ADDR.ARPA木と同じように、この
案が弱い所の１つは最下位ラベルでの委任であるが、ＩＰｖ６アドレスの最
少４ビットを委任する真の必要はないと思われますので、これは重大な制限
であるように思われません。
[RFC2874] proposed a radically different way of naming entries in the
reverse mapping tree: rather than using textual representations of
addresses, it proposes to use a new kind of DNS label (a "bit label")
to represent binary addresses directly in the DNS. This has the
advantage of being significantly more compact than the textual
representation, and arguably might have been a better solution for
DNS to use for this purpose if it had been designed into the protocol
from the outset. Unfortunately, experience to date suggests that
deploying a new DNS label type is very hard: all of the DNS name
servers that are authoritative for any portion of the name in
question must be upgraded before the new label type can be used, as
must any resolvers involved in the resolution process. Any name
server that has not been upgraded to understand the new label type
will reject the query as being malformed.
[RFC2874]が逆のマッピングツリーで項目を指し示す根本的に異なった方法
を提案しました：アドレスのテキスト表現を使うより、ＤＮＳで直接２進数
のアドレスを表す新しい種類のＤＮＳラベル（「ビットラベル」）を使うこと
を提案しました。これはテキスト表現よりも密な利点を持ち、多分ＤＮＳプ
ロトコルを最初から設計できるならこの目的のために使うべき良い解決方法
であったかもしれません。不幸にも、今日までの経験が新しいＤＮＳラベル
タイプを動作させることが非常に難しいことを示唆します：質問の名前の部
分の権威のあるＤＮＳネームサーバーのすべてが、新しいラベルタイプが使
われる前に、更新されなくてはならず、解決プロセスに関係しているリゾル
バもそうしなくてはなりません。新しいラベルタイプを理解するためにアッ
プグレードされなかった名前サーバーはフォーマット誤りとして問合せを拒
絶するでしょう。
Since the main benefit of the bit label approach appears to be an
ability that we don't really need (delegation in the least
significant four bits of an IPv6 address), and since the upgrade
problem is likely to render bit labels unusable until a significant
portion of the DNS code base has been upgraded, it is difficult to
escape the conclusion that the textual solution is good enough.
ビットラベルアプローチの主な利益が我々が本当に必要とはしない能力（Ｉ
Ｐｖ６アドレスの最下位４ビットでの委任）であるように思われ、アップグ
レード問題が、ＤＮＳコードベースの重要な部分がアップグレードされるま
で、ビットラベルを使用できなくする可能性が高いので、テキストの解決が
十分に良いという結論から逃れることは難しいです。
DNAME RRs
DNAME資源レコード
[RFC2874] also proposes using DNAME RRs as a way of providing the
equivalent of A6's fragmented addresses in the reverse mapping tree.
That is, by using DNAME RRs, one can write zone files for the reverse
mapping tree that have the same ability to cope with rapid
renumbering or GSE-style routing that the A6 RR offers in the main
portion of the DNS tree. Consequently, the need to use 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.
[RFC2874]が逆マップ木でＡ６の断片的なアドレスの同等物を供給する方法と
してDNAME資源レコードを用いることを提案します。すなわち、DNAME資源レ
コードを使うことによって、Ａ６資源レコードがＤＮＳ木のメイン部分での素
早いリナンバリングやGSE様式のルーティングにうまく対処する能力を持つ逆
マッピング木のゾーンファイルを書くことができます。従って、逆マッピング
木でDNAMEを使う必要はメイン木で断片的なＡ６を使う必要と密接に結びつけ
られているように思われます：もし一方が必要なら他も必要で、一方が不要な
ら他方も不要です。
Other uses have also been proposed for the DNAME RR, but since they
are outside the scope of the IPv6 address discussion, they will not
be addressed here.
他の利点がDNAME資源レコードに対して提案されましたが、それらがＩＰｖ
６アドレス論議の範囲の外にあるのでここで扱いません。
Recommendation
推薦
Distilling the above feature comparisons down to their key elements,
the important questions appear to be:
重要な要素の上記の機能比較の要点をは、重要な問題が以下ということだと
思われます：
(a) Is IPv6 going to do rapid renumbering or GSE-like routing?
(a) ＩＰｖ６が素早いリナンバリングやＧＳＥのようなルーティングをする
方向に進みますか？
(b) Is the reverse mapping tree for IPv6 going to require delegation
in the least significant four bits of the address?
(b) 逆のマッピング木はＩＰｖ６アドレスの最下位４ビットでの委任を必要
としようとしていますか？
Question (a) appears to be the key to the debate. This is really a
decision for the IPv6 community to make, not the DNS community.
（ａ）が討論に鍵であるように思われる問題です。これはＩＰｖ６共同体が
するべき決断で、ＤＮＳ共同体ではありません。
Question (b) is also for the IPv6 community to make, but it seems
fairly obvious that the answer is "no".
質問（ｂ）がＩＰｖ６共同体の解決すべき問題ですが、答えが「ノー」であ
ることはかなり明白に思われます。
Recommendations based on these questions:
これらの質問に基づいた推薦：
(1) If the IPv6 working groups seriously intend to specify and deploy
rapid renumbering or GSE-like routing, we should transition to
using the A6 RR in the main tree and to using DNAME RRs as
necessary in the reverse tree.
(1) ＩＰｖ６ワークグループが素早いリナンバリングかＧＳＥの様なルーチ
ングを強く指定し配置するつもりなら、我々はメイン木でＡ６資源レコー
ドを、逆木でＤＮＡＭＥ資源レコードを使うように移行すべきです。
(2) Otherwise, we should keep the simpler AAAA solution in the main
tree and should not use DNAME RRs in the reverse tree.
(2) さもなければ、我々はメイン木でより単純なAAAA解決を維持すべきで、
逆木でDNAME資源レコードを使うべきではありません。
(3) In either case, the reverse tree should use the textual
representation described in [RFC1886] rather than the bit label
representation described in [RFC2874].
(3) いずれの場合でも、逆木は[RFC2874]で記述されたビットラベル表現では
なく[RFC1886]で記述されたテキスト表現を使うべきです。
(4) If we do go to using A6 RRs in the main tree and to using DNAME
RRs in the reverse tree, we should write applicability statements
and implementation guidelines designed to discourage excessively
complex uses of these features; in general, any network that can
be described adequately using A6 0 RRs and without using DNAME
RRs should be described that way, and the enhanced features
should be used only when absolutely necessary, at least until we
have much more experience with them and have a better
understanding of their failure modes.
(4) もし我々がメイン木でＡ６資源レコードを使うことにし、逆木でDNAME
資源レコードを使うことにするなら、我々はこれらの機能の過度に複雑
な使用を思いとどまらせるよう意図された適用性声明と実行ガイドライ
ンを書くべきです；一般に、Ａ６ ０資源レコードを使いDNAME資源レ
コードを使わないで十分に記述できるネットワークは、そのように記述
されるべきで、そして少なくとも我々がずっと多くの経験をして、それ
らの失敗の良い理解えるまではを拡張機能は絶対的に必要な時だけ使わ
れるべきです。
Security Considerations
セキュリティの考慮
This note compares two mechanisms with similar security
characteristics, but there are a few security implications to the
choice between these two mechanisms:
このメモは２つのメカニズムを類似のセキュリティ特性と比較します、しか
しこれらの２つのメカニズムの間の選択に少数のセキュリティ的な意味があ
ります：
(1) The two mechanisms have similar but not identical interactions
with DNSSEC. Please see the section entitled "Interactions with
DNSSEC" (above) for a discussion of these issues.
(1) ２つのメカニズムはDNSSECについて類似であるが、同一でない相互作用
を持っています。問題の論議のためにどうか（上記）「DNSSECとの相互作
用」と題を付けた章を見てください。
(2) To the extent that operational complexity is the enemy of
security, the tradeoffs in operational complexity discussed
throughout this note have an impact on security.
(2) 操作上の複雑さがセキュリティの敵である限りにおいて、この文書を通
じて論じられた操作上の複雑さのトレードオフはセキュリティに影響を
持っています。
(3) To the extent that protocol complexity is the enemy of security,
the additional protocol complexity of [RFC2874] as compared to
[RFC1886] has some impact on security.
(3) プロトコル複雑さがセキュリティの敵である限りにおいて、[RFC1886]
と比較してプロトコルの複雑さを追加した[RFC2874]はセキュリティに
なんらかの影響を持っています。
IANA Considerations
ＩＡＮＡの考慮
None, since all of these RR types have already been allocated.
これらすべての資源レコードタイプがすでに割り当てられてるので、ありません。
Acknowledgments
謝辞
This note is based on a number of discussions both public and private
over a period of (at least) eight years, but particular thanks go to
Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
and Sue Thomson, none of whom are responsible for what the author did
with their ideas.
このメモは、（少なくとも）８年間以上の、多くの公的や私的な論議に基づい
ていますが、彼らは著者が彼らの考えに関してしたことに関して責任がないけ
ども、Alain DurandとBill SommerfeldとChristian HuitemaとJun-ichiro
itojun HaginoとMark AndrewsとMatt CrawfordとOlafur Gudmundssonと
Randy BushとSue Thomsonに特別に感謝します。
References
参考文献
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support
IP version 6", RFC 1886, December 1995.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874,
July 2000.
[Sommerfeld] Private message to the author from Bill Sommerfeld dated
21 March 2001, summarizing the result of experiments he
performed on a copy of the MIT.EDU zone.
２００１年３月２１日の日付の、彼がMIT.EDUゾーンのコピー
に対して行った実験の結果を要約しているBill Sommerfeldか
らの著者へのプライベートのメッセージ。
[GSE] "GSE" was an evolution of the so-called "8+8" proposal
discussed by the IPng working group in 1996 and 1997.
The GSE proposal itself was written up as an Internet-
Draft, which has long since expired. Readers interested
in the details and history of GSE should review the IPng
working group's mailing list archives and minutes from
that period.
"GSE"は１９９６年と１９９７年にIPngワークグループによっ
て論じられるいわゆる「８＋８」提案の発展です。GSE提案自
身はインターネットドラフトとして書き上げられ、既に失効し
ています。GSEの細部と歴史に興味を持った読者はその期間の
IPngワークグループのメーリングリストアーカイブを再検討す
るべきです。
Author's Address
著者のアドレス
Rob Austein
EMail: sra@hactrn.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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。