RFC3364 日本語訳

Network Working Group                                         R. Austein
Request for Comments: 3364                           Bourgeois Dilettant
Updates: 2673, 2874                                          August 2002
Category: Informational

Austeinがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3364ブルジョアDilettantは以下をアップデートします。 2673、2874年2002年8月のカテゴリ: 情報

             Tradeoffs in Domain Name System (DNS) Support
                 for Internet Protocol version 6 (IPv6)

インターネットプロトコルバージョン6のドメインネームシステム(DNS)サポートにおける見返り(IPv6)

Status of this Memo

この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)インターネット協会(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.

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.

RFC1886[RFC1886]は、DNSのIPv6アドレスをサポートするために簡単なメカニズムを指定しました。 これらのメカニズムは密接にIPv4を支持するのに使用されるメカニズムに類似して、CIDR. 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.

RFC2874[RFC2874]は、DNSのIPv6アドレスをサポートするために高められたメカニズムを指定しました。 これらのメカニズムはアドレスの基礎となりながらネットワーク形態を反映できる方法で複数のDNSリソース記録に壊れるのをDNSに格納されたIPv6アドレスに可能にする新機能を提供します、その結果、ある種類の不可能であるか、またはこれらのメカニズムなしで表すのが、より難しいネットワーク形態変化かルーティング構造を反映するのをDNSに格納されたデータに可能にします。また、RFC2874は現在、Proposed Standardとして記載されます。

Austein                      Informational                      [Page 1]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[1ページ]のRFC3364見返り

   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 Standardsの両方は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つのものは私たちが現在このすべてのレアルSoonに関する心を決めるべきであるということです。

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が非常に一般的であり、AAAA RRによって[RFC1886]に提供された機能性のスーパーセットを提供している間、ゾーンファイル世代の間の前処理で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.

1つの特定の領域がA6 RRsがAAAA RRsを使用することで提供できない何かを提供するところにあります: A6 RRsはパーティーによるどんな動作(または、恐らく知識さえ)もアドレスの末端部(最下位ビット)を含むDNSゾーンを制御しないでアドレスの接頭語部分が変化できるアドレスを表すことができます。 これはいわゆる「急速な番号を付け替える」シナリオ(全体のネットワークの接頭語が非常に急速に変化するかもしれないところ)と前の"GSE"提案[GSE](アドレスの「ルーティンググープ」部分はいきなり変化するようになることがあるかもしれないところ)などのルーティング構造の両方を含んでいます。 A6 RRsは出来事に番号を付け替えさせながら、完全にすべての間に葉のゾーンをアップデートする必要性を取り除くというわけではありませんが(例えば、通常、ISPを変えるのは上向きの代表団ポインタへの変化を必要とするでしょう)、A6 RRsの慎重な使用はそのような出来事の間、最小限に変化する必要があるRRsの数を保つかもしれません。

   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 RRsを組み立てるのがまさにA6 RRsがDNSに格納する情報の種類を必要とすることに注意してください。 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つの「無駄な」八重奏がある)に意味的に同等であるので、また、何かA6 RRと共にAAAA RRと共にできることができるということである、」

Austein                      Informational                      [Page 2]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[2ページ]のRFC3364見返り

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によって提供された機能性の部分集合だけを提供している間に[RFC1886]で提案されたAAAA 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が本質的にはIPv4Aの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から顔を背けるための正当化であるということです。

Austein                      Informational                      [Page 3]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[3ページ]のRFC3364見返り

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のチェーンを決議するのは、何に関するシリーズがほとんど独立している質問であるかと決議することを伴いますが、全く伴うというわけではありません。 それぞれのこれらのサブ質問はいくらかの非ゼロ時間がかかります、リゾルバのローカルなキャッシュに答えがたまたま既にない場合。 AAAA RRを決議すると時間Tが基線としてみなされると仮定する場合、私たちは、それがA6 RRsのN-リンク・チェーンを決議するために時間N*Tにアプローチしながら平均で何かを取ると推測できます、私たちは、アドレスの、より重要なビットを表すA6断片のためのかなり良いキャッシュ要素を見ると予想するでしょうが。 これは2つの選択を私たちに残します:そのどちらも非常に良くはありません。 私たちがレゾルバが、各断片を待っても構わないと思う時間に減少できますか、または私たちはレゾルバが、失敗をクライアントに返す前に待っても構わないと思う時間に増加できます。 私たちがこの問題に関してどんな小さいデータを持っているかがユーザが既に彼らがIPv6インターネットのかなり長い遅れに我慢強い傾向がないと示唆するIPv4インターネットでA 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

いっそう困ったことに、A6 RRsが急速な番号を付け替えるのに重要であるかGSEのようなルーティングである傾向がある場所はA6 RRの接頭語名前欄がA6 RRを含んでいて、DNSゾーンだけの外にありませんが、異なった組織によって管理される目標を示す(例えば、エンドユーザのサイトの場合では、接頭語名はたぶん接続性をサイトに提供するISPに属す名前を示すでしょう)状況です。 ゾーンからのポインタはそういうものの問題ではありませんが、他の組織へのポインタは、いくらか維持するのが難しくて少ないです。

Austein                      Informational                      [Page 4]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[4ページ]のRFC3364見返り

   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.

オートメーションに影響されやすい、単純組織の中のポインタであるだろうより。 接着剤RRsとPTR RRsのIN ADDR.ARPA木の経験が、多くのゾーンの管理者がどのように適切にこれらのポインタをセットアップして、維持するかを本当に理解していないのを示して、私たちはそれらが今日持っているほどこれらのゾーンの管理者がA6チェーンによる、より良い仕事をすると信じるどんな特定の理由も持っていません。 しかしながら、公正に、なるように、ゾーンをロードする前の前処理でAAAA RRsを造る代替のケースに、同じ問題の多くがあります。 せいぜい、1つは、DNSクライアントがAAAA RRsを使用するのにこのために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.

最終的に、失敗するように質問がどれくらいありそうであるかへの近い総無知を仮定する場合、N-リンクA6チェーンがある失敗の確率はおよそNに比例しているように見えるでしょう、A6チェーンを決議するのにかかわるそれぞれの質問がただ一つのAAAA質問としての失敗の同じ確率を持っているでしょう、したがって。 このコメントがその過程で得られたデータではなく、質問を決議する過程による失敗に適用されることにもう一度注意してください。 論証上、理想の世界では、A6 RRsが正しいので、クライアントが(最終的に)得る答えの確率を増加させるでしょう、何も質問の過程で支障をきたしませんが、私たちにはここにどのようにこの注意のほかの場所で使用された手-wavey範囲にさえその仮定を定量化するかというどんな本当の考えもないと仮定して。

   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デザインは接頭語に合っている1A6 RRが葉の一部をA6 RRと命名するということであるそこの可能性を含んでいます。 すなわち、A6チェーンが簡単な繋がっているリストでないかもしれない、事実上、それは木であるかもしれません、各ブランチが可能な接頭語を表すところで。 A6の何人かの評論家がこれが質問の無計画的な拡大に通じることを心配していましたが、これはレゾルバが単にRFC1034(35ページ)で説明された「1質問あたりの境界がある仕事」規則に従うなら問題でないと判明します。 その規則は、質問を処理する試みから生じながらすべて働くのに当てはまります、それが簡単な質問、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と対話するかに関する正確な詳細にあります。 以下のコメントは非無接頭語A6 RRsだけに適用されます(A6 0 RRsはAAAA RRsにもう一度意味的に同等です)。

Austein                      Informational                      [Page 5]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[5ページ]のRFC3364見返り

   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 RRsと共にA6 RRs(むしろそれぞれのアドレス記録がただ一般的な接頭語A6 RRとゾーンのネームサーバに関連しているいくつかのA6 0 RRsにサインするより再契約されなければならないので)より長いです。 しかしながら、一般に、これが重大なスケーリング問題を提示しないことに注意してください、再契約が葉のゾーンで実行されるので。

   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のために受けられた署名について確かめるのにかかわるより多くの仕事があります、それぞれのアドレス断片には別々の関連署名があるので。 同様に、1セットの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.

ビル・ゾンマーフェルト[ゾンマーフェルト]による実証的検定は128KBのL2キャッシュでその333MHzのセレロンラップトップを示します、そして、BIND-9 dnssec-signzoneが386BSD派生のOSの下でプログラムする64MBのRAM走行は1秒あたりおよそ40の1024年のビットのRSA署名を発生させることができます。 1つAがRRと、1AAAA RRと、1ホストあたり1NXT RRであると仮定して、これから推定して、これは、AAAA RRsを使用することで10**6ホストを記載するゾーンにサインするように5人のホスト、またはおよそ1日間10**を記載するゾーンにサインするにはこのラップトップに数時間かかると示唆します。

   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のダイナミックなアップデートは1つの小さい方の例外があるAAAAかA6 RRsに等しくうまくいくように見えます: A6 RRsと共に、ダイナミックなアップデートクライアントは、接頭語の長さと接頭語名を知る必要があります。 現在のところ、メカニズムが全くこれらの値についてダイナミックなアップデートクライアントに知らせるために存在しませんが、おそらく、DHCPへの拡大でそのようなメカニズムを提供できるだろう、だろう、だろう、だろう、だろう、だろう、だろうか、ある他の同等物について工夫できました。

Austein                      Informational                      [Page 6]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[6ページ]のRFC3364見返り

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質問を実行するという結果を表すAAAA RRsを統合できたということです。 自分たちのためにDNSSEC合法化を実行するのと気にかけるクライアントがAAAA統合に依存するより直接むしろA6に質問を発行しなければならないように、この場合AAAA RRのために同等なDNSSEC署名を発生させるのが可能でないことに注意してください。

Bitlabels

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の違いはこれまでの議論の大部分を発生させましたが、また、逆のマッピング木(IPv4INの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進数字を別々のラベルにするのは、任意のビット境界の代表団がラベルレベルあたり最大16NS RRsetsをもたらすことを意味します。 一方、メカニズムは、人間にとっていくらか退屈ですが、非常にプログラムしやすいです。 IPv4のIN-ADDR.ARPA木のように、取り扱い代表団にはこの計画が弱い1つの場所が最も重要でないラベルにあります。 しかしながら、代表として派遣する中で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

[RFC2874]は逆のマッピング木でエントリーを命名する根本的に異なった方法を提案しました: アドレスの原文の表現を使用するよりむしろ、それは、直接DNSの2進のアドレスを表すのに、新しい種類のDNSラベル(「噛み付いているラベル」)を使用するよう提案します。 これは、原文の表現よりかなりコンパクトであることの利点を持って、このためにそれがプロトコルに設計されたなら、論証上DNSが使用するより良い解決策だったでしょうに。

Austein                      Informational                      [Page 7]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[7ページ]のRFC3364見返り

   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.

着手から。 残念ながら、これまでの経験は、新しい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を使用する必要性に結ばれるように見えます: 1つが必要であるなら、もう片方もそうです、そして、1つは必要でないなら、もう片方がどちらかではありません。

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

また、作るIPv6共同体には質問(b)がありますが、答えが「いいえ」であることはかなり明白に見えます。

Austein                      Informational                      [Page 8]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[8ページ]のRFC3364見返り

   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 RRsを使用することへの変遷を配備するべきです。

   (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を使用することに行くなら、私たちはこれらの特徴の過度に複雑な用途に水をさしているように設計された適用性証明と実施要綱を書くべきです。 一般に、DNAME RRsを使用しないで、説明できるどんなネットワークも、適切にA6 0 RRsを使用して、そのように説明されるべきです、そして、絶対に必要であるときにだけ、拡張機能は使用されるべきです、私たちが少なくともそれらのずっと多くの経験を持っていて、それらの故障モードの、より良い理解を持つまで。

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との相互作用」に(above)の権利を与えたのを確実にしてください。

   (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タイプのすべてを割り当てて以来のなし。

Austein                      Informational                      [Page 9]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[9ページ]のRFC3364見返り

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、6月-ichiro itojun Hagino、マーク・アンドリュース、マット・クロフォード、Olafurグドムンソン、ランディ・ブッシュ、およびスー・トムソンのものになります。そのいずれも作者が彼らの考えでしたことに原因となりません。

References

参照

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

IPを支持してください。[RFC1886] トムソン、S.、およびC.Huitema、「DNS Extensions、バージョン6インチ、RFC1886、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、「IPv6アドレス集合を支持して、番号を付け替えることへのDNS拡張子」、RFC2874、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.

ビル・ゾンマーフェルトからの作者への[ゾンマーフェルト]プライベート・メッセージは2001年3月21日の日付を入れました、彼が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"がいわゆる発展であった、「8 +8 」 1996年と1997年にIPngワーキンググループによって議論された提案。 GSE提案自体はインターネット草稿として詳しく書かれました。(長い間、それは、以来、期限が切れています)。 GSEの詳細と歴史に興味を持っている読者はその期間からのIPngワーキンググループのメーリングリストが格納するレビューと数分がそうするべきです。

Author's Address

作者のアドレス

   Rob Austein

ロブAustein

   EMail: sra@hactrn.net

メール: sra@hactrn.net

Austein                      Informational                     [Page 10]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002

IPv6 August 2002のDNSサポートにおけるAusteinの情報[10ページ]のRFC3364見返り

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

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

Austein                      Informational                     [Page 11]

Austein情報です。[11ページ]