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
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).
著作権（C）インターネット協会（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オプション」と「よく知られているエニーキャストが」この文書で説明するアプローチは、標準化されていません。結果的にこれらのアプローチのための分析は、将来的に提案している可能性のある具体的な提案に完全に適用できない場合があります。
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サーバー用のよく知られたエニーキャストアドレス：これは3つのソリューションの操作属性を詳述します。また、マルチ溶液分解能を考慮ネットワーク（ISP、企業、3GPP、および管理されていないネットワーク）の4種類で展開シナリオを示唆しています。
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ステートレスアドレス自動構成のための近隣探索（ND）は、1つの以上のIPv6アドレス、デフォルトルート、およびいくつかの他のパラメータとの固定または移動のいずれかのノードを構成する方法を提供する[1] [2]。 WebサーバなどDNS名で識別され、インターネットでの追加サービスへのアクセスをサポートするために、少なくとも一つの再帰的なDNSサーバーの設定も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サーバーのエニーキャストアドレスを周知します[7]。 （a）は、ISPのネットワーク、（b）は、企業ネットワーク、（c）は3GPPネットワーク、および（d）非管理ネットワーク：また、ネットワークの4種類の適用シナリオを示唆しています。
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のアプローチは、新たなNDオプションを定義し、再帰的なDNSサーバアドレスが含まれているRDNSSオプションを、と呼ばれる[6]。既存のND輸送機構（すなわち、広告及び勧誘）が使用されています。これは、ルータとプレフィックスについて学ぶノードと同じように動作します。 IPv6ホストは、定期的にルータによって送信またはルーター要請（RS）で募集RAメッセージを介して、1つ以上のRDNSSesの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メッセージは、[6]など、多くのRDNSSアドレスを含めることができます。
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のアプローチは、RAのオプションは、クライアントがクライアントに近いRDNSSesを使用することができます寿命フィールドが含まれているためRDNSSesのアドレスが変更されているいくつかのモバイル環境で有用です。これはエントリーから時間にクライアントを必要とし、別のRDNSSアドレス[6]に切り替わります値に設定することができます。しかし、実装の観点から、寿命フィールドは、もう少し複雑な問題を作るように思われます。代わりに、ちょうどそのようなRDNSSアドレスのリストについては、resolv.confのように、DNSの設定ファイルへの書き込み、私たちはRDNSSesの寿命を常に監視している周りのデーモン（または定義された間隔で呼び出されたプログラム）を持っている必要があり、すべての時間。
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は、いくつかのRDNSSes [6]のうち、一次RDNSSを選択するホストでき。これはRDNSSesの負荷分散のために使用することができます。
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オプションは、[1]〜[2]とベースNDプロトコルの変更を必要とせず、既存の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.ホストが（など、電子メール、ウェブ、FTP、など）基本的なインターネットアプリケーションを実行するために必要なすべての情報は、NDとアドレス自動設定するには、このオプションを追加で得ることができます。単一のメカニズムの使用は、より信頼性が高く、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）と低パフォーマンス（例えば、携帯電話ネットワーク）あるリンクでうまく動作します。後者の場合には、RAにおける他の情報とRDNSS情報を組み合わせることにより、ホストが単一のパケットでは、そのようなウェブなど、ほとんどのインターネットアプリケーションを使用するために必要なすべての情報を学ぶことができます。これは、帯域幅を節約するだけでなく、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フレームワークは、カーネル空間およびユーザ空間でDNS構成ファイル内RDNSSesための別のNDキャッシュ間の同期を容易にするために改変されなければなりません。それは書き込み、カーネルから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と自動設定と一緒に、ホストはそれがウェブのような基本的なインターネットサービスにアクセスするために必要なすべての情報を取得することを可能にする、電子メール、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]ホスト[5]再帰的なDNSサーバのIPアドレスのリストを取得することができ、それを通して「DNS再帰ネームサーバ」オプションが含まれています。 DNS再帰ネームサーバオプションは、ホストがDNSクエリを送信することにどのRDNSSesの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再帰ネームサーバオプションは、要求または情報要求メッセージのいずれかに応じて、任意のDHCPv6の応答メッセージで行うことができます。したがって、DNS再帰ネームサーバーオプションを使用することができるいずれかのDHCPv6は、アドレス割り当てのために使用される場合、またはDHCPv6のは、ステートレス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サーバを使用することによって、またはルータのハードウェアのいずれかで展開することができます。いくつかのルータベンダーは現在、ステートレスのDHCPv6サーバを実装します。ルータにステートレス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作業部会はRDNSSesのリストを含む構成情報は、更新することができ、それを通して、追加のメカニズムを標準化しています。 [8] DHCPv6の寿命オプションは、DHCPv6のを通して得られた情報を構成する、有効期間を割り当てます。生涯の満了時に、ホスト連絡DHCPv6サーバはRDNSSesのリストを含む更新された構成情報を、取得します。この寿命は、ネットワーク管理者にホストがリストをリフレッシュする時間を制御することによって、新しいRDNSSesでホストを構成する別のメカニズムを提供します。
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サーバを設定すると、ネットワーク管理者は、タイムゾーンなどRDNSSes、他のネットワークサービスのアドレス、およびロケーション固有の情報を、設定することができます。
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.
同じリンク上のホストが異なるRDNSSesとし、その他の構成情報を使用して構成することができるように、3のDHCPv6は、そのホストに固有の情報を持つホストの構成を可能にします。
4. A mechanism exists for extending DHCPv6 to support the transmission of additional configuration that has not yet been anticipated.
前記機構は、まだ予期されていない追加の構成の送信をサポートするための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.
そのようなSIPサーバとNTPサーバのアドレスなどの他の構成情報を必要とする5.ホストは、他の構成については、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のスルーRDNSSesの構成のための仕様は、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のは大きな利点と有意な欠点を提供します。ホストはRDNSSesのリストに加えて、他の構成情報が必要な場合、またはホストを選択的に構成する必要がある場合でも、帯域幅が貴重であり、低遅延が要求される場合には、これらのホストは、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.
しかし、我々はRAパケットにRDNSS情報を入れることが好ましいであろういくつかのアプリケーションを認識しています。例えば、帯域幅が貴重であり、非常に低レイテンシが要求される携帯電話ネットワークです。 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.
エニーキャストは、ユニキャストと同じルーティングシステムを使用する[9]。しかし、管理エンティティはローカルなものです。ローカルエンティティは、隣接するエンティティからエニーキャストサーバに（デフォルトルートを含む）ユニキャストルートを受け入れることができます。彼らはサーバーへのいくつかのピアからの外部アクセスを禁止したい場合は、管理エンティティは、その内部エニーキャストサーバへのピア・ルートをアドバタイズべきではありません。いくつかの広告が（例えばデフォルトルートの場合のように）避けられない場合は、サーバへのパケットは、エンティティの境界でブロックする必要があります。したがって、このエニーキャストのために、ユニキャストルーティングだけでなく、ユニキャスト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.
まず、よく知られたエニーキャストアドレスのアプローチは、過去にIPv6のワーキンググループで議論とはかなり異なっている[7]。このメモで「エニーキャスト」は、RFC 1546のそれよりも簡単であることに注意してください[9]およびRFC 3513 [10]、それは、エニーキャストアドレスを共有する単一のリンク上で複数のサーバーを持つことが禁止されると仮定されています。これは、リンクの上に、エニーキャストアドレスは一意であると仮定されています。 DNSクライアントは、今日はすでにRDNSSアドレスとして構成された複数のよく知られたエニーキャストアドレスを持つことで冗長性を持っています。単一リンク上でエニーキャストアドレスを共有する複数のRDNSSesを持っても意味がありません。
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].
よく知られたエニーキャストアドレスを持つアプローチは、工場出荷時のデフォルト、たとえば、として最初からクライアントのリゾルバ設定ファイルで複数のよく知られたエニーキャストアドレスを設定することです。したがって、いかなる搬送機構なしパケットフォーマット[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.
エニーキャストアドレスは、複数のサーバで共有アドレスである（この場合、サーバはRDNSSesあります）。エニーキャストアドレスへのクライアントからの要求は、ルーティングシステムによって選択されたサーバーにルーティングされます。しかし、ほとんどのユーザーが独自のサーバーを持っているし、自分のサイトの境界を越えて自分のISPにアクセスしたくないので、エニーキャストアドレスの「サイト」の境界を強制することは悪い考えです。大規模なサイトはまた、彼らのISPに依存してもよいか、「サイト」境界内に自分のRDNSSesを有することができます。
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.応答やパケットロスによるNOさらに遅延を取得するための遅延はありません。
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ベースの手法などの他の構成メカニズム、並びに工場出荷時のデフォルト設定と組み合わせることができます。
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.
もう一つの利点は、このアプローチが唯一のルータ（またはプロキシルータの設定）として、DNSサーバの設定を必要とすることです。 DNSサーバーで設定が必要なのかということを考えると、全体的な設定作業の量は、DNSサーバーの数に比例し、それが直線的に拡張します。なお、ISPへの加入者がDNSサーバーを持っていない最も単純なケースで、加入者は当然加入者とISPが何もしないし、DNSサーバの情報を交換するために何のプロトコルが存在しないにもかかわらず、ISPの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.
ルータは（いくつかの設定を必要とルーティングシステムにそのエニーキャストアドレスを広告スケーラビリティに前のセクションの最後の段落を参照するとしてよく知られているエニーキャストアドレスのアプローチは、その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.
他のアプローチを加えて使用している場合は、よく知られたエニーキャストアドレスは、ユーザーの設定の手間を軽減するために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.
前者のアプローチは、古いサーバはそのエニーキャストアドレスへの経路を生成することができますので、複数RDNSSesによって冗長性が良く、同じエニーキャストアドレスを共有する複数のサーバーによっては異なるエニーキャストアドレスを持つ複数のサーバによって提供されます。ドメインは、負荷分散が必要であることが非常に大きい場合を除きしたがって、ルーティングドメイン（またはDNSサーバを共有するドメイン）に、エニーキャストアドレスを持つ唯一のサーバが存在するであろう。
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.
中小ISPはすべての加入者によって共有されている各エニーキャストアドレスに1 RDNSSで動作します。大きなISPは、配布とRDNSSesの境界が固定されてもよい負荷を低減するために各エニーキャストアドレスで複数RDNSSesを操作する（冗長性が依然として複数のアドレスによって提供される）または動的に変更することができます。 （禁止されていないが）のISPは、自分の世話をすることができると期待されているとしてよく知られているエニーキャストアドレスとDNSパケットは、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.
このメモで「エニーキャストは、」RFC 1546のそれよりも簡単なので、[9]およびRFC 3513 [10]、管理上、このメモでエニーキャストアドレス、エニーキャストを共有し、単一のリンク上で複数のサーバーを持つことが禁止されると仮定した場合べきRFC 2461 [1]のユニキャストおよびRFC 3513 [10]として実装されてもよいです。その結果、ND-関連の不安定性が消えます。従って、周知のエニーキャストアドレスがアプローチでは、エニーキャストはとUDPおよびTCP応答パケットの送信元ユニキャスト（RFC 3513によれば、[10]）アドレスとしてエニーキャストアドレスを使用する必要ができます。ルートが反転すると、エニーキャストアドレスへのパケットは、新しいサーバーにルーティングされている場合、TCPでは、フリップがICMPまたはシーケンス番号矛盾によって検出されることが予想され、TCP接続がリセットされ、再試行されていることです。
Three approaches can work together for IPv6 host configuration of RDNSS. This section shows a consideration on how these approaches can interwork.
3つのアプローチは、RDNSSのIPv6ホストの設定のために一緒に働くことができます。このセクションでは、これらのアプローチが相互に作用することができますどのように配慮を示しています。
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ホストは、DHCPv6のを通してDNS設定を行うことができる[3] - [5]にかかわらず、Oフラグがセットされているか否かの。
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:
よく知られたエニーキャストアドレスは、完全に他のアプローチとのインターワークに近づきます。それは他のアプローチは、デフォルトの設定としてよく知られているアドレスを使用してサーバ上で設定作業を削除することができ、あります。また、クライアントは、よく知られているエニーキャストアドレスは、さらに他のアプローチからの構成情報が利用可能である場合、よく知られているアドレスを上書きする他の手法を使用するように構成することが可能で事前設定しました。それ以外の場合は、すべてのクライアントは、事前設定のよく知られたエニーキャストアドレスを持っている必要があります。以下の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情報を得ることができないとき、よく知られているアドレスは、最後の手段として使用されていることです。よく知られたエニーキャストアドレスは、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.最後には、よく知られているエニーキャストアドレスは、ユーザの設定の手間を軽減するために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のオプション、今日のようなよく知られている事前設定済みのエニーキャストアドレスとして、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は、バックボーンネットワークインフラ[11]複数のCPEデバイスを接続すること接続されていることです。 CPEは、ホストまたはルータであってもよいです。
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オプションは、[6] CPEはRDNSS情報とホストが新しいサブネットに接続されていると同時に、ステートレスアドレス自動設定のための/ 64プレフィックス情報を取得できるようにするために使用することができます。 IPv6ホストは、ステートレスアドレス自動設定とルータの設定のための少なくとも一つの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.
このアプローチは、管理者がルータのRDNSS情報を設定する必要がホストは、一般的に他のシナリオに比べて、新しいネットワークを検出するための少なくともRAメッセージを受信する必要があるモバイルホストのシナリオでは、より価値があります。 RAメッセージが使用されている場合、拡張セキュリティを提供することができND [12]を固定します。
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として、DHCPv6の場所にすでにある[5]とDHCPv6-liteのかステートレスDHCPは、[4]フルDHCPv6の実装ほど複雑ではありません。 ISPが意図的にそのネットワーク上のユーザーIDを扱うことができるようにDHCPは、クライアントサーバモデルのプロトコルです。また、セキュアなメッセージ交換のために使用することができる[13] DHCPを認証。
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.
ISPによるIPv6サービスを展開するための予想モデルは、顧客のネットワーク内の各ネットワークに/ 64プレフィックスを割り当てるために、顧客ゲートウェイによって使用される各顧客にプレフィックスを割り当てることです。 DHCP（DHCPv6のPD）を有するプレフィックス委譲は既に顧客ゲートウェイ[15]に顧客プレフィックスの割り当てを自動化するためのISPによって採用されています。 DNS構成は、顧客ゲートウェイまたは顧客ネットワークによって必要とされる他の任意の構成情報とともに、効率的にその情報を提供するために、DHCPv6のために使用される同一のDHCPv6メッセージ交換で行うことができます。このサービスモデルは、自宅やSOHO加入者に役立ちます。 ISPのカスタマーゲートウェイである家庭またはSOHOゲートウェイは、次いで、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.
よく知られているエニーキャストアドレスアプローチはまた、ISP [7]のために可能でシンプルな機構です。よく知られたエニーキャストアドレスの使用は、RAやDHCPv6のような外部プロトコルを介して送信される不正なメッセージでのセキュリティリスクのいくつかを回避することができます。周知のエニーキャストアドレスを使用するためのホストの構成はいかなるプロトコルまたは手動設定を必要としないが、エニーキャストアドレスのルーティングの設定は、ネットワーク管理者の一部に介入を必要とします。また、特殊なアドレスの数は、加入者が利用できるようにすることができRDNSSesの数に等しくなります。
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つ以上のルータの接続があり、積極的にネットワーク運用エンティティ[14]により管理されたネットワークとして定義されます。企業ネットワークは、手動設定またはプレフィックス委譲[15]によって、ISPからネットワークプレフィックスを取得することができます。企業ネットワークには独自のDNSドメインを管理しているため、ほとんどのケースでは、それはドメインの独自のDNSサーバーを動作させます。 IPv6はRDNSSesとしてホストから企業ネットワーク内のこれらのDNSサーバーは、再帰的なDNSの名前解決要求を処理します。それは次のように3つのアプローチを併用することができる、第4節にあるように、企業ネットワーク内のRDNSS設定を行うことができます。
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ホストは、[28]、または[6] RAメッセージ内のOフラグとそのサブネット内に使用することができるアプローチを決定することができます。第4節では最初の選択肢としては、よく知られたエニーキャストアドレスはRDNSS情報は、RAオプションまたはDHCPオプションのいずれかを介して取得することができない最後の手段として使用することができます。この場合は、IPv6が自分のDNSの設定ファイルでよく知られているエニーキャストアドレスを事前設定するホスト必要があります。
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.企業は、他の人によく知られているエニーキャストアプローチを好む場合、それは最初の選択肢であるように、IPv6ホストは、周知のエニーキャストアドレスを事前設定すべきです。
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.最後の選択肢、より便利かつ透明な方法は、IPv6が、彼らはユニキャストアドレスであるかのようにアドレスがRAオプションまたはDHCPv6のオプションのいずれかを経由して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自動設定および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とGGSNとの間の専用リンクのパケットデータプロトコル（PDP）コンテキストと呼ばれています。このリンクはPDPコンテキスト起動手順[19]を使用して作成されます。 IPv4およびIPv6トラフィック用に別のPDPコンテキストタイプがあります。 3GPP UEのユーザ（すなわち、アクティブのIPv6 PDPコンテキストを有することによって）IPv6を使用して通信している場合、ユーザが同時にアクティブのIPv4 PDPコンテキストを持っていると仮定することができず、DNSクエリはIPv4を使用して行うことができます。 3GPP UEは、このようにIPv6ノードとすることができ、何とかそれはRDNSSのアドレスを発見する必要があります。 IPベースのサービス（例えば、ウェブブラウジングや電子メール）を使用することができ、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に手動で入力したができます。最後の二つのメカニズムは非常によくスケーラブルではないことに注意してください。 UEユーザは、おそらくのIPv6 RDNSSは、ユーザのUEに手動でアドレスを入力する必要はありません。よく知られているアドレスの使用は、簡単にセクション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が関係なく、基盤となるネットワークインフラストラクチャが何であるか、ゼロコンフィギュレーションの方法で動作していないことを意図しています。一般的に、RDNSSアドレスはIPv6ノードを正常に動作させるために必要とされており、DNSの設定は、アドレス自動設定メカニズムのように単純にする必要があります。いくつかの近い将来の3GPP UEの中で、追加のIPインタフェースが存在することに注意してください。例えば、（例えば、PCO-IE [20]など）3GPP固有のDNS構成メカニズムは、これらの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コンフィギュレーション・ソリューションは、（1つの事業者のネットワークでも、何百、何百万の）IPv6対応のUEの非常に大きな数のために実現可能である、自動であり、したがって、ユーザーの操作は必要ありません。軽量、ステートレスなメカニズムは、すべてのネットワーク環境で使用するために標準化されることが示唆されます。次いで、溶液を、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.
ルータアドバタイズメント拡張[6] 3GPP UEのIPv6スタック内の軽微な変更を必要とゲートウェイGPRSサポートノード（GGSN、3GPPアーキテクチャにおけるデフォルトルータ）の軽量IPv6のDNS構成メカニズムIPv6スタックです。この溶液は、IETFで指定された（何もアクションが3GPPにおいて必要とされない）、および3GPPのUEとGGSNでの使用に取り込むことができます。
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アドレスは、ルータ広告で受信され、RDNSSアドレスを問い合わせるための余分なラウンドトリップ時間（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.
1の短所を考慮すると、このメカニズムはまだ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のベースのソリューションは、ステートレスDHCPの実装を必要とする[4]とDHCPv6 DNSオプション[5] UEで、オペレータのネットワークでDHCPv6サーバ。可能な構成は、GGSNはDHCPリレーとして働くようになっています。
The pros of a stateless DHCPv6-based solution are:
ステートレスDHCPv6のベースのソリューションの長所は、以下のとおりです。
2. DHCPv6 can be used for receiving configuration information other than RDNSS addresses; e.g., SIP server addresses.
2. DHCPv6のはRDNSSアドレス以外の構成情報を受信するために使用することができます。例えば、SIPサーバのアドレス。
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.
（ステートレス）のDHCPv6機能は既存のルータに統合されていない限り、1の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ステートレスアドレス自動設定が典型的に使用される）と、自動的に、3GPPのIPv6のUEに実装されていません。
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.
（UEの数千万または何百もの）非常に大規模な3GPPネットワーク内のDHCPv6 3.スケーラビリティおよび信頼性が問題であってもよいです。少なくとも、冗長性が世話をする必要があります。 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.
5. If the DNS information (suddenly) changes, Stateless DHCPv6 cannot automatically update the UE; see [21].
5. DNS情報（急に）変更された場合、ステートレス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エニーキャストアドレスが提案されています。
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]：
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).
NATの背後にあるデュアルスタックホストがIPv6 RDNSSへのアクセスを必要とする場合は、完全に排除することはできません。 DNS設定メカニズムは、トンネル上で動作するように持っており、基本的なトンネリングメカニズムはNATトラバーサルを実装することができます。トンネルサーバ（DHCPとよく知られているエニーキャストアドレスの両方のアプローチのために）リレーの役割を想定しています。
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ベースのメカニズムは、トンネルサーバはまた、RAの発光IPv6ルータであると仮定すると、その操作が比較的簡単です。よく知られたエニーキャストアドレスも近づいてトンネルを越えて運転中に簡単なようだが、トンネリングされた環境ではよく知られているエニーキャストアドレスを使用して展開モデルはよく理解不明確かではありません。
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).
これは、DNSの設定パラメータがDHCPを使用して得られた典型的なIPv4のホームユーザーのシナリオに似ています。例外は、DHCPサーバは、（それがクライアントの状態を維持する）ステートフルであるIPv4のシナリオとは対照的にステートレス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.
ゲートウェイは、またRDNSSへのアクセスを提供することになっている、トンネルを管理することにより、IPv6接続を提供する場合これは、ケースBに似ています。このように、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.
[25]ルートキーロールオーバでクライアントの構成および再構成を必要とする[27] [26] - DNSSEC [23]ので、再帰的サーバを自動設定では、DNSSECは、過剰であってもよいです。安全なキーロールオーバーのための追加キーは初期設定で追加された場合でも、彼らは、このような社会的なハッキングなどの攻撃のいくつかの形態、元のキーと同様に脆弱です。一緒にDNSSECと自動設定を使用してのもう一つの問題は、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アドレスを持つ偽リゾルバに向けることができます。
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スイッチは、悪意のあるノードへのルータ宛のパケットを送信します。また、この攻撃は、どこか自分のトラフィックを送信するホストを伝えるリダイレクトを送ることができます。このすべてが独立してNDを実装するのに行うことができますなど、悪意のあるノードは、非要請RAを送信することができますかNAは返信、RSまたはNS要求に答えます。したがって、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 SENDワーキンググループ（近隣探索の確保）、および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再帰ネームサーバオプションは、[5]侵入者のDNS再帰ネームサーバーにDNSクエリを送信するためにDHCPクライアントを引き起こすために、侵入者DHCPサーバによって使用することができます。これらの見当違いの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を介して取得DNS再帰ネームサーバのリストをインストールする前に、（[3] [13] RFC 3315で「DHCPメッセージの認証」を参照してください）要求すべきです。
The well-known anycast addresses approach is not a protocol, thus there is no need to secure the protocol itself.
よく知られているエニーキャストアドレスのアプローチは、このように、プロトコル自体を確保する必要がなく、プロトコルではありません。
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リゾルバシステム上のサービス拒否攻撃を使用エニーキャストアドレスは、定義によってよく知られているとして実現する方が簡単かもしれません。
Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Ave. Boxboro, MA 01719 US
ラルフDromsシスコシステムズ株式会社1414年マサチューセッツアベニュー。 Boxboro、MA 01719米国
Phone: +1 978 936 1674 EMail: rdroms@cisco.com
電話：+1 978 936 1674 Eメール：rdroms@cisco.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
ロバートM. Hindenとノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア州94043米国
Phone: +1 650 625 2004 EMail: bob.hinden@nokia.com
電話：+1 650 625 2004 Eメール：bob.hinden@nokia.com
Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 US
テッド・レモンノミナム社950憲章ストリートレッドウッドシティ、CA 94043米国
EMail: Ted.Lemon@nominum.com
メールアドレス：Ted.Lemon@nominum.com
Masataka Ohta Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152-8552 Japan
まさたか おｈた ときょ いんｓちつて おｆ てｃｈのぉｇｙ ２ー１２ー１、 おーおかやま、 めぐろーく ときょ １５２ー８５５２ じゃぱん
Phone: +81 3 5734 3299 Fax: +81 3 5734 3299 EMail: mohta@necom830.hpcl.titech.ac.jp
電話：+81 3 5734 3299ファックス：+81 3 5734 3299 Eメール：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
Soohongダニエル・パークモバイルプラットフォーム研究所、三星電子416 Maetan-3dong、霊通区水原、京畿道443から742韓国
Phone: +82 31 200 4508 EMail: soohong.park@samsung.com
電話：+82 31 200 4508 Eメール：soohong.park@samsung.com
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 US
スレシュSatapatiシスコシステムズ社サンノゼ、CA 95134米国
EMail: satapati@cisco.com
メールアドレス：satapati@cisco.com
Juha Wiljakka Nokia Visiokatu 3 FIN-33720, TAMPERE Finland
ユハWiljakkaノキアビジョンストリート3 FIN-33720タンペレフィンランド
Phone: +358 7180 48372 EMail: juha.wiljakka@nokia.com
電話：+358 7180 48372電子メール：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.
この文書では、大幅にデビッド・マイヤー、ロブAusteinと、達也神明、ペッカSavola、ティムのchown、リュックBeloeilの、クリスチャンのHuitema、トーマスNarten氏、パスカルThubert、およびグレッグデイリーにより入力から恩恵を受けています。また、トニー・ボナーノはこの文書を校正しました。作者は彼らの貢献に感謝しています。
[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.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[2]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "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]、RFC 3646、2003年12月Droms、R.、 "IPv6の動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション" を。
[6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", Work in Progress, September 2005.
[6]チョン、J.、公園、S.、Beloeilの、L.、およびS. Madanapalli、 "DNS設定のためのIPv6ルータアドバタイズメント・オプション"、進歩、2005年9月で仕事を。
[7] Ohta, M., "Preconfigured DNS Server Addresses", Work in Progress, February 2004.
[7]太田、M.、 "設定済みのDNSサーバーアドレス"、進歩、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.フォルツ、RFC 4242、2005年11月の "IPv6のための動的ホスト構成プロトコル（DHCPv6の）のための情報更新時間オプションを"。
[9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[9]ウズラ、C.、メンデス、T.、およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[10] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン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]リンド、M.、Ksinant、V.、公園、S.、ボドー、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.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[16] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[16]ワッサーマン、M.、RFC 3314 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための提言"、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.、RFC 4215 "第三世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6移行に関する分析"、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、 "汎用パケット無線サービス（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、RFC 4076、2005年5月 "IPv6のステートレス動的ホスト構成プロトコル（DHCPv6の）のための番号を付け替える要件"。
[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.のファンデルポール、 "非管理ネットワークの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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]パーク、S.、Madanapalli、S.、およびT.神明、 "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
Jaehoonポール・チョン（エディタ）コンピュータサイエンスとミネソタ117プレザントストリートSEミネアポリス、MN 55455米国のエンジニアリング大学のETRI /教室
Phone: +1 651 587 7774 Fax: +1 612 625 2002 EMail: jjeong@cs.umn.edu URI: http://www.cs.umn.edu/~jjeong/
電話：+1 651 587 7774ファックス：+1 612 625 2002 Eメール：jjeong@cs.umn.edu URI：http://www.cs.umn.edu/~jjeong/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。