[要約] 要約：RFC 4339は、IPv6ホストのDNSサーバー情報の設定方法についてのガイドラインです。 目的：IPv6ホストが正しくDNSサーバーに接続できるようにするための設定アプローチを提供することを目的としています。
Network Working Group J. Jeong, Ed.
Request for Comments: 4339 ETRI/University of Minnesota
Category: Informational February 2006
IPv6 Host Configuration of DNS Server Information Approaches
DNSサーバー情報アプローチのIPv6ホスト構成
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
IESG Note
IESGノート
This document describes three different approaches for the configuration of DNS name resolution server information in IPv6 hosts.
このドキュメントでは、IPv6ホストのDNS名解像度サーバー情報の構成に関する3つの異なるアプローチについて説明します。
There is not an IETF consensus on which approach is preferred. The analysis in this document was developed by the proponents for each approach and does not represent an IETF consensus.
どのアプローチが優先されるかについてのIETFコンセンサスはありません。このドキュメントの分析は、各アプローチの支持者によって開発され、IETFコンセンサスを表していません。
The 'RA option' and 'Well-known anycast' approaches described in this document are not standardized. Consequently the analysis for these approaches might not be completely applicable to any specific proposal that might be proposed in the future.
このドキュメントで説明されている「RAオプション」および「有名なAnycast」アプローチは標準化されていません。したがって、これらのアプローチの分析は、将来提案される可能性のある特定の提案に完全に適用できない可能性があります。
Abstract
概要
This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution.
このドキュメントでは、IPv6の再帰DNSサーバーアドレス構成の3つのアプローチについて説明します。RAオプション、DHCPV6オプション、および再帰的なDNSサーバーの有名なAnycastアドレスの3つのソリューションの運用属性について詳しく説明しています。さらに、マルチソリューション解像度を考慮して、4種類のネットワーク（ISP、エンタープライズ、3GPP、および管理されていないネットワーク）の展開シナリオを示唆しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. IPv6 DNS Configuration Approaches ...............................3
3.1. RA Option ..................................................3
3.1.1. Advantages ..........................................4
3.1.2. Disadvantages .......................................5
3.1.3. Observations ........................................5
3.2. DHCPv6 Option ..............................................6
3.2.1. Advantages ..........................................7
3.2.2. Disadvantages .......................................8
3.2.3. Observations ........................................9
3.3. Well-known Anycast Addresses ...............................9
3.3.1. Advantages .........................................10
3.3.2. Disadvantages ......................................10
3.3.3. Observations .......................................10
4. Interworking among IPv6 DNS Configuration Approaches ...........11
5. Deployment Scenarios ...........................................12
5.1. ISP Network ...............................................12
5.1.1. RA Option Approach .................................13
5.1.2. DHCPv6 Option Approach .............................13
5.1.3. Well-known Anycast Addresses Approach ..............14
5.2. Enterprise Network ........................................14
5.3. 3GPP Network ..............................................15
5.3.1. Currently Available Mechanisms and
Recommendations ....................................15
5.3.2. RA Extension .......................................16
5.3.3. Stateless DHCPv6 ...................................16
5.3.4. Well-known Addresses ...............................17
5.3.5. Recommendations ....................................18
5.4. Unmanaged Network .........................................18
5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18
5.4.2. Case B: A Dual-stack Gateway Connected to a
Dual-stack ISP .....................................19
5.4.3. Case C: A Dual-stack Gateway Connected to
an IPv4-only ISP ...................................19
5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19
6. Security Considerations ........................................19
6.1. RA Option .................................................20
6.2. DHCPv6 Option .............................................21
6.3. Well-known Anycast Addresses ..............................21
7. Contributors ...................................................21
8. Acknowledgements ...............................................23
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................23
Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address Autoconfiguration provide ways to configure either fixed or mobile nodes with one or more IPv6 addresses, default routes, and some other parameters [1][2]. To support the access to additional services in the Internet that are identified by a DNS name, such as a web server, the configuration of at least one recursive DNS server is also needed for DNS name resolution.
IPバージョン6およびIPv6 StatelessアドレスのNeighbor Discovery（ND）Autoconfigurationは、1つ以上のIPv6アドレス、デフォルトルート、およびその他のパラメーター[1] [2]で固定またはモバイルノードを構成する方法を提供します。WebサーバーなどのDNS名で識別されるインターネット内の追加サービスへのアクセスをサポートするために、DNS名の解像度には少なくとも1つの再帰DNSサーバーの構成も必要です。
This document describes three approaches of recursive DNS server address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6 option [3]-[5], and (c) well-known anycast addresses for recursive DNS servers [7]. Also, it suggests the applicable scenarios for four kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP network, and (d) unmanaged network.
このドキュメントでは、IPv6ホストの再帰的DNSサーバーアドレス構成の3つのアプローチについて説明します：（a）RAオプション[6]、（b）DHCPV6オプション[3] - [5]、および（c）再帰的なDNSサーバーのよく知られているAnycastアドレス[7]。また、4種類のネットワークに該当するシナリオを示唆しています：（a）ISPネットワーク、（b）エンタープライズネットワーク、（c）3GPPネットワーク、および（d）管理されていないネットワーク。
This document is just an analysis of each possible approach, and it does not recommend a particular approach or combination of approaches. Some approaches may even not be adopted at all as a result of further discussion.
このドキュメントは、可能な各アプローチの分析にすぎず、特定のアプローチやアプローチの組み合わせを推奨しません。さらなる議論の結果として、いくつかのアプローチはまったく採用されない場合があります。
Therefore, the objective of this document is to help the audience select the approaches suitable for IPv6 host configuration of recursive DNS servers.
したがって、このドキュメントの目的は、再帰的なDNSサーバーのIPv6ホスト構成に適したアプローチを視聴者が選択できるようにすることです。
This document uses the terminology described in [1]-[7]. In addition, a new term is defined below:
この文書は、[1] - [7]で説明されている用語を使用しています。さらに、新しい用語を以下に定義します。
o Recursive DNS Server (RDNSS): Server which provides a recursive DNS resolution service.
o 再帰DNSサーバー（RDNSS）：再帰DNS解像度サービスを提供するサーバー。
In this section, the operational attributes of the three solutions are described in detail.
このセクションでは、3つのソリューションの運用属性について詳しく説明します。
The RA approach defines a new ND option, called the RDNSS option, that contains a recursive DNS server address [6]. Existing ND transport mechanisms (i.e., advertisements and solicitations) are used. This works in the same way that nodes learn about routers and prefixes. An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA message periodically sent by a router or solicited by a Router Solicitation (RS).
RAアプローチは、再帰的なDNSサーバーアドレス[6]を含むRDNSSオプションと呼ばれる新しいNDオプションを定義します。既存のNDトランスポートメカニズム（つまり、広告と勧誘）が使用されます。これは、ノードがルーターとプレフィックスについて学習するのと同じ方法で機能します。IPv6ホストは、ルーターによって定期的に送信されるRAメッセージまたはルーター勧誘（RS）によって定期的に送信されたRAメッセージを介して、1つ以上のRDNSSEのIPv6アドレスを構成できます。
This approach needs RDNSS information to be configured in the routers doing the advertisements. The configuration of RDNSS addresses can be performed manually by an operator or in other ways, such as automatic configuration through a DHCPv6 client running on the router. An RA message with one RDNSS option can include as many RDNSS addresses as needed [6].
このアプローチには、広告を実行するルーターでRDNSS情報を構成する必要があります。RDNSSアドレスの構成は、ルーターで実行されているDHCPV6クライアントを介した自動構成など、オペレーターまたは他の方法で手動で実行できます。1つのRDNSSオプションを備えたRAメッセージには、必要な限り多くのRDNSアドレスを含めることができます[6]。
Through the ND protocol and RDNSS option, along with a prefix information option, an IPv6 host can perform network configuration of its IPv6 address and RDNSS simultaneously [1][2]. The RA option for RDNSS can be used on any network that supports the use of ND.
NDプロトコルとRDNSSオプションを介して、プレフィックス情報オプションとともに、IPv6ホストはIPv6アドレスとRDNSSのネットワーク構成を同時に実行できます[1] [2]。RDNSSのRAオプションは、NDの使用をサポートする任意のネットワークで使用できます。
The RA approach is useful in some mobile environments where the addresses of the RDNSSes are changing because the RA option includes a lifetime field that allows client to use RDNSSes nearer to the client. This can be configured to a value that will require the client to time out the entry and switch over to another RDNSS address [6]. However, from the viewpoint of implementation, the lifetime field would seem to make matters a bit more complex. Instead of just writing to a DNS configuration file, such as resolv.conf for the list of RDNSS addresses, we have to have a daemon around (or a program that is called at the defined intervals) that keeps monitoring the lifetime of RDNSSes all the time.
RAアプローチは、RDNSSEのアドレスが変更されている一部のモバイル環境で役立ちます。RAオプションには、クライアントがクライアントに近いRDNSSを使用できる生涯フィールドが含まれているためです。これは、クライアントがエントリをタイムアウトし、別のRDNSSアドレスに切り替える必要がある値に構成できます[6]。ただし、実装の観点からは、生涯フィールドは問題をもう少し複雑にするように思われます。RDNSSアドレスのリストのResolv.ConfなどのDNS構成ファイルに書き込むだけでなく、RDNSSの寿命をすべて監視し続けるデーモン（または定義された間隔で呼ばれるプログラム）が必要です。時間。
The preference value of RDNSS, included in the RDNSS option, allows IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this can be used for the load balancing of RDNSSes.
RDNSSオプションに含まれるRDNSSの優先値により、IPv6ホストはいくつかのRDNSSからプライマリRDNSを選択できます[6]。これは、RDNSSEの負荷分散に使用できます。
The RA option for RDNSS has a number of advantages. These include:
RDNSSのRAオプションには多くの利点があります。これらには以下が含まれます：
1. The RA option is an extension of existing ND/Autoconfig mechanisms [1][2] and does not require a change in the base ND protocol.
1. RAオプションは、既存のND/AutoConFigメカニズム[1] [2]の拡張であり、ベースNDプロトコルの変更は必要ありません。
2. This approach, like ND, works well on a variety of link types, including point-to-point links, point-to-multipoint, and multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1] states, however, that there may be some link types on which ND is not feasible; on such links, some other mechanisms will be needed for DNS configuration.
2. NDと同様に、このアプローチは、ポイントツーポイントリンク、ポイントツーマルチポイント、マルチポイントツーマルチポイント（つまり、イーサネットLAN）など、さまざまなリンクタイプでうまく機能します。ただし、RFC 2461 [1]は、NDが実行不可能であるリンクタイプがいくつかある可能性があると述べています。このようなリンクでは、DNS構成には他のメカニズムが必要になります。
3. All the information a host needs to run the basic Internet applications (such as the email, web, ftp, etc.) can be obtained with the addition of this option to ND and address autoconfiguration. The use of a single mechanism is more reliable and easier to provide than when the RDNSS information is learned via another protocol mechanism. Debugging problems when multiple protocol mechanisms are being used is harder and much more complex.
3. ホストが基本的なインターネットアプリケーション（電子メール、Web、FTPなどなど）を実行するために必要なすべての情報は、このオプションをNDに追加してAutoConfigurationに対処することで取得できます。単一のメカニズムの使用は、RDNSS情報が別のプロトコルメカニズムを介して学習される場合よりも信頼性が高く、提供しやすいです。複数のプロトコルメカニズムが使用されている場合のデバッグの問題は、より難しく、はるかに複雑です。
4. This mechanism works over a broad range of scenarios and leverages IPv6 ND. This works well on links that are high performance (e.g., Ethernet LANs) and low performance (e.g., cellular networks). In the latter case, by combining the RDNSS information with the other information in the RA, the host can learn all the information needed to use most Internet applications, such as the web, in a single packet. This not only saves bandwidth, but also minimizes the delay needed to learn the RDNSS information.
4. このメカニズムは、幅広いシナリオで機能し、IPv6 NDを活用します。これは、高性能（イーサネットLANなど）と低いパフォーマンス（セルラーネットワークなど）のリンクでうまく機能します。後者の場合、RDNSS情報とRAの他の情報と組み合わせることにより、ホストは単一のパケットでWebなどのほとんどのインターネットアプリケーションを使用するために必要なすべての情報を学習できます。これにより、帯域幅を節約するだけでなく、RDNSS情報の学習に必要な遅延を最小限に抑えます。
5. The RA approach could be used as a model for similar types of configuration information. New RA options for other server addresses, such as NTP server address, that are common to all clients on a subnet would be easy to define.
5. RAアプローチは、同様のタイプの構成情報のモデルとして使用できます。サブネット上のすべてのクライアントに共通するNTPサーバーアドレスなど、他のサーバーアドレスの新しいRAオプションは簡単に定義できます。
1. ND is mostly implemented in the kernel of the operating system. Therefore, if ND supports the configuration of some additional services, such as DNS servers, ND should be extended in the kernel and complemented by a user-land process. DHCPv6, however, has more flexibility for the extension of service discovery because it is an application layer protocol.
1. NDは、主にオペレーティングシステムのカーネルに実装されています。したがって、NDがDNSサーバーなどのいくつかの追加サービスの構成をサポートする場合、NDはカーネルに拡張され、ユーザーランドプロセスによって補完される必要があります。ただし、DHCPV6は、アプリケーションレイヤープロトコルであるため、サービス発見の拡張に対してより柔軟性があります。
2. The current ND framework should be modified to facilitate the synchronization between another ND cache for RDNSSes in the kernel space and the DNS configuration file in the user space. Because it is unacceptable to write and rewrite to the DNS configuration file (e.g., resolv.conf) from the kernel, another approach is needed. One simple approach to solve this is to have a daemon listening to what the kernel conveys, and to have the daemon do these steps, but such a daemon is not needed with the current ND framework.
2. 現在のNDフレームワークは、カーネル空間のRDNSSEの別のNDキャッシュとユーザースペースのDNS構成ファイル間の同期を容易にするために変更する必要があります。カーネルからDNS構成ファイル（resolv.confなど）を書き込み、書き直すことは受け入れられないため、別のアプローチが必要です。これを解決するための簡単なアプローチの1つは、デーモンにカーネルが伝えるものを聞いてもらい、デーモンにこれらの手順を実行させることですが、現在のNDフレームワークではそのようなデーモンは必要ありません。
3. It is necessary to configure RDNSS addresses at least at one router on every link where this information needs to be configured via the RA option.
3. この情報をRAオプションを介して構成する必要があるすべてのリンクで、少なくとも1つのルーターでRDNSSアドレスを構成する必要があります。
The proposed RDNSS RA option, along with the IPv6 ND and Autoconfiguration, allows a host to obtain all of the information it needs to access basic Internet services like the web, email, ftp, etc. This is preferable in the environments where hosts use RAs to autoconfigure their addresses and all the hosts on the subnet share the same router and server addresses. If the configuration information can be obtained from a single mechanism, it is preferable because it does not add additional delay, and because it uses a minimum of bandwidth. Environments like this include homes, public cellular networks, and enterprise environments where no per host configuration is needed.
提案されたRDNSS RAオプションは、IPv6 NDおよびAutoConfigurationとともに、ホストがWeb、電子メール、FTPなどの基本的なインターネットサービスにアクセスするために必要なすべての情報を取得できるようにします。これは、ホストがRASを使用する環境で好ましいです。アドレスとサブネット上のすべてのホストが同じルーターとサーバーアドレスを共有することをオートコンフィグするには。構成情報を単一のメカニズムから取得できる場合、追加の遅延を追加せず、最小限の帯域幅を使用するため、好ましいです。このような環境には、ホーム、パブリックセルラーネットワーク、ホストごとの構成が必要ないエンタープライズ環境が含まれます。
DHCPv6 is preferable where it is being used for address configuration and if there is a need for host specific configuration [3]-[5]. Environments like this are most likely to be the enterprise environments where the local administration chooses to have per host configuration control.
DHCPV6は、アドレス構成に使用されている場合、およびホスト固有の構成[3] - [5]が必要な場合に好ましいです。このような環境は、地方行政がホスト構成制御ごとに選択するエンタープライズ環境である可能性が最も高いです。
DHCPv6 [3] includes the "DNS Recursive Name Server" option, through which a host can obtain a list of IP addresses of recursive DNS servers [5]. The DNS Recursive Name Server option carries a list of IPv6 addresses of RDNSSes to which the host may send DNS queries. The DNS servers are listed in the order of preference for use by the DNS resolver on the host.
DHCPV6 [3]には、「DNS Recursive Name Server」オプションが含まれており、ホストは再帰DNSサーバーのIPアドレスのリストを取得できます[5]。DNS Recursive Name Serverオプションには、ホストがDNSクエリを送信できるRDNSSEのIPv6アドレスのリストが掲載されています。DNSサーバーは、ホストのDNSリゾルバーが使用するための優先順位でリストされています。
The DNS Recursive Name Server option can be carried in any DHCPv6 Reply message, in response to either a Request or an Information request message. Thus, the DNS Recursive Name Server option can be used either when DHCPv6 is used for address assignment, or when DHCPv6 is used only for other configuration information as stateless DHCPv6 [4].
DNS Recursive Name Serverオプションは、要求または情報リクエストメッセージのいずれかに応じて、任意のDHCPV6返信メッセージに携帯できます。したがって、DNS再帰名サーバーオプションは、DHCPV6がアドレス割り当てに使用される場合、またはDHCPV6がStateless DHCPV6として他の構成情報にのみ使用される場合のいずれかを使用できます[4]。
Stateless DHCPv6 can be deployed either by using DHCPv6 servers running on general-purpose computers, or on router hardware. Several router vendors currently implement stateless DHCPv6 servers. Deploying stateless DHCPv6 in routers has the advantage that no special hardware is required, and it should work well for networks where DHCPv6 is needed for very straightforward configuration of network devices.
ステートレスDHCPV6は、汎用コンピューターで実行されているDHCPV6サーバー、またはルーターハードウェアで展開できます。現在、いくつかのルーターベンダーは、Stateless DHCPV6サーバーを実装しています。RoutersにStateless DHCPV6を展開するには、特別なハードウェアが不要になるという利点があり、ネットワークデバイスの非常に簡単な構成にDHCPV6が必要なネットワークに適しているはずです。
However, routers can also act as DHCPv6 relay agents. In this case, the DHCPv6 server need not be on the router; it can be on a general purpose computer. This has the potential to give the operator of the DHCPv6 server more flexibility in how the DHCPv6 server responds to individual clients that can easily be given different configuration information based on their identity, or for any other reason. Nothing precludes adding this flexibility to a router, but generally, in current practice, DHCP servers running on general-purpose hosts tend to have more configuration options than those that are embedded in routers.
ただし、ルーターはDHCPV6リレー剤としても作用することもできます。この場合、DHCPV6サーバーはルーター上にある必要はありません。汎用コンピューター上にあります。これにより、DHCPV6サーバーのオペレーターが、DHCPV6サーバーが個々のクライアントにどのように応答するかについて、アイデンティティに基づいて、またはその他の理由で異なる構成情報を簡単に提供できる柔軟性を高める可能性があります。この柔軟性をルーターに追加することを妨げるものはありませんが、一般的に、現在の練習では、汎用ホストで実行されるDHCPサーバーは、ルーターに埋め込まれたものよりも多くの構成オプションを持つ傾向があります。
DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 clients that use a stateful configuration assignment. To do this, the DHCPv6 server sends a Reconfigure message to the client. The client validates the Reconfigure message, and then contacts the DHCPv6 server to obtain updated configuration information. By using this mechanism, it is currently possible to propagate new configuration information to DHCPv6 clients as this information changes.
DHCPV6は現在、ステートフルな構成割り当てを使用するDHCPV6クライアントを再構成するためのメカニズムを提供しています。これを行うために、DHCPV6サーバーはクライアントに再構成メッセージを送信します。クライアントは再構成メッセージを検証し、DHCPV6サーバーに連絡して更新された構成情報を取得します。このメカニズムを使用することにより、この情報が変更されるにつれて、新しい構成情報をDHCPV6クライアントに伝播することが現在可能です。
The DHC Working Group has standardized an additional mechanism through which configuration information, including the list of RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns a lifetime to configuration information obtained through DHCPv6. At the expiration of the lifetime, the host contacts the DHCPv6 server to obtain updated configuration information, including the list of RDNSSes. This lifetime gives the network administrator another mechanism to configure hosts with new RDNSSes by controlling the time at which the host refreshes the list.
DHCワーキンググループは、RDNSSEのリストを含む構成情報を更新できる追加のメカニズムを標準化しました。dhcpv6 [8]の寿命オプションは、dhcpv6を介して取得した構成情報に寿命を割り当てます。寿命が切れると、ホストはDHCPV6サーバーに連絡して、RDNSSEのリストを含む更新された構成情報を取得します。この寿命は、ネットワーク管理者に、ホストがリストを再リッシュする時間を制御することにより、新しいRDNSSEでホストを構成する別のメカニズムを与えます。
The DHC Working Group has also discussed the possibility of defining an extension to DHCPv6 that would allow the use of multicast to provide configuration information to multiple hosts with a single DHCPv6 message. Because of the lack of deployment experience, the WG has deferred consideration of multicast DHCPv6 configuration at this time. Experience with DHCPv4 has not identified a requirement for multicast message delivery, even in large service provider networks with tens of thousands of hosts that may initiate a DHCPv4 message exchange simultaneously.
DHCワーキンググループは、単一のDHCPV6メッセージで複数のホストに構成情報を提供するためにマルチキャストを使用することを可能にするDHCPV6の拡張機能を定義する可能性についても議論しています。展開の経験が不足しているため、WGは現時点でマルチキャストDHCPV6構成の検討を延期しました。DHCPV4の経験は、DHCPV4メッセージ交換を同時に開始する可能性のある数万人のホストを備えた大規模なサービスプロバイダーネットワークであっても、マルチキャストメッセージ配信の要件を特定していません。
The DHCPv6 option for RDNSS has a number of advantages. These include:
RDNSSのDHCPV6オプションには多くの利点があります。これらには以下が含まれます：
1. DHCPv6 currently provides a general mechanism for conveying network configuration information to clients. Configuring DHCPv6 servers in this way allows the network administrator to configure RDNSSes, the addresses of other network services, and location-specific information, such as time zones.
1. DHCPV6は現在、ネットワーク構成情報をクライアントに伝えるための一般的なメカニズムを提供しています。この方法でDHCPV6サーバーを構成することで、ネットワーク管理者はRDNSSE、他のネットワークサービスのアドレス、およびタイムゾーンなどの場所固有の情報を構成できます。
2. As a consequence, when the network administrator goes to configure DHCPv6, all the configuration information can be managed through a single service, typically with a single user interface and a single configuration database.
2. 結果として、ネットワーク管理者がDHCPV6を構成する場合、すべての構成情報は、通常、単一のユーザーインターフェイスと単一の構成データベースを使用して、単一のサービスを介して管理できます。
3. DHCPv6 allows for the configuration of a host with information specific to that host, so that hosts on the same link can be configured with different RDNSSes and with other configuration information.
3. DHCPV6では、そのホストに固有の情報を持つホストの構成を可能にするため、同じリンク上のホストを異なるRDNSSEおよび他の構成情報で構成できます。
4. A mechanism exists for extending DHCPv6 to support the transmission of additional configuration that has not yet been anticipated.
4. DHCPV6を拡張して、まだ予想されていない追加の構成の送信をサポートするメカニズムが存在します。
5. Hosts that require other configuration information, such as the addresses of SIP servers and NTP servers, are likely to need DHCPv6 for other configuration information.
5. SIPサーバーやNTPサーバーのアドレスなど、他の構成情報を必要とするホストは、他の構成情報にDHCPV6が必要になる可能性があります。
6. The specification for configuration of RDNSSes through DHCPv6 is available as an RFC. No new protocol extensions (such as new options) are necessary.
6. DHCPV6を介したRDNSSEの構成の仕様は、RFCとして利用できます。新しいプロトコル拡張（新しいオプションなど）は必要ありません。
7. Interoperability among independent implementations has been demonstrated.
7. 独立した実装間の相互運用性が実証されています。
The DHCPv6 option for RDNSS has a few disadvantages. These include:
RDNSSのDHCPV6オプションにはいくつかの欠点があります。これらには以下が含まれます：
1. Update currently requires a message from server (however, see [8]).
1. 更新には現在、サーバーからのメッセージが必要です（ただし、[8]を参照）。
2. Because DNS information is not contained in RA messages, the host must receive two messages from the router and must transmit at least one message to the router. On networks where bandwidth is at a premium, this is a disadvantage, although on most networks it is not a practical concern.
2. DNS情報はRAメッセージに含まれていないため、ホストはルーターから2つのメッセージを受信する必要があり、少なくとも1つのメッセージをルーターに送信する必要があります。帯域幅がプレミアムにあるネットワークでは、これは不利な点ですが、ほとんどのネットワークでは実際的な懸念事項ではありません。
3. There is an increased latency for initial configuration. In addition to waiting for an RA message, the client must now exchange packets with a DHCPv6 server. Even if it is locally installed on a router, this will slightly extend the time required to configure the client. For clients that are moving rapidly from one network to another, this will be a disadvantage.
3. 初期構成のレイテンシーが増加しています。RAメッセージを待つことに加えて、クライアントはDHCPV6サーバーとパケットを交換する必要があります。ルーターにローカルにインストールされていても、クライアントの構成に必要な時間がわずかに延長されます。あるネットワークから別のネットワークに急速に移動しているクライアントの場合、これは不利です。
In the general case, on general-purpose networks, stateless DHCPv6 provides significant advantages and no significant disadvantages. Even in the case where bandwidth is at a premium and low latency is desired, if hosts require other configuration information in addition to a list of RDNSSes or if hosts must be configured selectively, those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive name server option will be advantageous.
一般的なケースでは、汎用ネットワークでは、ステートレスDHCPV6が重要な利点を提供し、大きな欠点はありません。帯域幅がプレミアムで低レイテンシが必要な場合でも、ホストがRDNSSEのリストに加えて他の構成情報を必要とする場合、またはホストを選択的に構成する必要がある場合、それらのホストはDHCPV6とDHCPV6 DNS再帰の使用を使用します名前サーバーオプションは有利です。
However, we are aware of some applications where it would be preferable to put the RDNSS information into an RA packet; for example, in a mobile phone network, where bandwidth is at a premium and extremely low latency is desired. The DNS configuration based on RA should be standardized so as to allow these special applications to be handled using DNS information in the RA packet.
ただし、RDNSS情報をRAパケットに入れることが望ましいアプリケーションをいくつか認識しています。たとえば、帯域幅がプレミアムであり、非常に低いレイテンシが必要な携帯電話ネットワークでは。RAに基づくDNS構成は、RAパケットのDNS情報を使用してこれらの特別なアプリケーションを処理できるように標準化する必要があります。
Anycast uses the same routing system as unicast [9]. However, administrative entities are local ones. The local entities may accept unicast routes (including default routes) to anycast servers from adjacent entities. The administrative entities should not advertise their peer routes to their internal anycast servers, if they want to prohibit external access from some peers to the servers. If some advertisement is inevitable (such as the case with default routes), the packets to the servers should be blocked at the boundary of the entities. Thus, for this anycast, not only unicast routing but also unicast ND protocols can be used as is.
Anycastは、Unicastと同じルーティングシステムを使用しています[9]。ただし、管理エンティティは地元のエンティティです。ローカルエンティティは、隣接するエンティティからのAnycastサーバーへのユニキャストルート（デフォルトルートを含む）を受け入れる場合があります。管理エンティティは、一部のピアからサーバーへの外部アクセスを禁止したい場合は、内部Anycastサーバーにピアルートを宣伝しないでください。一部の広告が避けられない場合（デフォルトルートの場合など）、サーバーへのパケットはエンティティの境界でブロックする必要があります。したがって、このAnycastでは、ユニキャストルーティングだけでなく、ユニキャストNDプロトコルもそのまま使用できます。
First of all, the well-known anycast addresses approach is much different from that discussed by the IPv6 Working Group in the past [7]. Note that "anycast" in this memo is simpler than that of RFC 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to have multiple servers on a single link sharing an anycast address. That is, on a link, an anycast address is assumed to be unique. DNS clients today already have redundancy by having multiple well-known anycast addresses configured as RDNSS addresses. There is no point in having multiple RDNSSes sharing an anycast address on a single link.
まず、よく知られているAnycastアドレスアプローチは、過去にIPv6ワーキンググループが議論したものとは大きく異なります[7]。このメモの「Anycast」は、RFC 1546 [9]およびRFC 3513 [10]のメモよりも簡単であることに注意してください。ここでは、単一のリンクに複数のサーバーがAnyCastアドレスを共有することが禁止されていると想定されています。つまり、リンクでは、Anycastアドレスが一意であると想定されています。DNSクライアントは、RDNSSアドレスとして構成されている複数の有名なAnycastアドレスを既に冗長にすることにより、すでに冗長性を持っています。単一のリンクでAnycastアドレスを共有する複数のRDNSSEを持つことには意味がありません。
The approach with well-known anycast addresses is to set multiple well-known anycast addresses in clients' resolver configuration files from the beginning as, say, factory default. Thus, there is no transport mechanism and no packet format [7].
よく知られているAnycastアドレスを使用したアプローチは、たとえば工場のデフォルトとして、クライアントのリゾルバー構成ファイルに複数の有名なAnycastアドレスを設定することです。したがって、輸送メカニズムもパケット形式もありません[7]。
An anycast address is an address shared by multiple servers (in this case, the servers are RDNSSes). A request from a client to the anycast address is routed to a server selected by the routing system. However, it is a bad idea to mandate "site" boundary on anycast addresses, because most users do not have their own servers and want to access their ISPs across their site boundaries. Larger sites may also depend on their ISPs or may have their own RDNSSes within "site" boundaries.
Anycastアドレスは、複数のサーバーが共有するアドレスです（この場合、サーバーはRDNSSESです）。クライアントからAnycastアドレスへのリクエストは、ルーティングシステムによって選択されたサーバーにルーティングされます。ただし、ほとんどのユーザーは独自のサーバーを持っておらず、サイトの境界を越えてISPにアクセスしたいため、Anycastアドレスに「サイト」の境界を義務付けることは悪い考えです。大規模なサイトは、ISPに依存している場合や、「サイト」境界内に独自のRDNSSEを持っている場合があります。
The basic advantage of the well-known addresses approach is that it uses no transport mechanism. Thus, the following apply:
よく知られているアドレスアプローチの基本的な利点は、輸送メカニズムを使用していないことです。したがって、次のものが適用されます。
1. There is no delay to get the response and no further delay by packet losses.
1. 応答を取得する遅延はなく、パケット損失によるさらなる遅延はありません。
2. The approach can be combined with any other configuration mechanisms, such as the RA-based approach and DHCP-based approach, as well as the factory default configuration.
2. このアプローチは、RAベースのアプローチやDHCPベースのアプローチなど、工場出荷時のデフォルト構成など、他の構成メカニズムと組み合わせることができます。
3. The approach works over any environment where DNS works.
3. このアプローチは、DNSが機能するあらゆる環境で機能します。
Another advantage is that this approach only needs configuration of the DNS servers as a router (or configuration of a proxy router). Considering that DNS servers do need configuration, the amount of overall configuration effort is proportional to the number of DNS servers and it scales linearly. Note that, in the simplest case, where a subscriber to an ISP does not have a DNS server, the subscriber naturally accesses DNS servers of the ISP, even though the subscriber and the ISP do nothing and there is no protocol to exchange DNS server information between the subscriber and the ISP.
もう1つの利点は、このアプローチには、ルーターとしてのDNSサーバーの構成のみが必要であることです（またはプロキシルーターの構成）。DNSサーバーには構成が必要であることを考慮すると、全体的な構成の努力の量はDNSサーバーの数に比例し、それは線形にスケーリングします。ISPへのサブスクライバーがDNSサーバーを持っていない最も単純なケースでは、サブスクライバーとISPが何もしていない場合でも、サブスクライバーはISPのDNSサーバーに自然にアクセスし、DNSサーバー情報を交換するプロトコルはありません。サブスクライバーとISPの間。
The well-known anycast addresses approach requires that DNS servers (or routers near to them as a proxy) act as routers to advertise their anycast addresses to the routing system, which requires some configuration (see the last paragraph of the previous section on the scalability of the effort). In addition, routers at the boundary of the "site" might need the configuration of route filters to prevent providing DNS services for parties outside the "site" and the possibility of denial of service attacks on the internal DNS infrastructure.
よく知られているAnycastアドレスアプローチでは、DNSサーバー（またはプロキシとして近くのルーター）がルーターとして機能することを要求しています。努力の）。さらに、「サイト」の境界にあるルーターは、「サイト」外の関係者にDNSサービスを提供することを防ぎ、内部DNSインフラストラクチャに対するサービス拒否攻撃の可能性を防ぐために、ルートフィルターの構成が必要になる場合があります。
If other approaches are used in addition, the well-known anycast addresses should also be set in RA or DHCP configuration files to reduce the configuration effort of users.
さらに、他のアプローチが使用されている場合、ユーザーの構成努力を削減するために、よく知られているAnycastアドレスもRAまたはDHCP構成ファイルで設定する必要があります。
The redundancy by multiple RDNSSes is better provided by multiple servers with different anycast addresses than by multiple servers sharing the same anycast address, because the former approach allows stale servers to generate routes to their anycast addresses. Thus, in a routing domain (or domains sharing DNS servers), there will be only one server with an anycast address unless the domain is so large that load distribution is necessary.
複数のRDNSSEによる冗長性は、以前のアプローチでは古いサーバーがAnycastアドレスへのルートを生成できるため、同じAnycastアドレスを共有する複数のサーバーとは異なるAnycastアドレスを持つ複数のサーバーによってより適切に提供されます。したがって、ルーティングドメイン（またはDNSサーバーを共有するドメイン）では、ドメインが非常に大きいため、負荷分布が必要な場合を除き、Anycastアドレスを持つサーバーは1つだけです。
Small ISPs will operate one RDNSS at each anycast address that is shared by all the subscribers. Large ISPs may operate multiple RDNSSes at each anycast address to distribute and reduce load, where the boundary between RDNSSes may be fixed (redundancy is still provided by multiple addresses) or change dynamically. DNS packets with the well-known anycast addresses are not expected (though not prohibited) to cross ISP boundaries, as ISPs are expected to be able to take care of themselves.
Small ISPは、すべてのサブスクライバーが共有する各任意のキャストアドレスで1つのRDNSを操作します。大規模なISPは、各任意のキャストアドレスで複数のRDNSSEを動作させて荷重を分配および削減する場合があります。ここでは、RDNSSEの境界が固定され（冗長性は複数のアドレスで提供されます）、または動的に変更されます。よく知られているAnycastアドレスを備えたDNSパケットは、ISPが自分の面倒を見ることができると予想されるため、ISPの境界を越えることは予想されません（禁止されていませんが）。
Because "anycast" in this memo is simpler than that of RFC 1546 [9] and RFC 3513 [10], where it is assumed to be administratively prohibited to have multiple servers on a single link sharing an anycast address, anycast in this memo should be implemented as UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related instability disappears. Thus, in the well-known anycast addresses approach, anycast can and should use the anycast address as a source unicast (according to RFC 3513 [10]) address of packets of UDP and TCP responses. With TCP, if a route flips and packets to an anycast address are routed to a new server, it is expected that the flip is detected by ICMP or sequence number inconsistency, and that the TCP connection is reset and retried.
このメモの「Anycast」はRFC 1546 [9]およびRFC 3513 [10]の「Anycast」よりも簡単であるため、1つのリンクに複数のサーバーがAnycastアドレスを共有することが管理上禁止されていると想定されるため、このメモのAnycastはRFC 2461 [1]およびRFC 3513 [10]のユニキャストとして実装されます。その結果、ND関連の不安定性は消えます。したがって、よく知られているAnycastアドレスアプローチでは、AnycastアドレスをUDPおよびTCP応答のパケットのソースユニキャスト（RFC 3513 [10]）アドレスとして（RFC 3513 [10]）アドレスとして使用することができます。TCPを使用すると、ルートがAnycastアドレスにフリップされ、パケットが新しいサーバーにルーティングされる場合、フリップはICMPまたはシーケンス番号の矛盾によって検出され、TCP接続がリセットおよび再試行されることが予想されます。
Three approaches can work together for IPv6 host configuration of RDNSS. This section shows a consideration on how these approaches can interwork.
RDNSのIPv6ホスト構成のために、3つのアプローチが協力できます。このセクションでは、これらのアプローチがどのようにインターワークできるかについての考慮事項を示しています。
For ordering between RA and DHCP approaches, the O (Other stateful configuration) flag in the RA message can be used [6][28]. If no RDNSS option is included, an IPv6 host may perform DNS configuration through DHCPv6 [3]-[5] regardless of whether the O flag is set or not.
RAとDHCPアプローチの間を注文するには、RAメッセージのO（他のステートフル構成）フラグを使用できます[6] [28]。RDNSSオプションが含まれていない場合、IPv6ホストは、Oフラグが設定されているかどうかに関係なく、DHCPv6 [3] - [5]を介してDNS構成を実行できます。
The well-known anycast addresses approach fully interworks with the other approaches. That is, the other approaches can remove the configuration effort on servers by using the well-known addresses as the default configuration. Moreover, the clients preconfigured with the well-known anycast addresses can be further configured to use other approaches to override the well-known addresses, if the configuration information from other approaches is available. Otherwise, all the clients need to have the well-known anycast addresses preconfigured. In order to use the anycast approach along with two other approaches, there are three choices as follows:
よく知られているAnycastアドレスは、他のアプローチと完全にインターワークをアプローチします。つまり、他のアプローチでは、有名なアドレスをデフォルトの構成として使用して、サーバーの構成努力を削除できます。さらに、他のアプローチからの構成情報が利用可能な場合、よく知られているAnycastアドレスを事前に構成したクライアントを他のアプローチを使用して、よく知られているアドレスをオーバーライドするように構成できます。それ以外の場合、すべてのクライアントは、有名なAnycastアドレスを事前に設定する必要があります。Anycastアプローチを他の2つのアプローチとともに使用するために、次の3つの選択肢があります。
1. The first choice is that well-known addresses are used as last resort, when an IPv6 host cannot get RDNSS information through RA and DHCP. The well-known anycast addresses have to be preconfigured in all of IPv6 hosts' resolver configuration files.
1. 最初の選択は、IPv6ホストがRAとDHCPを介してRDNSS情報を取得できない場合、よく知られているアドレスが最後の手段として使用されることです。よく知られているAnycastアドレスは、すべてのIPv6ホストのリゾルバー構成ファイルで事前に構成する必要があります。
2. The second is that an IPv6 host can configure well-known addresses as the most preferable in its configuration file even though either an RA option or DHCP option is available.
2. 2つ目は、IPv6ホストが、RAオプションまたはDHCPオプションのいずれかが利用可能である場合でも、その構成ファイルで最も好ましいアドレスとして構成できることです。
3. The last is that the well-known anycast addresses can be set in RA or DHCP configuration to reduce the configuration effort of users. According to either the RA or DHCP mechanism, the well-known addresses can be obtained by an IPv6 host. Because this approach is the most convenient for users, the last option is recommended.
3. 最後は、よく知られているAnycastアドレスをRAまたはDHCP構成で設定して、ユーザーの構成努力を削減できることです。RAまたはDHCPメカニズムのいずれかによれば、よく知られているアドレスはIPv6ホストによって取得できます。このアプローチはユーザーにとって最も便利であるため、最後のオプションが推奨されます。
Note: This section does not necessarily mean that this document suggests adopting all of these three approaches and making them interwork in the way described here. In fact, as a result of further discussion some approaches may not even be adopted at all.
注：このセクションでは、このドキュメントがこれら3つのアプローチのすべてを採用し、ここで説明する方法でインターワークすることを示唆していることを意味するわけではありません。実際、さらなる議論の結果、いくつかのアプローチはまったく採用されないかもしれません。
Regarding the DNS configuration on the IPv6 host, several mechanisms are being considered by the DNSOP Working Group, such as RA option, DHCPv6 option, and well-known preconfigured anycast addresses as of today, and this document is a final result from the long thread. In this section, we suggest four applicable scenarios of three approaches for IPv6 DNS configuration.
IPv6ホストのDNS構成に関して、RAオプション、DHCPV6オプション、および有名な事前に構成されたAnycastアドレスなど、DNSOPワーキンググループによっていくつかのメカニズムが考慮されています。このドキュメントは、長いスレッドの最終結果です。。このセクションでは、IPv6 DNS構成の3つのアプローチの4つの適用可能なシナリオを提案します。
Note: In the applicable scenarios, authors do not implicitly push any specific approaches into the restricted environments. No enforcement is in each scenario, and all mentioned scenarios are probable. The main objective of this work is to provide a useful guideline for IPv6 DNS configuration.
注：該当するシナリオでは、著者は特定のアプローチを制限付き環境に暗黙的にプッシュしません。各シナリオには施行はありません。また、言及されたすべてのシナリオは可能性があります。この作業の主な目的は、IPv6 DNS構成に有用なガイドラインを提供することです。
A characteristic of an ISP network is that multiple Customer Premises Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) routers and that each PE connects multiple CPE devices to the backbone network infrastructure [11]. The CPEs may be hosts or routers.
ISPネットワークの特徴は、複数の顧客施設機器（CPE）デバイスがIPv6 PE（プロバイダーエッジ）ルーターに接続されており、各PEが複数のCPEデバイスをバックボーンネットワークインフラストラクチャに接続していることです[11]。CPESはホストまたはルーターである場合があります。
If the CPE is a router, there is a customer network that is connected to the ISP backbone through the CPE. Typically, each customer network gets a different IPv6 prefix from an IPv6 PE router, but the same RDNSS configuration will be distributed.
CPEがルーターの場合、CPEを介してISPバックボーンに接続されている顧客ネットワークがあります。通常、各顧客ネットワークはIPv6 PEルーターから異なるIPv6プレフィックスを取得しますが、同じRDNSS構成が分散されます。
This section discusses how the different approaches to distributing DNS information are compared in an ISP network.
このセクションでは、DNS情報の配布に対するさまざまなアプローチがISPネットワークでどのように比較されるかについて説明します。
When the CPE is a host, the RA option for RDNSS can be used to allow the CPE to get RDNSS information and /64 prefix information for stateless address autoconfiguration at the same time when the host is attached to a new subnet [6]. Because an IPv6 host must receive at least one RA message for stateless address autoconfiguration and router configuration, the host could receive RDNSS configuration information in the RA without the overhead of an additional message exchange.
CPEがホストの場合、RDNSSのRAオプションを使用して、CPEがRDNSS情報と /64のプレフィックス情報を入手できるようにします。IPv6ホストは、StatelessアドレスのAutoconfigurationおよびRouter構成の少なくとも1つのRAメッセージを受信する必要があるため、ホストは追加のメッセージ交換のオーバーヘッドなしでRAでRDNSS構成情報を受信できます。
When the CPE is a router, the CPE may accept the RDNSS information from the RA on the interface connected to the ISP and copy that information into the RAs advertised in the customer network.
CPEがルーターの場合、CPEはISPに接続されたインターフェイス上のRAからRDNSS情報を受け入れ、その情報をカスタマーネットワークで宣伝されているRAにコピーします。
This approach is more valuable in the mobile host scenario, in which the host must receive at least an RA message for detecting a new network, than in other scenarios generally, although the administrator should configure RDNSS information on the routers. Secure ND [12] can provide extended security when RA messages are used.
このアプローチは、モバイルホストのシナリオでより価値があります。ホストは、一般的に他のシナリオよりも、少なくとも新しいネットワークを検出するためのRAメッセージを受け取る必要がありますが、管理者はルーターにRDNSS情報を構成する必要があります。Secure Nd [12]は、RAメッセージが使用されるときに拡張セキュリティを提供できます。
DHCPv6 can be used for RDNSS configuration through the use of the DNS option, and can provide other configuration information in the same message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or stateless DHCP [4] is not nearly as complex as a full DHCPv6 implementation. DHCP is a client-server model protocol, so ISPs can handle user identification on its network intentionally; also, authenticated DHCP [13] can be used for secure message exchange.
DHCPV6は、DNSオプションを使用してRDNSS構成に使用でき、RDNSS構成[3] - [5]で同じメッセージ内の他の構成情報を提供できます。DHCPV6 DNSオプションは、RFC 3646 [5]およびDHCPV6-LITEまたはSTATENTER DHCP [4]が完全なDHCPV6実装ほど複雑ではないため、DHCPV6のために既に導入されています。DHCPはクライアントサーバーモデルプロトコルであるため、ISPは意図的にネットワーク上のユーザー識別を処理できます。また、認証されたDHCP [13]は、安全なメッセージ交換に使用できます。
The expected model for deployment of IPv6 service by ISPs is to assign a prefix to each customer, which will be used by the customer gateway to assign a /64 prefix to each network in the customer's network. Prefix delegation with DHCP (DHCPv6 PD) has already been adopted by ISPs for automating the assignment of the customer prefix to the customer gateway [15]. DNS configuration can be carried in the same DHCPv6 message exchange used for DHCPv6 to provide that information efficiently, along with any other configuration information needed by the customer gateway or customer network. This service model can be useful to Home or SOHO subscribers. The Home or SOHO gateway, which is a customer gateway for ISP, can then pass that RDNSS configuration information to the hosts in the customer network through DHCP.
ISPSによるIPv6サービスの展開に予想されるモデルは、各顧客にプレフィックスを割り当てることです。これは、顧客ゲートウェイが使用して、顧客のネットワーク内の各ネットワークにA /64プレフィックスを割り当てることです。DHCP（DHCPV6 PD）を使用したプレフィックス委任は、顧客ゲートウェイ[15]への顧客プレフィックスの割り当てを自動化するために、ISPSによってすでに採用されています。DNS構成は、dhcpv6が使用される同じDHCPV6メッセージ交換で、その情報を効率的に提供し、顧客ゲートウェイまたは顧客ネットワークで必要な他の構成情報を提供できます。このサービスモデルは、自宅やSohoの加入者に役立ちます。ISPの顧客ゲートウェイであるHomeまたはSoho Gatewayは、DHCPを介してそのRDNSS構成情報を顧客ネットワークのホストに渡すことができます。
The well-known anycast addresses approach is also a feasible and simple mechanism for ISP [7]. The use of well-known anycast addresses avoids some of the security risks in rogue messages sent through an external protocol such as RA or DHCPv6. The configuration of hosts for the use of well-known anycast addresses requires no protocol or manual configuration, but the configuration of routing for the anycast addresses requires intervention on the part of the network administrator. Also, the number of special addresses would be equal to the number of RDNSSes that could be made available to subscribers.
よく知られているAnycastアドレスアプローチは、ISPの実行可能で簡単なメカニズムでもあります[7]。よく知られているAnycastアドレスを使用すると、RAやDHCPV6などの外部プロトコルを介して送信されるRogueメッセージのセキュリティリスクの一部が回避されます。よく知られているAnycastアドレスを使用するためのホストの構成には、プロトコルまたは手動構成は必要ありませんが、Anycastアドレスのルーティングの構成には、ネットワーク管理者側の介入が必要です。また、特別なアドレスの数は、加入者が利用できるRDNSSの数に等しくなります。
An enterprise network is defined as a network that has multiple internal links, one or more router connections to one or more providers, and is actively managed by a network operations entity [14]. An enterprise network can get network prefixes from an ISP by either manual configuration or prefix delegation [15]. In most cases, because an enterprise network manages its own DNS domains, it operates its own DNS servers for the domains. These DNS servers within enterprise networks process recursive DNS name resolution requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the enterprise network can be performed as it is in Section 4, in which three approaches can be used together as follows:
エンタープライズネットワークは、複数の内部リンクを備えたネットワーク、1つ以上のプロバイダーへの1つ以上のルーター接続を備えたネットワークとして定義され、ネットワーク運用エンティティ[14]によって積極的に管理されています。エンタープライズネットワークは、手動構成またはプレフィックス委任[15]によってISPからネットワークプレフィックスを取得できます。ほとんどの場合、エンタープライズネットワークは独自のDNSドメインを管理するため、ドメイン用の独自のDNSサーバーを操作します。エンタープライズネットワーク内のこれらのDNSサーバーは、IPv6ホストからRDNSSEとして再帰的なDNS名解像度要求を処理します。エンタープライズネットワークのRDNSS構成は、セクション4のように実行できます。この場合、3つのアプローチを次のように使用できます。
1. An IPv6 host can decide which approach is or may be used in its subnet with the O flag in RA message [6][28]. As the first choice in Section 4, well-known anycast addresses can be used as a last resort when RDNSS information cannot be obtained through either an RA option or a DHCP option. This case needs IPv6 hosts to preconfigure the well-known anycast addresses in their DNS configuration files.
1. IPv6ホストは、RAメッセージ[6] [28]のOフラグを使用して、サブネットでどのアプローチが使用されるか、または使用される可能性があるかを決定できます。セクション4の最初の選択肢として、RDNSS情報をRAオプションまたはDHCPオプションのいずれかで取得できない場合、有名なAnycastアドレスを最後の手段として使用できます。このケースでは、DNS構成ファイルの有名なAnycastアドレスを事前に構成するためにIPv6ホストが必要です。
2. When the enterprise prefers the well-known anycast approach to others, IPv6 hosts should preconfigure the well-known anycast addresses as it is in the first choice.
2. エンタープライズが他の人への有名なAnycastアプローチを好む場合、IPv6ホストは、最初の選択肢であるため、有名なAnycastアドレスを事前に構成する必要があります。
3. The last choice, a more convenient and transparent way, does not need IPv6 hosts to preconfigure the well-known anycast addresses because the addresses are delivered to IPv6 hosts via either the RA option or DHCPv6 option as if they were unicast addresses. This way is most recommended for the sake of the user's convenience.
3. より便利で透明な方法である最後の選択は、アドレスがUnicastアドレスであるかのようにRAオプションまたはDHCPV6オプションのいずれかを介してIPv6ホストに配信されるため、有名なAnycastアドレスを事前に構成するためにIPv6ホストを必要としません。この方法は、ユーザーの便利さのために最もお勧めします。
The IPv6 DNS configuration is a missing part of IPv6 autoconfiguration and an important part of the basic IPv6 functionality in the 3GPP User Equipment (UE). The higher-level description of the 3GPP architecture can be found in [16], and transition to IPv6 in 3GPP networks is analyzed in [17] and [18].
IPv6 DNS構成は、IPv6 Autoconfigurationの欠落部分であり、3GPPユーザー機器（UE）の基本的なIPv6機能の重要な部分です。3GPPアーキテクチャの高レベルの説明は[16]にあり、3GPPネットワークのIPv6への移行を[17]および[18]で分析します。
In the 3GPP architecture, there is a dedicated link between the UE and the GGSN called the Packet Data Protocol (PDP) Context. This link is created through the PDP Context activation procedure [19]. There is a separate PDP context type for IPv4 and IPv6 traffic. If a 3GPP UE user is communicating by using IPv6 (i.e., by having an active IPv6 PDP context), it cannot be assumed that the user simultaneously has an active IPv4 PDP context, and DNS queries could be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow it needs to discover the address of the RDNSS. Before IP-based services (e.g., web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses need to be discovered in the 3GPP UE.
3GPPアーキテクチャでは、UEとPacket Data Protocol（PDP）コンテキストと呼ばれるGGSNの間に専用のリンクがあります。このリンクは、PDPコンテキストアクティベーション手順[19]を介して作成されます。IPv4およびIPv6トラフィックには、個別のPDPコンテキストタイプがあります。3GPP UEユーザーがIPv6を使用して通信している場合（つまり、アクティブなIPv6 PDPコンテキストを持つことで）、ユーザーに同時にアクティブなIPv4 PDPコンテキストを持ち、DNSクエリをIPv4を使用して実行できると想定することはできません。したがって、3GPP UEはIPv6ノードになる可能性があり、どういうわけかRDNSSのアドレスを発見する必要があります。IPベースのサービス（Webブラウジングや電子メールなど）を使用する前に、IPv6（およびIPv4）RDNSSアドレスを3GPP UEで発見する必要があります。
Section 5.3.1 briefly summarizes currently available mechanisms in 3GPP networks and recommendations. 5.3.2 analyzes the Router Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6 mechanism, and 5.3.4 analyzes the well-known addresses approach. Section 5.3.5 summarizes the recommendations.
セクション5.3.1は、3GPPネットワークと推奨事項で現在利用可能なメカニズムを簡単に要約します。5.3.2ルーター広告ベースのソリューションを分析し、5.3.3ステートレスDHCPV6メカニズムを分析し、5.3.4はよく知られているアドレスアプローチを分析します。セクション5.3.5は、推奨事項をまとめたものです。
3GPP has defined a mechanism in which RDNSS addresses can be received in the PDP context activation (a control plane mechanism). That is called the Protocol Configuration Options Information Element (PCO-IE) mechanism [20]. The RDNSS addresses can also be received over the air (using text messages) or typed in manually in the UE. Note that the two last mechanisms are not very well scalable. The UE user most probably does not want to type IPv6 RDNSS addresses manually in the user's UE. The use of well-known addresses is briefly discussed in section 5.3.4.
3GPPは、PDPコンテキストのアクティベーション（コントロールプレーンメカニズム）でRDNSSアドレスを受信できるメカニズムを定義しています。これは、プロトコル構成オプション情報要素（PCO-IE）メカニズムと呼ばれます[20]。RDNSSアドレスは、空中で（テキストメッセージを使用して）受け取るか、UEで手動で入力することもできます。2つの最後のメカニズムはあまりスケーラブルではないことに注意してください。UEユーザーは、おそらくユーザーのUEでIPv6 RDNSSアドレスを手動で入力したくないでしょう。よく知られているアドレスの使用については、セクション5.3.4で簡単に説明します。
It is seen that the mechanisms above most probably are not sufficient for the 3GPP environment. IPv6 is intended to operate in a zero-configuration manner, no matter what the underlying network infrastructure is. Typically, the RDNSS address is needed to make an IPv6 node operational, and the DNS configuration should be as simple as the address autoconfiguration mechanism. Note that there will be additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP-specific DNS configuration mechanisms (such as PCO-IE [20]) do not work for those IP interfaces. In other words, a good IPv6 DNS configuration mechanism should also work in a multi-access network environment.
上記のメカニズムは、おそらく3GPP環境では十分ではないことがわかります。IPv6は、基礎となるネットワークインフラストラクチャが何であれ、ゼロコンフィグレーターの方法で動作することを目的としています。通常、IPv6ノードを動作させるにはRDNSSアドレスが必要であり、DNS構成はアドレスAutoconfigurationメカニズムと同じくらい簡単でなければなりません。いくつかの近距離3GPP UEに追加のIPインターフェイスがあることに注意してください。たとえば、3GPP固有のDNS構成メカニズム（PCO-IE [20]など）は、これらのIPインターフェイスでは機能しません。言い換えれば、優れたIPv6 DNS構成メカニズムは、マルチアクセスネットワーク環境でも機能する必要があります。
From a 3GPP point of view, the best IPv6 DNS configuration solution is feasible for a very large number of IPv6-capable UEs (even hundreds of millions in one operator's network), is automatic, and thus requires no user action. It is suggested that a lightweight, stateless mechanism be standardized for use in all network environments. The solution could then be used for 3GPP, 3GPP2, and other access network technologies. Thus, not only is a light, stateless IPv6 DNS configuration mechanism needed in 3GPP networks, but also 3GPP networks and UEs would certainly benefit from the new mechanism.
3GPPの観点から、最適なIPv6 DNS構成ソリューションは、非常に多数のIPv6対応UE（1つのオペレーターのネットワークで数億個も）で自動化されるため、ユーザーアクションは必要ありません。すべてのネットワーク環境で使用するために、軽量のステートレスメカニズムを標準化することが示唆されています。このソリューションは、3GPP、3GPP2、およびその他のアクセスネットワークテクノロジーに使用できます。したがって、3GPPネットワークで必要とされる軽量で無国籍のIPv6 DNS構成メカニズムだけでなく、3GPPネットワークとUEも新しいメカニズムから確実に利益を得るでしょう。
Router Advertisement extension [6] is a lightweight IPv6 DNS configuration mechanism that requires minor changes in the 3GPP UE IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in the 3GPP architecture) IPv6 stack. This solution can be specified in the IETF (no action is needed in the 3GPP) and taken in use in 3GPP UEs and GGSNs.
Router Advertisement Extension [6]は、3GPP UE IPv6スタックとゲートウェイGPRSサポートノード（3GPPアーキテクチャのデフォルトルーター）IPv6スタックのマイナーな変更を必要とする軽量IPv6 DNS構成メカニズムです。このソリューションは、IETF（3GPPではアクションは必要ありません）で指定し、3GPP UESおよびGGSNSで使用できます。
In this solution, an IPv6-capable UE configures DNS information via an RA message sent by its default router (GGSN); i.e., the RDNSS option for a recursive DNS server is included in the RA message. This solution is easily scalable for a very large number of UEs. The operator can configure the RDNSS addresses in the GGSN as a part of normal GGSN configuration. The IPv6 RDNSS address is received in the Router Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS addresses can be avoided.
このソリューションでは、IPv6対応のUEは、デフォルトルーター（GGSN）によって送信されたRAメッセージを介してDNS情報を構成します。つまり、再帰的なDNSサーバーのRDNSSオプションがRAメッセージに含まれています。このソリューションは、非常に多数のUEに対して簡単にスケーラブルです。オペレーターは、通常のGGSN構成の一部としてGGSNでRDNSSアドレスを構成できます。IPv6 RDNSSアドレスはルーター広告で受信され、RDNSのアドレスを尋ねるための追加の往復時間（RTT）は回避できます。
When one considers the cons, this mechanism still requires standardization effort in the IETF, and the end nodes and routers need to support this mechanism. The equipment software update should, however, be pretty straightforward, and new IPv6 equipment could support RA extension already from the beginning.
短所を考慮すると、このメカニズムにはIETFでの標準化の取り組みが必要であり、エンドノードとルーターはこのメカニズムをサポートする必要があります。ただし、機器ソフトウェアの更新は非常に簡単である必要があり、新しいIPv6機器は最初からRA拡張をサポートできます。
A DHCPv6-based solution needs the implementation of Stateless DHCP [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the operator's network. A possible configuration is such that the GGSN works as a DHCP relay.
DHCPV6ベースのソリューションでは、UEでのステートレスDHCP [4]およびDHCPV6 DNSオプション[5]、およびオペレーターネットワークのDHCPV6サーバーの実装が必要です。可能な構成とは、GGSNがDHCPリレーとして機能するようなものです。
The pros of a stateless DHCPv6-based solution are:
ステートレスDHCPV6ベースのソリューションのプロは次のとおりです。
1. Stateless DHCPv6 is a standardized mechanism.
1. ステートレスDHCPV6は標準化されたメカニズムです。
2. DHCPv6 can be used for receiving configuration information other than RDNSS addresses; e.g., SIP server addresses.
2. DHCPV6は、RDNSSアドレス以外の構成情報を受信するために使用できます。たとえば、SIPサーバーアドレス。
3. DHCPv6 works in different network environments.
3. DHCPV6は、さまざまなネットワーク環境で動作します。
4. When DHCPv6 service is deployed through a single, centralized server, the RDNSS configuration information can be updated by the network administrator at a single source.
4. DHCPV6サービスが単一の集中サーバーを介して展開されると、RDNSS構成情報は、単一のソースでネットワーク管理者によって更新できます。
Some issues with DHCPv6 in 3GPP networks are listed below:
3GPPネットワークのDHCPV6のいくつかの問題を以下に示します。
1. DHCPv6 requires an additional server in the network unless the (Stateless) DHCPv6 functionality is integrated into an existing router. This means that there might be one additional server to be maintained.
1. DHCPV6は、（ステートレス）DHCPV6機能が既存のルーターに統合されていない限り、ネットワーク内の追加のサーバーを必要とします。これは、維持される追加のサーバーが1つある可能性があることを意味します。
2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing (3GPP Stateless Address Autoconfiguration is typically used) and is not automatically implemented in 3GPP IPv6 UEs.
2. DHCPV6は、3GPP UE IPv6アドレス指定（3GPP StatelessアドレスAutoconfigurationが通常使用される）に必ずしも必要ではなく、3GPP IPv6 UESで自動的に実装されていません。
3. Scalability and reliability of DHCPv6 in very large 3GPP networks (with tens or hundreds of millions of UEs) may be an issue; at least the redundancy needs to be taken care of. However, if the DHCPv6 service is integrated into the network elements, such as a router operating system, scalability and reliability is comparable with other DNS configuration approaches.
3. 非常に大きな3GPPネットワークにおけるDHCPV6のスケーラビリティと信頼性（数トンまたは数億UEの）が問題になる可能性があります。少なくとも冗長性を処理する必要があります。ただし、DHCPV6サービスがルーターオペレーティングシステムなどのネットワーク要素に統合されている場合、スケーラビリティと信頼性は他のDNS構成アプローチに匹敵します。
4. It is sub-optimal to utilize the radio resources in 3GPP networks for DHCPv6 messages if there is a simpler alternative is available.
4. より単純な代替手段がある場合、DHCPV6メッセージの3GPPネットワークで無線リソースを利用することは最適です。
* The use of stateless DHCPv6 adds one round-trip delay to the case in which the UE can start transmitting data right after the Router Advertisement.
* ステートレスDHCPV6を使用すると、ルーター広告の直後にUEがデータの送信を開始できる場合に、1回の往復遅延が追加されます。
5. If the DNS information (suddenly) changes, Stateless DHCPv6 cannot automatically update the UE; see [21].
5. DNS情報（突然）が変更された場合、Stateless DHCPV6はUEを自動的に更新できません。[21]を参照してください。
Using well-known addresses is also a feasible and light mechanism for 3GPP UEs. Those well-known addresses can be preconfigured in the UE software and the operator can make the corresponding configuration on the network side. Thus, this is a very easy mechanism for the UE, but it requires some configuration work in the network. When using well-known addresses, UE forwards queries to any of the preconfigured addresses. In the current proposal [7], IPv6 anycast addresses are suggested.
よく知られているアドレスを使用することは、3GPP UEの実現可能かつ軽いメカニズムでもあります。これらのよく知られているアドレスは、UEソフトウェアで事前に設定でき、オペレーターはネットワーク側に対応する構成を作成できます。したがって、これはUEにとって非常に簡単なメカニズムですが、ネットワークでの構成作業が必要です。よく知られているアドレスを使用する場合、UEは事前に設定されたアドレスのいずれかにクエリを転送します。現在の提案[7]では、IPv6 Anycastアドレスが提案されています。
Note: An IPv6 DNS configuration proposal, based on the use of well-known site-local addresses, was developed by the IPv6 Working Group; it was seen as a feasible mechanism for 3GPP UEs, although no IETF consensus was reached on this proposal. In the end, the deprecation of IPv6 site-local addresses made it impossible to standardize a mechanism that uses site-local addresses as well-known addresses. However, as of this writing, this mechanism is implemented in some operating systems and 3GPP UEs as a last resort of IPv6 DNS configuration.
注：有名なサイトローカルアドレスの使用に基づいたIPv6 DNS構成提案は、IPv6ワーキンググループによって開発されました。この提案についてはIETFのコンセンサスは達成されていませんが、3GPP UEの実行可能なメカニズムと見なされていました。最終的に、IPv6サイトローカルアドレスの非推奨により、サイトローカルアドレスをよく知られたアドレスとして使用するメカニズムを標準化することが不可能になりました。ただし、この記述の際に、このメカニズムは、IPv6 DNS構成の最後の手段として、一部のオペレーティングシステムと3GPP UEに実装されています。
It is suggested that a lightweight, stateless DNS configuration mechanism be specified as soon as possible. From a 3GPP UE and network point of view, the Router Advertisement-based mechanism looks most promising. The sooner a light, stateless mechanism is specified, the sooner we can stop using well-known site-local addresses for IPv6 DNS configuration.
軽量のステートレスDNS構成メカニズムをできるだけ早く指定することをお勧めします。3GPP UEとネットワークの観点から、ルーター広告ベースのメカニズムは最も有望に見えます。ライトが早く指定されているほど、IPv6 DNS構成のよく知られているサイトローカルアドレスの使用を早く停止できます。
There are four deployment scenarios of interest in unmanaged networks [22]:
管理されていないネットワークに関心のある4つの展開シナリオがあります[22]：
1. A gateway that does not provide IPv6 at all,
1. IPv6をまったく提供しないゲートウェイ、
2. A dual-stack gateway connected to a dual-stack ISP,
2. デュアルスタックISPに接続されたデュアルスタックゲートウェイ、
3. A dual-stack gateway connected to an IPv4-only ISP, and
3. IPv4のみのISPに接続されたデュアルスタックゲートウェイ、および
4. A gateway connected to an IPv6-only ISP.
4. IPv6のみのISPに接続されたゲートウェイ。
In this case, the gateway does not provide IPv6; the ISP may or may not provide IPv6. Automatic or Configured tunnels are the recommended transition mechanisms for this scenario.
この場合、ゲートウェイはIPv6を提供しません。ISPはIPv6を提供する場合と提供できない場合があります。このシナリオには、自動または構成されたトンネルが推奨される遷移メカニズムです。
The case where dual-stack hosts behind an NAT need access to an IPv6 RDNSS cannot be entirely ruled out. The DNS configuration mechanism has to work over the tunnel, and the underlying tunneling mechanism could implement NAT traversal. The tunnel server assumes the role of a relay (for both DHCP and well-known anycast addresses approaches).
IPv6 RDNSSへのNATニーズアクセスの背後にあるデュアルスタックホストが完全に除外できない場合。DNS構成メカニズムはトンネルを介して動作する必要があり、基礎となるトンネルメカニズムはNATトラバーサルを実装できます。トンネルサーバーは、リレーの役割を想定しています（DHCPと有名なAnycastアドレスの両方のアプローチ）。
The RA-based mechanism is relatively straightforward in its operation, assuming the tunnel server is also the IPv6 router emitting RAs. The well-known anycast addresses approach also seems simple in operation across the tunnel, but the deployment model using well-known anycast addresses in a tunneled environment is unclear or not well understood.
RAベースのメカニズムは、トンネルサーバーがRASを発するIPv6ルーターでもあると仮定して、その動作が比較的簡単です。よく知られているAnycastアドレスのアプローチもトンネル全体で動作しているように見えますが、トンネル環境でよく知られているAnycastアドレスを使用した展開モデルは不明であるか、よく理解されていません。
This is similar to a typical IPv4 home user scenario, where DNS configuration parameters are obtained using DHCP. The exception is that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where the DHCP server is stateful (it maintains the state for clients).
これは、DHCPを使用してDNS構成パラメーターが取得される典型的なIPv4ホームユーザーシナリオに似ています。例外は、DHCPサーバーがステートフルであるIPv4シナリオとは対照的に、Stateless Dhcpv6が使用されることです（クライアントの状態を維持しています）。
This is similar to Case B. If a gateway provides IPv6 connectivity by managing tunnels, then it is also supposed to provide access to an RDNSS. Like this, the tunnel for IPv6 connectivity originates from the dual-stack gateway instead of from the host.
これはケースBに似ています。ゲートウェイがトンネルを管理してIPv6接続を提供する場合、RDNSSへのアクセスも提供することになっています。このように、IPv6接続のトンネルは、ホストではなくデュアルスタックゲートウェイから発生します。
This is similar to Case B.
これはケースBに似ています
As security requirements depend solely on applications and differ from application to application, there can be no generic requirement defined at the IP or application layer for DNS.
セキュリティ要件はアプリケーションのみに依存しており、アプリケーションごとに異なるため、DNSのIPまたはアプリケーションレイヤーで定義される一般的な要件はありません。
However, note that cryptographic security requires configured secret information and that full autoconfiguration and cryptographic security are mutually exclusive. People insisting on secure, full autoconfiguration will get false security, false autoconfiguration, or both.
ただし、暗号化セキュリティには構成された秘密情報が必要であり、完全な自動構成と暗号化セキュリティは相互に排他的であることに注意してください。安全で完全な自動構成を主張する人々は、誤ったセキュリティ、誤検知、またはその両方を得るでしょう。
In some deployment scenarios [17], where cryptographic security is required for applications, the secret information for the cryptographic security is preconfigured, through which application-specific configuration data, including those for DNS, can be securely configured. Note that if applications requiring cryptographic security depend on DNS, the applications also require cryptographic security to DNS. Therefore, the full autoconfiguration of DNS is not acceptable.
アプリケーションに暗号化セキュリティが必要ないくつかの展開シナリオ[17]では、暗号化セキュリティの秘密情報が事前に構成されており、DNSを含むアプリケーション固有の構成データを安全に構成できます。暗号化セキュリティを必要とするアプリケーションがDNSに依存する場合、アプリケーションはDNSに暗号化セキュリティも必要であることに注意してください。したがって、DNSの完全な自動構成は受け入れられません。
However, with full autoconfiguration, weaker but still reasonable security is being widely accepted and will continue to be acceptable.
ただし、完全な自動構成により、弱いが合理的なセキュリティが広く受け入れられており、引き続き受け入れられます。
That is, with full autoconfiguration, which means there is no cryptographic security for the autoconfiguration, it is already assumed that the local environment is secure enough that the information from the local autoconfiguration server has acceptable security even without cryptographic security. Thus, the communication between the local DNS client and local DNS server has acceptable security.
つまり、完全なオートコンフィギュレーションを使用すると、自動構成に暗号化セキュリティがないことを意味します。ローカル環境は、ローカルオートコンフィグレーションサーバーからの情報が暗号化セキュリティがなくても許容できるセキュリティを持っているほど十分に安全であると想定されています。したがって、ローカルDNSクライアントとローカルDNSサーバー間の通信には、許容可能なセキュリティがあります。
In autoconfiguring recursive servers, DNSSEC may be overkill, because DNSSEC [23]-[25] needs the configuration and reconfiguration of clients at root key roll-over [26][27]. Even if additional keys for secure key roll-over are added at the initial configuration, they are as vulnerable as the original keys to some forms of attack, such as social hacking. Another problem of using DNSSEC and autoconfiguration together is that DNSSEC requires secure time, which means secure communication with autoconfigured time servers, which requires configured secret information. Therefore, in order that the autoconfiguration may be secure, configured secret information is required.
DNSSEC [23] - [25]がルートキーロールオーバー[26] [27]でクライアントの構成と再構成を必要とするため、Autoconfiging Recursiveサーバーでは、DNSSECが過剰になる可能性があります。セキュアなキーロールオーバーのための追加のキーが初期構成に追加されたとしても、ソーシャルハッキングなど、いくつかの形式の攻撃に対する元のキーと同じくらい脆弱です。DNSSECとAutoconfigurationを一緒に使用するもう1つの問題は、DNSSECには安全な時間が必要であることです。したがって、自動コンフィギュレーションが安全であるため、構成された秘密情報が必要です。
If DNSSEC [23]-[25] is used and the signatures are verified on the client host, the misconfiguration of a DNS server may simply be denial of service. Also, if local routing environment is not reliable, clients may be directed to a false resolver with the same IP address as the true one.
DNSSEC [23] - [25]が使用され、クライアントホストで署名が検証されている場合、DNSサーバーの誤解は単にサービスの拒否である可能性があります。また、ローカルルーティング環境が信頼できない場合、クライアントは、真のIPアドレスと同じIPアドレスを持つ誤ったリゾルバーに向けられる場合があります。
The security of RA option for RDNSS is the same as the ND protocol security [1][6]. The RA option does not add any new vulnerability.
RDNSSのRAオプションのセキュリティは、NDプロトコルセキュリティと同じです[1] [6]。RAオプションは、新しい脆弱性を追加しません。
Note that the vulnerability of ND is not worse and is a subset of the attacks that any node attached to a LAN can do independently of ND. A malicious node on a LAN can promiscuously receive packets for any router's MAC address and send packets with the router's MAC address as the source MAC address in the L2 header. As a result, the L2 switches send packets addressed to the router to the malicious node. Also, this attack can send redirects that tell the hosts to send their traffic somewhere else. The malicious node can send unsolicited RA or NA replies, answer RS or NS requests, etc. All of this can be done independently of implementing ND. Therefore, the RA option for RDNSS does not add to the vulnerability.
NDの脆弱性は悪くなく、LANに接続されたノードがNDとは独立して行うことができる攻撃のサブセットであることに注意してください。LANの悪意のあるノードは、ルーターのMacアドレスのパケットを無差別に受信し、L2ヘッダーのソースMACアドレスとしてルーターのMacアドレスを含むパケットを送信できます。その結果、L2スイッチは、悪意のあるノードにルーターにアドレス指定されたパケットを送信します。また、この攻撃は、ホストに他のどこかにトラフィックを送信するように指示するリダイレクトを送信する可能性があります。悪意のあるノードは、未承諾のRAまたはNAの応答を送信したり、RSまたはNSリクエストに応答したりできます。これはすべて、NDの実装とは独立して実行できます。したがって、RDNSSのRAオプションは脆弱性を追加しません。
Security issues regarding the ND protocol were discussed by the IETF SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for the ND security has been published [12].
NDプロトコルに関するセキュリティの問題は、IETF送信（近隣発見の保護）ワーキンググループによって議論され、NDセキュリティのRFC 3971が公開されました[12]。
The DNS Recursive Name Server option may be used by an intruder DHCP server to cause DHCP clients to send DNS queries to an intruder DNS recursive name server [5]. The results of these misdirected DNS queries may be used to spoof DNS names.
DNS Recursive Name Serverオプションは、侵入者DHCPサーバーによって使用され、DHCPクライアントがDNSクエリを侵入者DNS再帰名サーバーに送信することができます[5]。これらの誤った方向のDNSクエリの結果は、DNS名をスプーフィングするために使用できます。
To avoid attacks through the DNS Recursive Name Server option, the DHCP client SHOULD require DHCP authentication (see "Authentication of DHCP messages" in RFC 3315 [3][13]) before installing a list of DNS recursive name servers obtained through authenticated DHCP.
DNS再帰名サーバーオプションを介した攻撃を回避するには、DHCPクライアントはDHCP認証を必要とする必要があります（DHCP 3315 [3] [13]の「DHCPメッセージの認証」を参照）。
The well-known anycast addresses approach is not a protocol, thus there is no need to secure the protocol itself.
よく知られているAnycastアドレスアプローチはプロトコルではないため、プロトコル自体を保護する必要はありません。
However, denial of service attacks on the DNS resolver system might be easier to achieve as the anycast addresses used are by definition well known.
ただし、DNSリゾルバーシステムに対するサービス拒否攻撃は、使用されるAnycastアドレスが定義上よく知られているため、達成しやすいかもしれません。
Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Ave. Boxboro, MA 01719 US
Ralph Droms Cisco Systems、Inc。1414 Massachusetts Ave. Boxboro、MA 01719 US
Phone: +1 978 936 1674
EMail: rdroms@cisco.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
ロバートM.ヒンデンノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043米国
Phone: +1 650 625 2004 EMail: bob.hinden@nokia.com Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 US
電話：1 650 625 2004メール：bob.hinden@nokia.com Ted Lemon Nominum、Inc。950 Charter Street Redwood City、CA 94043 US
EMail: Ted.Lemon@nominum.com
Masataka Ohta Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152-8552 Japan
マサタカオタ東京工科大学2-12-1、O-Okayama、Meguro-Ku Tokyo 152-8552日本
Phone: +81 3 5734 3299
Fax: +81 3 5734 3299
EMail: mohta@necom830.hpcl.titech.ac.jp
Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-Gu Suwon, Gyeonggi-Do 443-742 Korea
スーホンダニエルパークモバイルプラットフォームラボラトリー、サムスンエレクトロニクス416マエタン-3dong、Yeongtong-gu Suwon、Gyeonggi-Do 443-742 Korea
Phone: +82 31 200 4508
EMail: soohong.park@samsung.com
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 US
Suresh Satapati Cisco Systems、Inc。San Jose、CA 95134 US
EMail: satapati@cisco.com
Juha Wiljakka Nokia Visiokatu 3 FIN-33720, TAMPERE Finland
Juha Wiljakka Nokia Visiokatu 3 Fin-33720、Tampere Finland
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com
This document has greatly benefited from inputs by David Meyer, Rob Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. Also, Tony Bonanno proofread this document. The authors appreciate their contribution.
この文書は、デビッド・マイヤー、ロブ・アウスタイン、タトゥヤ・ジンメイ、ペッカ・サヴォラ、ティム・チャウン、リュック・ベロエル、クリスチャン・フイテマ、トーマス・ナルテン、パスカル・ツバート、グレッグ・デイリーによる意見から大きな恩恵を受けています。また、Tony Bonannoはこのドキュメントを校正しています。著者は彼らの貢献に感謝しています。
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[1] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6の近隣発見（IPv6）」、RFC 2461、1998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[2] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[3] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6（DHCPV6）の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[4] DROMS、R。、「IPv6用のステートレスダイナミックホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[5] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[5] DROMS、R。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", Work in Progress, September 2005.
[6] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーター広告オプション」、2005年9月、作業進行中。
[7] Ohta, M., "Preconfigured DNS Server Addresses", Work in Progress, February 2004.
[7] Ohta、M。、「Preconfigured DNS Serverアドレス」、2004年2月に進行中の作業。
[8] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
[8] Venaas、S.、Chown、T。、およびB. Volz、「IPv6（DHCPV6）の動的ホスト構成プロトコルの情報更新時間オプション」、RFC 4242、2005年11月。
[9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[9] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月。
[10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[10] Hinden、R。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[11] Lind、M.、Ksinant、V.、Park、S.、Baudot、A。、およびP. Savola、「ISPネットワークにIPv6を導入するためのシナリオと分析」、RFC 4029、2005年3月。
[12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[12] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[13] Droms、R。およびW. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[14] バウンド、J。、「IPv6エンタープライズネットワークシナリオ」、RFC 4057、2005年6月。
[15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[15] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[16] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[16] Wasserman、M。、「第3世代パートナーシッププロジェクト（3GPP）規格におけるIPv6の推奨」、RFC 3314、2002年9月。
[17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003.
[17] Soininen、J。、「3GPPネットワークの移行シナリオ」、RFC 3574、2003年8月。
[18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[18] Wiljakka、J。、「第3世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6遷移に関する分析」、RFC 4215、2005年10月。
[19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[19] 3GPP TS 23.060 V5.4.0、「General Packet Radio Service（GPRS）;サービス説明;ステージ2（リリース5）」、2002年12月。
[20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003.
[20] 3GPP TS 24.008 V5.8.0、「モバイル無線インターフェイスレイヤー3仕様、コアネットワークプロトコル、ステージ3（リリース5）」、2003年6月。
[21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[21] Chown、T.、Venaas、S。、およびA. Vijayabhaskar、「IPv6（DHCPV6）のステートレス動的ホスト構成プロトコルの要件の変更」、RFC 4076、2005年5月。
[22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004.
[22] Huitema、C.、Austein、R.、Satapati、S。、およびR. van der Pol、「管理されていないネットワークIPv6トランジションシナリオ」、RFC 3750、2004年4月。
[23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[23] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[24] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のリソースレコード」、RFC 4034、2005年3月。
[25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[25] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。
[26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work in Progress, October 2005.
[26] Kolkman、O。およびR. Gieben、「DNSSEC運用慣行」、2005年10月、進行中の作業。
[27] Guette, G. and O. Courtay, "Requirements for Automated Key Rollover in DNSSEC", Work in Progress, January 2005.
[27] Guette、G。およびO. Courtay、「DNSSECの自動化されたキーロールオーバーの要件」、2005年1月、進行中の作業。
[28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M and O Flags of IPv6 Router Advertisement", Work in Progress, March 2005.
[28] Park、S.、Madanapalli、S。、およびT. Jinmei、「IPv6ルーター広告のMおよびOフラグに関する考慮事項」、2005年3月、進行中の作業。
Author's Address
著者の連絡先
Jaehoon Paul Jeong (editor) ETRI/Department of Computer Science and Engineering University of Minnesota 117 Pleasant Street SE Minneapolis, MN 55455 US
ジェフーンポールジョン（編集者）エトリ/ミネソタ州コンピュータサイエンスエンジニアリング大学117プレザントストリートSEミネアポリス、ミネソタ州55455米国
Phone: +1 651 587 7774
Fax: +1 612 625 2002
EMail: jjeong@cs.umn.edu
URI: http://www.cs.umn.edu/~jjeong/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。