[要約] RFC 6563は、A6レコードタイプを歴史的なステータスに移行することを提案しています。この提案の目的は、A6レコードの使用が減少しているため、その機能を他の方法で代替することを推奨することです。
Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6563 Huawei Technologies Co., Ltd
Category: Informational D. Conrad
ISSN: 2070-1721 Cloudflare, Inc.
B. Carpenter
Univ. of Auckland
March 2012
Moving A6 to Historic Status
A6を歴史的ステータスに移行する
Abstract
概要
This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators.
このドキュメントは、A6レコードの使用に関連する問題の概要を提供し、現在のステータスについて説明し、RFC 2874を履歴ステータスに移行し、実装者とオペレーターに明確さを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6563.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6563で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction and Background .....................................2
1.1. Standards Action Taken .....................................3
2. A6 Issues .......................................................3
2.1. Resolution Latency .........................................3
2.2. Resolution Failure .........................................3
2.3. Cross Administrative Domains ...............................4
2.4. Difficult Maintenance ......................................4
2.5. Existence of Multiple RR Types for One Purpose is Harmful ..4
2.6. Higher Security Risks ......................................4
3. Current Usage of A6 .............................................5
3.1. Reasons for Current A6 Usage ...............................5
4. Moving A6 to Historic Status ....................................6
4.1. Impact on Current A6 Usage .................................6
4.2. Transition Phase for Current A6 Usage ......................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgments .................................................6
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................7
The IETF began standardizing two different DNS protocol enhancements for IPv6 addresses in DNS records: AAAA was specified in 1995 as a Proposed Standard [RFC1886] and later in 2003 as a Draft Standard [RFC3596], and A6 appeared in 2000 as a Proposed Standard [RFC2874].
IETFは、DNSレコードのIPv6アドレス用に2つの異なるDNSプロトコル拡張機能の標準化を開始しました。AAAAは1995年に提案標準[RFC1886]として指定され、2003年にドラフト標準[RFC3596]として指定され、A6は2000年に提案標準[ RFC2874]。
The existence of multiple ways to represent an IPv6 address in the DNS has led to confusion and conflicts about which of these protocol enhancements should be implemented and/or deployed. Having more than one choice of how IPv6 addresses are to be represented within the DNS can be argued to have led to delays in the deployment of IPv6. In 2002, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)" [RFC3363] moved A6 to Experimental status, with an aim of clearing up any confusion in this area. [RFC3363] and [RFC3364] compared AAAA and A6, and examined many of the issues in the A6 standard; these issues are summarized in this document.
DNSでIPv6アドレスを表す複数の方法が存在するため、これらのプロトコル拡張のどれを実装または展開する必要があるかについて混乱と競合が発生しています。 DNS内でIPv6アドレスをどのように表現するかについて複数の選択肢があることは、IPv6の展開に遅延をもたらしたと主張することができます。 2002年、「ドメインネームシステム（DNS）でのインターネットプロトコルバージョン6（IPv6）アドレスの表現」[RFC3363]は、この領域の混乱を解消することを目的として、A6を試験運用ステータスに移動しました。 [RFC3363]と[RFC3364]はAAAAとA6を比較し、A6標準の問題の多くを調べました。これらの問題はこのドキュメントで要約されています。
After ten years, the Experimental status of A6 continues to result in confusion and parallel deployment of both A6 and AAAA, albeit AAAA predominates by a large degree. In recent IPv6 transition tests and deployments, some providers informally mentioned A6 support as a possible future choice.
10年後、AA6の大部分が圧倒的に多いにもかかわらず、A6の実験的ステータスは、A6とAAAAの両方の混乱と並行展開をもたらし続けています。最近のIPv6移行テストと展開では、一部のプロバイダーは、A6サポートを将来の可能な選択肢として非公式に述べています。
This document provides a brief summary of the issues related to the use of A6 records and discusses the current usage status of A6. Given the implications of A6 on the DNS architecture and the state of A6 deployment, this document moves RFC 2874 [RFC2874] to Historic status, thereby clarifying that implementers and operators should represent IPv6 addresses in the DNS by using AAAA records only.
このドキュメントでは、A6レコードの使用に関連する問題の概要と、A6の現在の使用状況について説明します。 DNSアーキテクチャとA6展開の状態に対するA6の影響を考慮して、このドキュメントはRFC 2874 [RFC2874]を歴史的ステータスに移行し、それによって実装者とオペレーターがAAAAレコードのみを使用してDNSでIPv6アドレスを表す必要があることを明確にします。
Per this document, the status of RFC 2874 has been changed from Experimental to Historic.
このドキュメントに従って、RFC 2874のステータスは実験的から歴史的に変更されました。
This section summarizes the known issues associated with the use of A6 resource records (RRs), including the analyses explored in [RFC3363]. The reader is encouraged to review that document to fully understand the issues relating to A6.
このセクションでは、[RFC3363]で検討されている分析を含め、A6リソースレコード（RR）の使用に関連する既知の問題をまとめています。読者は、A6に関連する問題を完全に理解するためにそのドキュメントを確認することをお勧めします。
Resolving an A6 record chain can involve resolving a series of subqueries that are likely to be independent of each other. Each of these subqueries takes a non-negligible amount of time unless the answer already happens to be in the resolver's cache. In the worst-case scenario, the time spent resolving an N-link chain A6 record would be the sum of the latency resulting from each of the N resolutions. As a result, long A6 chains would likely increase user frustration due to an excessive wait time for domain names to resolve.
A6レコードチェーンの解決には、互いに独立している可能性が高い一連のサブクエリの解決が含まれる場合があります。これらの各サブクエリは、回答がリゾルバのキャッシュに既に存在しない限り、無視できないほどの時間がかかります。最悪のシナリオでは、NリンクチェーンA6レコードの解決に費やされた時間は、N個の解決のそれぞれから生じるレイテンシの合計になります。その結果、ドメイン名が解決されるまでの待機時間が長くなり、A6チェーンが長いとユーザーの不満が高まる可能性があります。
In practice, it is very hard to derive a reasonable timeout-handling strategy for the reassembly of all the results from A6 subqueries. It has proved difficult to decide multiple timeout parameters, including: (1) the communication timeout for a single A6 fragment, (2) the communication timeout for the IPv6 address itself (total time needed for reassembly), and (3) the Time to Live (TTL) timeout for A6 fragment records.
実際には、A6サブクエリからのすべての結果を再構成するための適切なタイムアウト処理戦略を導き出すことは非常に困難です。 （1）単一のA6フラグメントの通信タイムアウト、（2）IPv6アドレス自体の通信タイムアウト（再構成に必要な合計時間）、および（3）時間A6フラグメントレコードのライブ（TTL）タイムアウト。
The probability of A6 resolution failure during the process of resolving an N-link A6 chain is the sum of the probabilities of failure of each subquery, since each of the queries involved in resolving an A6 chain has a nonzero probability of failure, and an A6 resolution cannot complete until all subqueries have succeeded.
NリンクA6チェーンの解決プロセス中のA6解決の失敗の確率は、各サブクエリの失敗の確率の合計です。これは、A6チェーンの解決に関連する各クエリの失敗の確率がゼロではなく、A6すべてのサブクエリが成功するまで、解決は完了できません。
Furthermore, the failure may happen at any link among 1~N of an N-Link A6 chain. Therefore, it would take an indeterminate time to return a failure result.
さらに、障害はN-Link A6チェーンの1〜N間のリンクで発生する可能性があります。したがって、失敗の結果が返されるまでに不確定な時間がかかります。
One of the primary motivations for the A6 RR is to facilitate renumbering and multihoming, where the prefix name field in the A6 RR points to a target that is not only outside the DNS zone containing the A6 RR, but is administered by a different organization entirely.
A6 RRの主な動機の1つは、再番号付けとマルチホーミングを容易にすることです。A6RRのプレフィックス名フィールドは、A6 RRを含むDNSゾーンの外部にあるだけでなく、別の組織によって完全に管理されているターゲットを指します。 。
While pointers out-of-zone are not a problem per se, experience both with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that pointers to other organizations are often not maintained properly, perhaps because they're less amenable to automation than pointers within a single organization would be.
ゾーン外のポインター自体は問題ではありませんが、グルーRRとIN-ADDR.ARPAツリーのPTR RRの両方の経験から、他の組織へのポインターは適切に維持されていないことが多いことがわかります。単一の組織内でのポインターよりも自動化することになります。
In A6, changes to components of an RR are not isolated from the use of the composite IPv6 address. Any change to a non-128-bit component of an A6 RR may cause change to a large number of IPv6 addresses. The relationship dependency actually makes the maintenance of addresses much more complicated and difficult. Without understanding these complicated relationships, any arbitrary change for a non-128-bit A6 RR component may result in undesired consequences.
A6では、RRのコンポーネントへの変更は、複合IPv6アドレスの使用から分離されません。 A6 RRの128ビット以外のコンポーネントを変更すると、多数のIPv6アドレスが変更される可能性があります。関係の依存関係は、実際にはアドレスの保守をはるかに複雑かつ困難にします。これらの複雑な関係を理解していないと、128ビット以外のA6 RRコンポーネントの任意の変更により、望ましくない結果が生じる可能性があります。
Multiple correlative subcomponents of A6 records may have different TTLs, which can make cache maintenance very complicated.
A6レコードの複数の相関サブコンポーネントには異なるTTLがあり、キャッシュのメンテナンスが非常に複雑になる可能性があります。
If both AAAA and A6 records were widely deployed in the global DNS, it would impose more query delays to the client resolvers. DNS clients have insufficient knowledge to choose between AAAA and A6 queries, requiring local policy to determine which record type to query. If local policy dictates parallel queries for both AAAA and A6 records, and if those queries returned different results for any reason, the clients would have no knowledge about which address to choose.
AAAAレコードとA6レコードの両方がグローバルDNSに広く展開されている場合、クライアントリゾルバーにより多くのクエリ遅延が課されます。 DNSクライアントには、AAAAクエリとA6クエリのどちらを選択するかについての十分な知識がないため、クエリするレコードタイプを決定するローカルポリシーが必要です。ローカルポリシーがAAAAとA6の両方のレコードに対して並列クエリを指示し、それらのクエリが何らかの理由で異なる結果を返した場合、クライアントはどのアドレスを選択するかについての知識がありません。
The dependency relationships inherent in A6 chains increase security risks. An attacker may successfully attack a single subcomponent of an A6 record, which would then influence many query results, and possibly every host on a large site. There is also the danger of unintentionally or maliciously creating a resolution loop -- an A6 chain may create an infinite loop because an out of zone pointer may point back to another component farther down the A6 chain.
A6チェーンに固有の依存関係は、セキュリティリスクを増大させます。攻撃者は、A6レコードの単一のサブコンポーネントを攻撃する可能性があり、その結果、多くのクエリ結果に影響を与え、場合によっては大規模サイトのすべてのホストに影響を及ぼします。また、意図せずにまたは故意に解決ループを作成する危険もあります。ゾーン外ポインターがA6チェーンのさらに下にある別のコンポーネントを指す可能性があるため、A6チェーンが無限ループを作成する可能性があります。
Full support for IPv6 in the global DNS can be argued to have started when the first IPv6 records were associated with root servers in early 2008.
グローバルDNSでのIPv6の完全サポートは、最初のIPv6レコードが2008年の初めにルートサーバーに関連付けられたときに始まったと主張できます。
One of the major DNS server software packages, BIND9 [BIND], supports both A6 and AAAA, and is unique among the major DNS resolvers in that certain versions of the BIND9 resolver will attempt to query for A6 records and follow A6 chains.
主要なDNSサーバーソフトウェアパッケージの1つであるBIND9 [BIND]は、A6とAAAAの両方をサポートし、特定のバージョンのBIND9リゾルバーがA6レコードのクエリを実行し、A6チェーンを追跡するという点で、主要なDNSリゾルバー間で一意です。
According to published statistics for two root DNS servers (the "K" root server [KROOT] and the "L" root server [LROOT]), there are between 9,000 and 14,000 DNS queries per second on the "K" root server and between 13,000 to 19,000 queries per second on the "L" root server. The distributions of those queries by RR type are similar: roughly 60% A queries, 20~25% AAAA queries, and less than 1% A6 queries.
2つのルートDNSサーバー（「K」ルートサーバー[KROOT]と「L」ルートサーバー[LROOT]）の公開された統計によると、「K」ルートサーバーとその間のDNSクエリは1秒あたり9,000から14,000です。 「L」ルートサーバーで1秒あたり13,000〜19,000クエリ。 RRタイプによるこれらのクエリの分布は類似しています。Aクエリは約60％、AAAAクエリは20〜25％、A6クエリは1％未満です。
That there is A6 query traffic does not mean that A6 is actually in use; it is likely the result of some recursive servers that issue internally generated A6 queries when looking up missing name server addresses, in addition to issuing A and AAAA queries.
A6クエリトラフィックがあることは、A6が実際に使用されていることを意味しません。 AおよびAAAAクエリの発行に加えて、欠落しているネームサーバーアドレスを検索するときに、内部で生成されたA6クエリを発行する一部の再帰サーバーの結果である可能性があります。
BIND versions 9.0 through 9.2 could be configured to make A6 queries, and it is possible that some active name servers running those versions have not yet been upgraded.
BINDバージョン9.0〜9.2は、A6クエリを実行するように構成できます。これらのバージョンを実行しているアクティブなネームサーバーの一部がまだアップグレードされていない可能性があります。
In the late 1990s, A6 was considered to be the future in preference to AAAA [RFC2874]. As a result, A6 queries were tried by default in BINDv9 versions. When it was pointed out that A6 had some fundamental issues (discussed in [A6DISC] with the deprecation codified in RFC 3363), A6 was abandoned in favor of AAAA and BINDv9 no longer tried A6 records by default. A6 was removed from the query order in the BIND distribution in 2004 or 2005.
1990年代後半、A6はAAAA [RFC2874]よりも優先されると考えられていました。その結果、BINDv9バージョンではデフォルトでA6クエリが試行されました。 A6にいくつかの根本的な問題があると指摘されたとき（RFC 3363で成文化された非推奨については[A6DISC]で説明）、A6はAAAAに代わって放棄され、BINDv9はデフォルトでA6レコードを試行しなくなりました。 A6は、2004年または2005年にBINDディストリビューションのクエリ順序から削除されました。
Some Linux/glibc versions may have had A6 query implementations in gethostbyname() 8-10 years ago. These operating systems/libraries may not have been replaced or upgraded everywhere yet.
Linux / glibcの一部のバージョンでは、8〜10年前にgethostbyname()にA6クエリ実装があった可能性があります。これらのオペレーティングシステム/ライブラリは、まだどこでも交換またはアップグレードされていない可能性があります。
This document moves the A6 specification to Historic status. This move provides a clear signal to implementers and/or operators that A6 should NOT be implemented or deployed.
このドキュメントでは、A6仕様を歴史的ステータスに移行します。この動きは、A6を実装または展開すべきではないという明確なシグナルを実装者やオペレーターに提供します。
If A6 were in use and it were to be treated as an 'unknown record' (RFC3597) as discussed below, it might lead to some interoperability issues since resolvers that support A6 are required to do additional section processing for these records on the wire. However, as there are no known production uses of A6, the impact is considered negligible.
A6が使用されていて、以下で説明するように「不明なレコード」（RFC3597）として扱われる場合、A6をサポートするリゾルバーがこれらのレコードに対して追加のセクション処理を行う必要があるため、相互運用性の問題が発生する可能性があります。ただし、A6の既知の製造用途はないため、影響は無視できると考えられます。
Since there is no known A6-only client in production use, the transition phase may not be strictly necessary. However, clients that attempt to resolve A6 before AAAA will suffer a performance penalty. Therefore, we recommend that:
実稼働で使用される既知のA6専用クライアントがないため、移行フェーズは厳密には必要ない場合があります。ただし、AAAAの前にA6を解決しようとするクライアントは、パフォーマンスが低下します。したがって、次のことをお勧めします。
* A6 handling from all new or updated host stacks be removed;
* すべての新規または更新されたホストスタックからのA6処理が削除されました。
* All existing A6 records be removed; and,
* 既存のA6レコードはすべて削除されます。そして、
* All resolver and server implementations to return the same response as for any unknown or deprecated RR type for all A6 queries. If a AAAA record exists for the name being resolved, a suitable response would be 'no answers/no error', i.e., the response packet has an answer count of 0 but no error is indicated.
* すべてのA6クエリに対して不明または非推奨のRRタイプの場合と同じ応答を返すすべてのリゾルバーとサーバーの実装。解決される名前のAAAAレコードが存在する場合、適切な応答は「応答なし/エラーなし」です。つまり、応答パケットの応答カウントは0ですが、エラーは示されません。
Removing A6 records will eliminate any security exposure related to that RR type, and should introduce no new vulnerabilities.
A6レコードを削除すると、そのRRタイプに関連するセキュリティの危険性がなくなり、新しい脆弱性が生じることはありません。
IANA has updated the annotation of the A6 RR type (code 38) from "Experimental" to "Obsolete" in the DNS Parameters registry.
IANAは、DNSパラメーターレジストリのA6 RRタイプ（コード38）の注釈を「実験的」から「廃止」に更新しました。
The authors would like to thank Ralph Droms, Roy Arends, Edward Lewis, Andreas Gustafsson, Mark Andrews, Jun-ichiro "itojun" Hagino, and other members of DNS WGs for valuable contributions.
著者は、貴重な貢献をしてくれたRalph Droms、Roy Arends、Edward Lewis、Andreas Gustafsson、Mark Andrews、Jung-ichiro "itojun" Hagino、およびDNS WGの他のメンバーに感謝します。
[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月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V.、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、2003年10月。
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.
[RFC1886] Thomson、S.およびC. Huitema、「DNS Extensions to support IP version 6」、RFC 1886、1995年12月。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3363] Bush、R.、Durand、A.、Fink、B.、Gudmundsson、O.、T。Hain、「Representing Internet Protocol version 6（IPv6）Addresses in the Domain Name System（DNS）」、RFC 3363 、2002年8月。
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[RFC3364] Austein、R。、「インターネットプロトコルバージョン6（IPv6）のドメインネームシステム（DNS）サポートにおけるトレードオフ」、RFC 3364、2002年8月。
[A6DISC] Hagino, J., "Comparison of AAAA and A6 (do we really need A6?)", (Work In Progress), July 2001.
[A6DISC]萩野純一、「AAAAとA6の比較（本当にA6が必要なのか？）」（作業中）、2001年7月。
[BIND] "Internet Systems Consortium", http://www.isc.org/software/bind.
[バインド]「インターネットシステムコンソーシアム」、http：//www.isc.org/software/bind。
[KROOT] "RIPE Network Coordination Centre", http://k.root-servers.org/.
[KROOT]「RIPE Network Coordination Centre」、http：//k.root-servers.org/。
[LROOT] "ICANN DNS Operations", http://dns.icann.org/lroot/
Author's Addresses
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China EMail: jiangsheng@huawei.com
S横江hu Aはテクノロジー株式会社Q14、hu Aはキャンパスno.156です。i青道路H艾-Dイアン地区、北京100095 P.R.中国Eメール：Descend@Huawei.com
David Conrad Cloudflare, Inc. 665 3rd Street, Suite 207 San Francisco CA 94107 USA EMail: drc@cloudflare.com
David Conrad Cloudflare、Inc. 665 3rd Street、Suite 207 San Francisco CA 94107 USAメール：drc@cloudflare.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com
ブライアンカーペンターコンピューターサイエンス大学オークランド大学PB 92019オークランド、1142ニュージーランドメール：brian.e.carpenter@gmail.com