ＩＰｖ６アドレス集約サポートとリナンバリングへのＤＮＳ拡張

この文書はRFC2874の日本語訳です。この文書の翻訳内容の正確さは保障できないため、正確な知識を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

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
ＩＰｖ６アドレス集約サポートとリナンバリングへのＤＮＳ拡張

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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。

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.
この文書はリナンバリングと集約ＩＰｖ６をサポートするドメインネームシステ
ムに対する変更を定義します。この変更はＩＰｖ６アドレスのネットワーク番号
の付け直し（リナンバリング）を促進する新しい資源レコードタイプと、追加セ
クション処理の一部にインターネットアドレスを返す既存の問合せタイプの定義
の更新した方法を含みます。

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.
検索用のＩＰｖ６アドレス（しばしば逆引きと呼ばれる）について、この文
書は新しいゾーン構造を定義しました、新しい構造はアドレス空間の（マル
チプロバイダやサイトに関する）平行したコピーやネットワークリナンバリ
ングに対して修正せずに使用できます。

Table of Contents
目次

1. Introduction はじめに
2. Overview 概要
2.1. Name-to-Address Lookup 名前からアドレスの検索
2.2. Underlying Mechanisms for Reverse Lookups 逆引き機構の基礎
2.2.1. Delegation on Arbitrary Boundaries 任意の境界での委任
2.2.2. Reusable Zones 再利用可能なゾーン
3. Specifications 仕様
3.1. The A6 Record Type Ａ６レコードタイプ
3.1.1. Format フォーマット
3.1.2. Processing 処理
3.1.3. Textual Representation テキスト表現
3.1.4. Name Resolution Procedure 名前解決手順
3.2. Zone Structure for Reverse Lookups 逆引きのためのゾーン構造
4. Modifications to Existing Query Types 既存の問合せタイプへの修正
5. Usage Illustrations 使用法具体例
5.1. A6 Record Chains Ａ６レコード鎖
5.1.1. Authoritative Data 権威があるデータ
5.1.2. Glue 接着剤
5.1.3. Variations 相違
5.2. Reverse Mapping Zones 逆引きゾーン
5.2.1. The TLA level ＴＬＡレベル
5.2.2. The ISP level ＩＳＰレベル
5.2.3. The Site Level サイトレベル
5.3. Lookups 検索
5.4. Operational Note 操作上の注釈
6. Transition from RFC 1886 and Deployment Notes RFC1886からの移行と配置メモ
6.1. Transition from AAAA and Coexistence with A Records AAAAからの移行とＡレコードとの共存
6.2. Transition from Nibble Labels to Binary Labels ４ビットラベルから２進数ラベルへの移行
7. Security Considerations セキュリティ考慮
8. IANA Considerations IANA考慮
9. Acknowledgments 謝辞
10. References 参考文献
11. Authors' Addresses 著者のアドレス
12. Full Copyright Statement 著作権表示全文

1. Introduction
1. はじめに

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のアドレス情報の維持管理はＩＰバージョン４でサイトとプロバイダで番
号を付け直す（リナンバリング）を困難にした障害の１つです。安定したルー
ティングシステム維持やその他の目的でのネットワークリナンバリング重要
性の論拠は[RENUM1, RENUM2, RENUM3]を読んで下さい。リナンバリングを妨
げずにＩＰｖ６アドレスの登録をサポートするため、我々は次の拡張を定義
します。

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"が定義されます。

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 ＩＰｖ４アドレスを設定する追加セクション処理を行う既存の問合せが、
ＩＰｖ４とＩＰｖ６アドレス両方の処理に再定義されます。

o A new domain, IP6.ARPA, is defined to support lookups based on
IPv6 address.
o 新しいドメインIP6.ARPAがＩＰｖ６アドレスに基づいた検索をサポートす
るために定義されます。

o A new prefix-delegation method is defined, relying on new DNS
features [BITLBL, DNAME].
o 新しいＤＮＳ機能[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].
変更は既存のアプリケーション・プログラミング・インタフェースと両立で
きるよう意図されます。ＩＰｖ４アドレスに対する既存のサポートは維持さ
れます。ＤＮＳでのＩＰｖ４とＩＰｖ６両方の共存に関する移行問題が
[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]の置換えと、現在の実装環境の置換えを提案しま
す。変更はネットワーク番号を付け直すことを容易にし、マルチホームする
よう意図されます。ＩＰｖ６アドレスにＡ６レコードを使用しているドメイ
ンが移行を容易にするために自動的に生成された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.
この文書の次の３つの主要な章は、この仕様書によって定義されるか使用さ
れる機能の概要、仕様自身、使用例です。

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"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[KWORD]で記述されるように、解釈されるはずです。キーワード"SUGGESTED"
はMAYとSHOULDの間の強度を意味します：提案の遵守がたいていの場合に明白
な利益があると信じられます。

2. Overview
2. 概要

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.
この章はＩＰｖ６アドレスの登録とＩＰｖ６に基づいく検索のDNS機能の概要
と、ここか他で定義するものの概要を提供します。

2.1. Name-to-Address Lookup
2.1. 名前からアドレスの検索

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.
ＩＰｖ６アドレスが１つ以上のＡ６資源レコードに登録されます。１つのＡ
６レコードが完全なＩＰｖ６アドレスを含むか、アドレスの連続的な部分と
上位プレフィックスを探す情報を含みます。プレフィックス情報がプレフィッ
クス長と、完全なＩＰｖ６アドレスを生成するのに必要な１つ以上のプレ
フィックスを定義している１つ以上のＡ６レコードの所有者のＤＮＳ名を含
みます。プレフィックス長がゼロの時、ＤＮＳ名が存在せず、全てのアドレ
ス上位ビットは有効です。無効ビットに多数のレベルがあるかもしれません、
そしてどんなレベルでも多数のＡ６レコードの存在は生成するＩＰｖ６アド
レスの数を増やします。

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.
ＩＰｖ６アドレスを検索するアプリケーションが一般にＤＮＳリゾルバにい
くつかのＡ６レコードをアクセスさせるでしょう、たとえ照会された名前が
ただ１つのＡ６レコードの所有者であったとしても多数のＩＰｖ６アドレス
が返されるかもしれません。返されたアドレスの信憑性は直接ＤＮＳセキュ
リティ[DNSSEC]で確かめることができません。アドレスに寄与したＡ６レコー
ドは、もし署名されるなら、検証されるかもしれません。

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.
実装者はリゾルバがクライアントの要請で行う仕事量を制限する必要を思い
出させられます。この原則は「アドレスから名前」（あるいは「名前からア
ドレス」）の検索の要求が求めるＤＮＳ問合せの数を制限するために拡大さ
れなくてはなりません(MUST)。

2.2. Underlying Mechanisms for Reverse Lookups
2.2. 逆引き機構の基礎

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.
この章はこの文書が採用する新しいＤＮＳ機能を記述します。この章は機能
の仕様書ではなく概要です。読者はそれぞれ細部について参考文献を見てく
ださい。

2.2.1. Delegation on Arbitrary Boundaries
2.2.1. 任意の境界での委任

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]と呼
ばれるＤＮＳラベルに頼ります。このラベルは１ビットラベルの階層的な列
と扱われる任意のビット列を短く表現します。資源レコードがこれによって
任意のビット境界線上におくことができます。

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.
５章の例でビットストリングラベルの以下のテキスト表現を使用するが、こ
れは[BITLBL]で定義される文法のサブセットです。１６進数と１６進数の連
続を示す"x"が"\["と"]"「ｘ」の間に包まれます。数字の示すビットは1ビッ
トドメインラベルの最上位ビットから最下位ビットへの連続を表します。
（これは１ビットを一度に表記する場合の逆順ですが、都合が良い表記と思
われます）。数字列はスラッシュ("/")と１０進数の個数が続くかもしれませ
ん。もしなければ、１６進数の数の４倍と等しい個数を暗示します。

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の問合せでQCLASSでＩＰｖ６アドレスが
3ffe:7c0:40:9:a00:20ff:fe81:2b32のノードの名前を探すのに使えます。

\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.

\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.

2.2.2. Reusable Zones
2.2.2. 再利用可能なゾーン

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.
ＤＮＳアドレス空間委任がゾーンの切断と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.

which will cause it to look for a.b.c.w.xy.
これはa.b.c.w.xyを検索せるでしょう。

3. Specifications
3. 仕様

3.1. The A6 Record Type
3.1. Ａ６レコードタイプ

The A6 record type is specific to the IN (Internet) class and has
type number 38 (decimal).
Ａ６レコードタイプはＩＮ（インターネット）クラス特有で、種別番号３８
（１０進数）です。

3.1.1. Format
3.1.1. フォーマット

The RDATA portion of the A6 record contains two or three fields.
Ａ６レコードのRDATA部は２つか３つのフィールドを含んでいます。

o A prefix length, encoded as an eight-bit unsigned integer with
value between 0 and 128 inclusive.
o ８ビットの符号なしの整数としてコード化される、０から１２８の間の値
のプレフィックス長。

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 ネットワークオーダー（上位オクテットが先）でコード化されるＩＰｖ６
アドレス後部。このフィールドは過不足なく正確にオクテット単位で(MUST)、
１２８からプレフィックス長を引いた数のビットと、このフィールドをオ
クテット単位にするための０から７ビットの穴埋めビットを含みます。パッ
ドビットがもしあるなら、ゾーンファイルを読み込んだときにゼロに設定
され、（SIG確認時を除き[DNSSEC]）受信時に無視されます(MUST)。

o The name of the prefix, encoded as a domain name. By the rules of
[DNSIS], this name MUST NOT be compressed.
o プレフィックスの名はドメイン名としてコード化されます。[DNSIS]の規
定どおりこの名前は圧縮さません(MUST NOT)。

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.
ドメイン名の部分は、プレフィックス長がゼロなら、存在するべきでありま
せん(SHALL NOT)。アドレス後半部は、プレフィックス長が１２８であるなら、
存在するべきではありません(SHALL NOT)。

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.
他のＡ６レコードのプレフィックスに使用するＡ６レコードは、アドレスの
後半部にゼロが設定される無意味なビットを持つことを意図していると示唆
します(SUGGESTED)

3.1.2. Processing
3.1.2. 処理

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の問合せは、Ａ６タイプと、もし回答のＡ６レコードのRDATAフィー
ルドにプレフィックスがあれば、ＮＳタイプの追加セクションを発生します。
この処理はＡ６レコードのプレフィックス名に再帰的に適用されます(SHOULD)、
追加データに含められます。応答パケットの大きさの限界に達した時、追加
のＡ６レコードを含むことがＮＳレコードより優先されます。

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.
プレフィックス長Ｌ１＞０のＡ６レコードがドメイン名を参照し、そのドメ
イン名がプレフィックス長Ｌ２＞Ｌ１のＡ６レコードの場合、エラーです。
もしこのような状態のリゾルバが遭遇したら、違反した（大きい）プレフィッ
クス長のＡ６レコードは無視されなくてはなりません(MUST)。もしアドレス
が正しいＡ６レコードから生成できればエラーは防げます、しかし安定のた
めゾーン管理者は時折そのゾーンが参照するすべてのＡ６レコードをチェッ
クすることが提案されます(SUGGESTED)。

3.1.3. Textual Representation
3.1.3. テキスト表現

The textual representation of the RDATA portion of the A6 resource
record in a zone file comprises two or three fields separated by
whitespace.
ゾーンファイル中のＡ６資源レコードのRDATA部のテキスト表現は空白スペー
スで分割された２つあるいは３つのフィールドを含みます。

o A prefix length, represented as a decimal number between 0 and 128
inclusive,
o ０以上１２８以下の１０進数表記のプレフィックス長

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]で定義されるＩＰｖ６アドレスのテキスト表現（いくらかの
先頭ビットと後続ビットが無意味ですが）。

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.
ドメイン名は、プレフィックス長がゼロなら、ないに違いありません(MUST)。
プレフィックス長が１２８なら、ＩＰｖ６アドレスはないかもしれません
(MAY)。プレフィックス長に等しい数のアドレスの先頭ビットが、３．１．１
章で指定されるように暗黙（：：表記）にか明示的に、ゼロにするべきです
(SHOULD)。

3.1.4. Name Resolution Procedure
3.1.4. 名前解決手順

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.
指定された名前に属するＩＰｖ６アドレスを得るには、ＤＮＳクライアント
が完全なＡ６鎖を得ないといけません(MUST)、各鎖は指定された名前に所有
されるレコードとそのレコードのプレフィックス名を所有するレコードを含
み、これが繰り返され、プレフィックス長がゼロのＡ６レコードで終わりま
す。ＩＰｖ６アドレスは最初のＡ６レコードから順に、各プレフィックス長
で示されるビット位置までのビットを取り出していくことで生成されます。
与えられた名前から始まり、３.１.２章で定義される無効なプレフィックス
長のレコード以外で、完全なＡ６レコード鎖から形成されたアドレスが、す
べてのＩＰｖ６アドレスです。

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.
もしあるＡ６問合せが失敗し他が成功するなら、クライアントは全てのＩＰ
ｖ６アドレスのうち一部だけを得るかもしれません。多くの場合これは許容
できるかもしれません。Ａ６レコード集合の完全性は検査によって決定され
るかもしれません。

3.2. Zone Structure for Reverse Lookups
3.2. 逆引きのためのゾーン構造

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.
新しい案のデータでIP６.ARPAの下で実際に現われるのは極めて少しです；た
だ委任の最初のレベルだけがそのドメインの下にある必要があります。もし
上位レベルの委任がDNAMEレコードでなくNSレコードでされるなら、より多く
のレベルの委任がIP6.ARPA下に置けます。これはＴＬＡレベル[AGGR]で番号
を付け直すコストを増やすでしょう。それ故に、すべてのアドレス空間委任
がNSではなくDNAMEメカニズムで行うべきとここに宣言します(SHOULD)。

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"の直下に登録することを提案しま
す(SUGGESTED)。別の言い方をすると、この提案に適合するとは、ＩＰｖ６逆
引きをサポートするDNAMEレコードのRDATAフィールドの最初のラベルは"IP6"
あることです。

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.
「予約」か「ゼロである」ビットがは委任境界に隣接している場合、上位の
権威者が権威者自身の制御下にそれらのビットを置き、下位の権威者には権
限を持っているビットだけを委任しなくてはならない(MUST)。

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.
与えられたＩＰｖ６アドレスからノード名前を見つけるために、ＤＮＳクラ
イアントが、１２８ビットのアドレスを、１つ以上のビットストリングラベ
ル[BITLBL]と続く標準の２つのラベル"IP6.ARPA"として構成し、QCLASS=IN,
QTYPE=PTRの問合せを行わなくてはなりません。もし再帰的サービスがサーバー
から得られず、望ましいPTRレコードが返されなければ、リゾルバはDNAMEレ
コードを解答者は[DNAME]で指定されるように処理し、NSレコードを[DNSCF]
で指定されるように処理し、再度問合せします(MUST)。

4. Modifications to Existing Query Types
4. 既存の問合せタイプへの修正

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）とメールボックス（ＭＢ）の問合せタ
イプと実験的なＡＦＳデータベース（AFSDB）と経路指定（RT）タイプが、タ
イプＡとタイプＡ６とタイプＡＡＡＡの追加セクション処理をするように再
定義されます、このときタイプＡが最も追加の優先度が高くＡＡＡＡが追加
の優先度が低くなります。この再定義はネームサーバーが、上記の問合わの
どれかを処理する時、回答の追加セクションにローカルに利用可能な適切な
ＩＰｖ４とＩＰｖ６アドレス情報を加えてよいことを意味します。追加の部
分に含められたＡ６レコードの参照するＡ６レコードの再帰的な追加は任意
です(OPTIONAL)。

5. Usage Illustrations
5. 使用法具体例

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.
この章は前の章で定義された機構の役に立つ例を示します。ここに記載され
たすべてのアドレスとドメインは説明の目的で作った架空のものです。この
例で読みやすさのため委任を４ビット単位で設定します；この指定はビット
整列に無関係です。

Use of the IPv6 aggregatable address format [AGGR] is assumed in the
examples.
例でＩＰｖ６集約アドレスフォーマット[AGGR]の使用が仮定されます。

5.1. A6 Record Chains
5.1. Ａ６レコード鎖

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.
中間プロバイダＡとＢにマルチホームしているあるサイトＸを例にします。
プロバイダＡ自身は中継プロバイダＣとＤにマルチホームします。プロバイ
ダＢは１つのプロバイダＥから中継サービスを得ます。単純のために、Ｃと
ＤとＥが同じ最上位集約(TLA)'2345'（フォーマットプレフィックスを含む）
にあり、ＴＬＡの管理者がALPHA-TLA.ORGとします。ALPHA-TLA.ORGはＣとＤ
とＥにそれぞれ次のレベル集約（ＮＬＡ）プレフィックスの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.
ＣがＡにＮＬＡプレフィックス2345:00C1:CA00::/40を割り当て、ＤがＡにプ
レフィックスに2345:00D2:DA00::/40を割り当て、ＥがＢに
2345:000E: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:
ＡがＸに加入者識別子'11'を割り当て、Ｂが加入者身識別子'22'を割り当て
ます。結果として、サイトＸは３つのアドレスプレフィックスを継承します：

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.

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:
そのＮがサイトＸのノードで、このサイトのサブネット番号１を割り当てら
れ、インタフェース識別子が'1234:5678:9ABC:DEF0'とします。この条件で、
ノードＮは３つのアドレスを持ちます：

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

5.1.1. Authoritative Data
5.1.1. 権威があるデータ

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.EXAMPLEと表されると想定し、ＡとＢとＣと
ＤとＥがA.NETとB.NETとC.NETとD.NETとE.NETで 表されると想定します。こ
れらのドメインのそれぞれに対応するプレフィックスを登録するサブドメイ
ン"IP6"を仮定します。ノードＮはドメイン名N.X.EXAMPLEで表します。次の
レコードはＸのＤＮＳに現われるでしょう。

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

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.

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::

5.1.2. Glue
5.1.2. 接着剤

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のＤＮＳサーバーの一部か全部がX.EXAMPLEゾー
ン自身の中にある時、最上位ゾーンEXAMPLEはＤＮＳクライアントがネームサ
ーバにアクセスできるのに十分な「接着剤」情報が必要です。これはＩＰｖ４
と同様にＩＰｖ６でも真実です。Ａ６レコードはＤＮＳ管理者にいくつかの
選択肢を与えます。接着剤は次のどれかです。

o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
o X.EXAMPLEゾーンからコピーされたＡ６レコードの最小集合。

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 プレフィックス長がゼロのＡ６レコード集合、サーバーの完全なグローバ
ルアドレスを記録します。

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.
これは管理しやすさと安定性のトレードオフです。最善と最悪の両方が、最
初か２番目の選択と3番目の選択を同時にすることではっせいするかもしれま
せん。接着剤の選択を説明するのに、X.EXAMPLE２つのネームサーバー
NS1.X.EXAMPLEとNS2.X.EXAMPLEで扱われて、それぞれサブネット１と２にあ
り、インターフェース識別子::1:11:111:1111と::2:22:222:2222します。最
上位ゾーンEXAMPLEは以下のＡ６レコードのいくつかを含むでしょう。

$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.
最初と２番目の接着剤の選択はX.EXAMPLEのプロバイダプレフィックスA.NET
とB.NETの番号を付け直すことに対して安定であるが、プロバイダの自身のＤ
ＮＳにアクセスできないと失敗するでしょう。３番目の選択は接着剤レコー
ドは、EXAMPLEゾーンとX.EXAMPLE自身を除き、他のＤＮＳの障害に対して安
定ですが、Ｘのアドレス空間が番号を付け直される時、設定しなおさないと
いけません。

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.
もしEXAMPLEゾーンが重複した接着剤、例えば1番目と３番目の選択のＡ６レ
コードの組合せを含むなら、標準的な状況の下で重複したＩＰｖ６アドレス
がＤＮＳクライアントによって得られるでしょう。もしプロバイダのＤＮＳ
が故障しても、プレフィックス長がゼロのレコードからアドレスが得られる
し、他方もしEXAMPLEゾーンの設定し直しがX.EXAMPLEの番号を付け直しより
遅れてもＤＮＳクライアントの得たアドレスの半分が最新でしょう。

The zero-prefix-length glue records can of course be automatically
generated and/or checked in practice.
プレフィックス長がゼロの接着剤レコードはもちろん自動的に生成でき、実
際に確認することができます。

5.1.3. Variations
5.1.3. 相違

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.
最初にサイトＸはサブネット情報を各ノードのＡ６レコードに入れるか、
別のＡ６レコードに入れるかを決めます。

Second, that site X is referred to as "SUBSCRIBER-X" by both of
its providers A and B.
第二に、サイトＸはそのプロバイダＡとＢの両方から"SUBSCRIBER-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.
第三にサイトＸがプロバイダ情報を上位ビットを含まないIP6.X.EXAMPLE
のＡ６レコードから間接参照するか選択します。各プロバイダの各サブ
ネットレコードで選択が繰り返されます。

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.
第四に、ＢとＥがＡとＣとＤより少し異なるプレフィックス名の規定を使
います。各ネットワークの階層でそれぞれ名前を決めなくてはなりません。

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で終わります。
そこにＴＬＡ値を割り当てたもう１つのレベルがあり、そのビットを含
むＡ６レコードがあります。

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:
最終的に、上記の構造はある者が割り当てたアドレスフィールドはその者が
持つＡ６でだけ記録されるという仮定を反映します。そのビットは代わりに、
下位レベルの者のゾーンのＡ６レコードに入れる事ができます：

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.

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.
あるいは上位者が（異なるＤＮＳ所有者名で）両方のＡ６レコードの種類を
持ち、下位者に好きなＡ６鎖につなぐことを選択可能にきます。けれどもデー
タ重複を避ける一般的な原則は割当てた値をしまう適切な場所が割当者が
持っていることを示唆します。

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.
これは可能ですが、ゾーン管理者がＡ６レコードをつなぐのと１つのゾーン
ファイルに全部のＩＰｖ６アドレスを記録するため、番号を付け直しのサポー
トをあきらめるだろうから必ずしも推薦されていません。

5.2. Reverse Mapping Zones
5.2. 逆引きゾーン

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
フォーマットプレフィックス（００１、2進表記）のＴＬＡで、識別子０３４
５と０６７８と０９ABのアドレス空間が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.

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]の予約８ビッ
トを反映するため各ＴＬＡＩＤに後続する８個のゼロのビットが含められました。

5.2.1. The TLA level
5.2.1. ＴＬＡレベル

ALPHA-TLA's assignments to network providers C, D and E are reflected
in the reverse data as follows.
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.

5.2.2. The ISP level
5.2.2. ＩＳＰレベル

The providers A through E carry the following delegation information
in their zone files.
プロバイダＡからＥは各ゾーンファイルに次の委任情報を含めます。

\[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に現われることに注意して
ください。この場合、１つのゾーンが多数のプレフィックスの検索で使われ
ています。

5.2.3. The Site Level
5.2.3. サイトレベル

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.
ユーザX.EXAMPLEがアドレスから名前への翻訳にIP6.X.EXAMPLEを使っている
と思ってください。このドメインは２つの異なるプロバイダの持つ２つの異
なる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.
SUBNET-1がDNAMEレコードにいれる必要はありません；サブネットビットはイ
ンタフェース識別子とつなぐことができます。もしサブネットをＡ６レコー
ドと逆引きの両方で同様に扱うなら、各プレフィックスの正引きと逆引きの
定義データを１つのゾーンに置いておくことが常に可能でしょう。

5.3. Lookups
5.3. 検索

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:CA11:0001:1234:5678:9ABC:DEF0のホスト名を探している
ＤＮＳリゾルバは上記DNAMEレコードのいくつかを獲得し、新しい問合せを作
るでしょう。IP6.ARPAのサーバーを知る手順が始まったと想定します、しかし
どのサーバも再帰を提供せず、キャッシュされた他の有用な追加の情報もない
と想定します、。名前の問合せは以下のようになるでしょう（すべてQCLASS=IN,
QTYPE=PTRです）：

To a server for IP6.ARPA:
IP6.ARPAのサーバーに対して：
QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.

Answer:
回答：
\[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.

To a server for IP6.ALPHA-TLA.ORG:
IP6.ALPHA-TLA.ORGのサーバーに対して：
QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.

Answer:
回答：
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.

To a server for 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.:
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.:
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で解決できたら、そのレコード
は再度読まなくてよいでしょう。

5.4. Operational Note
5.4. 操作上の注釈

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.
５．１章の例示で、例えばネットワークプロバイダとユーザは顧客のような、
階層的に隣接した管理者は、委任されたプレフィックスの定義を登録するＤ
ＮＳ名について合意しなければなりません。単純な取決め方の１つは、上位
者が下位者に割当てたビットと正確に同じビットストリングラベルを使用す
ることです。例えば"SUBSCRIBER-X"は"\[x11/8]"に置き換えられます。これ
は、委任されたプレフィックスを定義しているＡ６レコードを、委任と関連
しているDNAMEレコードと、ＤＮＳ木の正確に同じ位置に設置します。この簡
略化のデメリットは、番号を付け直す時に、下位のゾーンが上位を指定する
Ａ６レコードを修正しなければならないことです。このデメリットは実際に
は許容できるかもしれません。

6. Transition from RFC 1886 and Deployment Notes
6. RFC1886からの移行と配置メモ

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.
プレフィックスがＡ６レコードで「上に委任された」時、１つのＩＰｖ６ア
ドレスを作るために問い合わされるＤＮＳ資源レコードの数はかなりの割合
で増加します。これらのレコードは、必ずではないけど、一般的に異なるＤ
ＮＳゾーンから得られます（これらの問合せは独立になんらかの原因で失敗
するかもしれません）。同時に多数のＩＰｖ６アドレスを得る時は問合せ数
の増加は相対的に少なく、もしアドレスが同じゾーンにまとめられていれば、
そしてＤＮＳ応答の総量は減少するかもしれません。応答レコードは、例え
ばMXやNSやSRVなど、サイズの大きい応答[DNSCLAR]で、ＵＤＰサイズの上限
を超えることがあります。ＤＮＳ検索の性能と信頼性の全体的な低下の可能
性は高く、特に委任ポイントが他のゾーンのレコードを示す時、関係する委
任プレフィックス数が増加します。

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.
ＤＮＳセキュリティ[DNSSEC]がＤＮＳの本質的な問題であるキャッシュされ
たデータの信用を扱います。これをＩＰｖ６アドレスに適用すると、異なる
Ａ６レコードに異なる署名鎖で検証が必要ならば、プレフィックス委任の数
だけコストが増えます。もし信頼できる中央集権化されたキャッシュサーバー
（例えば[TSIG]）が使えるならばこのコストは許容できる程度に低下するか
もしれません。認証されたＡ６レコードと認証されないＡ６レコードからＩ
Ｐｖ６アドレスが生成される可能性があります。

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.
多くのＡ６レコードに設定の経験が得られるまで、プレフィックス委任が１
つか２つ程度に限定することが勧められます。合理的な段階的導入方法はプ
レフィックス委任なし（プレフィックス長が０のＡ６レコード）から始め、
次にひとつのゾーン内での１段階の委任を始めることです。（もし「プレ
フィックス」Ａ６レコードのTTLが適切な時間に設定されれば、迅速に番号を
付け直す能力は失われません）。より多くの積極的で柔軟な委任が、実験的
に一部のホストから導入できます。

6.1. Transition from AAAA and Coexistence with A Records
6.1. AAAAからの移行とＡレコードとの共存

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.
Ａ６レコードを含むゾーンの管理者が、Ａ６レコードではなくAAAAレコード
を理解するリゾルバに簡単に対応できます。管理者はホスト名からＩＰｖ６
アドレスを生成する手順を行うことで、ゾーン内のＡ６レコードの名前に対
してAAAAレコードを自動生成できます（３．１．４章参照）。生成された
AAAAレコードのTTLは、ＩＰｖ６アドレスを生成するのに使用されたＡ６のど
のTTLよりも小さくなるようにしなければなりません(MUST)。十分な安定性の
ために、AAAAレコードが生成されたゾーンで変更がくても、異なるゾーンの
Ａ６レコードの（TTLやRDATAの）変更を監視すべきです。もしゾーンが安全
[DNSSEC]なら、生成されたAAAAレコードはゾーンデータの残りとともに署名
されなくてはなりません(MUST)。

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.
ゾーン毎の考えで、数が少なく無害な余計なＡ６レコードのプレフィックス
がAAAAレコード生成時に除くかれるかもしれません(MAY)。このような例は、
ゾーンファイル中の最も大きい値以下の長さのプレフィックスのＡ６レコー
ドや、アドレスに特定の数の後続のゼロのビットを持つＡ６レコードです。

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.
利用者側からはＩＰｖ６アドレス検索でＡ６とAAAAの問合せ順序に次のどれ
かが可能です(MAY)：最初Ａ６次にAAAA；最初AAAAで次にＡ６；Ａ６のみ；同
時に両方。デフォルト（もし設定可能でなければ唯一の）の順序が最初にＡ
６で次にAAAAでなければなりません(MUST)。もしも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.
ＩＰｖ４とＩＰｖ６アドレスの間の優先順位のガイドラインとオプショ
ンは[TRANS]で指定されます。[TRANS]でAAAAレコードとしているものは、
これからは前の段落で指定された順番で、Ａ６そして／あるいはAAAAレ
コードに置き換えられるはずです。

6.2. Transition from Nibble Labels to Binary Labels
6.2. ４ビットラベルから２進数ラベルへの移行

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."
ＩＰｖ６アドレスがIP6.INTドメイン内のドットで区切られた文字列で
「.IP６.INT」で終わるものと表現されます。ドットで区切られた文字列
は逆順でコード化されます、すなわち低位部が最初で、次の部分がその次
と、コード化されます。各部分が１６進数で表現されます。例えば、
５．３章の例のアドレス2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
に対応する逆検索ドメイン名は、"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."になります。

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.
この仕様書に従う実装が３．２章で指定されたIP6.ARPAで２進法ラベルの検
索を行うでしょう。移行期間の実装が最初にIP6.ARPAで２進法ラベルを検索
し、これに失敗したらIP6.INTで４ビットラベルを検索することが勧められま
す(RECOMMENDED)。

7. Security Considerations
7. セキュリティ考慮

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.
ＩＰｖ６アドレスを決定するＡ６レコードの署名当局［DNSSEC］は、そのア
ドレスが占めるアドレス空間の委任パスを反映していくつかの実体の間で配
られます。ＤＮＳセキュリティは完全にビットストリングラベルとDNAMEレ
コードに適用できます。そしてＩＰｖ４と同じで、名前からアドレスへの変
換の認証とアドレスから名前への変換の認証が論理的に独立です。

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の有無にかかわらず、３.１.４章の不完全なアドレス集合生成が、Ｄ
ＮＳ検索での部分的障害により発生します。何らかの場合に完全なＤＮＳの
失敗より部分的な失敗が有害なら、利用者側で不完全な集合を拒否するか、
サーバー側ですべてのアドレスをプレフィックス長が０のＡ６レコードに設
定することで緩和できるかもしれません。

8. IANA Considerations
8. IANA考慮

The A6 resource record has been assigned a Type value of 38.
Ａ６資源レコードは３８のタイプ値を割り当てられました。

9. Acknowledgments
9. 謝辞

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.
著者は貴重な論議と批評に対して次の人々に感謝したいです：(略）

10. References
10. 参考文献

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

[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.

[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format", RFC 2374, July
1998.

[BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.

[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.

[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.

[DNSIS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
Security Extensions", RFC 2535, March 1999.

[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.

[RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering
Overview: Why would I want it and what is it anyway?", RFC
2071, January 1997.

[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.

[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.

[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.

11. Authors' Addresses
11. 著者のアドレス

Matt Crawford
Fermilab
MS 368
PO Box 500
Batavia, IL 60510
USA

Phone: +1 630 840-3461
EMail: crawdad@fnal.gov

Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

EMail: huitema@microsoft.com

12. Full Copyright Statement
12. 著作権表示全文

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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。

Japanese translation by Ishida So