Network Working Group G. Huston
Request for Comments: 5158 APNIC
Category: Informational March 2008
6to4 Reverse DNS Delegation Specification
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block.
このメモは、6to4逆ゾーンファイルへの6to4のIPv6アドレスの逆引き参照を提供DNSサーバーの委任を入力するためのサービスメカニズムを説明しています。メカニズムは、サービスクライアントが委任ドメインのDNSサーバーの数の詳細を入力することができ、従来のDNS委任サービス・インターフェースに基づいています。逆の6to4委任の文脈では、クライアントは、主に委譲リクエストに使用されるソースアドレスによって認証され、そのIPv6アドレスプレフィックスは、要求の6to4委任アドレスブロック内のアドレスに対応する場合に機能の使用を許可されています。
6to4 [RFC3056] defines a mechanism for allowing isolated IPv6 sites to communicate using IPv6 over the public IPv4 Internet. This is achieved through the use of a dedicated IPv6 global unicast address prefix. A 6to4 'router' can use its IPv4 address value in conjunction with this global prefix to create a local IPv6 site prefix. Local IPv6 hosts use this site prefix to form their local IPv6 address.
6to4 [RFC3056]は、単離されたIPv6サイトがパブリックIPv4インターネット上でIPv6を使用して通信することを可能にするための機構を定義します。これは、専用のIPv6グローバルユニキャストアドレスプレフィクスを使用することによって達成されます。 6to4の「ルータのローカルIPv6サイト接頭辞を作成するには、このグローバルプレフィックスと一緒にそのIPv4アドレスの値を使用することができます。ローカルIPv6ホストは、ローカルIPv6アドレスを形成するために、このサイトの接頭辞を使用しています。
This address structure allows any site that is connected to the IPv4 Internet the ability to use IPv6 via automatically created IPv6 over IPv4 tunnels. The advantage of this approach is that it allows the piecemeal deployment of IPv6 using tunnels to traverse IPv4 network segments. A local site can connect to an IPv6 network without necessarily obtaining IPv6 services from its adjacent upstream network provider.
このアドレス構造は、IPv4インターネットにIPv4トンネルの上に自動的に作成されたIPv6経由でIPv6を使用する能力を接続しているすべてのサイトを可能にします。このアプローチの利点は、IPv4ネットワークセグメントを横断するトンネルを用いたIPv6の断片的な展開を可能にすることです。ローカルサイトは、必ずしもそれに隣接する上流のネットワークプロバイダからIPv6サービスを取得することなく、IPv6ネットワークに接続することができます。
As noted in [6to4-dns], the advantage of this approach is that: "it decouples deployment of IPv6 by the core of the network (e.g. Internet Service Providers or ISPs) from deployment of IPv6 at the edges (e.g. customer sites), allowing each site or ISP to deploy IPv6 support in its own time frame according to its own priorities. With 6to4, the edges may communicate with one another using IPv6 even if one or more of their ISPs do not yet provide native IPv6 service."
[6to4の-DNS]で述べたように、このアプローチの利点は、ということである：それはネットワーク（例えば、インターネット・サービス・プロバイダやISPの）のコアでのIPv6の展開を切り離す」エッジ（例えば顧客サイト）でのIPv6の展開から、各サイトやISPは、自身の優先順位に従って、独自の時間枠でのIPv6サポートを展開することができます。6to4のでは、エッジは自分のISPの1つ以上がまだネイティブIPv6サービスを提供しない場合でも、IPv6を使用して互いに通信することができます。」
The particular question here is the task of setting up a set of delegations that allows "reverse lookups" for this address space.
ここでは特に質問はこのアドレス空間のために、「逆引き」を可能にする代表団のセットを設定する作業です。
"[This] requires that there be a delegation path for the IP address being queried, from the DNS root to the servers for the [DNS] zone which provides the PTR records for that IP address. For ordinary IPv6 addresses, the necessary DNS servers and records for IPv6 reverse lookups would be maintained by the each organization to which an address block is delegated; the delegation path of DNS records reflects the delegation of address blocks themselves. However, for IPv6 addresses beginning with the 6to4 address prefix, the DNS records would need to reflect IPv4 address delegation. Since the entire motivation of 6to4 is to decouple site deployment of IPv6 from infrastructure deployment of IPv6, such records cannot be expected to be present for a site using 6to4 - especially for a site whose ISP did not yet support IPv6 in any form." [6to4-dns]
「[これ]はそのIPアドレス用のPTRレコードを提供して、[DNS]ゾーンのサーバにDNSルートから、照会されるIPアドレスのための委任パスが存在している必要があります。通常のIPv6アドレスの場合は、必要に応じてDNSサーバをおよびIPv6の逆引き参照のレコードは、アドレスブロックが委任されている各団体によって維持されるだろう、DNSレコードの委任パスが自身のアドレスブロックの委任を反映しかし、6to4アドレスプレフィックスで始まるIPv6アドレスのために、DNSレコード。 。6to4の全体のモチベーションがIPv6のインフラストラクチャの展開からのIPv6のサイトの展開を切り離すことであるため、IPv4アドレスの委任を反映させる必要があるだろう、そのような記録は、6to4を使用してサイトに存在することが期待できない - 特にそのISPはまだなかったサイトのためにいかなる形でIPv6をサポートしています。」 【の6to4-DNS]
The desired characteristics of a reverse lookup delegation mechanism are that it:
逆引き委譲機構の所望の特性はそれということです。
* is deployable with minimal overhead or tool development
*最小のオーバーヘッドやツールの開発と展開可能です
* has no impact on existing DNS software and existing DNS operations
*既存のDNSソフトウェアと既存のDNSの運用に影響はありません
* performs name lookup efficiently
*効率的に名前のルックアップを実行
* does not compromise any DNS security functions
*任意のDNSのセキュリティ機能を損ないません
There are a number of approaches to this problem, ranging from a conventional explicit delegation structure to various forms of modified server behaviors that attempt to guess the location of non-delegated servers for fragments of this address space. These approaches have been explored in some detail in terms of their advantages and drawbacks in [6to4-dns], so only a summary of these approaches will be provided here.
従来の明示的な委任構造から、このアドレス空間の断片のための非委任サーバーの場所を推測しようと修正サーバービヘイビアの様々な形に至るまで、この問題へのアプローチの数があります。これらのアプローチはとてもこれらのアプローチの概要のみがここで提供され、[6to4の-DNS]で、それぞれの長所と短所の面でいくつかの詳細に検討されています。
The problem with this form of delegation is the anticipated piecemeal deployment of 6to4 sites. The reason why an end site would use 6to4 is commonly that the upstream Internet Service Provider does not support an IPv6 transit service and the end site is using 6to4 to tunnel through to IPv6 connectivity. A conventional end site environment of this form would have the end site using provider-based IPv4 addresses, where the end site's IPv4 address is a more specific address block drawn from the upstream provider's address block, and the end site would have an entry in the upstream provider's reverse DNS zone file, or it would have authoritative local name servers that are delegated from the upstream provider's DNS zone. In the case of the 6to4 mapped IPv6 space, the upstream may not be providing any IPv6-based services at all, and therefore would not be expected to have a 6to4 reverse DNS delegation for its IPv4 address block. The general observation is that 6to4 IPv6 reverse DNS delegations cannot necessarily always precisely match the corresponding IPv4 reverse DNS delegations.
代表団のこの形式の問題は、6to4サイトの予想断片的な展開です。エンドサイトは6to4のを使用する理由は、上流のインターネットサービスプロバイダがIPv6トランジットサービスをサポートしていませんし、エンドサイトがIPv6接続に至るトンネルに6to4のを使用していることが一般的です。この形式の従来のエンドサイト環境は、エンドサイトのIPv4アドレスは、上流プロバイダのアドレスブロックから引き出された複数の特定のアドレスブロックであり、エンドサイトはのエントリを持つことになり、プロバイダベースのIPv4アドレスを使用して、エンドサイトを有するであろう上流プロバイダの逆引きDNSゾーンファイル、またはそれは、上流プロバイダのDNSゾーンから委任される権威あるローカルネームサーバを持っているでしょう。 6to4の場合には、IPv6の空間をマッピングし、上流側には、全く任意のIPv6ベースのサービスを提供しなくてもよいため、そのIPv4アドレスブロックのDNS委任を逆の6to4有することが期待されないであろう。一般的な観察は、6to4 IPv6の逆引きDNS委譲は必ずしも常に正確に対応したIPv4がDNS委任を逆一致しないことです。
Sub-delegations of IPv4 provider address space are not consistently recorded, and any 6to4 reverse zone operator would be required to undertake reverse zone delegations in the absence of reliable current address assignment information, undertaking a "hop over" of the upstream provider's address block. Similarly, a delegated entity may need to support the same "hop over" when undertaking further delegations in their reverse zone.
IPv4のプロバイダのアドレス空間のサブ委任は一貫記録されない、任意の6to4逆ゾーンオペレータは、上流プロバイダのアドレスブロックの「オーバーホップ」引き受け、信頼性の高い現在のアドレス割当情報の不在下で逆ゾーンの委任を行うために必要とされるであろう。同様に、委任されたエンティティは、その逆ゾーンにさらに委任を行ったときに同じことが「オーバーホップ」をサポートする必要があるかもしれません。
One way to avoid such unreliable delegations is to alter server behavior for reverse servers in this zone. Where no explicit delegation information exists in the zone file, the server could look up the in-addr.arpa domain for the servers for the equivalent IPv4 address root used in the 6to4 address. These servers could then be queried for the IPv6 PTR query.
そのような信頼性のない委任を回避する1つの方法は、このゾーンの逆サーバのサーバ動作を変更することです。明示的な委任情報は、ゾーンファイルに存在しない場合は、サーバーは、6to4アドレスで使用される同等のIPv4アドレスのルートのためのサーバ用のin-addr.arpaドメインを調べることができます。これらのサーバは、IPv6のPTRクエリを照会することができます。
The issues with fielding altered server behaviors for this domain are not to be taken lightly, and the delegation chain for IPv4 will not be the same for 6to4 in any case. An isolated 6to4 site uses a single IPv4 /32 address, and it is improbable that a single address would have explicit in-addr.arpa delegation. In other words, it is not likely that the delegation for IPv4 would parallel that of 6to4.
このドメインの変更されたサーバービヘイビアを守備に問題を軽視してはならない、とIPv4のための委任チェーンは、どのような場合に6to4のために同じにはなりません。孤立した6to4サイトでは、単一のIPv4 / 32アドレスを使用し、単一のアドレスは、明示的なin-addr.arpa委任を持っているということありそうです。言い換えれば、IPv4の代表団はの6to4のことを平行しまう可能性が高いではありません。
Another approach uses an altered server to resolve non-delegated 6to4 reverse queries. The 6to4 query is decoded to recover the original 6to4 IP address. The site-specific part of the address is rewritten to a constant value, and this value is used as the target of a lookup query. This requires that a 6to4 site should reserve local addresses, and configure reverse servers on these addresses. Again, this is a weak approach in that getting the DNS to query non-delegated addresses is a case of generation of spurious traffic.
別のアプローチは、クエリを逆6to4の非委任解決するために変更されたサーバーを使用しています。 6to4のクエリは、元の6to4 IPアドレスを回復するためにデコードされます。アドレスのサイト固有の部分が一定値に書き換えられ、この値は、ルックアップクエリのターゲットとして使用されています。これは6to4サイトがローカルアドレスを予約し、これらのアドレスに逆サーバを設定する必要があることが必要です。繰り返しますが、これは非委任アドレスを照会するDNSを得るという点で弱いアプローチは、不正なトラフィックが発生した場合です。
The final approach considered here is to synthesize an answer when no explicit delegation exists. This approach would construct a pseudo host name using the IPv6 query address as the seed. Given that the host name has no valid forward DNS mapping, then this becomes a case of transforming one invalid DNS object into another.
ここで考え、最終的なアプローチは、明示的な代表団が存在しない場合、答えを合成することです。このアプローチは、シードとしてのIPv6クエリーアドレスを使用して、擬似ホスト名を構築します。ホスト名が有効な前方DNSマッピングを持っていないことを考えると、これは別のものに1つの無効DNSオブジェクトを変換する場合になります。
It would appear that the most reasonable approach from this set of potential candidates is to support a model of conventional standard delegation. The consequent task is to reduce the administrative overheads in managing the zone, supporting delegation of reverse zone files on a basis of providing a delegation capability directly to each 6to4 site.
潜在的な候補のセットから最も合理的なアプローチは、従来の標準委任のモデルをサポートすることであるように思われます。その結果としてのタスクは、ゾーンを管理し、各6to4サイトに直接委任機能を提供するに基づいて逆ゾーンファイルの委任をサポートするには、管理オーバーヘッドを削減することです。
A 6to4 client network is an isolated IPv6 network composed as a set of IPv6 hosts and a dual stack (IPv4 and IPv6) local router connected to the local IPv6 network and the external IPv4 network.
6to4のクライアントネットワークは、ローカルIPv6ネットワークと外部のIPv4ネットワークに接続されたIPv6ホストのセットとデュアルスタック（IPv4とIPv6）ローカルルータとして構成される単離されたIPv6ネットワークです。
An example of a 6to4 network is as follows:
以下の通りの6to4ネットワークの一例です。
+-------------+
IPv6-in-IPv4 packets (A)| | IPv6 packets
------------------------| 6to4router |--------------------------
| | | | | | |
+-------------+ local IPv6 clients
IPv4 network IPv6 network
IPv4のネットワークのIPv6ネットワーク
Figure 1
図1
The IPv4 address used as part of the generation of 6to4 addresses for the local IPv6 network is that of the external IPv4 network interface address (labelled '(A)' in the above diagram). For example, if the interface (A) has the IPv4 address 192.0.2.1, then the local IPv6 clients will use a common IPv6 address prefix of the form 2002: {192.0.2.1}::/48 (or (2002:C000:201::/48 in hex notation). All the local IPv6 clients share this common /48 address prefix, irrespective of any local IPv4 address that such host may use if they are operating in a dual stack mode.
ローカルIPv6ネットワークのための6to4アドレスの生成の一部として使用されるIPv4アドレスは、外部のIPv4ネットワークインタフェースアドレス（上の図中の標識「（A）」）のことです。インターフェース（A）はIPv4アドレス192.0.2.1を有する場合、例えば、ローカルのIPv6クライアント2002形式の共通IPv6アドレスプレフィックスを使用する：{192.0.2.1} :: / 48（又は（2002：C000： 16進表記で201 :: / 48）。すべてのローカルIPv6クライアントに関係なく、それらがデュアルスタックモードで動作している場合、ホストが使用することができる任意のローカルIPv4アドレスの、この共通/ 48アドレスプレフィックスを共有します。
An example of a 6to4 network with addressing:
アドレス指定の6to4ネットワークの例：
+-------------+
IPv4 network (A)| | IPv6 network
-------------------| 6to4router |-------------
192.0.2.1| | | | | interface identifier
+-------------+ 1A | | local IPv6 address
2002:C000:201::1A
| |
1B |
2002:C000:201::1B
|
1C
2002:C000:201::1C
Figure 2
図2
This specification uses a single delegation level in the 2.0.0.2.ip6.arpa zone (the ip6.arpa zone is specified in [RFC3596]), delegating zones only at the 48th bit position. This corresponds with individual delegations related to a single /32 IPv4 address, or the equivalent of a single 6to4 local site.
この仕様は、48番目のビット位置にゾーンを委任、2.0.0.2.ip6.arpaゾーン内の単一の委任レベル（ip6.arpaゾーンは[RFC3596]で指定されている）を使用します。これは、単一の/ 32のIPv4アドレス、または単一の6to4ローカルサイトの同等に関連する個々の委任に対応します。
The zone files containing the end site delegations are to be operated with a low TTL (configured to be a time value in the scale of hours rather than days or weeks), and updates for delegation requests in the 2.0.0.2.ipv6.arpa zone are to be made using dynamic DNS updates [RFC2136].
エンドサイト委任を含むゾーンファイルは低いTTL（時間ではなく、数日または数週間の規模で時間値になるように構成）、および2.0.0.2.ipv6.arpaゾーンの委任リクエストのためのアップデートで動作することがありますダイナミックDNSアップデート[RFC2136]を使用して作製されます。
The delegation system is to be self-driven by clients residing within 6to4 networks. The 6to4 reverse DNS delegation function is to be accessible only by clients using 6to4 IPv6 source addresses, and the only delegation that can be managed is that corresponding to the /48 prefix of the IPv6 source address of the client.
委任システムは、自己駆動の6to4ネットワーク内に存在するクライアントであることをです。 6to4の逆引きDNS委任機能は、6to4のIPv6送信元アドレスを使用してクライアントがアクセスできるようにし、管理することができる唯一の代表団は、クライアントのIPv6送信元アドレスの/ 48プレフィックスに対応するということです。
This service is to operate the delegation management service using web-based server access using Transport Layer Security (TLS) [RFC4346] (accessible via a "https:" URL). This is intended to ensure that the source address-driven delegation selection function cannot be disrupted through proxy caching of the web server's responses, and also to ensure that the delegation service cannot be readily mimicked.
このサービスは、トランスポート層セキュリティ（TLS）[RFC4346]（「HTTPS：」URLを介してアクセス）を使用して、Webベースのサーバーへのアクセスを使用して、委任管理サービスを動作させることです。これは、送信元アドレス駆動の委譲選択機能は、Webサーバの応答のプロキシキャッシングによって中断することができず、また、委任サービスが容易に模倣できないことを保証するためにことを保証することを意図しています。
The service is to be found at https://6to4.nro.net
サービスはhttps://6to4.nro.netで発見されます
This service is implemented by web servers that are operated on a dual-stack IPv4 / IPv6 server, accessible via SSL. The web server's actions will be determined by the source address of the client. If the client uses a 6to4 source address, the server will present a delegation interface for the corresponding 6to4 reverse zone. Otherwise, the server will provide a description of the delegation process.
このサービスは、SSLを介してアクセスできるデュアルスタックIPv4 / IPv6サーバー上で動作しているWebサーバによって実装されます。 Webサーバの動作は、クライアントの送信元アドレスによって決定されます。クライアントは6to4の送信元アドレスを使用している場合、サーバは、対応する6to4の逆ゾーンの委任インタフェースを提示します。そうしないと、サーバは委任プロセスの説明を提供します。
When accessed by a 6to4 source address, the interface presented by the delegation service is a conventional DNS delegation interface, allowing the client to enter the details of a number of DNS servers for the corresponding reverse domain. The targets of the DNS delegation are checked by the delegation manager using IPv4 and IPv6, according to the addresses of the targets, to ensure that they are responding, that they are configured consistently, and are authoritative for the delegated domain. If these conditions are met, the delegation details are entered into the zone at the primary master. In order to avoid the server being used as a denial of service platform, the server should throttle the number of DNS delegation requests made to any single IP address, and also throttle the number of redelegation requests for any single 6to4 zone.
6to4の送信元アドレスでアクセスすると、委任サービスによって提示されたインタフェースは、クライアントが対応する逆のドメインのDNSサーバーの数の詳細を入力することができ、従来のDNS委任インタフェースです。 DNS委任のターゲットは、彼らが一貫して構成されていることを、彼らは応答していることを保証するために、ターゲットのアドレスに応じて、IPv4とIPv6を使用して、委任管理者によって確認され、委任ドメインに対して権限のあるされています。これらの条件が満たされている場合、委任の詳細は、プライマリマスターでゾーンに入っています。サービスプラットフォームの拒否として使用されているサーバーを避けるために、サーバーは、任意の単一のIPアドレスに対して行われたDNS委任、要求の数を制限し、また、任意の単一の6to4ゾーンの再委任要求の数を絞る必要があります。
In other cases the system provides diagnostic information to the client.
他の例では、システムはクライアントに診断情報を提供します。
The benefits of this structure include a fully automated mode of operation. The service delivery is on demand and the system only permits self-operation of the delegation function.
この構造の利点は、操作の完全自動化モードを含みます。サービスの提供は、オンデマンドであり、システムは唯一の委任機能の自己操作が可能になります。
The potential issues with this structure include:
このような構造を持つ潜在的な問題は、次のとおりです。
o Clients inside a 6to4 site could alter the delegation details without the knowledge of the site administrator. It is noted that this is intended for small-scale sites. Where there are potential issues of unauthorized access to this delegation function, the local site administrator could take appropriate access control measures.
O 6to4サイト内のクライアントは、サイト管理者の知識がなくても、委任内容を変更することができます。これは小規模なサイトのために意図されることに留意されたいです。この委任機能への不正アクセスの潜在的な問題がある場合、ローカルサイトの管理者は、適切なアクセス制御対策を取ることができます。
o IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses dynamically-assigned external IPv4 interface addresses, could inherit nonsense reverse entries created by previous users of the dynamically assigned address. In this case, the client site could request delegation of the reverse zone as required. More generally, given the potentially for inheritance of 'stale' reverse DNS information in this context, in those cases where the issues of potential inheritance of 'stale' reverse DNS information is a concern, it is recommended that a 6to4 site either use a static IPv4 address in preference to a dynamically-assigned address, or ensure that the reverse delegation information is updated using the service mechanism described here upon each dynamic address assignment event.
IPv4のDHCPベースの6to4サイト、または動的に割り当てられた外部IPv4インタフェースのアドレスを使用するすべての6to4サイトO、動的に割り当てられたアドレスの前のユーザーが作成したナンセンス逆エントリを継承することができます。この場合、必要に応じ、クライアントサイトは、逆ゾーンの委任を要求することができます。より一般的には、潜在的にこの文脈で「古い」逆DNS情報の継承のために与えられた、「古くなった」逆DNS情報の潜在的な継承の問題が懸念されるような場合には、6to4サイトが静的を使用することを推奨します動的に割り当てられたアドレスに優先してIPv4アドレス、または逆委任情報は、各動的アドレス割当イベントの際に、ここで記述されたサービス・メカニズムを使用して更新されていることを確認します。
o The approach does not scale efficiently, as there is the potential that the flat zone file may grow considerably. However, it is noted that 6to4 is intended to be a transition mechanism useful for a limited period of time in a limited context of an isolated network where other forms of a tunnelled connection is not feasible. It is envisaged that at some point the density of IPv6 adoption in stub network would provide adequate drivers for widespread adoption of native IPv6 services, obviating the need for continued scaling of 6to4 support services. An estimate of the upper bound of the size of the 6to4 reverse delegation zone would be of the order of millions of entries. It is also noted that the value of a reverse delegation is a questionable proposition and many deployment environments have no form of reverse delegation.
フラットゾーンファイルが大幅に成長するという可能性があるとして、Oのアプローチは、効率的に拡張しません。しかし、6to4のがトンネル接続の他の形態が実現可能でない孤立したネットワークの限られた状況において、限られた期間のために有用な遷移機構であることを意図していることに留意されたいです。いくつかの点でスタブネットワークにおけるIPv6の採用の密度は、6to4のサポートサービスの継続的なスケーリングの必要性をなくす、ネイティブのIPv6サービスの普及のための適切なドライバを提供することが想定されています。 6to4の逆引きゾーンのサイズの上限の推定値は、エントリ数百万のオーダーであろう。また、逆引きの値は疑問の命題であり、多くのデプロイメント環境は、逆引きのno形式を持っていないことに留意されたいです。
o It is also conceivable that an enterprise network could decide to use 6to4 internally in some form of private context, with the hosts only visible in internal DNS servers. In this mechanism the reverse delegation, if desired, would need to be implemented in an internal private (non-delegated) corresponding zone of the 6to4 reverse domain space.
Oまた、企業ネットワークが内部DNSサーバーでのみ表示ホストで、プライベートコンテキストのいくつかの形式で内部の6to4を使用することを決定したことが考えられます。この機構では逆引き、所望であれば、6to4の逆ドメイン空間の内部（非委任）プライベート対応するゾーン内に実装される必要があるであろう。
There may be circumstances where an IPv4 address controller wishes to "block" the ability for users of these addresses to use this 6to4 scheme. Scenarios that would motivate this concern would include situations when the IPv4 provider is also offering an IPv6 service, and native IPv6 should be deployed instead of 6to4. In such circumstances the 6to4 reverse zone operator should allow for such a 6to4 reverse delegation blocking function upon application to the delegation zone operator.
IPv4アドレスコントローラは、「ブロック」は、これらのアドレスのユーザーがこの6to4の方式を使用するための能力を望む状況があるかもしれません。 IPv4のプロバイダはまた、IPv6サービスを提供しており、ネイティブのIPv6が代わりの6to4で展開する必要があるときは、この懸念を動機となるシナリオは、状況が含まれます。そのような状況での6to4逆ゾーンオペレータは委任ゾーンオペレータに適用時にそのような6to4の逆委任ブロッキング機能を可能にすべきです。
For a delegation to be undertaken the following conditions should hold:
代表団が着手されるようにするには、以下の条件を保持する必要があります：
o The 6to4 site must have configured a minimum of one primary and one secondary server for the 6to4 IPv6 reverse address zone.
O 6to4サイトは、1つのプライマリとアドレスゾーンを逆にIPv6の6to4のための1台のセカンダリサーバの最小値を設定しておく必要があります。
o At the time of the delegation request, the primary and secondary servers must be online, reachable, correctly configured, and in a mutually consistent state with respect to the 6to4 reverse zone. In this context, "mutually consistent" implies the same SOA RR and identical NS RRSets.
委任要求時のoは、プライマリサーバとセカンダリサーバが到達可能な、正しく設定、および6to4の逆引きゾーンに関して相互に整合性のある状態では、オンラインである必要があります。この文脈において、「互いに一致」同じSOAのRRと同じNS資源レコード集合を意味しています。
o The 6to4 reverse delegation service will only accept delegation requests associated with the 6to4 source address of the requesting client.
O 6to4の逆引きサービスは要求しているクライアントの6to4の送信元アドレスに関連付けられている委譲要求を受け入れます。
The approach described here, of a fully automated system driven by the site administrators of the 6to4 client networks, appears to represent an appropriate match of the operational requirements of managing reverse DNS domains for 6to4 addresses.
6to4のクライアント・ネットワークのサイトの管理者によって駆動完全に自動化されたシステムで、ここで説明するアプローチは、6to4のアドレスに対して逆DNSドメインを管理する運用要件の適切なマッチングを表すために表示されます。
For maintenance of the reverse delegation zones the service maintains an email contact point for each active delegation, derived from the zone's SOA contact address (SOA RNAME), or explicitly entered in the delegation interface. This contact point would be informed upon any subsequent change of delegation details.
逆引きゾーンのメンテナンスのためサービスは、ゾーンのSOAコンタクトアドレス（SOA RNAME）に由来する、または明示的に委任インタフェースに入力された各アクティブ委譲のための電子メールの接触点を、維持します。この接触点は、委任の詳細のいずれかのその後の変更時に通知されるだろう。
The 6to4 reverse DNS management system also undertakes a periodic sweep of all active delegations, so that each delegation is checked every 30 days. If the delegation fails this integrity check the email contact point is informed of the problem, and a further check is scheduled for 14 days later. If this second check fails, the delegation is automatically removed, and a further notice is issued to the contact point.
各代表団が30日ごとにチェックされているように、6to4のリバースDNS管理システムはまた、すべてのアクティブな代表団の定期的なスイープを行っています。代表団が失敗した場合、この整合性は、電子メールの接触点が問題が通知され確認し、さらにチェックが14日後に予定されています。この第2のチェックが失敗した場合は、委任が自動的に削除され、さらに通知が接点に発行されます。
This system offers a rudimentary level of assurance in attempting to ensure that delegation requests from a 6to4 site can only direct the delegation of the corresponding 6to4 reverse DNS domain and no other.
このシステムは、対応する6to4のリバースDNSドメインなしその他の委任を指示することができ、6to4サイトからの委任リクエストを確保しようとして保証の初歩的なレベルを提供しています。
Address-based authentication is not a very robust method from a security perspective, as addresses can be readily spoofed. Accordingly, reverse delegation information does not provide reliable information in either validating a domain name or in validating an IP address, and no conclusions should be drawn from the presence or otherwise of a reverse DNS mapping for any IP address.
アドレスは容易に詐称することができますように、アドレスベースの認証は、セキュリティの観点から非常に堅牢な方法ではありません。したがって、いずれかのドメイン名の検証中またはIPアドレスの確認で信頼性の高い情報を提供しない委任情報を逆にし、何の結論は、任意のIPアドレスの逆引きDNSマッピングが存在するか、そうでないから引き出されるべきではありません。
The service management interface allows a 6to4 client to insert any server name as a DNS server, potentially directing the delegation test system to make a DNS query to any nominated system. The server throttles the number of requests made to any single IP address to mitigate the attendant risk of a high volume of bogus DNS queries being generated by the server. For similar reasons, the server also throttles the number of redelegation requests for any single 6to4 zone.
サービス管理インターフェースは、6to4クライアントが潜在的に任意の指名システムにDNSクエリを作るために委任テストシステムを向ける、DNSサーバとして任意のサーバー名を挿入することができます。サーバは、サーバによって生成された偽のDNSクエリの高いボリュームの付帯リスクを軽減するために、任意の単一のIPアドレスに対して行われた要求の数を絞ります。同様の理由で、サーバーは、任意の単一の6to4ゾーンの再委任要求の数を絞ります。
For a general threat analysis of 6to4, especially the additional risk of address spoofing in 2002::/16, see [RFC3964].
6to4のの一般的な脅威分析、2002 :: / 16のアドレススプーフィングの特に追加的なリスクについては、[RFC3964]を参照してください。
Section 4 notes that the local site administrator could take appropriate access control measures to prevent clients inside a 6to4 site performing unauthorized changes to the delegation details. This may be in the form of a firewall configuration, regarding control of access to the service from the interior of a 6to4 site, or a similar mechanism that enforces local access policies.
ローカルサイトの管理者は、委任の詳細への不正な変更を行っ6to4サイト内のクライアントを防止するための適切なアクセス制御対策を取ることができる第4節のノート。これは6to4サイトの内部、またはローカルアクセスポリシーを強制する同様のメカニズムからのサービスへのアクセスの制御については、ファイアウォール設定の形態であってもよいです。
The IANA has delegated the 2.0.0.2.ip6.arpa domain according to delegation instructions provided by the Internet Architecture Board.
IANAは、インターネットアーキテクチャ委員会が提供する委任指示に従って2.0.0.2.ip6.arpaドメインを委任しています。
The author acknowledges the prior work of Keith Moore in preparing a document that enumerated a number of possible approaches to undertake the delegation and discovery of reverse zones. The author acknowledges the assistance of George Michaelson and Andrei Robachevsky in preparing this document, and Peter Koch, Pekka Savola, Jun-ichiro Itojun Hagino, and Catherine Meadows for their helpful review comments.
著者は委任と逆ゾーンの発見に着手する可能なアプローチの数を列挙した文書を作成するにはキース・ムーアの前の仕事を認めています。著者は、この文書を作成するにはジョージ・マイケルソンとアンドレイRobachevskyの支援を認識し、その有用レビューコメントについてピーター・コッホ、ペッカSavola、6月-一郎いとぢゅん萩野、そしてキャサリンメドウズ。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[6to4-dns] Moore, K., "6to4 and DNS", Work in Progress, April 2003.
[6to4の-DNS]ムーア、K.、 "6to4のとDNS"、進歩、2003年4月の作業。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P.とC.パテル、 "6to4のためのセキュリティの考慮事項"、RFC 3964、2004年12月。
Author's Address
著者のアドレス
Geoff Huston APNIC
ジェフ・ヒューストンAPNIC
EMail: gih@apnic.net URI: http://www.apnic.net
電子メール：gih@apnic.net URI：http://www.apnic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。