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)

インターネットプロトコルバージョン6（IPv6）のドメイン名システム（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.

Copyright（c）The Internet Society（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アドレスをサポートするための簡単なメカニズムを指定しました。これらのメカニズムは、IPv4をサポートするために使用されるメカニズムに非常に似ており、CIDRの経験に基づいた逆マッピングメカニズムを軽度に改善します。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に保存されているIPv6アドレスを、アドレスの根底にあるネットワークトポロジを反映できる方法で複数のDNSリソースレコードに分割できるようにする新しい機能を提供し、DNSに保存されているデータが可能になります。これらのメカニズムなしでは、不可能または表現がより困難な特定の種類のネットワークトポロジの変更またはルーティングアーキテクチャを反映します。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.

そこにあることの1つは、広範囲にわたる合意であるように思われることです。私たちは、この現実のすべてについてすぐに決心すべきだということです。

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.

[RFC2874]で提案されているA6 RRは非常に一般的であり、[RFC1886]のAAAA RRによって提供される機能のスーパーセットを提供しますが、A6の機能の多くは、ゾーンファイルの生成中の前処理を介してAAAA RRSで実装することもできます。

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 RRSがAAAA RRSを使用して提供できないものを提供する特定の領域が1つあります。A6RRSは、アドレスのプレフィックス部分が、DNSゾーンを管理する当事者によってアクション（またはおそらく知識さえ）なしで変更できるアドレスを表すことができます。アドレスの端子部分（最小有意なビット）。これには、いわゆる「迅速な変更」シナリオ（ネットワーク全体のプレフィックスが非常に迅速に変更される可能性がある場合）と、以前の「GSE」提案[GSE]（アドレスの「ルーティンググープ」部分が件名の対象となる可能性のあるルーティングアーキテクチャの両方が含まれます。警告なしに変更する）。A6 RRSは、すべての変更イベント中に葉のゾーンを更新する必要性を完全に削除するわけではありません（たとえば、ISPを変更するには通常、上向きの委任ポインターの変更が必要です）が、A6 RRSを慎重に使用すると、変更する必要がある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 RRSが保存する種類の情報が正確に必要であることに注意してください。これは、仮想のプリプロセッサが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（ワイヤ表現に1つの「無駄にした」オクテット）と意味的に同等であることに注意してください。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:

[RFC1886]で提案されたAAAA RRは、[RFC2874]で提案されているA6 RRによって提供される機能のサブセットのみを提供し、推奨する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 RRSは、IPv4のA RRSと本質的に同一（長さ以外）であるため、AAAA RRSに関連する使用パターン、障害シナリオなどを予測するのに役立つ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 RRSは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.

A6の代わりにAAAAを使用するというプレッシャーの一部は、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 RRSを超えるAAAA RRSを支持する別の議論は、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 RRSとは異なる機能に直接起因するA6 RRSには、チェーンを介してアドレスを構築する能力を備えたいくつかの潜在的な問題もあります。

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 RRSのチェーンを解決するには、ほぼ独立したクエリのシリーズを解決することが含まれますが、完全ではありません。回答がすでにリゾルバーのローカルキャッシュに含まれていない限り、これらのサブQuerieはそれぞれゼロ以外の時間がかかります。AAAA RRを解決することはベースラインとして時間がかかると仮定すると、平均して、A6 RRSのNリンクチェーンを解決するために時間n*tに近づく何かが必要であると推測できますが、アドレスのより重要なビットを表すA6フラグメントの優れたキャッシング係数。これにより、2つの選択肢が残りますが、どちらも非常に良いものではありません。リゾルバーが各フラグメントを待つ意思のある時間を短縮するか、リゾルバーが障害を返す前に待機する時間を増やすことができます。クライアントに。このテーマに関する私たちが持っているデータがほとんどないことは、ユーザーがIPv4インターネットのRRSを解決するのにかかる時間にすでに焦りがちであることを示唆しています。同時に、クエリを時期尚早に終了することは、リソースの無駄とユーザーのフラストレーションの別のソースの両方です。したがって、長い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 RRのプレフィックス名フィールドがA6を含むDNSゾーンの外側だけではないターゲットを指している状況です。RRですが、別の組織によって管理されています（たとえば、エンドユーザーのサイトの場合、プレフィックス名は、サイトに接続を提供するISPに属する名前を指します）。ゾーンからのポインターはそれ自体は問題ではありませんが、他の組織へのポインターは、維持がやや難しく、単一の組織内のポインターよりも自動化の影響を受けにくいです。接着剤RRSとIn-ADDR.ARPAツリーのPTR RRSの両方で経験することは、多くのゾーン管理者がこれらのポインターを適切にセットアップおよび維持する方法を実際に理解していないことを示唆しています。A6チェーンでは、今日よりも良い仕事です。ただし、公平を期すために、ゾーンを積み込む前に前処理を介してAAAA RRを構築する代替ケースには、同じ問題が多くあります。せいぜい、この目的のためにAAAA RRSを使用すると、DNSクライアントがA6 RRSよりも幾分効率的に誤った答えを得ることができると主張できます。

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-Link A6チェーンでの障害の確率はNにほぼ比例しているように見えます。単一のAAAAクエリとしての障害の確率。このコメントは、そのプロセスで得られたデータではなく、クエリを解決するプロセスの障害に適用されることに再度注意してください。おそらく、理想的な世界では、A6 RRSはクライアントが（最終的に）正しくなる答えの確率を高めます。このメモの他の場所で使用されている手帯の範囲で。

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 RRSに関して過去に提起された潜在的な問題の1つは、深刻な問題ではないことが判明しました。A6デザインには、Leaf A6 RRのプレフィックス名部分に1つ以上の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 RRSが異なる領域の1つは、DNSSECとの相互作用の正確な詳細です。以下のコメントは、非ゼロ-Prefix A6 RRSにのみ適用されます（A6 0 RRSは、再び、AAAA RRとセマンティックに同等です）。

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 RRSよりもAAAA RRSの方が長くなります（各アドレスレコードは単に共通に署名するのではなく、再署名する必要があるためゾーンの名前サーバーに関連付けられているプレフィックス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 RRSの署名を確認することに関与する作業が増えています。同様に、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 RRSは、迅速な変更またはGSEスタイルのルーティングシナリオを非常にうまく表現できないため、AAAA RRSのDNSSEC署名もやや問題があることは驚くべきことではありません。接頭辞の変更に追いつくためにAAAA RRSが非常に迅速に変更されなければならない場合、AAAA RRSを再署名するのに必要な時間は法外な場合があります。

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 Laptopと、NETBSDの下で9 DNSSEC-Signzoneプログラムを実行する64MB RAMが約40 1024ビットRSA署名を生成できることを示唆しています。これから外挿して、ホストごとにRR、1つのAAAA RR、および1つのNXT RRを想定して、これは、このラップトップが10 ** 5ホストのリストに署名するのに数時間かかること、またはゾーンに署名するために約1日かかることを示唆しています。AAAA RRSを使用して、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 RRSでいっぱいの大規模なゾーンに再署名する追加の努力は、AAAA RRSがとにかくうまく機能しない急速な改修の場合にのみ禁止される可能性が高いことを示唆しています。

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ダイナミックアップデートは、AAAAまたはA6 RRSでも同様に機能しているように見えますが、1つのマイナーな例外があります。A6RRSを使用すると、動的更新クライアントはプレフィックスの長さとプレフィックス名を知る必要があります。現在、動的更新クライアントにこれらの値を通知するメカニズムは存在しませんが、おそらくそのようなメカニズムはDHCPへの拡張を介して提供されるか、他の同等物を考案することができます。

Transition from AAAA to A6 Via AAAA Synthesis

AAAA合成を介してAAAAからA6への移行

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よりも広く展開されていますが、AAAAに同意したDNSソフトウェアからA6対応DNSソフトウェアに移行することができます。このための大まかな計画は、ミネアポリスのIETF-50で提示され、IPNGメーリングリストで議論されています。したがって、IETFがA6の強化された機能が必要であると結論付けた場合、AAAAからA6に移行できるはずです。

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クエリを実行した結果を表すAAA RRを合成できるということです。この場合、AAAA RRの同等のDNSSEC署名を生成することは不可能であるため、DNSSEC検証を自分で実行することを気にするクライアントは、AAAA合成に依存するのではなく、A6クエリを直接発行する必要があります。

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

[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]は、IPv4アドレスに使用されるIN-ADDR.ARPAメカニズムに非常によく似たメカニズムを提案します。RR名は、IPv6アドレスの16進表現です。16進数桁。結果のDNS名は、人間がタイプするのがやや退屈ですが、プログラムが生成するのは非常に簡単です。各16進数桁を個別のラベルにすることは、任意のビット境界の代表団がラベルレベルごとに最大16 ns rrsetになることを意味します。繰り返しますが、このメカニズムは人間にとってやや退屈ですが、プログラムするのは非常に簡単です。IPv4のIn-Addr.Arpa Treeと同様に、このスキームが弱い場所は、最も重要なラベルの代表団を処理することです。ただし、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 rrs

[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 RRSを使用することも提案しています。つまり、DNAME RRSを使用することにより、A6 RRがDNSツリーの主要部分で提供する迅速な変更またはGSEスタイルのルーティングに対処する能力を持つ逆マッピングツリーのゾーンファイルを書き込むことができます。その結果、逆マッピングツリーでDNAMEを使用する必要性は、メインツリーで断片化されたA6を使用する必要性と密接に結びついているように見えます。どちらか。

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）は議論の鍵であると思われます。これは、DNSコミュニティではなく、IPv6コミュニティが作成する決定です。

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.

(1) IPv6のワーキンググループが、迅速な変更またはGSEのようなルーティングを真剣に指定および展開する場合、メインツリーで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 RRSを使用しないでください。

(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) メインツリーでA6 RRSを使用し、逆ツリーでDNAME RRSを使用する場合は、これらの機能の過度に複雑な使用を阻止するように設計されたアプリケーションステートメントと実装ガイドラインを記述する必要があります。一般に、A6 0 RRSを適切に使用し、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つのメカニズムを比較しますが、これら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) プロトコルの複雑さがセキュリティの敵である限り、[RFC1886]と比較した[RFC2874]の追加のプロトコルの複雑さは、セキュリティにある程度の影響を与えます。

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年の期間にわたって公的および私的の両方の議論に基づいていますが、特に感謝します。特に感謝します。Olafur Gudmundsson、Randy Bush、Sue Thomsonは、著者が自分のアイデアで何をしたかについて責任を負いません。

References

参考文献

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

[RFC1886] Thomson, S. および C. Huitema、「IP バージョン 6 をサポートする DNS 拡張機能」、RFC 1886、1995 年 12 月。

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

[RFC2874] Crawford、M。およびC. Huitema、「IPv6アドレスの集約と変更をサポートするDNS拡張」、RFC 2874、2000年7月。

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

[Sommerfeld] 2001年3月21日付のBill Sommerfeldからの著者へのプライベートメッセージ。MIT.EDUゾーンのコピーで彼が行った実験の結果を要約しました。

[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年と1997年にIPNGワーキンググループが議論したいわゆる「8 8」の提案の進化でした。GSEの提案自体は、長い間失効しているインターネットドラフトとして書かれています。GSEの詳細と歴史に興味のある読者は、IPNGワーキンググループのメーリングリストアーカイブとその期間の議事録を確認する必要があります。

Author's Address

著者の連絡先

Rob Austein

ロブ・オーストイン

   EMail: sra@hactrn.net
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。