[要約] RFC 2874は、IPv6アドレスの集約と再番号付けをサポートするためのDNS拡張に関するものです。このRFCの目的は、IPv6ネットワークの管理を容易にするために、DNSを使用してアドレスの集約と再番号付けを行う方法を提案することです。
Network Working Group M. Crawford
Request for Comments: 2874 Fermilab
Category: Standards Track C. Huitema
Microsoft Corporation
July 2000
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
IPv6アドレスの集約と変更をサポートするDNS拡張機能
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing.
このドキュメントでは、ドメイン名システムへの変更を定義して、非バンバレ的で集計可能なIPv6アドレス指定をサポートします。変更には、追加のセクション処理の一部としてインターネットアドレスを返す既存のクエリタイプのネットワークの変更と更新された定義を迅速化する方法でIPv6アドレスを格納する新しいリソースレコードタイプが含まれます。
For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events.
IPv6アドレス（逆ルックアップと呼ばれることが多い）でキーキングされているルックアップの場合、このドキュメントは、アドレス空間（マルチホームプロバイダーまたはサイトの場合）およびネットワーク全体のイベントの並列コピーの修正なしでゾーンを使用できる新しいゾーン構造を定義します。。
Table of Contents
目次
1. Introduction ............................................... 2
2. Overview ................................................... 3
2.1. Name-to-Address Lookup ............................... 4
2.2. Underlying Mechanisms for Reverse Lookups ............ 4
2.2.1. Delegation on Arbitrary Boundaries ............. 4
2.2.2. Reusable Zones ................................. 5
3. Specifications ............................................. 5
3.1. The A6 Record Type ................................... 5
3.1.1. Format ......................................... 6
3.1.2. Processing ..................................... 6
3.1.3. Textual Representation ......................... 7
3.1.4. Name Resolution Procedure ...................... 7
3.2. Zone Structure for Reverse Lookups ................... 7
4. Modifications to Existing Query Types ...................... 8
5. Usage Illustrations ........................................ 8
5.1. A6 Record Chains ..................................... 9
5.1.1. Authoritative Data ............................. 9
5.1.2. Glue ........................................... 10
5.1.3. Variations ..................................... 12
5.2. Reverse Mapping Zones ................................ 13
5.2.1. The TLA level .................................. 13
5.2.2. The ISP level .................................. 13
5.2.3. The Site Level ................................. 13
5.3. Lookups .............................................. 14
5.4. Operational Note ..................................... 15
6. Transition from RFC 1886 and Deployment Notes .............. 15
6.1. Transition from AAAA and Coexistence with A Records .. 16
6.2. Transition from Nibble Labels to Binary Labels ....... 17
7. Security Considerations .................................... 17
8. IANA Considerations ........................................ 17
9. Acknowledgments ............................................ 18
10. References ................................................ 18
11. Authors' Addresses ........................................ 19
12. Full Copyright Statement .................................. 20
Maintenance of address information in the DNS is one of several obstacles which have prevented site and provider renumbering from being feasible in IP version 4. Arguments about the importance of network renumbering for the preservation of a stable routing system and for other purposes may be read in [RENUM1, RENUM2, RENUM3]. To support the storage of IPv6 addresses without impeding renumbering we define the following extensions.
アドレス情報のメンテナンスDNSのメンテナンスは、IPバージョン4で修正可能なサイトおよびプロバイダーが実行可能になることを妨げているいくつかの障害の1つです。[Renum1、Renum2、Renum3]。変更を妨げることなくIPv6アドレスの保存をサポートするために、次の拡張機能を定義します。
o A new resource record type, "A6", is defined to map a domain name to an IPv6 address, with a provision for indirection for leading "prefix" bits.
o 新しいリソースレコードタイプ「A6」は、ドメイン名をIPv6アドレスにマッピングするように定義されています。
o Existing queries that perform additional section processing to locate IPv4 addresses are redefined to do that processing for both IPv4 and IPv6 addresses.
o IPv4アドレスを見つけるために追加のセクション処理を実行する既存のクエリは、IPv4アドレスとIPv6アドレスの両方でその処理を行うように再定義されます。
o A new domain, IP6.ARPA, is defined to support lookups based on IPv6 address.
o 新しいドメインであるIP6.ARPAは、IPv6アドレスに基づいてルックアップをサポートするように定義されています。
o A new prefix-delegation method is defined, relying on new DNS features [BITLBL, DNAME].
o 新しいDNS機能[BITLBL、DNAME]に依存して、新しいプレフィックスディールメソッドが定義されています。
The changes are designed to be compatible with existing application programming interfaces. The existing support for IPv4 addresses is retained. Transition issues related to the coexistence of both IPv4 and IPv6 addresses in DNS are discussed in [TRANS].
変更は、既存のアプリケーションプログラミングインターフェイスと互換性があるように設計されています。IPv4アドレスの既存のサポートが保持されます。DNSのIPv4アドレスとIPv6アドレスの両方の共存に関連する遷移の問題については、[Trans]で説明します。
This memo proposes a replacement for the specification in RFC 1886 [AAAA] and a departure from current implementation practices. The changes are designed to facilitate network renumbering and multihoming. Domains employing the A6 record for IPv6 addresses can insert automatically-generated AAAA records in zone files to ease transition. It is expected that after a reasonable period, RFC 1886 will become Historic.
このメモは、RFC 1886 [AAAA]の仕様の代替品と現在の実装慣行からの逸脱を提案しています。変更は、ネットワークの変更とマルチホームを促進するように設計されています。IPv6アドレスにA6レコードを使用するドメインは、ゾーンファイルに自動化されたAAAAレコードを挿入して、移行を容易にすることができます。合理的な期間の後、RFC 1886が歴史的になると予想されます。
The next three major sections of this document are an overview of the facilities defined or employed by this specification, the specification itself, and examples of use.
このドキュメントの次の3つの主要なセクションは、この仕様、仕様自体、および使用例によって定義または採用されている施設の概要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KWORD]. The key word "SUGGESTED" signifies a strength between MAY and SHOULD: it is believed that compliance with the suggestion has tangible benefits in most instances.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[kword]で説明されていると解釈される。「提案された」キーワードは、5月とすべきであるとの間の強さを意味します。提案の順守は、ほとんどの場合に具体的な利点があると考えられています。
This section provides an overview of the DNS facilities for storage of IPv6 addresses and for lookups based on IPv6 address, including those defined here and elsewhere.
このセクションでは、IPv6アドレスの保管と、ここや他の場所で定義されているものを含むIPv6アドレスに基づくルックアップのためのDNS施設の概要を説明します。
IPv6 addresses are stored in one or more A6 resource records. A single A6 record may include a complete IPv6 address, or a contiguous portion of an address and information leading to one or more prefixes. Prefix information comprises a prefix length and a DNS name which is in turn the owner of one or more A6 records defining the prefix or prefixes which are needed to form one or more complete IPv6 addresses. When the prefix length is zero, no DNS name is present and all the leading bits of the address are significant. There may be multiple levels of indirection and the existence of multiple A6 records at any level multiplies the number of IPv6 addresses which are formed.
IPv6アドレスは、1つ以上のA6リソースレコードに保存されます。単一のA6レコードには、完全なIPv6アドレス、または1つ以上のプレフィックスにつながるアドレスと情報の連続した部分が含まれる場合があります。プレフィックス情報は、1つ以上の完全なIPv6アドレスを形成するために必要なプレフィックスまたはプレフィックスを定義する1つまたは複数のA6の所有者が次に記録されるプレフィックスの長さとDNS名で構成されています。プレフィックスの長さがゼロの場合、DNS名は存在せず、アドレスのすべての主要なビットが重要です。間接レベルには複数のレベルがあり、任意のレベルでの複数のA6レコードの存在は、形成されるIPv6アドレスの数を掛けています。
An application looking up an IPv6 address will generally cause the DNS resolver to access several A6 records, and multiple IPv6 addresses may be returned even if the queried name was the owner of only one A6 record. The authenticity of the returned address(es) cannot be directly verified by DNS Security [DNSSEC]. The A6 records which contributed to the address(es) may of course be verified if signed.
IPv6アドレスを検索するアプリケーションは、通常、DNSリゾルバーがいくつかのA6レコードにアクセスするようになり、クエリ名が1つのA6レコードの所有者であった場合でも、複数のIPv6アドレスが返される場合があります。返されたアドレス（ES）の信頼性は、DNSセキュリティ[DNSSEC]で直接検証することはできません。アドレスに貢献したA6レコードは、もちろん署名された場合に検証される場合があります。
Implementers are reminded of the necessity to limit the amount of work a resolver will perform in response to a client request. This principle MUST be extended to also limit the generation of DNS requests in response to one name-to-address (or address-to-name) lookup request.
実装者は、クライアントのリクエストに応じてリゾルバーが実行する作業の量を制限する必要性を思い出します。この原則は、1つの名前からアドレス（またはアドレスから名付け）ルックアップリクエストに応じて、DNSリクエストの生成を制限するために拡張する必要があります。
This section describes the new DNS features which this document exploits. This section is an overview, not a specification of those features. The reader is directed to the referenced documents for more details on each.
このセクションでは、このドキュメントが悪用する新しいDNS機能について説明します。このセクションは、これらの機能の仕様ではなく、概要です。読者は、それぞれの詳細については、参照されたドキュメントに向けられています。
This new scheme for reverse lookups relies on a new type of DNS label called the "bit-string label" [BITLBL]. This label compactly represents an arbitrary string of bits which is treated as a hierarchical sequence of one-bit domain labels. Resource records can thereby be stored at arbitrary bit-boundaries.
逆ルックアップのこの新しいスキームは、「ビットストリングラベル」[BITLBL]と呼ばれる新しいタイプのDNSラベルに依存しています。このラベルは、1ビットドメインラベルの階層シーケンスとして扱われる任意のビットのストリングをコンパクトに表しています。これにより、リソース記録は任意のビットバウンダリに保存できます。
Examples in section 5 will employ the following textual representation for bit-string labels, which is a subset of the syntax defined in [BITLBL]. A base indicator "x" for hexadecimal and a sequence of hexadecimal digits is enclosed between "\[" and "]". The bits denoted by the digits represent a sequence of one-bit domain labels ordered from most to least significant. (This is the opposite of the order they would appear if listed one bit at a time, but it appears to be a convenient notation.) The digit string may be followed by a slash ("/") and a decimal count. If omitted, the implicit count is equal to four times the number of hexadecimal digits.
セクション5の例では、[BITLBL]で定義された構文のサブセットであるビットストリングラベルの次のテキスト表現を採用しています。16進数のベースインジケーター「x」と16進数の桁のシーケンスは、「\ ["と「]」の間に囲まれています。数字で示されるビットは、最も重要なものから最も重要なものに注文された一連の1ビットドメインラベルを表します。（これは、一度に1つずつリストされている場合に表示される順序の反対ですが、便利な表記法のように見えます。）桁の文字列の後に、スラッシュ（ "/"）と小数カウントが続く場合があります。省略した場合、暗黙的なカウントは16進数の桁数の4倍に等しくなります。
Consecutive bit-string labels are equivalent (up to the limit imposed by the size of the bit count field) to a single bit-string label containing all the bits of the consecutive labels in the proper order. As an example, either of the following domain names could be used in a QCLASS=IN, QTYPE=PTR query to find the name of the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
連続したビットストリングラベルは、適切な順序で連続したラベルのすべてのビットを含む単一のビットストリングラベルに相当する（ビットカウントフィールドのサイズによって課される制限まで）同等です。例として、次のドメイン名のいずれかをqclass = in、qtype = ptr queryで使用して、IPv6アドレス3ffe：7c0：40：9：a00：20ff：fe81：2b32を使用してノードの名前を見つけます。
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
\ [x3ffe07c0004000090a0020fffe812b32/128] .ip6.arpa。
\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
\ [x0a0020fffe812b32/64]。\ [x0009/16]。\ [x3ffe07c00040/48] .ip6.arpa。
DNS address space delegation is implemented not by zone cuts and NS records, but by a new analogue to the CNAME record, called the DNAME resource record [DNAME]. The DNAME record provides alternate naming to an entire subtree of the domain name space, rather than to a single node. It causes some suffix of a queried name to be substituted with a name from the DNAME record's RDATA.
DNSアドレススペース委任は、ゾーンカットやNSレコードではなく、DNAMEリソースレコード[DNAME]と呼ばれるCNAMEレコードの新しいアナログによって実装されます。DNAMEレコードは、単一のノードではなく、ドメイン名スペースのサブツリー全体に代替命名を提供します。クエリの名前の接尾辞に、DNAMEレコードのRDATAの名前を置き換えます。
For example, a resolver or server providing recursion, while looking up a QNAME a.b.c.d.e.f may encounter a DNAME record
たとえば、QName A.B.C.D.E.Fを検索しながら再帰を提供するリゾルバーまたはサーバーがDNAMEレコードに遭遇する可能性があります
d.e.f. DNAME w.xy.
D.E.F.dname w.xy.
which will cause it to look for a.b.c.w.xy.
これにより、A.B.C.W.xyを探します。
The A6 record type is specific to the IN (Internet) class and has type number 38 (decimal).
A6レコードタイプはIN（インターネット）クラスに固有で、タイプ番号38（小数）があります。
The RDATA portion of the A6 record contains two or three fields.
A6レコードのRDATA部分には、2つまたは3つのフィールドが含まれています。
+-----------+------------------+-------------------+
|Prefix len.| Address suffix | Prefix name |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
o A prefix length, encoded as an eight-bit unsigned integer with value between 0 and 128 inclusive.
o 0〜128の包括的値の8ビットの符号なし整数としてエンコードされたプレフィックスの長さ。
o An IPv6 address suffix, encoded in network order (high-order octet first). There MUST be exactly enough octets in this field to contain a number of bits equal to 128 minus prefix length, with 0 to 7 leading pad bits to make this field an integral number of octets. Pad bits, if present, MUST be set to zero when loading a zone file and ignored (other than for SIG [DNSSEC] verification) on reception.
o ネットワークの順序でエンコードされたIPv6アドレスの接尾辞（最初に高次のオクテット）。このフィールドには、128マイナスのプレフィックスの長さに等しい多数のビットを含むのに十分なオクテットが必要であり、このフィールドを積分数のオクテットにするために0〜7のリーディングパッドビットがあります。ゾーンファイルをロードするときにパッドビットをゼロに設定する必要があり、レセプションで（SIG [DNSSEC]検証以外）無視する必要があります。
o The name of the prefix, encoded as a domain name. By the rules of [DNSIS], this name MUST NOT be compressed.
o ドメイン名としてエンコードされたプレフィックスの名前。[dnsis]のルールでは、この名前を圧縮してはなりません。
The domain name component SHALL NOT be present if the prefix length is zero. The address suffix component SHALL NOT be present if the prefix length is 128.
プレフィックスの長さがゼロの場合、ドメイン名コンポーネントは存在しません。接頭辞の長さが128の場合、アドレス接尾辞コンポーネントは存在しません。
It is SUGGESTED that an A6 record intended for use as a prefix for other A6 records have all the insignificant trailing bits in its address suffix field set to zero.
他のA6レコードのプレフィックスとして使用することを目的としたA6レコードには、アドレス接尾辞フィールドにゼロに設定されたすべての取るに足らないトレーリングビットがあることが示唆されています。
A query with QTYPE=A6 causes type A6 and type NS additional section processing for the prefix names, if any, in the RDATA field of the A6 records in the answer section. This processing SHOULD be recursively applied to the prefix names of A6 records included as additional data. When space in the reply packet is a limit, inclusion of additional A6 records takes priority over NS records.
QTYPE = A6を使用したクエリは、回答セクションのA6レコードのRDATAフィールドで、型A6とタイプNSの追加セクション処理を発生させます。この処理は、追加データとして含まれるA6レコードのプレフィックス名に再帰的に適用する必要があります。返信パケットのスペースが制限の場合、追加のA6レコードを含めると、NSレコードよりも優先されます。
It is an error for an A6 record with prefix length L1 > 0 to refer to a domain name which owns an A6 record with a prefix length L2 > L1. If such a situation is encountered by a resolver, the A6 record with the offending (larger) prefix length MUST be ignored. Robustness precludes signaling an error if addresses can still be formed from valid A6 records, but it is SUGGESTED that zone maintainers from time to time check all the A6 records their zones reference.
プレフィックス長> 0のA6レコードのエラーは、プレフィックス長l2> L1を持つA6レコードを所有するドメイン名を参照することです。このような状況がリゾルバーで遭遇した場合、問題のある（より大きな）接頭辞の長さを持つA6レコードは無視する必要があります。堅牢性は、有効なA6レコードからアドレスを形成できる場合、エラーをシグナル化することを妨げますが、ゾーンメンテナーはすべてのA6レコードの参照を時々チェックすることが示唆されています。
The textual representation of the RDATA portion of the A6 resource record in a zone file comprises two or three fields separated by whitespace.
ゾーンファイル内のA6リソースレコードのRDATA部分のテキスト表現は、Whitespaceで区切られた2つまたは3つのフィールドで構成されています。
o A prefix length, represented as a decimal number between 0 and 128 inclusive,
o 0〜128の包括的数字として表される接頭辞の長さ、
o the textual representation of an IPv6 address as defined in [AARCH] (although some leading and/or trailing bits may not be significant),
o [AARCH]で定義されているIPv6アドレスのテキスト表現（いくつかの主要なおよび/または後続のビットは重要ではないかもしれませんが）、
o a domain name, if the prefix length is not zero.
o プレフィックスの長さがゼロでない場合、ドメイン名。
The domain name MUST be absent if the prefix length is zero. The IPv6 address MAY be be absent if the prefix length is 128. A number of leading address bits equal to the prefix length SHOULD be zero, either implicitly (through the :: notation) or explicitly, as specified in section 3.1.1.
プレフィックスの長さがゼロの場合、ドメイン名はない必要があります。接頭辞の長さが128の場合、IPv6アドレスが存在しない場合があります。セクション3.1.1で指定されているように、プレフィックスの長さに等しい多くの先行アドレスビットはゼロ（::表記を介して）または明示的にゼロにする必要があります。
To obtain the IPv6 address or addresses which belong to a given name, a DNS client MUST obtain one or more complete chains of A6 records, each chain beginning with a record owned by the given name and including a record owned by the prefix name in that record, and so on recursively, ending with an A6 record with a prefix length of zero. One IPv6 address is formed from one such chain by taking the value of each bit position from the earliest A6 record in the chain which validly covers that position, as indicated by the prefix length. The set of all IPv6 addresses for the given name comprises the addresses formed from all complete chains of A6 records beginning at that name, discarding records which have invalid prefix lengths as defined in section 3.1.2.
特定の名前に属するIPv6アドレスまたはアドレスを取得するには、DNSクライアントはA6レコードの1つ以上の完全なチェーンを取得する必要があります。各チェーンは、特定の名前が所有するレコードから始まり、そのプレフィックス名が所有するレコードを含むレコードから始まります。再帰的にレコードなど、プレフィックスの長さがゼロのA6レコードで終了します。1つのIPv6アドレスは、プレフィックスの長さで示されるように、その位置を有効にカバーするチェーン内の初期のA6レコードから各ビット位置の値を取得することにより、そのようなチェーンの1つから形成されます。指定された名前のすべてのIPv6アドレスのセットは、その名前で始まるA6レコードのすべての完全なチェーンから形成されたアドレスで構成され、セクション3.1.2で定義されているように無効なプレフィックスの長さがあるレコードを破棄します。
If some A6 queries fail and others succeed, a client might obtain a non-empty but incomplete set of IPv6 addresses for a host. In many situations this may be acceptable. The completeness of a set of A6 records may always be determined by inspection.
一部のA6クエリが失敗し、他のクエリが成功した場合、クライアントはホストのIPv6アドレスの空白ではあるが不完全なセットを取得する場合があります。多くの状況では、これは受け入れられるかもしれません。A6レコードのセットの完全性は、常に検査によって決定される場合があります。
Very little of the new scheme's data actually appears under IP6.ARPA; only the first level of delegation needs to be under that domain. More levels of delegation could be placed under IP6.ARPA if some top-level delegations were done via NS records instead of DNAME records, but this would incur some cost in renumbering ease at the level of TLAs [AGGR]. Therefore, it is declared here that all address space delegations SHOULD be done by the DNAME mechanism rather than NS.
新しいスキームのデータは、実際にはIP6.ARPAの下に表示されません。代表団の最初のレベルのみがそのドメインの下にある必要があります。DNAMEレコードの代わりにNSレコードを介してトップレベルの代表団が行われた場合、IP6.ARPAの下には、より多くの委任を行うことができますが、TLAS [AGGR]のレベルでの容易さを数に変更するにはいくらかのコストがかかります。したがって、ここでは、すべてのアドレススペース代表団は、NSではなくDNAMEメカニズムによって行われるべきであると宣言されています。
In addition, since uniformity in deployment will simplify maintenance of address delegations, it is SUGGESTED that address and prefix information be stored immediately below a DNS label "IP6". Stated another way, conformance with this suggestion would mean that "IP6" is the first label in the RDATA field of DNAME records which support IPv6 reverse lookups.
さらに、展開の均一性はアドレス代表団のメンテナンスを簡素化するため、アドレスとプレフィックス情報をDNSラベル「IP6」のすぐ下に保存することが提案されています。別の方法で、この提案に準拠することは、「IP6」がIPv6リバースルックアップをサポートするDNAMEレコードのRDATAフィールドの最初のラベルであることを意味します。
When any "reserved" or "must be zero" bits are adjacent to a delegation boundary, the higher-level entity MUST retain those bits in its own control and delegate only the bits over which the lower-level entity has authority.
「予約済み」または「ゼロ」ビットが委任境界に隣接する場合、高レベルのエンティティはそれらのビットを独自の制御に保持し、低レベルのエンティティが権限を持っているビットのみを委任する必要があります。
To find the name of a node given its IPv6 address, a DNS client MUST perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the 128 bit address as one or more bit-string labels [BITLBL], followed by the two standard labels "IP6.ARPA". If recursive service was not obtained from a server and the desired PTR record was not returned, the resolver MUST handle returned DNAME records as specified in [DNAME], and NS records as specified in [DNSCF], and iterate.
IPv6アドレスを指定したノードの名前を見つけるには、DNSクライアントは、qclass = in、qtype = ptrを使用してクエリを実行する必要があります。2つの標準ラベル「IP6.ARPA」。再帰サービスがサーバーから取得されず、目的のPTRレコードが返されなかった場合、Resolverは[DNAME]で指定されているように返されたDNAMEレコードを処理し、[DNSCF]で指定されているNSレコードを処理する必要があります。
All existing query types that perform type A additional section processing, i.e. the name server (NS), mail exchange (MX), and mailbox (MB) query types, and the experimental AFS data base (AFSDB) and route through (RT) types, must be redefined to perform type A, A6 and AAAA additional section processing, with type A having the highest priority for inclusion and type AAAA the lowest. This redefinition means that a name server may add any relevant IPv4 and IPv6 address information available locally to the additional section of a response when processing any one of the above queries. The recursive inclusion of A6 records referenced by A6 records already included in the additional section is OPTIONAL.
タイプAの追加セクション処理、つまり名前サーバー（NS）、メールエクスチェンジ（MX）、およびメールボックス（MB）クエリタイプ、および実験AFSデータベース（AFSDB）とルート（RT）タイプを実行するすべての既存のクエリタイプ、タイプA、A6、およびAAAAの追加セクション処理を実行するには再定義する必要があります。タイプAは、包含とタイプAAAの最優先度が最も低いです。この再定義は、名前サーバーが、上記のクエリのいずれかを処理するときに、応答の追加セクションでローカルに利用可能な関連するIPv4およびIPv6アドレス情報を追加することを意味します。追加セクションに既に含まれているA6レコードが参照するA6レコードを再帰的に含めることはオプションです。
This section provides examples of use of the mechanisms defined in the previous section. All addresses and domains mentioned here are intended to be fictitious and for illustrative purposes only. Example delegations will be on 4-bit boundaries solely for readability; this specification is indifferent to bit alignment.
このセクションでは、前のセクションで定義されたメカニズムの使用例を示します。ここで説明するすべてのアドレスとドメインは、架空の目的でのみ架空のものであることを目的としています。代表団の例は、読みやすさのためだけに4ビットの境界にあります。この仕様は、ビットアラインメントに無関心です。
Use of the IPv6 aggregatable address format [AGGR] is assumed in the examples.
IPv6 Aggregatableアドレス形式[AGGR]の使用は、例で想定されています。
Let's take the example of a site X that is multi-homed to two "intermediate" providers A and B. The provider A is itself multi-homed to two "transit" providers, C and D. The provider B gets its transit service from a single provider, E. For simplicity suppose that C, D and E all belong to the same top-level aggregate (TLA) with identifier (including format prefix) '2345', and the TLA authority at ALPHA-TLA.ORG assigns to C, D and E respectively the next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and 2345:000E::/32.
2つの「中間」プロバイダーAとBにマルチホームされたサイトXの例を見てみましょう。プロバイダーAは2つの「トランジット」プロバイダー、CとDにマルチホームされています。プロバイダーBは、トランジットサービスを取得します。単一のプロバイダー、E。簡単にするために、c、d、およびeがすべて識別子（フォーマットプレフィックスを含む） '2345'を含む同じトップレベル集約（TLA）に属し、alpha-tla.orgのTLA当局がC、D、およびE次のレベル集約（NLA）プレフィックス2345：00C0 ::/28、2345：00D0 ::/28および2345：000E ::/32。
C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to B.
c NLAプレフィックス2345：00C1：CA00 ::/40をAに割り当て、Dはプレフィックス2345：00D2：00D2：DA00 ::/40をAに割り当て、Eは2345：000E：EB00 ::/40にB.
A assigns to X the subscriber identification '11' and B assigns the subscriber identification '22'. As a result, the site X inherits three address prefixes:
aはxにサブスクライバー識別 '11'を割り当て、bはサブスクライバー識別 '22'を割り当てます。その結果、サイトXは3つのアドレスプレフィックスを継承します。
o 2345:00C1:CA11::/48 from A, for routes through C. o 2345:00D2:DA11::/48 from A, for routes through D. o 2345:000E:EB22::/48 from B, for routes through E.
o 2345：00C1：CA11 ::/48 Aから、C。O 2345：00D2：00D2：DA11 ::/48からAから、D。O 2345：000E：EB22 ::/48、ルートの場合は、bからeb22 ::/48E.を通して
Let us suppose that N is a node in the site X, that it is assigned to subnet number 1 in this site, and that it uses the interface identifier '1234:5678:9ABC:DEF0'. In our configuration, this node will have three addresses:
nはサイトXのノードであり、このサイトのサブネット番号1に割り当てられ、インターフェイス識別子 '1234：5678：9ABC：def0'を使用すると仮定します。構成では、このノードには3つのアドレスがあります。
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
We will assume that the site X is represented in the DNS by the domain name X.EXAMPLE, while A, B, C, D and E are represented by A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we assume a subdomain "IP6" that will hold the corresponding prefixes. The node N is identified by the domain name N.X.EXAMPLE. The following records would then appear in X's DNS.
サイトxはドメイン名x.exampleでDNSで表され、a、b、c、d、およびeはa.net、b.net、c.net、d.net、eで表されると仮定します。。ネット。これらの各ドメインでは、対応するプレフィックスを保持するサブドメイン「IP6」を想定しています。ノードnは、ドメイン名n.x.exampleで識別されます。次のレコードがXのDNSに表示されます。
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
And elsewhere there would appear
そして他の場所に現れるでしょう
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
subscriber-x.ip6.a.net。a6 40 0：0：0011 :: a.net.ip6.c.net。subscriber-x.ip6.a.net。A6 40 0：0：0011 :: A.NET.IP6.D.NET。
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
subscriber-x.ip6.b.net。a6 40 0：0：0022 :: b-net.ip6.e.net。
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
a.net.ip6.c.net。A6 28 0：0001：CA00 :: C.NET.ALPHA-TLA.ORG。
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
a.net.ip6.d.net。a6 28 0：0002：da00 :: d.net.alpha-tla.org。
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
b-net.ip6.e.net。A6 32 0：0：EB00 :: E.NET.ALPHA-TLA.ORG。
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
c.net.alpha-tla.org。A6 0 2345：00C0 :: D.NET.ALPHA-TLA.ORG。A6 0 2345：00D0 :: E.NET.ALPHA-TLA.ORG。a6 0 2345：000e ::
When, as is common, some or all DNS servers for X.EXAMPLE are within the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry enough "glue" information to enable DNS clients to reach those nameservers. This is true in IPv6 just as in IPv4. However, the A6 record affords the DNS administrator some choices. The glue could be any of
一般的に、x.exampleの一部またはすべてのDNSサーバーがx.exampleゾーン自体内にある場合、トップレベルゾーンの例は、DNSクライアントがそれらの名前サーバーに到達できるようにするために十分な「接着剤」情報を運ぶ必要があります。これは、IPv4と同様にIPv6で当てはまります。ただし、A6レコードはDNS管理者にいくつかの選択肢を提供します。接着剤はいずれかです
o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
o x.exampleゾーンから複製されたA6レコードの最小セット、
o a (possibly smaller) set of records which collapse the structure of that minimal set,
o その最小セットの構造を崩壊させるレコードのセット（おそらく小さい）セット、
o or a set of A6 records with prefix length zero, giving the entire global addresses of the servers.
o または、プレフィックスの長さゼロを備えたA6レコードのセットで、サーバーのグローバルアドレス全体を提供します。
The trade-off is ease of maintenance against robustness. The best and worst of both may be had together by implementing either the first or second option together with the third. To illustrate the glue options, suppose that X.EXAMPLE is served by two nameservers NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. Then the top-level zone EXAMPLE would include one (or more) of the following sets of A6 records as glue.
トレードオフは、堅牢性に対するメンテナンスの容易さです。両方の最良と最悪は、最初のオプションまたは2番目のオプションを3番目のオプションと一緒に実装することにより、一緒に持つことができます。接着剤のオプションを説明するために、x.exampleに2つの名前のns1.x.exampleとns2.x.exampleによって提供されていると仮定します。それぞれサブネット1と2。次に、トップレベルのゾーンの例には、接着剤としてのA6レコードの次のセットの1つ（またはそれ以上）が含まれます。
$ORIGIN EXAMPLE. ; first option
X NS NS1.X
NS NS2.X
NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN EXAMPLE. ; second option
X NS NS1.X
NS NS2.X
NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
$ORIGIN EXAMPLE. ; third option
X NS NS1.X
NS NS2.X
NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
A6 0 2345:00D2:DA11:1:1:11:111:1111
A6 0 2345:000E:EB22:1:1:11:111:1111
NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
A6 0 2345:00D2:DA11:2:2:22:222:2222
A6 0 2345:000E:EB22:2:2:22:222:2222
The first and second glue options are robust against renumbering of X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if those providers' own DNS is unreachable. The glue records of the third option are robust against DNS failures elsewhere than the zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's address space is renumbered.
1番目と2番目の接着剤オプションは、プロバイダーA.NETおよびB.NETによるX.exampleのプレフィックスの名前を変更することに対して堅牢ですが、これらのプロバイダー自身のDNSが到達できない場合は失敗します。3番目のオプションの接着剤レコードは、ゾーンの例やXの例よりも他の場所のDNS障害に対して堅牢ですが、Xのアドレススペースが変更されたときに更新する必要があります。
If the EXAMPLE zone includes redundant glue, for instance the union of the A6 records of the first and third options, then under normal circumstances duplicate IPv6 addresses will be derived by DNS clients. But if provider DNS fails, addresses will still be obtained from the zero-prefix-length records, while if the EXAMPLE zone lags behind a renumbering of X.EXAMPLE, half of the addresses obtained by DNS clients will still be up-to-date.
例のゾーンに冗長な接着剤が含まれている場合、たとえば最初と3番目のオプションのA6レコードの結合が含まれている場合、通常の状況では、DNSクライアントによって複製されたIPv6アドレスが導出されます。ただし、プロバイダーDNSが失敗した場合、アドレスはゼロプレフィックスの長さのレコードから引き続き取得されますが、例のゾーンがXの名前を変更するのに遅れをとっている場合、DNSクライアントが取得したアドレスの半分は引き続き最新です。
The zero-prefix-length glue records can of course be automatically generated and/or checked in practice.
もちろん、ゼロプレフィックスの長さの接着剤レコードは、自動的に生成および/または実際にチェックされます。
Several more-or-less arbitrary assumptions are reflected in the above structure. All of the following choices could have been made differently, according to someone's notion of convenience or an agreement between two parties.
上記の構造には、多かれ少なかれarbitrary意的な仮定が反映されています。誰かの利便性または2つの当事者間の合意に従って、以下の選択はすべて異なる方法で行われた可能性があります。
First, that site X has chosen to put subnet information in a separate A6 record rather than incorporate it into each node's A6 records.
まず、そのサイトXは、各ノードのA6レコードに組み込むのではなく、サブネット情報を別のA6レコードに配置することを選択しました。
Second, that site X is referred to as "SUBSCRIBER-X" by both of its providers A and B.
第二に、そのサイトXは、プロバイダーAとBの両方から「サブスクライバーX」と呼ばれます。
Third, that site X chose to indirect its provider information through A6 records at IP6.X.EXAMPLE containing no significant bits. An alternative would have been to replicate each subnet record for each provider.
第三に、そのサイトXは、有意なビットが含まれていないIP6.x.exampleでのA6レコードを通じてプロバイダー情報を間接的にすることを選択しました。別の方法は、各プロバイダーの各サブネットレコードを複製することでした。
Fourth, B and E used a slightly different prefix naming convention between themselves than did A, C and D. Each hierarchical pair of network entities must arrange this naming between themselves.
第4に、BとEは、A、C、Dと比較して、自分自身の間でわずかに異なるプレフィックスの命名規則を使用しました。各ネットワークエンティティの各階層ペアは、自分自身の間でこの命名を整理する必要があります。
Fifth, that the upward prefix referral chain topped out at ALPHA-TLA.ORG. There could have been another level which assigned the TLA values and holds A6 records containing those bits.
5番目、Alpha-Tla.orgで上向きのプレフィックス参照チェーンがトップになったこと。TLA値を割り当て、それらのビットを含むA6レコードを保持する別のレベルがあった可能性があります。
Finally, the above structure reflects an assumption that address fields assigned by a given entity are recorded only in A6 records held by that entity. Those bits could be entered into A6 records in the lower-level entity's zone instead, thus:
最後に、上記の構造は、特定のエンティティによって割り当てられたアドレスフィールドが、そのエンティティが保持しているA6レコードにのみ記録されるという仮定を反映しています。これらのビットは、代わりに、低レベルのエンティティゾーンのA6レコードに入力できます。
IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
IP6.x.example。a6 40 0：0：11 :: ip6.a.net。IP6.x.example。a6 40 0：0：22 :: ip6.b.net。
IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. and so on.
IP6.A.NET。A6 28 0：1：CA00 :: IP6.C.NET。等々。
Or the higher-level entities could hold both sorts of A6 records (with different DNS owner names) and allow the lower-level entities to choose either mode of A6 chaining. But the general principle of avoiding data duplication suggests that the proper place to store assigned values is with the entity that assigned them.
または、高レベルのエンティティは、両方の種類のA6レコード（異なるDNS所有者名を持つ）を保持し、低レベルのエンティティがA6チェーンのいずれかのモードを選択できるようにすることができます。しかし、データの複製を回避するという一般原則は、割り当てられた値を保存する適切な場所は、それらを割り当てたエンティティにあることを示唆しています。
It is possible, but not necessarily recommended, for a zone maintainer to forego the renumbering support afforded by the chaining of A6 records and to record entire IPv6 addresses within one zone file.
ゾーンメンテナーがA6レコードのチェーンによって提供される変更サポートを控え、1つのゾーンファイル内にIPv6アドレス全体を記録することは可能ですが、必ずしも推奨されるわけではありません。
Supposing that address space assignments in the TLAs with Format Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then the IP6.ARPA zone would include
フォーマットプレフィックス（001）バイナリおよびIDS 0345、0678、および09ABを使用してTLASのアドレススペース割り当てを仮定すると、Alpha-Tla.org、Bravo-Tla.org、Charlie-Tla.xy、次にIP6.Arpaゾーンには含まれます
$ORIGIN IP6.ARPA. \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
$ origin ip6.arpa。\ [x234500/24] dname ip6.alpha-tla.org。\ [x267800/24] dname ip6.bravo-tla.org。\ [x29ab00/24] dname ip6.charlie-tla.xy。
Eight trailing zero bits have been included in each TLA ID to reflect the eight reserved bits in the current aggregatable global unicast addresses format [AGGR].
現在の集計可能なグローバルユニキャストアドレス形式[AGGR]の8つの予約されたビットを反映するために、各TLA IDに8つの後続のビットが含まれています。
ALPHA-TLA's assignments to network providers C, D and E are reflected in the reverse data as follows.
Alpha-TLAのネットワークプロバイダーC、D、およびEへの割り当ては、次のように逆データに反映されます。
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
\ [xc/4] .ip6.alpha-tla.org。dname ip6.c.net。\ [xd/4] .ip6.alpha-tla.org。dname ip6.d.net。\ [x0e/8] .ip6.alpha-tla.org。dname ip6.e.net。
The providers A through E carry the following delegation information in their zone files.
プロバイダーAからEは、ゾーンファイルに次の委任情報を携帯しています。
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
\ [x1ca/12] .ip6.c.net。dname ip6.a.net。\ [x2da/12] .ip6.d.net。dname ip6.a.net。\ [xeb/8] .ip6.e.net。dname ip6.b.net。\ [x11/8] .ip6.a.net。dname ip6.x.example。\ [x22/8] .ip6.b.net。dname ip6.x.example。
Note that some domain names appear in the RDATA of more than one DNAME record. In those cases, one zone is being used to map multiple prefixes.
いくつかのドメイン名は、複数のDNAMEレコードのRDATAに表示されることに注意してください。そのような場合、複数のプレフィックスをマッピングするために1つのゾーンが使用されています。
Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-name translations. This domain is now referenced by two different DNAME records held by two different providers.
アドレス間翻訳については、IP6.x.exampleを使用して顧客x.exampleを検討してください。このドメインは、2つの異なるプロバイダーが保有する2つの異なるDNAMEレコードによって参照されています。
$ORIGIN IP6.X.EXAMPLE. \[x0001/16] DNAME SUBNET-1 \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. and so on.
$ origin ip6.x.example。\ [x0001/16] dname subnet-1 \ [x123456789abcdef0] .subnet-1 ptr n.x.example。等々。
SUBNET-1 need not have been named in a DNAME record; the subnet bits could have been joined with the interface identifier. But if subnets are treated alike in both the A6 records and in the reverse zone, it will always be possible to keep the forward and reverse definition data for each prefix in one zone.
Subnet-1は、DNAMEレコードで名前が付けられている必要はありません。サブネットビットは、インターフェイス識別子と結合されている可能性があります。ただし、サブネットがA6レコードとリバースゾーンの両方で同様に扱われている場合、1つのゾーンの各プレフィックスのフォワードおよびリバースの定義データを常に維持することが常に可能になります。
A DNS resolver looking for a hostname for the address 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the DNAME records shown above and would form new queries. Assuming that it began the process knowing servers for IP6.ARPA, but that no server it consulted provided recursion and none had other useful additional information cached, the sequence of queried names and responses would be (all with QCLASS=IN, QTYPE=PTR):
アドレス2345：00C1：00C1：0001：0001：0001：5678：9ABC：def0のホスト名を探しているDNSリゾルバーは、上記のDNAMEレコードの特定を取得し、新しいクエリを形成します。IP6.ARPAのサーバーを知っているプロセスを開始したが、それが相談したサーバーが再帰を提供し、他の有用な追加情報がキャッシュされていないと仮定すると、クエリの名前と応答のシーケンスは（すべてQClass = in、qtype = ptrを使用）：
To a server for IP6.ARPA: QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
ip6.arpaのサーバーへ：qname = \ [x234500c1ca1100100123456789abcdef0/128] .ip6.arpa。
Answer: \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
回答：\ [x234500/24] .ip6.arpa。dname ip6.alpha-tla.org。
To a server for IP6.ALPHA-TLA.ORG: QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
ip6.alpha-tla.orgのサーバーへ：qname = \ [xc1ca1100123456789abcdef0/104] .ip6.alpha-tla.org。
Answer: \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
回答：\ [xc/4] .ip6.alpha-tla.org。dname ip6.c.net。
To a server for IP6.C.NET.: QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
ip6.c.net。のサーバーへ：qname = \ [x1ca110001123456789abcdef0/100] .ip6.c.net。
Answer: \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
回答：\ [x1ca/12] .ip6.c.net。dname ip6.a.net。
To a server for IP6.A.NET.: QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
ip6.a.net。：qname = \ [x11000101123456789abcdef0/88] .ip6.a.netのサーバーへ。
Answer: \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
回答：\ [x11/8] .ip6.a.net。dname ip6.x.example。
To a server for IP6.X.EXAMPLE.: QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
ip6.x.exampleのサーバーへ：qname = \ [x0001123456789abcdef0/80] .ip6.x.example。
Answer: \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
回答：\ [x0001/16] .ip6.x.example。dname subnet-1.ip6.x.example。\ [x123456789ABCDEF0/64] .SUBNET-1.X.EXAMPLE。ptr n.x.example。
All the DNAME (and NS) records acquired along the way can be cached to expedite resolution of addresses topologically near to this address. And if another global address of N.X.EXAMPLE were resolved within the TTL of the final PTR record, that record would not have to be fetched again.
途中で取得したすべてのDNAME（およびNS）レコードは、このアドレスに近い住所の解決を促進するためにキャッシュされます。また、N.X.exampleの別のグローバルアドレスが最終PTRレコードのTTL内で解決された場合、そのレコードを再び取得する必要はありません。
In the illustrations in section 5.1, hierarchically adjacent entities, such as a network provider and a customer, must agree on a DNS name which will own the definition of the delegated prefix(es). One simple convention would be to use a bit-string label representing exactly the bits which are assigned to the lower-level entity by the higher. For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]". This would place the A6 record(s) defining the delegated prefix at exactly the same point in the DNS tree as the DNAME record associated with that delegation. The cost of this simplification is that the lower-level zone must update its upward-pointing A6 records when it is renumbered. This cost may be found quite acceptable in practice.
セクション5.1の図では、ネットワークプロバイダーや顧客などの階層的に隣接するエンティティは、委任されたプレフィックス（ES）の定義を所有するDNS名に同意する必要があります。簡単な規則の1つは、より高いレベルのエンティティに割り当てられたビットを正確に表すビットストリングラベルを使用することです。たとえば、「サブスクライバー-X」は「\ [x11/8]」に置き換えることができます。これにより、A6レコードは、その代表団に関連付けられたDNAMEレコードとまったく同じポイントで委任されたプレフィックスを定義します。この単純化のコストは、下位レベルゾーンが上向きの上向きのA6レコードを変更されたときに更新する必要があることです。このコストは、実際には非常に受け入れられる可能性があります。
When prefixes have been "delegated upward" with A6 records, the number of DNS resource records required to establish a single IPv6 address increases by some non-trivial factor. Those records will typically, but not necessarily, come from different DNS zones (which can independently suffer failures for all the usual reasons). When obtaining multiple IPv6 addresses together, this increase in RR count will be proportionally less -- and the total size of a DNS reply might even decrease -- if the addresses are topologically clustered. But the records could still easily exceed the space available in a UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or SRV query, for example. The possibilities for overall degradation of performance and reliability of DNS lookups are numerous, and increase with the number of prefix delegations involved, especially when those delegations point to records in other zones.
接頭辞がA6レコードを使用して「上方に委任された」と、単一のIPv6アドレスを確立するために必要なDNSリソースレコードの数が、何らかの非自明の要因によって増加します。これらのレコードは通常、必ずしもではありませんが、異なるDNSゾーンから生まれます（通常のすべての理由で独立して失敗を被る可能性があります）。複数のIPv6アドレスを一緒に取得すると、このRRカウントの増加は比例して小さくなり、DNS応答の合計サイズは、アドレスがトポロジカルにクラスター化されている場合さえ減少する可能性があります。しかし、レコードは、たとえば、大きなRRSet [DNSClar]をMX、NS、またはSRVクエリに戻すUDP応答で利用可能なスペースを簡単に超える可能性があります。DNSルックアップのパフォーマンスと信頼性の全体的な劣化の可能性は多数あり、特にそれらの代表団が他のゾーンの記録を指している場合、関係する接頭辞委任の数とともに増加します。
DNS Security [DNSSEC] addresses the trustworthiness of cached data, which is a problem intrinsic to DNS, but the cost of applying this to an IPv6 address is multiplied by a factor which may be greater than the number of prefix delegations involved if different signature chains must be verified for different A6 records. If a trusted centralized caching server (as in [TSIG], for example) is used, this cost might be amortized to acceptable levels. One new phenomenon is the possibility that IPv6 addresses may be formed from a A6 records from a combination of secure and unsecured zones.
DNSセキュリティ[DNSSEC]は、DNSに固有の問題であるキャッシュデータの信頼性に対処しますが、これをIPv6アドレスに適用するコストには、異なる署名チェーンの場合に関与するプレフィックス委任の数よりも大きい場合の因子を掛けます。さまざまなA6レコードについて検証する必要があります。信頼できる集中キャッシュサーバー（[TSIG]など）が使用される場合、このコストは許容レベルに償却される可能性があります。1つの新しい現象は、IPv6アドレスが安全なゾーンと無担保ゾーンの組み合わせからA6レコードから形成される可能性があることです。
Until more deployment experience is gained with the A6 record, it is recommended that prefix delegations be limited to one or two levels. A reasonable phasing-in mechanism would be to start with no prefix delegations (all A6 records having prefix length 0) and then to move to the use of a single level of delegation within a single zone. (If the TTL of the "prefix" A6 records is kept to an appropriate duration the capability for rapid renumbering is not lost.) More aggressively flexible delegation could be introduced for a subset of hosts for experimentation.
A6レコードでさらに展開エクスペリエンスが得られるまで、プレフィックス委任を1つまたは2つのレベルに制限することをお勧めします。合理的なフェージングインメカニズムは、プレフィックス代表団（すべてのA6レコードをプレフィックス長0）から開始し、単一のゾーン内で単一レベルの委任を使用することになることです。（「プレフィックス」A6レコードのTTLが適切な期間に維持されている場合、迅速な変更の機能は失われません。）実験用のホストのサブセットに対して、より積極的に柔軟な代表団を導入できます。
Administrators of zones which contain A6 records can easily accommodate deployed resolvers which understand AAAA records but not A6 records. Such administrators can do automatic generation of AAAA records for all of a zone's names which own A6 records by a process which mimics the resolution of a hostname to an IPv6 address (see section 3.1.4). Attention must be paid to the TTL assigned to a generated AAAA record, which MUST be no more than the minimum of the TTLs of the A6 records that were used to form the IPv6 address in that record. For full robustness, those A6 records which were in different zones should be monitored for changes (in TTL or RDATA) even when there are no changes to zone for which AAAA records are being generated. If the zone is secure [DNSSEC], the generated AAAA records MUST be signed along with the rest of the zone data.
A6レコードを含むゾーンの管理者は、A6レコードではなくAAAAレコードを理解する展開されたリゾルバーに簡単に対応できます。このような管理者は、IPv6アドレスに対するホスト名の解像度を模倣するプロセスによってA6レコードを所有するすべてのゾーンの名前のAAAAレコードの自動生成を行うことができます（セクション3.1.4を参照）。生成されたAAAAレコードに割り当てられたTTLに注意を払う必要があります。これは、そのレコードのIPv6アドレスを形成するために使用されたA6レコードのTTLの最小値にすぎません。完全な堅牢性のために、異なるゾーンにあったA6レコードは、AAAAレコードが生成されているゾーンに変更がない場合でも、変更を（TTLまたはRDATAで）監視する必要があります。ゾーンが安全である場合、生成されたAAAAレコードは、残りのゾーンデータとともに署名する必要があります。
A zone-specific heuristic MAY be used to avoid generation of AAAA records for A6 records which record prefixes, although such superfluous records would be relatively few in number and harmless. Examples of such heuristics include omitting A6 records with a prefix length less than the largest value found in the zone file, or records with an address suffix field with a certain number of trailing zero bits.
ゾーン固有のヒューリスティックを使用して、プレフィックスを記録するA6レコードのAAAAレコードの生成を回避するために使用できますが、このような余分なレコードは比較的少数で無害です。このようなヒューリスティックの例には、ゾーンファイルに見られる最大値よりも少ない接頭辞の長さのA6レコードを省略すること、または一定数のトレーリングゼロビットを持つアドレス接尾辞フィールドのレコードが含まれます。
On the client side, when looking up and IPv6 address, the order of A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA; AAAA, then A6; A6 only; or both in parallel. The default order (or only order, if not configurable) MUST be to try A6 first, then AAAA. If and when the AAAA becomes deprecated a new document will change the default.
クライアント側では、見上げるとIPv6アドレスの場合、A6およびAAAAクエリの順序は、A6、AAAAのいずれかになるように構成可能である可能性があります。aaaa、a6;A6のみ;または両方の並列。デフォルトの注文（または構成可能ではないにしても、注文のみ）は、最初にA6を試してからAAAAを試す必要があります。AAAAが非推奨になった場合、新しいドキュメントがデフォルトを変更します。
The guidelines and options for precedence between IPv4 and IPv6 addresses are specified in [TRANS]. All mentions of AAAA records in that document are henceforth to be interpreted as meaning A6 and/or AAAA records in the order specified in the previous paragraph.
IPv4アドレスとIPv6アドレスの間の優先順位のガイドラインとオプションは、[Trans]で指定されています。その文書におけるAAAA記録のすべての言及は、以前の段落で指定された順序でA6および/またはAAAA記録を意味すると解釈されると解釈されることです。
Implementations conforming to RFC 1886 [AAAA] perform reverse lookups as follows:
RFC 1886 [AAAA]に適合する実装は、次のように逆ルックアップを実行します。
An IPv6 address is represented as a name in the IP6.INT domain by a sequence of nibbles separated by dots with the suffix ".IP6.INT". The sequence of nibbles is encoded in reverse order, i.e. the low-order nibble is encoded first, followed by the next low-order nibble and so on. Each nibble is represented by a hexadecimal digit. For example, a name for the address 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section 5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.- 8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
IPv6アドレスは、接尾辞 ".ip6.int"でドットで分離された一連のニブルによってIP6.intドメインの名前として表されます。ニブルのシーケンスは逆の順序でエンコードされます。つまり、低次のニブルが最初にエンコードされ、次に次の低次のニブルなどがエンコードされます。各ナブルは、16進数桁で表されます。たとえば、アドレスの名前2345：00C1：CA11：0001：1234：5678：9ABC：9ABC：DEF0は、DNS名「0.F.E.D.C.B.A.9.- 8.7.6.5.4.4.3.2.11」で求められます。.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int。 "
Implementations conforming to this specification will perform a lookup of a binary label in IP6.ARPA as specified in Section 3.2. It is RECOMMENDED that for a transition period implementations first lookup the binary label in IP6.ARPA and if this fails try to lookup the 'nibble' label in IP6.INT.
この仕様に準拠した実装は、セクション3.2で指定されているように、IP6.ARPAのバイナリラベルのルックアップを実行します。遷移期間実装の場合、最初にIP6.ARPAのバイナリラベルを検索し、IP6.intの「ニブル」ラベルを検索しようとすることをお勧めします。
The signing authority [DNSSEC] for the A6 records which determine an IPv6 address is distributed among several entities, reflecting the delegation path of the address space which that address occupies. DNS Security is fully applicable to bit-string labels and DNAME records. And just as in IPv4, verification of name-to-address mappings is logically independent of verification of address-to-name mappings.
IPv6アドレスを決定するA6レコードの署名機関[DNSSEC]は、いくつかのエンティティに配布され、アドレスが占有するアドレス空間の委任パスを反映しています。DNSセキュリティは、ビットストリングラベルとDNAMEレコードに完全に適用できます。また、IPv4と同様に、名前からアドレスへのマッピングの検証は、アドレス間マッピングの検証と論理的に依存しています。
With or without DNSSEC, the incomplete but non-empty address set scenario of section 3.1.4 could be caused by selective interference with DNS lookups. If in some situation this would be more harmful than complete DNS failure, it might be mitigated on the client side by refusing to act on an incomplete set, or on the server side by listing all addresses in A6 records with prefix length 0.
DNSSECの有無にかかわらず、セクション3.1.4の不完全ではあるが空でないアドレスセットシナリオは、DNS検索との選択的干渉によって引き起こされる可能性があります。ある状況で、これが完全なDNS障害よりも有害である場合、不完全なセットでの行動を拒否することにより、またはA6レコードのすべてのアドレスをプレフィックス長0のA6レコードのすべてのアドレスをリストすることにより、クライアント側で軽減される可能性があります。
The A6 resource record has been assigned a Type value of 38.
A6リソースレコードには、38のタイプ値が割り当てられています。
The authors would like to thank the following persons for valuable discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden, Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
著者は、価値のある議論とレビューについて次の人に感謝したいと思います：マーク・アンドリュース、ロブ・オーストイン、ジム・バウンド、ランディ・ブッシュ、ブライアン・カーペンター、デビッド・コンラッド、スティーブ・ディーリング、フランシス・デュポン、ロバート・エルツ、ボブ・フィンク、オラファー・グドマンドソン、ボブ・ハリー、ボブ・ヒンデン、エドワード・ルイス、ビル・マニング、キース・ムーア、トーマス・ナルテン、エリック・ノードマーク、マイク・オデル、マイケル・パットン、ケン・パウエル。
[AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6, RFC 1886, December 1995.
[AAAA] Thomson、S。およびC. Huitema、「DNS拡張機能IPバージョン6、RFC 1886、1995年12月。
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Aarch] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[Aggr] Hinden、R.、O'Dell、M。、およびS. Deering、「IPv6 Agregatable Global Unicastアドレス形式」、RFC 2374、1998年7月。
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[BITLBL] Crawford、M。、「ドメイン名システムのバイナリラベル」、RFC 2673、1999年8月。
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[DNAME] Crawford、M。、「非末端DNS名リダイレクト」、RFC 2672、1999年8月。
[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[Dnsclar] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[DNSIS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNSIS] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC]イーストレイク、D。3rdおよびC.カウフマン、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KWORD] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[Renum1] Carpenter、B。and Y. Rekhter、「Nemumbering Needs Work」、RFC 1900、1996年2月。
[RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[Renum2] Ferguson、P。and H. Berkowitz、「ネットワークの名前を変更する概要：なぜ私はそれが欲しいのか、とにかくそれは何ですか？」、RFC 2071、1997年1月。
[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[Renum3] Carpenter、B.、Crowcroft、J。and Y. Rekhter、「IPv4アドレスToday」、RFC 2101、1997年2月。
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[Trans] Gilligan、R。およびE. Nordmark、「IPv6ホストとルーターの遷移メカニズム」、RFC 1933、1996年4月。
[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[Tsig] Vixie、P.、Gudmundsson、O.、Eastlake、D。3rdand B. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
Matt Crawford Fermilab MS 368 PO Box 500バタビア、イリノイ60510 USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: huitema@microsoft.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。