Network Working Group B. Aboba
Request for Comments: 5505 D. Thaler
Category: Informational L. Andersson
S. Cheshire
Internet Architecture Board
May 2009
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
Internet主机配置原则
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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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.
本文档描述了Internet主机配置的原则。它涵盖了与Internet层参数的配置有关的问题，以及影响更高层协议的参数。
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
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.
本文档描述了Internet主机[STD3]配置的原理。它涵盖了与Internet层参数的配置有关的问题，以及影响更高层协议的参数。
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 链路层协议和隧道协议在Internet主机配置中的作用。
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:
Internet层配置定义为支持Internet层操作所需的配置。这包括每个接口和每个主机参数的配置，包括IP地址、子网前缀、默认网关、移动代理、引导服务配置和其他参数：
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.
Internet协议（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用于地址配置以外的目的可以安全地假定主机将具有一个或多个IP地址，这些IP地址可以是自配置的链路本地地址[RFC3927][RFC4862]，或通过DHCP或其他方式配置的其他地址。
Subnet prefix(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.
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.
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)).
Internet层参数配置还包括每主机参数（例如主机名）和每接口参数（例如，在传出数据包中使用的IP生存时间（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:
高层配置定义为支持Internet层之上的其他组件的操作所需的配置。这包括，例如：
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 Internet名称服务（WINS）、Internet存储名称服务（iSNS）[RFC4171][RFC4174]和网络信息服务（NIS）服务器[RFC3898]，以及名称解析参数的设置，如DNS域和搜索列表[RFC3397]、NetBIOS节点类型等。它还可能包括主机自身名称的传输或设置。请注意，链路本地名称解析服务（如NetBIOS[RFC1001]、链路本地多播名称解析（LLMNR）[RFC4795]和多播DNS（MDN）[MDN]）通常不需要配置。
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）等协议的服务器配置。由于准确确定时间对于主机上运行的应用程序（包括安全服务）的操作可能很重要，因此时间服务器的配置可能是更高层操作的先决条件。但是，这通常不是Internet层配置的要求。虽然可以基于每个接口提供时间服务参数，但它们的配置通常会影响整个主机的行为。
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.
本节介绍Internet主机配置的基本原则。
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].
也就是说，为了将配置错误的可能性降至最低，应尽可能自动计算参数（或至少具有合理的默认值）。例如，可以发现路径最大传输单元（PMTU），如“分组化层路径MTU发现”[RFC4821]、“路径MTU发现的TCP问题”[RFC2923]、“路径MTU发现”[RFC1191]和“IP版本6的路径MTU发现”[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."
通用Internet主机配置的标准化、简单机制的可用性是非常理想的。“互联网的架构原则”[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
为了在许多类型的设备中支持协议，将占用空间要求降至最低是很重要的。例如，基于IP的协议被广泛应用于各种设备上，从超级计算机到运行“嵌入式”操作系统的小型低成本设备。自从
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.
可用于主机配置的资源（例如，内存和代码大小）可能非常小，希望主机能够以尽可能简单的方式配置自身。
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）中执行引导前代码，并使用最小的可用内存。许多主机在这个ROM中没有足够的空间，即使是简单的TCP实现，因此在预引导执行环境（PXE）中，获取引导映像的任务是使用IP上的用户数据报协议（UDP/IP）[RFC768]来执行的。这就是为什么Internet层配置机制通常只依赖于IP和UDP的原因之一。获得启动映像后，主机将拥有可用的TCP/IP的全部功能，包括对可靠传输协议、IPsec等的支持。
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:
应尽量减少主机配置机制的数量。Internet主机配置机制的多样性带来了几个问题：
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.
因此，非常希望Internet主机配置机制独立于底层。也就是说，只有链路层协议（无论是物理链路还是虚拟隧道链路）应该明确地知道链路层参数（尽管这些链路层参数可以由一般的因特网层机制配置）。低层依赖关系的引入增加了互操作性问题的可能性，并增加了主机需要实现的Internet层配置机制。
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.
通过将Internet主机配置保持在链路层之上，可以最好地避免较低层的依赖关系，从而能够为支持IP的任何链路层处理配置。为了提供媒体独立性，Internet主机配置机制应该是独立于链路层协议的。
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".
例如，“名称服务器地址的PPP互联网协议控制协议扩展”[RFC1877]是在“动态主机配置协议”[RFC2131]中定义DHCPINFORM消息之前开发的；当时，动态主机配置协议（DHCP）服务器还没有在接入设备上广泛实现，也没有部署在服务提供商网络中。虽然IPv4CP的设计在1992年是合适的，但不应将其作为新链路层技术应效仿的例子。事实上，为了“积极推进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]）可用，PPP IPv6CP[RFC5072]配置类似于媒体访问控制（MAC）地址的接口标识符。这使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密钥交换版本2（IKEv2）[RFC4306]通过为IPv4和IPv6的Internet主机配置定义配置有效负载，使用与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的Internet层配置机制在支持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.
网络访问身份验证和授权是与Internet主机配置不同的问题。因此，网络访问身份验证和授权最好独立于Internet和更高层的配置机制进行处理。
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.
协议应该是自配置的（特别是在命运共享很重要的情况下），或者使用通用配置机制（如DHCP或服务发现协议，如第3.2节所述）。选择时应考虑第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之类的Internet主机配置机制中，如果提供了多个服务器实例，则认为它们是可互换的。例如，在时间服务器列表中，服务器被认为是可互换的，因为它们都提供完全相同的服务——告诉您当前时间。在本地缓存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适合于在这些时间间隔内相对静态且不变的信息。服务器地址的启动时发现适用于存在少量可互换服务器的服务类型，这些服务器对大量客户端都感兴趣。例如，在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.
服务发现协议可以支持发现Internet上的服务器，而不仅仅是本地管理域中的服务器。例如，请参阅“通过DNS SRV在服务位置协议（SLP）中进行远程服务发现”[RFC3832]和基于DNS的服务发现[DNS-SD]。另一方面，DHCP等Internet主机配置机制通常假定本地管理域中的一台或多台服务器包含权威信息集。
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地址或名称的机制。因此，服务发现协议通常不能用于获取基本的Internet层配置，尽管它们可以用于获取更高层的配置参数。
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.
“DNS服务器信息方法的IPv6主机配置”[RFC4339]的第3.3节讨论了使用众所周知的选播地址来发现DNS服务器。使用选播地址可以实现命运共享，即使选播地址是由不相关的服务器提供的。然而，为了通用，这种方法需要为每个服务分配一个或多个已知的选播地址。需要配置多个选播地址，以允许客户端以比路由协议收敛更快的速度进行故障转移。
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.
第一种反应不够迅速。在这种情况下，按照预期的成功可能性对列表进行排序将帮助客户更快地获得结果。对于同时支持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，每个服务器都有一个IPv4地址和一个IPv6地址。如果主机应该尝试的第一个地址是（比如）服务器A的IPv6地址，那么主机应该尝试的第二个地址，如果第一个地址失败，通常是服务器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）：IPv4和IPv6双堆栈问题”[RFC4477]，以了解有关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配置带来了许多挑战。除了拒绝服务和中间人攻击外，对配置机制的攻击可能以特定参数为目标。例如，攻击者可能以DNS服务器配置为目标，以支持后续的网络钓鱼或欺骗攻击，如“大规模DNS劫持中的新特洛伊木马”[DNSTrojan]中所述。如“IPv6邻居发现（ND）信任”第2.6节和第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]、“DHCP消息身份验证”[RFC3118]第1.1节和“IPv6动态主机配置协议（DHCPv6）”第23节[RFC3315]。考虑到潜在的漏洞，主机通常会将对DHCP选项的支持限制在提供基本TCP/IP配置所需的最低限度。
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].
由于引导配置决定主机要运行的引导映像，因此对引导配置的成功攻击可能会导致攻击者获得对主机的完全控制。因此，保护引导配置尤其重要。“使用Internet小型计算机系统接口（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.
可用于保护Internet层配置的技术是有限的。虽然从技术上讲，在没有IP地址的情况下执行非常有限的IP网络操作子集是可能的，但这些功能受到严重限制。没有IP地址的主机不能接收传统的单播IP数据包，只能接收发送到广播或多播地址的IP数据包。IP地址的配置允许使用IP分段；从未知地址发送的数据包无法可靠地重新组装，因为来自使用未知地址的多个主机的片段可能会重新组装为单个IP数据包。如果没有IP地址，则无法利用“Internet协议的安全体系结构”[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
如果配置数据包只预期来自特定的链路或特定的主机，则过滤可以帮助控制配置欺骗。例如，无线接入点通常没有理由将广播DHCP DISCOVER分组转发给其无线客户端，并且通常应该丢弃从这些无线客户端接收的任何DHCP OFFER分组，因为一般来说，无线客户端应该从网络请求地址，而不是从网络请求地址
offering them. To prevent spoofing, communication between the DHCP relay and servers can be authenticated and integrity protected using a mechanism such as IPsec.
提供它们。为了防止欺骗，可以使用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.
Internet层安全配置机制包括用于IPv6无状态地址自动配置的安全邻居发现（SEND）[RFC3971]或用于有状态地址配置的DHCP身份验证[RFC4862]。DHCPv4[RFC2131]最初不包括对安全性的支持；这是在“DHCP消息的身份验证”[RFC3118]中添加的。DHCPv6[RFC3315]包括安全支持。但是，DHCPv4或DHCPv6都没有广泛实现DHCP身份验证。
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.
可能存在的例外情况是，安全设施在引导过程的后期才可用。如果安全功能在引导配置完成后才可用，则即使配置了Internet层，也可能很难保护引导配置。例如，Kerberos、IPsec或TLS可能在引导过程的后期才可用；有关讨论，请参阅“使用Internet小型计算机系统接口（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., "New trojan in mass DNS hijack", The
Register, December 5, 2008,
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, August
1979, 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]Cheshire，S.和M.Krocmal，“基于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] Henry, M. and M. Johnston, "Preboot Execution
Environment (PXE) Specification", September 1999,
http://www.pix.net/software/pxeboot/archive/pxespec.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]国防高级研究计划局、互联网活动委员会和端到端服务工作组的NetBIOS工作组，“TCP/UDP传输上NetBIOS服务的协议标准：概念和方法”，STD 19，RFC 10011987年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，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）”，标准51，RFC1661，1994年7月。
[RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995.
[RFC1877]Cobb，S.，“名称服务器地址的PPP互联网协议控制协议扩展”，RFC 18771995年12月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年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的路径MTU发现”，RFC 1981，1996年8月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年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 26081999年6月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年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消息的身份验证”，RFC31182001年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的动态主机配置协议（DHCPv6）”，RFC3315，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邻居发现（ND）信任模型和威胁”，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 37752004年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]Kalusialingam，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链路本地地址的动态配置”，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，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年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 41712005年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，“使用互联网小型计算机系统接口（iSCSI）协议引导客户端”，RFC 41732005年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 43012005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，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.和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.，Thaler，D.，和L.Esibov，“链路本地多播名称解析（LLMNR）”，RFC 47952007年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年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无状态地址自动配置”，RFC 48622007年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中无状态地址自动配置的隐私扩展”，RFC 49412007年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，“传输层安全（TLS）协议版本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
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）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: bernarda@microsoft.com
EMail: bernarda@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
Dave Thaler微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: dthaler@microsoft.com
EMail: dthaler@microsoft.com
Loa Andersson Ericsson AB
安达信爱立信律师事务所
EMail: loa.andersson@ericsson.com
EMail: loa.andersson@ericsson.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino, CA 95014
斯图尔特·柴郡苹果计算机有限公司，加利福尼亚州库比蒂诺市1号无限环路，邮编95014
EMail: cheshire@apple.com
EMail: cheshire@apple.com