Network Working Group                                      J. Jeong, Ed.
Request for Comments: 5006                  ETRI/University of Minnesota
Category: Experimental                                           S. Park
                                                     SAMSUNG Electronics
                                                              L. Beloeil
                                                      France Telecom R&D
                                                          S. Madanapalli
                                                      Ordyn Technologies
                                                          September 2007
         IPv6 Router Advertisement Option for DNS Configuration

Status of This Memo


This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.




This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Applicability Statements . . . . . . . . . . . . . . . . .  2
     1.2.  Coexistence of RDNSS Option and DHCP Option  . . . . . . .  2
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  Neighbor Discovery Extension . . . . . . . . . . . . . . . . .  4
     5.1.  Recursive DNS Server Option  . . . . . . . . . . . . . . .  4
     5.2.  Procedure of DNS Configuration . . . . . . . . . . . . . .  5
       5.2.1.  Procedure in IPv6 Host . . . . . . . . . . . . . . . .  5
   6.  Implementation Considerations  . . . . . . . . . . . . . . . .  6
     6.1.  DNS Server List Management . . . . . . . . . . . . . . . .  6
     6.2.  Synchronization between DNS Server List and Resolver
           Repository . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . .  9
1. Introduction
1. はじめに

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 routers and some other parameters [2][3]. 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アドレス、デフォルトルータおよびいくつかの他のパラメータとの固定または移動のいずれかのノードを構成する方法を提供する[2] [3]。 WebサーバなどDNS名で識別され、インターネットでの追加サービスへのアクセスをサポートするために、少なくとも一つの再帰的なDNSサーバーの設定もDNSの名前解決のために必要とされています。

It is infeasible for nomadic hosts, such as laptops, to be configured manually with a DNS resolver each time they connect to a different wireless LAN (WLAN) such as IEEE 802.11 a/b/g [12]-[15]. Normally, DHCP [6]-[8] is used to locate such resolvers. This document provides an alternate, experimental mechanism which uses a new IPv6 Router Advertisement (RA) option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts.

それはラップトップなどノマディックホストのため実行不可能である、IEEE 802.11 / B / GとしてDNSリゾルバを使用して手動でそれらは、異なる無線LAN(WLAN)に接続するたびに設定する[12] - [15]。通常、DHCP [6] - [8]このようなレゾルバの位置を特定するために使用されます。この文書は、IPv6ルーターがIPv6ホストにDNSの再帰的サーバーのアドレスを宣伝することを可能にする新しいIPv6ルーター広告(RA)オプションを使用する代替、実験的なメカニズムを提供します。

1.1. Applicability Statements
1.1. 適用性ステートメント

The only standards-track DNS configuration mechanism in the IETF is DHCP, and its support in hosts and routers is necessary for reasons of interoperability.


RA-based DNS configuration is a useful, optional alternative in networks where an IPv6 host's address is autoconfigured through IPv6 stateless address autoconfiguration, and where the delays in acquiring server addresses and communicating with the servers are critical. RA-based DNS configuration allows the host to acquire the nearest server addresses on every link. Furthermore, it learns these addresses from the same RA message that provides configuration information for the link, thereby avoiding an additional protocol run. This can be beneficial in some mobile environments, such as with Mobile IPv6 [10].

RAベースのDNSの設定は、IPv6ホストのアドレスがIPv6ステートレスアドレス自動設定による自動設定されるネットワークで有用で、オプションの代替であり、サーバのアドレスを取得し、サーバとの通信に遅延が極めて重要であるところ。 RAベースのDNSの設定は、ホストがすべてのリンクに最も近いサーバーアドレスを取得することができます。さらに、それによって追加のプロトコルの実行を回避する、リンクの構成情報を提供するのと同じRAメッセージから、これらのアドレスを学習します。これは、モバイルIPv6 [10]と同様に、いくつかのモバイル環境において有益であり得ます。

The advantages and disadvantages of the RA-based approach are discussed in [9] along with other approaches, such as the DHCP and well-known anycast addresses approaches.


1.2. Coexistence of RDNSS Option and DHCP Option
1.2. RDNSSオプションとDHCPオプションの共存

The RDNSS (Recursive DNS Server) option and DHCP option can be used together [9]. To order the RA and DHCP approaches, the O (Other stateful configuration) flag can be used in the RA message [2]. If no RDNSS option is included in the RA messages, an IPv6 host may perform DNS configuration through DHCPv6 [6]-[8] regardless of whether the O flag is set or not.

RDNSS(再帰DNSサーバ)オプションとDHCPオプションを一緒に使用することができる[9]。 RAとDHCPアプローチを注文するために、O(その他のステートフル設定)フラグがRAメッセージで使用することができる[2]。何RDNSSオプションがRAメッセージに含まれていない場合、IPv6ホストは、DHCPv6のを通してDNS設定を行うことができる[6] - [8]にかかわらず、Oフラグがセットされているか否かの。

2. Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。

3. Terminology

This document uses the terminology described in [2] and [3]. In addition, four new terms are defined below:


o Recursive DNS Server (RDNSS): Server which provides a recursive DNS resolution service for translating domain names into IP addresses as defined in [4] and [5].


o RDNSS Option: IPv6 RA option to deliver the RDNSS information to IPv6 hosts [2].

RDNSSオプションO:IPv6ホストにRDNSS情報を提供するためのIPv6 RAオプション[2]。

o DNS Server List: A data structure for managing DNS Server Information in the IPv6 protocol stack in addition to the Neighbor Cache and Destination Cache for Neighbor Discovery [2].


o Resolver Repository: Configuration repository with RDNSS addresses that a DNS resolver on the host uses for DNS name resolution; for example, the Unix resolver file (i.e., /etc/resolv.conf) and Windows registry.


4. Overview

This document defines a new ND option called RDNSS option that contains the addresses of recursive DNS servers. Existing ND transport mechanisms (i.e., advertisements and solicitations) are used. This works in the same way that hosts learn about routers and prefixes. An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA messages periodically sent by a router or solicited by a Router Solicitation (RS).

この文書では、再帰的なDNSサーバのアドレスが含まれているRDNSSオプションと呼ばれる新しいNDオプションを定義します。既存のND輸送機構(すなわち、広告及び勧誘)が使用されています。これは、ホストがルーターとプレフィックスを学ぶのと同じように動作します。 IPv6ホストは、定期的にルータによって送信またはルーター要請(RS)によって勧誘RAメッセージを介して、1つ以上のRDNSSesのIPv6アドレスを設定することができます。

Through the RDNSS option, along with the prefix information option based on the ND protocol ([2] and [3]), an IPv6 host can perform network configuration of its IPv6 address and RDNSS simultaneously without needing a separate message exchange for the RDNSS information. The RA option for RDNSS can be used on any network that supports the use of ND.

NDプロトコルに基づいて、プレフィックス情報オプションと共に、RDNSSオプションを介して([2]及び[3])、IPv6ホストはRDNSS情報のための別個のメッセージ交換を必要とせず、同時に、そのIPv6アドレスとRDNSSのネットワーク設定を行うことができ。 RDNSSのためのRAオプションは、NDの使用をサポートする任意のネットワーク上で使用することができます。

This approach requires RDNSS information to be configured in the routers sending the advertisements. The configuration of RDNSS addresses in the routers can be done by manual configuration. The automatic configuration or redistribution of RDNSS information is possible by running a DHCPv6 client on the router [6]-[8]. The automatic configuration of RDNSS addresses in routers is out of scope for this document.

このアプローチは、広告を送信して、ルータに設定するRDNSS情報が必要です。ルータでのRDNSSアドレスの設定は手動設定で行うことができます。 RDNSS情報の自動設定または再配布は、ルータ上のDHCPv6クライアントを実行することが可能である[6] - [8]。ルータでのRDNSSアドレスの自動設定はこの文書の範囲外です。

5. Neighbor Discovery Extension

The IPv6 DNS configuration mechanism in this document needs a new ND option in Neighbor Discovery: the Recursive DNS Server (RDNSS) option.


5.1. Recursive DNS Server Option
5.1. 再帰DNSサーバオプション

The RDNSS option contains one or more IPv6 addresses of recursive DNS servers. All of the addresses share the same lifetime value. If it is desirable to have different lifetime values, multiple RDNSS options can be used. Figure 1 shows the format of the RDNSS option.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |     Type      |     Length    |           Reserved            |
     |                           Lifetime                            |
     |                                                               |
     :            Addresses of IPv6 Recursive DNS Servers            :
     |                                                               |

Figure 1: Recursive DNS Server (RDNSS) Option Format




Type 8-bit identifier of the RDNSS option type as assigned by the IANA: 25


Length 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. The minimum value is 3 if one IPv6 address is contained in the option. Every additional RDNSS address increases the length by 2. The Length field is used by the receiver to determine the number of IPv6 addresses in the option.

長さ8ビットの符号なし整数。 (タイプと長さフィールドを含む)オプションの長さは8つのオクテット単位です。 1つのIPv6アドレスがオプションに含まれている場合、最小値は3です。すべての追加のRDNSSアドレスは、長さフィールドはオプションでIPv6アドレスの数を決定するために受信機によって使用される2により長さを増加させます。

Lifetime 32-bit unsigned integer. The maximum time, in seconds (relative to the time the packet is sent), over which this RDNSS address MAY be used for name resolution. Hosts MAY send a Router Solicitation to ensure the RDNSS information is fresh before the interval expires. In order to provide fixed hosts with stable DNS service and allow mobile hosts to prefer local RDNSSes to remote RDNSSes, the value of Lifetime should be at least as long as the Maximum RA Interval (MaxRtrAdvInterval) in RFC 4861, and be at most as long as two times MaxRtrAdvInterval; Lifetime SHOULD be bounded as follows: MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval. A value of all one bits (0xffffffff) represents infinity. A value of zero means that the RDNSS address MUST no longer be used.

寿命32ビット符号なし整数。このRDNSSアドレスを名前解決に使用することができる上に、(パケットが送信される時間と比較して)秒の最大時間。ホストは間隔が切れる前にRDNSS情報が新鮮であることを確認するためにルータ要請を送信することができます。安定したDNSサービスと固定ホストに提供し、モバイルホストがリモートRDNSSesローカルRDNSSesを好むことを可能にするために、ライフタイムの値は、RFC 4861で、少なくとも限り最大RA間隔(MaxRtrAdvInterval)としてもよく、最大であればなければなりません2倍のMaxRtrAdvInterval。 MaxRtrAdvInterval <=寿命<= 2 * MaxRtrAdvInterval次のように寿命が境界されるべきです。全ての1つのビット(0xFFFFFFFFを)の値は無限を表します。ゼロの値はRDNSSアドレスがもはや使用されなければならないことを意味します。

Addresses of IPv6 Recursive DNS Servers One or more 128-bit IPv6 addresses of the recursive DNS servers. The number of addresses is determined by the Length field. That is, the number of addresses is equal to (Length - 1) / 2.

IPv6の再帰的なDNSサーバーのアドレスを再帰的なDNSサーバの一つ以上の128ビットのIPv6アドレス。アドレスの数は、長さフィールドによって決定されます。すなわち、アドレスの数に等しいである(長さ - 1)/ 2。

5.2. Procedure of DNS Configuration
5.2. DNS設定の手順

The procedure of DNS configuration through the RDNSS option is the same as with any other ND option [2].


5.2.1. Procedure in IPv6 Host
5.2.1. IPv6ホストの手順

When an IPv6 host receives an RDNSS option through RA, it checks whether the option is valid.


o If the RDNSS option is valid, the host SHOULD copy the option's value into the DNS Server List and the Resolver Repository as long as the value of the Length field is greater than or equal to the minimum value (3). The host MAY ignore additional RDNSS addresses within an RDNSS option and/or additional RDNSS options within an RA when it has gathered a sufficient number of RDNSS addresses.


o If the RDNSS option is invalid (e.g., the Length field has a value less than 3), the host SHOULD discard the option.


6. Implementation Considerations

Note: This non-normative section gives some hints for implementing the processing of the RDNSS option in an IPv6 host.


For the configuration and management of RDNSS information, the advertised RDNSS addresses can be stored and managed in both the DNS Server List and the Resolver Repository.


In environments where the RDNSS information is stored in user space and ND runs in the kernel, it is necessary to synchronize the DNS Server List of RDNSS addresses in kernel space and the Resolver Repository in user space. For the synchronization, an implementation where ND works in the kernel should provide a write operation for updating RDNSS information from the kernel to the Resolver Repository. One simple approach is to have a daemon (or a program that is called at defined intervals) that keeps monitoring the lifetime of RDNSS addresses all the time. Whenever there is an expired entry in the DNS Server List, the daemon can delete the corresponding entry from the Resolver Repository.

RDNSS情報がユーザ空間に保存されているとNDは、カーネル内で実行される環境では、カーネル空間とユーザ空間のリゾルバ倉庫にRDNSSアドレスのDNSサーバーのリストを同期させる必要があります。同期では、NDがカーネルで動作する実装はリゾルバ倉庫にカーネルからRDNSS情報を更新するための書き込み動作を提供する必要があります。一つの簡単な方法は、すべての時間を扱うRDNSSの寿命を監視し続けるデーモン(または定義された間隔で呼び出されたプログラム)を持つことです。 DNSサーバーリストの期限切れのエントリがあるたびに、デーモンはリゾルバ倉庫から対応するエントリを削除することができます。

6.1. DNS Server List Management
6.1. DNSサーバーリストの管理

The kernel or user-space process (depending on where RAs are processed) should maintain a data structure called a DNS Server List which keeps the list of RDNSS addresses. Each entry in the DNS Server List consists of an RDNSS address and Expiration-time as follows:


o RDNSS address: IPv6 address of the Recursive DNS Server, which is available for recursive DNS resolution service in the network advertising the RDNSS option; such a network is called site in this document.

O RDNSSアドレス:RDNSSオプションを宣伝し、ネットワーク内の再帰的なDNS解決サービスのために利用可能である再帰DNSサーバのIPv6アドレス。そのようなネットワークは、この文書に記載されているサイトと呼ばれています。

o Expiration-time: The time when this entry becomes invalid. Expiration-time is set to the value of the Lifetime field of the RDNSS option plus the current system time. Whenever a new RDNSS option with the same address is received, this field is updated to have a new expiration time. When Expiration-time becomes less than the current system time, this entry is regarded as expired.


Note: An RDNSS address MUST be used only as long as both the RA router lifetime and the RDNSS option lifetime have not expired. The reason is that the RDNSS may not be currently reachable or may not provide service to the host's current address (e.g., due to network ingress filtering [16][17]).

注意:RDNSSアドレスは限りRAルータ寿命とRDNSSオプションの寿命の両方の期限が切れていないとして使用しなければなりません。理由はRDNSSが現在到達可能でないか、またはホストの現在のアドレスにサービスを提供しないかもしれないということである(例えば、イングレスフィルタリングをネットワークに起因する[16] [17])。

6.2. Synchronization between DNS Server List and Resolver Repository
6.2. DNSサーバリストとリゾルバ倉庫間の同期

When an IPv6 host receives the information of multiple RDNSS addresses within a site through an RA message with RDNSS option(s), it stores the RDNSS addresses (in order) into both the DNS Server List and the Resolver Repository. The processing of the RDNSS option(s) included in an RA message is as follows:

IPv6ホストがRDNSSオプション(複数可)を有するRAメッセージを介してサイト内の複数のRDNSSアドレスの情報を受信すると、DNSサーバリストとリゾルバリポジトリの両方に(順番に)RDNSSアドレスを格納します。 RDNSSオプション(複数可)の処理は、RAメッセージに含まれる以下の通りであります:

Step (a): Receive and parse the RDNSS option(s). For the RDNSS addresses in each RDNSS option, perform Step (b) through Step (d). Note that Step (e) is performed whenever an entry expires in the DNS Server List.


Step (b): For each RDNSS address, check the following: If the RDNSS address already exists in the DNS Server List and the RDNSS option's Lifetime field is set to zero, delete the corresponding RDNSS entry from both the DNS Server List and the Resolver Repository in order to prevent the RDNSS address from being used any more for certain reasons in network management, e.g., the breakdown of the RDNSS or a renumbering situation. The processing of this RDNSS address is finished here. Otherwise, go to Step (c).


Step (c): For each RDNSS address, if it already exists in the DNS Server List, then just update the value of the Expiration-time field according to the procedure specified in the second bullet of Section 6.1. Otherwise, go to Step (d).


Step (d): For each RDNSS address, if it does not exist in the DNS Server List, register the RDNSS address and lifetime with the DNS Server List and then insert the RDNSS address in front of the Resolver Repository. In the case where the data structure for the DNS Server List is full of RDNSS entries, delete from the DNS Server List the entry with the shortest expiration time (i.e., the entry that will expire first). The corresponding RDNSS address is also deleted from the Resolver Repository. In the order in the RDNSS option, position the newly added RDNSS addresses in front of the Resolver Repository so that the new RDNSS addresses may be preferred according to their order in the RDNSS option for the DNS name resolution. The processing of these RDNSS addresses is finished here. Note that, in the case where there are several routers advertising RDNSS option(s) in a subnet, the RDNSSes that have been announced recently are preferred.

工程(d):それはDNSサーバーの一覧に存在しない場合は、各RDNSSアドレスの場合は、DNSサーバーの一覧でRDNSSアドレスと寿命を登録して、リゾルバ倉庫の前でRDNSSアドレスを挿入します。 DNSサーバのリストのためのデータ構造はRDNSSエントリに満ちている場合には、DNSサーバー一覧から最短有効期限のエントリ(最初の期限切れとなる、すなわち、エントリ)を削除します。対応するRDNSSアドレスもリゾルバリポジトリから削除されます。新しいRDNSSアドレスがDNS名前解決のためのRDNSSオプションでそれらの順序に従って好まれ得るようにRDNSSオプション順に、リゾルバリポジトリの前に新たに追加されたRDNSSアドレスを位置付けます。これらのRDNSSアドレスの処理はここで終了します。サブネット内の複数のルータ広告RDNSSオプション(複数可)が存在する場合には、最近発表されているRDNSSesが好ましい、ということに注意してください。

Step (e): Delete each expired entry from the DNS Server List, and delete the RDNSS address corresponding to the entry from the Resolver Repository.


7. Security Considerations

The security of the RA option for RDNSS might be worse than ND protocol security [2]. However, any new vulnerability in this RA option is not known yet. In this context, it can be claimed 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, 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 Neighbor Advertisement (NA) replies, answer RS or Neighbor Solicitation (NS) requests, etc. Also, an attacker could configure a host to send out an RA with a fraudulent RDNSS address, which is presumably an easier avenue of attack than becoming a rogue router and having to process all traffic for the subnet. It is necessary to disable the RA RDNSS option in both routers and clients administratively to avoid this problem. All of this can be done independently of implementing ND. Therefore, it can be claimed that the RA option for RDNSS has vulnerabilities similar to those existing in current mechanisms.

RDNSSのためのRAオプションのセキュリティは、NDプロトコルセキュリティ[2]より悪いかもしれません。しかし、このRAオプションのいずれかの新しい脆弱性は、まだ知られていません。この文脈では、NDの脆弱性が悪化していないと、LANに接続されているすべてのノードはNDとは独立して行うことができます攻撃のサブセットであることを主張することができます。 LAN上の悪意のあるノードは、無差別任意のルータのMACアドレスのパケットを受信すると、L2ヘッダ内の送信元MACアドレスとしてルータのMACアドレスを持つパケットを送信することができます。結果として、L2スイッチは、悪意のあるノードへのルータ宛のパケットを送信します。また、この攻撃は、どこか自分のトラフィックを送信するホストを伝えるリダイレクトを送ることができます。悪意のあるノード迷惑RAや近隣広告(NA)応答を送信することができ、攻撃者はおそらくある詐欺RDNSSアドレス、とRAを送信するホストを設定することができ、また、などRSまたは近隣要請(NS)の要求に答えます不正なルータになることやサブネットのすべてのトラフィックを処理するよりも、攻撃の容易な道。この問題を回避するために、管理上のルーターとクライアントの両方でRA RDNSSオプションを無効にする必要があります。このすべてが独立してNDを実装するのに行うことができます。したがって、RDNSSのためのRAオプションは現在のメカニズムに存在するものと同様の脆弱性を持っていると主張することができます。

If the Secure Neighbor Discovery (SEND) protocol is used as a security mechanism for ND, all the ND options including the RDNSS option are automatically included in the signatures [11], so the RDNSS transport is integrity-protected. However, since any valid SEND node can still insert RDNSS options, SEND cannot verify who is or is not authorized to send the options.


8. IANA Considerations
8. IANAの考慮事項

The IANA has assigned a new IPv6 Neighbor Discovery Option type for the RDNSS option defined in this document.


                 Option Name               Type
                 RDNSS option              25

The IANA registry for these options is:



9. Acknowledgements

This document has greatly benefited from inputs by Robert Hinden, Pekka Savola, Iljitsch van Beijnum, Brian Haberman and Tim Chown. The authors appreciate their contributions.


10. References
10.1. Normative References
10.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.

[2] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、RFC 4861 "IPバージョン6(IPv6)のための近隣探索" 2007年9月。

[3] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[3]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。

10.2. Informative References
10.2. 参考文献

[4] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987.

[4] Mockapetris、P.、 "ドメイン名 - 概念と施設"、RFC 1034、1987年11月。

[5] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987.

[5] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、RFC 1035、1987年11月。

[6] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[6] Droms、R.、エド。、 "IPv6の動的ホスト構成プロトコル(DHCPv6)"、RFC 3315、2003年7月。

[7] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.

[7] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル(DHCP)サービス"、RFC 3736、2004年4月。

[8] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.

[8] Droms、R.、エド。、RFC 3646、2003年12月、 "IPv6の動的ホスト構成プロトコル(DHCPv6)のためのDNSの設定オプション"。

[9] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.

[9]チョン、J.、エド。、 "DNSサーバ情報のアプローチのIPv6ホストの設定"、RFC 4339、2006年2月を。

[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[10]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。

[11] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[11] Arkko、J.、編、 "セキュア近隣探索(SEND)"、RFC 3971、2005年3月。

[12] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", March 1999.

[12] ANSI / IEEE規格802.​​11、 "パート11:無線LAN媒体アクセス制御(MAC)および物理層(PHY)仕様"、1999年3月。

[13] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ Band", September 1999.

[13] IEEE標準の802.11aの、「パート11:無線LAN媒体アクセス制御(MAC)および物理層(PHY)仕様:5GHz帯における高速物理層」、1999年9月。

[14] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Higher-Speed Physical Layer Extension in the 2.4 GHz Band", September 1999.

[14] IEEE規格の802.11bの、「パート11:無線LAN媒体アクセス制御(MAC)および物理層(PHY)仕様:2.4GHz帯における高速物理層の拡張」、1999年9月。

[15] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Further Higher Data Rate Extension in the 2.4 GHz Band", April 2003.

[15] IEEE P802.11g / D8.2、 "パート11:無線LAN媒体アクセス制御(MAC)および物理層(PHY)仕様:2.4GHz帯におけるより高いデータレート拡張"、2003年4月。

[16] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", Work in Progress, July 2007.


[17] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.

[17]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング:IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。

Authors' Addresses


Jaehoon Paul Jeong (editor) ETRI/Department of Computer Science and Engineering University of Minnesota 117 Pleasant Street SE Minneapolis, MN 55455 USA

Jaehoonポール・チョン(エディタ)コンピュータサイエンスとミネソタ117プレザントストリートSEミネアポリス、MN 55455 USAのエンジニアリング大学のETRI /教室

Phone: +1 651 587 7774 Fax: +1 612 625 0572 EMail: URI:

電話:+1 651 587 7774ファックス:+1 612 625 0572 Eメール URI:

Soohong Daniel Park Mobile Convergence 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:

電話:+82 31 200 4508 Eメール

Luc Beloeil France Telecom R&D 42, rue des coutures BP 6243 14066 CAEN Cedex 4 France

ルカBeloeilのフランステレコムR&D 42、縫合通りBP 6243 14066カーンセデックス4フランス

Phone: +33 02 3175 9391 EMail:

電話:+33 02 3175 9391 Eメール

Syam Madanapalli Ordyn Technologies 1st Floor, Creator Building, ITPL Bangalore - 560066 India

1つのサム服フロアmadanapalli ordhyam技術、創造主の建物、バンガロールaitipil - 560066、インド

Phone: +91-80-40383000 EMail:

電話:+ 91-80-40383000 Eメール

Full Copyright Statement


Copyright (C) The IETF Trust (2007).


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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。