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




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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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  Internet Protocol  . . . . . . . . . . . . . . . .  9  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  PKIX . . . . . . . . . . . . . . . . . . . . . . . 18  Kerberos . . . . . . . . . . . . . . . . . . . . . 19
     3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 19
       3.2.1.  IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19  Dual Stack Coexistence . . . . . . . . . . . . . . 19  Tunneling Mechanism  . . . . . . . . . . . . . . . 20  Translation between IPv4 and IPv6 Networks . . . . 20
       3.2.2.  Internet Protocol Version 4  . . . . . . . . . . . . . 21  IPv4 Address Allocation and Assignment . . . . . . 22  IPv4 Unicast Routing . . . . . . . . . . . . . . . 22  IPv4 Multicast Forwarding and Routing  . . . . . . 22
       3.2.3.  Internet Protocol Version 6  . . . . . . . . . . . . . 23  IPv6 Address Allocation and Assignment . . . . . . 23  IPv6 Routing . . . . . . . . . . . . . . . . . . . 24
       3.2.4.  Routing for IPv4 and IPv6  . . . . . . . . . . . . . . 24  Routing Information Protocol . . . . . . . . . . . 24  Open Shortest Path First . . . . . . . . . . . . . 24  ISO Intermediate System to Intermediate System . . 25  Border Gateway Protocol  . . . . . . . . . . . . . 25  Dynamic MANET On-Demand (DYMO) Routing . . . . . . 25  Optimized Link State Routing Protocol  . . . . . . 26  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  Internet Protocol  . . . . . . . . . . . . . . . .  9  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  PKIX . . . . . . . . . . . . . . . . . . . . . . . 18  Kerberos . . . . . . . . . . . . . . . . . . . . . 19
     3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 19
       3.2.1.  IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19  Dual Stack Coexistence . . . . . . . . . . . . . . 19  Tunneling Mechanism  . . . . . . . . . . . . . . . 20  Translation between IPv4 and IPv6 Networks . . . . 20
       3.2.2.  Internet Protocol Version 4  . . . . . . . . . . . . . 21  IPv4 Address Allocation and Assignment . . . . . . 22  IPv4 Unicast Routing . . . . . . . . . . . . . . . 22  IPv4 Multicast Forwarding and Routing  . . . . . . 22
       3.2.3.  Internet Protocol Version 6  . . . . . . . . . . . . . 23  IPv6 Address Allocation and Assignment . . . . . . 23  IPv6 Routing . . . . . . . . . . . . . . . . . . . 24
       3.2.4.  Routing for IPv4 and IPv6  . . . . . . . . . . . . . . 24  Routing Information Protocol . . . . . . . . . . . 24  Open Shortest Path First . . . . . . . . . . . . . 24  ISO Intermediate System to Intermediate System . . 25  Border Gateway Protocol  . . . . . . . . . . . . . 25  Dynamic MANET On-Demand (DYMO) Routing . . . . . . 25  Optimized Link State Routing Protocol  . . . . . . 26  Routing for Low-Power and Lossy Networks . . . . . 26
       3.2.5.  IPv6 Multicast Forwarding and Routing  . . . . . . . . 27  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  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
1. Introduction
1. 介绍

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.


In the words of Wikipedia [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.


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].


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.


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:


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:


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设计和部署中体现的业务体系结构。

2. The Internet Protocol Suite
2. 因特网协议套件

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.


2.1. Internet Protocol Layers
2.1. 因特网协议层

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.


                           | 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.


                    |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.1.1. Application
2.1.1. 应用

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.


2.1.2. Transport
2.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".


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.


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.


2.1.3. Network
2.1.3. 网络

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网络和其他类型的网络。 Internet Protocol 因特网协议

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.


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和应用程序的其他层保持不变。 Lower-Layer Networks 低层网络

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)网络传输。

2.1.4. Media Layers: Physical and Link
2.1.4. 媒体层:物理层和链接层

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.


2.2. Security Issues
2.2. 安全问题

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.


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.


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.


2.2.1. Physical and Data Link Layer Security
2.2.1. 物理和数据链路层安全

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.


2.2.2. Network, Transport, and Application Layer Security
2.2.2. 网络、传输和应用层安全

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):


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.


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.


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).


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.


2.3. Network Infrastructure
2.3. 网络基础设施

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.


2.3.1. Domain Name System (DNS)
2.3.1. 域名系统(DNS)

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.


2.3.2. Network Management
2.3.2. 网络管理

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.


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


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协议得到解决。

3. Specific Protocols
3. 特定协议

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.


3.1. Security Toolbox
3.1. 安全工具箱

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.


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.


3.1.1. Authentication, Authorization, and Accounting (AAA)
3.1.1. 身份验证、授权和记帐(AAA)

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.


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


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].


3.1.2. Network Layer Security
3.1.2. 网络层安全

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).


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.


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.


For the actual data protection, two types of protocols have historically been used, namely the IP Authentication Header (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.


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).


3.1.3. Transport Layer Security
3.1.3. 传输层安全

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.


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.


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.


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].


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.


3.1.4. Application Layer Security
3.1.4. 应用层安全

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].


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.


3.1.5. Secure Shell
3.1.5. 安全壳

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.


3.1.6. Key Management Infrastructures
3.1.6. 关键管理基础设施

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,下面将简要介绍这两种方案。 PKIX PKIX

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).


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 is generally perceived to better handle use-cases spanning multiple independent domains when compared to Kerberos.

与Kerberos相比,PKI通常被认为能够更好地处理跨多个独立域的用例。 Kerberos Kerberos

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.


3.2. Network Layer
3.2. 网络层

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.


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.


3.2.1. IPv4/IPv6 Coexistence Advice
3.2.1. IPv4/IPv6共存建议

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]。该文件中的思想在此复制。 Dual Stack Coexistence 双堆栈共存

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]中描述了这种方法。 Tunneling Mechanism 隧道机制

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]中记录了一种更具动态性的方法。 Translation between IPv4 and IPv6 Networks IPv4和IPv6网络之间的转换

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.


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.


For those applications in which network layer translation is indicated, the IETF has designed a translation mechanism, which is described in the following documents:


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.


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.


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.


3.2.2. Internet Protocol Version 4
3.2.2. 互联网协议版本4

IPv4 [RFC0791] and the Internet Control Message Protocol (ICMP) [RFC0792] comprise the IPv4 network layer. IPv4 provides unreliable delivery of datagrams.


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 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 Address Allocation and Assignment IPv4地址分配和分配

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]识别彼此的地址。 IPv4 Unicast Routing IPv4单播路由

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 Multicast Forwarding and Routing IPv4多播转发和路由

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.


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


"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].


3.2.3. Internet Protocol Version 6
3.2.3. 互联网协议版本6

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 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 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.


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报头压缩和子网架构问题,可能适用于智能电网高级计量基础设施或其他传感器领域。 IPv6 Address Allocation and Assignment 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]可用于保护这些操作。 IPv6 Routing IPv6路由

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.


3.2.4. Routing for IPv4 and IPv6
3.2.4. IPv4和IPv6的路由 Routing Information Protocol 路由信息协议

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]为算法设计者提供了缓解这些问题的指导。 Open Shortest Path First 先开最短路径

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.


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


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的协议的缺点是,每个路由器必须存储域中每个路由器连接的第一人称语句。 ISO Intermediate System to Intermediate System ISO中间系统到中间系统

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协议的优点主要在于,该网络被描述为一个路由器晶格,与子网和隔离主机相连。它的拓扑结构可以通过简单地宣布更改而快速轻松地更改,而不存在“通过谣言路由”的问题,因为路由域中的每台主机都有一个关于域中每个路由器连接的第一人称声明。否定的是一个推论:每个路由器必须存储域中每个路由器连接的第一人称语句。 Border Gateway Protocol 边界网关协议

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.


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的注意事项涉及必须定义的策略的灵活性和复杂性。灵活性是一件好事;在一个不是由专业人士运行的网络中,复杂性是很沉重的。 Dynamic MANET On-Demand (DYMO) Routing 动态MANET按需(DYMO)路由

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


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].


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本质上是为移动自组织网络设计的反应式路由协议,可用于其他形式的自组织网络。它们提供分布式子网中的一个设备和少数设备(可能包括到另一个子网的网关或路由器)之间的连接,而不跟踪到其他设备的连接。本质上,路由是根据需要计算和发现的,主机或路由器只需要维护当前工作和需要的路由。 Optimized Link State Routing Protocol 优化链路状态路由协议

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]是为移动自组织网络设计的主动式路由协议,可用于其他形式的自组织网络。它在分布式子网内的系统之间提供任意连接。与为有线网络设计的协议一样,只要检测到更改,就会计算路由,并在每个路由器的表中维护路由。然而,在子网内作为路由器运行的节点集是相当流动的,并且依赖于子网的这种瞬时拓扑结构。 Routing for Low-Power and Lossy Networks 低功耗有损网络的路由选择

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].


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流量)。

3.2.5. IPv6 Multicast Forwarding and Routing
3.2.5. IPv6多播转发和路由

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.


The mechanisms experimentally developed for reliable multicast in IPv4, discussed in Section, can be used in IPv6 as well.

第3.2.2.3节中讨论的IPv4中为可靠多播实验开发的机制也可用于IPv6。 Protocol-Independent Multicast Routing 协议无关多播路由

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.


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.


3.2.6. Adaptation to Lower-Layer Networks and Link Layer Protocols
3.2.6. 适应低层网络和链路层协议

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.


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].


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.


3.3. Transport Layer
3.3. 传输层

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.


3.3.1. User Datagram Protocol (UDP)
3.3.1. 用户数据报协议(UDP)

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


provide for multiplexing of applications directly on the IP layer, with transport functionality embedded in the application.


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].


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.


3.3.2. Transmission Control Protocol (TCP)
3.3.2. 传输控制协议(TCP)

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].


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.


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.


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.


3.3.3. Stream Control Transmission Protocol (SCTP)
3.3.3. 流控制传输协议(SCTP)

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 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.


3.3.4. Datagram Congestion Control Protocol (DCCP)
3.3.4. 数据报拥塞控制协议(DCCP)

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 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.


3.4. Infrastructure
3.4. 基础设施
3.4.1. Domain Name System
3.4.1. 域名系统

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 is found registered with a .com registrar, and within the associated network other names like 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].


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].


3.4.2. Dynamic Host Configuration
3.4.2. 动态主机配置

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.


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.


3.4.3. Network Time
3.4.3. 网络时间

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]。

3.5. Network Management
3.5. 网络管理

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.


3.5.1. Simple Network Management Protocol (SNMP)
3.5.1. 简单网络管理协议(SNMP)

The Simple Network Management Protocol, originally specified in the late 1980's and having passed through several revisions, is specified in several documents:


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.


3.5.2. Network Configuration (NETCONF) Protocol
3.5.2. 网络配置(NETCONF)协议

The NETCONF Configuration Protocol is specified in one basic document, with supporting documents for carrying it over the IPS. These documents include:


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.


3.6. Service and Resource Discovery
3.6. 服务和资源发现

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.


3.6.1. Service Discovery
3.6.1. 服务发现

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].


3.6.2. Resource Discovery
3.6.2. 资源发现

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


discovery and includes the ability to filter on attributes of resource descriptions. Finally, CoAP resource discovery can also be used to discover HTTP resources.


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].


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.


3.7. Other Applications
3.7. 其他应用

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.


3.7.1. Session Initiation Protocol
3.7.1. 会话启动协议

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.


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/


IPv4, IPv4/IPv6 as described in Section, or IPv6/IPv6, increases the complexity of SIP/SDP deployment. This is further discussed in [RFC2993] and [RFC5626].


3.7.2. Extensible Messaging and Presence Protocol
3.7.2. 可扩展消息和状态协议

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 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].


3.7.3. Calendaring
3.7.3. 压光

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]。

4. A Simplified View of the Business Architecture
4. 业务体系结构的简化视图

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.


                            ------                  ------
                           /      \                /      \
                 /--\     /        \              /        \
                |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


A specific example is shown in a traceroute from a home to a nearby school. Internet connectivity in Figure 4 passes through


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 traceroute to (, 64 hops max, 40 byte packets 1 fred-vpn ( 1.560 ms 1.108 ms 1.133 ms 2 ( 12.540 ms ... 3 ... 4 ... 5 ... 6 ... 7 ... 8 ... 9 ... 10 ... 11 ... 12 * * *

<隐形-10-32-244-218:>fred%traceroute traceroute to,最大64跳,40字节数据包1 fred vpn( ms 1.108 ms 1.133 ms 2 ms。。。3 ... 4 ... 5。。。6。。。7。。。8。。。9。。。10。。。。。。12 * * *

Figure 4: Traceroute from Residential Customer to Educational Institution


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 (,
                 64 hops max, 40 byte packets
          1  fred-vpn (  2.560 ms  1.100 ms  1.198 ms
                    <tunneled path through Cox and Pacific Bell>
          2  ****
          3  sjc24-00a-gw2-ge2-2 (  26.298 ms...
          4  sjc23-a5-gw2-g2-1 (  25.214 ms  ...
          5  sjc20-a5-gw1 (  23.205 ms  ...
          6  sjc12-abb4-gw1-t2-7 (  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 (,
                 64 hops max, 40 byte packets
          1  fred-vpn (  2.560 ms  1.100 ms  1.198 ms
                    <tunneled path through Cox and Pacific Bell>
          2  ****
          3  sjc24-00a-gw2-ge2-2 (  26.298 ms...
          4  sjc23-a5-gw2-g2-1 (  25.214 ms  ...
          5  sjc20-a5-gw1 (  23.205 ms  ...
          6  sjc12-abb4-gw1-t2-7 (  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


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).


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.


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.


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:


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]。

5. Security Considerations
5. 安全考虑

Security is addressed in some detail in Section 2.2 and Section 3.1.


6. Acknowledgements
6. 致谢

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.


7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[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.


[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.

[RFC4294]Loughney,J.,“IPv6节点要求”,RFC 42942006年4月。

7.2. Informative References
7.2. 资料性引用

[6LOWPAN-HC] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN)", Work in Progress, February 2011.


[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.


[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.


[DIME-BASE] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", Work in Progress, January 2011.


[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, February 2011.


[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security version 1.2", Work in Progress, March 2011.


[DYMO] Chakeres, I. and C. Perkins, "Dynamic MANET On-demand (DYMO) Routing", Work in Progress, July 2010.


[IEC61850] Wikipedia, "Wikipedia Article: IEC 61850", June 2011, < index.php?title=IEC_61850&oldid=433437827>.

[IEC61850]维基百科,“维基百科文章:IEC 61850”,2011年6月< 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.


[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.


[IP-SEC] Gont, F., "Security Assessment of the Internet Protocol Version 4", Work in Progress, April 2011.


[IPv6-NODE-REQ] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", Work in Progress, May 2011.


[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 twiki-sggrid/pub/SmartGrid/ SGIPConceptualModelDevelopmentSGAC/ Smart_Grid_Conceptual_Model_20100420.doc".

[模型]SGIP,“智能电网架构委员会:概念模型白皮书” 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.


[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.


[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.


[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.


[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.


[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.


[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.


[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.


[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.


[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.


[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.


[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.


[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.


[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.


[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.


[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.


[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.和 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.


[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.


[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.


[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.


[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, < index.php?title=Smart_grid&oldid=415838933>.

[智能电网]维基百科,“维基百科文章:智能电网”,2011年2月< index.php?title=Smart_grid&oldid=415838933>。

[TCP-SEC] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, January 2011.


[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.


Appendix A. Example: Advanced Metering Infrastructure


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.


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.


    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


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.1. How to Structure a Network
A.1. 如何构建网络

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.


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


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接口,而不是依靠路由器。这些都是制造商的设计决策。

A.1.1. HAN Routing
A.1.1. 汉路由

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.


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.


A.1.2. HAN Security
A.1.2. 汉安

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.


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.


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.


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


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.


A.2. Model 1: AMI with Separated Domains
A.2. 模型1:具有分离域的AMI

With the background given in Appendix A.1, we can now discuss the use of IP (IPv4 or IPv6) in the AMI.


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.


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.


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.


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,它可能会对正常交换使用常规级别的服务,但对这些消息使用更高优先级的服务。

A.3. Model 2: AMI with Neighborhood Access to the Home
A.3. 模式2:AMI,邻里可以进入家庭

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.


                +----------+ +--+ +--+ +--+
                |  Meter   | |D1| |D2| |D3|
                +-----+----+ ++-+ ++-+ ++-+
                      |       |    |    |
                ----+-+-------+----+----+---- IEEE 802.15.4
                 |      +------/------ NAN
                 |      +------/------ Residential Broadband
                ----+--+------+----+----+---- IEEE P1901
                       |      |    |    |
                      +-+-+   ++-+ ++-+ ++-+
                      |EMS|   |D4| |D5| |D6|
                      +---+   +--+ +--+ +--+
                +----------+ +--+ +--+ +--+
                |  Meter   | |D1| |D2| |D3|
                +-----+----+ ++-+ ++-+ ++-+
                      |       |    |    |
                ----+-+-------+----+----+---- IEEE 802.15.4
                 |      +------/------ NAN
                 |      +------/------ Residential Broadband
                ----+--+------+----+----+---- IEEE P1901
                       |      |    |    |
                      +-+-+   ++-+ ++-+ ++-+
                      |EMS|   |D4| |D5| |D6|
                      +---+   +--+ +--+ +--+

Figure 8: Home Area Network


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.


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.


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


described in [RFC4594], and let other traffic use the Standard Service Class or other service classes.


A.4. Model 3: Collector Is an IP Router
A.4. 型号3:收集器是一个IP路由器

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.


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.


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.


Authors' Addresses


Fred Baker Cisco Systems Santa Barbara, California 93117 USA



David Meyer Cisco Systems Eugene, Oregon 97403 USA

David Meyer Cisco Systems Eugene,美国俄勒冈州97403