[要約] RFC 5505は、インターネットホストの設定の原則に関するガイドラインです。このRFCの目的は、ネットワーク管理者が効果的なホスト設定を行うための指針を提供することです。
Network Working Group B. Aboba
Request for Comments: 5505 D. Thaler
Category: Informational L. Andersson
S. Cheshire
Internet Architecture Board
May 2009
Principles of Internet Host Configuration
インターネットホスト構成の原則
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols.
このドキュメントは、インターネットホスト構成の原則について説明します。インターネット層パラメーターの構成に関連する問題と、高層プロトコルに影響するパラメーターをカバーしています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Internet Host Configuration ................................4
1.2.1. Internet-Layer Configuration ........................4
1.2.2. Higher-Layer Configuration ..........................6
2. Principles ......................................................7
2.1. Minimize Configuration .....................................7
2.2. Less Is More ...............................................7
2.3. Minimize Diversity .........................................8
2.4. Lower-Layer Independence ...................................9
2.5. Configuration Is Not Access Control .......................11
3. Additional Discussion ..........................................12
3.1. Reliance on General-Purpose Mechanisms ....................12
3.2. Relationship between IP Configuration and Service
Discovery .................................................13
3.2.1. Fate Sharing .......................................14
3.3. Discovering Names versus Addresses ........................15
3.4. Dual-Stack Issues .........................................15
3.5. Relationship between Per-Interface and Per-Host
Configuration .............................................16
4. Security Considerations ........................................17
4.1. Configuration Authentication ..............................18
5. Informative References .........................................19
Appendix A. Acknowledgments .......................................24
Appendix B. IAB Members at the Time of This Writing ...............24
This document describes principles of Internet host [STD3] configuration. It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols.
このドキュメントは、インターネットホスト[STD3]構成の原則について説明します。インターネット層パラメーターの構成に関連する問題と、高層プロトコルに影響するパラメーターをカバーしています。
In recent years, a number of architectural questions have arisen, for which we provide guidance to protocol developers:
近年、多くの建築的質問が発生しており、プロトコル開発者にガイダンスを提供します。
o The protocol layers and general approaches that are most appropriate for configuration of various parameters.
o さまざまなパラメーターの構成に最も適したプロトコル層と一般的なアプローチ。
o The relationship between parameter configuration and service discovery.
o パラメーター構成とサービスの発見の関係。
o The relationship between per-interface and per-host configuration.
o インターフェイスごととホストごとの構成との関係。
o The relationship between network access authentication and host configuration.
o ネットワークアクセス認証とホスト構成の関係。
o The desirability of supporting self-configuration of parameters or avoiding parameter configuration altogether.
o パラメーターの自己構成をサポートしたり、パラメーター構成を完全に回避したりすることの望ましさ。
o The role of link-layer protocols and tunneling protocols in Internet host configuration.
o インターネットホスト構成におけるリンク層プロトコルとトンネルプロトコルの役割。
The role of the link-layer and tunneling protocols is particularly important, since it can affect the properties of a link as seen by higher layers (for example, whether privacy extensions [RFC4941] are available to applications).
リンク層とトンネリングプロトコルの役割は、高レイヤー（たとえば、プライバシー拡張[RFC4941]がアプリケーションが利用できるかどうか）に見られるリンクのプロパティに影響を与える可能性があるため、特に重要です。
link
リンク
A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), Point-to-Point Protocol (PPP) links, X.25, Frame Relay, or ATM networks as well as Internet- or higher-layer "tunnels", such as tunnels over IPv4 or IPv6 itself.
ノードがリンクレイヤー、つまりIPのすぐ下のレイヤーで通信できる通信施設または中程度。例としては、イーサネット（シンプルまたはブリッジ）、ポイントツーポイントプロトコル（PPP）リンク、X.25、フレームリレー、またはATMネットワーク、IPv4またはIPv6のトンネルなどのインターネットまたは高層の「トンネル」自体。
on link
リンク
An address that is assigned to an interface on a specified link.
指定されたリンク上のインターフェイスに割り当てられたアドレス。
off link
オフリンク
The opposite of "on link"; an address that is not assigned to any interfaces on the specified link.
「オンリンク」の反対。指定されたリンク上のインターフェイスに割り当てられないアドレス。
mobility agent
モビリティエージェント
Either a home agent or a foreign agent [RFC3344] [RFC3775].
ホームエージェントまたは外国人エージェント[RFC3344] [RFC3775]。
Internet-layer configuration is defined as the configuration required to support the operation of the Internet layer. This includes configuration of per-interface and per-host parameters, including IP address(es), subnet prefix(es), default gateway(s), mobility agent(s), boot service configuration and other parameters:
インターネット層構成は、インターネット層の動作をサポートするために必要な構成として定義されます。これには、IPアドレス（ES）、サブネットプレフィックス（ES）、デフォルトゲートウェイ、モビリティエージェント、ブートサービス構成、その他のパラメーターなど、インターフェイスごとのパラメーターの構成とホストごとのパラメーターが含まれます。
IP address(es)
IPアドレス（ES）
Internet Protocol (IP) address configuration includes both configuration of link-scope addresses as well as global addresses. Configuration of IP addresses is a vital step, since practically all of IP networking relies on the assumption that hosts have IP address(es) associated with (each of) their active network interface(s). Used as the source address of an IP packet, these IP addresses indicate the sender of the packet; used as the destination address of a unicast IP packet, these IP addresses indicate the intended receiver.
インターネットプロトコル（IP）アドレス構成には、リンクスコープアドレスの構成とグローバルアドレスの両方が含まれます。IPアドレスの構成は重要なステップです。実際、すべてのIPネットワーキングは、ホストがアクティブネットワークインターフェイス（それぞれ）に関連付けられているIPアドレスを持っているという仮定に依存しているためです。IPパケットのソースアドレスとして使用されるこれらのIPアドレスは、パケットの送信者を示しています。ユニキャストIPパケットの宛先アドレスとして使用されるこれらのIPアドレスは、意図したレシーバーを示しています。
The only common example of IP-based protocols operating without an IP address involves address configuration, such as the use of DHCPv4 [RFC2131] to obtain an address. In this case, by definition, DHCPv4 is operating before the host has an IPv4 address, so the DHCP protocol designers had the choice of either using IP without an IP address, or not using IP at all. The benefits of making IPv4 self-reliant, configuring itself using its own IPv4 packets, instead of depending on some other protocol, outweighed the drawbacks of having to use IP in this constrained mode. Use of IP for purposes other than address configuration can safely assume that the host will have one or more IP addresses, which may be self-configured link-local addresses [RFC3927] [RFC4862], or other addresses configured via DHCP or other means.
IPアドレスなしで動作するIPベースのプロトコルの唯一の一般的な例には、DHCPV4 [RFC2131]の使用など、アドレスを取得するなどのアドレス構成が含まれます。この場合、定義上、DHCPV4はホストがIPv4アドレスを持つ前に動作しているため、DHCPプロトコル設計者はIPアドレスなしでIPを使用するか、IPをまったく使用しないかのいずれかを選択しました。IPv4を自立させる利点は、他のプロトコルに依存するのではなく、独自のIPv4パケットを使用して自らを設定することで、この制約モードでIPを使用しなければならないという欠点を上回りました。アドレス構成以外の目的でIPを使用すると、ホストが1つ以上のIPアドレスを持つことを安全に想定できます。これは、自己構成リンクローカルアドレス[RFC3927] [RFC4862]、またはDHCPまたはその他の手段を介して構成されたその他のアドレスである可能性があります。
Subnet prefix(es)
サブネットプレフィックス（es）
Once a subnet prefix is configured on an interface, hosts with an IP address can exchange unicast IP packets directly with on-link hosts within the same subnet prefix.
サブネットプレフィックスがインターフェイスで構成されると、IPアドレスを持つホストは、同じサブネットプレフィックス内のオンリンクホストと直接ユニキャストIPパケットを交換できます。
Default gateway(s)
デフォルトゲートウェイ
Once a default gateway is configured on an interface, hosts with an IP address can send unicast IP packets to that gateway for forwarding to off-link hosts.
インターフェイスでデフォルトゲートウェイが構成されると、IPアドレスを持つホストがユニキャストIPパケットをそのゲートウェイに送信して、ホストをオフリンクするために送信できます。
Mobility agent(s)
モビリティエージェント
While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] include their own mechanisms for locating home agents, it is also possible for mobile nodes to utilize dynamic home agent configuration.
モバイルIPv4 [RFC3344]およびモバイルIPv6 [RFC3775]には、ホームエージェントを見つけるための独自のメカニズムが含まれていますが、モバイルノードは動的ホームエージェントの構成を利用することも可能です。
Boot service configuration
ブートサービスの構成
Boot service configuration is defined as the configuration necessary for a host to obtain and perhaps also to verify an appropriate boot image. This is appropriate for disk-less hosts looking to obtain a boot image via mechanisms such as the Trivial File Transfer Protocol (TFTP) [RFC1350], Network File System (NFS) [RFC3530], and Internet Small Computer Systems Interface (iSCSI) [RFC3720] [RFC4173]. It also may be useful in situations where it is necessary to update the boot image of a host that supports a disk, such as in the Preboot Execution Environment [PXE] [RFC4578]. While strictly speaking, boot services operate above the Internet layer, where boot service is used to obtain the Internet-layer code, it may be considered part of Internet-layer configuration. While boot service parameters may be provided on a per-interface basis, loading and verification of a boot image affects behavior of the host as a whole.
ブートサービス構成は、ホストが取得するために必要な構成として定義され、おそらく適切なブートイメージを確認するためにも定義されます。これは、些細なファイル転送プロトコル（TFTP）[RFC1350]、ネットワークファイルシステム（NFS）[RFC3530]、インターネット小規模コンピューターシステムインターフェイス（ISCSI）[RFC1350]などのメカニズムを介してブートイメージを取得しようとするディスクレスホストに適しています。RFC3720] [RFC4173]。また、プリブート実行環境[PXE] [RFC4578]など、ディスクをサポートするホストのブート画像を更新する必要がある状況でも役立つ場合があります。厳密に言えば、ブートサービスはインターネットレイヤーの上で動作します。インターネットサービスを使用してインターネット層コードを取得するために、インターネットレイヤー構成の一部と見なされる場合があります。ブートサービスパラメーターはインターフェイスごとに提供される場合がありますが、ブート画像の読み込みと検証は、ホスト全体の動作に影響します。
Other IP parameters
その他のIPパラメーター
Internet-layer parameter configuration also includes configuration of per-host parameters (e.g., hostname) and per-interface parameters (e.g., IP Time-To-Live (TTL) to use in outgoing packets, enabling/disabling of IP forwarding and source routing, and Maximum Transmission Unit (MTU)).
インターネットレイヤーパラメーターの構成には、ホストごとのパラメーター（ホスト名など）およびインターフェイスごとのパラメーター（例：IP時間からlive（TTL）の発信パケットで使用し、IP転送およびソースルーティングの有効化/無効化の構成も含まれます。、および最大透過ユニット（MTU））。
Higher-layer configuration is defined as the configuration required to support the operation of other components above the Internet-layer. This includes, for example:
高層構成は、インターネット層の上の他のコンポーネントの動作をサポートするために必要な構成として定義されます。これには、たとえばが含まれます。
Name Service Configuration
名前サービスの構成
The configuration required for the host to resolve names. This includes configuration of the addresses of name resolution servers, including IEN 116 [IEN116], Domain Name System (DNS), Windows Internet Name Service (WINS), Internet Storage Name Service (iSNS) [RFC4171] [RFC4174], and Network Information Service (NIS) servers [RFC3898], and the setting of name resolution parameters such as the DNS domain and search list [RFC3397], the NetBIOS node type, etc. It may also include the transmission or setting of the host's own name. Note that link-local name resolution services (such as NetBIOS [RFC1001], Link-Local Multicast Name Resolution (LLMNR) [RFC4795], and multicast DNS (mDNS) [mDNS]) typically do not require configuration.
ホストが名前を解決するために必要な構成。これには、IEN 116 [IEN116]、ドメイン名システム（DNS）、Windowsインターネット名サービス（WINS）、インターネットストレージ名サービス（ISNS）[RFC4171] [RFC4174]、ネットワーク情報など、名前解像度サーバーのアドレスの構成が含まれます。サービス（NIS）サーバー[RFC3898]、およびDNSドメインや検索リスト[RFC3397]、NetBiosノードタイプなどの名前解像度パラメーターの設定。ホスト自身の名前の送信または設定も含まれる場合があります。Link-Local Name Resolution Services（NetBios [RFC1001]、Link-Local Multicast Name Resolution（LLMNR）[RFC4795]、およびMultiCast DNS（MDNS）[MDNS]）は通常、構成を必要としないことに注意してください。
Once the host has completed name service configuration, it is capable of resolving names using name resolution protocols that require configuration. This not only allows the host to communicate with off-link hosts whose IP addresses are not known, but, to the extent that name services requiring configuration are utilized for service discovery, also enables the host to discover services available on the network or elsewhere. While name service parameters can be provided on a per-interface basis, their configuration will typically affect behavior of the host as a whole.
ホストが名前サービスの構成を完了すると、構成を必要とする名前解決プロトコルを使用して名前を解決できます。これにより、ホストはIPアドレスが不明なオフリンクホストと通信できるだけでなく、構成を必要とする名前のサービスがサービスの発見に利用される限り、ホストがネットワークまたは他の場所で利用可能なサービスを発見することもできます。名前のサービスパラメーターはインターフェイスごとに提供できますが、その構成は通常、ホスト全体の動作に影響します。
Time Service Configuration
タイムサービスの構成
Time service configuration includes configuration of servers for protocols such as the Simple Network Time Protocol (SNTP) and the Network Time Protocol (NTP). Since accurate determination of the time may be important to operation of the applications running on the host (including security services), configuration of time servers may be a prerequisite for higher-layer operation. However, it is typically not a requirement for Internet-layer configuration. While time service parameters can be provided on a per-interface basis, their configuration will typically affect behavior of the host as a whole.
タイムサービスの構成には、Simple Network Timeプロトコル（SNTP）やネットワークタイムプロトコル（NTP）などのプロトコル用のサーバーの構成が含まれます。時間を正確に決定することは、ホストで実行されるアプリケーション（セキュリティサービスを含む）の操作に重要である可能性があるため、時間サーバーの構成は、高層操作の前提条件である場合があります。ただし、通常、インターネット層構成の要件ではありません。タイムサービスパラメーターはインターフェイスごとに提供できますが、その構成は通常、ホスト全体の動作に影響します。
Other service configuration
その他のサービス構成
This can include discovery of additional servers and devices, such as printers, Session Initiation Protocol (SIP) proxies, etc. This configuration will typically apply to the entire host.
これには、プリンター、セッション開始プロトコル（SIP）プロキシなどの追加のサーバーやデバイスの発見が含まれます。この構成は通常、ホスト全体に適用されます。
This section describes basic principles of Internet host configuration.
このセクションでは、インターネットホスト構成の基本原則について説明します。
Anything that can be configured can be misconfigured. Section 3.8 of "Architectural Principles of the Internet" [RFC1958] states: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually."
構成できるものはすべて、誤って構成できます。「インターネットの建築原則」[RFC1958]のセクション3.8は、「可能な限りオプションとパラメーターを避けてください。オプションとパラメーターは、手動ではなく動的に構成または交渉する必要があります。」
That is, to minimize the possibility of configuration errors, parameters should be automatically computed (or at least have reasonable defaults) whenever possible. For example, the Path Maximum Transmission Unit (PMTU) can be discovered, as described in "Packetization Layer Path MTU Discovery" [RFC4821], "TCP Problems with Path MTU Discovery" [RFC2923], "Path MTU discovery" [RFC1191], and "Path MTU Discovery for IP version 6" [RFC1981].
つまり、構成エラーの可能性を最小限に抑えるために、可能な限りパラメーターを自動的に計算する（または少なくとも合理的なデフォルトを持つ）必要があります。たとえば、「パケット化レイヤーパスMTU発見」[RFC4821]、「パスMTU発見に関するTCP問題」[RFC2923]、「Path MTU Discovery」[RFC1191]で説明されているように、パス最大透過ユニット（PMTU）を発見できます。および「IPバージョン6のPATH MTU Discovery」[RFC1981]。
Having a protocol design with many configurable parameters increases the possibilities for misconfiguration of those parameters, resulting in failures or other sub-optimal operation. Eliminating or reducing configurable parameters helps lessen this risk. Where configurable parameters are necessary or desirable, protocols can reduce the risk of human error by making these parameters self-configuring, such as by using capability negotiation within the protocol, or by automated discovery of other hosts that implement the same protocol.
多くの構成可能なパラメーターを使用してプロトコル設計を持つことで、これらのパラメーターの誤った構成の可能性が高まり、その結果、障害またはその他の最適な動作が生じます。構成可能なパラメーターを排除または削減することは、このリスクを軽減するのに役立ちます。構成可能なパラメーターが必要または望ましい場合、プロトコルは、プロトコル内で機能交渉を使用するなど、同じプロトコルを実装する他のホストの自動発見など、これらのパラメーターを自己構成することにより、ヒューマンエラーのリスクを減らすことができます。
The availability of standardized, simple mechanisms for general-purpose Internet host configuration is highly desirable. "Architectural Principles of the Internet" [RFC1958] states, "Performance and cost must be considered as well as functionality" and "Keep it simple. When in doubt during design, choose the simplest solution."
汎用インターネットホスト構成の標準化されたシンプルなメカニズムの可用性は非常に望ましいです。「インターネットの建築原則」[RFC1958]は、「パフォーマンスとコストを考慮する必要があり、機能性を考慮する必要があります」と「シンプルに保つ必要があります。デザイン中に疑わしい場合は、最も単純なソリューションを選択してください。」
To allow protocol support in many types of devices, it is important to minimize the footprint requirement. For example, IP-based protocols are used on a wide range of devices, from supercomputers to small low-cost devices running "embedded" operating systems. Since the resources (e.g., memory and code size) available for host configuration may be very small, it is desirable for a host to be able to configure itself in as simple a manner as possible.
多くのタイプのデバイスでプロトコルサポートを許可するには、フットプリント要件を最小限に抑えることが重要です。たとえば、IPベースのプロトコルは、スーパーコンピューターから「組み込み」オペレーティングシステムを実行している小さな低コストのデバイスまで、幅広いデバイスで使用されます。ホスト構成に利用可能なリソース（メモリやコードサイズなど）は非常に少ない場合があるため、ホストができるだけ簡単な方法で自分自身を構成できることが望ましいです。
One interesting example is IP support in preboot execution environments. Since by definition boot configuration is required in hosts that have not yet fully booted, it is often necessary for pre-boot code to be executed from Read Only Memory (ROM), with minimal available memory. Many hosts do not have enough space in this ROM for even a simple implementation of TCP, so in the Preboot Execution Environment (PXE) the task of obtaining a boot image is performed using the User Datagram Protocol over IP (UDP/IP) [RFC768] instead. This is one reason why Internet-layer configuration mechanisms typically depend only on IP and UDP. After obtaining the boot image, the host will have the full facilities of TCP/IP available to it, including support for reliable transport protocols, IPsec, etc.
興味深い例の1つは、プリブート実行環境でのIPサポートです。定義上、まだ完全に起動していないホストではブート構成が必要であるため、利用可能なメモリを最小限に抑えて、プレブートコードを読み取り専用メモリ（ROM）から実行する必要があることがよくあります。多くのホストには、このROMにTCPの単純な実装にも十分なスペースがないため、プリブート実行環境（PXE）では、ブートイメージを取得するタスクは、IP（UDP/IP）[RFC768を介したユーザーデータグラムプロトコルを使用して実行されます。] その代わり。これが、インターネット層の構成メカニズムが通常、IPとUDPのみに依存する理由の1つです。ブートイメージを取得した後、ホストは、信頼できる輸送プロトコル、IPSECなどのサポートなど、TCP/IPの完全な設備を利用できます。
In order to reduce complexity, it is desirable for Internet-layer configuration mechanisms to avoid dependencies on higher layers. Since embedded devices may be severely constrained on how much code they can fit within their ROM, designing a configuration mechanism in such a way that it requires the availability of higher-layer facilities may make that configuration mechanism unusable in such devices. In fact, it cannot even be guaranteed that all Internet-layer facilities will be available. For example, the minimal version of IP in a host's boot ROM may not implement IP fragmentation and reassembly.
複雑さを減らすためには、インターネット層の構成メカニズムが高層の依存関係を回避することが望ましいです。埋め込まれたデバイスは、ROM内に収まるコードの量に厳しく制約される可能性があるため、高層設備の可用性を必要とするように構成メカニズムを設計すると、その設定メカニズムがそのようなデバイスで使用できなくなる可能性があります。実際、すべてのインターネット層施設が利用可能になることを保証することさえできません。たとえば、ホストのブートROMの最小バージョンのIPは、IPの断片化と再組み立てを実装しない場合があります。
The number of host configuration mechanisms should be minimized. Diversity in Internet host configuration mechanisms presents several problems:
ホスト構成メカニズムの数を最小限に抑える必要があります。インターネットホストの構成メカニズムの多様性は、いくつかの問題を提示します。
Interoperability
相互運用性
As configuration diversity increases, it becomes likely that a host will not support the configuration mechanism(s) available on the network to which it has attached, creating interoperability problems.
構成の多様性が向上するにつれて、ホストが添付されているネットワークで利用可能な構成メカニズムをサポートしない可能性が高く、相互運用性の問題が発生します。
Footprint
フットプリント
For maximum interoperability, a host would need to implement all configuration mechanisms used on all the link layers it supports. This increases the required footprint, a burden for embedded devices. It also leads to lower quality, since testing resources (both formal testing, and real-world operational use) are spread more thinly -- the more different configuration mechanisms a device supports, the less testing each one is likely to undergo.
相互運用性を最大限に活用するには、ホストがサポートするすべてのリンクレイヤーで使用されるすべての構成メカニズムを実装する必要があります。これにより、必要なフットプリントが増加します。これは、埋め込まれたデバイスの負担です。また、テストリソース（正式なテストと現実世界の運用使用の両方）がより薄く拡散するため、品質の低下につながります。デバイスがサポートする構成メカニズムが異なるほど、それぞれのテストが少なくなる可能性があります。
Redundancy
冗長性
To support diversity in host configuration mechanisms, operators would need to support multiple configuration services to ensure that hosts connecting to their networks could configure themselves. This represents an additional expense for little benefit.
ホスト構成メカニズムの多様性をサポートするために、オペレーターは複数の構成サービスをサポートして、ネットワークに接続するホストが自分で構成できるようにする必要があります。これは、ほとんど利益を得るための追加費用を表しています。
Latency
遅延
As configuration diversity increases, hosts supporting multiple configuration mechanisms may spend increasing effort to determine which mechanism(s) are supported. This adds to configuration latency.
構成の多様性が向上するにつれて、複数の構成メカニズムをサポートするホストは、どのメカニズムがサポートされているかを判断するためにますます努力を費やす可能性があります。これにより、構成遅延が追加されます。
Conflicts
対立
Whenever multiple mechanisms are available, it is possible that multiple configurations will be returned. To handle this, hosts would need to merge potentially conflicting configurations. This would require conflict-resolution logic, such as ranking of potential configuration sources, increasing implementation complexity.
複数のメカニズムが利用可能になると、複数の構成が返される可能性があります。これを処理するには、ホストは潜在的に矛盾する構成をマージする必要があります。これには、潜在的な構成ソースのランキングなど、競合解像度ロジックが必要になり、実装の複雑さが向上します。
Additional traffic
追加のトラフィック
To limit configuration latency, hosts may simultaneously attempt to obtain configuration by multiple mechanisms. This can result in increasing on-the-wire traffic, both from use of multiple mechanisms as well as from retransmissions within configuration mechanisms not implemented on the network.
構成遅延を制限するために、ホストは複数のメカニズムによって同時に構成を取得しようとする場合があります。これにより、複数のメカニズムの使用と、ネットワーク上に実装されていない構成メカニズム内の再送信の両方から、ワイヤ上のトラフィックが増加する可能性があります。
Security
安全
Support for multiple configuration mechanisms increases the attack surface without any benefit.
複数の構成メカニズムをサポートすると、利益なしに攻撃面が増加します。
"Architectural Principles of the Internet" [RFC1958] states, "Modularity is good. If you can keep things separate, do so." It is becoming increasingly common for hosts to support multiple network access mechanisms, including dialup, wireless, and wired local area networks; wireless metropolitan and wide area networks; etc. The proliferation of network access mechanisms makes it desirable for hosts to be able to configure themselves on multiple networks without adding configuration code specific to each new link layer.
「インターネットの建築原則」[RFC1958]は、「モジュール性は良好です。物事を別々に保つことができれば、そうしてください。」ホストがダイヤルアップ、ワイヤレス、有線ローカルネットワークなど、複数のネットワークアクセスメカニズムをサポートすることがますます一般的になっています。ワイヤレスメトロポリタンおよび広いエリアネットワーク。など。ネットワークアクセスメカニズムの拡散により、ホストが新しいリンクレイヤーに固有の構成コードを追加せずに複数のネットワークで設定できるようにすることが望ましい。
As a result, it is highly desirable for Internet host configuration mechanisms to be independent of the underlying lower layer. That is, only the link-layer protocol (whether it be a physical link or a virtual tunnel link) should be explicitly aware of link-layer parameters (although those link-layer parameters may be configured by general Internet-layer mechanisms). Introduction of lower-layer dependencies increases the likelihood of interoperability problems and adds Internet-layer configuration mechanisms that hosts need to implement.
その結果、インターネットホストの構成メカニズムが基礎となる下層とは独立していることが非常に望ましいです。つまり、リンク層プロトコル（物理リンクであろうと仮想トンネルリンクであろうと）のみが、リンク層パラメーターを明示的に認識する必要があります（これらのリンク層パラメーターは、一般的なインターネット層メカニズムによって構成される場合があります）。低層依存関係の導入により、相互運用性の問題の可能性が高まり、ホストが実装する必要があるインターネット層構成メカニズムが追加されます。
Lower-layer dependencies can be best avoided by keeping Internet host configuration above the link layer, thereby enabling configuration to be handled for any link layer that supports IP. In order to provide media independence, Internet host configuration mechanisms should be link-layer protocol independent.
低層依存関係は、リンクレイヤーの上にインターネットホストの構成を維持することで避けることができます。これにより、IPをサポートするリンクレイヤーの構成を処理できます。メディアの独立性を提供するために、インターネットホストの構成メカニズムはリンク層プロトコルが独立している必要があります。
While there are examples of Internet-layer configuration within the link layer (such as in PPP IPv4CP [RFC1332] and "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)" [3GPP-24.008]), this approach has disadvantages. These include the extra complexity of implementing different mechanisms on different link layers and the difficulty in adding new higher-layer parameters that would require defining a mechanism in each link-layer protocol.
リンクレイヤー内にインターネット層構成の例（PPP IPv4CP [RFC1332]や「モバイル無線インターフェイスレイヤー3仕様、コアネットワークプロトコル、ステージ3（リリース5）」[3GPP-24.008]）、これはアプローチには欠点があります。これらには、さまざまなリンクレイヤーにさまざまなメカニズムを実装するという特別な複雑さと、各リンク層プロトコルのメカニズムを定義する必要がある新しい高層パラメーターを追加することが困難になります。
For example, "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses" [RFC1877] was developed prior to the definition of the DHCPINFORM message in "Dynamic Host Configuration Protocol" [RFC2131]; at that time, Dynamic Host Configuration Protocol (DHCP) servers had not been widely implemented on access devices or deployed in service provider networks. While the design of IPv4CP was appropriate in 1992, it should not be taken as an example that new link-layer technologies should emulate. Indeed, in order to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value", "IANA Considerations for the Point-to-Point Protocol (PPP)" [RFC3818] changed the allocation of PPP numbers (including IPv4CP extensions) so as to no longer be "first come first served".
たとえば、「ダイナミックホスト構成プロトコル」[RFC2131]のDHCPINFORMメッセージの定義の前に、「名前サーバーアドレスのPPPインターネットプロトコルプロトコルプロトコル拡張」[RFC1877]が開発されました。当時、動的ホスト構成プロトコル（DHCP）サーバーは、アクセスデバイスに広く実装されていないか、サービスプロバイダーネットワークに展開されていませんでした。1992年にはIPv4CPの設計が適切でしたが、新しいリンク層技術がエミュレートすべき例としてはとられるべきではありません。実際、「PPPの最も有用な拡張機能を完全な標準に積極的に進めながら、疑わしい価値のさらなる強化を防御する」、「ポイントツーポイントプロトコル（PPP）のIANAの考慮事項」[RFC3818]は、PPP数の割り当てを変更しました。（IPv4CP拡張機能を含む）「最初に提供される」ことなくなりました。
In IPv6, where link-layer-independent mechanisms such as stateless autoconfiguration [RFC4862] and stateless DHCPv6 [RFC3736] are available, PPP IPv6CP [RFC5072] configures an Interface-Identifier that is similar to a Media Access Control (MAC) address. This enables PPP IPv6CP to avoid duplicating DHCPv6 functionality.
IPv6では、ステートレスオートコンチュレーション[RFC4862]やステートレスDHCPV6 [RFC3736]などのリンク層非依存メカニズムが利用可能です。PPPIPv6CP[RFC5072]は、メディアアクセスコントロール（MAC）アドレスに似たインターフェイスIDERIERを構成します。これにより、PPP IPv6CPがDHCPV6機能の複製を避けることができます。
However, Internet Key Exchange Version 2 (IKEv2) [RFC4306] utilizes the same approach as PPP IPv4CP by defining a Configuration Payload for Internet host configuration for both IPv4 and IPv6. While the IKEv2 approach reduces the number of packet exchanges, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode" [RFC3456] points out that leveraging DHCP has advantages in terms of address management integration, address pool management, reconfiguration, and fail-over.
ただし、Internet Key Exchangeバージョン2（IKEV2）[RFC4306]は、IPv4とIPv6の両方のインターネットホスト構成の構成ペイロードを定義することにより、PPP IPv4CPと同じアプローチを使用します。IKEV2アプローチはパケット交換の数を減らしますが、「IPSECトンネルモードの動的ホスト構成プロトコル（DHCPV4）構成」[RFC3456]は、DHCPを活用すること、アドレス管理、住所プール管理、再構成、および障害の障害に関しては利点があることを指摘しています。-以上。
Extensions to link-layer protocols for the purpose of Internet-, transport-, or application-layer configuration (including server configuration) should be avoided. Such extensions can negatively affect the properties of a link as seen by higher layers. For example, if a link-layer protocol (or tunneling protocol) configures individual IPv6 addresses and precludes using any other addresses, then applications that want to use privacy extensions [RFC4941] may not function well. Similar issues may arise for other types of addresses, such as Cryptographically Generated Addresses [RFC3972].
インターネット、トランスポート、またはアプリケーションレイヤー構成（サーバー構成を含む）を目的とするリンク層プロトコルへの拡張は避ける必要があります。このような拡張機能は、高層で見られるように、リンクのプロパティに悪影響を与える可能性があります。たとえば、リンク層プロトコル（またはトンネルプロトコル）が個々のIPv6アドレスを構成し、他のアドレスを使用して排除する場合、プライバシー拡張機能[RFC4941]を使用するアプリケーションはうまく機能しない場合があります。暗号化されたアドレス[RFC3972]など、他のタイプのアドレスでも同様の問題が発生する可能性があります。
Avoiding lower-layer dependencies is desirable even where the lower layer is link independent. For example, while the Extensible Authentication Protocol (EAP) may be run over any link satisfying its requirements (see Section 3.1 of [RFC3748]), many link layers do not support EAP and therefore Internet-layer configuration mechanisms that depend on EAP would not be usable on links that support IP but not EAP.
下層がリンクが独立している場合でも、低層の依存関係を避けることが望ましいです。たとえば、拡張可能な認証プロトコル（EAP）は、要件を満たすリンクに対して実行される場合がありますが（[RFC3748]、セクション3.1を参照）、多くのリンクレイヤーはEAPをサポートしていないため、EAPに依存するインターネット層構成メカニズムはサポートしません。EAPではなくIPをサポートするリンクで使用できます。
Network access authentication and authorization is a distinct problem from Internet host configuration. Therefore, network access authentication and authorization is best handled independently of the Internet and higher-layer configuration mechanisms.
ネットワークアクセス認証と承認は、インターネットホストの構成とは明確な問題です。したがって、ネットワークアクセス認証と認証は、インターネットと高層構成メカニズムとは無関係に最適に処理されます。
Having an Internet- or higher-layer protocol authenticate clients is appropriate to prevent resource exhaustion of a scarce resource on the server (such as IP addresses or prefixes), but not for preventing hosts from obtaining access to a link. If the user can manually configure the host, requiring authentication in order to obtain configuration parameters (such as an IP address) has little value. Network administrators who wish to control access to a link can better achieve this using technologies like Port-Based Network Access Control [IEEE-802.1X]. Note that client authentication is not required for Stateless DHCPv6 [RFC3736] since it does not result in allocation of any limited resources on the server.
インターネットまたは高層のプロトコルを持つことは、サーバー上の希少なリソース（IPアドレスやプレフィックスなど）のリソースの消耗を防ぐために適切ですが、ホストがリンクへのアクセスを取得できないようにするためではありません。ユーザーがホストを手動で構成できる場合、構成パラメーター（IPアドレスなど）を取得するために認証を必要とすることはほとんど価値がありません。リンクへのアクセスを制御したいネットワーク管理者は、ポートベースのネットワークアクセス制御[IEEE-802.1x]などのテクノロジーを使用して、これをより適切に実現できます。Stateless Dhcpv6 [RFC3736]には、クライアント認証は必要ないことに注意してください。これは、サーバー上の限られたリソースの割り当てにつながらないためです。
Protocols should either be self-configuring (especially where fate sharing is important), or use general-purpose configuration mechanisms (such as DHCP or a service discovery protocol, as noted in Section 3.2). The choice should be made taking into account the architectural principles discussed in Section 2.
プロトコルは、自己構成（特に運命共有が重要な場合）であるか、汎用構成メカニズム（セクション3.2に記載されているように、DHCPやサービス発見プロトコルなど）を使用する必要があります。セクション2で説明した建築原則を考慮に入れて選択する必要があります。
Taking into account the general-purpose configuration mechanisms currently available, we see little need for development of additional general-purpose configuration mechanisms.
現在利用可能な汎用構成メカニズムを考慮すると、追加の汎用構成メカニズムの開発がほとんど必要ありません。
When defining a new host parameter, protocol designers should first consider whether configuration is indeed necessary (see Section 2.1).
新しいホストパラメーターを定義する場合、プロトコル設計者は最初に構成が実際に必要かどうかを検討する必要があります（セクション2.1を参照）。
If configuration is necessary, in addition to considering fate sharing (see Section 3.2.1), protocol designers should consider:
構成が必要な場合は、運命の共有を検討することに加えて（セクション3.2.1を参照）、プロトコル設計者は次のことを考慮する必要があります。
1. The organizational implications for administrators. For example, routers and servers are often administered by different sets of individuals, so that configuring a router with server parameters may require cross-group collaboration.
1. 管理者に対する組織の意味。たとえば、ルーターとサーバーは多くの場合、さまざまな個人のセットで管理されるため、サーバーパラメーターを使用してルーターを構成するにはクロスグループコラボレーションが必要になる場合があります。
2. Whether the need is to configure a set of interchangeable servers or to select a particular server satisfying a set of criteria. See Section 3.2.
2. 交換可能なサーバーのセットを構成する必要があるか、一連の基準を満たす特定のサーバーを選択する必要があるかどうか。セクション3.2を参照してください。
3. Whether IP address(es) should be configured, or name(s). See Section 3.3.
3. IPアドレスを構成するか、名前を設定するか。セクション3.3を参照してください。
4. If IP address(es) are configured, whether IPv4 and IPv6 addresses should be configured simultaneously or separately. See Section 3.4.
4. IPアドレスが設定されている場合、IPv4およびIPv6アドレスを同時にまたは個別に構成する必要があるかどうか。セクション3.4を参照してください。
5. Whether the parameter is a per-interface or a per-host parameter. For example, configuration protocols such as DHCP run on a per-interface basis and hence are more appropriate for per-interface parameters.
5. パラメーターがインターフェイスごとであるか、ホストごとのパラメーターであるか。たとえば、DHCPなどの構成プロトコルは、インターフェイスごとに実行されるため、インターフェイスごとのパラメーターにより適しています。
6. How per-interface configuration affects host-wide behavior. For example, whether the host should select a subset of the per-interface configurations, or whether the configurations are to merged, and if so, how this is done. See Section 3.5.
6. インターフェイスごとの構成がどのようにホスト全体の動作に影響します。たとえば、ホストがインターフェイスごとの構成のサブセットを選択する必要があるかどうか、または構成がマージされるかどうか、もしそうなら、これがどのように行われるか。セクション3.5を参照してください。
Higher-layer configuration often includes configuring server addresses. The question arises as to how this differs from "service discovery" as provided by Service Discovery protocols such as "Service Location Protocol, Version 2" (SLPv2) [RFC2608] or "DNS-Based Service Discovery" (DNS-SD) [DNS-SD].
より高い層構成には、多くの場合、サーバーアドレスの構成が含まれます。「サービスロケーションプロトコル、バージョン2」（SLPV2）[RFC2608]または「DNSベースのサービスディスカバリー」（DNS-SD）[DNSなどのサービスディスカバリープロトコルによって提供されるように、これが「サービス発見」とどのように異なるかについて疑問が生じます。-SD]。
In Internet host configuration mechanisms such as DHCP, if multiple server instances are provided, they are considered interchangeable. For example, in a list of time servers, the servers are considered interchangeable because they all provide the exact same service -- telling you the current time. In a list of local caching DNS servers, the servers are considered interchangeable because they all should give you the same answer to any DNS query. In service discovery protocols, on the other hand, a host desires to find a server satisfying a particular set of criteria, which may vary by request. When printing a document, it is not the case that any printer will do. The speed, capabilities, and physical location of the printer matter to the user.
DHCPなどのインターネットホスト構成メカニズムでは、複数のサーバーインスタンスが提供されている場合、それらは交換可能と見なされます。たとえば、タイムサーバーのリストでは、すべてがまったく同じサービスを提供しているため、サーバーは交換可能と見なされます。ローカルキャッシュDNSサーバーのリストでは、サーバーはすべてDNSクエリに対して同じ答えを提供する必要があるため、交換可能と見なされます。一方、サービスディスカバリープロトコルでは、ホストは、特定の基準セットを満たすサーバーを見つけたいと考えています。これは、リクエストによって異なる場合があります。ドキュメントを印刷する場合、プリンターが行うことはありません。プリンターの速度、機能、および物理的位置は、ユーザーにとって重要です。
Information learned via DHCP is typically learned once, at boot time, and after that may be updated only infrequently (e.g., on DHCP lease renewal), if at all. This makes DHCP appropriate for information that is relatively static and unchanging over these time intervals. Boot-time discovery of server addresses is appropriate for service types where there are a small number of interchangeable servers that are of interest to a large number of clients. For example, listing time servers in a DHCP packet is appropriate because an organization may typically have only two or three time servers, and most hosts will be able to make use of that service. Listing all the printers or file servers at an organization is a lot less useful, because the list may contain hundreds or thousands of entries, and on a given day a given user may not use any of the printers in that list.
DHCPを介して学習した情報は、通常、ブート時に一度学習され、その後はまれに（例：DHCPリース更新）のみ更新される場合があります。これにより、DHCPは、これらの時間間隔で比較的静的で不変の情報に適しています。サーバーアドレスのブートタイムディスカバリーは、多数のクライアントにとって興味深い交換可能なサーバーが少ないサービスタイプに適しています。たとえば、組織には通常2つまたは3つのタイムサーバーしかなく、ほとんどのホストがそのサービスを利用できるため、DHCPパケットのタイムサーバーをリストすることが適切です。リストには数百または数千のエントリが含まれている可能性があり、特定のユーザーがそのリストのプリンターを使用しない場合があるため、組織のすべてのプリンターまたはファイルサーバーをリストすることはそれほど有用ではありません。
Service discovery protocols can support discovery of servers on the Internet, not just those within the local administrative domain. For example, see "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV" [RFC3832] and DNS-Based Service Discovery [DNS-SD]. Internet host configuration mechanisms such as DHCP, on the other hand, typically assume the server or servers in the local administrative domain contain the authoritative set of information.
Service Discoveryプロトコルは、ローカル管理ドメイン内のサーバーだけでなく、インターネット上のサーバーの発見をサポートできます。たとえば、「DNS SRVを介したサービスロケーションプロトコル（SLP）のリモートサービスディスカバリー」[RFC3832]およびDNSベースのサービスディスカバリー[DNS-SD]を参照してください。一方、DHCPなどのインターネットホスト構成メカニズムは、通常、ローカル管理ドメインのサーバーまたはサーバーに権威ある情報セットが含まれていると仮定します。
For the service discovery problem (i.e., where the criteria varies on a per-request basis, even from the same host), protocols should either be self-discovering (if fate sharing is critical), or use a general-purpose service discovery mechanism.
サービスの発見の問題（つまり、基準が同じホストからでも要求ごとに変化する場合）の場合、プロトコルは自己発見（運命の共有が重要な場合）であるか、汎用サービス発見メカニズムを使用する必要があります。。
In order to avoid a dependency on multicast routing, it is necessary for a host to either restrict discovery to services on the local link or to discover the location of a Directory Agent (DA). Since the DA may not be available on the local link, service discovery beyond the local link is typically dependent on a mechanism for configuring the DA address or name. As a result, service discovery protocols can typically not be relied upon for obtaining basic Internet-layer configuration, although they can be used to obtain higher-layer configuration parameters.
マルチキャストルーティングへの依存を回避するために、ホストがローカルリンクのサービスへの発見を制限するか、ディレクトリエージェント（DA）の場所を発見する必要があります。DAはローカルリンクで利用できない可能性があるため、ローカルリンクを超えたサービスの発見は通常、DAアドレスまたは名前を構成するためのメカニズムに依存します。その結果、サービス発見プロトコルは通常、基本的なインターネットレイヤー構成を取得するために依存することはできませんが、高レイヤー構成パラメーターを取得するために使用できます。
If a server (or set of servers) is needed to get a set of configuration parameters, "fate sharing" (Section 2.3 of [RFC1958]) is preserved if those parameters are ones that cannot be usefully used without those servers being available. In this case, successfully obtaining those parameters via other means has little benefit if they cannot be used because the required servers are not available. The possibility of incorrect information being configured is minimized if there is only one machine that is authoritative for the information (i.e., there is no need to keep multiple authoritative servers in sync). For example, learning default gateways via Router Advertisements provides perfect fate sharing. That is, gateway addresses can be obtained if and only if they can actually be used. Similarly, obtaining DNS server configuration from a DNS server would provide fate sharing since the configuration would only be obtainable if the DNS server were available.
構成パラメーターのセットを取得するためにサーバー（またはサーバーのセット）が必要な場合、「Fate Sharing」（[RFC1958]のセクション2.3）が保存されます。この場合、必要なサーバーが利用できないために使用できない場合、他の手段を介してこれらのパラメーターを正常に取得することはほとんど利点がありません。誤った情報が構成されている可能性は、情報に対して権威あるマシンが1つしかない場合に最小化されます（つまり、複数の権威あるサーバーを同期させる必要はありません）。たとえば、ルーター広告を介したデフォルトゲートウェイの学習は、完全な運命共有を提供します。つまり、実際に使用できる場合にのみ、ゲートウェイアドレスを取得できます。同様に、DNSサーバーからDNSサーバー構成を取得すると、DNSサーバーが利用可能であった場合にのみ構成が取得できるため、運命共有が提供されます。
While fate sharing is a desirable property of a configuration mechanism, in some situations fate sharing may not be possible. When utilized to discover services on the local link, service discovery protocols typically provide for fate sharing, since hosts providing service information typically also provide the services. However, this is no longer the case when service discovery is assisted by a Directory Agent (DA). First of all, the DA's list of operational servers may not be current, so it is possible that the DA may provide clients with service information that is out of date. For example, a DA's response to a client's service discovery query may contain stale information about servers that are no longer operational. Similarly, recently introduced servers might not yet have registered themselves with the DA. Furthermore, the use of a DA for service discovery also introduces a dependency on whether the DA is operational, even though the DA is typically not involved in the delivery of the service.
運命の共有は構成メカニズムの望ましい特性ですが、場合によっては、運命共有は不可能かもしれません。ローカルリンクでサービスを発見するために利用される場合、サービス情報を提供するホストもサービスを提供するため、サービスディスカバリープロトコルは通常、運命共有を提供します。ただし、これは、サービスの発見がディレクトリエージェント（DA）によって支援されている場合はもはやそうではありません。まず第一に、DAの運用サーバーのリストは最新ではない可能性があるため、DAがクライアントに古くなっているサービス情報を提供する可能性があります。たとえば、クライアントのサービスディスカバリークエリに対するDAの応答には、動作しなくなったサーバーに関する古い情報が含まれている場合があります。同様に、最近導入されたサーバーはまだDAに登録されていない可能性があります。さらに、DAが通常サービスの提供に関与していない場合でも、サービスの発見にDAを使用すると、DAが動作しているかどうかに依存します。
Similar limitations exist for other server-based configuration mechanisms such as DHCP. Typically DHCP servers do not check for the liveness of the configuration information they provide, and do not discover new configuration information automatically. As a result, there is no guarantee that configuration information will be current.
DHCPなどの他のサーバーベースの構成メカニズムには同様の制限があります。通常、DHCPサーバーは、それらが提供する構成情報の活性を確認せず、新しい構成情報を自動的に発見しません。その結果、構成情報が最新になるという保証はありません。
Section 3.3 of "IPv6 Host Configuration of DNS Server Information Approaches" [RFC4339] discusses the use of well-known anycast addresses for discovery of DNS servers. The use of anycast addresses enables fate sharing, even where the anycast address is provided by an unrelated server. However, in order to be universally useful, this approach would require allocation of one or more well-known anycast addresses for each service. Configuration of more than one anycast address is desirable to allow the client to fail over faster than would be possible from routing protocol convergence.
「DNSサーバー情報アプローチのIPv6ホスト構成」のセクション3.3 [RFC4339]は、DNSサーバーの発見のためによく知られているAnycastアドレスの使用について説明しています。Anycastアドレスを使用すると、Anycastアドレスが無関係なサーバーによって提供されている場合でも、運命共有が可能になります。ただし、普遍的に有用であるためには、このアプローチでは、各サービスに1つ以上のよく知られているAnycastアドレスを割り当てる必要があります。複数のAnycastアドレスの構成が望ましいです。クライアントがルーティングプロトコルの収束から可能になるよりも速く失敗することを可能にします。
In discovering servers other than name resolution servers, it is possible to either discover the IP addresses of the server(s), or to discover names, each of which may resolve to a list of addresses.
名前解像度サーバー以外のサーバーを発見すると、サーバーのIPアドレスを発見するか、それぞれがアドレスのリストに解決できる名前を検出することができます。
It is typically more efficient to obtain the list of addresses directly, since this avoids the extra name resolution steps and accompanying latency. On the other hand, where servers are mobile, the name-to-address binding may change, requiring a fresh set of addresses to be obtained. Where the configuration mechanism does not support fate sharing (e.g., DHCP), providing a name rather than an address can simplify operations, assuming that the server's new address is manually or automatically updated in the DNS; in this case, there is no need to re-do parameter configuration, since the name is still valid. Where fate sharing is supported (e.g., service discovery protocols), a fresh address can be obtained by re-initiating parameter configuration.
通常、アドレスのリストを直接取得する方が効率的です。これにより、追加の名前の解像度の手順とそれに付随する遅延が回避されるためです。一方、サーバーがモバイルである場合、名前からアドレスへのバインディングが変更される場合があり、新しいアドレスを取得する必要があります。構成メカニズムが運命共有（DHCPなど）をサポートしていない場合、アドレスではなく名前を提供すると、サーバーの新しいアドレスがDNSで手動または自動化されていると仮定して、操作を簡素化できます。この場合、名前がまだ有効であるため、パラメーターの構成を再入力する必要はありません。運命の共有がサポートされている場合（たとえば、サービスディスカバリープロトコルなど）、パラメーター構成を再明確にすることで新しいアドレスを取得できます。
In providing the IP addresses for a set of servers, it is desirable to distinguish which IP addresses belong to which servers. If a server IP address is unreachable, this enables the host to try the IP address of another server, rather than another IP address of the same server, in case the server is down. This can be enabled by distinguishing which addresses belong to the same server.
一連のサーバーのIPアドレスを提供する際には、どのIPアドレスがどのサーバーに属しているかを区別することが望ましいです。サーバーIPアドレスが到達できない場合、これにより、サーバーがダウンしている場合に備えて、同じサーバーの別のIPアドレスではなく、ホストが別のサーバーのIPアドレスを試すことができます。これは、同じサーバーに属するアドレスを区別することで有効にできます。
One use for learning a list of interchangeable server addresses is for fault tolerance, in case one or more of the servers are unresponsive. Hosts will typically try the addresses in turn, only attempting to use the second and subsequent addresses in the list if the first one fails to respond quickly enough. In such cases, having the list sorted in order of expected likelihood of success will help clients get results faster. For hosts that support both IPv4 and IPv6, it is desirable to obtain both IPv4 and IPv6 server addresses within a single list. Obtaining IPv4 and IPv6 addresses in separate lists, without indicating which server(s) they correspond to, requires the host to use a heuristic to merge the lists.
交換可能なサーバーアドレスのリストを学習するための1つの用途は、1つ以上のサーバーが反応しない場合に備えて、フォールトトレランスです。ホストは通常、アドレスを順番に試しますが、最初のアドレスが十分に迅速に応答できない場合、リスト内の2番目と後続のアドレスを使用しようとします。そのような場合、成功の予想される可能性の順にリストをソートすることで、クライアントがより速く結果を得るのに役立ちます。IPv4とIPv6の両方をサポートするホストの場合、単一のリスト内でIPv4サーバーとIPv6サーバーアドレスの両方を取得することが望ましいです。IPv4とIPv6のアドレスを別々のリストで取得します。どのサーバーが対応するかを示さずに、リストをマージするためにヒューリスティックを使用する必要があります。
For example, assume there are two servers, A and B, each with one IPv4 address and one IPv6 address. If the first address the host should try is (say) the IPv6 address of server A, then the second address the host should try, if the first one fails, would generally be the IPv4 address of server B. This is because the failure of the first address could be due to either server A being down, or some problem with the host's IPv6 address, or a problem with connectivity to server A. Trying the IPv4 address next is preferred since the reachability of the IPv4 address is independent of all potential failure causes.
たとえば、AとBの2つのサーバーがあると仮定し、それぞれに1つのIPv4アドレスと1つのIPv6アドレスがあります。ホストが試す必要がある最初のアドレスが（たとえば）サーバーAのIPv6アドレスである場合、ホストが試してみる2番目のアドレスは、通常、サーバーBのIPv4アドレスであるためです。最初のアドレスは、サーバーAがダウンしているか、ホストのIPv6アドレスの問題、またはサーバーAへの接続の問題が原因である可能性があります。IPv4アドレスの到達可能性はすべての可能性に依存しないため、次にIPv4アドレスを試してください。障害の原因。
If the list of IPv4 server addresses were obtained separately from the list of IPv6 server addresses, a host trying to merge the lists would not know which IPv4 addresses belonged to the same server as the IPv6 address it just tried. This can be solved either by explicitly distinguishing which addresses belong to which server or, more simply, by configuring the host with a combined list of both IPv4 and IPv6 addresses. Note that the same issue can arise with any mechanism (e.g., DHCP, DNS, etc.) for obtaining server IP addresses.
IPv4サーバーアドレスのリストがIPv6サーバーアドレスのリストとは別に取得された場合、リストをマージしようとするホストは、どのIPv4アドレスが試したばかりのIPv6アドレスと同じサーバーに属しているかがわかりません。これは、どのアドレスがどのサーバーに属しているかを明示的に区別することによって、またはより簡単に、IPv4アドレスとIPv6アドレスの両方の複合リストでホストを構成することによって解決できます。サーバーIPアドレスを取得するために、同じ問題があらゆるメカニズム（DHCP、DNSなど）で発生する可能性があることに注意してください。
Configuring a combined list of both IPv4 and IPv6 addresses gives the configuration mechanism control over the ordering of addresses, as compared with configuring a name and allowing the host resolver to determine the address list ordering. See "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues" [RFC4477] for more discussion of dual-stack issues in the context of DHCP.
IPv4アドレスとIPv6アドレスの両方の複合リストを構成すると、名前の構成とホストリゾルバーがアドレスリストの順序を決定できるようにするのと比較して、アドレスの順序付けに対する構成メカニズム制御が得られます。DHCPのコンテキストでのデュアルスタックの問題の詳細については、「動的ホスト構成プロトコル（DHCP）：IPv4およびIPv6デュアルスタックの問題」[RFC4477] [RFC4477]を参照してください。
Parameters that are configured or acquired on a per-interface basis can affect behavior of the host as a whole. Where only a single configuration can be applied to a host, the host may need to prioritize the per-interface configuration information in some way (e.g., most trusted to least trusted). If the host needs to merge per-interface configuration to produce a host-wide configuration, it may need to take the union of the per-host configuration parameters and order them in some way (e.g., highest speed interface to lowest speed interface). Which procedure is to be applied and how this is accomplished may vary depending on the parameter being configured. Examples include: Boot service configuration
インターフェイスごとに構成または取得したパラメーターは、ホスト全体の動作に影響を与える可能性があります。ホストに単一の構成のみを適用できる場合、ホストはインターフェイスごとの構成情報に何らかの方法で優先順位を付ける必要がある場合があります（たとえば、最も信頼されていないことから最も信頼されていない）。ホストがインターフェイスごとの構成をマージしてホスト全体の構成を生成する必要がある場合、ホストあたりの構成パラメーターの結合を取り、何らかの方法で注文する必要がある場合があります（たとえば、最低速度インターフェイスへの最高速度インターフェイス）。どの手順を適用するか、これがどのように達成されるかは、構成されているパラメーターによって異なる場合があります。例には、ブートサービスの構成が含まれます
While boot service configuration can be provided on multiple interfaces, a given host may be limited in the number of boot loads that it can handle simultaneously. For example, a host not supporting virtualization may only be capable of handling a single boot load at a time, or a host capable of supporting N virtual machines may only be capable of handling up to N simultaneous boot loads. As a result, a host may need to select which boot load(s) it will act on, out of those configured on a per-interface basis. This requires that the host prioritize them (e.g., most to least trusted).
ブートサービスの構成は複数のインターフェイスで提供できますが、特定のホストは、同時に処理できるブートロードの数が制限される場合があります。たとえば、仮想化をサポートしていないホストは、一度に単一のブート負荷を処理することができる場合、または仮想マシンをサポートできるホストは、同時のブートロードまでのみ処理できる場合があります。その結果、ホストは、インターフェイスごとに構成されたものから、どのブートロードに作用するかを選択する必要があります。これには、ホストがそれらに優先順位を付ける必要があります（たとえば、ほとんどが最も信頼されていない）。
Name service configuration
名前サービスの構成
While name service configuration is provided on a per-interface basis, name resolution configuration typically will affect behavior of the host as a whole. For example, given the configuration of DNS server addresses and searchlist parameters on each interface, the host determines what sequence of name service queries is to be sent on which interfaces.
名前サービスの構成はインターフェイスごとに提供されますが、通常、名前の解像度の構成はホスト全体の動作に影響します。たとえば、各インターフェイスのDNSサーバーアドレスと検索リストパラメーターの構成を考慮して、ホストは、どのインターフェイスに送信される名前サービスクエリのシーケンスを決定します。
Since the algorithms used to determine per-host behavior based on per-interface configuration can affect interoperability, it is important for these algorithms to be understood by implementers. We therefore recommend that documents defining per-interface mechanisms for acquiring per-host configuration (e.g., DHCP or IPv6 Router Advertisement options) include guidance on how to deal with multiple interfaces. This may include discussions of the following items:
インターフェイスごとの構成に基づいてホストごとの動作を決定するために使用されるアルゴリズムは、相互運用性に影響を与える可能性があるため、これらのアルゴリズムが実装者が理解することが重要です。したがって、インターフェイスごとのメカニズムを定義するドキュメントで、ホストごとの構成を取得するためのドキュメント（DHCPやIPv6ルーター広告オプションなど）には、複数のインターフェイスの処理方法に関するガイダンスが含まれることをお勧めします。これには、次の項目の議論が含まれる場合があります。
1. Merging. How are per-interface configurations combined to produce a per-host configuration? Is a single configuration selected, or is the union of the configurations taken?
1. マージ。インターフェイスごとの構成を組み合わせて、ホストごとの構成を作成しますか？単一の構成は選択されていますか、それとも構成の結合は取られていますか？
2. Prioritization. Are the per-interface configurations prioritized as part of the merge process? If so, what are some of the considerations to be taken into account in prioritization?
2. 優先順位付け。インターフェイスごとの構成は、マージプロセスの一部として優先されますか？もしそうなら、優先順位付けで考慮すべき考慮事項のいくつかは何ですか？
Secure IP configuration presents a number of challenges. In addition to denial-of-service and man-in-the-middle attacks, attacks on configuration mechanisms may target particular parameters. For example, attackers may target DNS server configuration in order to support subsequent phishing or pharming attacks such as those described in "New trojan in mass DNS hijack" [DNSTrojan]. A number of issues exist with various classes of parameters, as discussed in Section 2.6, Section 4.2.7 of "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756], Section 1.1 of "Authentication for DHCP Messages" [RFC3118], and Section 23 of "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315]. Given the potential vulnerabilities, hosts often restrict support for DHCP options to the minimum set required to provide basic TCP/IP configuration.
Secure IP構成は、多くの課題を提示します。サービスの拒否と中間の攻撃に加えて、構成メカニズムに対する攻撃は特定のパラメーターをターゲットにする可能性があります。たとえば、攻撃者は、「Mass DNS Hijackの新しいトロイの木馬」[Dnstrojan]に記載されているような後続のフィッシングまたはファーミング攻撃をサポートするために、DNSサーバーの構成をターゲットにすることができます。セクション2.6、「IPv6 Neighbor Discovery（ND）信頼モデルと脅威」のセクション4.2.7 [RFC3756]、「DHCPメッセージの認証」[RFC3118]のセクション4.2.7で説明されているように、さまざまなクラスのパラメーターには多くの問題が存在します。、および「IPv6（DHCPV6）の動的ホスト構成プロトコル」[RFC3315]のセクション23。潜在的な脆弱性を考えると、ホストはしばしば基本的なTCP/IP構成を提供するために必要な最小セットにDHCPオプションのサポートを制限します。
Since boot configuration determines the boot image to be run by the host, a successful attack on boot configuration could result in an attacker gaining complete control over a host. As a result, it is particularly important that boot configuration be secured. Approaches to boot configuration security are described in "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution Environment (PXE) Specification" [PXE].
ブート構成により、ホストが実行するブートイメージが決定されるため、ブート構成に対する攻撃が成功すると、攻撃者がホストを完全に制御できるようになります。その結果、ブート構成を保護することが特に重要です。ブート構成セキュリティへのアプローチは、「インターネットSmall Computer System Interface（ISCSI）プロトコルを使用してクライアントをブートストラップする」[RFC4173]および「プリブート実行環境（PXE）仕様」[PXE]で説明されています。
The techniques available for securing Internet-layer configuration are limited. While it is technically possible to perform a very limited subset of IP networking operations without an IP address, the capabilities are severely restricted. A host without an IP address cannot receive conventional unicast IP packets, only IP packets sent to the broadcast or a multicast address. Configuration of an IP address enables the use of IP fragmentation; packets sent from the unknown address cannot be reliably reassembled, since fragments from multiple hosts using the unknown address might be reassembled into a single IP packet. Without an IP address, it is not possible to take advantage of security facilities such as IPsec, specified in "Security Architecture for the Internet Protocol" [RFC4301] or Transport Layer Security (TLS) [RFC5246]. As a result, configuration security is typically implemented within the configuration protocols themselves.
インターネット層構成を保護するために利用可能な手法は限られています。IPアドレスなしでIPネットワーキング操作の非常に限られたサブセットを実行することは技術的に可能ですが、機能は厳しく制限されています。IPアドレスのないホストは、従来のユニキャストIPパケットを受信できず、ブロードキャストまたはマルチキャストアドレスに送信されるIPパケットのみが送信されます。IPアドレスの構成により、IPフラグメンテーションを使用できます。不明なアドレスを使用して複数のホストからのフラグメントが単一のIPパケットに再組み立てされる可能性があるため、不明なアドレスから送信されたパケットを確実に再構築することはできません。IPアドレスがなければ、「インターネットプロトコルのセキュリティアーキテクチャ」[RFC4301]または輸送層セキュリティ（TLS）[RFC5246]で指定されたIPSECなどのセキュリティ機能を利用することはできません。その結果、構成セキュリティは通常、構成プロトコル自体に実装されます。
PPP [RFC1661] does not support secure negotiation within IPv4CP [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to the link to subvert the negotiation. In contrast, IKEv2 [RFC4306] provides encryption, integrity, and replay protection for configuration exchanges.
PPP [RFC1661]は、IPv4CP [RFC1332]またはIPv6CP [RFC5072]内の安全な交渉をサポートせず、攻撃者がリンクにアクセスして交渉を破壊することを可能にします。対照的に、IKEV2 [RFC4306]は、構成交換の暗号化、整合性、およびリプレイ保護を提供します。
Where configuration packets are only expected to originate on particular links or from particular hosts, filtering can help control configuration spoofing. For example, a wireless access point usually has no reason to forward broadcast DHCP DISCOVER packets to its wireless clients, and usually should drop any DHCP OFFER packets received from those wireless clients, since, generally speaking, wireless clients should be requesting addresses from the network, not offering them. To prevent spoofing, communication between the DHCP relay and servers can be authenticated and integrity protected using a mechanism such as IPsec.
構成パケットが特定のリンクまたは特定のホストからのみ発生すると予想される場合、フィルタリングは構成のスプーフィングを制御するのに役立ちます。たとえば、ワイヤレスアクセスポイントには通常、DHCPの発見パケットをワイヤレスクライアントに転送する理由はありません。通常、ワイヤレスクライアントから受け取ったDHCPオファーパケットをドロップする必要があります。、それらを提供していません。スプーフィングを防ぐために、IPSECなどのメカニズムを使用して、DHCPリレーとサーバー間の通信を認証および整合性保護できます。
Internet-layer secure configuration mechanisms include SEcure Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address autoconfiguration [RFC4862], or DHCP authentication for stateful address configuration. DHCPv4 [RFC2131] initially did not include support for security; this was added in "Authentication for DHCP Messages" [RFC3118]. DHCPv6 [RFC3315] included security support. However, DHCP authentication is not widely implemented for either DHCPv4 or DHCPv6.
インターネット層の安全な構成メカニズムには、IPv6 Stateless Address Autoconfiguration [RFC4862]の安全な近隣発見（送信）[RFC3971]、またはステートフルアドレス構成のDHCP認証が含まれます。DHCPV4 [RFC2131]は当初、セキュリティのサポートを含まなかった。これは、「DHCPメッセージの認証」に追加されました[RFC3118]。DHCPV6 [RFC3315]にはセキュリティサポートが含まれていました。ただし、DHCP認証は、DHCPV4またはDHCPV6のいずれにも広く実装されていません。
Higher-layer configuration can make use of a wider range of security techniques. When DHCP authentication is supported, higher-layer configuration parameters provided by DHCP can be secured. However, even if a host does not support DHCPv6 authentication, higher-layer configuration via Stateless DHCPv6 [RFC3736] can still be secured with IPsec.
より高い層構成は、より幅広いセキュリティ手法を利用できます。DHCP認証がサポートされる場合、DHCPによって提供される高層構成パラメーターを保護できます。ただし、ホストがDHCPV6認証をサポートしていなくても、Stateless DHCPV6 [RFC3736]を介した高層構成をIPSECで保護できます。
Possible exceptions can exist where security facilities are not available until later in the boot process. It may be difficult to secure boot configuration even once the Internet layer has been configured, if security functionality is not available until after boot configuration has been completed. For example, it is possible that Kerberos, IPsec, or TLS will not be available until later in the boot process; see "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol" [RFC4173] for discussion.
ブートプロセスの後半までセキュリティ施設が利用できない場合、可能な例外が存在する可能性があります。ブート構成が完了するまでセキュリティ機能が利用できない場合でも、インターネットレイヤーが構成されていても、ブート構成を保護することは困難な場合があります。たとえば、Kerberos、IPSEC、またはTLSは、ブートプロセスの後半まで利用できない可能性があります。ディスカッションについては、「インターネットSmall Computer System Interface（ISCSI）プロトコル」[RFC4173]を使用した「クライアントのブートストラップクライアント」を参照してください。
Where public key cryptography is used to authenticate and integrity-protect configuration, hosts need to be configured with trust anchors in order to validate received configuration messages. For a node that visits multiple administrative domains, acquiring the required trust anchors may be difficult.
公開キーの暗号化が使用されている場合、整合性を保護するために構成を認証および保護するには、受信した構成メッセージを検証するために、ホストを信頼アンカーで構成する必要があります。複数の管理ドメインにアクセスするノードの場合、必要な信頼アンカーを取得することは難しい場合があります。
[3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003.
[3GPP-24.008] 3GPP TS 24.008 V5.8.0、「モバイル無線インターフェイスレイヤー3仕様、コアネットワークプロトコル、ステージ3（リリース5）」、2003年6月。
[DNSTrojan] Goodin, D., "New trojan in mass DNS hijack", The Register, December 5, 2008, http://www.theregister.co.uk/2008/12/05/ new_dnschanger_hijacks/
[Dnstrojan] Goodin、D。、「Mass DNS Hijackの新しいトロイの木馬」、レジスター、2008年12月5日、http：//www.theregister.co.uk/2008/12/05/ new_dnschanger_hijacks/
[IEN116] J. Postel, "Internet Name Server", IEN 116, August 1979, http://www.ietf.org/rfc/ien/ien116.txt
[IEN116] J. Postel、「Internet Name Server」、IEN 116、1979年8月、http：//www.ietf.org/rfc/ien/ien116.txt
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004.
[IEEE-802.1X]電気および電子機器エンジニアの研究所、「地方および大都市圏ネットワーク：ポートベースのネットワークアクセス制御」、IEEE Standard 802.1x-2004、2004年12月。
[DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.
[DNS-SD] Cheshire、S。、およびM. Krochmal、「DNSベースのサービスディスカバリー」、2008年9月、進行中の作業。
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, September 2008.
[MDNS] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、2008年9月、進行中の作業。
[PXE] Henry, M. and M. Johnston, "Preboot Execution Environment (PXE) Specification", September 1999, http://www.pix.net/software/pxeboot/archive/pxespec.pdf
[PXE]ヘンリー、M。およびM.ジョンストン、「プリブート実行環境（PXE）仕様」、1999年9月、http：//www.pix.net/software/pxeboot/archive/pxesp.pdf
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC1001] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods", STD 19, RFC 1001, March 1987.
[RFC1001] Devense Advanced Research Projects Agency、Internet Activity Board、およびEnd-to-End ServicesタスクフォースのNetBiosワーキンググループ、「TCP/UDP輸送に関するNetBiosサービスのプロトコル標準：概念と方法」、STD 19、RFC 1001、1987年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、G。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350]ソリンズ、K。、「TFTPプロトコル（改訂2）」、STD 33、RFC 1350、1992年7月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995.
[RFC1877] Cobb、S。、「名前サーバーアドレスのPPPインターネットプロトコル制御プロトコル拡張」、RFC 1877、1995年12月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter、B.、ed。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.、ed。、およびW. Arbaugh、ed。、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[RFC3397] Aboba、B。およびS. Cheshire、「動的ホスト構成プロトコル（DHCP）ドメイン検索オプション」、RFC 3397、2002年11月。
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456] Patel、B.、Aboba、B.、Kelly、S。、およびV. Gupta、「Ipsecトンネルモードの動的ホスト構成プロトコル（DHCPV4）構成」、RFC 3456、2003年1月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「ネットワークファイルシステム（NFS）バージョン4プロトコル」、RFC 3530、2003年4月。
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、「インターネットスモールコンピューターシステムインターフェイス（ISCSI）」、RFC 3720、2004年4月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Ed。、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、RFC 3756、2004年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004.
[RFC3818] Schryver、V。、「ポイントツーポイントプロトコル（PPP）に対するIANAの考慮事項」、BCP 88、RFC 3818、2004年6月。
[RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV", RFC 3832, July 2004.
[RFC3832] Zhao、W.、Schulzrinne、H.、Guttman、E.、Bisdikian、C。、およびW. Jerome、「DNS SRVを介したサービスロケーションプロトコル（SLP）のリモートサービスディスカバリー」、RFC 3832、2004年7月。
[RFC3898] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[RFC3898] Kalusivalingam、V。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのネットワーク情報サービス（NIS）構成オプション」、RFC 3898、2004年10月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、RFC 3927、2005年5月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
[RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
[RFC4171] Tseng、J.、Gibbons、K.、Travostino、F.、Du Laney、C。、およびJ. Souza、「インターネットストレージ名サービス（ISNS）」、RFC 4171、2005年9月。
[RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005.
[RFC4173] Sarkar、P.、Missimer、D。、およびC. Sapuntzakis、「インターネットSmall Computer System Interface（ISCSI）プロトコルを使用してクライアントをブートストラップする」、RFC 4173、2005年9月。
[RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service", RFC 4174, September 2005.
[RFC4174] Monia、C.、Tseng、J。、およびK. Gibbons、「インターネットストレージ名サービス用のIPv4ダイナミックホスト構成プロトコル（DHCP）オプション」、RFC 4174、2005年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[RFC4339] Jeong、J.、ed。、「DNSサーバー情報アプローチのIPv6ホスト構成」、RFC 4339、2006年2月。
[RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006.
[RFC4477] Chown、T.、Venaas、S。、およびC. Strauf、「動的ホスト構成プロトコル（DHCP）：IPv4およびIPv6デュアルスタックの問題」、RFC 4477、2006年5月。
[RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, November 2006.
[RFC4578] Johnston、M。and S. Venaas、ed。、「Intel Preboot実行環境（PXE）の動的ホスト構成プロトコル（DHCP）オプション」、RFC 4578、2006年11月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-Local Multicast Name Resolution（LLMNR）」、RFC 4795、2007年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072] Varada、S.、ed。、Haskins、D。、およびE. Allen、「PPP上のIPバージョン6」、RFC 5072、2007年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[STD3] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[STD3] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
Braden、R.、ed。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola, James Kempf, Ted Hardie, and Alfred Hoenes provided valuable input on this document.
Elwyn Davies、Bob Hinden、Pasi Eronen、Jari Arkko、Pekka Savola、James Kempf、Ted Hardie、およびAlfred Hoenesは、この文書に貴重な情報を提供しました。
Loa Andersson Gonzalo Camarillo Stuart Cheshire Russ Housley Olaf Kolkman Gregory Lebovitz Barry Leiba Kurtis Lindqvist Andrew Malis Danny McPherson David Oran Dave Thaler Lixia Zhang
ロア・アンダーソン・ゴンザロ・カマリロ・スチュアート・チェシャー・ラス・ハウズリー・オラフ・コルクマン・グレゴリー・レボビッツ・バリー・レイバ・カルティス・リンドクヴィスト・アンドリュー・マリス・ダニー・マクファーソン・デイビッド・オラン・デイバー・ザン・リキシア・ザン
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: bernarda@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: dthaler@microsoft.com
Loa Andersson Ericsson AB
Loa Andersson Ericsson AB
EMail: loa.andersson@ericsson.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino, CA 95014
Stuart Cheshire Apple Computer、Inc。1 Infinite Loop Cupertino、CA 95014
EMail: cheshire@apple.com