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
DNSの拡張機能は、IPv6アドレスの集約とリナンバリングをサポートします
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.
著作権（C）インターネット協会（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.
この文書では、アドレッシングrenumberableと集約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内のアドレス情報の維持は、安定したルーティングシステムの保存のためおよび他の目的のためにリナンバリングネットワークの重要性について4引数で読み取ることができるIPバージョンで可能であることからリナンバリングサイトとプロバイダを妨げてきたいくつかの障害の一つであります[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.
新しいリソースレコードタイプ、「A6」O、「接頭辞」のビットをリードするための間接のための引当金で、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.
IPv4アドレスを見つけるために、追加のセクション処理を行うO既存のクエリは、IPv4アドレスとIPv6アドレスの両方のためにその処理を行うように再定義されています。
o A new domain, IP6.ARPA, is defined to support lookups based on IPv6 address.
新しいドメイン、IP6.ARPA O、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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります【KWORD]に記載されているように解釈されます。 「提案」というキーワードは、MAY間の強さを意味し、必要があります。提案の遵守は、ほとんどの場合、具体的なメリットを持っていると考えられています。
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アドレスは、一つ以上の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レコードにアクセスするようになりますし、複数のIPv6アドレスを照会名は一つだけA6レコードの所有者であっても返されることがあります。返されたアドレス（複数可）の信憑性は、直接DNSセキュリティ[DNSSEC]によって検証することができません。署名された場合、アドレス（ES）に寄与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進数と16進数のシーケンスのための塩基指示薬「X」は「\の[」と「]」の間に封入されています。数字で表されるビットが最もから最下位まで順序付けられ、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.
連続したビット列のラベルが適切な順序での連続したラベルのすべてのビットを含む単一のビット列ラベルに（ビット・カウント・フィールドのサイズによって課される限度まで）と等価です。 7C0：40：9：A00：20ff：fe81：2b32例として、以下のドメイン名のいずれかは、IPv6アドレス3FFEを持つノードの名前を検索するにはQCLASS =、QTYPE = PTRクエリで使用することができます。
\[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レコードで実装されていませんが、CNAMEレコードに新しいアナログによって、DNAMEリソースレコード[DNAME]と呼ばれています。 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（10進数）があります。
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.
ネットワークオーダー（第一高次オクテット）でエンコードされたIPv6アドレスのサフィックス、O。このフィールドオクテットの整数倍にするために0〜7の主要なパッドビットで、128のマイナスプレフィックス長に等しいビット数を含むように、このフィールドに正確に十分なオクテットがあるに違いありません。受信時にゾーンファイルをロードし（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を引き起こし、解答セクションのA6レコードのRDATAフィールドで、もしあれば、接頭語名の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.
これは、プレフィックス長L2> L1とA6レコードを所有しているドメイン名を参照するために、プレフィックス長L1> 0の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部のテキスト表現は、空白で区切られた二つまたは三つのフィールドを含みます。
o A prefix length, represented as a decimal number between 0 and 128 inclusive,
プレフィックス長O、0から128までの間の10進数として表されます
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.
プレフィックス長がゼロの場合、ドメイン名が存在してはなりません。プレフィックス長は、プレフィックス長に等しい先頭アドレスビットの数はセクション3.1.1で指定されるように、暗黙的（::表記を介して）、または明示的にゼロであるべき128である場合、IPv6アドレスが存在しないかもしれません。
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レコードから各ビット位置の値を取ることによって、一つのこのような鎖から形成されます。指定された名前のためのすべてのIPv6アドレスのセットは、セクション3.1.2で定義された無効なプレフィックス長を持つレコードを破棄し、その名前から始まるA6レコードのすべての完全なチェーンから形成されたアドレスを含みます。
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]のレベルで再番号付けやすさで、いくつかのコストが発生します。したがって、すべてのアドレス空間の代表団は、DNAMEメカニズムではなく、NSによって行われるべきであることをここに宣言されています。
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クライアントは、一つ以上のビットストリングラベル[BITLBL]、続いとして128ビットのアドレスから形成された名前をQCLASS = IN、QTYPE = PTRでクエリを実行しなければなりません2つの標準ラベル「IP6.ARPA」。再帰的なサービスは、サーバと、所望のPTRレコードから得られなかった場合に返されなかった[DNSCF]、および反復で指定されるように[DNAME]、およびNSレコードで指定され、リゾルバは返さDNAMEレコードを処理する必要があります。
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.
ネームサーバ、すなわち、追加のセクション処理を入力し実行し、すべての既存のクエリの種類、（NS）、メール交換（MX）、およびメールボックス（MB）クエリの種類、および（RT）タイプによる実験AFSデータベース（AFSDB）とルート、タイプAが最も包含およびタイプAAAAのための最も高い優先度を有する、タイプA、A6及びAAAA追加セクション処理を実行するように再定義されなければなりません。この再定義は、上記のクエリのいずれかを処理する場合、ネームサーバは、応答の追加セクションに局所的に利用可能な任意の関連する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の集約アドレスフォーマット[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「トランジット」プロバイダに、CおよびDは、プロバイダBからのトランジットサービスを取得し、それ自体があるのは、2つの「中間」プロバイダAとBプロバイダAにマルチホームされたサイトXの例を見てみましょう単一のプロバイダ、E.を簡単にするために「2345」（フォーマットプレフィックスを含む）C、DおよびEはすべて識別子と同じトップレベル集約（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.
00C1：Cは、NLAプレフィックス2345割り当てるAにCA00 :: / 40、Dは、プレフィックス2345割り当て：00D2：AにDA00 :: / 40とEは、2345割り当て：000E：B.へEB00 :: / 40
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:
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.
00D2：2345 O D.介してルートのAからDA11 :: / 48：000E：BからEB22 :: / 48、のための2345 O Cを介してルートのAからCA11 :: / 48：00C1：2345 O E.スルー経路
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は、それがこのサイトにサブネット番号1に割り当てられていることを、サイトX内のノードであり、それはインタフェース識別子「：5678：9ABC：DEF0 1234」を使用していると仮定しましょう。私達の構成では、このノードには、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
00C1：2345 O CA11：0001：1234：5678：9ABC：DEF0 2345 O：00D2：DA11：0001：1234：5678：9ABC：000E：EB22：0001：1234：5678：9ABC：DEF0 2345 O 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.
我々は、A、B、C、D及びEはA.NET、B.NET、C.NET、D.NET及びEで表されている間、サイトXは、ドメイン名X.EXAMPLEによってDNSに表されていると仮定します。ネット。これらのドメインのそれぞれにおいて、我々はサブドメインに対応する接頭辞を保持する「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.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
SUBSTSRIBER-S.IPSH.B.NET。アッシュ40 0：0：0022 :: B-NET.IPSH.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.IPSH.E.NET。アッシュ32 0：0：EB00 :: E.NET.ALFA-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::
TS.NET.ALFA-TLA.ORG。アッシュ0 2345：000 :: D.NET.ALFA-TLA.ORG。アッシュ0 2345：00D0 :: E.NET.ALFA-TLA.ORG。アッシュ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.
トレードオフは、堅牢性に対するメンテナンスの容易さです。両方の最高と最悪のは、第三と一緒に第1または第2のいずれかのオプションを実装することで、一緒にいたことがあります。 11：111：1111 :: 2：222：2222 22インタフェース識別子:: 1を有する、X.EXAMPLEは二つのネームサーバ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例。 ;最初のオプションX NS NS1.X NS NS2.X NS1.X A6 64 :: 1：11：111：1111サブネット1.IP6.X NS2.X A6 64 :: 2：22：222：2222サブネット2。 IP6.Xサブネット-1.IP6.X A6 48 0：0：0：1 :: IP6.Xサブネット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例。 ;第二の選択肢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
$ ORIGIN例。 ;第三の選択肢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.
第一及び第二の接着オプションは、プロバイダのA.NETとB.NETによってX.EXAMPLEの接頭辞のリナンバリングに対して頑健であるが、これらのプロバイダの独自のDNSが到達不能である場合に失敗します。第三の選択肢のグルーレコードは、他の場所ゾーンの例とX.EXAMPLEそのものよりも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.
実施例ゾーンは例えば第一及び第三のオプションのA6レコードの結合のために、冗長な接着剤を含む場合、次いで、通常の状況下でのIPv6アドレスを重複DNSクライアントによって導出されます。プロバイダのDNSが失敗した場合例ゾーンはX.EXAMPLEのリナンバリング遅れている場合は、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.
いくつかの多かれ少なかれ任意の仮定は、上記の構造に反映されています。次の選択肢のすべてが誰かの利便性の概念や両当事者間の合意によると、別々に行われている可能性があります。
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.
A、CおよびDは、ネットワークエンティティの各階層ペアは自分自身との間にこのネーミングを手配しなければなりませんでしたよりも、第四に、BおよびEは、自分自身との間にわずかに異なるプレフィックスの命名規則を使用していました。
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.
第五に、上向きのプレフィックス紹介チェーンは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.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.
またはより高いレベルのエンティティは、（別のDNS所有者名を持つ）A6レコードの両方の種類を保持し、下位レベルのエンティティは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
TLASにそのアドレス空間の割り当てを想定フォーマットプレフィックス（001）バイナリとID 0345、0678および09ABはALPHA-TLA.ORG、BRAVO-TLA.ORGとチャーリー・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.
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].
八個の末尾のゼロ・ビットは、現在の集約可能グローバルユニキャストアドレス形式の8つの予約ビット[AGGR]を反映するように各TLA IDに含まれています。
ALPHA-TLA's assignments to network providers C, D and E are reflected in the reverse data as follows.
次のようにネットワークプロバイダC、D及びEにALPHA-TLAの割り当ては、逆方向データに反映されています。
\[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.
E経由プロバイダAは、自分のゾーンファイルに次の委任情報を運びます。
\[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に現れることに注意してください。これらの場合、一つのゾーンは、複数のプレフィックスをマッピングするために使用されています。
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つの異なるDNAMEレコードによって参照されます。
$ORIGIN IP6.X.EXAMPLE.
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
and so on.
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.
サブネット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):
00C1：アドレス2345のホスト名を探してDNSリゾルバCA11：0001：5678：1234 9ABC：DEF0は上記に示したDNAMEレコードの特定の取得になると、新しいクエリを形成するであろう。それはIP6.ARPAのためのサーバーを知るプロセスを開始したと仮定すると、ないサーバーということは、どれもが他の有用な追加情報をキャッシュしなかった照会の名前と応答のシーケンスを再帰を提供し、相談することになります（QCLASSを持つすべてのIN =、QTYPE = PTR） ：
To a server for IP6.ARPA: QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
QNAME = \ [x234500C1CA110001123456789ABCDEF0 / 128] .IP6.ARPA：IP6.ARPAのためにサーバに。
Answer:
\[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
To a server for IP6.ALPHA-TLA.ORG: QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
QNAME = \ [xC1CA110001123456789ABCDEF0 / 104] .IP6.ALPHA-TLA.ORG：IP6.ALPHA-TLA.ORGためのサーバです。
Answer:
\[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.
To a server for IP6.A.NET.: QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
IP6.A.NET：QNAME = \ [x110001123456789ABCDEF0 / 88] .IP6.A.NETのためにサーバに。
Answer:
\[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.
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節の図では、このようなネットワークプロバイダと顧客として階層的に隣接するエンティティは、委任プレフィックス（複数可）の定義を所有するDNS名に同意しなければなりません。一つの単純な規則は、より高いによって下位レベルのエンティティに割り当てられた正確ビットを表すビット列のラベルを使用することであろう。例えば、 "加入者X" は "\ [X11 / 8]" で置き換えることができます。これは、その代表団に関連付けられているDNAMEレコードとしてDNSツリー内のまったく同じポイントで委任プレフィックスを定義するA6レコード（複数可）を置きます。この単純化のコストは、それが番号付けし直されたときに下位レベルのゾーンがその上向きの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応答の合計サイズは、さらに低下することがあります - アドレスは位相的にクラスタ化されている場合。しかし、レコードは、依然として容易例えば、MX、NS、またはSRVクエリに[DNSCLAR]大資源レコード集合を返す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]におけるとして）信頼集中キャッシュサーバが使用される場合、このコストは、許容可能なレベルに償却されるかもしれません。一つの新しい現象は、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つのレベルに制限することをお勧めします。合理的な位相のメカニズムはないプレフィックス委譲（プレフィックス長0を有する全てのA6レコード）で開始し、その後、単一ゾーン内の委任の単一レベルの使用に移動するであろう。 （「接頭辞」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レコードを含むゾーンの管理者は、簡単にAAAAレコードではなく、A6レコードを理解して展開リゾルバを収容することができます。このような管理者がIPv6アドレスにホスト名の解決を模倣プロセスにより、A6レコードを所有しているゾーンの名前のすべてのためにAAAAレコードの自動生成を行うことができます（セクション3.1.4を参照してください）。注目は、そのレコード内のIPv6アドレスを形成するために使用されたA6レコードのTTLの最小値以下であってはならない生成AAAAレコードに割り当てられたTTLに支払わなければなりません。完全な堅牢性のために、異なるゾーンにあったものA6レコードは、AAAAレコードが生成されているゾーンに変更がない場合でも（TTLまたはRDATAに）変更するために監視されるべきです。ゾーンは、[DNSSEC]安全である場合、生成された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;または並列に両方。デフォルトの順序（または唯一の順序は、設定可能でない場合）、その後、最初のAAAAをA6を試してみなければなりません。 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：5.3節の例のDEF0は、DNS名「0.fedcba9.- 8.7.6.5.4.3.2.1で求められます.1.0.0.0.1.1.ac1.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にバイナリ・ラベルの検索を実行します。移行期間の実装のための第1 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の障害よりも有害であるならば、それは、プレフィックス長が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.
著者は、貴重な議論とレビューのために、次の人に感謝したいと思います：マーク・アンドリュース、ロブAusteinと、ジム・バウンド、ランディブッシュ、ブライアン・カーペンター、デヴィッド・コンラッド、スティーブデアリング、フランシスデュポン、ロバート・エルツ、ボブ・フィンク、オラフルグドムンソン、ボブ・ハレー、ボブHindenとエドワード・ルイス、ビル・マニング、キースムーア、トーマスNarten氏、エリックNordmarkと、マイク・オデル、マイケル・パットンとケン・パウエル。
[AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6, RFC 1886, December 1995.
[AAAA]トムソン、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.とS.デアリング、 "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.、オデル、M.とS.デアリング、 "IPv6の集約可能グローバルユニキャストアドレス形式"、RFC 2374、1998年7月。
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[BITLBL]クロフォード、M.、 "ドメインネームシステムにおけるバイナリラベル"、RFC 2673、1999年8月。
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[DNAME]クロフォード、M.、 "非ターミナルDNS名リダイレクション"、RFC 2672、1999年8月。
[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[DNSCLAR]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月 "DNS仕様の明確化"。
[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.第三及び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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[RENUM1]大工、B.およびY. Rekhter、 "リナンバリングは作業が必要"、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]ファーガソン、P.とH.バーコウィッツ、「ネットワークのリナンバリングの概要：なぜ私はそれをしたいだろうし、それはとにかく何ですか？」、RFC 2071、1997年1月。
[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
【RENUM3]カーペンター、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、RFC 2101、1997年2月。
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[TRANS]ギリガン、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.、グドムンソン、O.、イーストレイク、D.第三およびB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
マット・クロフォードフェルミ研究所MS 368私書箱500バタビア、IL 60510 USA
Phone: +1 630 840-3461 EMail: crawdad@fnal.gov
電話：+1 630 840-3461 Eメール：crawdad@fnal.gov
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: huitema@microsoft.com
メールアドレス：huitema@microsoft.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。