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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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ネットワーク、ならびにInternet-あるいは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）、デフォルトゲートウェイ（S）、モビリティエージェント（s）は、ブートサービスの設定および他のパラメータを含むインターフェイスごとおよびホストパラメータの設定が含まれています。
IP address(es)
IPアドレス（複数可）
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]を使用するように、アドレス設定を含みます。この場合、定義によって、ホストはIPv4アドレスを持つ前のDHCPv4が動作しているので、DHCPプロトコルの設計者は、IPアドレスなしにIPを使用して、またはまったくIPを使用していないのいずれかを選択します。いくつかの他のプロトコルに応じて、自身のIPv4パケットを使用して、代わりにそれ自体を構成し、IPv4の自立製造の利点は、この制約モードでIPを使用することの欠点を上回ります。アドレス設定以外の目的のためにIPを使用すると、安全にDHCPまたは他の手段を介して構成された自己構成されたリンクローカルアドレス[RFC3927] [RFC4862]、または他のアドレスとすることができる、ホストは1つまたは複数のIPアドレスを持っていると仮定することができます。
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)
デフォルトゲートウェイ（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の）などのメカニズムを経由して、ブートイメージを得るために探して、ディスクレスホストに適しています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転送の無効化とソースルーティングを可能にする、ホストごとのパラメータ（例えば、ホスト）と発信パケットで使用するインターフェースごとのパラメータ（例えば、IPのTime-To-Live（TTL）の構成を含みます、及び最大伝送単位（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]、およびネットワーク情報を含め、名前解決サーバのアドレスの構成を含みますなどのDNSドメインおよび検索リスト[RFC3397]、NetBIOSノードタイプ、などのサービス（NIS）のサーバ[RFC3898]、および名前解決パラメーターの設定は、それはまた、宿主自身の名前の送信や設定を含むことができます。一般的な構成を必要としない（例えばNetBIOSの[RFC1001]、リンクローカルマルチキャスト名前解決（LLMNR）[RFC4795]、およびマルチキャスト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.
タイムサービスの構成は、このような簡易ネットワークタイムプロトコル（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]で説明したように例えば、パスの最大転送単位（PMTU）は、[RFC2923]、「パスMTUディスカバリ」[RFC1191]、「パスMTUディスカバリとTCPの問題」を発見することができます[RFC1981]と "IPバージョン6のパスMTUディスカバリー"。
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.
一つの興味深い例は、プリブート実行環境におけるIPのサポートです。定義のブート構成でまだ完全に起動していないホストで必要とされているので、プリブートコードは、最小限の使用可能なメモリと、読み出し専用メモリ（ROM）から実行するために、それはしばしば必要です。 IP（UDP / IP）[RFC768を超えるユーザーデータグラムプロトコルを使用して行われるPreboot Execution Environment（PXE）ブートイメージを取得するタスクで非常に多くのホストは、TCPのさえ単純な実装のために、このROMに十分なスペースがありません]の代わりに。これは、インターネット層構造の仕組みは、一般的にのみIPやUDPに依存理由の一つです。ブートイメージを取得した後、ホストはなど、信頼性の高いトランスポートプロトコルのサポートを含め、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."
「インターネットの建築原則」[RFC1958]の状態、「モジュール化は良いです。あなたがそう、物事は分離しておくことができます。」
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.
ホストはダイヤルアップ、無線、有線ローカルエリアネットワークを含む複数のネットワークアクセスメカニズムをサポートすることがますます一般的になりつつあります。無線メトロポリタンおよびワイドエリアネットワーク。等のネットワークアクセスメカニズムの増殖は、それが望ましいホストがそれぞれの新しいリンクレイヤに固有の構成コードを追加することなく、複数のネットワークに自身を設定することができるようになります。
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.
この（「;コアネットワークプロトコル、ステージ3（リリース5）移動無線インタフェースレイヤ3仕様」[3GPP-24.008]そのようなPPP IPv4CP [RFC1332]と同様に）リンク層内のインターネット層構成の例があるがアプローチには欠点があります。これらは、異なるリンクレイヤ上の異なるメカニズムを実装するの余分な複雑さ及び各リンク層プロトコルにおける機構を定義必要とするであろう新たな上位層のパラメータを追加することの難しさが挙げられます。
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".
たとえば、「ネームサーバーアドレスのためのPPPインターネットプロトコル制御プロトコル拡張機能」[RFC1877]は、「動的ホスト構成プロトコル」でDHCPINFORMメッセージの定義に先立って開発された[RFC2131]。その時点で、動的ホスト構成プロトコル（DHCP）サーバーは、広くアクセスデバイスに実装されていなかったか、サービスプロバイダーネットワークで展開します。 IPv4CPのデザインは1992年に適切であったが、新しいリンク層技術をエミュレートする必要があることを例にとるべきではありません。実際、「疑わしい価値の更なる機能強化を防御しながら、積極的に、完全な標準にPPPの最も便利な拡張を進める」ために、「IANAの考慮事項をポイントツーポイントプロトコル（PPP）のために」[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.
このようなステートレス自動[RFC4862]とステートレスDHCPv6の[RFC3736]などのリンク層に依存しないメカニズムが用意されていたIPv6では、PPP IPV6CP [RFC5072]はメディアアクセス制御（MAC）アドレスに類似しているインターフェイス識別子を構成します。これは、DHCPv6の機能の重複を避けるために、PPP IPV6CPを可能にします。
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.
しかし、インターネット鍵交換バージョン2（IKEv2の）[RFC4306]は、IPv4とIPv6の両方のためのインターネットホストの設定のための設定ペイロードを定義することにより、PPP IPv4CPと同じアプローチを採用しています。 IKEv2のアプローチは、パケット交換の回数を減少させるが、「IPsecのトンネルモードの動的ホスト構成プロトコル（DHCPv4の）設定」[RFC3456]はDHCPを活用すると、アドレス管理の統合、アドレスプール管理、再構成の面で利点があり、そして失敗していることを指摘-Over。
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].
Internet-、transport-、または（サーバー設定を含む）は、アプリケーション層構成を目的としたリンク層プロトコルへの拡張は避けるべきです。上位層で見られるような機能拡張は、マイナスのリンクの特性に影響を与えることができます。リンク層プロトコル（またはトンネリングプロトコル）は、個々の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に依存インターネット層構成メカニズムはないだろうIPはなく、EAPをサポートするリンクで使用可能です。
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
Internet-または上位層プロトコルの認証クライアントを有する（例えば、IPアドレスまたはプレフィックスとして）サーバ上ではなく、リンクへのアクセスを得ることからホストを防止するための希少資源の資源の枯渇を防止することが適切です。ユーザが手動で（IPアドレスなど）の構成パラメータを取得するために認証を必要とするホストを設定することができればほとんど価値を有しています。リンクへのアクセスを制御したいネットワーク管理者は、より優れたポートベースのネットワークアクセスのように、この使用して技術を実現することができます
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.
コントロール[IEEE-802.1X]。それは、サーバー上の任意の限られた資源の割り当てを生じさせないため、クライアント認証がステートレス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.
サービス発見プロトコルは、インターネット上のものだけでなく、ローカルの管理ドメイン内のサーバーの検出をサポートすることができます。例えば、 "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.
サーバ（またはサーバのセット）を設定パラメータのセットを取得するために必要とされる場合、それらのパラメータが有効にそれらのサーバーが利用可能にされることなく使用することができないものであれば、「運命の共有」（[RFC1958]のセクション2.3）が保持されます。必要なサーバが利用できないので、彼らが使用できない場合は、この場合には、成功した他の手段を介してこれらのパラメータを得ることはほとんど利益があります。情報のための権限がある唯一のマシンがある場合、不正な情報の可能性が最小化されるように構成されている（すなわち、同期して複数の権威サーバーを維持する必要はありません）。例えば、ルータ広告を経由して、デフォルトゲートウェイを学ぶことは、完璧な運命の共有を提供します。それらが実際に使用することができる場合にのみ場合には、ゲートウェイのアドレスを得ることができます。 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.
セクション3.3 [RFC4339]はDNSサーバーの検出のためのよく知られたエニーキャストアドレスの使用について説明し、「DNSサーバ情報のIPv6ホストの設定は、アプローチ」。エニーキャストアドレスの使用は、エニーキャストアドレスは無関係なサーバによって提供される場合であっても、運命の共有を可能にします。しかし、普遍的に有用であるために、このアプローチは、各サービスのための1つ以上の周知のエニーキャストアドレスの割り当てを必要とするであろう。複数のエニーキャストアドレスの設定は、クライアントは、プロトコルのコンバージェンスをルーティングから可能であるよりも速くをフェールオーバーすることができるようにすることが望ましいです。
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つ以上が応答しない、耐障害性のためです。ホストは通常、最初の一つだけは十分に迅速に応答しない場合、リストに目以降のアドレスを使用しようとし、順番にアドレスをしようとします。このような場合には、成功の期待可能性の順にソートされたリストを持つことは、クライアントがより早く結果を得るのを助けます。 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.
例えば、1つのIPv4アドレスと1つのIPv6アドレスを有する2台のサーバ、A及びB、それぞれが存在すると仮定する。ホストは試してみてください最初のアドレスは、（例えば）サーバAのIPv6アドレスの場合は、2番目のアドレスのホストは、最初の1が失敗した場合、一般的にサーバBのIPv4アドレスになります。これは、のために失敗で、試してみてください最初のアドレスが原因のサーバーダウンしているA、またはホストのIPv6アドレスを持ついくつかの問題のいずれかである可能性があり、またはIPv4アドレスの到達可能性は、すべての可能性とは独立しているため、IPv4アドレスを試みるサーバAへの接続に問題が隣好ましいです失敗の原因。
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サーバアドレスのリストとは別に入手した場合は、リストをマージしようとしているホストは、IPv6はそれだけで試したアドレスとしてIPv4アドレスが同じサーバーに属しているか分からないでしょう。これは、アドレスがどのサーバにまたは、より簡単に、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の文脈におけるデュアルスタックの問題のより多くの議論のための[RFC4477]：「IPv4とIPv6のデュアルスタックの問題動的ホスト構成プロトコル（DHCP）」を参照してください。
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).
ブートサービスの構成が複数のインターフェイスに設けることができるが、特定のホストは、それが同時に処理できるブート負荷の数に制限されてもよいです。たとえば、仮想化をサポートしていないホストは、一度に単一のブート負荷を処理することが可能であり得る、またはNの仮想マシンをサポートできるホストはN同時起動負荷まで処理することが可能であってもよいです。その結果、ホストは、インターフェイスごとに設定されているもののうちに行動するどのブート負荷（複数可）を選択する必要があるかもしれません。これは、ホストが（例えば、ほとんどの少なくともに信頼さ）、それらに優先順位をつけることが必要です。
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
セキュアなIP構成は多くの課題を提示しています。サービス拒否およびman-in-the-middle攻撃に加えて、コンフィギュレーションメカニズムに対する攻撃は、特定のパラメータをターゲットにしてもよいです。例えば、攻撃者は、「質量のDNSハイジャックの新しいトロイの木馬」[DNSTrojan]に記載されているような後続のフィッシングまたはファーミング攻撃をサポートするためにDNSサーバーの構成を標的とし得ます。セクション2.6、「IPv6近隣探索（ND）信託のセクション4.2.7で説明したように多くの問題は、パラメータの種々のクラスに存在します
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.
モデルと脅威」[RFC3756]のセクション1.1 『DHCPメッセージの認証』 [RFC3118]、およびセクション23の 『IPv6のための動的ホスト構成プロトコル（DHCPv6）』 [RFC3315]。潜在的な脆弱性を考えると、ホストは多くの場合のためのサポートを制限基本的な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].
ブート構成は、ホストによって実行されるブートイメージを決定するので、ブート構成に成功した攻撃は、ホストの完全な制御を獲得し、攻撃者につながる可能性があります。その結果、ブート構成が確保されることが特に重要です。コンフィギュレーションのセキュリティをブートするアプローチは、[RFC4173]と「プレブート実行環境（PXE）仕様」[PXE]「インターネット小型コンピュータシステムインタフェース（iSCSIの）プロトコルを使用してブートストラップクライアント」で説明されています。
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（Transport Layer Security）[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 DISCOVERパケットを転送し、する理由がありません、それらを提供していません。なりすましを防ぐために、DHCPリレーとサーバ間の通信は、認証と整合性はIPsecなどのメカニズムを使用して保護することができます。
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ステートレスアドレス自動設定[RFC4862]、またはステートフルアドレス構成のためのDHCP認証のためのセキュア近隣探索（SEND）[RFC3971]を含みます。 DHCPv4 [RFC2131]は、最初は、セキュリティのサポートが含まれていませんでした。これは[RFC3118]「DHCPメッセージの認証」で追加されました。 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の認証をサポートしていない場合でも、ステートレス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が後のブートプロセス中にまで利用されない可能性があり、議論のための[RFC4173]「インターネット小型コンピュータシステムインタフェース（iSCSIの）プロトコルを使用しているクライアントのブートストラップ」を参照してください。
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.、 "質量DNSハイジャックの新しいトロイの木馬"、登録、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.ポステル、 "インターネットネームサーバ"、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標準802.1X-2004、2004年12月。
[DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.
[DNS-SD]チェシャー、S.、およびM. Krochmal、 "DNSベースのサービス発見"、進歩、2008年9月の作業。
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, September 2008.
[mDNSの]チェシャー、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/pxespec.pdf
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]ポステル、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]米国防総省の国防高等研究計画庁内のNetBIOSワーキンググループ、インターネット活動委員会、およびエンドツーエンドサービスタスクフォース、「TCP / UDPトランスポート上のNetBIOSサービスのためのプロトコル標準：概念と方法」、STD 19は、 RFC 1001、1987年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350] Sollins、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]シンプソン、W.、編、 "ポイントツーポイントプロトコル（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]コブ、S.、 "ネームサーバーアドレスのためのPPPインターネットプロトコル制御プロトコル拡張機能"、RFC 1877、1995年12月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、エド。、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[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]ガットマン、E.、パーキンス、C.、Veizades、J.、およびM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.、エド。、およびW. Arbaugh、エド。、 "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.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "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.チェシャー、 "動的ホスト構成プロトコル（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]パテル、B.、Aboba、B.、ケリー、S.、およびV.グプタ、 "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.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、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.、メタ、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.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（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。、編、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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.、BCP 88、RFC 3818、2004年6月 "ポイントツーポイントプロトコル（PPP）のためのIANAの考慮事項"。
[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]趙、W.、Schulzrinneと、H.、ガットマン、E.、Bisdikian、C.、およびW.ジェローム、 "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.、 "ネットワーク情報サービス（NIS）IPv6の動的ホスト構成プロトコル（DHCPv6）のための設定オプション"、RFC 3898、2004年10月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、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.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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]ツェン、J.、ギボンズ、K.、Travostino、F.、デュレイニー、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]サルカール、P.、Missimer、D.、およびC. Sapuntzakis、RFC 4173、2005年9月 "インターネット小型コンピュータシステムインタフェース（iSCSIの）プロトコルを使用しているクライアントのブートストラップ"。
[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]モニア、C.、ツェン、J.、およびK.ギボンズ、 "インターネットストレージネームサービスのIPv4動的ホスト構成プロトコル（DHCP）オプション"、RFC 4174、2005年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[RFC4339]チョン、J.、エド。、 "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]ジョンストン、M.とS. Venaas、エド。、 "インテルプレブート実行環境（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.、ターラー、D.、およびL. Esibov、 "リンクローカルマルチキャスト名前解決（LLMNR）"、RFC 4795、2007年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、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.、エド。、ハスキンズ、D.、およびE.アレン、 "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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[STD3] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[STD3]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
Appendix A. Acknowledgments
付録A.謝辞
Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola, James Kempf, Ted Hardie, and Alfred Hoenes provided valuable input on this document.
エルウィン・デイビス、ボブHindenとパシEronen、ヤリArkko、ペッカSavola、ジェームズ・ケンプ、テッドハーディー、およびアルフレッドHoenessは、この文書に貴重な入力を提供します。
Appendix B. IAB Members at the Time of This Writing
この記事の執筆時点では、付録B. IABメンバー
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
ロア・アンダーソンゴンサロ・カマリロスチュアートチェシャーラスHousleyオラフKolkmanグレゴリーLebovitzバリー・レイバカーティスLindqvistアンドリューMalisダニー・マクファーソンデヴィッドオランデーブターラーLixiaチャン
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: bernarda@microsoft.com
メールアドレス：bernarda@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
デーブターラーマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: dthaler@microsoft.com
メールアドレス：dthaler@microsoft.com
Loa Andersson Ericsson AB
ロア・アンダーソン、エリクソンAB
EMail: loa.andersson@ericsson.com
メールアドレス：loa.andersson@ericsson.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino, CA 95014
スチュアートチェシャーたApple Computer、Inc. 1無限ループクパチーノ、CA 95014
EMail: cheshire@apple.com
メールアドレス：cheshire@apple.com