RFC 3364 - Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) 日本語訳

URL : https://tools.ietf.org/html/rfc3364
タイトル : RFC 3364 - ドメインネームシステム（DNS）は、インターネットプロトコルバージョン6のサポートにおけるトレードオフ（IPv6）の
翻訳編集 : 自動生成

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2002）。全著作権所有。

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.

IETFは、IPv6用のDNSのサポートを行う方法については、表上の2つの異なる提案を持っており、これまでのアプローチが優れている上で明確な合意に達することができませんでした。このノートでは、我々は閉鎖に到達し、上に移動できるように、議論を明確にすることを期待して、各アプローチの長所と短所を検討しようとします。

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]はDNSでIPv6アドレスをサポートするための簡単なメカニズムを指定しました。これらの機構は密接にCIDRの経験に基づいて、逆マッピングメカニズムにマイナーな改善ではIPv4をサポートするために使用されるメカニズムに似ています。 RFC 1886は、現在提案されている標準としてリストされています。

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]はDNSでIPv6アドレスをサポートするように拡張メカニズムを指定しました。これらのメカニズムは、このようにDNSに格納されたデータのためにそれが可能となる、アドレスを基盤となるネットワークトポロジを反映することができる方法で複数のDNSリソースレコードに分割するDNSに保存されているIPv6アドレスのためにそれを可能にする新機能を提供しますこれらのメカニズムなしで表現することが不可能又はより困難のいずれかであるネットワーク・トポロジの変更またはルーティングアーキテクチャの特定の種類を反映します。 RFC 2874は、現在提案されている標準としてリストされています。

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.

これらの提案された標準の両方が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]で提案されたメカニズムよりも一般的であり、IPv6のの進化は一定の方向に行く場合には、これらの拡張メカニズムは貴重かもしれないということを少し疑問があります。質問は、私たちは本当に新しい使用の問題が改善メカニズムと一緒に来るかもしれない、とこのすべてがIPv6の展開にどのような影響を持つことになりますどのようなより一般的なメカニズムを、必要があるかどうかです。

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

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.

A6 RRは非常に一般的であり、[RFC1886]でのAAAA RRによって提供される機能のスーパーセットを提供する[RFC2874]で提案されているが、A6の特徴の多くはまた、ゾーンファイル生成時の前処理を介して、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.

A6資源レコードはAAAAのRRを使用して提供することができないものを提供する1つの特定の領域がある：A6 RRは含むDNSゾーンを制御する当事者によってアドレスのプレフィックス部分は、任意のアクション（またはおそらく知識）なしに変更可能なアドレスを表すことができアドレスの端子部（最下位ビット）。これは、アドレスの「ルーティングGOOP」部分は、対象となることがあり、前者「GSE」提案[GSE]（として（全体のネットワークのプレフィックスが非常に迅速に変更することができる場合）とルーティングアーキテクチャ、いわゆる「急速リナンバリング」シナリオの両方を含みます）警告なしに変更されることがあります。 A6 RRは完全に（通常は上向きの委任ポインタへの変更を必要とするのISPを変更する、など）すべてのリナンバリングイベント時の葉のゾーンを更新する必要が削除されませんが、A6 RRの慎重な使用は、変更する必要があるRRの数を保つことができます最小限に、このようなイベント中。

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 RRを構築すると、DNSでのA6のRR店、その情報の正確並べ替えを必要とすることに注意してください。これは、仮想的なプリプロセッサは、それがDNSからそれを取得していない場合は、その情報をどこから取得するかの質問を頼みます。

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 RR、その長さゼロプレフィックス形（「A6 0」）に制限するとき、AAAAの（ワイヤー表現の一つの「無駄」オクテットで）RRので、行うことができるものと意味的に等価ですAAAAのRRでもA6のRRで行うことができます。

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:

[RFC2874]で提案されたA6 RRによって提供される機能のサブセットのみを提供しながら、AAAA RRは、[RFC1886]で提案され、それをお勧めするために2つの主な点を有しています。

- 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 RRはIPv4ののAのRRに（その長さ以外の）本質的に同一であるので、我々は、私たちはAAAA RRのに関連付けられているなど使用パターン、障害シナリオとの予測を支援するために15年以上の経験を持っています。

- 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 RRは増加を犠牲にして（完全なアドレスを記憶するのではなく、レゾルバは個のアドレスを取得することにより、それがDNSからアドレスを取得するに関与する労力を最小限に抑える、という意味で、「読むために最適化」されていますDNSに新しいデータを注入に関与エフォート）。

Less Compelling Arguments in Favor of A6

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.

A6 RRは、ゾーン管理者は、そのアドレスの記述基本的なネットワークトポロジにマップゾーンファイルを書き込むことができますので、A6のRRは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の代わりに、A6に行くには圧力の一部はAAAAの広い展開に基づいているように見えます。（後でこのノートでは、AAAA合成の説明を参照）の移行ツールを構築することが可能であるので、これはA6は、私たちが本当に必要な機能を提供する場合魅力的な引数ではありません。

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.

A6のRR以上AAAA RRの賛成で別の引数は、A6 RRの高度な機能は、ゾーン管理者が非稼働の構成を構築できる方法の数を増やすことであるように思われます。運用上の問題は確かに重要ですが、これは、我々はそれがA6は、私たちが本当に必要な機能を提供する場合A6から離れて回しを正当化する理由であるよりも、ゾーン管理者のためのより良いツールを必要と引数の詳細です。

Potential Problems with A6

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.

A6 RRの拡張機能は、興味深いながら、自分自身に私たちは本当にこれらの機能を必要としない場合はA6を選択するための正当な理由ではありません。 A6 RRは、DNSに断片化されたIPv6アドレスを格納することが可能となることで、それは犠牲にして、それがDNSに新しいデータを注入するのにかかることに努力を（軽減することが可能となり、という意味で、「書き込み用に最適化」されますDNSからのフェッチデータに関わる労力を）増やします。非常に慎重に私たちは法外であることをAAAAスタイルのDNSエントリの維持に関与努力を期待する場合、これが正当化されるかもしれないが、一般的に、我々は、DNSデータは、それが書かれているよりも頻繁に読まれることを期待し、私たちは、この特定のトレードオフを評価する必要があります。

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 RRをから彼らは違う機能から直接幹A6のRRにはいくつかの潜在的な問題もあります。

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.

A6 RRの連鎖を解決することではなく、かなり、ほとんどの独立したクエリであるかのシリーズを解決含まれます。答えはすでにリゾルバのローカルキャッシュにあることを起こる場合を除き、これらのサブクエリのそれぞれは、時間のいくつかの非ゼロ量を要します。 AAAA RRを解決するベースラインとして時間Tを要すると仮定すると、我々はかなりを見ることを期待するものの、平均して、それは、A6 RRのN-リンクチェーンを解決するために何か近づい時間N * Tを取るだろう、と推測することができますアドレスの上位ビットを表すA6フラグメントのための良好なキャッシュ要因。これは非常に良いですどちらも二つの選択肢、と私たちを残します：私たちはリゾルバが各フラグメントを待つために喜んでいる時間の量を減らすことができ、またはリゾルバが失敗を返す前に待機する意志があることを、我々は時間の量を増やすことができますクライアントへ。このテーマにはほとんど何のデータ我々が持っているユーザーは、すでにそれは彼らがIPv6インターネットで有意に長い遅延と患者である可能性が高いではないことを示唆しているIPv4インターネット、でRRを解決するのにかかる時間の長さにせっかちであることを示唆しています。同時に、途中でクエリを終了すると、リソースの浪費とユーザーフラストレーションの別のソースでもあります。したがって、我々は長いA6連鎖の無差別使用は問題につながる可能性があると結論することを余儀なくされています。

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.

さらに悪いことに、A6のRRは急速なリナンバリングやGSEのようなルーティングのために最も重要である可能性が高い場所ではないだけA6を含むDNSゾーンの外にあるターゲットにA6のRRポイントでのプレフィックス名フィールドの状況ですRRが、異なる組織によって管理される（エンドユーザーのサイトの場合には、例えば、プレフィックス名意志サイトの接続性を提供し、ISPに属する名前に最も可能性の高いポイント）。ゾーンのうちポインタはそれ自体が問題ではありませんが、他の組織へのポインタを維持することがやや困難となり、単一の組織内のポインタより自動化の影響を受けにくいです。 IN-ADDR.ARPAツリー内の接着剤のRRとRRとPTR RRの両方の経験は、多くのゾーン管理者が実際に設定し、適切にこれらのポインタを維持する方法を理解していない、と私たちはこれらのゾーン管理者が行いますことを信じなければならない特別な理由がないことを示唆しています彼らは今日やるよりも、A6鎖とのより良い仕事。公平を期すために、しかし、ロードゾーンの前に前処理を経てのAAAA RRを構築する別の場合は、同じ問題の多くを持っています。せいぜい、1は、この目的のためにAAAA RRを使用すると、DNSクライアントはA6のRRよりもやや効率的に間違った答えを得るためにできるようになると主張することができます。

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.

A6チェーンの解決に関与したクエリのそれぞれが同じを持っているであろうから最後に、クエリが失敗することがいかにそうなの総無知に近いと仮定すると、N-リンクA6鎖と失敗の確率は、Nにほぼ比例あるように思われます単一AAAAクエリとして失敗の確率。このコメントは、クエリを解決するプロセスの障害にはなく、そのプロセスを経て得られたデータに適用されることに再び注意してください。間違いなく、理想的な世界では、A6のRRは（最終的に）答えの確率にクライアントを増加させるクエリ処理には何もうまくいかないと仮定して、右されて取得しますが、私たちはどのようにしても、この時点ではその仮定を定量化するために本当のアイデアを持っていませんこのノートの他の場所で使用手ウェービー限り。

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.

A6のRRに関して、過去に提起されてきた一つの潜在的な問題は深刻な問題ではないことが判明します。 A6設計がリーフA6 RRの接頭辞名部分に一致する複数のA6のRRであることの可能性を含みます。つまり、A6チェーンは、単純なリンクリストではないかもしれないが、それは実際には、各分岐が可能な接頭辞を表し木があってもよいです。 A6のいくつかの批評家は、これは、クエリの野生の拡大につながることを懸念していたが、これは、リゾルバは、単にRFC 1034（35ページ）に記載されている「有界作業クエリごと」のルールに従っている場合、問題ではないことが判明します。そのルールは関係なく、それは単純なクエリ、CNAMEチェーン、A6ツリー、または無限ループのかどうかの、クエリを処理しようとする試みから生じたすべての作業に適用されます。クライアントはゾーンがひどく設定されている場合に便利な答えを取り戻すことはできませんが、適切な実装は処理も、最も邪悪なA6ツリー、チェーン、またはループの結果として、クエリの爆発を作り出すべきではありません。

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とA6のRRが異なる領域の1つは、彼らがDNSSECとの対話方法の正確な詳細です。以下のコメントは、唯一の非ゼロプレフィックスA6のRR（A6 0のRR、再度、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.

リナンバリングイベントがA6のRR（よりもAAAA RRをして長くなった後、他の物事が等しい場合、それはするのにかかる時間は、ゾーン内のアドレスをすべて再署名各アドレスレコードは、単に共通に署名するのではなく、再署名する必要があるため、プレフィックスA6 RRとゾーンのネームサーバに関連付けられているいくつかのA6 0のRR）。再署名が葉のゾーンで実行されているため、一般的に、これは重大なスケーリング問題を提示していないこと、しかし、注意してください。

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.

各アドレス断片は別個関連署名を持っているので、他のものが等しい、A6資源レコードのために戻って受信された署名を検証することに関与する多くの作業があります。同様に、A6アドレス断片およびそれらに関連するシグネチャのセットを含むDNSメッセージは、単一のAAAA（またはA6 0）と単一関連する署名と同等のパケットよりも大きくなります。

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 RRのは本当に非常によく、迅速なリナンバリングやGSEスタイルのルーティングシナリオを表すことができないので、AAAA RRのDNSSEC署名もやや問題であることを驚くべきことではありません。 AAAA RRのプレフィックスの変化についていくことが非常に急速に変化しなければならないであろう場合には、への再署名AAAA RRのに必要な時間は、法外かもしれません。

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.

ビル・ゾンマーフェルト[ゾンマーフェルト]による実証試験は、128キロバイトのL2キャッシュとNetBSDでBIND-9 DNSSEC-signzoneプログラムを実行する64メガバイトのRAMと333MHzのCeleronはラップトップは、毎秒約40 1024ビットのRSA署名を生成することができることを示唆しています。このことから外挿すると、1つのA RR、1 AAAA RR、およびホストごとに1つのNXT RRを想定し、これは10台の** 5ホスト、またはゾーンに署名する日についてをリストゾーンに署名するために、このノートPCは数時間かかることを示唆していますAAAA RRを使用して10台の** 6ホストが一覧表示されます。

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 RRの完全な再署名する大ゾーンの追加的努力は、目立つ一方で、AAAA RRをとにかくうまく動作しない迅速なリナンバリングの場合には法外であることが唯一の可能性があること。

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.

DNS動的更新は1マイナーの例外を除いて、AAAAまたはA6のRRのためにも同様に動作するように見える：A6のRRで、動的更新クライアントは、プレフィックス長とプレフィックスの名前を知っている必要があります。現在のところ、機構は、これらの値の動的更新クライアントに通知するために存在していないが、おそらくそのような機構は、DHCPの拡張を介して提供することができ、またはいくつかの他の同等物が考案され得ます。

Transition from AAAA to A6 Via AAAA Synthesis

AAAAからA6経由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は現在より広く展開A6よりもですが、A6対応のDNSソフトウェアにAAAA対応のDNSソフトウェアから移行することが可能です。このためラフな計画は、ミネアポリスでのIETF-50で発表されたとIPNGメーリングリストで議論されてきました。 IETFは、A6の拡張機能が必要であると結論するのであれば、A6に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.

この移行の詳細については、別の文書に残されているが、一般的な考え方は、DNSクライアントプログラムに代わって、反復解決を実行しているリゾルバが同等のA6のクエリを実行した結果を表すAAAAのRRを合成することができることです。自分のためにDNSSEC検証を実行する気にクライアントはAAAA合成に頼るよりも、むしろ直接A6クエリを発行しなければならないので、この場合には、AAAA RRのための同等のDNSSEC署名を生成することが可能ではないことに注意してください。

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とA6のRRとの違いは、これまでの議論のほとんどを生成しているが、逆マッピングツリーを構築するための2つの提案のメカニズム（IPv4ののIN-ADDR.ARPAツリーのIPv6の相当）もあります。

[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.

RR名はそれぞれの間でドット砕き、よく知られている接尾辞と逆と連結されたIPv6アドレスの16進表現である：[RFC1886]はIPv4アドレスに使用IN-ADDR.ARPA機構と非常に類似したメカニズムが提案されています進数字。結果のDNS名は、人間が入力するのがやや面倒ですが、プログラムが生成するのは非常に簡単です。別ラベルは、任意のビット境界上の委任がラベルレベルあたり16個のNS資源レコード集合の最大値をもたらすであろうことを意味各進数字を作ります。再び、メカニズムは、人間にとってやや面倒ですが、プログラムには非常に簡単です。 IPv4ののIN-ADDR.ARPAツリーと同じように、この方式が弱い一つの場所は、最下位のラベルに代表団を処理しています。ただし、IPv6アドレスの最下位4ビットを委任する本当の必要性はないようであることから、これは重大な制限ではありません。

[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]は、逆マッピング・ツリー内のエントリに名前を付けるの根本的に異なる方法が提案：アドレスのテキスト表現をよりむしろ使用して、それがDNSに直接バイナリアドレスを表すためにDNSラベル（「ビットラベル」）の新しい種類を使用することを提案します。これは、テキスト表現よりも大幅にコンパクトであるという利点を持っており、間違いなくそれは最初からプロトコルの中に設計されていた場合には、この目的のために使用するDNSのためのより良い解決策だったかもしれません。使用できる新しいラベルタイプの前にアップグレードする必要があり、問題の名前のいずれかの部分に対して権限のあるDNSネームサーバのすべてを、任意のリゾルバなければならないよう：残念ながら、これまでの経験は、新しいDNSラベルタイプを展開することは非常に困難であることを示唆しています解決プロセスに関与。新しいラベルの種類を理解するためにアップグレードされていない任意のネームサーバは、不正な形式であるとして、クエリを拒否します。

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.

ビットラベルアプローチの主な利点は、私たちは本当に（IPv6アドレスの最下位4ビットで委任）必要はありませんし、アップグレードの問題はビットが重要になるまで使用不可能ラベルレンダリングする可能性があるためという能力であるように思われるので、 DNSコードベースの部分は、テキストのソリューションは十分であるとの結論をエスケープすることは困難であり、アップグレードされています。

DNAME RRs

DNAMEのRR

[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]も逆マッピングツリーでA6の断片化されたアドレスに相当するものを提供する方法としてDNAME RRを使用して提案しています。これは、DNAME RRを使用することによって、人は急速なリナンバリングやA6 RRは、DNSツリーの主要部分で提供していますGSEスタイルのルーティングに対処するために、同じ能力を持つ逆マッピングツリー用のゾーンファイルを書き込むことができています。その結果、逆マッピング木でDNAMEを使用する必要性は密接にメインツリーに断片化されたA6を使用する必要性に結びついているように見える：1が必要であれば、そう他があり、もう1つは必要でない場合は、他のISN 「のいずれかトン。

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 RRのために提案されているが、彼らは、IPv6アドレスの議論の範囲外であるため、彼らはここで扱われることはありません。

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）はIPv6が急速リナンバリングやGSEのようなルーティングをするつもりされていますか？

(b) Is the reverse mapping tree for IPv6 going to require delegation in the least significant four bits of the address?

（b）はIPv6の逆マッピング木は、アドレスの最下位4ビットで委任を必要としようとしていますか？

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.

質問は、（a）の議論への鍵であるように思われます。これは実際に作るためのIPv6コミュニティのための意思決定ではなく、DNSのコミュニティです。

Question (b) is also for the IPv6 community to make, but it seems fairly obvious that the answer is "no".

質問（b）は作るためのIPv6コミュニティのためにもですが、それは、答えは「ノー」であることをかなり明白と思われます。

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.

IPv6のワーキンググループが著しく急速リナンバリングやGSEのようなルーティングを指定して展開する場合（1）、我々は、メインツリーにA6 RRを使用して、逆ツリーで必要に応じてDNAME RRを使用することに移行すべきです。

(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 RRを使用しないでください。

(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）いずれの場合においても、逆ツリーは[RFC1886]で説明テキスト表現ではなく、[RFC2874]に記載のビットラベル表現を使用する必要があります。

(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）私たちは、メインツリーにA6 RRを使用すると、我々は適用文と、これらの機能の過度に複雑な用途を阻止するために設計された実装ガイドラインを記述する必要があり、逆木でDNAMEのRRを使用して行く場合。一般的に、A6 0 RRを使用し、DNAMEのRRを使用せずに十分に説明することができ、任意のネットワークは、そのように説明しなければならない、と強化された機能は絶対に必要な、我々は彼らとより多くの経験を持っており、少なくともまで持っていたときにのみ使用してくださいその故障モードをより良く理解します。

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:

このノートでは、同様のセキュリティ特性を持つ2つのメカニズムを比較し、これらの二つのメカニズムの間の選択にはいくつかのセキュリティ上の影響があります。

(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）2つのメカニズムが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）プロトコルの複雑さは、セキュリティの敵であること限り、[RFC2874]の追加のプロトコルの複雑[RFC1886]と比較して、セキュリティ上のいくつかの影響を与えます。

IANA Considerations

IANAの考慮事項

None, since all of these RR types have already been allocated.

なし、これらのRRタイプの全てが既に割り当てられているからです。

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.

このノートは（少なくとも）8年間のパブリックとプライベートの両方の議論の数に基づいていますが、特定のおかげでアラン・デュラン、ビルゾンマーフェルト、クリスチャンのHuitema、Jun-ichiro itojun Haginoは、マーク・アンドリュース、マット・クロフォードに行くされ、オラフルグドムンソン、ランディブッシュ、とスートムソンは、のどれも作者が自分のアイデアをやったことの責任ではありません。

References

リファレンス

[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.

"IPバージョン6をサポートするためのDNS拡張機能" [RFC1886]トムソン、S.とC.のHuitema、RFC 1886、1995年12月。

[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.

[RFC2874]クロフォード、M.とC.のHuitemaは、RFC 2874、2000年7月 "DNSの拡張機能は、IPv6アドレスの集約とリナンバリングを支援します"。

[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ゾーンのコピーに対して行われた実験の結果をまとめ、2001年3月21日付。

[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]「GSEは、」1996年のIPngワーキンググループで議論し、いわゆる「8 + 8」の提案の進化と1997年GSEの提案自体は有効期限が切れたので、長い間持っているインターネットドラフトとして書き上げありました。 GSEの詳細と歴史に関心のある読者は、その期間からのIPngワーキンググループのメーリングリストのアーカイブと分を確認してください。

Author's Address

著者のアドレス

Rob Austein

ロブAusteinと

EMail: sra@hactrn.net

メールアドレス：sra@hactrn.net

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。