Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 6272 D. Meyer
Category: Informational Cisco Systems
ISSN: 2070-1721 June 2011
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 6272 D. Meyer
Category: Informational Cisco Systems
ISSN: 2070-1721 June 2011
Internet Protocols for the Smart Grid
智能电网的Internet协议
Abstract
摘要
This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here.
本说明确定了智能电网中使用的互联网协议套件的关键基础设施协议。目标受众是那些寻求有关如何为智能电网构建适当的互联网协议套件配置文件的指导的人。在实践中，这样一个概要文件将包括从这里展示的图片中选择智能电网部署所需的内容。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6272.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6272.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 6
2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 6
2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 9
2.1.3.2. Lower-Layer Networks . . . . . . . . . . . . . . . 9
2.1.4. Media Layers: Physical and Link . . . . . . . . . . . 9
2.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Physical and Data Link Layer Security . . . . . . . . 10
2.2.2. Network, Transport, and Application Layer Security . . 11
2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 13
2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 13
2.3.2. Network Management . . . . . . . . . . . . . . . . . . 13
3. Specific Protocols . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Security Toolbox . . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Authentication, Authorization, and Accounting (AAA) . 14
3.1.2. Network Layer Security . . . . . . . . . . . . . . . . 15
3.1.3. Transport Layer Security . . . . . . . . . . . . . . . 16
3.1.4. Application Layer Security . . . . . . . . . . . . . . 17
3.1.5. Secure Shell . . . . . . . . . . . . . . . . . . . . . 18
3.1.6. Key Management Infrastructures . . . . . . . . . . . . 18
3.1.6.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.6.2. Kerberos . . . . . . . . . . . . . . . . . . . . . 19
3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19
3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 19
3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 20
3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 20
3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 21
3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 22
3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 22
3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 22
3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 23
3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 23
3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 24
3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 24
3.2.4.1. Routing Information Protocol . . . . . . . . . . . 24
3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 24
3.2.4.3. ISO Intermediate System to Intermediate System . . 25
3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 25
3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing . . . . . . 25
3.2.4.6. Optimized Link State Routing Protocol . . . . . . 26
3.2.4.7. Routing for Low-Power and Lossy Networks . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 6
2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 6
2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 9
2.1.3.2. Lower-Layer Networks . . . . . . . . . . . . . . . 9
2.1.4. Media Layers: Physical and Link . . . . . . . . . . . 9
2.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Physical and Data Link Layer Security . . . . . . . . 10
2.2.2. Network, Transport, and Application Layer Security . . 11
2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 13
2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 13
2.3.2. Network Management . . . . . . . . . . . . . . . . . . 13
3. Specific Protocols . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Security Toolbox . . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Authentication, Authorization, and Accounting (AAA) . 14
3.1.2. Network Layer Security . . . . . . . . . . . . . . . . 15
3.1.3. Transport Layer Security . . . . . . . . . . . . . . . 16
3.1.4. Application Layer Security . . . . . . . . . . . . . . 17
3.1.5. Secure Shell . . . . . . . . . . . . . . . . . . . . . 18
3.1.6. Key Management Infrastructures . . . . . . . . . . . . 18
3.1.6.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.6.2. Kerberos . . . . . . . . . . . . . . . . . . . . . 19
3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19
3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 19
3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 20
3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 20
3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 21
3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 22
3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 22
3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 22
3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 23
3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 23
3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 24
3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 24
3.2.4.1. Routing Information Protocol . . . . . . . . . . . 24
3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 24
3.2.4.3. ISO Intermediate System to Intermediate System . . 25
3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 25
3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing . . . . . . 25
3.2.4.6. Optimized Link State Routing Protocol . . . . . . 26
3.2.4.7. Routing for Low-Power and Lossy Networks . . . . . 26
3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 27
3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 27
3.2.6. Adaptation to Lower-Layer Networks and Link Layer
Protocols . . . . . . . . . . . . . . . . . . . . . . 28
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 28
3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 29
3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 29
3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 30
3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 30
3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 31
3.4.3. Network Time . . . . . . . . . . . . . . . . . . . . . 31
3.5. Network Management . . . . . . . . . . . . . . . . . . . . 31
3.5.1. Simple Network Management Protocol (SNMP) . . . . . . 31
3.5.2. Network Configuration (NETCONF) Protocol . . . . . . . 32
3.6. Service and Resource Discovery . . . . . . . . . . . . . . 33
3.6.1. Service Discovery . . . . . . . . . . . . . . . . . . 33
3.6.2. Resource Discovery . . . . . . . . . . . . . . . . . . 33
3.7. Other Applications . . . . . . . . . . . . . . . . . . . . 34
3.7.1. Session Initiation Protocol . . . . . . . . . . . . . 34
3.7.2. Extensible Messaging and Presence Protocol . . . . . . 35
3.7.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 35
4. A Simplified View of the Business Architecture . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Normative References . . . . . . . . . . . . . . . . . . . 40
7.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Example: Advanced Metering Infrastructure . . . . . . 58
A.1. How to Structure a Network . . . . . . . . . . . . . . . . 59
A.1.1. HAN Routing . . . . . . . . . . . . . . . . . . . . . 62
A.1.2. HAN Security . . . . . . . . . . . . . . . . . . . . . 62
A.2. Model 1: AMI with Separated Domains . . . . . . . . . . . 64
A.3. Model 2: AMI with Neighborhood Access to the Home . . . . 65
A.4. Model 3: Collector Is an IP Router . . . . . . . . . . . . 66
3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 27
3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 27
3.2.6. Adaptation to Lower-Layer Networks and Link Layer
Protocols . . . . . . . . . . . . . . . . . . . . . . 28
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 28
3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 29
3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 29
3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 30
3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 30
3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 31
3.4.3. Network Time . . . . . . . . . . . . . . . . . . . . . 31
3.5. Network Management . . . . . . . . . . . . . . . . . . . . 31
3.5.1. Simple Network Management Protocol (SNMP) . . . . . . 31
3.5.2. Network Configuration (NETCONF) Protocol . . . . . . . 32
3.6. Service and Resource Discovery . . . . . . . . . . . . . . 33
3.6.1. Service Discovery . . . . . . . . . . . . . . . . . . 33
3.6.2. Resource Discovery . . . . . . . . . . . . . . . . . . 33
3.7. Other Applications . . . . . . . . . . . . . . . . . . . . 34
3.7.1. Session Initiation Protocol . . . . . . . . . . . . . 34
3.7.2. Extensible Messaging and Presence Protocol . . . . . . 35
3.7.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 35
4. A Simplified View of the Business Architecture . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Normative References . . . . . . . . . . . . . . . . . . . 40
7.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Example: Advanced Metering Infrastructure . . . . . . 58
A.1. How to Structure a Network . . . . . . . . . . . . . . . . 59
A.1.1. HAN Routing . . . . . . . . . . . . . . . . . . . . . 62
A.1.2. HAN Security . . . . . . . . . . . . . . . . . . . . . 62
A.2. Model 1: AMI with Separated Domains . . . . . . . . . . . 64
A.3. Model 2: AMI with Neighborhood Access to the Home . . . . 65
A.4. Model 3: Collector Is an IP Router . . . . . . . . . . . . 66
This document provides Smart Grid designers with advice on how to best "profile" the Internet Protocol Suite (IPS) for use in Smart Grids. It provides an overview of the IPS and the key infrastructure protocols that are critical in integrating Smart Grid devices into an IP-based infrastructure.
本文档为智能电网设计师提供了有关如何最佳“配置”智能电网中使用的互联网协议套件（IPS）的建议。它概述了IP和关键基础设施协议，这些协议对于将智能电网设备集成到基于IP的基础设施中至关重要。
In the words of Wikipedia [SmartGrid]:
用维基百科[SmartGrid]的话说：
A Smart Grid is a form of electricity network utilizing digital technology. A Smart Grid delivers electricity from suppliers to consumers using two-way digital communications to control appliances at consumers' homes; this saves energy, reduces costs and increases reliability and transparency. It overlays the ordinary electrical Grid with an information and net metering system, that includes smart meters. Smart Grids are being promoted by many governments as a way of addressing energy independence, global warming and emergency resilience issues.
智能电网是一种利用数字技术的电网形式。智能电网通过双向数字通信将电力从供应商输送到消费者，以控制消费者家中的电器；这节省了能源，降低了成本，提高了可靠性和透明度。它在普通电网上覆盖了一个信息和网络计量系统，包括智能电表。许多政府都在推动智能电网，以此作为解决能源独立、全球变暖和应急恢复问题的一种方式。
A Smart Grid is made possible by applying sensing, measurement and control devices with two-way communications to electricity production, transmission, distribution and consumption parts of the power Grid that communicate information about Grid condition to system users, operators and automated devices, making it possible to dynamically respond to changes in Grid condition.
智能电网是通过将具有双向通信的传感、测量和控制设备应用于电网的发电、输电、配电和用电部分而实现的，这些发电、输电、配电和用电部分将有关电网状况的信息传达给系统用户、操作员和自动化设备，使其能够动态响应网格条件的变化。
A Smart Grid includes an intelligent monitoring system that keeps track of all electricity flowing in the system. It also has the capability of integrating renewable electricity such as solar and wind. When power is least expensive the user can allow the smart Grid to turn on selected home appliances such as washing machines or factory processes that can run at arbitrary hours. At peak times it could turn off selected appliances to reduce demand.
智能电网包括一个智能监控系统，可以跟踪系统中的所有电流。它还具备整合太阳能和风能等可再生电力的能力。当电力最便宜时，用户可以允许智能电网打开选定的家用电器，如洗衣机或可在任意时间运行的工厂流程。在高峰期，它可以关闭选定的电器以减少需求。
Other names for a Smart Grid (or for similar proposals) include smart electric or power Grid, intelligent Grid (or intelliGrid), futureGrid, and the more modern interGrid and intraGrid.
智能电网（或类似方案）的其他名称包括智能电力或电力电网、智能电网（或智能电网）、未来电网以及更现代的interGrid和interGrid。
That description focuses on the implications of Smart Grid technology in the home of a consumer. In fact, data communications technologies of various kinds are used throughout the Grid, to monitor and maintain power generation, transmission, and distribution, as well as the operations and management of the Grid. One can view the Smart Grid as a collection of interconnected computer networks that connects and serves the needs of public and private electrical utilities and their customers.
该描述侧重于智能电网技术对消费者家庭的影响。事实上，各种数据通信技术在整个电网中都得到了应用，用于监测和维护发电、输电和配电，以及电网的运行和管理。人们可以将智能电网视为一组相互连接的计算机网络，连接并满足公共和私人电力设施及其客户的需求。
At the time of this writing, there is no single document that can be described as comprising an internationally agreed standard for the Smart Grid; that is in part the issue being addressed in its development. The nearest approximations are probably the Smart Grid Interoperability Panel's Conceptual Model [Model] and documents comprising [IEC61850].
在撰写本文时，没有一份文件可以被描述为包含智能电网的国际商定标准；这在一定程度上是其发展过程中正在解决的问题。最接近的近似值可能是智能电网互操作性小组的概念模型[Model]和包含[IEC61850]的文件。
The Internet Protocol Suite (IPS) provides options for numerous architectural components. For example, the IPS provides several choices for the traditional transport function between two systems: the Transmission Control Protocol (TCP) [RFC0793], the Stream Control Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP) [RFC4340]. Another option is to select an encapsulation such as the User Datagram Protocol (UDP) [RFC0768], which essentially allows an application to implement its own transport service. In practice, a designer will pick a transport protocol that is appropriate to the problem being solved.
Internet协议套件（IPS）为许多体系结构组件提供了选项。例如，IPS为两个系统之间的传统传输功能提供了几种选择：传输控制协议（TCP）[RFC0793]、流控制传输协议（SCTP）[RFC4960]和数据报拥塞控制协议（DCCP）[RFC4340]。另一个选项是选择封装，例如用户数据报协议（UDP）[RFC0768]，它本质上允许应用程序实现自己的传输服务。在实践中，设计者将选择一种适合于所解决问题的传输协议。
The IPS is standardized by the Internet Engineering Task Force (IETF). IETF protocols are documented in the Request for Comments (RFC) series. Several RFCs have been written describing how the IPS should be implemented. These include:
IPS由互联网工程任务组（IETF）标准化。IETF协议记录在征求意见（RFC）系列中。已经编写了几个RFC来描述IPS应该如何实现。这些措施包括：
o Requirements for Internet Hosts - Communication Layers [RFC1122],
o 互联网主机要求-通信层[RFC1122]，
o Requirements for Internet Hosts - Application and Support [RFC1123],
o 互联网主机要求-应用程序和支持[RFC1123]，
o Requirements for IP Version 4 Routers [RFC1812], and
o IP版本4路由器[RFC1812]的要求，以及
o IPv6 Node Requirements [RFC4294].
o IPv6节点要求[RFC4294]。
At the time of this writing, RFC 4294 is in the process of being updated, in [IPv6-NODE-REQ].
在撰写本文时，[IPv6节点请求]中的RFC 4294正在更新中。
This document is intended to provide Smart Grid architects and designers with a compendium of relevant RFCs (and to some extent, Internet Drafts), and is organized as an annotated list of RFCs. To that end, the remainder of this document is organized as follows:
本文件旨在为智能电网架构师和设计师提供相关RFC（在某种程度上，还包括互联网草案）的概要，并以RFC注释列表的形式组织。为此，本文件其余部分的组织如下：
o Section 2 describes the Internet Architecture and its protocol suite.
o 第2节描述了Internet体系结构及其协议套件。
o Section 3 outlines a set of protocols that may be useful in Smart Grid deployment. It is not exhaustive.
o 第3节概述了一组在智能电网部署中可能有用的协议。它并非详尽无遗。
o Finally, Section 4 provides an overview of the business architecture embodied in the design and deployment of the IPS.
o 最后，第4节概述了IPS设计和部署中体现的业务体系结构。
Before enumerating the list of Internet protocols relevant to Smart Grid, we discuss the layered architecture of the IPS, the functions of the various layers, and their associated protocols.
在列举与智能电网相关的互联网协议列表之前，我们将讨论IPS的分层体系结构、各层的功能及其相关协议。
While Internet architecture uses the definitions and language similar to language used by the ISO Open System Interconnect (ISO-OSI) reference model (Figure 1), it actually predates that model. As a result, there is some skew in terminology. For example, the ISO-OSI model uses "end system" while the Internet architecture uses "host". Similarly, an "intermediate system" in the ISO-OSI model is called an "internet gateway" or "router" in Internet parlance. Notwithstanding these differences, the fundamental concepts are largely the same.
虽然互联网体系结构使用的定义和语言与ISO开放系统互连（ISO-OSI）参考模型（图1）使用的语言相似，但它实际上早于该模型。因此，术语上存在一些偏差。例如，ISO-OSI模型使用“终端系统”，而Internet体系结构使用“主机”。类似地，ISO-OSI模型中的“中间系统”在互联网术语中称为“互联网网关”或“路由器”。尽管存在这些差异，但基本概念基本相同。
+--------------------+
| Application Layer |
+--------------------+
| Presentation Layer |
+--------------------+
| Session Layer |
+--------------------+
| Transport Layer |
+--------------------+
| Network Layer |
+--------------------+
| Data Link Layer |
+--------------------+
| Physical Layer |
+--------------------+
+--------------------+
| Application Layer |
+--------------------+
| Presentation Layer |
+--------------------+
| Session Layer |
+--------------------+
| Transport Layer |
+--------------------+
| Network Layer |
+--------------------+
| Data Link Layer |
+--------------------+
| Physical Layer |
+--------------------+
Figure 1: The ISO OSI Reference Model
图1:ISO OSI参考模型
The structure of the Internet reference model is shown in Figure 2.
Internet参考模型的结构如图2所示。
+---------------------------------+
|Application |
| +---------------------------+ |
| | Application Protocol | |
| +----------+----------------+ |
| | Encoding | Session Control| |
| +----------+----------------+ |
+---------------------------------+
|Transport |
| +---------------------------+ |
| | Transport Layer | |
| +---------------------------+ |
+---------------------------------+
|Network |
| +---------------------------+ |
| | Internet Protocol | |
| +---------------------------+ |
| | Lower Network Layers | |
| +---------------------------+ |
+---------------------------------+
|Media Layers |
| +---------------------------+ |
| | Data Link Layer | |
| +---------------------------+ |
| | Physical Layer | |
| +---------------------------+ |
+---------------------------------+
+---------------------------------+
|Application |
| +---------------------------+ |
| | Application Protocol | |
| +----------+----------------+ |
| | Encoding | Session Control| |
| +----------+----------------+ |
+---------------------------------+
|Transport |
| +---------------------------+ |
| | Transport Layer | |
| +---------------------------+ |
+---------------------------------+
|Network |
| +---------------------------+ |
| | Internet Protocol | |
| +---------------------------+ |
| | Lower Network Layers | |
| +---------------------------+ |
+---------------------------------+
|Media Layers |
| +---------------------------+ |
| | Data Link Layer | |
| +---------------------------+ |
| | Physical Layer | |
| +---------------------------+ |
+---------------------------------+
Figure 2: The Internet Reference Model
图2：互联网参考模型
In the Internet model, the Application, Presentation, and Session layers are compressed into a single entity called "the application". For example, the Simple Network Management Protocol (SNMP) [RFC3411] describes an application that encodes its data in an ASN.1 profile and engages in a session to manage a network element. The point here is that in the Internet, the distinction between these layers exists but is not highlighted. Further, note that in Figure 2, these functions are not necessarily cleanly layered: the fact that an application protocol encodes its data in some way and that it manages sessions in some way doesn't imply a hierarchy between those processes. Rather, the application views encoding, session management, and a variety of other services as a tool set that it uses while doing its work.
在Internet模型中，应用程序层、表示层和会话层被压缩为一个称为“应用程序”的实体。例如，简单网络管理协议（SNMP）[RFC3411]描述了一个应用程序，该应用程序在ASN.1配置文件中对其数据进行编码，并参与管理网元的会话。这里的要点是，在互联网中，这些层之间存在区别，但没有突出显示。此外，请注意，在图2中，这些函数不一定是干净分层的：应用程序协议以某种方式对其数据进行编码，并以某种方式管理会话，这一事实并不意味着这些进程之间存在层次结构。相反，应用程序将编码、会话管理和各种其他服务视为一个工具集，在执行工作时使用。
The term "transport" is perhaps among the most confusing concepts in the communication architecture, to a large extent because people with various backgrounds use it to refer to "the layer below that which I am interested in, which gets my data to my peer". For example, optical network engineers refer to optical fiber and associated electronics as "the transport", while web designers refer to the Hypertext Transfer Protocol (HTTP) [RFC2616] (an application layer protocol) as "the transport".
术语“传输”可能是通信体系结构中最容易混淆的概念之一，在很大程度上是因为具有不同背景的人使用它来指代“我感兴趣的层下面的层，它将我的数据传递给我的同龄人”。例如，光网络工程师将光纤和相关电子设备称为“传输”，而web设计师将超文本传输协议（HTTP）[RFC2616]（应用层协议）称为“传输”。
In the Internet protocol stack, the "transport" is the lowest protocol layer that travels end-to-end unmodified, and it is responsible for end-to-end data delivery services. In the Internet, the transport layer is the layer above the network layer. Transport layer protocols have a single minimum requirement: the ability to multiplex several applications on one IP address. UDP [RFC0768], TCP [RFC0793], DCCP [RFC4340], SCTP [RFC4960], and NORM [RFC5740] each accomplish this using a pair of port numbers, one for the sender and one for the receiver. A port number identifies an application instance, which might be a general "listener" that peers or clients may open sessions with, or a specific correspondent with such a "listener". The session identification in an IP datagram is often called the "five-tuple", and consists of the source and destination IP addresses, the source and destination ports, and an identifier for the transport protocol in use.
在Internet协议栈中，“传输”是未经修改的端到端传输的最低协议层，负责端到端的数据传输服务。在Internet中，传输层是网络层之上的层。传输层协议有一个最低要求：能够在一个IP地址上多路传输多个应用程序。UDP[RFC0768]、TCP[RFC0793]、DCCP[RFC4340]、SCTP[RFC4960]和NORM[RFC5740]都使用一对端口号来实现这一点，一个用于发送方，一个用于接收方。端口号标识应用程序实例，该实例可能是对等方或客户端可以打开会话的通用“侦听器”，也可能是与此类“侦听器”的特定对应方。IP数据报中的会话标识通常称为“五元组”，由源和目标IP地址、源和目标端口以及所用传输协议的标识符组成。
In addition, the responsibilities of a specific transport layer protocol typically include the delivery of data (either as a stream of messages or a stream of bytes) in a stated sequence with stated expectations regarding delivery rate and loss. For example, TCP will reduce its rate in response to loss, as a congestion control trigger, while DCCP accepts some level of loss if necessary to maintain timeliness.
此外，特定传输层协议的责任通常包括按照规定的顺序交付数据（作为消息流或字节流），并对交付速率和损失进行规定的预期。例如，TCP将降低其速率以响应丢失，作为拥塞控制触发器，而DCCP则在必要时接受一定程度的丢失以保持及时性。
The main function of the network layer is to identify a remote destination and deliver data to it. In connection-oriented networks such as Multi-protocol Label Switching (MPLS) [RFC3031] or Asynchronous Transfer Mode (ATM), a path is set up once, and data is delivered through it. In connectionless networks such as Ethernet and IP, data is delivered as datagrams. Each datagram contains both the source and destination network layer addresses, and the network is responsible for delivering it. In the Internet Protocol Suite, the Internet Protocol is the network that runs end to end. It may be encapsulated over other LAN and WAN technologies, including both IP networks and networks of other types.
网络层的主要功能是识别远程目的地并向其传送数据。在面向连接的网络中，如多协议标签交换（MPLS）[RFC3031]或异步传输模式（ATM），一次建立一条路径，然后通过该路径传输数据。在以太网和IP等无连接网络中，数据以数据报的形式传输。每个数据报都包含源和目标网络层地址，网络负责传递这些地址。在Internet协议套件中，Internet协议是端到端运行的网络。它可以封装在其他LAN和WAN技术上，包括IP网络和其他类型的网络。
IPv4 and IPv6, each of which is called the Internet Protocol, are connectionless ("datagram") architectures. They are designed as common elements that interconnect network elements across a network of lower-layer networks. In addition to the basic service of identifying a datagram's source and destination, they offer services to fragment and reassemble datagrams when necessary, assist in diagnosis of network failures, and carry additional information necessary in special cases.
IPv4和IPv6都称为Internet协议，是无连接（“数据报”）体系结构。它们被设计为公共元件，跨低层网络的网络互连网络元件。除了识别数据报源和目的地的基本服务外，它们还提供必要时对数据报进行分段和重新组装的服务，帮助诊断网络故障，并在特殊情况下携带必要的附加信息。
The Internet layer provides a uniform network abstraction network that hides the differences between various network technologies. This is the layer that allows diverse networks such as Ethernet, 802.15.4, etc. to be combined into a uniform IP network. New network technologies can be introduced into the IP Protocol Suite by defining how IP is carried over those technologies, leaving the other layers of the IPS and applications that use those protocol unchanged.
Internet层提供了一个统一的网络抽象网络，它隐藏了各种网络技术之间的差异。这一层允许将以太网、802.15.4等多种网络组合成统一的IP网络。新的网络技术可以通过定义IP在这些技术上的传输方式引入IP协议套件，而使用这些协议的IP和应用程序的其他层保持不变。
The network layer can be recursively subdivided as needed. This may be accomplished by tunneling, in which an IP datagram is encapsulated in another IP header for delivery to a decapsulator. IP is frequently carried in Virtual Private Networks (VPNs) across the public Internet using tunneling technologies such as the Tunnel mode of IPsec, IP-in-IP, and Generic Route Encapsulation (GRE) [RFC2784]. In addition, IP is also frequently carried in circuit networks such as MPLS [RFC4364], GMPLS, and ATM. Finally, IP is also carried over wireless networks (IEEE 802.11, 802.15.4, or 802.16) and switched Ethernet (IEEE 802.3) networks.
网络层可以根据需要递归细分。这可以通过隧道来实现，在隧道中，IP数据报被封装在另一个IP报头中以传送到解封装器。IP经常通过使用隧道技术（如IPsec的隧道模式、IP中的IP和通用路由封装（GRE））在公共互联网上的虚拟专用网络（VPN）中传输[RFC2784]。此外，IP也经常在MPLS[RFC4364]、GMPLS和ATM等电路网络中传输。最后，IP也通过无线网络（IEEE 802.11、802.15.4或802.16）和交换式以太网（IEEE 802.3）网络传输。
At the lowest layer of the IP architecture, data is encoded in messages and transmitted over the physical media. While the IETF specifies algorithms for carrying IPv4 and IPv6 various media types, it rarely actually defines the media -- it happily uses specifications from IEEE, ITU, and other sources.
在IP体系结构的最底层，数据被编码在消息中并通过物理媒体传输。虽然IETF指定了承载IPv4和IPv6各种媒体类型的算法，但它很少实际定义媒体——它乐于使用IEEE、ITU和其他来源的规范。
While complaining about the security of the Internet is popular, it is important to distinguish between attacks on protocols and attacks on users (e.g., phishing). Attacks on users are largely independent of protocol details, reflecting interface design issues or user education problems, and are out of scope for this document. Security problems with Internet protocols are in scope, of course, and can
尽管抱怨互联网的安全性很普遍，但区分对协议的攻击和对用户的攻击（如网络钓鱼）很重要。对用户的攻击在很大程度上与协议细节无关，反映了接口设计问题或用户教育问题，不在本文档的范围之内。当然，互联网协议的安全问题在范围之内，并且可以
often be mitigated using existing security features already specified for the protocol, or by leveraging the security services offered by other IETF protocols. See the Security Assessment of the Transmission Control Protocol (TCP) [TCP-SEC] and the Security Assessment of the Internet Protocol version 4 [IP-SEC] for more information on TCP and IPv4 issues, respectively.
通常可以使用已经为协议指定的现有安全功能，或利用其他IETF协议提供的安全服务来缓解。有关TCP和IPv4问题的更多信息，请分别参阅传输控制协议（TCP）[TCP-SEC]的安全评估和Internet协议版本4[IP-SEC]的安全评估。
These solutions do, however, need to get deployed as well. The road to widespread deployment can sometimes be painful since often multiple stakeholders need to take actions. Experience has shown that this takes some time, and very often only happens when the incentives are high enough in relation to the costs.
然而，这些解决方案也需要部署。实现广泛部署的道路有时是痛苦的，因为往往需要多个利益相关者采取行动。经验表明，这需要一些时间，而且通常只有在激励措施相对于成本足够高的情况下才会发生。
Furthermore, it is important to stress that available standards are important, but the range of security problems is larger than a missing standard; many security problems are the result of implementation bugs and the result of certain deployment choices. While these are outside the realm of standards development, they play an important role in the security of the overall system. Security has to be integrated into the entire process.
此外，重要的是要强调现有标准很重要，但安全问题的范围比缺少的标准更大；许多安全问题是实现错误和某些部署选择的结果。虽然这些不属于标准开发的范畴，但它们在整个系统的安全性方面发挥着重要作用。必须将安全纳入整个过程。
The IETF takes security seriously in the design of their protocols and architectures; every IETF specification has to have a Security Considerations section to document the offered security threats and countermeasures. RFC 3552 [RFC3552] provides recommendations on writing such a Security Considerations section. It also describes the classical Internet security threat model and lists common security goals.
IETF在协议和架构的设计中非常重视安全性；每个IETF规范都必须有一个安全注意事项部分来记录提供的安全威胁和对策。RFC3552[RFC3552]提供了编写此类安全注意事项部分的建议。它还描述了经典的互联网安全威胁模型，并列出了常见的安全目标。
In a nutshell, security has to be integrated into every protocol, protocol extension, and consequently, every layer of the protocol stack to be useful. We illustrate this also throughout this document with references to further security discussions. Our experience has shown that dealing with security as an afterthought does not lead to the desired outcome.
简而言之，安全性必须集成到每个协议、协议扩展中，因此，协议栈的每一层都是有用的。我们在本文档中也对这一点进行了说明，并参考了进一步的安全讨论。我们的经验表明，事后处理安全问题不会产生预期的结果。
The discussion of security threats and available security mechanisms aims to illustrate some of the design aspects that commonly appear.
对安全威胁和可用安全机制的讨论旨在说明一些常见的设计方面。
At the physical and data link layers, threats generally center on physical attacks on the network -- the effects of backhoes, deterioration of physical media, and various kinds of environmental noise. Radio-based networks are subject to signal fade due to distance, interference, and environmental factors; it is widely noted that IEEE 802.15.4 networks frequently place a metal ground plate between the meter and the device that manages it. Fiber was at one
在物理层和数据链路层，威胁通常集中在对网络的物理攻击上——反铲的影响、物理介质的恶化和各种环境噪音。由于距离、干扰和环境因素，基于无线电的网络容易出现信号衰减；人们广泛注意到，IEEE 802.15.4网络经常在电表和管理电表的设备之间放置金属接地板。纤维在一起
time deployed because it was believed to be untappable; we have since learned to tap it by bending the fiber and collecting incidental light, and we have learned about backhoes. As a result, some installations encase fiber optic cable in a pressurized sheath, both to quickly identify the location of a cut and to make it more difficult to tap.
时间被部署，因为它被认为是不可实现的；从那以后，我们学会了通过弯曲光纤和收集附带的光线来挖掘它，我们还学会了反铲。因此，一些装置将光纤电缆包裹在加压护套中，以快速识别切口位置，并使其更难分接。
While there are protocol behaviors that can detect certain classes of physical faults, such as keep-alive exchanges, physical security is generally not considered to be a protocol problem.
虽然有一些协议行为可以检测某些类别的物理故障，例如保持活动的交换，但物理安全通常不被认为是协议问题。
For wireless transmission technologies, eavesdropping on the transmitted frames is also typically a concern. Additionally, those operating networks may want to ensure that access to their infrastructure is restricted to those who are authenticated and authorized (typically called 'network access authentication'). This procedure is often offered by security primitives at the data link layer.
对于无线传输技术，对传输帧的窃听通常也是一个问题。此外，这些操作网络可能希望确保对其基础设施的访问仅限于经过身份验证和授权的人（通常称为“网络访问身份验证”）。此过程通常由数据链路层的安全原语提供。
At the network, transport, and application layers, it is common to demand a few basic security requirements, commonly referred to as CIA (Confidentiality, Integrity, and Availability):
在网络、传输和应用层，通常需要一些基本的安全要求，通常称为CIA（机密性、完整性和可用性）：
1. Confidentiality: Protect the transmitted data from unauthorized disclosure (i.e., keep eavesdroppers from learning what was transmitted). For example, for trust in e-commerce applications, credit card transactions are exchanged encrypted between the Web browser and a Web server.
1. 保密性：保护传输的数据免受未经授权的泄露（即防止窃听者了解传输的内容）。例如，为了信任电子商务应用程序，信用卡交易在Web浏览器和Web服务器之间进行加密交换。
2. Integrity: Protect against unauthorized changes to exchanges, including both intentional change or destruction and accidental change or loss, by ensuring that changes to exchanges are detectable. It has two parts: one for the data and one for the peers.
2. 完整性：通过确保可检测到交换的更改，防止未经授权的交换更改，包括故意更改或破坏以及意外更改或丢失。它有两个部分：一个用于数据，另一个用于对等点。
* Peers need to verify that information that appears to be from a trusted peer is really from that peer. This is typically called 'data origin authentication'.
* 对等方需要验证似乎来自受信任对等方的信息确实来自该对等方。这通常称为“数据源身份验证”。
* Peers need to validate that the content of the data exchanged is unmodified. The term typically used for this property is 'data integrity'.
* 对等方需要验证交换的数据内容是否未被修改。此属性通常使用的术语是“数据完整性”。
3. Availability: Ensure that the resource is accessible by mitigating of denial-of-service attacks.
3. 可用性：通过减少拒绝服务攻击，确保资源可访问。
To this we add authenticity, which requires that the communicating peers prove that they are in fact who they say they are to each other (i.e., mutual authentication). This generally means knowing "who" the peer is, and that they demonstrate the possession of a "secret" as part of the security protocol interaction.
除此之外，我们还增加了真实性，这要求通信的对等方证明他们实际上是他们彼此所说的人（即相互认证）。这通常意味着知道对等方是谁，并且他们证明拥有作为安全协议交互的一部分的“秘密”。
The following three examples aim to illustrate these security requirements.
以下三个示例旨在说明这些安全性要求。
One common attack against a TCP session is to bombard the session with reset messages. Other attacks against TCP include the "SYN flooding" attack, in which an attacker attempts to exhaust the memory of the target by creating TCP state. In particular, the attacker attempts to exhaust the target's memory by opening a large number of unique TCP connections, each of which is represented by a Transmission Control Block (TCB). The attack is successful if the attacker can cause the target to fill its memory with TCBs.
对TCP会话的一种常见攻击是用重置消息轰炸会话。其他针对TCP的攻击包括“SYN洪泛”攻击，在这种攻击中，攻击者试图通过创建TCP状态来耗尽目标的内存。特别是，攻击者试图通过打开大量独特的TCP连接来耗尽目标内存，每个连接都由传输控制块（TCB）表示。如果攻击者能够使目标用TCB填充其内存，则攻击成功。
A number of mechanisms have been developed to deal with these types of denial-of-service attacks. One, "SYN Cookies", delays state establishment on the server side to a later phase in the protocol exchange. Another mechanism, specifically targeting the reset attack cited above, provides authentication services in TCP itself to ensure that fake resets are rejected.
已经开发了许多机制来处理这些类型的拒绝服务攻击。一个是“SYN Cookies”，它将服务器端的状态建立延迟到协议交换的稍后阶段。另一种机制专门针对上述重置攻击，在TCP本身中提供身份验证服务，以确保拒绝虚假重置。
Another approach would be to offer security protection already at a lower layer, such as IPsec (see Section 3.1.2) or TLS (see Section 3.1.3), so that a host can identify legitimate messages and discard the others, thus mitigating any damage that may have been caused by the attack.
另一种方法是在较低层提供安全保护，如IPsec（见第3.1.2节）或TLS（见第3.1.3节），以便主机可以识别合法消息并丢弃其他消息，从而减轻攻击可能造成的任何损害。
Another common attack involves unauthorized access to resources. For example, an unauthorized party might try to attach to a network. To protect against such an attack, an Internet Service Provider (ISP) typically requires network access authentication of new hosts demanding access to the network and to the Internet prior to offering access. This exchange typically requires authentication of that entity and a check in the ISPs back-end database to determine whether corresponding subscriber records exist and are still valid (e.g., active subscription and sufficient credits).
另一种常见的攻击涉及未经授权访问资源。例如，未经授权的一方可能试图连接到网络。为了防止此类攻击，Internet服务提供商（ISP）通常需要在提供访问之前对要求访问网络和Internet的新主机进行网络访问身份验证。此交换通常需要对该实体进行身份验证，并在ISPs后端数据库中进行检查，以确定相应的订户记录是否存在且仍然有效（例如，活动订阅和足够的信用）。
From the discussion above, establishing a secure communication channel is clearly an important concept frequently used to mitigate a range of attacks. Unfortunately, focusing only on channel security may not be enough for a given task. Threat models have evolved and even some of the communication endpoints cannot be considered fully trustworthy, i.e., even trusted peers may act maliciously.
从上面的讨论可以看出，建立安全的通信通道显然是一个重要的概念，经常被用来缓解一系列攻击。不幸的是，仅关注通道安全性可能不足以完成给定的任务。威胁模型已经演变，甚至一些通信端点也不能被认为是完全可信的，即，即使是可信的对等方也可能会恶意行事。
Furthermore, many protocols are more sophisticated in their protocol interaction and involve more than two parties in the protocol exchange. Many of the application layer protocols, such as email, instant messaging, voice over IP, and presence-based applications, fall into this category. With this class of protocols, secure data, such as DNS records, and secure communications with middleware, intermediate servers, and supporting applications need to be considered as well as the security of the direct communication. A detailed treatment of the security threats and requirements of these multi-party protocols is beyond this specification but the interested reader is referred to the above-mentioned examples for an illustration of what technical mechanisms have been investigated and proposed in the past.
此外，许多协议在协议交互方面更为复杂，协议交换涉及两方以上。许多应用层协议，如电子邮件、即时消息、IP语音和基于状态的应用程序，都属于这一类。对于这类协议，除了直接通信的安全性外，还需要考虑安全数据（如DNS记录）、与中间件、中间服务器和支持应用程序的安全通信。这些多方协议的安全威胁和要求的详细处理超出了本规范的范围，但感兴趣的读者可以参考上述示例，以说明过去研究和提出了哪些技术机制。
While the following protocols are not critical to the design of a specific system, they are important to running a network, and as such are surveyed here.
虽然以下协议对于特定系统的设计并不重要，但它们对于运行网络很重要，因此本文将对其进行概述。
The DNS' main function is translating names to numeric IP addresses. While this is not critical to running a network, certain functions are made a lot easier if numeric addresses can be replaced with mnemonic names. This facilitates renumbering of networks and generally improves the manageability and serviceability of the network. DNS has a set of security extensions called DNSSEC, which can be used to provide strong cryptographic authentication to the DNS. DNS and DNSSEC are discussed further in Section 3.4.1.
DNS的主要功能是将名称转换为数字IP地址。虽然这对运行网络并不重要，但如果可以用助记符名称替换数字地址，则某些功能会变得容易得多。这有助于网络的重新编号，并通常提高网络的可管理性和可维护性。DNS有一组称为DNSSEC的安全扩展，可用于向DNS提供强加密身份验证。DNS和DNSSEC将在第3.4.1节中进一步讨论。
Network management has proven to be a difficult problem. As such, various solutions have been proposed, implemented, and deployed. Each solution has its proponents, all of whom have solid arguments for their viewpoints. The IETF has two major network management solutions for device operation: SNMP, which is ASN.1-encoded and is primarily used for monitoring of system variables, and NETCONF [RFC4741], which is XML-encoded and primarily used for device configuration.
网络管理已被证明是一个难题。因此，已经提出、实施和部署了各种解决方案。每一种解决方案都有其支持者，他们都有自己的观点。IETF有两种主要的设备操作网络管理解决方案：SNMP（采用ASN.1编码，主要用于监控系统变量）和NETCONF[RFC4741]，采用XML编码，主要用于设备配置。
Another aspect of network management is the initial provisioning and configuration of hosts, which is discussed in Section 3.4.2. Note that Smart Grid deployments may require identity authentication and authorization (as well as other provisioning and configuration) that may not be within the scope of either DHCP or Neighbor Discovery. While the IP Protocol Suite has limited support for secure
网络管理的另一个方面是主机的初始配置和配置，这将在第3.4.2节中讨论。请注意，智能电网部署可能需要身份验证和授权（以及其他资源调配和配置），这可能不在DHCP或邻居发现的范围内。而IP协议套件对安全性的支持有限
provisioning and configuration, these problems have been solved using IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0].
在资源调配和配置方面，这些问题已通过使用DOCSIS 3.0[SP-MULPIv3.0]等规范中的IP协议得到解决。
In this section, having briefly laid out the IP architecture and some of the problems that the architecture tries to address, we introduce specific protocols that might be appropriate to various Smart Grid use cases. Use cases should be analyzed along with privacy, Authentication, Authorization, and Accounting (AAA), transport, and network solution dimensions. The following sections provide guidance for such analysis.
在本节中，我们简要介绍了IP体系结构以及该体系结构试图解决的一些问题，然后介绍了可能适用于各种智能电网用例的特定协议。用例应该与隐私、身份验证、授权和计费（AAA）、传输和网络解决方案维度一起进行分析。以下各节为此类分析提供了指导。
As noted, a key consideration in security solutions is a good threat analysis coupled with appropriate mitigation strategies at each layer. The IETF has over time developed a number of building blocks for security based on the observation that protocols often demand similar security services. The following sub-sections outline a few of those commonly used security building blocks. Reusing them offers several advantages, such as availability of open source code, experience with existing systems, a number of extensions that have been developed, and the confidence that the listed technologies have been reviewed and analyzed by a number of security experts.
如前所述，安全解决方案中的一个关键考虑因素是良好的威胁分析以及每一层的适当缓解策略。随着时间的推移，IETF根据协议通常需要类似安全服务的观察结果，开发了许多安全构建块。以下小节概述了一些常用的安全构建块。重用它们提供了一些优势，例如开放源代码的可用性、现有系统的经验、已开发的许多扩展，以及所列技术已被许多安全专家审查和分析的信心。
It is important to highlight that in addition to the mentioned security tools, every protocol often comes with additional, often unique security considerations that are specific to the domain in which the protocol operates. Many protocols include features specifically designed to mitigate these protocol-specific risks. In other cases, the security considerations will identify security-relevant services that are required from other network layers to achieve appropriate levels of security.
必须强调的是，除了上述安全工具外，每个协议通常还附带附加的、通常是独特的安全注意事项，这些安全注意事项特定于协议运行所在的域。许多协议包括专门设计用于缓解这些协议特定风险的功能。在其他情况下，安全考虑因素将确定其他网络层需要的安全相关服务，以实现适当的安全级别。
While the term AAA sounds generic and applicable to all sorts of security protocols, it has been, in the IETF, used in relation to network access authentication and is associated with the RADIUS ([RFC2865]) and the Diameter protocol ([RFC3588], [DIME-BASE]) in particular.
虽然术语AAA听起来是通用的，适用于各种安全协议，但在IETF中，它已被用于网络访问认证，并与RADIUS（[RFC2865]）和DIAME协议（[RFC3588]，[DIME-BASE]）尤其相关。
The authentication procedure for network access aims to deal with the task of verifying that a peer is authenticated and authorized prior to accessing a particular resource (often connectivity to the Internet). Typically, the authentication architecture for network access consists of the following building blocks: the Extensible
网络访问的身份验证过程旨在处理在访问特定资源（通常是连接到Internet）之前验证对等方是否经过身份验证和授权的任务。通常，网络访问的身份验证体系结构由以下构建块组成：可扩展的
Authentication Protocol (EAP [RFC4017]) as a container to encapsulate EAP methods, an EAP Method (as a specific way to perform cryptographic authentication and key exchange, such as described in RFC 5216 [RFC5216] and RFC 5433 [RFC5433]), a protocol that carries EAP payloads between the end host and a server-side entity (such as a network access server), and a way to carry EAP payloads to back-end server infrastructure (potentially in a cross-domain scenario) to provide authorization and accounting functionality. The latter part is provided by RADIUS and Diameter. To carry EAP payloads between the end host and a network access server, different mechanisms have been standardized, such as the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191] and IEEE 802.1X [IEEE802.1X]. For access to remote networks, such as enterprise networks, the ability to utilize EAP within IKEv2 [RFC5996] has also been developed.
认证协议（EAP[RFC4017]）作为封装EAP方法的容器，EAP方法（作为执行加密认证和密钥交换的特定方式，如RFC 5216[RFC5216]和RFC 5433[RFC5433]中所述），在终端主机和服务器端实体之间承载EAP有效负载的协议（例如网络访问服务器），以及将EAP有效负载传送到后端服务器基础架构的方法（可能在跨域场景中）提供授权和记帐功能。后一部分由RADIUS和Diameter提供。为了在终端主机和网络访问服务器之间承载EAP有效负载，已对不同的机制进行了标准化，例如承载网络访问身份验证协议（PANA）[RFC5191]和IEEE 802.1X[IEEE802.1X].为了访问远程网络，如企业网络，还开发了在IKEv2[RFC5996]中利用EAP的能力。
More recently, the same architecture with EAP and RADIUS/Diameter is being reused for application layer protocols. More details about this architectural variant can be found in [ABFAB-ARCH].
最近，与EAP和RADIUS/Diameter相同的体系结构被重新用于应用层协议。有关此架构变体的更多详细信息，请参见[ABFAB-ARCH]。
IP security, as described in [RFC4301], addresses security at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms. It offers a set of security services for traffic at the IP layer, in both the IPv4 and IPv6 environment. The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic-flow confidentiality. These services are provided at the IP layer, offering protection in a standard fashion for all protocols that may be carried over IP (including IP itself).
如[RFC4301]所述，IP安全解决了IP层的安全问题，通过使用密码和协议安全机制的组合提供。它为IPv4和IPv6环境中的IP层流量提供了一组安全服务。提供的一组安全服务包括访问控制、无连接完整性、数据源身份验证、检测和拒绝重播（部分序列完整性的一种形式）、机密性（通过加密）和有限流量机密性。这些服务在IP层提供，以标准方式为可能通过IP承载的所有协议（包括IP本身）提供保护。
The architecture foresees a split between the rather time-consuming (a) authentication and key exchange protocol step that also establishes a security association (a data structure with keying material and security parameters) and (b) the actual data traffic protection.
该体系结构预见了相当耗时的（a）认证和密钥交换协议步骤（该步骤还建立了安全关联（具有密钥材料和安全参数的数据结构））和（b）实际数据流量保护之间的分离。
For the former step, the Internet Key Exchange protocol version 2 (IKEv2 [RFC5996]) is the most recent edition of the standardized protocol. IKE negotiates each of the cryptographic algorithms that will be used to protect the data independently, somewhat like selecting items a la carte.
对于前一步，Internet密钥交换协议版本2（IKEv2[RFC5996]）是标准化协议的最新版本。IKE协商用于独立保护数据的每个加密算法，有点像点菜式选择项目。
For the actual data protection, two types of protocols have historically been used, namely the IP Authentication Header (AH)
对于实际的数据保护，历史上使用过两种类型的协议，即IP认证头（AH）
[RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. The two differ in the security services they offer; the most important distinction is that ESP offers confidentiality protection while AH does not. Since ESP can also provide authentication services, most recent protocol developments making use of IPsec only specify use of ESP and do not use AH.
[RFC4302]和封装安全有效负载（ESP）[RFC4303]。两者提供的安全服务不同；最重要的区别是ESP提供保密保护，而AH不提供。由于ESP还可以提供身份验证服务，因此使用IPsec的最新协议开发只指定使用ESP，而不使用AH。
In addition to these base line protocol mechanisms a number of extensions have been developed for IKEv2 (e.g., an extension to perform EAP-only authentication [RFC5998]) and since the architecture supports flexible treatment of cryptographic algorithms a number of them have been specified (e.g., [RFC4307] for IKEv2, and [RFC4835] for AH and ESP).
除了这些基线协议机制外，还为IKEv2开发了许多扩展（例如，执行仅EAP身份验证的扩展[RFC5998]），并且由于体系结构支持灵活处理加密算法，因此已经指定了许多扩展（例如，为IKEv2开发了[RFC4307]，为AH和ESP开发了[RFC4835]）。
Transport Layer Security v1.2 [RFC5246] are security services that protect data above the transport layer. The protocol allows client/ server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. TLS is application protocol independent.
传输层安全v1.2[RFC5246]是保护传输层之上数据的安全服务。该协议允许客户机/服务器应用程序以防止窃听、篡改或消息伪造的方式进行通信。TLS与应用程序协议无关。
TLS is composed of two layers: the TLS Record protocol and the TLS Handshake protocol. The TLS Record protocol provides connection security that has two basic properties: (a) confidentiality protection and (b) integrity protection.
TLS由两层组成：TLS记录协议和TLS握手协议。TLS记录协议提供具有两个基本属性的连接安全性：（a）机密性保护和（b）完整性保护。
The TLS Handshake protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The negotiated parameters and the derived keying material is then used by the TLS Record protocol to perform its job.
TLS握手协议允许服务器和客户端在应用程序协议传输或接收其第一个字节的数据之前相互验证并协商加密算法和加密密钥。TLS记录协议随后使用协商的参数和派生的键控材料来执行其工作。
Unlike IKEv2/IPsec, TLS negotiates these cryptographic parameters in suites, so-called 'cipher suites'. Examples of cipher suites that can be negotiated with TLS include Elliptic Curve Cryptography (ECC) [RFC4492] [RFC5289] [AES-CCM-ECC], Camellia [RFC5932], and the Suite B Profile [RFC5430]. [IEC62351-3] outlines the use of different TLS cipher suites for use in the Smart Grid. The basic cryptographic mechanisms for ECC have been documented in [RFC6090].
与IKEv2/IPsec不同，TLS在套件中协商这些加密参数，即所谓的“密码套件”。可与TLS协商的密码套件示例包括椭圆曲线密码（ECC）[RFC4492][RFC5289][AES-CCM-ECC]、Camellia[RFC5932]和套件B配置文件[RFC5430]。[IEC62351-3]概述了智能电网中不同TLS密码套件的使用。[RFC6090]中记录了ECC的基本加密机制。
TLS must run over a reliable transport channel -- typically TCP. In order to offer the same security services for unreliable datagram traffic, such as UDP, the Datagram Transport Layer Security (DTLS [RFC4347] [DTLS]) was developed.
TLS必须运行在可靠的传输通道上——通常是TCP。为了为不可靠的数据报流量（如UDP）提供相同的安全服务，开发了数据报传输层安全（DTLS[RFC4347][DTLS]）。
In certain cases, the application layer independent security mechanisms described in the previous sub-sections are not sufficient to deal with all the identified threats. For this purpose, a number of security primitives are additionally available at the application layer where the semantic of the application can be considered.
在某些情况下，前面小节中描述的独立于应用层的安全机制不足以处理所有已识别的威胁。为此，在应用层还可以使用许多安全原语，其中可以考虑应用程序的语义。
We will focus our description on a few mechanisms that are commonly used throughout the Internet.
我们将重点介绍互联网上常用的几种机制。
Cryptographic Message Syntax (CMS [RFC5652]) is an encapsulation syntax to sign, digest, authenticate, or encrypt arbitrary message content. It also allows arbitrary attributes, such as signing time, to be signed along with the message content, and it provides for other attributes such as countersignatures to be associated with a signature. The CMS can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX (Public Key Infrastructure using X.509) working group [RFC5280]. The CMS has been leveraged to supply security services in a variety of protocols, including secure email [RFC5751], key management [RFC5958] [RFC6031], and firmware updates [RFC4108].
加密消息语法（CMS[RFC5652]）是一种封装语法，用于对任意消息内容进行签名、摘要、验证或加密。它还允许将任意属性（如签名时间）与消息内容一起签名，并提供与签名关联的其他属性（如反签名）。CMS可以支持各种基于证书的密钥管理体系结构，例如PKIX（使用X.509的公钥基础设施）工作组[RFC5280]定义的体系结构。CMS已被用于以多种协议提供安全服务，包括安全电子邮件[RFC5751]、密钥管理[RFC5958][RFC6031]和固件更新[RFC4108]。
Related work includes the use of digital signatures on XML-encoded documents, which has been jointly standardized by W3C and the IETF [RFC3275]. Digitally signed XML is a good choice where applications natively support XML-encoded data, such as the Extensible Messaging and Presence Protocol (XMPP).
相关工作包括在XML编码文档上使用数字签名，这已由W3C和IETF联合标准化[RFC3275]。数字签名XML是一个很好的选择，因为应用程序本机支持XML编码的数据，例如可扩展消息和状态协议（Extensible Messaging and Presence Protocol，XMPP）。
More recently, the work on delegated authentication and authorization often demanded by Web applications have been developed with the Open Web Authentication (OAuth) protocol [RFC5849] [OAUTHv2]. OAuth is used by third-party applications to gain access to protected resources (such as energy consumption information about a specific household) without having the resource owner share its long-term credentials with that third-party. In OAuth, the third-party application requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner. More specifically, the third-party applications obtain an access token during the OAuth protocol exchange. This token denotes a specific scope, duration, and other access attributes. As a result, it securely gains access to the protected resource with the consent of the resource owner.
最近，Web应用程序经常需要的委托身份验证和授权工作已使用开放式Web身份验证（OAuth）协议[RFC5849][OAUTHv2]开发。第三方应用程序使用OAuth来访问受保护的资源（例如特定家庭的能耗信息），而无需资源所有者与该第三方共享其长期凭据。在OAuth中，第三方应用程序请求访问由资源所有者控制并由资源服务器托管的资源，并获得与资源所有者不同的凭据集。更具体地说，第三方应用程序在OAuth协议交换期间获得访问令牌。此标记表示特定的范围、持续时间和其他访问属性。因此，在资源所有者的同意下，它可以安全地访问受保护的资源。
The Secure Shell (SSH) protocol [RFC4253] has been widely used by administrators and others for secure remote login, but is also usable for secure tunneling. More recently, protocols have chosen to layer on top of SSH for transport security services; for example, the NETCONF network management protocol (see Section 3.5.2) uses SSH as its main communications security protocol.
安全Shell（SSH）协议[RFC4253]已被管理员和其他人广泛用于安全远程登录，但也可用于安全隧道。最近，协议选择在SSH之上分层以提供传输安全服务；例如，NETCONF网络管理协议（见第3.5.2节）使用SSH作为其主要通信安全协议。
All of the security protocols discussed above depend on cryptography for security, and hence require some form of key management. Most IETF protocols at least nominally require some scalable form of key management to be defined as mandatory to implement; indeed the lack of such key management features has in the past been a reason to delay approval of protocols. There are two generic key management schemes that are widely used by other Internet protocols, PKIX and Kerberos, each of which is briefly described below.
上面讨论的所有安全协议都依赖于加密来实现安全性，因此需要某种形式的密钥管理。大多数IETF协议至少名义上要求将某种可扩展形式的密钥管理定义为强制实施；事实上，缺乏此类关键管理功能在过去一直是推迟批准协议的原因。有两种通用密钥管理方案被其他互联网协议广泛使用，即PKIX和Kerberos，下面将简要介绍这两种方案。
Public Key Infrastructure (PKI) refers to the kind of key management that is based on certification authorities (CAs) issuing public key certificates for other key holders. By chaining from a trust anchor (a locally trusted copy of a CA public key) down to the public key of some protocol peer, PKI allows for secure binding between keys and protocol-specific names, such as email addresses, and hence enables security services such as data and peer authentication, data integrity, and confidentiality (encryption).
公钥基础设施（PKI）是指一种基于证书颁发机构（CA）为其他密钥持有者颁发公钥证书的密钥管理。通过将信任锚点（CA公钥的本地受信任副本）链接到某个协议对等方的公钥，PKI允许密钥和特定于协议的名称（如电子邮件地址）之间的安全绑定，从而启用安全服务，如数据和对等方身份验证、数据完整性和机密性（加密）。
The main Internet standard for PKI is [RFC5280], which is a profile of the X.509 public key certificate format. There are a range of private and commercial CAs operating today providing the ability to manage and securely distribute keys for all protocols that use public key certificates, e.g., TLS and S/MIME. In addition to the profile standard, the PKIX working group has defined a number of management protocols (e.g., [RFC5272] and [RFC4210]) as well as protocols for handling revocation of public key certificates such as the Online Certificate Status Protocol (OCSP) [RFC2560].
PKI的主要互联网标准是[RFC5280]，它是X.509公钥证书格式的一个配置文件。目前有一系列的私有和商业CA正在运行，它们能够为使用公钥证书的所有协议（如TLS和S/MIME）管理和安全分发密钥。除了概要文件标准外，PKIX工作组还定义了许多管理协议（例如[RFC5272]和[RFC4210]），以及用于处理公钥证书撤销的协议，例如在线证书状态协议（OCSP）[RFC2560]。
PKI is generally perceived to better handle use-cases spanning multiple independent domains when compared to Kerberos.
与Kerberos相比，PKI通常被认为能够更好地处理跨多个独立域的用例。
The Kerberos Network Authentication System [RFC4120] is commonly used within organizations to centralize authentication, authorization, and policy in one place. Kerberos natively supports usernames and passwords as the basis of authentication. With Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC4556], Kerberos supports certificate or public-key-based authentication. This may provide an advantage by concentrating policy about certificate validation and mapping of certificates to user accounts in one place. Through the GSS-API [RFC1964] [RFC2743] [RFC4121], Kerberos can be used to manage authentication for most applications. While Kerberos works best within organizations and enterprises, it does have facilities that permit authentication to be shared between administrative domains.
Kerberos网络身份验证系统[RFC4120]通常用于组织内部，将身份验证、授权和策略集中在一个地方。Kerberos本机支持用户名和密码作为身份验证的基础。使用公钥加密技术在Kerberos（PKINIT）[RFC4556]中进行初始身份验证，Kerberos支持基于证书或公钥的身份验证。通过将有关证书验证和证书到用户帐户的映射的策略集中在一个地方，这可能会提供一个优势。通过GSS-API[RFC1964][RFC2743][RFC4121]，Kerberos可用于管理大多数应用程序的身份验证。虽然Kerberos在组织和企业中工作得最好，但它确实具有允许在管理域之间共享身份验证的功能。
The IPS specifies two network layer protocols: IPv4 and IPv6. The following sections describe the IETF's coexistence and transition mechanisms for IPv4 and IPv6.
IPS指定了两个网络层协议：IPv4和IPv6。以下各节介绍IETF针对IPv4和IPv6的共存和转换机制。
Note that on 3 February 2011, the IANA's IPv4 free pool (the pool of available, unallocated IPv4 addresses) was exhausted, and the Regional Internet Registrars' (RIRs') free pools are expected to be exhausted during the coming year, if not sooner. The IETF, the IANA, and the RIRs recommend that new deployments use IPv6, and that IPv4 infrastructures be supported via the mechanisms described in Section 3.2.1.
请注意，2011年2月3日，IANA的IPv4免费池（可用的、未分配的IPv4地址池）已耗尽，而地区互联网注册商（RIR）的免费池预计将在来年耗尽，甚至更早。IETF、IANA和RIR建议新部署使用IPv6，并通过第3.2.1节中描述的机制支持IPv4基础设施。
The IETF has specified a variety of mechanisms designed to facilitate IPv4/IPv6 coexistence. The IETF actually recommends relatively few of them: the current advice to network operators is found in Guidelines for Using IPv6 Transition Mechanisms [RFC6180]. The thoughts in that document are replicated here.
IETF规定了各种机制，旨在促进IPv4/IPv6共存。IETF实际上推荐的建议相对较少：目前对网络运营商的建议见IPv6转换机制使用指南[RFC6180]。该文件中的思想在此复制。
The simplest coexistence approach is to
最简单的共存方法是
o provide a network that routes both IPv4 and IPv6,
o 提供同时路由IPv4和IPv6的网络，
o ensure that servers and their applications similarly support both protocols, and
o 确保服务器及其应用程序同样支持这两种协议，以及
o require that all new systems and applications purchased or upgraded support both protocols.
o 要求所有购买或升级的新系统和应用程序支持这两种协议。
The net result is that over time all systems become protocol agnostic, and that eventually maintenance of IPv4 support becomes a business decision. This approach is described in the Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213].
最终的结果是，随着时间的推移，所有系统都变得与协议无关，最终维护IPv4支持成为一项业务决策。IPv6主机和路由器的基本转换机制[RFC4213]中描述了这种方法。
In those places in the network that support only IPv4, the simplest and most reliable approach to coexistence is to provide virtual connectivity using tunnels or encapsulations. Early in IPv6 deployment, this was often done using static tunnels. A more dynamic approach is documented in IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5569].
在网络中仅支持IPv4的地方，最简单、最可靠的共存方法是使用隧道或封装提供虚拟连接。在IPv6部署的早期，这通常是使用静态隧道完成的。IPv4基础设施上的IPv6快速部署（6rd）[RFC5569]中记录了一种更具动态性的方法。
In those cases where an IPv4-only host would like to communicate with an IPv6-only host (or vice versa), a need for protocol translation may be indicated. At first blush, protocol translation may appear trivial; on deeper inspection, it turns out that protocol translation can be complicated.
在仅IPv4主机希望与仅IPv6主机通信的情况下（反之亦然），可能需要协议转换。乍一看，协议翻译可能显得微不足道；深入研究后发现，协议翻译可能会很复杂。
The most reliable approach to protocol translation is to provide application layer proxies or gateways, which natively enable application-to-application connections using both protocols and can use whichever is appropriate. For example, a web proxy might use both protocols and as a result enable an IPv4-only system to run HTTP across an IPv6-only network or to a web server that implements only IPv6. Since this approach is a service of a protocol-agnostic server, it is not the subject of standardization by the IETF.
协议转换的最可靠的方法是提供应用层代理或网关，这些代理或网关本机使用两种协议启用应用程序到应用程序的连接，并且可以使用任何合适的协议。例如，web代理可能同时使用这两种协议，从而使仅IPv4的系统能够跨仅IPv6的网络或仅实现IPv6的web服务器运行HTTP。由于该方法是协议无关服务器的服务，因此它不是IETF标准化的主题。
For those applications in which network layer translation is indicated, the IETF has designed a translation mechanism, which is described in the following documents:
对于那些指明了网络层翻译的应用，IETF设计了一种翻译机制，如下文件所述：
o Framework for IPv4/IPv6 Translation [RFC6144]
o IPv4/IPv6转换框架[RFC6144]
o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]
o IPv4/IPv6转换器的IPv6寻址[RFC6052]
o DNS extensions [RFC6147]
o DNS扩展[RFC6147]
o IP/ICMP Translation Algorithm [RFC6145]
o IP/ICMP转换算法[RFC6145]
o Translation from IPv6 Clients to IPv4 Servers [RFC6146]
o 从IPv6客户端到IPv4服务器的转换[RFC6146]
As with IPv4/IPv4 Network Address Translation, translation between IPv4 and IPv6 has limited real world applicability for an application protocol that carries IP addresses in its payload and expects those addresses to be meaningful to both client and server. However, for those protocols that do not, protocol translation can provide a useful network extension.
与IPv4/IPv4网络地址转换一样，IPv4和IPv6之间的转换限制了在其有效负载中承载IP地址并期望这些地址对客户端和服务器都有意义的应用程序协议的实际适用性。然而，对于那些不这样做的协议，协议转换可以提供有用的网络扩展。
Network-based translation provides for two types of services: stateless (and therefore scalable and load-sharable) translation between IPv4 and IPv6 addresses that embed an IPv4 address in them, and stateful translation similar to IPv4/IPv4 translation between IPv4 addresses. The stateless mode is straightforward to implement, but due to the embedding, requires IPv4 addresses to be allocated to an otherwise IPv6-only network, and is primarily useful for IPv4- accessible servers implemented in the IPv6 network. The stateful mode allows clients in the IPv6 network to access servers in the IPv4 network, but does not provide such service for IPv4 clients accessing IPv6 peers or servers with general addresses; it has the advantage that it does not require that a unique IPv4 address be embedded in the IPv6 address of hosts using this mechanism.
基于网络的转换提供两种类型的服务：在IPv4和IPv6地址之间嵌入IPv4地址的无状态（因此可扩展且可负载共享）转换，以及类似于IPv4地址之间IPv4/IPv4转换的有状态转换。无状态模式很容易实现，但由于嵌入，需要将IPv4地址分配给仅限IPv6的网络，并且主要适用于在IPv6网络中实现的可访问IPv4的服务器。有状态模式允许IPv6网络中的客户端访问IPv4网络中的服务器，但不为访问IPv6对等点或具有通用地址的服务器的IPv4客户端提供此类服务；它的优点是不需要在使用此机制的主机的IPv6地址中嵌入唯一的IPv4地址。
Finally, note that some site networks are IPv6 only while some transit networks are IPv4 only. In these cases, it may be necessary to tunnel IPv6 over IPv4 or translate between IPv6 and IPv4.
最后，请注意，有些站点网络仅为IPv6，而有些传输网络仅为IPv4。在这些情况下，可能需要通过IPv4对IPv6进行隧道传输或在IPv6和IPv4之间进行转换。
IPv4 [RFC0791] and the Internet Control Message Protocol (ICMP) [RFC0792] comprise the IPv4 network layer. IPv4 provides unreliable delivery of datagrams.
IPv4[RFC0791]和Internet控制消息协议（ICMP）[RFC0792]构成IPv4网络层。IPv4提供了不可靠的数据报传递。
IPv4 also provides for fragmentation and reassembly of long datagrams for transmission through networks with small Maximum Transmission Units (MTU). The MTU is the largest packet size that can be delivered across the network. In addition, the IPS provides ICMP [RFC0792], which is a separate protocol that enables the network to report errors and other issues to hosts that originate problematic datagrams.
IPv4还提供了长数据报的分段和重组，以便通过具有较小最大传输单元（MTU）的网络进行传输。MTU是可以通过网络传送的最大数据包大小。此外，IPS还提供ICMP[RFC0792]，这是一个单独的协议，使网络能够向产生问题数据报的主机报告错误和其他问题。
IPv4 originally supported an experimental type of service field that identified eight levels of operational precedence styled after the requirements of military telephony, plus three and later four bit flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 [RFC2328] interpreted as control traffic; this control traffic is assured of not being dropped when queued or upon receipt, even if other traffic is being dropped. These control bits turned out to be less useful than the designers had hoped. They were replaced by the Differentiated Services Architecture [RFC2474] [RFC2475], which
IPv4最初支持一种实验型服务域，该服务域确定了八个级别的操作优先级，按照军事电话的要求进行设计，加上OSI IS-IS（IS-IS）[RFC1195]和OSPF版本2[RFC2328]解释为控制流量的三个和更高的四位标志；此控制流量在排队或接收时不会被丢弃，即使其他流量正在被丢弃。结果证明，这些控制位没有设计者所希望的那么有用。它们被差异化服务体系结构[RFC2474][RFC2475]所取代，后者
contains a six-bit code point used to select an algorithm (a "per-hop behavior") to be applied to the datagram. The IETF has also produced a set of Configuration Guidelines for DiffServ Service Classes [RFC4594], which describes a set of service classes that may be useful to a network operator.
包含一个六位代码点，用于选择要应用于数据报的算法（“每跳行为”）。IETF还为DiffServ服务类[RFC4594]制定了一套配置指南，其中描述了一套可能对网络运营商有用的服务类。
IPv4 addresses are administratively assigned, usually using automated methods, using the Dynamic Host Configuration Protocol (DHCP) [RFC2131]. On most interface types, neighboring systems identify each others' addresses using the Address Resolution Protocol (ARP) [RFC0826].
IPv4地址通常使用自动方法，通过动态主机配置协议（DHCP）[RFC2131]进行管理分配。在大多数接口类型上，相邻系统使用地址解析协议（ARP）[RFC0826]识别彼此的地址。
Routing for the IPv4 Internet is accomplished by routing applications that exchange connectivity information and build semi-static destination routing databases. If a datagram is directed to a given destination address, the address is looked up in the routing database, and the most specific ("longest") prefix found that contains it is used to identify the next-hop router or the end system to which it will be delivered. This is not generally implemented on hosts, although it can be; a host normally sends datagrams to a router on its local network, and the router carries out the intent.
IPv4 Internet的路由由交换连接信息和构建半静态目标路由数据库的路由应用程序完成。如果数据报指向给定的目标地址，则会在路由数据库中查找该地址，找到的包含该地址的最特定（“最长”）前缀将用于标识下一跳路由器或将其发送到的终端系统。这通常不会在主机上实现，尽管可以；主机通常向其本地网络上的路由器发送数据报，路由器执行该意图。
IETF specified routing protocols include RIP Version 2 [RFC2453], OSI IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4 [RFC4271]. Active research exists in mobile ad hoc routing and other routing paradigms; these result in new protocols and modified forwarding paradigms.
IETF指定的路由协议包括RIP版本2[RFC2453]、用于IPv4的OSI IS-IS[RFC1195]、OSPF版本2[RFC2328]和BGP-4[RFC4271]。移动自组织路由和其他路由模式的研究比较活跃；这些导致了新的协议和改进的转发模式。
IPv4 was originally specified as a unicast (point to point) protocol, and was extended to support multicast in [RFC1112]. This uses the Internet Group Management Protocol [RFC3376] [RFC4604] to enable applications to join multicast groups, and for most applications uses Source-Specific Multicast [RFC4607] for routing and delivery of multicast messages.
IPv4最初被指定为单播（点对点）协议，并在[RFC1112]中扩展为支持多播。这使用Internet组管理协议[RFC3376][RFC4604]来允许应用程序加入多播组，并且对于大多数应用程序，使用源特定多播[RFC4607]来路由和传递多播消息。
An experiment carried out in IPv4 that is not part of the core Internet architecture but may be of interest in the Smart Grid is the development of so-called "Reliable Multicast". This is "so-called" because it is not "reliable" in the strict sense of the word -- it is perhaps better described as "enhanced reliability". A best effort network by definition can lose traffic, duplicate it, or reorder it, something as true for multicast as for unicast. Research in
在IPv4中进行的一项实验不是核心互联网体系结构的一部分，但可能对智能电网感兴趣，这就是所谓的“可靠多播”的开发。这是“所谓的”，因为它不是严格意义上的“可靠的”——也许更适合描述为“增强的可靠性”。根据定义，一个尽力而为的网络可能会丢失流量、复制流量或重新排序流量，这对于多播和单播都是如此。研究
"Reliable Multicast" technology intends to improve the probability of delivery of multicast traffic.
“可靠多播”技术旨在提高多播流量的交付概率。
In that research, the IETF imposed guidelines [RFC2357] on the research community regarding what was desirable. Important results from that research include a number of papers and several proprietary protocols including some that have been used in support of business operations. RFCs in the area include The Use of Forward Error Correction (FEC) in Reliable Multicast [RFC3453], the Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) [RFC4410].
在这项研究中，IETF对研究界施加了关于什么是可取的准则[RFC2357]。这项研究的重要成果包括许多论文和一些专有协议，其中一些已用于支持业务运营。该领域的RFC包括在可靠多播[RFC3453]中使用前向纠错（FEC）、面向否定应答（NACK）的可靠多播（NORM）协议[RFC5740]和选择性可靠多播协议（SRMP）[RFC4410]。
IPv6 [RFC2460], with the Internet Control Message Protocol "v6" [RFC4443], constitutes the next generation protocol for the Internet. IPv6 provides for transmission of datagrams from source to destination hosts, which are identified by fixed-length addresses.
IPv6[RFC2460]与互联网控制消息协议“v6”[RFC4443]构成互联网的下一代协议。IPv6提供了从源主机到目标主机的数据报传输，目标主机由固定长度的地址标识。
IPv6 also provides for fragmentation and reassembly of long datagrams by the originating host, if necessary, for transmission through "small packet" networks. ICMPv6, which is a separate protocol implemented along with IPv6, enables the network to report errors and other issues to hosts that originate problematic datagrams.
IPv6还提供了源主机对长数据报的分段和重新组装（如有必要），以便通过“小数据包”网络进行传输。ICMPv6是与IPv6一起实施的独立协议，它使网络能够向产生问题数据报的主机报告错误和其他问题。
IPv6 adopted the Differentiated Services Architecture [RFC2474] [RFC2475], which contains a six-bit code point used to select an algorithm (a "per-hop behavior") to be applied to the datagram.
IPv6采用了区分服务体系结构[RFC2474][RFC2475]，其中包含一个六位代码点，用于选择要应用于数据报的算法（“每跳行为”）。
The IPv6 over Low-Power Wireless Personal Area Networks RFC [RFC4919] and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks document [6LOWPAN-HC] addresses IPv6 header compression and subnet architecture in at least some sensor networks, and may be appropriate to the Smart Grid Advanced Metering Infrastructure or other sensor domains.
低功耗无线个人区域网络上的IPv6 RFC[RFC4919]和6LoWPAN Networks文档[6LoWPAN-HC]中的IPv6数据报压缩格式解决了至少一些传感器网络中的IPv6报头压缩和子网架构问题，可能适用于智能电网高级计量基础设施或其他传感器领域。
An IPv6 Address [RFC4291] may be administratively assigned using DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are. In addition, IPv6 addresses may also be autoconfigured. Autoconfiguration enables various models of network management that may be advantageous in different use cases. Autoconfiguration procedures are defined in [RFC4862] and [RFC4941]. IPv6 neighbors identify each others' addresses using Neighbor Discovery (ND) [RFC4861]. SEcure Neighbor Discovery (SEND) [RFC3971] may be used to secure these operations.
IPv6地址[RFC4291]可以使用DHCPv6[RFC3315]以类似于IPv4地址的方式进行管理分配。此外，还可以自动配置IPv6地址。自动配置支持各种网络管理模型，这些模型在不同的用例中可能会有优势。[RFC4862]和[RFC4941]中定义了自动配置程序。IPv6邻居使用邻居发现（ND）[RFC4861]识别彼此的地址。安全邻居发现（SEND）[RFC3971]可用于保护这些操作。
Routing for the IPv6 Internet is accomplished by routing applications that exchange connectivity information and build semi-static destination routing databases. If a datagram is directed to a given destination address, the address is looked up in the routing database, and the most specific ("longest") prefix found that contains it is used to identify the next-hop router or the end system to which it will be delivered. Routing is not generally implemented on hosts (although it can be); generally, a host sends datagrams to a router on its local network, and the router carries out the intent.
IPv6 Internet的路由由交换连接信息和构建半静态目标路由数据库的路由应用程序完成。如果数据报指向给定的目标地址，则会在路由数据库中查找该地址，找到的包含该地址的最特定（“最长”）前缀将用于标识下一跳路由器或将其发送到的终端系统。路由通常不在主机上实现（尽管可以）；通常，主机向其本地网络上的路由器发送数据报，路由器执行该意图。
IETF-specified routing protocols include RIP for IPv6 [RFC2080], IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6 [RFC2545]. Active research exists in mobile ad hoc routing, routing in low-power networks (sensors and Smart Grids), and other routing paradigms; these result in new protocols and modified forwarding paradigms.
IETF指定的路由协议包括用于IPv6的RIP[RFC2080]、用于IPv6的IS-IS[RFC5308]、用于IPv6的OSPF[RFC5340]和用于IPv6的BGP-4[RFC2545]。在移动自组织路由、低功率网络（传感器和智能电网）中的路由以及其他路由范式中存在着活跃的研究；这些导致了新的协议和改进的转发模式。
The prototypical routing protocol used in the Internet has probably been the Routing Information Protocol [RFC1058]. People that use it today tend to deploy RIPng for IPv6 [RFC2080] and RIP Version 2 [RFC2453]. Briefly, RIP is a distance vector routing protocol that is based on a distributed variant of the widely known Bellman-Ford algorithm. In distance vector routing protocols, each router announces the contents of its route table to neighboring routers, which integrate the results with their route tables and re-announce them to others. It has been characterized as "routing by rumor", and suffers many of the ills we find in human gossip -- propagating stale or incorrect information in certain failure scenarios, and being in cases unresponsive to changes in topology. [RFC1058] provides guidance to algorithm designers to mitigate these issues.
互联网中使用的典型路由协议可能是路由信息协议[RFC1058]。今天使用它的人倾向于为IPv6部署RIPng[RFC2080]和RIP版本2[RFC2453]。简单地说，RIP是一种距离向量路由协议，它基于广为人知的Bellman-Ford算法的分布式变体。在距离向量路由协议中，每个路由器向相邻路由器宣布其路由表的内容，相邻路由器将结果与其路由表集成，并向其他路由器重新宣布。它被描述为“通过谣言路由”，并遭受我们在人类八卦中发现的许多弊病——在某些故障场景中传播陈旧或不正确的信息，在某些情况下对拓扑结构的更改没有响应。[RFC1058]为算法设计者提供了缓解这些问题的指导。
The Open Shortest Path First (OSPF) routing protocol is one of the more widely used protocols in the Internet. OSPF is based on Dijkstra's well known Shortest Path First (SPF) algorithm. It is implemented as OSPF Version 2 [RFC2328] for IPv4, OSPF for IPv6 [RFC5340] for IPv6, and the Support of Address Families in OSPFv3 [RFC5838] to enable [RFC5340] routing both IPv4 and IPv6.
开放最短路径优先（OSPF）路由协议是互联网上应用最广泛的协议之一。OSPF基于Dijkstra著名的最短路径优先（SPF）算法。它实现为用于IPv4的OSPF版本2[RFC2328]，用于IPv6的OSPF[RFC5340]，以及用于IPv6的OSPFv3[RFC5838]中的地址族支持，以支持[RFC5340]对IPv4和IPv6进行路由。
The advantage of any SPF-based protocol (i.e., OSPF and IS-IS) is primarily that every router in the network constructs its view of the
任何基于SPF的协议（即OSPF和IS-IS）的优点主要在于，网络中的每个路由器都构建其对网络的视图
network from first-hand knowledge rather than the "gossip" that distance vector protocols propagate. As such, the topology is quickly and easily changed by simply announcing the change. The disadvantage of SPF-based protocols is that each router must store a first-person statement of the connectivity of each router in the domain.
网络来自第一手知识，而不是距离向量协议传播的“流言蜚语”。因此，只需宣布更改，即可快速轻松地更改拓扑。基于SPF的协议的缺点是，每个路由器必须存储域中每个路由器连接的第一人称语句。
The Intermediate System to Intermediate System (IS-IS) routing protocol is one of the more widely used protocols in the Internet. IS-IS is also based on Dijkstra's SPF algorithm. It was originally specified as ISO DP 10589 for the routing of Connectionless Network Service (CLNS), and extended for routing in TCP/IP and dual environments [RFC1195], and more recently for routing of IPv6 [RFC5308].
中间系统到中间系统（IS-IS）路由协议是Internet上应用较为广泛的协议之一。IS-IS也基于Dijkstra的SPF算法。它最初被指定为ISO DP 10589，用于无连接网络服务（CLNS）的路由，并扩展用于TCP/IP和双环境中的路由[RFC1195]，最近用于IPv6的路由[RFC5308]。
As with OSPF, the positives of any SPF-based protocol and specifically IS-IS are primarily that the network is described as a lattice of routers with connectivity to subnets and isolated hosts. It's topology is quickly and easily changed by simply announcing the change, without the issues of "routing by rumor", since every host within the routing domain has a first-person statement of the connectivity of each router in the domain. The negatives are a corollary: each router must store a first-person statement of the connectivity of each router in the domain.
与OSPF一样，任何基于SPF的协议，特别是IS-IS协议的优点主要在于，该网络被描述为一个路由器晶格，与子网和隔离主机相连。它的拓扑结构可以通过简单地宣布更改而快速轻松地更改，而不存在“通过谣言路由”的问题，因为路由域中的每台主机都有一个关于域中每个路由器连接的第一人称声明。否定的是一个推论：每个路由器必须存储域中每个路由器连接的第一人称语句。
The Border Gateway Protocol (BGP) [RFC4271] is widely used in the IPv4 Internet to exchange routes between administrative entities -- service providers, their peers, their upstream networks, and their customers -- while applying specific policy. Multiprotocol Extensions [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain Routing [RFC2545], multicast reachability information, and VPN information, among others.
边界网关协议（BGP）[RFC4271]在IPv4互联网中被广泛使用，用于在管理实体（服务提供商、其对等方、其上游网络和其客户）之间交换路由，同时应用特定的策略。BGP的多协议扩展[RFC4760]允许BGP携带IPv6域间路由[RFC2545]、多播可达性信息和VPN信息等。
Considerations that apply with BGP deal with the flexibility and complexity of the policies that must be defined. Flexibility is a good thing; in a network that is not run by professionals, the complexity is burdensome.
应用于BGP的注意事项涉及必须定义的策略的灵活性和复杂性。灵活性是一件好事；在一个不是由专业人士运行的网络中，复杂性是很沉重的。
The Mobile Ad Hoc working group of the IETF developed, among other protocols, Ad hoc On-Demand Distance Vector (AODV) Routing [RFC3561]. This protocol captured the minds of some in the embedded devices industry, but experienced issues in wireless networks such as
IETF的移动特设工作组在其他协议中开发了特设按需距离向量（AODV）路由[RFC3561]。该协议吸引了嵌入式设备行业一些人的注意力，但在无线网络中遇到了一些问题，如
802.15.4 and 802.11's Ad Hoc mode. As a result, it is in the process of being updated in the Dynamic MANET On-demand (DYMO) Routing protocol [DYMO].
802.15.4和802.11的自组织模式。因此，动态MANET随需应变（DYMO）路由协议[DYMO]正在对其进行更新。
AODV and DYMO are essentially reactive routing protocols designed for mobile ad hoc networks, and usable in other forms of ad hoc networks. They provide connectivity between a device within a distributed subnet and a few devices (including perhaps a gateway or router to another subnet) without tracking connectivity to other devices. In essence, routing is calculated and discovered upon need, and a host or router need only maintain the routes that currently work and are needed.
AODV和DYMO本质上是为移动自组织网络设计的反应式路由协议，可用于其他形式的自组织网络。它们提供分布式子网中的一个设备和少数设备（可能包括到另一个子网的网关或路由器）之间的连接，而不跟踪到其他设备的连接。本质上，路由是根据需要计算和发现的，主机或路由器只需要维护当前工作和需要的路由。
The Optimized Link State Routing Protocol (OLSR) [RFC3626] is a proactive routing protocol designed for mobile ad hoc networks, and can be used in other forms of ad hoc networks. It provides arbitrary connectivity between systems within a distributed subnet. As with protocols designed for wired networks, routing is calculated whenever changes are detected, and maintained in each router's tables. The set of nodes that operate as routers within the subnet, however, are fairly fluid, and dependent on this instantaneous topology of the subnet.
优化链路状态路由协议（OLSR）[RFC3626]是为移动自组织网络设计的主动式路由协议，可用于其他形式的自组织网络。它在分布式子网内的系统之间提供任意连接。与为有线网络设计的协议一样，只要检测到更改，就会计算路由，并在每个路由器的表中维护路由。然而，在子网内作为路由器运行的节点集是相当流动的，并且依赖于子网的这种瞬时拓扑结构。
The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [RPL] is a reactive routing protocol designed for use in resource constrained networks. Requirements for resource constrained networks are defined in [RFC5548], [RFC5673], [RFC5826], and [RFC5867].
用于低功耗和有损网络的IPv6路由协议（RPL）[RPL]是一种设计用于资源受限网络的反应式路由协议。[RFC5548]、[RFC5673]、[RFC5826]和[RFC5867]中定义了资源受限网络的要求。
Briefly, a constrained network is comprised of nodes that:
简而言之，受约束网络由以下节点组成：
o Are built with limited processing power and memory, and sometimes energy when operating on batteries.
o 它们的处理能力和内存都很有限，有时在使用电池时也会消耗能量。
o Are interconnected through a low-data-rate network interface and are potentially vulnerable to communication instability and low packet delivery rates.
o 通过低数据速率网络接口互连，可能容易受到通信不稳定和低数据包传输速率的影响。
o Potentially have a mix of roles such as being able to act as a host (i.e., generating traffic) and/or a router (i.e., both forwarding and generating RPL traffic).
o 可能具有混合角色，例如能够充当主机（即生成流量）和/或路由器（即转发和生成RPL流量）。
IPv6 specifies both unicast and multicast datagram exchange. This uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] [RFC3590] [RFC3810] [RFC4604] to enable applications to join multicast groups, and for most applications uses Source-Specific Multicast [RFC4607] for routing and delivery of multicast messages.
IPv6指定单播和多播数据报交换。这使用多播侦听器发现协议（MLDv2）[RFC2710][RFC3590][RFC3810][RFC4604]来允许应用程序加入多播组，并且对于大多数应用程序，使用源特定多播[RFC4607]来路由和传递多播消息。
The mechanisms experimentally developed for reliable multicast in IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.
第3.2.2.3节中讨论的IPv4中为可靠多播实验开发的机制也可用于IPv6。
A multicast routing protocol has two basic functions: building the multicast distribution tree and forwarding multicast traffic. Multicast routing protocols generally contain a control plane for building distribution trees, and a forwarding plane that uses the distribution tree when forwarding multicast traffic.
组播路由协议有两个基本功能：建立组播分布树和转发组播流量。多播路由协议通常包含用于构建分发树的控制平面，以及在转发多播流量时使用分发树的转发平面。
The multicast model works as follows: hosts express their interest in receiving multicast traffic from a source by sending a Join message to their first-hop router. That router in turn sends a Join message upstream towards the root of the tree, grafting the router (leaf node) onto the distribution tree for the group. Data is delivered down the tree toward the leaf nodes, which forward it onto the local network for delivery.
多播模型的工作原理如下：主机通过向其第一跳路由器发送加入消息来表示对从源接收多播流量的兴趣。该路由器依次向树的根向上游发送连接消息，将路由器（叶节点）嫁接到组的分发树上。数据沿着树向下传递到叶节点，叶节点将数据转发到本地网络进行传递。
The initial multicast model deployed in the Internet was known as Any-Source Multicast (ASM). In the ASM model, any host could send to the group and inter-domain multicast was difficult. Protocols such as Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) [RFC3973] and Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601] were designed for the ASM model.
最初部署在Internet上的多播模型称为任意源多播（ASM）。在ASM模型中，任何主机都可以发送到组，域间多播是困难的。为ASM模型设计了协议独立多播密集模式（PIM-DM）：协议规范（修订版）[RFC3973]和协议独立多播稀疏模式（PIM-SM）：协议规范（修订版）[RFC4601]等协议。
Many modern multicast deployments use Source-Specific Multicast (PIM-SSM) [RFC3569][RFC4608]. In the SSM model, a host expresses interest in a "channel", which is comprised of a source (S) and a group (G). Distribution trees are rooted to the sending host (called an "(S,G) tree"). Since only the source S can send on to the group, SSM has inherent anti-jamming capability. In addition, inter-domain multicast is simplified since finding the (S,G) channel they are interested in receiving is the responsibility of the receivers (rather than the networks). This implies that SSM requires some form of directory service so that receivers can find the (S,G) channels.
许多现代多播部署使用源特定多播（PIM-SSM）[RFC3569][RFC4608]。在SSM模型中，主机表示对“通道”感兴趣，该通道由一个源（S）和一个组（G）组成。分发树以发送主机为根（称为“（S，G）树”）。由于只有源S可以发送到组，SSM具有固有的抗干扰能力。此外，域间多播被简化，因为寻找他们感兴趣的（S，G）信道是接收者（而不是网络）的责任。这意味着SSM需要某种形式的目录服务，以便接收方可以找到（S，G）通道。
In general, the layered architecture of the Internet enables the IPS to run over any appropriate layer two architecture. The ability to change the link or physical layer without having to rethink the network layer, transports, or applications has been a great benefit in the Internet.
一般来说，互联网的分层架构使IP能够在任何适当的第二层架构上运行。更改链路或物理层而不必重新考虑网络层、传输或应用程序的能力是互联网的一大优势。
Examples of link layer adaptation technology include:
链路层适配技术的示例包括：
Ethernet/IEEE 802.3: IPv4 has run on each link layer environment that uses the Ethernet header (which is to say 10 and 100 MBPS wired Ethernet, 1 and 10 GBPS wired Ethernet, and the various versions of IEEE 802.11) using [RFC0894]. IPv6 does the same using [RFC2464].
Ethernet/IEEE 802.3:IPv4在使用以太网报头（即10和100 MBPS有线以太网、1和10 GBPS有线以太网以及各种版本的IEEE 802.11）的每个链路层环境上运行，使用[RFC0894]。IPv6也使用[RFC2464]实现同样的功能。
PPP: The IETF has defined a serial line protocol, the Point-to-Point Protocol (PPP) [RFC1661], that uses High-Level Data Link Control (bit-synchronous or byte synchronous) framing. The IPv4 adaptation specification is [RFC1332], and the IPv6 adaptation specification is [RFC5072]. Current use of this protocol is in traditional serial lines, authentication exchanges in DSL networks using PPP Over Ethernet (PPPoE) [RFC2516], and the Digital Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH) using PPP over SONET/SDH [RFC2615].
PPP:IETF定义了一种串行线协议，即点对点协议（PPP）[RFC1661]，它使用高级数据链路控制（位同步或字节同步）帧。IPv4适配规范为[RFC1332]，IPv6适配规范为[RFC5072]。该协议目前用于传统串行线路、使用以太网PPP（PPPoE）[RFC2516]的DSL网络中的身份验证交换，以及使用SONET/SDH上的PPP的数字信令层次结构（通常称为SONET/SDH上的数据包）[RFC2615]。
IEEE 802.15.4: The adaptation specification for IPv6 transmission over IEEE 802.15.4 Networks is [RFC4944].
IEEE 802.15.4:IEEE 802.15.4网络上IPv6传输的适配规范为[RFC4944]。
Numerous other adaptation specifications exist, including ATM, Frame Relay, X.25, other standardized and proprietary LAN technologies, and others.
存在许多其他适配规范，包括ATM、帧中继、X.25、其他标准化和专有LAN技术等。
This section outlines the functionality of UDP, TCP, SCTP, and DCCP. UDP and TCP are best known and most widely used in the Internet today, while SCTP and DCCP are newer protocols that were built for specific purposes. Other transport protocols can be built when required.
本节概述UDP、TCP、SCTP和DCCP的功能。UDP和TCP是当今互联网上最为人所知和使用最为广泛的协议，而SCTP和DCCP则是为特定目的而构建的较新协议。需要时，可以构建其他传输协议。
The User Datagram Protocol [RFC0768] and the Lightweight User Datagram Protocol [RFC3828] are properly not "transport" protocols in the sense of "a set of rules governing the exchange or transmission of data electronically between devices". They are labels that
用户数据报协议[RFC0768]和轻量级用户数据报协议[RFC3828]在“管理设备之间电子数据交换或传输的一组规则”的意义上不是“传输”协议。它们是
provide for multiplexing of applications directly on the IP layer, with transport functionality embedded in the application.
提供直接在IP层上复用应用程序，并在应用程序中嵌入传输功能。
Many exchange designs have been built using UDP, and many of them have not worked out. As a result, the use of UDP really should be treated as designing a new transport. Advice on the use of UDP in new applications can be found in Unicast UDP Usage Guidelines for Application Designers [RFC5405].
许多exchange设计都是使用UDP构建的，其中许多还没有实现。因此，使用UDP确实应该被视为设计一种新的传输。有关在新应用程序中使用UDP的建议，请参见应用程序设计者的单播UDP使用指南[RFC5405]。
Datagram Transport Layer Security [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery for applications that run over UDP. Alternatively, UDP can run over IPsec.
数据报传输层安全[RFC5238]可用于防止在UDP上运行的应用程序的窃听、篡改或消息伪造。或者，UDP可以在IPsec上运行。
TCP [RFC0793] is the predominant transport protocol used in the Internet. It is "reliable", as the term is used in protocol design: it delivers data to its peer and provides acknowledgement to the sender, or it dies trying. It has extensions for Congestion Control [RFC5681] and Explicit Congestion Notification [RFC3168].
TCP[RFC0793]是互联网上使用的主要传输协议。它是“可靠的”，正如协议设计中所使用的术语：它将数据传递给对等方，并向发送方提供确认，否则它将失败。它具有拥塞控制扩展[RFC5681]和显式拥塞通知扩展[RFC3168]。
The user interface for TCP is a byte stream interface -- an application using TCP might "write" to it several times only to have the data compacted into a common segment and delivered as such to its peer. For message-stream interfaces, ACSE/ROSE uses the ISO Transport Service on TCP [RFC1006][RFC2126] in the application.
TCP的用户界面是一个字节流接口——使用TCP的应用程序可能会多次“写入”到它，结果数据被压缩到一个公共段中，并以此方式传递给它的对等方。对于消息流接口，ACSE/ROSE在应用程序的TCP[RFC1006][RFC2126]上使用ISO传输服务。
Transport Layer Security [RFC5246] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, TCP can run over IPsec. Additionally, [RFC4987] discusses mechanisms similar to SCTP's and DCCP's "cookie" approach that may be used to secure TCP sessions against flooding attacks.
传输层安全[RFC5246]可用于防止窃听、篡改或消息伪造。或者，TCP可以在IPsec上运行。此外，[RFC4987]还讨论了类似于SCTP和DCCP的“cookie”方法的机制，这些机制可用于保护TCP会话免受洪水攻击。
Finally, note that TCP has been the subject of ongoing research and development since it was written. The Roadmap for TCP Specification Documents [RFC4614] captures this history, and is intended to be a guide to current and future developers in the area.
最后，请注意，TCP自编写以来一直是不断研究和开发的主题。TCP规范文档的路线图[RFC4614]记录了这一历史，旨在为该领域当前和未来的开发人员提供指南。
SCTP [RFC4960] is a more recent reliable transport protocol that can be imagined as a TCP-like context containing multiple separate and independent message streams (unlike TCP's byte streams). The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. As it uses a message stream interface, it may also be more appropriate for the ISO Transport Service than using RFC 1006/2126 to turn TCP's octet streams into a message interface.
SCTP[RFC4960]是一种较新的可靠传输协议，可以想象为一种类似TCP的上下文，包含多个独立的消息流（与TCP的字节流不同）。SCTP的设计包括适当的拥塞避免行为以及对洪水和伪装攻击的抵抗。由于它使用消息流接口，因此与使用RFC 1006/2126将TCP的八位字节流转换为消息接口相比，它可能更适合ISO传输服务。
SCTP offers several delivery options. The basic service is sequential non-duplicated delivery of messages within a stream, for each stream in use. Since streams are independent, one stream may pause due to head-of-line blocking while another stream in the same session continues to deliver data. In addition, SCTP provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received.
SCTP提供了几种交付选项。基本服务是针对每个正在使用的流，在流中按顺序不重复地传递消息。由于流是独立的，一个流可能由于行首阻塞而暂停，而同一会话中的另一个流继续传送数据。此外，SCTP还提供了一种绕过顺序传递服务的机制。使用此机制发送的用户消息在收到后立即传递给SCTP用户。
SCTP implements a simple "cookie" mechanism intended to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer. Mechanisms also exist for Dynamic Address Reconfiguration [RFC5061], enabling peers to change addresses during the session and yet retain connectivity. Transport Layer Security [RFC3436] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, SCTP can run over IPsec.
SCTP实现了一种简单的“cookie”机制，旨在通过相互身份验证限制洪水攻击的有效性。这表明应用程序连接到同一个对等方，但不标识该对等方。还存在用于动态地址重新配置的机制[RFC5061]，使对等方能够在会话期间更改地址，同时保持连接。传输层安全[RFC3436]可用于防止窃听、篡改或消息伪造。或者，SCTP可以在IPsec上运行。
DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that does not guarantee message delivery) that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.
DCCP[RFC4340]是一种“不可靠”传输协议（例如，不保证消息传递的协议），它提供拥塞控制的不可靠数据报的双向单播连接。DCCP适用于传输大量数据的应用程序，并且可以从控制及时性和可靠性之间的权衡中获益。
DCCP implements a simple "cookie" mechanism intended to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer. Datagram Transport Layer Security [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, DCCP can run over IPsec.
DCCP实现了一种简单的“cookie”机制，旨在通过相互身份验证限制泛洪攻击的有效性。这表明应用程序连接到同一个对等方，但不标识该对等方。数据报传输层安全[RFC5238]可用于防止窃听、篡改或消息伪造。或者，DCCP可以在IPsec上运行。
In order to facilitate network management and operations, the Internet community has defined the Domain Name System (DNS) [RFC1034] [RFC1035]. Names are hierarchical: a name like example.com is found registered with a .com registrar, and within the associated network other names like baldur.cincinatti.example.com can be defined, with obvious hierarchy. Security extensions, which allow a registry to sign the records it contains and in so doing demonstrate their authenticity, are defined by the DNS Security Extensions [RFC4033] [RFC4034] [RFC4035].
为了便于网络管理和操作，互联网社区定义了域名系统（DNS）[RFC1034][RFC1035]。名称是分层的：example.com这样的名称在.com注册商处注册，在相关网络中，可以定义其他名称，如baldur.cincinatti.example.com，具有明显的层次结构。DNS安全扩展[RFC4033][RFC4034][RFC4035]定义了安全扩展，它允许注册中心对其包含的记录进行签名，并以此证明其真实性。
Devices can also optionally update their own DNS record. For example, a sensor that is using Stateless Address Autoconfiguration [RFC4862] to create an address might want to associate it with a name using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update [RFC3007].
设备还可以选择更新自己的DNS记录。例如，使用无状态地址自动配置[RFC4862]创建地址的传感器可能希望使用DNS动态更新[RFC2136]或DNS安全动态更新[RFC3007]将其与名称关联。
As discussed in Section 3.2.2, IPv4 address assignment is generally performed using DHCP [RFC2131]. By contrast, Section 3.2.3 points out that IPv6 address assignment can be accomplished using either autoconfiguration [RFC4862] [RFC4941] or DHCPv6 [RFC3315]. The best argument for the use of autoconfiguration is a large number of systems that require little more than a random number as an address; the argument for DHCP is administrative control.
如第3.2.2节所述，IPv4地址分配通常使用DHCP[RFC2131]执行。相比之下，第3.2.3节指出，IPv6地址分配可以使用自动配置[RFC4862][RFC4941]或DHCPv6[RFC3315]来完成。使用自动配置的最佳论据是大量系统只需要一个随机数作为地址；DHCP的理由是管理控制。
There are other parameters that may need to be allocated to hosts requiring administrative configuration; examples include the addresses of DNS servers, keys for Secure DNS, and Network Time servers.
可能需要为需要管理配置的主机分配其他参数；示例包括DNS服务器的地址、安全DNS的密钥和网络时间服务器。
The Network Time Protocol was originally designed by Dave Mills of the University of Delaware and CSNET, implementing a temporal metric in the Fuzzball Routing Protocol and generally coordinating time experiments. The current versions of the time protocol are the Network Time Protocol [RFC5905].
网络时间协议最初是由德拉瓦大学的Dave Mills和CSNET设计的，在FuffBar路由协议中实现时间度量，并且通常协调时间实验。时间协议的当前版本为网络时间协议[RFC5905]。
The IETF has developed two protocols for network management: SNMP and NETCONF. SNMP is discussed in Section 3.5.1, and NETCONF is discussed in Section 3.5.2.
IETF开发了两种网络管理协议：SNMP和NETCONF。SNMP在第3.5.1节中讨论，NETCONF在第3.5.2节中讨论。
The Simple Network Management Protocol, originally specified in the late 1980's and having passed through several revisions, is specified in several documents:
简单网络管理协议最初是在20世纪80年代末规定的，经过多次修订，在一些文件中有规定：
o An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks [RFC3411]
o 描述简单网络管理协议（SNMP）管理框架的体系结构[RFC3411]
o Message Processing and Dispatching [RFC3412]
o 消息处理和调度[RFC3412]
o SNMP Applications [RFC3413]
o SNMP应用程序[RFC3413]
o User-based Security Model (USM) for SNMP version 3 [RFC3414]
o SNMP版本3[RFC3414]的基于用户的安全模型（USM）
o View-based Access Control Model (VACM) [RFC3415]
o 基于视图的访问控制模型（VACM）[RFC3415]
o Version 2 of the SNMP Protocol Operations [RFC3416]
o SNMP协议操作的第2版[RFC3416]
o Transport Mappings [RFC3417]
o 传输映射[RFC3417]
o Management Information Base (MIB) [RFC3418]
o 管理信息库（MIB）[RFC3418]
It provides capabilities for polled and event-driven activities, and for both monitoring and configuration of systems in the field. Historically, it has been used primarily for monitoring nodes in a network. Messages and their constituent data are encoded using a profile of ASN.1.
它为轮询和事件驱动活动以及现场系统的监控和配置提供了功能。历史上，它主要用于监视网络中的节点。消息及其组成数据使用ASN.1的概要文件进行编码。
The NETCONF Configuration Protocol is specified in one basic document, with supporting documents for carrying it over the IPS. These documents include:
NETCONF配置协议在一个基本文档中指定，并附有通过IPS传输该协议的支持文档。这些文件包括：
o NETCONF Configuration Protocol [RFC4741]
o NETCONF配置协议[RFC4741]
o Using the NETCONF Configuration Protocol over Secure SHell (SSH) [RFC4742]
o 通过安全SHell（SSH）使用NETCONF配置协议[RFC4742]
o Using NETCONF over the Simple Object Access Protocol (SOAP) [RFC4743]
o 通过简单对象访问协议（SOAP）使用NETCONF[RFC4743]
o Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) [RFC4744]
o 在块可扩展交换协议（BEEP）上使用NETCONF协议[RFC4744]
o NETCONF Event Notifications [RFC5277]
o NETCONF事件通知[RFC5277]
o NETCONF over Transport Layer Security (TLS) [RFC5539]
o 传输层安全性（TLS）上的网络配置[RFC5539]
o Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717]
o NETCONF[RFC5717]的部分锁定远程过程调用（RPC）
NETCONF was developed in response to operator requests for a common configuration protocol based on ASCII text, unlike ASN.1. In essence, it carries XML-encoded remote procedure call (RPC) data. In response to Smart Grid requirements, there is consideration of a variant of the protocol that could be used for polled and event-driven management activities, and for both monitoring and configuration of systems in the field.
与ASN.1不同，NETCONF是为了响应操作员对基于ASCII文本的通用配置协议的请求而开发的。本质上，它携带XML编码的远程过程调用（RPC）数据。为了响应智能电网的要求，考虑了一种协议变体，该变体可用于轮询和事件驱动的管理活动，以及现场系统的监控和配置。
Service and resource discovery are among the most important protocols for constrained resource self-organizing networks. These include various sensor networks as well as the Home Area Networks (HANs), Building Area Networks (BANs), and Field Area Networks (FANs) envisioned by Smart Grid architects.
服务和资源发现是受限资源自组织网络中最重要的协议之一。其中包括各种传感器网络以及智能电网设计师设想的家庭区域网络（HANs）、建筑区域网络（BAN）和现场区域网络（FANs）。
Service discovery protocols are designed for the automatic configuration and detection of devices, and the services offered by the discovered devices. In many cases service discovery is performed by so-called "constrained resource" devices (i.e., those with limited processing power, memory, and power resources).
服务发现协议是为自动配置和检测设备以及所发现设备提供的服务而设计的。在许多情况下，服务发现由所谓的“受限资源”设备（即处理能力、内存和电源资源有限的设备）执行。
In general, service discovery is concerned with the resolution and distribution of host names via multicast DNS [MULTICAST-DNS] and the automatic location of network services via DHCP (Section 3.4.2), the DNS Service Discovery (DNS-SD) [DNS-SD] (part of Apple's Bonjour technology), and the Service Location Protocol (SLP) [RFC2608].
一般来说，服务发现涉及通过多播DNS[multicast-DNS]解析和分发主机名，以及通过DHCP（第3.4.2节）、DNS服务发现（DNS-SD）[DNS-SD]（苹果Bonjour技术的一部分）和服务定位协议（SLP）[RFC2608]自动定位网络服务。
Resource Discovery is concerned with the discovery of resources offered by end-points and is extremely important in machine-to-machine closed-loop applications (i.e., those with no humans in the loop). The goals of resource discovery protocols include:
资源发现与端点提供的资源的发现有关，在机器到机器的闭环应用程序（即循环中没有人的应用程序）中非常重要。资源发现协议的目标包括：
o Simplicity of creation and maintenance of resources
o 创建和维护资源的简单性
o Commonly understood semantics
o 通俗语义
o Conformance to existing and emerging standards
o 符合现有和新兴标准
o International scope and applicability
o 国际范围和适用性
o Extensibility
o 扩展性
o Interoperability among collections and indexing systems
o 馆藏和索引系统之间的互操作性
The Constrained Application Protocol (CoAP) [COAP] is being developed in IETF with these goals in mind. In particular, CoAP is designed for use in constrained resource networks and for machine-to-machine applications such as smart energy and building automation. It provides a RESTful transfer protocol [RESTFUL], a built-in resource discovery protocol, and includes web concepts such as URIs and content-types. CoAP provides both unicast and multicast resource
IETF正在考虑这些目标，开发受限应用协议（CoAP）[CoAP]。特别是，CoAP设计用于受限资源网络和机器对机器应用，如智能能源和楼宇自动化。它提供了一个RESTful传输协议[RESTful]，一个内置的资源发现协议，并包括URI和内容类型等web概念。CoAP同时提供单播和多播资源
discovery and includes the ability to filter on attributes of resource descriptions. Finally, CoAP resource discovery can also be used to discover HTTP resources.
发现并包括根据资源描述的属性进行筛选的能力。最后，CoAP资源发现还可用于发现HTTP资源。
For simplicity, CoAP makes the assumption that all CoAP servers listen on the default CoAP port or otherwise have been configured or discovered using some general service discovery mechanism such as DNS Service Discovery (DNS-SD) [DNS-SD].
为简单起见，CoAP假设所有CoAP服务器都在默认CoAP端口上侦听，或者已经使用一些通用服务发现机制（如DNS服务发现（DNS-SD）[DNS-SD]）进行了配置或发现。
Resource discovery in CoAP is accomplished through the use of well-known resources that describe the links offered by a CoAP server. CoAP defines a well-known URI for discovery: "/.well-known/r" [RFC5785]. For example, the query [GET /.well-known/r] returns a list of links (representing resources) available from the queried CoAP server. A query such as [GET /.well-known/r?n=Voltage] returns the resources with the name Voltage.
CoAP中的资源发现是通过使用描述CoAP服务器提供的链接的知名资源来完成的。CoAP为发现定义了一个众所周知的URI:“/.well-known/r”[RFC5785]。例如，查询[GET/.well-known/r]返回可从查询的CoAP服务器获得的链接列表（表示资源）。像[GET/.well-known/r？n=Voltage]这样的查询返回名为Voltage的资源。
There are many applications that rely on the IP infrastructure, but are not properly thought of as part of the IP infrastructure itself. These applications may be useful in the context of the Smart Grid. The choices made when constructing a profile of the Internet Profile Suite may impact how such applications could be used. Some of them, not by any means an exhaustive list, are discussed here.
有许多应用程序依赖于IP基础设施，但没有被正确地视为IP基础设施本身的一部分。这些应用程序在智能电网环境中可能很有用。构建Internet配置文件套件配置文件时所做的选择可能会影响此类应用程序的使用方式。这里讨论的是其中的一些问题，并非详尽无遗的清单。
The Session Initiation Protocol [RFC3261] [RFC3265] [RFC3853] [RFC4320] [RFC4916] [RFC5393] [RFC5621] is an application layer control (signaling) protocol for creating, modifying, and terminating multimedia sessions on the Internet, and is meant to be more scalable than H.323. Multimedia sessions can be voice, video, instant messaging, shared data, and/or subscriptions of events. SIP can run on top of TCP, UDP, SCTP, or TLS over TCP. SIP is independent of the transport layer, and independent of the underlying IPv4/v6 version. In fact, the transport protocol used can change as the SIP message traverses SIP entities from source to destination.
会话启动协议[RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621]是一种应用层控制（信令）协议，用于在Internet上创建、修改和终止多媒体会话，其可扩展性比H.323更高。多媒体会话可以是语音、视频、即时消息、共享数据和/或事件订阅。SIP可以在TCP、UDP、SCTP或TCP上的TLS之上运行。SIP独立于传输层，并且独立于底层IPv4/v6版本。事实上，当SIP消息从源到目标遍历SIP实体时，所使用的传输协议可能会发生变化。
SIP itself does not choose whether a session is voice or video, nor does it identify the actual endpoints' IP addresses. The Session Description Protocol (SDP) [RFC4566] is intended for those purposes. Within the SDP, which is transported by SIP, codecs are offered and accepted (or not), and the port number and IP address at which each endpoint wants to receive their Real-time Transport Protocol (RTP) [RFC3550] packets are determined. The introduction of Network Address Translation (NAT) technology into the profile, whether IPv4/
SIP本身不选择会话是语音还是视频，也不确定实际端点的IP地址。会话描述协议（SDP）[RFC4566]用于这些目的。在由SIP传输的SDP中，提供并接受（或不接受）编解码器，并确定每个端点想要接收其实时传输协议（RTP）[RFC3550]数据包的端口号和IP地址。在配置文件中引入网络地址转换（NAT）技术，无论是IPv4/
IPv4, IPv4/IPv6 as described in Section 3.2.1.3, or IPv6/IPv6, increases the complexity of SIP/SDP deployment. This is further discussed in [RFC2993] and [RFC5626].
第3.2.1.3节中描述的IPv4、IPv4/IPv6或IPv6/IPv6增加了SIP/SDP部署的复杂性。[RFC2993]和[RFC5626]对此进行了进一步讨论。
The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. Since XMPP provides a generalized, extensible framework for exchanging XML data, it has been proposed as an application structure for interchange between embedded devices and sensors. It is currently used for Instant Messaging and Presence [RFC6121] and a wide variety of real-time communication modes. These include multi-user chat, publish-subscribe, alerts and notifications, service discovery, multimedia session management, device configuration, and remote procedure calls. XMPP supports channel encryption using TLS [RFC5246] and strong authentication (including PKIX certificate authentication) using SASL [RFC4422]. It also makes use of Unicode-compliant addresses and UTF-8 [RFC3629] data exchange for internationalization.
可扩展消息和状态协议（XMPP）[RFC6120]是一种流式传输可扩展标记语言（XML）元素的协议，以便在任意两个网络端点之间近实时地交换结构化信息。由于XMPP提供了一个通用的、可扩展的XML数据交换框架，因此它被提议作为嵌入式设备和传感器之间交换的应用程序结构。它目前用于即时消息和状态[RFC6121]以及各种实时通信模式。其中包括多用户聊天、发布订阅、警报和通知、服务发现、多媒体会话管理、设备配置和远程过程调用。XMPP支持使用TLS[RFC5246]的通道加密和使用SASL[RFC4422]的强身份验证（包括PKIX证书身份验证）。它还利用Unicode兼容地址和UTF-8[RFC3629]数据交换实现国际化。
XMPP allows for End-to-End Signing and Object Encryption [RFC3923], access to objects named using Uniform Resource Names (URN) [RFC4854], use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) [RFC5122], and the presentation of Notifications [RFC5437].
XMPP允许端到端签名和对象加密[RFC3923]，访问使用统一资源名（URN）[RFC4854]命名的对象，使用国际化资源标识符（IRI）和统一资源标识符（URI）[RFC5122]，以及显示通知[RFC5437]。
Internet calendaring, as implemented in Apple iCal, Microsoft Outlook and Entourage, and Google Calendar, is specified in Internet Calendaring and Scheduling Core Object Specification (iCalendar) [RFC5545] and is in the process of being updated to an XML schema in iCalendar XML Representation [xCAL]. Several protocols exist to carry calendar events, including the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the iCalendar Message-Based Interoperability Protocol (iMIP) [RFC6047], and open source work on the Atom Publishing Protocol [RFC5023].
在Apple iCal、Microsoft Outlook and Entourage和Google Calendar中实现的Internet日历在Internet日历和调度核心对象规范（iCalendar）[RFC5545]中指定，并且正在更新为iCalendar XML表示[xCAL]中的XML模式。有几种协议可以承载日历事件，包括iCalendar传输独立互操作性协议（iTIP）[RFC5546]、iCalendar基于消息的互操作性协议（iMIP）[RFC6047]和Atom发布协议的开源工作[RFC5023]。
The Internet is a network of networks in which networks are interconnected in specific ways and are independently operated. It is important to note that the underlying Internet architecture puts no restrictions on the ways that networks are interconnected; interconnection is a business decision. As such, the Internet
互联网是一个由网络组成的网络，其中网络以特定的方式相互连接并独立运行。需要注意的是，底层互联网架构对网络互联方式没有任何限制；互联是一项商业决策。因此，互联网
interconnection architecture can be thought of as a "business structure" for the Internet.
互连架构可以被认为是互联网的“业务结构”。
Central to the Internet business structure are the networks that provide connectivity to other networks, called "transit networks". These networks sell bulk bandwidth and routing services to each other and to other networks as customers. Around the periphery of the transit network are companies, schools, and other networks that provide services directly to individuals. These might generally be divided into "enterprise networks" and "access networks"; enterprise networks provide "free" connectivity to their own employees or members, and also provide them a set of services including electronic mail, web services, and so on. Access networks sell broadband connectivity (DSL, Cable Modem, 802.11 wireless, or 3GPP wireless) or "dial" services (including PSTN dial-up and ISDN) to subscribers. The subscribers are typically either residential or small office/home office (SOHO) customers. Residential customers are generally entirely dependent on their access provider for all services, while a SOHO buys some services from the access provider and may provide others for itself. Networks that sell transit services to nobody else -- SOHO, residential, and enterprise networks -- are generally refereed to as "edge networks"; transit networks are considered to be part of the "core" of the Internet, and access networks are between the two. This general structure is depicted in Figure 3.
互联网业务结构的核心是提供与其他网络连接的网络，称为“运输网络”。这些网络相互销售批量带宽和路由服务，并作为客户销售给其他网络。交通网络的外围是直接向个人提供服务的公司、学校和其他网络。这些网络一般可分为“企业网络”和“接入网络”；企业网络为自己的员工或成员提供“免费”连接，还为他们提供一组服务，包括电子邮件、web服务等。接入网络向用户出售宽带连接（DSL、电缆调制解调器、802.11无线或3GPP无线）或“拨号”服务（包括PSTN拨号和ISDN）。订户通常是住宅或小型办公室/家庭办公室（SOHO）客户。住宅客户通常完全依赖其接入提供商提供所有服务，而SOHO从接入提供商处购买一些服务，并可能为自己提供其他服务。向其他任何人出售公交服务的网络——SOHO、住宅和企业网络——通常被称为“边缘网络”；公交网络被认为是互联网“核心”的一部分，接入网络介于两者之间。这一总体结构如图3所示。
------ ------
/ \ / \
/--\ / \ / \
|SOHO|---+ Access | |Enterprise|
\--/ | Service | | Network |
/--\ | Provider| | |
|Home|---+ | ------ | |
\--/ \ +---+ +---+ /
\ / / \ \ /
------ | Transit | ------
| Service |
| Provider |
| |
\ /
\ /
------
------ ------
/ \ / \
/--\ / \ / \
|SOHO|---+ Access | |Enterprise|
\--/ | Service | | Network |
/--\ | Provider| | |
|Home|---+ | ------ | |
\--/ \ +---+ +---+ /
\ / / \ \ /
------ | Transit | ------
| Service |
| Provider |
| |
\ /
\ /
------
Figure 3: Conceptual Model of Internet Businesses
图3：互联网业务的概念模型
A specific example is shown in a traceroute from a home to a nearby school. Internet connectivity in Figure 4 passes through
从家到附近学校的追踪路线中显示了一个具体示例。图4中的Internet连接通过
o the home network,
o 家庭网络，
o Cox Communications, an access network using Cable Modem technology,
o Cox Communications，一种使用电缆调制解调器技术的接入网络，
o TransitRail, a commodity peering service for research and education (R&E) networks,
o TransitRail是一种用于研究和教育（R&E）网络的商品对等服务，
o Corporation for Education Network Initiatives in California (CENIC), a transit provider for educational networks, and
o 加利福尼亚州教育网络倡议公司（CENIC），一家教育网络运输提供商，以及
o the University of California at Santa Barbara, which in this context might be viewed as an access network for its students and faculty or as an enterprise network.
o 加州大学圣芭芭拉分校，在这种背景下，可以被看作是一个接入网络，为其学生和教师或企业网络。
<stealth-10-32-244-218:> fred% traceroute www.ucsb.edu traceroute to web.ucsb.edu (128.111.24.41), 64 hops max, 40 byte packets 1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms 2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ... 3 68.6.13.101 ... 4 68.6.13.129 ... 5 langbbr01-as0.r2.la.cox.net ... 6 calren46-cust.lsanca01.transitrail.net ... 7 dc-lax-core1--lax-peer1-ge.cenic.net ... 8 dc-lax-agg1--lax-core1-ge.cenic.net ... 9 dc-ucsb--dc-lax-dc2.cenic.net ... 10 r2--r1--1.commserv.ucsb.edu ... 11 574-c--r2--2.commserv.ucsb.edu ... 12 * * *
<隐形-10-32-244-218:>fred%traceroute www.ucsb.edu traceroute to web.ucsb.edu（128.111.24.41），最大64跳，40字节数据包1 fred vpn（10.32.244.217）1.560 ms 1.108 ms 1.133 ms 2 wsip-98-173-193-1.sb.sd.cox.net（98.173.193.1）12.540 ms。。。3 68.6.13.101 ... 4 68.6.13.129 ... 5 langbbr01-as0.r2.la.cox.net。。。6 calren46-cust.lsanca01.transitrail.net。。。7 dc-lax-core1--lax-peer1-ge.cenic.net。。。8 dc-lax-agg1--lax-core1-ge.cenic.net。。。9 dc-ucsb--dc-lax-dc2.cenic.net。。。10 r2--r1--1.commserv.ucsb.edu。。。11574-c--r2--2.commserv.ucsb.edu。。。12 * * *
Figure 4: Traceroute from Residential Customer to Educational Institution
图4：从住宅客户到教育机构的追踪路线
Another specific example could be shown in a traceroute from the home through a Virtual Private Network (VPN tunnel) from the home, crossing Cox Cable (an access network) and Pacific Bell (a transit network), and terminating in Cisco Systems (an enterprise network); a traceroute of the path doesn't show that as it is invisible within the VPN and the contents of the VPN are invisible, due to encryption, to the networks on the path. Instead, the traceroute in Figure 5 is entirely within Cisco's internal network.
另一个具体示例可以显示在从家到虚拟专用网络（VPN隧道）的跟踪路由中，穿过考克斯电缆（接入网络）和Pacific Bell（传输网络），并在Cisco Systems（企业网络）中终止；路径的跟踪路由不会显示，因为它在VPN中不可见，并且由于加密，VPN的内容对路径上的网络不可见。相反，图5中的跟踪路由完全位于Cisco的内部网络内。
<stealth-10-32-244-218:~> fred% traceroute irp-view13
traceroute to irp-view13.cisco.com (171.70.120.60),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms
<tunneled path through Cox and Pacific Bell>
2 ****
3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms...
4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ...
5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ...
6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ...
7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ...
8 sjc12-dc5-gw2-ten3-1 ...
9 sjc5-dc4-gw1-ten8-1 ...
10 irp-view13 ...
<stealth-10-32-244-218:~> fred% traceroute irp-view13
traceroute to irp-view13.cisco.com (171.70.120.60),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms
<tunneled path through Cox and Pacific Bell>
2 ****
3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms...
4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ...
5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ...
6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ...
7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ...
8 sjc12-dc5-gw2-ten3-1 ...
9 sjc5-dc4-gw1-ten8-1 ...
10 irp-view13 ...
Figure 5: Traceroute across VPN
图5：跨VPN的跟踪路由
Note that in both cases, the home network uses private address space [RFC1918] while other networks generally use public address space, and that three middleware technologies are in use here. These are the uses of a firewall, a Network Address Translator (NAT), and a Virtual Private Network (VPN).
请注意，在这两种情况下，家庭网络使用专用地址空间[RFC1918]，而其他网络通常使用公共地址空间，这里使用三种中间件技术。这些是防火墙、网络地址转换器（NAT）和虚拟专用网络（VPN）的使用。
Firewalls are generally sold as and considered by many to be a security technology. This is based on the fact that a firewall imposes a border between two administrative domains. Typically, a firewall will be deployed between a residential, SOHO, or enterprise network and its access or transit provider. In its essence, a firewall is a data diode, imposing a policy on what sessions may pass between a protected domain and the rest of the Internet. Simple policies generally permit sessions to be originated from the protected network but not from the outside; more complex policies may permit additional sessions from the outside, such as electronic mail to a mail server or a web session to a web server, and may prevent certain applications from global access even though they are originated from the inside.
防火墙通常作为一种安全技术出售，并被许多人认为是一种安全技术。这是基于防火墙在两个管理域之间设置边界的事实。通常，防火墙将部署在住宅、SOHO或企业网络与其访问或传输提供商之间。从本质上讲，防火墙是一个数据二极管，它对受保护域和Internet其余部分之间可能通过的会话实施策略。简单策略通常允许会话从受保护的网络发起，但不允许从外部发起；更复杂的策略可能允许来自外部的附加会话，例如发送到邮件服务器的电子邮件或发送到web服务器的web会话，并且可能会阻止某些应用程序进行全局访问，即使它们来自内部。
Note that the effectiveness of firewalls remains controversial. While network managers often insist on deploying firewalls as they impose a boundary, others point out that their value as a security solution is debatable. This is because most attacks come from behind the firewall. In addition, firewalls do not protect against application layer attacks such as viruses carried in email. Thus, as a security solution, firewalls are justified as a layer in defense in depth. That is, while an end system must in the end be responsible for its own security, a firewall can inhibit or prevent certain kinds of attacks, for example the consumption of CPU time on a critical server.
请注意，防火墙的有效性仍然存在争议。虽然网络管理者经常坚持部署防火墙，因为他们强加了一个边界，但其他人指出，防火墙作为安全解决方案的价值是有争议的。这是因为大多数攻击来自防火墙后面。此外，防火墙不能防止应用层攻击，例如电子邮件中携带的病毒。因此，作为一种安全解决方案，防火墙被认为是一个纵深防御层。也就是说，虽然终端系统最终必须对其自身的安全负责，但防火墙可以抑制或防止某些类型的攻击，例如在关键服务器上消耗CPU时间。
Key documents describing firewall technology and the issues it poses include:
描述防火墙技术及其带来的问题的关键文档包括：
o IP Multicast and Firewalls [RFC2588]
o IP多播和防火墙[RFC2588]
o Benchmarking Terminology for Firewall Performance [RFC2647]
o 防火墙性能基准术语[RFC2647]
o Behavior of and Requirements for Internet Firewalls [RFC2979]
o 互联网防火墙的行为和要求[RFC2979]
o Benchmarking Methodology for Firewall Performance [RFC3511]
o 防火墙性能基准测试方法[RFC3511]
o Mobile IPv6 and Firewalls: Problem Statement [RFC4487]
o 移动IPv6和防火墙：问题陈述[RFC4487]
o NAT and Firewall Traversal Issues of Host Identity Protocol Communication [RFC5207]
o 主机身份协议通信的NAT和防火墙穿越问题[RFC5207]
Network Address Translation is a technology that was developed in response to ISP behaviors in the mid-1990's; when [RFC1918] was published, many ISPs started handing out single or small numbers of addresses, and edge networks were forced to translate. In time, this became considered a good thing, or at least not a bad thing; it amplified the public address space, and it was sold as if it were a firewall. It of course is not; while traditional dynamic NATs only translate between internal and external session address/port tuples during the detected duration of the session, that session state may exist in the network much longer than it exists on the end system, and as a result constitutes an attack vector. The design, value, and limitations of network address translation are described in:
网络地址转换是20世纪90年代中期针对ISP行为而开发的一项技术；[RFC1918]发布后，许多ISP开始分发单个或少量地址，边缘网络被迫进行翻译。随着时间的推移，这被认为是一件好事，或者至少不是坏事；它扩大了公共广播空间，并被当作防火墙出售。当然不是,；虽然传统动态NATS只在会话的检测持续时间内在内部会话和外部会话地址/端口元组之间转换，但会话状态可能存在于网络中，远多于终端系统上存在的会话状态，因此构成攻击向量。网络地址转换的设计、价值和限制如所述：
o IP Network Address Translator Terminology and Considerations [RFC2663]
o IP网络地址转换器术语和注意事项[RFC2663]
o Traditional IP Network Address Translator [RFC3022]
o 传统IP网络地址转换器[RFC3022]
o Protocol Complications with the IP Network Address Translator [RFC3027]
o IP网络地址转换器的协议复杂性[RFC3027]
o Network Address Translator Friendly Application Design Guidelines [RFC3235]
o 网络地址转换器友好型应用程序设计指南[RFC3235]
o IAB Considerations for Network Address Translation [RFC3424]
o 网络地址转换的IAB注意事项[RFC3424]
o IPsec-Network Address Translation Compatibility Requirements [RFC3715]
o IPsec网络地址转换兼容性要求[RFC3715]
o Network Address Translation Behavioral Requirements for Unicast UDP [RFC4787]
o 单播UDP的网络地址转换行为要求[RFC4787]
o State of Peer-to-Peer Communication across Network Address Translators [RFC5128]
o 跨网络地址转换器的对等通信状态[RFC5128]
o IP Multicast Requirements for a Network Address Translator and a Network Address Port Translator [RFC5135]
o 网络地址转换器和网络地址端口转换器的IP多播要求[RFC5135]
Virtual Private Networks come in many forms; what they have in common is that they are generally tunneled over the Internet backbone, so that as in Figure 5, connectivity appears to be entirely within the edge network although it is in fact across a service provider's network. Examples include IPsec tunnel-mode encrypted tunnels, IP-in-IP or GRE tunnels, and MPLS LSPs [RFC3031][RFC3032].
虚拟专用网络有多种形式；它们的共同点是，它们通常通过互联网主干进行隧道连接，因此如图5所示，连接似乎完全在边缘网络内，尽管它实际上是跨服务提供商的网络。示例包括IPsec隧道模式加密隧道、IP或GRE隧道中的IP以及MPLS LSP[RFC3031][RFC3032]。
Security is addressed in some detail in Section 2.2 and Section 3.1.
第2.2节和第3.1节详细介绍了安全性。
Review comments were made by Adrian Farrel, Andrew Yourtchenko, Ashok Narayanan, Bernie Volz, Chris Lonvick, Dan Romascanu, Dave McGrew, Dave Oran, David Harrington, David Su, Don Sturek, Francis Cleveland, Hemant Singh, James Polk, Jari Arkko, John Meylor, Joseph Salowey, Julien Abeille, Kerry Lynn, Lars Eggert, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, Peter Saint-Andre, Ralph Droms, Robert Sparks, Russ White, Sean Turner, Sheila Frankel, Stephen Farrell, Tim Polk, Toerless Eckert, Tom Herbst, Vint Cerf, and Yoshihiro Ohba. Several of the individuals suggested text, which was very useful, as the authors don't claim to know half as much as their reviewers collectively do.
阿德里安·法雷尔、安德鲁·尤琴科、阿肖克·纳拉亚南、伯尼·沃尔兹、克里斯·隆维克、丹·罗马斯坎努、戴夫·麦格雷夫、戴夫·奥兰、大卫·哈灵顿、大卫·苏、唐·斯特雷克、弗朗西斯·克利夫兰、赫曼特·辛格、詹姆斯·波尔克、贾里·阿克科、约翰·梅勒、约瑟夫·萨洛维、朱利安·阿贝尔、克里·林恩、拉尔斯·艾格特、马格纳斯·韦斯特隆德、穆塔扎·千叶、，保罗·达菲、保罗·霍夫曼、彼得·圣安德烈、拉尔夫·卓姆斯、罗伯特·斯帕克斯、罗斯·怀特、肖恩·特纳、希拉·弗兰克尔、斯蒂芬·法雷尔、蒂姆·波尔克、无趾埃克特、汤姆·赫伯斯特、文特·瑟夫和大贺吉弘。有几个人提出了文本，这是非常有用的，因为作者并没有声称他们的审稿人知道的一半。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294]Loughney，J.，“IPv6节点要求”，RFC 42942006年4月。
[6LOWPAN-HC] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN)", Work in Progress, February 2011.
[6LOWPAN-HC]Hui，J.和P.Thubert，“低功耗和有损网络中IPv6数据报的压缩格式（6LOWPAN）”，正在进行的工作，2011年2月。
[ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, March 2011.
[ABFAB-ARCH]Howlett，J.，Hartman，S.，Tschofenig，H.，和E.Lear，“Web之外联邦访问的应用程序桥接（ABFAB）体系结构”，正在进行的工作，2011年3月。
[AES-CCM-ECC] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM ECC Cipher Suites for TLS", Work in Progress, January 2011.
[AES-CCM-ECC]McGrew，D.，Bailey，D.，Campagna，M.，和R.Dugal，“用于TLS的AES-CCM ECC密码套件”，正在进行的工作，2011年1月。
[COAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", Work in Progress, March 2011.
[COAP]Shelby，Z.，Hartke，K.，Bormann，C.，和B.Frank，“受限应用协议（COAP）”，正在进行的工作，2011年3月。
[DIME-BASE] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", Work in Progress, January 2011.
[DIME-BASE]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，“直径基础协议”，正在进行的工作，2011年1月。
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, February 2011.
[DNS-SD]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，正在进行的工作，2011年2月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security version 1.2", Work in Progress, March 2011.
[DTLS]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，正在进行的工作，2011年3月。
[DYMO] Chakeres, I. and C. Perkins, "Dynamic MANET On-demand (DYMO) Routing", Work in Progress, July 2010.
[DYMO]Chakeres，I.和C.Perkins，“动态MANET随需应变（DYMO）路由”，正在进行的工作，2010年7月。
[IEC61850] Wikipedia, "Wikipedia Article: IEC 61850", June 2011, <http://en.wikipedia.org/w/ index.php?title=IEC_61850&oldid=433437827>.
[IEC61850]维基百科，“维基百科文章：IEC 61850”，2011年6月<http://en.wikipedia.org/w/ index.php？title=IEC_61850&oldid=433437827>。
[IEC62351-3] International Electrotechnical Commission Technical Committee 57, "POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE. DATA AND COMMUNICATIONS SECURITY -- Part 3: Communication network and system security Profiles including TCP/IP", May 2007.
[IEC62351-3]国际电工委员会技术委员会57，“电力系统管理和相关信息交换。数据和通信安全——第3部分：通信网络和系统安全概要，包括TCP/IP”，2007年5月。
[IEEE802.1X] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks - Port based Network Access Control", IEEE Standard 802.1X-2010, February 2010.
[IEEE802.1X]电气和电子工程师协会，“局域网和城域网IEEE标准-基于端口的网络访问控制”，IEEE标准802.1X-2010，2010年2月。
[IP-SEC] Gont, F., "Security Assessment of the Internet Protocol Version 4", Work in Progress, April 2011.
[IP-SEC]Gont，F.，“互联网协议版本4的安全评估”，正在进行的工作，2011年4月。
[IPv6-NODE-REQ] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", Work in Progress, May 2011.
[IPv6节点要求]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，正在进行的工作，2011年5月。
[MULTICAST-DNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, February 2011.
[MULTICAST-DNS]Cheshire，S.和M.Krochmal，“MULTICAST DNS”，正在进行的工作，2011年2月。
[Model] SGIP, "Smart Grid Architecture Committee: Conceptual Model White Paper http://collaborate.nist.gov/ twiki-sggrid/pub/SmartGrid/ SGIPConceptualModelDevelopmentSGAC/ Smart_Grid_Conceptual_Model_20100420.doc".
[模型]SGIP，“智能电网架构委员会：概念模型白皮书”http://collaborate.nist.gov/ twiki sggrid/pub/SmartGrid/SGIPConceptualModelDevelopmentSGAC/Smart_Grid_概念_Model_20100420.doc”。
[OAUTHv2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Authorization Protocol", Work in Progress, May 2011.
[OAUTHv2]Hammer Lahav，E.，Recordon，D.和D.Hardt，“OAuth 2.0授权协议”，正在进行的工作，2011年5月。
[RESTFUL] Fielding, "Architectural Styles and the Design of Network-based Software Architectures", 2000.
[RESTFUL]Fielding，“架构风格和基于网络的软件架构的设计”，2000年。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC0894]Hornig，C.，“通过以太网传输IP数据报的标准”，STD 41，RFC 894，1984年4月。
[RFC1006] Rose, M. and D. Cass, "ISO transport services on top of the TCP: Version 3", STD 35, RFC 1006, May 1987.
[RFC1006]Rose，M.和D.Cass，“TCP之上的ISO传输服务：版本3”，STD 35，RFC 1006，1987年5月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058]Hedrick，C.，“路由信息协议”，RFC10581988年6月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC20801997年1月。
[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top of TCP (ITOT)", RFC 2126, March 1997.
[RFC2126]Poufary，Y.和A.Young，“TCP之上的ISO传输服务（ITOT）”，RFC 2126，1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]Mankin，A.，Romanov，A.，Bradner，S.，和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516]Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.，和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545]Marques，P.和F.Dupont，“将BGP-4多协议扩展用于IPv6域间路由”，RFC 25451999年3月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999.
[RFC2588]Finlayson，R.，“IP多播和防火墙”，RFC2588，1999年5月。
[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月。
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[RFC2615]Malis，A.和W.Simpson，“SONET/SDH上的PPP”，RFC 26151999年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, August 1999.
[RFC2647]Newman，D.，“防火墙性能的基准术语”，RFC 2647，1999年8月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027]Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3235] Senie, D., "Network Address Translator (NAT)- Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235]Senie，D.，“网络地址转换器（NAT）-友好的应用程序设计指南”，RFC 32352002年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)- Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]Eastlake，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC3275，2002年3月。
[RFC3315] Droms, R., 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.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3412]Case，J.，Harrington，D.，Presohn，R.，和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]Levi，D.，Meyer，P.，和B.Stewart，“简单网络管理协议（SNMP）应用”，STD 62，RFC 3413，2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）版本3的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415]Wijnen，B.，Presuhn，R.，和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，“简单网络管理协议（SNMP）协议操作的第2版”，STD 62，RFC 3416，2002年12月。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417]Presohn，R.，“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436]Jungmaier，A.，Rescorla，E.，和M.Tuexen，“流控制传输协议上的传输层安全”，RFC 3436，2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, "Benchmarking Methodology for Firewall Performance", RFC 3511, April 2003.
[RFC3511]Hickman，B.，Newman，D.，Tadjudin，S.，和T.Martin，“防火墙性能的基准测试方法”，RFC 35112003年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[RFC3561]Perkins，C.，Belding Royer，E.，和S.Das，“临时按需距离向量（AODV）路由”，RFC 3561，2003年7月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]Bhattacharyya，S.，“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3590]Haberman，B.，“多播侦听器发现（MLD）协议的源地址选择”，RFC 35902003年9月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626]Clausen，T.和P.Jacquet，“优化链路状态路由协议（OLSR）”，RFC 3626，2003年10月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[RFC3853]Peterson，J.，“会话启动协议（SIP）的S/MIME高级加密标准（AES）要求”，RFC3853，2004年7月。
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923, October 2004.
[RFC3923]Saint Andre，P.，“可扩展消息和状态协议（XMPP）的端到端签名和对象加密”，RFC 39232004年10月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108]Housley，R.“使用加密消息语法（CMS）保护固件包”，RFC 4108，2005年8月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210]Adams，C.，Farrell，S.，Kause，T.，和T.Mononen，“互联网X.509公钥基础设施证书管理协议（CMP）”，RFC 42102005年9月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Ylonen，T.和C.Lonvick，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[RFC4320]Sparks，R.，“解决会话启动协议（SIP）非邀请事务已识别问题的措施”，RFC 4320，2006年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4410] Pullen, M., Zhao, F., and D. Cohen, "Selectively Reliable Multicast Protocol (SRMP)", RFC 4410, February 2006.
[RFC4410]Pullen，M.，Zhao，F.，和D.Cohen，“选择性可靠多播协议（SRMP）”，RFC 4410，2006年2月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile IPv6 and Firewalls: Problem Statement", RFC 4487, May 2006.
[RFC4487]Le，F.，Faccin，S.，Patil，B.，和H.Tschofenig，“移动IPv6和防火墙：问题陈述”，RFC 4487，2006年5月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，2006年5月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556]Zhu，L.和B.Tung，“Kerberos中初始身份验证的公钥加密（PKINIT）”，RFC 45562006年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 45942006年8月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006.
[RFC4608]Meyer，D.，Rockell，R.，和G.Shepherd，“232/8中的源特定协议独立多播”，BCP 120，RFC 4608，2006年8月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]Duke，M.，Braden，R.，Eddy，W.，和E.Blanton，“传输控制协议（TCP）规范文件路线图”，RFC 46142006年9月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]Enns，R.，“网络配置协议”，RFC 47412006年12月。
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[RFC4742]Wasserman，M.和T.Goddard，“在安全外壳（SSH）上使用NETCONF配置协议”，RFC 4742，2006年12月。
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.
[RFC4743]Goddard，T.，“通过简单对象访问协议（SOAP）使用NETCONF”，RFC 4743，2006年12月。
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.
[RFC4744]Lear，E.和K.Crozier，“在块可扩展交换协议（BEEP）上使用NETCONF协议”，RFC 47442006年12月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)", RFC 4854, April 2007.
[RFC4854]Saint Andre，P.，“扩展消息和状态协议（XMPP）扩展的统一资源名（URN）命名空间”，RFC 4854，2007年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[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月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]Elwell，J.，“会话启动协议（SIP）中的连接身份”，RFC 4916，2007年6月。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007.
[RFC4919]Kushalnagar，N.，黑山，G.，和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，2007年8月。
[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月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，2007年8月。
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007.
[RFC5023]Gregorio，J.和B.de hOra，“原子发布协议”，RFC 5023，2007年10月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 50612007年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月。
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[RFC5122]Saint Andre，P.，“可扩展消息和状态协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，RFC 5122，2008年2月。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008.
[RFC5128]Srisuresh，P.，Ford，B.，和D.Kegel，“跨网络地址转换器（NAT）的对等（P2P）通信状态”，RFC 51282008年3月。
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5135]Wing，D.和T.Eckert，“网络地址转换器（NAT）和网络地址端口转换器（NAPT）的IP多播要求”，BCP 135，RFC 5135，2008年2月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191]Forsberg，D.，Ohba，Y.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 51912008年5月。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
[RFC5207]Stieemerling，M.，Quittek，J.，和L.Eggert，“主机身份协议（HIP）通信的NAT和防火墙穿越问题”，RFC 5207，2008年4月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，2008年3月。
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.
[RFC5238]Phelan，T.，“数据报拥塞控制协议（DCCP）上的数据报传输层安全性（DTLS）”，RFC 5238，2008年5月。
[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月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）”，RFC 52722008年6月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277]Chisholm，S.和H.Trevino，“NETCONF事件通知”，RFC 5277，2008年7月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008.
[RFC5289]Rescorla，E.“具有SHA-256/384和AES伽罗瓦计数器模式（GCM）的TLS椭圆曲线密码套件”，RFC 5289，2008年8月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[RFC5308]Hopps，C.，“使用IS-IS路由IPv6”，RFC5308，2008年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, December 2008.
[RFC5393]Sparks，R.，Lawrence，S.，Hawrylyshen，A.，和B.Campen，“解决会话启动协议（SIP）分叉代理中的放大漏洞”，RFC 5393，2008年12月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile for Transport Layer Security (TLS)", RFC 5430, March 2009.
[RFC5430]Salter，M.，Rescorla，E.，和R.Housley，“传输层安全（TLS）的套件B配置文件”，RFC 5430，2009年3月。
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009.
[RFC5433]Clancy，T.和H.Tschofenig，“可扩展认证协议-通用预共享密钥（EAP-GPSK）方法”，RFC 5433，2009年2月。
[RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)", RFC 5437, January 2009.
[RFC5437]Saint Andre，P.和A.Melnikov，“筛选通知机制：可扩展消息和存在协议（XMPP）”，RFC 5437，2009年1月。
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[RFC5539]Badra，M.，“传输层安全（TLS）上的网络配置”，RFC 5539，2009年5月。
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
[RFC5545]Desruisseaux，B.“互联网日历和调度核心对象规范（iCalendar）”，RFC 55452009年9月。
[RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009.
[RFC5546]Daboo，C.，“iCalendar传输独立互操作性协议（iTIP）”，RFC5462009年12月。
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548]Dohler，M.，Watteyne，T.，Winter，T.，和D.Barthel，“城市低功率和有损网络的路由要求”，RFC 5548，2009年5月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569]Despres，R.，“IPv4基础设施上的IPv6快速部署（第6次）”，RFC 5569，2010年1月。
[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5621]Camarillo，G.“会话启动协议（SIP）中的消息体处理”，RFC 56212009年9月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673]Pister，K.，Thubert，P.，Dwars，S.，和T.Phinney，“低功率和有损网络中的工业路由要求”，RFC 5673，2009年10月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote Procedure Call (RPC) for NETCONF", RFC 5717, December 2009.
[RFC5717]Lengyel，B.和M.Bjorklund，“NETCONF的部分锁远程过程调用（RPC）”，RFC 57172009年12月。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.
[RFC5740]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向NACK的可靠多播（NORM）传输协议”，RFC 57402009年11月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，2010年4月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826]Brandt，A.，Buron，J.，和G.Porcu，“低功率和有损网络中的家庭自动化路由要求”，RFC 5826，2010年4月。
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[RFC5838]Lindem，A.，Mirtorabi，S.，Roy，A.，Barnes，M.，和R.Aggarwal，“OSPFv3中地址家庭的支持”，RFC 5838，2010年4月。
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010.
[RFC5849]Hammer Lahav，E.“OAuth 1.0协议”，RFC 5849，2010年4月。
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867]Martocci，J.，De Mil，P.，Riou，N.，和W.Vermeylen，“低功率和有损网络中的楼宇自动化路由要求”，RFC 58672010年6月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC5932] Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher Suites for TLS", RFC 5932, June 2010.
[RFC5932]Kato，A.，Kanda，M.，和S.Kanno，“TLS的茶花密码套件”，RFC 5932，2010年6月。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC5958]Turner，S.，“非对称密钥包”，RFC 5958，2010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010.
[RFC5998]Eronen，P.，Tschofenig，H.，和Y.Sheffer，“IKEv2中仅EAP认证的扩展”，RFC 5998，2010年9月。
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, December 2010.
[RFC6031]Turner，S.和R.Housley，“加密消息语法（CMS）对称密钥包内容类型”，RFC 60312010年12月。
[RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, December 2010.
[RFC6047]Melnikov，A.，“基于iCalendar消息的互操作性协议（iMIP）”，RFC 6047，2010年12月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 60902011年2月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121]圣安德烈，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC61212011年3月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC RFC6144, April 2011.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC RFC6144，2011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
[RFC6180]Arkko，J.和F.Baker，“IPv6部署期间使用IPv6转换机制的指南”，RFC 6180，2011年5月。
[RPL] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2011.
[RPL]Winter，T.，Thubert，P.，Brandt，A.，Clausen，T.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，和J.Vasseur，“RPL:低功耗和有损网络的IPv6路由协议”，正在进行的工作，2011年3月。
[SP-MULPIv3.0] CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I10- 090529", May 2009.
[SP-MULPIv3.0]CableLabs，“DOCSIS 3.0 MAC和上层协议接口规范，CM-SP-MULPIv3.0-I10-090529”，2009年5月。
[SmartGrid] Wikipedia, "Wikipedia Article: Smart Grid", February 2011, <http://en.wikipedia.org/w/ index.php?title=Smart_grid&oldid=415838933>.
[智能电网]维基百科，“维基百科文章：智能电网”，2011年2月<http://en.wikipedia.org/w/ index.php？title=Smart_grid&oldid=415838933>。
[TCP-SEC] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, January 2011.
[TCP-SEC]Gont，F.，“传输控制协议（TCP）的安全评估”，正在进行的工作，2011年1月。
[r1822] Bolt Beranek and Newman Inc., "Interface Message Processor -- Specifications for the interconnection of a host and a IMP, Report No. 1822", January 1976.
[r1822]Bolt Beranek和Newman Inc.，“接口消息处理器——主机和IMP互连规范，第1822号报告”，1976年1月。
[xCAL] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML format for iCalendar", Work in Progress, April 2011.
[xCAL]Daboo，C.，Douglass，M.，和S.Lees，“xCAL:iCalendar的XML格式”，正在进行的工作，2011年4月。
Appendix A. Example: Advanced Metering Infrastructure
附录A.示例：高级计量基础设施
This appendix provides a worked example of the use of the Internet Protocol Suite in a network such as the Smart Grid's Advanced Metering Infrastructure (AMI). There are several possible models.
本附录提供了在智能电网的高级计量基础设施（AMI）等网络中使用互联网协议套件的工作示例。有几种可能的模式。
Figure 6 shows the structure of the AMI as it reaches out towards a set of residences. In this structure, we have the home itself and its Home Area Network (HAN), the Neighborhood Area Network (NAN) that the utility uses to access the meter at the home, and the utility access network that connects a set of NANs to the utility itself. For the purposes of this discussion, assume that the NAN contains a distributed application in a set collectors, which is of course only one way the application could be implemented.
图6显示了AMI向一组住宅延伸时的结构。在这种结构中，我们有家庭本身及其家庭区域网络（HAN），公用事业公司用来访问家庭电表的邻域区域网络（NAN），以及将一组NAN连接到公用事业公司本身的公用事业公司接入网络。出于本讨论的目的，假设NAN在集合收集器中包含一个分布式应用程序，这当然是实现应用程序的唯一方法。
---
A thermostats, appliances, etc
| ------+-----------------------------------
| |
|"HAN" | <--- Energy Services Interface (ESI)
| +---+---+
| | Meter | Meter is generally an ALG between the AMI and the HAN
| +---+---+
V \
--- \
A \ | /
| \ | /
| "NAN" +--+-+-+---+ Likely a router but could
| |Collector | be a front-end application
V +----+-----+ gateway for utility
--- \
A \ | /
| \ | /
|"AMI" +--+-+-+--+
| | AMI |
| | Headend |
V +---------+
---
---
A thermostats, appliances, etc
| ------+-----------------------------------
| |
|"HAN" | <--- Energy Services Interface (ESI)
| +---+---+
| | Meter | Meter is generally an ALG between the AMI and the HAN
| +---+---+
V \
--- \
A \ | /
| \ | /
| "NAN" +--+-+-+---+ Likely a router but could
| |Collector | be a front-end application
V +----+-----+ gateway for utility
--- \
A \ | /
| \ | /
|"AMI" +--+-+-+--+
| | AMI |
| | Headend |
V +---------+
---
Figure 6: The HAN, NAN, and Utility in the Advanced Metering Infrastructure
图6：高级计量基础设施中的HAN、NAN和公用设施
There are several questions that have to be answered in describing this picture, which given possible answers yield different possible models. They include at least:
在描述这幅图时，有几个问题需要回答，给出可能的答案会产生不同的可能模型。它们至少包括：
o How does Demand Response work? Either:
o 需求响应是如何工作的？要么：
* The utility presents pricing signals to the home,
* 电力公司向家庭提供定价信号，
* The utility presents pricing signals to individual devices (e.g., a Pluggable Electric Vehicle),
* 电力公司向单个设备（例如，可插拔电动汽车）提供定价信号，
* The utility adjusts settings on individual appliances within the home.
* 该实用程序可调整家庭中各个设备的设置。
o How does the utility access meters at the home?
o 公用事业公司如何在家里使用电表？
* The AMI Headend manages the interfaces with the meters, collecting metering data and passing it on to the appropriate applications over the Enterprise Bus, or
* AMI前端管理与仪表的接口，收集计量数据并通过企业总线将其传递给适当的应用程序，或
* Distributed application support ("collectors") might access and summarize the information; this device might be managed by the utility or by a service between the utility and its customers.
* 分布式应用程序支持（“收集器”）可以访问和汇总信息；此设备可能由公用事业管理，也可能由公用事业与其客户之间的服务管理。
In implementation, these models are idealized; reality may include some aspects of each model in specified cases.
在实现中，这些模型是理想化的；现实可能包括特定情况下每个模型的某些方面。
The examples include:
这些例子包括：
1. Appendix A.2 presumes that the HAN, the NAN, and the utility's network are separate administrative domains and speak application to application across those domains.
1. 附录A.2假定HAN、NAN和公用事业公司的网络是独立的管理域，并在这些域之间进行应用程序对应用程序的对话。
2. Appendix A.3 repeats the first example, but presuming that the utility directly accesses appliances within the HAN from the collector.
2. 附录A.3重复了第一个示例，但假定公用设施直接从收集器访问HAN内的设备。
3. Appendix A.4 repeats the first example, but presuming that the collector directly forwards traffic as a router in addition to distributed application chores. Note that this case implies numerous privacy and security concerns and as such is considered a less likely deployment model.
3. 附录A.4重复了第一个示例，但假定收集器除了分布式应用程序杂务外，还作为路由器直接转发流量。请注意，这种情况意味着许多隐私和安全问题，因此被认为是不太可能的部署模型。
A key consideration in the Internet has been the development of new link layer technologies over time. The ARPANET originally used a BBN proprietary link layer called BBN 1822 [r1822]. In the late 1970's, the ARPANET switched to X.25 as an interface to the 1822 network. With the deployment of the IEEE 802 series technologies in the early 1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE 802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of various kinds, Frame Relay, and ATM. A key issue in this evolution was that the applications developed to run on the Internet use APIs
互联网的一个关键考虑因素是随着时间的推移，新的链路层技术的发展。ARPANET最初使用一个名为BBN 1822[r1822]的BBN专有链路层。在20世纪70年代末，ARPANET切换到X.25作为1822网络的接口。随着20世纪80年代早期IEEE 802系列技术的部署，IP被部署在以太网（IEEE 802.3）、令牌环（IEEE 802.5）和WiFi（IEEE 802.11）以及Arcnet、各种串行线路、帧中继和ATM上。这一演变过程中的一个关键问题是，为在Internet上运行而开发的应用程序使用API
related to the IPS, and as a result require little or no change to continue operating in a new link layer architecture or a mixture of them.
与IPS相关，因此，在新的链路层体系结构或它们的混合体系结构中继续运行只需要很少或根本不需要更改。
The Smart Grid is likely to see a similar evolution over time. Consider the Home Area Network (HAN) as a readily understandable small network. At this juncture, technologies proposed for residential networks include IEEE P1901, various versions of IEEE 802.15.4, and IEEE 802.11. It is reasonable to expect other technologies to be developed in the future. As the Zigbee Alliance has learned (and as a resulted incorporated the IPS in Smart Energy Profile 2.0), there is significant value in providing a virtual address that is mapped to interfaces or nodes attached to each of those technologies.
随着时间的推移，智能电网可能会出现类似的演变。考虑家庭局域网（HAN）作为一个容易理解的小网络。此时，针对住宅网络提出的技术包括IEEE P1901、各种版本的IEEE 802.15.4和IEEE 802.11。我们有理由期待将来开发其他技术。正如Zigbee联盟所了解到的（并因此将IPS纳入智能能源配置文件2.0），提供映射到连接到每种技术的接口或节点的虚拟地址具有重大价值。
Utility NAN
/
/
+----+-----+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
|Router+------/------ Residential Broadband
+--+---+
|
----+---------+----+----+---- IEEE P1901
| | |
++-+ ++-+ ++-+
|D4| |D5| |D6|
+--+ +--+ +--+
A thermostats, appliances, etc
| ------+----------------+------------------
|"HAN" | |
| +---+---+ +---+---+
| |Router | | Meter |
| |or EMS | | |
V +---+---+ +---+---+
--- | --- \
| ^ \ | /
| |"NAN" \ | /
---+--- | +--+-+-+---+
/ \ | |"Pole Top"|
| Internet| v +----+-----+
\ / ---
-------
Utility NAN
/
/
+----+-----+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
|Router+------/------ Residential Broadband
+--+---+
|
----+---------+----+----+---- IEEE P1901
| | |
++-+ ++-+ ++-+
|D4| |D5| |D6|
+--+ +--+ +--+
A thermostats, appliances, etc
| ------+----------------+------------------
|"HAN" | |
| +---+---+ +---+---+
| |Router | | Meter |
| |or EMS | | |
V +---+---+ +---+---+
--- | --- \
| ^ \ | /
| |"NAN" \ | /
---+--- | +--+-+-+---+
/ \ | |"Pole Top"|
| Internet| v +----+-----+
\ / ---
-------
Figure 7: Two Views of a Home Area Network
图7：家庭区域网络的两个视图
There are two possible communication models within the HAN, both of which are likely to be useful. Devices may communicate directly with each other, or they may be managed by some central controller. An example of direct communications might be a light switch that directly commands a lamp to turn on or off. An example of indirect communications might be a control application in a Customer or Building that accepts telemetry from a thermostat, applies some form of policy, and controls the heating and air conditioning systems. In addition, there are high-end appliances in the market today that use residential broadband to communicate with their manufacturers, and obviously the meter needs to communicate with the utility.
在汉族中有两种可能的交流模式，这两种模式都可能有用。设备可以相互直接通信，也可以由某个中央控制器管理。直接通信的一个例子可能是直接命令灯打开或关闭的灯开关。间接通信的一个例子可能是客户或建筑物中的控制应用程序，该应用程序接受来自恒温器的遥测，应用某种形式的策略，并控制供暖和空调系统。此外，目前市场上有一些高端家电使用住宅宽带与制造商进行通信，显然电表需要与公用设施进行通信。
Figure 7 shows two simple networks, one of which uses IEEE 802.15.4 and IEEE 1901 domains, and one of which uses an arbitrary LAN within the home, which could be IEEE 802.3/Ethernet, IEEE 802.15.4, IEEE 1901, IEEE 802.11, or anything else that made sense in context. Both show the connectivity between them as a router separate from the energy management system (EMS). This is for clarity; the two could of course be incorporated into a single system, and one could imagine appliances that want to communicate with their manufacturers supporting both a HAN interface and a WiFi interface rather than depending on the router. These are all manufacturer design decisions.
图7显示了两个简单的网络，其中一个使用IEEE 802.15.4和IEEE 1901域，另一个使用家庭中的任意LAN，可以是IEEE 802.3/以太网、IEEE 802.15.4、IEEE 1901、IEEE 802.11或上下文中有意义的任何其他网络。两者都将它们之间的连接显示为独立于能源管理系统（EMS）的路由器。这是为了澄清；当然，这两者可以整合到一个单一的系统中，人们可以想象，想要与制造商通信的设备同时支持HAN接口和WiFi接口，而不是依靠路由器。这些都是制造商的设计决策。
The HAN can be seen as communicating with two kinds of non-HAN networks. One is the home LAN, which may in turn be attached to the Internet, and will generally either derive its prefix from the upstream ISP or use a self-generated Unique Local Addressing (ULA). Another is the utility's NAN, which through an ESI provides utility connectivity to the HAN; in this case the HAN will be addressed by a self-generated ULA (note, however, that in some cases ESI may also provide a prefix via DHCP [RFC3315]). In addition, the HAN will have link-local addresses that can be used between neighboring nodes. In general, an HAN will be comprised of both 802.15.4, 802.11, and possibly other networks.
汉族人可以被视为与两种非汉族网络进行通信。一种是家庭局域网，它可以连接到互联网，通常会从上游ISP获得其前缀，或者使用自行生成的唯一本地寻址（ULA）。另一个是公用事业公司的NAN，它通过ESI提供与HAN的公用事业连接；在这种情况下，HAN将由自生成的ULA寻址（但是，注意，在某些情况下，ESI也可以通过DHCP[RFC3315]提供前缀）。此外，HAN将具有可在相邻节点之间使用的链路本地地址。通常，HAN将由802.15.4、802.11以及可能的其他网络组成。
The ESI is a node on the user's residential network, and will not typically provide stateful packet forwarding or firewall services between the HAN and the utility network(s). In general, the ESI is a node on the home network; in some cases, the meter may act as the ESI. However, the ESI must be capable of understanding that most home networks are not 802.15.4 enabled (rather, they are typically 802.11 networks), and that it must be capable of setting up ad hoc networks between various sensors in the home (e.g., between the meter and say, a thermostat) in the event there aren't other networks available.
ESI是用户住宅网络上的节点，通常不会在HAN和公用网络之间提供有状态分组转发或防火墙服务。通常，ESI是家庭网络上的节点；在某些情况下，仪表可能充当ESI。然而，ESI必须能够理解大多数家庭网络没有启用802.15.4（而是通常为802.11网络），并且在没有其他网络可用的情况下，ESI必须能够在家庭中的各种传感器之间（例如，仪表和恒温器之间）建立自组织网络。
In any network, we have a variety of threats and a variety of possible mitigations. These include, at minimum:
在任何网络中，我们都有各种威胁和各种可能的缓解措施。这些措施至少包括：
Link Layer: Why is your machine able to talk in my network? The WiFi SSIDs often use some form of authenticated access control, which may be a simple encrypted password mechanism or may use a combination of encryption and IEEE 802.1X+EAP-TLS Authentication/
链接层：为什么你的机器可以在我的网络中通话？WiFi SSID通常使用某种形式的经过身份验证的访问控制，可以是简单的加密密码机制，也可以使用加密和IEEE 802.1X+EAP-TLS身份验证的组合/
Authorization to ensure that only authorized communicants can use it. If a LAN has a router attached, the router may also implement a firewall to filter remote accesses.
授权以确保只有经授权的通信者才能使用它。如果LAN连接了路由器，路由器还可以实施防火墙来过滤远程访问。
Network Layer: Given that your machine is authorized access to my network, why is your machine talking with my machine? IPsec is a way of ensuring that computers that can use a network are allowed to talk with each other, may also enforce confidentiality, and may provide VPN services to make a device or network appear to be part of a remote network.
网络层：既然您的机器被授权访问我的网络，为什么您的机器与我的机器对话？IPsec是一种确保允许可以使用网络的计算机相互通信的方法，还可以强制保密，并可以提供VPN服务，使设备或网络看起来是远程网络的一部分。
Application: Given that your machine is authorized access to my network and my machine, why is your application talking with my application? The fact that your machine and mine are allowed to talk for some applications doesn't mean they are allowed to for all applications. (D)TLS, https, and other such mechanisms enable an application to impose application-to-application controls similar to the network layer controls provided by IPsec.
应用程序：既然您的机器被授权访问我的网络和机器，为什么您的应用程序与我的应用程序对话？允许您的机器和我的机器在某些应用程序中进行对话并不意味着允许它们在所有应用程序中进行对话。（D） TLS、https和其他此类机制使应用程序能够实施应用程序到应用程序的控制，类似于IPsec提供的网络层控制。
Remote Application: How do I know that the data I received is the data you sent? Especially in applications like electronic mail, where data passes through a number of intermediaries that one may or may not really want munging it (how many times have you seen a URL broken by a mail server?), we have tools (DKIM, S/MIME, and W3C XML Signatures to name a few) to provide non-repudiability and integrity verification. This may also have legal ramifications: if a record of a meter reading is to be used in billing, and the bill is disputed in court, one could imagine the court wanting proof that the record in fact came from that meter at that time and contained that data.
远程应用程序：我如何知道我收到的数据是您发送的数据？特别是在像电子邮件这样的应用程序中，数据通过许多中间层传递，人们可能真的希望也可能不希望使用这些中间层（您见过多少次URL被邮件服务器破坏了？），我们有一些工具（DKIM、S/MIME和W3C XML签名等）来提供不可抵赖性和完整性验证。这也可能产生法律后果：如果在计费中使用抄表记录，并且账单在法庭上有争议，人们可以想象法庭需要证据证明记录事实上来自当时的抄表并包含该数据。
Application-specific security: In addition, applications often provide security services of their own. The fact that I can access a file system, for example, doesn't mean that I am authorized to access everything in it; the file system may well prevent my access to some of its contents. Routing protocols like BGP are obsessed with the question "what statements that my peer made am I willing to believe", and monitoring protocols like SNMP may not be willing to answer every question they are asked, depending on access configuration.
特定于应用程序的安全性：此外，应用程序通常提供自己的安全服务。例如，我可以访问文件系统并不意味着我有权访问其中的所有内容；文件系统可能会阻止我访问其中的某些内容。像BGP这样的路由协议沉迷于“我的同行所做的陈述我愿意相信”这个问题，而像SNMP这样的监控协议可能不愿意回答他们所问的每一个问题，这取决于访问配置。
Devices in the HAN want controlled access to the LAN in question for obvious reasons. In addition, there should be some form of mutual authentication between devices -- the lamp controller will want to know that the light switch telling it to change state is the right light switch, for example. The EMS may well want strong authentication of accesses -- the parents may not want the children
由于明显的原因，韩国人的设备想要控制对局域网的访问。此外，设备之间应该有某种形式的相互认证——例如，灯控制器希望知道告诉它改变状态的灯开关是正确的灯开关。EMS可能需要对访问进行强身份验证——家长可能不想要孩子
changing the settings, and while the utility and the customer are routinely granted access, other parties (especially parties with criminal intent) need to be excluded.
更改设置时，虽然公用事业公司和客户通常被授予访问权限，但需要排除其他方（特别是有犯罪意图的方）。
With the background given in Appendix A.1, we can now discuss the use of IP (IPv4 or IPv6) in the AMI.
有了附录A.1中给出的背景知识，我们现在可以讨论在AMI中使用IP（IPv4或IPv6）。
In this first model, consider the three domains in Figure 6 to literally be separate administrative domains, potentially operated by different entities. For example, the NAN could be a WiMAX network operated by a traditional telecom operator, the utility's network (including the collector) is its own, and the residential network is operated by the resident. In this model, while communications between the collector and the Meter are normal, the utility has no other access to appliances in the home, and the collector doesn't directly forward messages from the NAN upstream.
在第一个模型中，考虑图6中的三个域，从字面上来说是独立的管理域，潜在地由不同的实体操作。例如，NAN可以是由传统电信运营商运营的WiMAX网络，公用事业公司的网络（包括收集器）是其自己的，住宅网络由居民运营。在这种模式中，虽然采集器和电表之间的通信正常，但公用事业公司无法访问家用电器，采集器也不会直接转发来自NAN上游的消息。
In this case, as shown in Figure 7, it would make the most sense to design the collector, the Meter, and the EMS as hosts on the NAN -- design them as systems whose applications can originate and terminate exchanges or sessions in the NAN, but not forward traffic from or to other devices.
在这种情况下，如图7所示，将收集器、电表和EMS设计为NAN上的主机是最有意义的——将它们设计为其应用程序可以在NAN中发起和终止交换或会话，但不能转发来自或到其他设备的流量的系统。
In such a configuration, Demand Response has to be performed by having the EMS accept messages such as price signals from the "pole top", apply some form of policy, and then orchestrate actions within the home. Another possibility is to have the EMS communicate with the ESI located in the meter. If the thermostat has high demand and low demand (day/night or morning/day/evening/night) settings, Demand Response might result in it moving to a lower demand setting, and the EMS might also turn off specified circuits in the home to diminish lighting.
在这种配置中，需求响应必须通过让EMS接受来自“极点”的价格信号等消息来执行，应用某种形式的策略，然后在家中协调行动。另一种可能性是让EMS与仪表中的ESI通信。如果恒温器具有高需求和低需求（白天/晚上或早上/白天/晚上/晚上）设置，需求响应可能会导致恒温器移动到较低的需求设置，EMS也可能会关闭家庭中的指定电路以减少照明。
In this scenario, Quality of Service (QoS) issues reportedly arise when high precedence messages must be sent through the collector to the home; if the collector is occupied polling the meters or doing some other task, the application may not yield control of the processor to the application that services the message. Clearly, this is either an application or an Operating System problem; applications need to be designed in a manner that doesn't block high precedence messages. The collector also needs to use appropriate NAN services, if they exist, to provide the NAN QoS it needs. For example, if WiMax is in use, it might use a routine-level service for normal exchanges but a higher precedence service for these messages.
在这种情况下，当必须通过收集器将高优先级消息发送到家庭时，据说会出现服务质量（QoS）问题；如果收集器正在轮询仪表或执行其他任务，则应用程序可能无法将处理器的控制权让给为消息提供服务的应用程序。显然，这要么是应用程序问题，要么是操作系统问题；应用程序需要以不阻止高优先级消息的方式设计。收集器还需要使用适当的NAN服务（如果存在），以提供其所需的NAN QoS。例如，如果使用WiMax，它可能会对正常交换使用常规级别的服务，但对这些消息使用更高优先级的服务。
In this second model, let's imagine that the utility directly accesses appliances within the HAN. Rather than expect an EMS to respond to price signals in Demand Response, it directly commands devices like air conditioners to change state, or throws relays on circuits to or within the home.
在第二个模型中，让我们设想实用程序直接访问HAN中的设备。与期望EMS在需求响应中响应价格信号不同，它直接命令空调等设备改变状态，或在通往家庭或家庭内部的电路上设置继电器。
+----------+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
| +------/------ NAN
|Router|
| +------/------ Residential Broadband
+--+---+
|
----+--+------+----+----+---- IEEE P1901
| | | |
+-+-+ ++-+ ++-+ ++-+
|EMS| |D4| |D5| |D6|
+---+ +--+ +--+ +--+
+----------+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
| +------/------ NAN
|Router|
| +------/------ Residential Broadband
+--+---+
|
----+--+------+----+----+---- IEEE P1901
| | | |
+-+-+ ++-+ ++-+ ++-+
|EMS| |D4| |D5| |D6|
+---+ +--+ +--+ +--+
Figure 8: Home Area Network
图8：家庭区域网络
In this case, as shown in Figure 8, the Meter and EMS act as hosts on the HAN, and there is a router between the HAN and the NAN.
在这种情况下，如图8所示，仪表和EMS充当HAN上的主机，HAN和NAN之间有一个路由器。
As one might imagine, there are serious security considerations in this model. Traffic between the NAN and the residential broadband network should be filtered, and the issues raised in Appendix A.1.2 take on a new level of meaning. One of the biggest threats may be a legal or at least a public relations issue; if the utility intentionally disables a circuit in a manner or at a time that threatens life (the resident's kidney dialysis machine is on it, or a respirator, for example), the matter might make the papers. Unauthorized access could be part of juvenile pranks or other things as well. So one really wants the appliances to only obey commands under strict authentication/authorization controls.
可以想象，在这个模型中存在着严重的安全考虑。应过滤NAN和住宅宽带网络之间的流量，附录A.1.2中提出的问题具有新的意义。最大的威胁之一可能是法律问题，或者至少是公共关系问题；如果公用事业公司故意以威胁生命的方式或在威胁生命的时间（例如，居民的肾透析机在上面，或呼吸器）禁用电路，则该问题可能会使文件失效。未经授权的访问可能是青少年恶作剧或其他事情的一部分。因此，人们确实希望设备只在严格的身份验证/授权控制下遵守命令。
In addition to the QoS issues raised in Appendix A.2, there is the possibility of queuing issues in the router. In such a case, the IP datagrams should probably use the Low-Latency Data Service Class
除了附录A.2中提出的QoS问题外，路由器中还可能存在排队问题。在这种情况下，IP数据报可能应该使用低延迟数据服务类
described in [RFC4594], and let other traffic use the Standard Service Class or other service classes.
如[RFC4594]所述，并允许其他通信使用标准服务类或其他服务类。
In this third model, the relationship between the NAN and the HAN is either as in Appendix A.2 or Appendix A.3; what is different is that the collector may be an IP router. In addition to whatever autonomous activities it is doing, it forwards traffic as an IP router in some cases.
在第三个模型中，南部和汉族之间的关系如附录A.2或附录A.3所示；不同的是，收集器可能是一个IP路由器。除了执行任何自主活动外，在某些情况下，它还作为IP路由器转发流量。
Analogous to Appendix A.3, there are serious security considerations in this model. Traffic being forwarded should be filtered, and the issues raised in Appendix A.1.2 take on a new level of meaning -- but this time at the utility mainframe. Unauthorized access is likely similar to other financially-motivated attacks that happen in the Internet, but presumably would be coming from devices in the HAN that have been co-opted in some way. One really wants the appliances to only obey commands under strict authentication/authorization controls.
与附录A.3类似，该模型中存在严重的安全考虑。应该对转发的流量进行过滤，附录A.1.2中提出的问题具有新的意义——但这次是在公用事业主机上。未经授权的访问很可能类似于互联网上发生的其他出于财务动机的攻击，但可能是来自汉人以某种方式增选的设备。人们确实希望设备只在严格的身份验证/授权控制下遵守命令。
In addition to the QoS issues raised in Appendix A.2, there is the possibility of queuing issues in the collector. In such a case, the IP datagrams should probably use the Low-Latency Data Service Class described in [RFC4594], and let other traffic use the Standard Service Class or other service classes.
除了附录A.2中提出的QoS问题外，收集器中还可能存在排队问题。在这种情况下，IP数据报可能应该使用[RFC4594]中描述的低延迟数据服务类，并让其他流量使用标准服务类或其他服务类。
Authors' Addresses
作者地址
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
EMail: fred@cisco.com
EMail: fred@cisco.com
David Meyer Cisco Systems Eugene, Oregon 97403 USA
David Meyer Cisco Systems Eugene，美国俄勒冈州97403
EMail: dmm@cisco.com
EMail: dmm@cisco.com