RFC2874 日本語訳
2874 DNS Extensions to Support IPv6 Address Aggregation andRenumbering. M. Crawford, C. Huitema. July 2000. (Format: TXT=44204 bytes) (Updates RFC1886) (Updated by RFC3152, RFC3226, RFC3363, RFC3364) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Crawford
Request for Comments: 2874 Fermilab
Category: Standards Track C. Huitema
Microsoft Corporation
July 2000
コメントを求めるワーキンググループM.クロフォードの要求をネットワークでつないでください: 2874年のフェルミ国立加速研究所カテゴリ: 標準化過程C.Huitemaマイクロソフト社2000年7月
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
IPv6アドレス集合を支持するDNS拡張子と番号を付け替えること
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
このドキュメントは、「番号を付け替え-可能」とaggregatable 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アドレス(しばしば逆のルックアップと呼ばれる)で合わせられたルックアップのために、このドキュメントはゾーンがアドレス空間(「マルチ-家へ帰」っているプロバイダーやサイトのような)の平行なコピーと、そして、出来事に番号を付け替えさせるネットワークの向こう側に変更なしで使用されるのを許容する新しいゾーン構造を定義します。
Crawford, et al. Standards Track [Page 1] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[1ページ]。
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
1. 序論… 2 2. 概観… 3 2.1. 名前からアドレスへのルックアップ… 4 2.2. 逆のルックアップのためにメカニズムの基礎となります… 4 2.2.1. 任意の境界の代表団… 4 2.2.2. 再利用できるゾーン… 5 3. 仕様… 5 3.1. A6はタイプを記録します… 5 3.1.1. 形式… 6 3.1.2. 処理… 6 3.1.3. 原文の表現… 7 3.1.4. 名前解決手順… 7 3.2. 逆のルックアップのためのゾーン構造… 7 4. 存在することへの変更はタイプについて質問します… 8 5. 用法イラスト… 8 5.1. A6はチェインズを記録します… 9 5.1.1. 正式のデータ… 9 5.1.2. にかわで接ぎます。 10 5.1.3. 変化… 12 5.2. ゾーンを写像して、逆になってください… 13 5.2.1. TLAレベル… 13 5.2.2. ISPレベル… 13 5.2.3. サイトレベル… 13 5.3. ルックアップ… 14 5.4. 操作上の注意… 15 6. RFC1886からの変遷と展開注意… 15 6.1. AAAAからの変遷と記録との共存。 16 6.2. 少量ラベルから2進のラベルまでの変遷… 17 7. セキュリティ問題… 17 8. IANA問題… 17 9. 承認… 18 10. 参照… 18 11. 作者のアドレス… 19 12. 完全な著作権宣言文… 20
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でのアドレス情報の維持はサイトとプロバイダーの番号を付け替えるのがIPバージョン4で可能であることを防いだいくつかの障害の1つです。 安定したルーティングシステムの保存と他の目的のためのネットワークの番号を付け替えることの重要性の議論は[RENUM1、RENUM2、RENUM3]で読まれるかもしれません。 番号を付け替えることを妨害しないでIPv6アドレスの格納を支持するために、私たちは以下の拡大を定義します。
Crawford, et al. Standards Track [Page 2] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[2ページ]。
o A new resource record type, "A6", is defined to map a domain name
to an IPv6 address, with a provision for indirection for leading
"prefix" bits.
o 新しいリソースレコード種類、「A6"、先導が「」 ビットを前に置く」ので、IPv6アドレスにドメイン名を写像するために間接指定へのa支給で定義されます。
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to do that processing for both
IPv4 and IPv6 addresses.
o IPv4アドレスの場所を見つけるように追加セクション処理を実行する既存の質問は、IPv4とIPv6アドレスの両方のためのその処理をするために再定義されます。
o A new domain, IP6.ARPA, is defined to support lookups based on
IPv6 address.
o 新しいドメイン(IP6.ARPA)は、IPv6アドレスに基づくルックアップを支持するために定義されます。
o A new prefix-delegation method is defined, relying on new DNS
features [BITLBL, DNAME].
o 新しいDNSの特徴[BITLBL、DNAME]を当てにして、新しい接頭語代表団方法は定義されます。
The changes are designed to be compatible with existing application programming interfaces. The existing support for IPv4 addresses is retained. Transition issues related to the coexistence of both IPv4 and IPv6 addresses in DNS are discussed in [TRANS].
変化は、既存のアプリケーションプログラミングインターフェースと互換性があるように設計されています。 IPv4アドレスの既存のサポートは保有されます。 [TRANS]でDNSでのIPv4とIPv6アドレスの両方の共存に関連する変遷問題について議論します。
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.
このメモは現在の実現練習からRFC1886[AAAA]の仕様との交換と出発を提案します。 変化は、ネットワークの番号を付け替えるのとマルチホーミングを容易にするように設計されています。 IPv6アドレスにA6記録を使うと挿入できるドメインは変遷を緩和するゾーンファイルでのAAAA記録を自動的に発生させました。 相当期間の後にRFC1886がHistoricになると予想されます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[KWORD]で説明されるように本書では解釈されることであるべきですか? そして、「示されたこと」が強さを意味するキーワードがそうするかもしれない、:であるべきです 提案への承諾には明白な利点がたいていの場合あると信じられています。
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.
このセクションはIPv6アドレスの格納とここで定義されたものを含むIPv6アドレスの上とほかの場所に基づいたルックアップにDNS施設の概観を提供します。
Crawford, et al. Standards Track [Page 3] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[3ページ]。
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.
IPv6アドレスは1つ以上のA6リソース記録に格納されます。 ただ一つのA6記録は完全なIPv6アドレス、または1つ以上の接頭語につながるアドレスと情報の隣接の部分を含むかもしれません。 接頭語情報は接頭語の長さと順番に、1A6の所有者が接頭語を定義しながら記録するということであるDNS名か1つ以上の完全なIPv6アドレスを形成するのに必要である接頭語を包括します。 接頭語の長さがゼロであるときに、どんな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.
一般に、DNSレゾルバはIPv6アドレスを調べるアプリケーションからいくつかのA6記録にアクセスするでしょう、そして、質問された名前が1つのA6記録だけの所有者であったとしても、複数のIPv6アドレスを返すかもしれません。 DNS Security[DNSSEC]は直接返されたアドレス(es)の信憑性について確かめることができません。 サインされるなら、アドレス(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.
Implementersはレゾルバがクライアント要求に対応して実行する仕事量を制限する必要性について思い出させられています。 また、1つの名前からアドレス(または、命名するアドレス)へのルックアップ要求に対応してDNS要求の世代を制限するためにこの原則について敷衍しなければなりません。
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.
このセクションはこのドキュメントが利用する新しいDNSの特徴について説明します。 このセクションはそれらの特徴の仕様ではなく、概観です。 読者はそれぞれに関するその他の詳細のための参照をつけられたドキュメントに向けられます。
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]と呼ばれる新しいタイプの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
セクション5の例はビット列ラベルの以下の原文の表現を使うでしょう。(それは、[BITLBL]で定義された構文の部分集合です)。 そして、「16進数字の16進と系列のための「x」が同封されるベースインディケータ」\、[「」、]、」 ケタによって指示されたビットは1ビットのドメインの系列を表します。
Crawford, et al. Standards Track [Page 4] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[4ページ]。
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.
ラベルは大部分から最も重要にならないまで注文されました。 (これによる一度に1ビット記載されるならそれらがそうするオーダーの正反対が現れますが、便利な記法であるように見えるということです。) スラッシュ(「/」)と10進カウントはケタストリングのあとに続くかもしれません。 省略されるなら、暗黙のカウントは数の4倍の16進数字と等しいです。
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で以下のドメイン名のどちらかを使用できました、IPv6アドレス3ffe: 7c0でノードの名前を見つけるQTYPE=PTR質問: 40:9:a00:20ff:fe81:2b32。
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA。
\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
\[x0A0020FFFE812B32/64]\[x0009/16]\[x3FFE07C00040/48].IP6.ARPA。
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.
DNSアドレス空間代表団はゾーンカットとNS記録によって実行されるのではなく、DNAMEリソース記録[DNAME]と呼ばれるCNAME記録への新しいアナログによって実行されます。 DNAME記録はただ一つのノードにというよりむしろドメイン名スペースの全体の下位木に交互の命名を提供します。 それで、名前でDNAME記録のRDATAから質問された名前の何らかの接尾語を代入します。
For example, a resolver or server providing recursion, while looking up a QNAME a.b.c.d.e.f may encounter a DNAME record
例えば、レゾルバかサーバが再帰を提供する場合、c.d.e.fはQNAME a.b.を見上げている間、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を探させるでしょう。
3. Specifications
3. 仕様
3.1. The A6 Record Type
3.1. A6レコード種類
The A6 record type is specific to the IN (Internet) class and has type number 38 (decimal).
A6レコード種類は、IN(インターネット)のクラスに特定であり、形式数38(小数)を持っています。
Crawford, et al. Standards Track [Page 5] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[5ページ]。
3.1.1. Format
3.1.1. 形式
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) |
+-----------+------------------+-------------------+
+-----------+------------------+-------------------+ |接頭語len| アドレス接尾語| 接頭語名| | (1つの八重奏) | (0 .16の八重奏) | (0 .255の八重奏) | +-----------+------------------+-------------------+
o A prefix length, encoded as an eight-bit unsigned integer with
value between 0 and 128 inclusive.
o 値0〜128が包括的に8ビットの符号のない整数としてコード化された接頭語の長さ。
o An IPv6 address suffix, encoded in network order (high-order octet
first). There MUST be exactly enough octets in this field to
contain a number of bits equal to 128 minus prefix length, with 0
to 7 leading pad bits to make this field an integral number of
octets. Pad bits, if present, MUST be set to zero when loading a
zone file and ignored (other than for SIG [DNSSEC] verification)
on reception.
o ネットワークオーダー(八重奏に1番目を高値で命令する)でコード化されたIPv6アドレス接尾語。 八重奏が十分まさにこの分野を整数の八重奏にする主な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.
ドメイン名コンポーネントSHALL NOT、接頭語の長さがゼロであるなら、存在してください。 接尾語コンポーネントSHALL NOTを記述してください。接頭語の長さが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記録が使用のために意図した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との質問は、接頭語名のためにタイプにA6を引き起こして、追加セクション処理をタイプNSに引き起こします、もしあれば、答え部でのA6記録のRDATA分野で。 この処理SHOULDは再帰的に申し込みます。追加データとして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記録をチェックするのは、SUGGESTEDです。
Crawford, et al. Standards Track [Page 6] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[6ページ]。
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.
ゾーンファイルにおける、A6リソース記録のRDATA部分の原文の表現は空白によって切り離された2か3つの野原を含みます。
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.
ドメイン名は接頭語の長さがゼロであるなら欠けているに違いありません。 IPv6アドレスはそうです。接頭語の長さが128であるなら、休んでください。 数、それとなく接頭語の長さのSHOULDと等しいアドレスビットを導くことでは、ゼロになってください、(通じて、: : 記法、)、明らかに、中で指定されるように.1に3.1を区分してください。
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.
名に属すIPv6アドレスかアドレスを得るために、DNSクライアントはその記録、などにA6記録と、記録が名に所有されている状態で始まる各チェーンと接頭語名によって所有されていた記録を含む1つ以上の完全なチェーンを再帰的に入手しなければなりません、ゼロの接頭語の長さがあるA6記録で終わって。 1つのIPv6アドレスがそのようなチェーンの1つから最も初期のA6記録から確実にその位置を覆うチェーンでそれぞれのビット位置の値を取ることによって、形成されます、接頭語の長さによって示されるように。 名のためのすべてのIPv6アドレスのセットはその名前で始まるA6記録のすべての完全なチェーンから形成されたアドレスを包括します、セクション3.1.2で定義されるように無効の接頭語の長さを持っている記録を捨てて。
If some A6 queries fail and others succeed, a client might obtain a non-empty but incomplete set of IPv6 addresses for a host. In many situations this may be acceptable. The completeness of a set of A6 records may always be determined by inspection.
いくつかのA6質問が失敗して、他のものが成功するなら、クライアントは非空の、しかし、不完全なIPv6アドレスをホストに得るかもしれません。 多くの状況で、これは許容できるかもしれません。 1セットのA6記録の完全性は点検でいつも決定するかもしれません。
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
新しい計画のデータについてほとんど、実際にIP6.ARPAの下に現れません。 最初のレベルの代表団だけが、そのドメインの下にある必要があります。 DNAME記録の代わりにNS記録でいくつかのトップレベル代表団をするなら、IP6.ARPAの下により多くのレベルの代表団を置くことができますが、これは番号を付け替えることにおける費用が軽くなるいくつかを被るでしょう。
Crawford, et al. Standards Track [Page 7] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[7ページ]。
level of TLAs [AGGR]. Therefore, it is declared here that all address space delegations SHOULD be done by the DNAME mechanism rather than NS.
TLAs[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です。 述べられた別の方法、この提案による順応は「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クライアントはIN(1つ以上のビット列が[BITLBL]をラベルするので128ビット・アドレスから形成された名前のQTYPE=PTR)が2つの標準ラベル"IP6.ARPA"を続けたQCLASS=で質問を実行しなければなりません。 再帰的なサービスがサーバから得られなかったか、そして、必要なPTR記録が返されなかったと[DNAME]での指定されるとしてのDNAME記録を返す場合、レゾルバは扱わなければならなくて、NSは、記録します。[DNSCF]で指定して、繰り返します。
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)((RT)タイプによるメール交換(MX)、およびメールボックス(MB)質問タイプ、実験AFSデータベース(AFSDB)、およびルート)を働くすべての既存の質問タイプがA追加セクション処理をタイプして、すなわち、タイプA、A6、およびAAAAの追加セクション処理を実行するために、再定義しなければなりません、包含のための最優先を持っているタイプAとタイプAAAAが最も低い状態で。 この再定義は、上の質問のどれかを処理するとき、ネームサーバが局所的に利用可能などんな関連IPv4とIPv6アドレス情報も応答の追加セクションに追加するかもしれないことを意味します。 追加セクションに既に含まれていたA6記録によって参照をつけられるA6記録の再帰的な包含は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.
このセクションは前項で定義されたメカニズムで役に立つ例を提供します。 すべてのアドレスとここに参照されたドメインは架空であることを意図して説明に役立った目的だけのためのものです。 例の代表団が唯一読み易さのための4ビットの境界にあるでしょう。 この仕様は噛み付いている整列に無関心です。
Use of the IPv6 aggregatable address format [AGGR] is assumed in the examples.
IPv6 aggregatableアドレス形式[AGGR]の使用は例で想定されます。
Crawford, et al. Standards Track [Page 8] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[8ページ]。
5.1. A6 Record Chains
5.1. A6はチェインズを記録します。
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.
サイトXに関する例を取ろう、マルチ、家へ帰り、2つの「中間的な」プロバイダーAとB.に、プロバイダーAがそれ自体である、マルチ、家へ帰り、2つの「トランジット」プロバイダーまで、そのC、D、およびEが同じトップレベルにすべて属すならプロバイダーBがトランジットサービスをただ一つのプロバイダー、E.Forの簡単さから得るCとD.は'2345'という識別子(形式接頭語を含んでいる)で(TLA)に集められます、そして、アルファー-TLA.ORGのTLA権威はそれぞれ次の平らな集合(NLA)接頭語2345: C、D、およびE00C0に以下を割り当てます:/28、2345: 00D0:、:/28と2345: 000E:、:/32.
C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to B.
CはNLA接頭語2345:00C1:CA00を割り当てます:、:A、Dへの/40は接頭語2345:00D2:DA00を割り当てます:、:Aへの/40とE案配2345: 000E: EB00:、:Bへの/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:
'Aは加入者識別11年をXに割り当てます、そして、'Bは加入者識別22年を割り当てます'。 その結果、サイトXは3つのアドレス接頭語を引き継ぎます:
o 2345:00C1:CA11::/48 from A, for routes through C. o 2345:00D2:DA11::/48 from A, for routes through D. o 2345:000E:EB22::/48 from B, for routes through E.
o 2345:00C1:CA11:、:ルートへのAからC.o2345:00D2:DA11の/48:、:D.o2345: 000E: ルートへのAからEB22の/48:、:ルートへのBからEの/48。
Let us suppose that N is a node in the site X, that it is assigned to subnet number 1 in this site, and that it uses the interface identifier '1234:5678:9ABC:DEF0'. In our configuration, this node will have three addresses:
NがサイトXのノードであり、それがこのサイトのサブネットNo.1に割り当てられて、'1234:5678:9ABC: DEF0'というインタフェース識別子を使用すると思いましょう。 私たちの構成では、このノードは3つのアドレスを持つでしょう:
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
o 2345:00C1:CA11: 0001:1234:5678:9ABC:DEF0o2345:00D2:DA11: 0001:1234:5678:9ABC:DEF0o、2345:000、E: 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がDNSにドメイン名X. EXAMPLEによって表されると思うつもりです、A、B、C、D、およびEはA. NET、B. NET、C. NET、D. NET、およびE. NETによって表されますが。 それぞれのこれらのドメインでは、私たちは、サブドメインが「対応する接頭語を保持する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.
$起源X.の例。 N A6 64:、:1234:5678:9ABC: DEF0サブネット-1.IP6サブネット1.IP6 A6、48、0:、0:0:1、:、: IP6 IP6 A6 48 0:、:0 加入者X.IP6.A.は網状になります。 IP6 A6 48 0:、:0 加入者X.IP6.B.は網状になります。
Crawford, et al. Standards Track [Page 9] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[9ページ]。
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.
加入者X.IP6.A.は網状になります。 A6 40 0:0:0011:、: A.NET.IP6.C.ネット。 加入者X.IP6.A.は網状になります。 A6 40 0:0:0011:、: A.NET.IP6.D.ネット。
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
加入者X.IP6.B.は網状になります。 A6 40 0:0:0022:、: B-NET.IP6.E.ネット。
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
A.NET.IP6.C.ネット。 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.ネット。 A6 28 0:0002:DA00:、: D.NET.ALPHA-TLA.ORG。
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
B-NET.IP6.E.ネット。 A6 32 0:0:EB00:、: E.NET.ALPHA-TLA.ORG。
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
C.NET.ALPHA-TLA.ORG。 A6 0 2345: 00C0:、: D.NET.ALPHA-TLA.ORG。 A6 0 2345: 00D0:、: E.NET.ALPHA-TLA.ORG。 A6 0 2345: 000E:、:
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のためのいくつかかすべてのDNSサーバが一般的であるようにあるとき、トップレベルゾーンEXAMPLEはDNSクライアントがそれらのネームサーバに達するのを可能にすることができるくらいの「接着剤」情報を運ばなければなりません。 これはちょうどIPv4のようにIPv6で本当です。 しかしながら、A6記録はいくつかの選択をDNS管理者に提供します。 接着剤はいずれであるかもしれませんも。
o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
o X. EXAMPLEゾーンからコピーされた、1人の極小集合に関する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の1セットは接頭語長さゼロで記録します。
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番目と共に1番目か2番目のオプションのどちらかを実行することによって、両方のベストと最悪を一緒に持っているかもしれません。 接着剤オプションを例証するには、インタフェース識別子を持っていて、X. EXAMPLEが2のネームサーバNS1.X. EXAMPLEとNS2.X. EXAMPLEによって役立たれていると仮定してください:、:そして、1:11:111:1111、:、:サブネット1と2に関する2:22:222:2222、それぞれ。 そして、トップレベルゾーンEXAMPLEは接着剤として以下のセットのA6記録の1つ(さらに)を含んでいるでしょう。
Crawford, et al. Standards Track [Page 10] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[10ページ]。
$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.
$起源の例。 ; 最初のオプション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 加入者X.IP6.A.は網状になります。 IP6.X A6 48 0:、:0 加入者X.IP6.B.は網状になります。
$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.
$起源の例。 ; 2番目のオプションX NS NS1.X NS NS2.X NS1.X A6 48:、:1:1:11:111:1111加入者X.IP6.A.は網状になります。 A6 48:、:1:1:11:111:1111加入者X.IP6.B.は網状になります。 NS2.X A6 48:、:2:2:22:222:2222加入者X.IP6.A.は網状になります。 A6 48:、:2:2:22:222:2222加入者X.IP6.B.は網状になります。
$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の1番目とオプションが番号を付け替えないように体力を要させる2番目の接着剤は、プロバイダーでA. NETとB. NETを前に置きますが、それらのプロバイダーの自身のDNSが手が届かないなら、失敗するでしょう。 3番目のオプションの接着剤記録はゾーンのEXAMPLEと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.
EXAMPLEゾーンが余分な接着剤、例えば1番目と3番目のオプションに関するA6記録の組合を含んでいると、通常の状況下で写しIPv6アドレスはDNSクライアントによって引き出されるでしょう。 しかし、それでも、プロバイダーDNSが失敗すると、無接頭語の長さの記録からアドレスを得るでしょう、EXAMPLEゾーンがX. EXAMPLEの番号を付け替えるところに後れを取るなら、DNSクライアントによって得られた半分のアドレスはまだ最新になっているでしょうが。
The zero-prefix-length glue records can of course be automatically generated and/or checked in practice.
もちろん無接頭語の長さの接着剤記録を自動的に発生する、そして/または、実際にはチェックできます。
Crawford, et al. Standards Track [Page 11] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[11ページ]。
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.
いくつかの多少任意の仮定が上の構造に反映されます。 以下の選択のすべてが異なって作られたかもしれません、便利に関するだれかの概念か2回のパーティーの間の協定通りに。
First, that site X has chosen to put subnet information in a
separate A6 record rather than incorporate it into each node's A6
records.
まず最初に、そのサイトXは、各ノードのA6記録にそれを組み入れるよりむしろ別々のA6記録にサブネット情報を入れるのを選びました。
Second, that site X is referred to as "SUBSCRIBER-X" by both of
its providers A and B.
2番目に、そのサイト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.
3番目に、どんな重要なビットも含んでいなくて、そのサイトXはIP6.X. EXAMPLEでのA6記録を通してプロバイダー情報を間接的に選びました。 代替手段は各プロバイダーのためのそれぞれのサブネット記録を模写するだろうことでした。
Fourth, B and E used a slightly different prefix naming convention
between themselves than did A, C and D. Each hierarchical pair of
network entities must arrange this naming between themselves.
4番目、B、およびEは自分たちの間のわずかにAと異なった接頭語命名規則を使用しました、C、ネットワーク実体のD.Each階層的な組は自分たちの間のこの命名を取りまとめなければなりません。
Fifth, that the upward prefix referral chain topped out at ALPHA-
TLA.ORG. There could have been another level which assigned the
TLA values and holds A6 records containing those bits.
5番目に、上向きの接頭語紹介が鎖を作るのがアルファーでTLA.ORGの完成を祝いました。 値をTLAに割り当てて、それらのビットを含むA6記録を保持する別のレベルがあったかもしれません。
Finally, the above structure reflects an assumption that address fields assigned by a given entity are recorded only in A6 records held by that entity. Those bits could be entered into A6 records in the lower-level entity's zone instead, thus:
最終的に、上の構造は与えられた実体によって割り当てられたアドレス・フィールドがその実体によって保持されたA6記録だけに記録されるという仮定を反映します。 代わりにこのようにして低レベル実体のゾーンでのA6記録にそれらのビットを入れることができました:
IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
IP6.X.の例。 A6 40 0:0:11:、: IP6.A.ネット。 IP6.X.の例。 A6 40 0:0:22:、: IP6.B.ネット。
IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
and so on.
IP6.A.ネット。 A6 28 0:1:CA00:、: IP6.C. NETなど。
Or the higher-level entities could hold both sorts of A6 records (with different DNS owner names) and allow the lower-level entities to choose either mode of A6 chaining. But the general principle of avoiding data duplication suggests that the proper place to store assigned values is with the entity that assigned them.
または、よりハイレベルの実体は、両方の種類に関するA6記録(異なったDNS所有者名がある)を保持して、低レベル実体がA6推論の方法を選ぶのを許容するかもしれません。 しかし、店への適所が値を割り当てたデータ複製が示す避けることの一般的な原則がそれらを割り当てた実体と共にあります。
It is possible, but not necessarily recommended, for a zone maintainer to forego the renumbering support afforded by the chaining of A6 records and to record entire IPv6 addresses within one zone file.
可能ですが、サポートがA6記録の推論で都合した番号を付け替えることに先立って、1個のゾーンファイルの中に全体のIPv6アドレスを記録するのは、ゾーン維持装置に、必ずお勧めであるというわけではありません。
Crawford, et al. Standards Track [Page 12] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[12ページ]。
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
Format Prefix(001)バイナリーとID0345、0678とのTLAsのアドレス空間課題と09ABがゾーンで維持されたと思うのがアルファー-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.
$起源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]で予約された8ビット反射するために各TLA IDに含まれています。
5.2.1. The TLA level
5.2.1. TLAレベル
ALPHA-TLA's assignments to network providers C, D and E are reflected in the reverse data as follows.
ネットワーク内の提供者C、D、およびEへのアルファー-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.
\[xC/4].IP6.ALPHA-TLA.ORG。 DNAME IP6.C.ネット。 \[xD/4].IP6.ALPHA-TLA.ORG。 DNAME IP6.D.ネット。 \[x0E/8].IP6.ALPHA-TLA.ORG。 DNAME IP6.E.ネット。
5.2.2. The ISP level
5.2.2. ISPレベル
The providers A through E carry the following delegation information in their zone files.
プロバイダーAからEはそれらのゾーンファイルの以下の代表団情報を運びます。
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
\[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
\[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
\[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
\[x1CA/12].IP6.C.ネット。 DNAME IP6.A.ネット。 \[x2DA/12].IP6.D.ネット。 DNAME IP6.A.ネット。 \[xEB/8].IP6.E.ネット。 DNAME IP6.B.ネット。 \[x11/8].IP6.A.ネット。 DNAME IP6.X.の例。 \[x22/8].IP6.B.ネット。 DNAME IP6.X.の例。
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.
いくつかのドメイン名が1つ以上のDNAME記録のRDATAに現れることに注意してください。 それらの場合では、1つのゾーンが、複数の接頭語を写像するのに使用されています。
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.
アドレスから名前への翻訳にIP6.X. EXAMPLEを使用して、顧客がX. EXAMPLEであると考えてください。 このドメインは現在、2つの異なったプロバイダーによって保持された2つの異なったDNAME記録によって参照をつけられます。
Crawford, et al. Standards Track [Page 13] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[13ページ]。
$ORIGIN IP6.X.EXAMPLE.
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
and so on.
$起源IP6.X.の例。 \[x0001/16]DNAME SUBNET-1\[x123456789ABCDEF0].SUBNET-1 PTR N. X. EXAMPLEなど。
SUBNET-1 need not have been named in a DNAME record; the subnet bits could have been joined with the interface identifier. But if subnets are treated alike in both the A6 records and in the reverse zone, it will always be possible to keep the forward and reverse definition data for each prefix in one zone.
SUBNET-1はDNAME記録で命名される必要はありませんでした。 サブネットビットはインタフェース識別子に接合されたかもしれません。 しかし、サブネットが両方のA6記録と逆のゾーンで同じく扱われると、1つのゾーンの各接頭語のためにフォワードを保って、定義データを逆にするのはいつも可能でしょう。
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):
DNAME記録が確かな状態で: 0001:1234:5678:9ABC:DEF0が獲得するアドレス2345:00C1:CA11のためのホスト名を探しているDNSレゾルバは、上で目立って、新しい質問を形成するでしょう。 IP6.ARPAのために過程知っているサーバを始めましたが、それが相談しなかったサーバが全く再帰を前提として、なにも他の役に立つ追加情報をキャッシュさせなかったと仮定する場合、質問された名前と応答の系列は(IN、QCLASSがあるすべて=QTYPE=PTR)でしょう:
To a server for IP6.ARPA: QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
IP6.ARPAのためのサーバに: QNAMEは\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPAと等しいです。
Answer:
\[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
以下に答えてください。 \[x234500/24].IP6.ARPA。 DNAME IP6.ALPHA-TLA.ORG。
To a server for IP6.ALPHA-TLA.ORG: QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
IP6.ALPHA-TLA.ORGのためのサーバに: QNAMEは\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORGと等しいです。
Answer:
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
以下に答えてください。 \[xC/4].IP6.ALPHA-TLA.ORG。 DNAME IP6.C.ネット。
To a server for IP6.C.NET.: QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
IP6.C. NETのためのサーバに: QNAMEは\[x1CA110001123456789ABCDEF0/100].IP6.C.ネットと等しいです。
Answer:
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
以下に答えてください。 \[x1CA/12].IP6.C.ネット。 DNAME IP6.A.ネット。
To a server for IP6.A.NET.: QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
IP6.A. NETのためのサーバに: QNAMEは\[x110001123456789ABCDEF0/88].IP6.A.ネットと等しいです。
Answer:
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
以下に答えてください。 \[x11/8].IP6.A.ネット。 DNAME IP6.X.の例。
To a server for IP6.X.EXAMPLE.: QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
IP6.X. EXAMPLEのためのサーバに: QNAMEは\[x0001123456789ABCDEF0/80].IP6.X.の例と等しいです。
Crawford, et al. Standards Track [Page 14] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[14ページ]。
Answer:
\[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
\[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
以下に答えてください。 \[x0001/16].IP6.X.の例。 DNAME、サブネット-1.IP6.X.、例 \[x123456789ABCDEF0/64].SUBNET-1.X.の例。 PTR N.X.の例。
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.
セクション5.1のイラストでは、階層的では、ネットワーク内の提供者や顧客などの隣接している実体は代表として派遣された接頭語(es)の定義を所有しているDNS名に同意しなければなりません。 1つの簡単なコンベンションはちょうどより高いことによって低レベル実体に割り当てられるビットを表すラベルを使用に少し結ぶことでしょう。 「例えば、「加入者X」を」 \[x11/8]に取り替えることができました。」 これは、まさに同じポイントでDNS木でその代表団に関連しているDNAME記録と代表として派遣された接頭語を定義しながら、A6記録を置くでしょう。 この簡素化の費用はそれが番号を付け替えられるとき、低レベルゾーンが上向きに指しているA6記録をアップデートしなければならないということです。 この費用が実際にはかなり許容できるのがわかるかもしれません。
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.
接頭語がA6記録と共に「上向きに代表として派遣された」とき、リソース記録がただ一つのIPv6アドレスを確立するのを必要としたDNSの数は何らかの重要な要素で増加します。 それらの記録は来ることのように通常なるでしょうが、必ずない、異なったDNSゾーン(すべての普通の理由で独自に失敗を経験できる)から来てください。 複数のIPv6アドレスを一緒に得るとき、RRカウントのこの増加は比例して少なくなるでしょう、そして、アドレスが位相的に群生しているなら、DNS回答の総サイズは減少さえするかもしれません。 しかし、記録はまだ容易に大きいRRset[DNSCLAR]を返すUDP応答で利用可能なスペースを例えば、MX、NS、またはSRV質問に超えているかもしれません。 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
DNS Security[DNSSEC]はDNSに本質的な問題であるキャッシュされたデータの信頼できることを記述しますが、異なったA6記録のために異なった署名チェーンについて確かめなければならないならかかわる接頭語代表団の数より大きいかもしれない要素はIPv6アドレスにこれを適用する費用に掛けられます。 信じられた集結されたキャッシュサーバ(同じくらい中[TSIG]と、例えば)が使用されているなら、この費用は合格水準に清算されるかもしれません。 1回の新しい現象がそうです。
Crawford, et al. Standards Track [Page 15] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[15ページ]。
the possibility that IPv6 addresses may be formed from a A6 records from a combination of secure and unsecured zones.
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.
接頭語代表団が1か2つのレベルに制限されるのは、A6記録で、より多くの展開経験をするまでお勧めです。 妥当な段階的に導入するメカニズムは、接頭語代表団(接頭語長さ0を持っているすべてのA6記録)から全く始まらないで、そして、ただ一つのゾーンの中をただ一つのレベルの代表団の使用に動くことになっているでしょう。 (「接頭語」A6記録の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.
A6記録を含むゾーンの管理者は容易に配備されたレゾルバを収容できます(A6記録ではなく、AAAA記録を理解しています)。 そのような管理者はIPv6アドレスにホスト名の解決をまねる工程でA6記録を所有しているゾーンの名前のすべてのためのAAAA記録の自動生成ができます(セクション3.1.4を見てください)。 その記録のIPv6アドレスを形成するのに使用されたA6記録のTTLsの最小限であるに違いない唯一の発生しているAAAA記録に割り当てられたTTLに注意を向けなければなりません。 AAAA記録が発生しているゾーンへの変化全くないときさえ、完全な丈夫さにおいて、異なったゾーンにあったそれらのA6記録は変化(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アドレス、質問が1であることで構成可能であるかもしれないA6とAAAAの注文に見えるときには面があってください: A6、当時のAAAA。 AAAA、当時のA6。 A6専用。 または、ともに平行です。 デフォルト順(そうでなければ、単に構成可能な状態で注文する)はA6 1番目、当時のAAAAを試みることでなければなりません。 AAAAが推奨しなくなると、新しいドキュメントはデフォルトを変えるでしょう。
The guidelines and options for precedence between IPv4 and IPv6 addresses are specified in [TRANS]. All mentions of AAAA records in that document are henceforth to be interpreted as meaning A6 and/or AAAA records in the order specified in the previous paragraph.
IPv4とIPv6アドレスの間の先行のためのガイドラインとオプションは[TRANS]で指定されます。 そのドキュメントにおける、AAAA記録のすべての言及はオーダーにおける意味A6、そして/または、AAAA記録が前のパラグラフで指定したように今後は解釈されることです。
Crawford, et al. Standards Track [Page 16] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[16ページ]。
6.2. Transition from Nibble Labels to Binary Labels
6.2. 少量ラベルから2進のラベルまでの変遷
Implementations conforming to RFC 1886 [AAAA] perform reverse lookups as follows:
RFC1886[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ドメインの名前が接尾語".IP6.INT"と共にドットで分離したので、IPv6アドレスは表されます。 少量の系列は逆順でコード化されます、すなわち、下位の少量が最初にコード化されます、次の下位の少量などがあとに続いていて。 各少量が16進数字によって表されます。 例えば、アドレス2345:00C1:CA11のための名前: セクション5.3の例の0001:1234:5678:9ABC:DEF0はDNS名の「0.f.e.直流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.
この仕様に従う実現はセクション3.2における指定されるとしてのIP6.ARPAで2進のラベルのルックアップを実行するでしょう。 過渡期実現のために、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.
IPv6アドレスを決定するA6記録のための調印権威[DNSSEC]はいくつかの実体の中で分配されます、そのアドレスが占領するアドレス空間の代表団経路を反映して。 DNS Securityはビット列ラベルとDNAME記録に完全に適切です。 そして、ちょうどIPv4のように、名前からアドレス・マッピングの検証は命名するアドレスマッピングの検証から論理的に独立しています。
With or without DNSSEC, the incomplete but non-empty address set scenario of section 3.1.4 could be caused by selective interference with DNS lookups. If in some situation this would be more harmful than complete DNS failure, it might be mitigated on the client side by refusing to act on an incomplete set, or on the server side by listing all addresses in A6 records with prefix length 0.
DNSSECのあるなしにかかわらず、セクション3.1.4の不完全な、しかし、非空のアドレスセットシナリオはDNSルックアップの選択的干渉で引き起こされる場合がありました。 何らかの状況で、これがDNSの故障を完成するより有害であるなら、それは不完全なセットに影響するのを拒否するのによるクライアント側の上、または、A6記録の接頭語長さ0があるすべてのアドレスを記載するのによるサーバ側の上で緩和されるかもしれません。
8. IANA Considerations
8. IANA問題
The A6 resource record has been assigned a Type value of 38.
38のType値をA6リソース記録に割り当ててあります。
Crawford, et al. Standards Track [Page 17] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[17ページ]。
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.
作者は貴重な議論とレビューについて以下の人々に感謝したがっています: ブライアン大工(デヴィッド・コンラッド)のアンドリュース、ロブAustein、ジムBound、ランディ・ブッシュ、スティーブ・デアリング、フランシス・デュポン、ロバートElz、ボブFink、Olafurグドムンソン、ボブ・ハレー、ボブHinden、エドワード・ルイス、ビル・マニング、キース・ムーア、トーマスNarten、エリックNordmark、マイク・オデル、マイケル・パットン、およびケン・パウエルを示してください。
10. References
10. 参照
[AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6, RFC 1886, December 1995.
[AAAA] トムソンとS.とC.Huitema、「1995年12月にIPバージョン6、RFC1886を支持するDNS Extensions。」
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[AARCH] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、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 Aggregatableのグローバルなユニキャストアドレス形式」、RFC2374、1998年7月。
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[BITLBL] クロフォード、M.、「ドメインネームシステムにおける2進のラベル」、RFC2673、1999年8月。
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[DNAME] クロフォード、M.、「非端末DNS名前リダイレクション」、RFC2672、1999年8月。
[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[DNSCLAR] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[DNSIS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[DNSIS]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
Security Extensions", RFC 2535, March 1999.
[DNSSEC]イーストレークとD.3番目とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KWORD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[RENUM1] 大工とB.とY.Rekhter、「番号を付け替えるのは仕事を必要とである」RFC1900、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.バーコウィッツ、「番号を付け替える概観をネットワークでつないでください」 「私はなぜそれととにかくそれであるものが欲しいでしょうか?」、RFC2071、1997年1月。
[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
[RENUM3] 大工とB.とクロウクロフトとJ.とY.Rekhter、「IPv4は今日ふるまいを記述する」RFC2101、1997年2月。
Crawford, et al. Standards Track [Page 18] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[18ページ]。
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[移-、]、ギリガン、R.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」RFC1933、4月1996日
[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.3番目、およびB.ウェリントン(「DNS(TSIG)のための秘密鍵取引認証」、RFC2845)は2000がそうするかもしれません。
11. Authors' Addresses
11. 作者のアドレス
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
バタビア、マットクロフォードフェルミ国立加速研究所MS368私書箱500イリノイ60510米国
Phone: +1 630 840-3461 EMail: crawdad@fnal.gov
以下に電話をしてください。 +1 630 840-3461 メールしてください: crawdad@fnal.gov
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: huitema@microsoft.com
メール: huitema@microsoft.com
Crawford, et al. Standards Track [Page 19] RFC 2874 IPv6 DNS July 2000
クロフォード、他 規格はIPv6 DNS2000年7月にRFC2874を追跡します[19ページ]。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Crawford, et al. Standards Track [Page 20]
クロフォード、他 標準化過程[20ページ]
一覧
スポンサーリンク
