[要約] RFC 5158は、6to4リバースDNS委任の仕様を定めたものであり、IPv6アドレスを逆引きするための手順を提供しています。目的は、6to4ネットワーク上のIPv6アドレスを正確に識別し、逆引き情報を提供することです。
Network Working Group G. Huston
Request for Comments: 5158 APNIC
Category: Informational March 2008
6to4 Reverse DNS Delegation Specification
6to4逆DNS委任仕様
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 IPv6アドレスのリバースルックアップを6to4リバースゾーンファイルに提供する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 'router'は、このグローバルプレフィックスと併せてIPv4アドレス値を使用して、ローカルIPv6サイトプレフィックスを作成できます。ローカル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]で述べたように、このアプローチの利点は、「エッジでのIPv6の展開（顧客サイトなど）の展開によるネットワーク（たとえば、インターネットサービスプロバイダーやISP）のコアによるIPv6の展開を分離していることです。各サイトまたはISPが独自の優先順位に応じて独自の時間枠でIPv6サポートを展開できるようにします。6to4を使用すると、1つ以上のISPがまだネイティブ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レコードはIPv4アドレス代表団を反映する必要があります。6to4の動機全体は、IPv6のインフラストラクチャ展開からのIPv6のサイト展開を分離することであるため、6to4を使用したサイトにはそのような記録が存在することは期待できません。あらゆる形で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.
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アドレスを使用しており、単一のアドレスが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オブジェクトを別の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ホストのセットとして構成された分離されたIPv6ネットワークと、ローカルIPv6ネットワークおよび外部IPv4ネットワークに接続されたデュアルスタック（IPv4および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：C000：201 :: /48 HEX表記法）
An example of a 6to4 network with addressing:
+-------------+
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.
この仕様では、2.0.0.2.IP6.ARPAゾーン（IP6.ARPAゾーンは[RFC3596]で指定されている）で単一の委任レベルを使用し、48ビット位置でのみゾーンを委任します。これは、単一 /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.
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.
このサービスは、Transport Layer Security（TLS）[RFC4346]を使用してWebベースのサーバーアクセスを使用して委任管理サービスを運用することです（「HTTPS：」URLを介してアクセス可能）。これは、Webサーバーの応答をプロキシキャッシュすることで、ソースアドレス駆動型の委任選択関数を確実に中断できないようにすることを目的としています。また、委任サービスを容易に模倣できないようにすることも目的です。
The service is to be found at 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.
このサービスはhttps://6to4.nro.netにあります。このサービスは、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ゾーンのRedelegationリクエストの数をスロットルする必要があります。
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.
o IPv4 DHCPベースの6to4サイト、または動的に割り当てられた外部IPv4インターフェイスアドレスを使用する6to4サイトは、動的に割り当てられたアドレスの以前のユーザーによって作成されたナンセンスの逆エントリを継承する可能性があります。この場合、クライアントサイトは、必要に応じてリバースゾーンの委任を要求できます。より一般的には、このコンテキストでの「古い」逆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採用の密度が、ネイティブIPv6サービスの広範な採用のための適切なドライバーを提供し、6to4サポートサービスの継続的なスケーリングの必要性を明らかにすることを想定しています。6to4逆委任ゾーンのサイズの上限の見積もりは、数百万のエントリのオーダーです。また、逆委任の価値は疑わしい提案であり、多くの展開環境には逆委任の形がないことにも注意してください。
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サイトは、6to4 IPv6リバースアドレスゾーンに最小1つのプライマリサーバーと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 RRSETを意味します。
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.
6to4逆DNS管理システムは、すべてのアクティブな代表団の定期的な掃引も行われているため、各委任は30日ごとにチェックされます。代表団がこの整合性に失敗した場合、電子メールの連絡先が問題を通知され、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サイトからの委任リクエストが、対応する6to4逆DNSドメインの委任のみを指示できるようにするために、初歩的なレベルの保証を提供します。
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.
Service Management Interfaceを使用すると、6to4クライアントがDNSサーバーとしてサーバー名を挿入することができ、潜在的に委任テストシステムに指名されたシステムにDNSクエリを作成するよう指示できます。サーバーは、単一のIPアドレスに作成されたリクエストの数を調整して、サーバーによって生成される大量の偽のDNSクエリのアテンダントリスクを軽減します。同様の理由で、サーバーは、単一の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.
セクション4は、ローカルサイト管理者が、6to4サイト内のクライアントが代表団の詳細に不正な変更を実行するのを防ぐために、適切なアクセス制御対策を講じることができることを指摘しています。これは、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.
著者は、キース・ムーアの以前の研究が、逆ゾーンの代表団と発見を引き受けるための多くの可能なアプローチを列挙した文書を準備したことを認めています。著者は、この文書の準備においてジョージ・マイケルソンとアンドレイ・ロバチェフスキーの支援を認めており、ピーター・コッホ、ペッカ・サヴォラ、ジュン・イチーロ・イトジュン・ハギノ、キャサリン・メドウズの有益なレビューコメントを求めています。
[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.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システム（DNSアップデート）の動的更新」、RFC 2136、1997年4月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS拡張機能IPバージョン6」、RFC 3596、2003年10月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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. Patel、「6to4のセキュリティ上の考慮事項」、RFC 3964、2004年12月。
Author's Address
著者の連絡先
Geoff Huston APNIC
Geoff Huston Apnic
EMail: gih@apnic.net
URI: http://www.apnic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。