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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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
       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.

インターネットプロトコルスイート(IPS)は、多数の建築コンポーネントのオプションを提供します。例えば、IPSは、2つのシステム間の伝統的な輸送機能のためにいくつかの選択肢を提供する:伝送制御プロトコル(TCP)[RFC0793]、ストリーム制御伝送プロトコル(SCTP)[RFC4960]、及びデータグラム輻輳制御プロトコル(DCCP)[ RFC4340]。別のオプションは、このような基本的に、独自の輸送サービスを実現するためのアプリケーションを許可するユーザーデータグラムプロトコル(UDP)[RFC0768]、としてカプセル化を選択することです。実際には、設計者は、問題が解決されていることが適切であるトランスポートプロトコルを選択します。

The IPS is standardized by the Internet Engineering Task Force (IETF). IETF protocols are documented in the Request for Comments (RFC) series. Several RFCs have been written describing how the IPS should be implemented. These include:

IPSは、IETF(Internet Engineering Task Force)によって標準化されています。 IETFプロトコルは、コメント(RFC)シリーズのリクエストに記載されています。いくつかのRFCは、IPSを実装する方法が記述されています。これらは、次のとおりです。

o Requirements for Internet Hosts - Communication Layers [RFC1122],

インターネットホストのためのO要件 - 通信層[RFC1122]、

o Requirements for Internet Hosts - Application and Support [RFC1123],

インターネットホストのためのO要件 - アプリケーションとサポート[RFC1123]、

o Requirements for IP Version 4 Routers [RFC1812], and


o IPv6 Node Requirements [RFC4294].


At the time of this writing, RFC 4294 is in the process of being updated, in [IPv6-NODE-REQ].

この記事の執筆時点では、RFC 4294には、[IPv6の-NODE-REQ]で、更新中のプロセスです。

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 Section 3 outlines a set of protocols that may be useful in Smart Grid deployment. It is not exhaustive.


o Finally, Section 4 provides an overview of the business architecture embodied in the design and deployment of the IPS.


2. The Internet Protocol Suite

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     |

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

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.

インターネット・プロトコル・スタック内で、「輸送」は、エンド・ツー・エンドの未変性の進行最下位プロトコル層であり、それはエンド・ツー・エンドのデータ配信サービスを担当します。インターネットでは、トランスポート層、ネットワーク層以上の層です。 1つのIPアドレスで複数のアプリケーションを多重化する能力:トランスポート層プロトコルは、単一の最小要件を持っています。 UDP [RFC0768]、TCP [RFC0793]、DCCP [RFC4340]、SCTP [RFC4960]、およびNORM [RFC5740]はそれぞれ、ポート番号、送信用と受信機のための1つのペアを使用してこれを達成します。ポート番号は、ピアまたはクライアントが有するセッションを開くことができる一般的な「リスナー」、または「リスナー」と特定対応かもしれないアプリケーションインスタンスを識別する。 IPデータグラムのセッション識別は、多くの場合、「5タプル」と呼ばれ、ソースおよび宛先IPアドレス、送信元および宛先ポート、および使用中のトランスポートプロトコルの識別子から構成されています。

In addition, the responsibilities of a specific transport layer protocol typically include the delivery of data (either as a stream of messages or a stream of bytes) in a stated sequence with stated expectations regarding delivery rate and loss. For example, TCP will reduce its rate in response to loss, as a congestion control trigger, while DCCP accepts some level of loss if necessary to maintain timeliness.

加えて、特定のトランスポート層プロトコルの責任は、典型的には、送達速度および損失について述べ期待に記載の順序で(いずれかのメッセージのストリームまたはバイトストリームとして)データの送達を含みます。 DCCPは、損失のあるレベルを受け入れながら、必要に応じて、例えば、TCPが適時性を維持するために、輻輳制御トリガとして、損失に応答してその速度を減少させます。

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などのコネクションレスネットワークでは、データはデータグラムとして配信されます。各データグラムには、送信元と宛先のネットワーク層アドレスの両方が含まれており、ネットワークがそれを提供する責任があります。インターネットプロトコルスイートでは、インターネットプロトコルは、エンドツーエンドを実行するネットワークです。これは、IPネットワークおよび他のタイプのネットワークの両方を含む他のLANとWAN技術、上でカプセル化することができます。 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.

インターネット層は、様々なネットワーク技術との違いを隠し均一なネットワーク抽象化ネットワークを提供します。これは、等、イーサネット、802.15.4、などの多様なネットワークが均一なIPネットワークに結合することを可能にする層です。新しいネットワーク技術は、IPSと変わらず、これらのプロトコルを使用するアプリケーションの他の層を残し、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(Generic Route Encapsulation)[RFC2784]のトンネルモードとしてトンネリング技術を使用して、パブリックインターネットを介して仮想プライベートネットワーク(VPN)で運ばれます。また、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.

IPアーキテクチャの最下層に、データは、メッセージに符号化され、物理媒体を介して送信します。 IETFは、IPv4とIPv6の様々なメディアタイプを運ぶためのアルゴリズムを指定するが、それは稀に実際にメディアを定義する - それは喜んIEEE、ITU、および他のソースからの仕様を使用します。

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.

IETFは、そのプロトコルとアーキテクチャの設計に真剣にセキュリティを取ります。すべてのIETF仕様では、提供されるセキュリティ上の脅威と対策を文書化するセキュリティの考慮事項のセクションを持っている必要があります。 RFC 3552 [RFC3552]は、このようなセキュリティの考慮事項のセクションの記述に関する推奨事項を示します。また、古典的なインターネットセキュリティ脅威モデルについて説明し、一般的なセキュリティ目標を示しています。

In a nutshell, security has to be integrated into every protocol, protocol extension, and consequently, every layer of the protocol stack to be useful. We illustrate this also throughout this document with references to further security discussions. Our experience has shown that dealing with security as an afterthought does not lead to the desired outcome.


The discussion of security threats and available security mechanisms aims to illustrate some of the design aspects that commonly appear.


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

物理層およびデータリンク層では、脅威は、一般的に、ネットワーク上の物理的な攻撃を中心に - バックホー、物理メディアの劣化、環境騒音の様々な種類の効果を。無線ベースのネットワークが原因の距離、干渉、及び環境因子にフェードを通知するために対象となります。広くIEEE 802.15.4ネットワークが頻繁計とそれを管理するデバイスとの間の金属接地板を配置することに留意されたいです。ファイバーは、それがuntappableであると考えられていたので、展開一度でした。我々は、以来、繊維を曲げると入射光を集めることによって、それをタップすることを学んだ、と私たちはバックホーについて学んできました。結果として、いくつかのインストールは両方とも素早くカットの位置を特定するために、それはより困難にタップする作るために、加圧されたシース内に光ファイバケーブルを包みます。

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.


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.


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


To this we add authenticity, which requires that the communicating peers prove that they are in fact who they say they are to each other (i.e., mutual authentication). This generally means knowing "who" the peer is, and that they demonstrate the possession of a "secret" as part of the security protocol interaction.


The following three examples aim to illustrate these security requirements.


One common attack against a TCP session is to bombard the session with reset messages. Other attacks against TCP include the "SYN flooding" attack, in which an attacker attempts to exhaust the memory of the target by creating TCP state. In particular, the attacker attempts to exhaust the target's memory by opening a large number of unique TCP connections, each of which is represented by a Transmission Control Block (TCB). The attack is successful if the attacker can cause the target to fill its memory with TCBs.

TCPセッションに対する一つの一般的な攻撃は、リセットメッセージとのセッションを砲撃することです。 TCPに対する他の攻撃は、攻撃者がTCPの状態を作成することにより、ターゲットのメモリを使い果たすしようとしている「SYNフラッド」攻撃が含まれます。具体的には、攻撃者は、伝送制御ブロック(TCB)で表され、それぞれが固有のTCP接続、多数の開いてターゲットのメモリを排出しようとします。攻撃者はターゲットがのTCBとそのメモリを埋めるために引き起こす可能性があれば攻撃が成功しています。

A number of mechanisms have been developed to deal with these types of denial-of-service attacks. One, "SYN Cookies", delays state establishment on the server side to a later phase in the protocol exchange. Another mechanism, specifically targeting the reset attack cited above, provides authentication services in TCP itself to ensure that fake resets are rejected.


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.

DNSの主要機能は、数値のIPアドレスに名前を変換されます。これは、ネットワークを実行するには重要ではないですが、数値のアドレスはニーモニック名に置き換えることができた場合、一部の機能は非常に簡単に作られています。これは、ネットワークの再番号付けを容易にし、一般的にネットワークの管理性と保守性を向上させます。 DNSは、DNSに強力な暗号認証を提供するために使用することができDNSSECと呼ばれるセキュリティ拡張機能のセットを、持っています。 DNSとDNSSECは、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.

ネットワーク管理は難しい問題であることが証明されています。そのため、様々な解決策は、提案された実装、および展開されています。各ソリューションは、彼らの視点のための強固な引数を持つすべての人のその支持者を持っています。 ASN.1符号化され、主にシステム変数のモニタリングのために使用されるSNMP、およびNETCONF [RFC4741]、XMLでエンコードされ、主に装置構成のために使用される:IETFは、デバイスの動作のための2つの主要なネットワーク管理ソリューションを有しています。

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

ネットワーク管理の別の局面は、セクション3.4.2に記載されているホストの初期プロビジョニングおよび構成です。スマートグリッドの展開は、DHCPまたは近隣探索のいずれかの範囲内ではないかもしれないアイデンティティ認証および許可(ならびに他のプロビジョニングと構成)を必要とし得ることに留意されたいです。 IPプロトコルスイートは、安全なプロビジョニングと構成のための限定的なサポートがありますが、これらの問題は、このようなDOCSIS 3.0 [SP-MULPIv3.0]などの仕様でIPプロトコルを使用して解決されています。

3. Specific Protocols

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.

前述のように、セキュリティソリューションの重要な考慮事項は、各レイヤでの適切な緩和策と相まって優れた脅威の分析です。 IETFは、時間の経過とともにプロトコルは、多くの場合、同様のセキュリティサービスを要求するという観察に基づいたセキュリティのためのビルディング・ブロックの数を開発しました。以下のサブセクションでは、これらの一般的に使用されるセキュリティ・ビルディング・ブロックのいくつかを概説します。それらを再利用すると、このようなオープンソースコードの利用可能性、既存システムとの経験、開発されている拡張子の数、および列挙された技術は、セキュリティ専門家の数によって見直され、分析されていることを確信などのいくつかの利点を提供しています。

It is important to highlight that in addition to the mentioned security tools, every protocol often comes with additional, often unique security considerations that are specific to the domain in which the protocol operates. Many protocols include features specifically designed to mitigate these protocol-specific risks. In other cases, the security considerations will identify security-relevant services that are required from other network layers to achieve appropriate levels of security.


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.

(例えば、RFC 5216に記載されているような暗号化認証及び鍵交換を実行するための具体的な方法として、[RFC5216]及びRFC 5433 [RFC5433])認証プロトコル(EAP [RFC4017])EAPメソッドをカプセル化するための容器として、EAPメソッド、A (ネットワークアクセスサーバとして)エンドホストとサーバ側エンティティ間のEAPペイロードを運ぶプロトコル、および(潜在的にクロスドメインのシナリオで)サーバインフラストラクチャバックエンドためにEAPペイロードを運ぶための方法の認可を提供することと会計機能。後者の部分はRADIUS及び直径によって提供されます。エンドホストとネットワークアクセスサーバとの間のEAPペイロードを運ぶために、異なるメカニズムは、[IEEE802.1X]ネットワークアクセス(PANA)[RFC5191]とIEEE 802.1Xの認証を実施するためのプロトコルとして、標準化されています。そのような企業ネットワークなどのリモートネットワークへのアクセスのために、のIKEv2 [RFC5996]内でEAPを利用する能力も開発されています。

More recently, the same architecture with EAP and RADIUS/Diameter is being reused for application layer protocols. More details about this architectural variant can be found in [ABFAB-ARCH].

より最近では、EAPとRADIUS /直径同じアーキテクチャは、アプリケーション層のプロトコルのために再使用されています。このアーキテクチャのバリアントについての詳細は[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.

前工程のために、インターネット鍵交換プロトコルバージョン2(IKEv2の[RFC5996])が標準化されたプロトコルの最新版です。 IKEは多少商品アラカルトを選択するように、独立して、データを保護するために使用される暗号アルゴリズムのそれぞれを交渉します。

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.

[RFC4302]とカプセル化セキュリティペイロード(ESP)[RFC4303]。二人は彼らが提供するセキュリティサービスが異なります。最も重要な違いは、AHにはないながら、ESPは、機密性保護を提供することです。 ESPは、認証サービスを提供することができるので、IPsecのを利用して、最新のプロトコルの開発はESPの使用を指定し、AHを使用しないでください。

In addition to these base line protocol mechanisms a number of extensions have been developed for IKEv2 (e.g., an extension to perform EAP-only authentication [RFC5998]) and since the architecture supports flexible treatment of cryptographic algorithms a number of them have been specified (e.g., [RFC4307] for IKEv2, and [RFC4835] for AH and ESP).


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.

トランスポート層セキュリティV1.2 [RFC5246]は、トランスポート層より上のデータを保護するセキュリティサービスです。プロトコルは、クライアント/サーバアプリケーションは、盗聴、改ざん、またはメッセージ偽造を防ぐために設計された方法で通信することができます。 TLSは、独立したアプリケーションプロトコルです。

TLS is composed of two layers: the TLS Record protocol and the TLS Handshake protocol. The TLS Record protocol provides connection security that has two basic properties: (a) confidentiality protection and (b) integrity protection.

TLSレコード・プロトコルとTLSハンドシェイクプロトコル:TLSは、二つの層から構成されています。 (a)は、機密性保護、および(b)完全性保護:TLSレコードプロトコルは、2つの基本的な性質を持っている接続のセキュリティを提供します。

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

IKEv2の/ IPsecのとは違って、TLSはスイートでこれらの暗号化パラメータ、いわゆる「暗号スイート」を交渉します。 TLSと交渉することができる暗号スイートの例は、楕円曲線暗号(ECC)[RFC4492]、[RFC5289] [AES-CCM-ECC]、カメリア[RFC5932]、およびスイートBプロファイル[RFC5430]を含みます。 【IEC62351-3】スマートグリッドに使用するための異なるTLS暗号スイートの使用を概説します。 ECCのための基本的な暗号化メカニズムは[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.

通常、TCP - TLSは、信頼性の高いトランスポート・チャネル上で実行する必要があります。 UDPのような信頼性のないデータグラムトラフィックの同じセキュリティサービスを、提供するために、データグラムトランスポート層セキュリティ(DTLS [RFC4347] [DTLS])を開発しました。

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

暗号メッセージ構文(CMS [RFC5652])は、署名ダイジェスト認証、または任意のメッセージコンテンツを暗号化するカプセル化構文です。また、そのような時間に署名等の任意の属性は、メッセージの内容と一緒に署名することができ、それは、そのような署名に関連付けられるcountersignaturesなどの他の属性を提供します。 CMSは、PKIX(X.509を使用して公開鍵インフラストラクチャ)で定義された一人として、証明書ベースの鍵管理のためのワーキンググループ[RFC5280]をさまざまなアーキテクチャをサポートすることができます。 CMSは、セキュアな電子メール[RFC5751]などのさまざまなプロトコルに鍵管理[RFC5958] [RFC6031]、およびファームウェアのアップデート[RFC4108]をセキュリティサービスを提供するために活用されています。

Related work includes the use of digital signatures on XML-encoded documents, which has been jointly standardized by W3C and the IETF [RFC3275]. Digitally signed XML is a good choice where applications natively support XML-encoded data, such as the Extensible Messaging and Presence Protocol (XMPP).

関連する作業は共同W3CとIETF [RFC3275]によって標準化されたXMLでエンコードされた文書のデジタル署名の使用を含みます。デジタル署名されたXMLは、アプリケーションがネイティブな拡張メッセージングおよびプレゼンスプロトコル(XMPP)としてXMLでエンコードされたデータを、サポートして良い選択です。

More recently, the work on delegated authentication and authorization often demanded by Web applications have been developed with the Open Web Authentication (OAuth) protocol [RFC5849] [OAUTHv2]. OAuth is used by third-party applications to gain access to protected resources (such as energy consumption information about a specific household) without having the resource owner share its long-term credentials with that third-party. In OAuth, the third-party application requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner. More specifically, the third-party applications obtain an access token during the OAuth protocol exchange. This token denotes a specific scope, duration, and other access attributes. As a result, it securely gains access to the protected resource with the consent of the resource owner.

さらに最近では、多くの場合、Webアプリケーションが要求する委任認証と承認の作業はオープンWeb認証(OAuthの)プロトコル[RFC5849] [OAUTHv2]で開発されています。 OAuthのは、リソースの所有者がそのサードパーティとの長期の資格情報を共有することなく、(例えば、特定の世帯についてのエネルギー消費情報などの)保護されたリソースへのアクセスを得るために、サードパーティのアプリケーションによって使用されます。 OAuthのでは、サードパーティのアプリケーションは、リソースサーバによってリソースの所有者によって制御され、ホストされたリソースへのアクセスを要求し、リソースの所有者のものとは、異なる証明書を発行しています。より具体的には、サードパーティアプリケーションは、OAuthプロトコル交換中にアクセストークンを取得します。このトークンは、特定の範囲、期間、および他のアクセス属性を示しています。その結果、それはしっかりとリソースの所有者の同意を得て保護されたリソースへのアクセスを得ます。

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で使用される2つの一般的な鍵管理方式があります。 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のための主要なインターネット標準は、X.509公開鍵証明書のフォーマットのプロファイルである[RFC5280]です。公開鍵証明書、例えば、TLSやS / MIMEを使用するすべてのプロトコルのための鍵を管理し、安全に配布する機能を提供し、今日のオペレーティングプライベートおよび商用CAの範囲があります。プロファイルの標準に加えて、PKIXワーキンググループは、管理プロトコルの数を定義している(例えば、[RFC5272]と[RFC4210])ならびにオンライン証明書状態プロトコルとして、公開鍵証明書の失効を処理するためのプロトコル(OCSP) [RFC2560]。

PKI is generally perceived to better handle use-cases spanning multiple independent domains when compared to Kerberos.

PKIは、一般的にケルベロスと比較した場合、複数の独立したドメインにまたがるより良いハンドルユースケースに知覚されます。 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.

ケルベロスネットワーク認証システム[RFC4120]は、一般的に一つの場所で認証、許可、およびポリシーを集中するために、組織内で使用されます。 Kerberosはネイティブ認証の基礎として、ユーザー名とパスワードをサポートしています。ケルベロスにおける初期認証のための公開鍵暗号(PKINIT)[RFC4556]を使用すると、Kerberosは証明書または公開鍵ベースの認証をサポートしています。これは、1つの場所でのユーザーアカウントへの証明書の検証と証明書のマッピングに関するポリシーを集中させることによって利点を提供することができます。 GSS-API [RFC1964] [RFC2743] [RFC4121]を通じて、Kerberosは、ほとんどのアプリケーションのための認証を管理するために使用することができます。 Kerberosは、組織や企業内最適に動作しますが、それは管理ドメイン間で共有する認証を許可する機能を持っています。

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.

早く自由プールが来年中に排出されることが期待される2011年2月3日に、IANAのIPv4フリープール(使用可能な、未割り当てのIPv4アドレスのプールが)疲れた、と地域インターネットレジストラ(のRIR)なお、そうでない場合は。 IETF、IANA、およびRIRは新たな展開がIPv6を使用することをお勧めします、とIPv4インフラストラクチャは、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 ensure that servers and their applications similarly support both protocols, and


o require that all new systems and applications purchased or upgraded support both protocols.


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の展開で、これは多くの場合、静的なトンネルを使用して行きました。より動的なアプローチは、[RFC5569]のIPv4基盤のIPv6のRapid Deployment(6rd)に記載されています。 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]

IPv4 / IPv6変換するためのOフレームワーク[RFC6144]

o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]

OのIPv6は、IPv4 / IPv6のトランスレータ[RFC6052]のアドレッシング

o DNS extensions [RFC6147]


o IP/ICMP Translation Algorithm [RFC6145]

O IP / ICMP翻訳アルゴリズム[RFC6145]

o Translation from IPv6 Clients to IPv4 Servers [RFC6146]


As with IPv4/IPv4 Network Address Translation, translation between IPv4 and IPv6 has limited real world applicability for an application protocol that carries IP addresses in its payload and expects those addresses to be meaningful to both client and server. However, for those protocols that do not, protocol translation can provide a useful network extension.

IPv4の/ IPv4のネットワークアドレス変換と同様に、IPv4とIPv6間の変換は、そのペイロードにIPアドレスを運び、これらのアドレスは、クライアントとサーバーの両方に意味があると予想したアプリケーションプロトコルのための実世界の適用可能性を制限しています。しかし、ないそれらのプロトコルのために、プロトコル変換は、便利なネットワーク拡張を提供することができます。

Network-based translation provides for two types of services: stateless (and therefore scalable and load-sharable) translation between IPv4 and IPv6 addresses that embed an IPv4 address in them, and stateful translation similar to IPv4/IPv4 translation between IPv4 addresses. The stateless mode is straightforward to implement, but due to the embedding, requires IPv4 addresses to be allocated to an otherwise IPv6-only network, and is primarily useful for IPv4- accessible servers implemented in the IPv6 network. The stateful mode allows clients in the IPv6 network to access servers in the IPv4 network, but does not provide such service for IPv4 clients accessing IPv6 peers or servers with general addresses; it has the advantage that it does not require that a unique IPv4 address be embedded in the IPv6 address of hosts using this mechanism.

ステートレス(したがって、拡張性と負荷共有可能)、その中にIPv4アドレスを埋め込みIPv4アドレスとIPv6アドレス間の変換、およびIPv4アドレス間のIPv4 / IPv4の変換に似ステートフル翻訳:ネットワークベースの翻訳は、2種類のサービスを提供します。ステートレスモードは、実装が簡単であるが、原因の埋め込みにはIPv4が他のIPv6のみのネットワークに割り当てられるアドレスを必要とし、IPv6ネットワークに実装アクセス可能なサーバIPv4-に主に有用です。ステートフルモードでは、IPv6ネットワーク内のクライアントがIPv4ネットワーク内のサーバーにアクセスすることができますが、一般的なアドレスでのIPv6ピアまたはサーバにアクセスするのIPv4クライアントのため、このようなサービスを提供していません。それはユニークIPv4アドレスがこのメカニズムを使用してホストのIPv6アドレスに埋め込まれていることを必要としないという利点を有します。

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の[RFC0791]とインターネット制御メッセージプロトコル(ICMP)[RFC0792]はIPv4ネットワーク層を含みます。 IPv4のデータグラムの信頼性のない配信を提供します。

IPv4 also provides for fragmentation and reassembly of long datagrams for transmission through networks with small Maximum Transmission Units (MTU). The MTU is the largest packet size that can be delivered across the network. In addition, the IPS provides ICMP [RFC0792], which is a separate protocol that enables the network to report errors and other issues to hosts that originate problematic datagrams.

IPv4のも小さい最大伝送単位(MTU)とネットワークを介して送信するための長いデータグラムの断片化と再アセンブリを提供します。 MTUは、ネットワーク経由で配信できる最大パケットサイズです。また、IPSは、問題のデータグラムを発信ホストにエラーやその他の問題を報告するためにネットワークを可能にする別のプロトコルであるICMP [RFC0792]を提供します。

IPv4 originally supported an experimental type of service field that identified eight levels of operational precedence styled after the requirements of military telephony, plus three and later four bit flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 [RFC2328] interpreted as control traffic; this control traffic is assured of not being dropped when queued or upon receipt, even if other traffic is being dropped. These control bits turned out to be less useful than the designers had hoped. They were replaced by the Differentiated Services Architecture [RFC2474] [RFC2475], which

IPv4のは、もともと軍事テレフォニーの要件の後にスタイル操作の優先順位の8つのレベル、プラスOSIは3つの以降4ビットフラグ識別されたサービス分野の実験タイプサポートのIPv4(IS-IS)[RFC1195]やOSPFバージョン2のためのISを-IS制御トラフィックとして解釈[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.

データグラムに適用されるアルゴリズム(「ホップ単位動作」)を選択するために使用される6ビットのコードポイントを含みます。 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.


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]を含む指定された、OSIは、IPv4 [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.

IPv4のは、もともとユニキャスト(ポイントツーポイント)プロトコルとして指定し、そして[RFC1112]にマルチキャストをサポートするように拡張しました。これは、マルチキャストグループに参加するアプリケーションを可能にするために、インターネットグループ管理プロトコル[RFC3376] [RFC4604]を使用し、ほとんどのアプリケーションのためのルーティングおよびマルチキャストメッセージの配信のためのソース固有のマルチキャスト[RFC4607]を使用しています。

An experiment carried out in IPv4 that is not part of the core Internet architecture but may be of interest in the Smart Grid is the development of so-called "Reliable Multicast". This is "so-called" because it is not "reliable" in the strict sense of the word -- it is perhaps better described as "enhanced reliability". A best effort network by definition can lose traffic, duplicate it, or reorder it, something as true for multicast as for unicast. Research in

コアインターネットアーキテクチャの一部ではなく、スマートグリッドへの関心のものとすることができるIPv4の中で行われた実験では、いわゆる「リライアブルマルチキャスト」の開発です。それは言葉の厳密な意味での「信頼性」ではないので、これは、「いわゆる」である - それは、おそらくより良い「高い信頼性」と記載されています。定義により、ベストエフォートネットワークは、ユニキャスト用としてマルチキャストのための真の何かを、トラフィックを失うそれを複製し、またはそれを並べ替えることができます。の研究

"Reliable Multicast" technology intends to improve the probability of delivery of multicast traffic.


In that research, the IETF imposed guidelines [RFC2357] on the research community regarding what was desirable. Important results from that research include a number of papers and several proprietary protocols including some that have been used in support of business operations. RFCs in the area include The Use of Forward Error Correction (FEC) in Reliable Multicast [RFC3453], the Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) [RFC4410].

その研究では、IETFが望ましい何であったかについての研究コミュニティのガイドライン[RFC2357]を課しました。その研究からの重要な結果は、論文や事業運営のサポートに使用されているものも含めて、いくつかの独自のプロトコルの数が含まれます。領域内のRFCは、前方誤り訂正高信頼マルチキャスト[RFC3453]で(FEC)の使用を含み、否定応答(NACK)配向高信頼マルチキャスト(NORM)プロトコル[RFC5740]、選択的高信頼マルチキャストプロトコル(SRMP)[ RFC4410]。

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.

インターネット制御メッセージプロトコル「V6」[RFC4443]とのIPv6 [RFC2460]は、インターネットのための次世代のプロトコルを構成します。 IPv6は、ソースから固定長アドレスによって識別される宛先ホストへのデータグラムの送信を提供します。

IPv6 also provides for fragmentation and reassembly of long datagrams by the originating host, if necessary, for transmission through "small packet" networks. ICMPv6, which is a separate protocol implemented along with IPv6, enables the network to report errors and other issues to hosts that originate problematic datagrams.

必要であれば、IPv6はまた、「小さなパケット」ネットワークを介して送信するため、送信元ホストにより長いデータグラムの断片化と再アセンブリを提供します。 IPv6のに伴って実施別のプロトコルであるICMPv6のは、問題のあるデータグラムを発信ホストにエラーやその他の問題を報告するためにネットワークを可能にします。

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.

低消費電力無線パーソナルエリアネットワークRFC [RFC4919]と6LoWPANネットワーク文書[6LOWPAN-HC]でのIPv6データグラムのための圧縮フォーマット上の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]は管理上のIPv4アドレスである方法と同様にしたDHCPv6 [RFC3315]を使用して割り当てることができます。また、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.


IETF-specified routing protocols include RIP for IPv6 [RFC2080], IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6 [RFC2545]. Active research exists in mobile ad hoc routing, routing in low-power networks (sensors and Smart Grids), and other routing paradigms; these result in new protocols and modified forwarding paradigms.

IETF指定のルーティングプロトコルは、IPv6 [RFC2080]のためにRIPを含む、のIPv6 [RFC2545]のIPv6 [RFC5308]、OSPFのIPv6 [RFC5340]のために、およびBGP-4 - です。活発な研究は、モバイルアドホックルーティング、低電力ネットワーク(センサ及びスマートグリッド)内のルーティング、および他のルーティングパラダイムに存在します。新しいプロトコルや修正フォワーディングパラダイムではこれらの結果。

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は広く知られているベルマン - フォード法の分散バリアントに基づいて距離ベクトルルーティングプロトコルです。距離ベクトルルーティングプロトコルでは、各ルータが他の人に彼らのルートテーブルとの結果を統合し、再発表それらの近隣ルータにそのルートテーブルの内容を発表しました。これは、「噂でルーティング」として特徴付け、そして私たちは人間のゴシップで見つける病気の多くを被ってきた - 特定の障害シナリオで古いまたは誤った情報を伝播し、トポロジの変化に応答しない場合であること。 [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.

オープンショーテストパスファースト(OSPF)ルーティングプロトコルは、インターネットで広く使用されるプロトコルの一つです。 OSPFは、Dijkstraのよく知られたSPF(Shortest Path First)アルゴリズムに基づいています。これは、IPv6のためのIPv6 [RFC5340]のIPv4、OSPF用OSPFバージョン2 [RFC2328]として実装され、およびOSPFv3の[RFC5838]でアドレスファミリのサポートを可能にするために[RFC5340]は、IPv4とIPv6の両方をルーティングします。

The advantage of any SPF-based protocol (i.e., OSPF and IS-IS) is primarily that every router in the network constructs its view of the 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ベースのプロトコルの利点(すなわち、OSPFおよびIS-IS)は、ネットワーク内のすべてのルータが最初の手の知識ではなく、「ゴシップ」プロトコルが伝播する距離ベクトルからネットワークのビューを構築する主ということです。そのため、トポロジは、迅速かつ簡単に、単純に変更を発表することによって変更されます。 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)ルーティングプロトコルは、インターネットで広く使用されるプロトコルの一つです。 IS-ISは、ダイクストラのSPFアルゴリズムに基づいています。もともとはコネクションレスネットワークサービス(CLNS)のルーティングのためのISO DP 10589として指定され、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.

特定のポリシーを適用しながら - サービスプロバイダー、仲間、彼らの上流のネットワーク、および顧客 - ボーダーゲートウェイプロトコル(BGP)[RFC4271]は、広く行政エンティティ間のルートを交換するためにIPv4インターネットで使用されています。 BGPのマルチプロトコル拡張[RFC4760]は、とりわけ、BGPは、IPv6ドメイン間ルーティング[RFC2545]、マルチキャスト到達可能性情報、およびVPNの情報を運ぶことができます。

Considerations that apply with BGP deal with the flexibility and complexity of the policies that must be defined. Flexibility is a good thing; in a network that is not run by professionals, the complexity is burdensome.

BGPに適用留意事項を定義する必要があります政策の柔軟性と複雑さに対処します。柔軟性は良いことです。専門家によって運営されていないネットワークでは、複雑さが負担です。 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 Are interconnected through a low-data-rate network interface and are potentially vulnerable to communication instability and low packet delivery rates.


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


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.

インターネットで展開初期のマルチキャストモデルはどれ-ソースマルチキャスト(ASM)と呼ばれていました。 ASMモデルでは、どのホストがグループに送信でき、ドメイン間のマルチキャストは困難でした。プロトコル仕様(改訂版)[RFC3973]及びプロトコル独立マルチキャスト - スパースモード(PIM-SM):プロトコル仕様(改訂版)[RFC4601]はASMモデルのために設計された稠密モード(PIM-DM) - そのようなプロトコル独立マルチキャストなどのプロトコル。

Many modern multicast deployments use Source-Specific Multicast (PIM-SSM) [RFC3569][RFC4608]. In the SSM model, a host expresses interest in a "channel", which is comprised of a source (S) and a group (G). Distribution trees are rooted to the sending host (called an "(S,G) tree"). Since only the source S can send on to the group, SSM has inherent anti-jamming capability. In addition, inter-domain multicast is simplified since finding the (S,G) channel they are interested in receiving is the responsibility of the receivers (rather than the networks). This implies that SSM requires some form of directory service so that receivers can find the (S,G) channels.

現代の多くのマルチキャスト展開では、ソース固有のマルチキャスト(PIM-SSM)[RFC3569] [RFC4608]を使用します。 SSMモデルでは、ホストは、ソース(S)とグループ(G)から構成されている「チャネル」への関心を表現します。配信ツリーは、(「(S、G)ツリー」と呼ばれる)を送信ホストに根ざしています。唯一のソースSは、グループへ送ることができるので、SSMは、固有の抗ジャミング能力を持っています。また、ドメイン間マルチキャストは、それらが受信することに興味を持っている(S、G)チャネルを見つけるために簡略化された受信機(よりむしろネットワーク)の責任です。これは、受信機は、(S、G)チャネルを見つけることができるように、SSMは、ディレクトリサービスのいくつかのフォームを必要とすることを意味します。

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

イーサネット(登録商標)/ IEEE 802.3:IPv4がイーサネットヘッダ使用する各リンク層環境で実行(10及び100Mbpsの有線イーサネット、1および10Gbpsの有線イーサネット(登録商標)と言うことであり、IEEE 802.11の様々なバージョン)[RFC0894]を使用しています。 IPv6は、[RFC2464]を使用して同じことを行います。

PPP: The IETF has defined a serial line protocol, the Point-to-Point Protocol (PPP) [RFC1661], that uses High-Level Data Link Control (bit-synchronous or byte synchronous) framing. The IPv4 adaptation specification is [RFC1332], and the IPv6 adaptation specification is [RFC5072]. Current use of this protocol is in traditional serial lines, authentication exchanges in DSL networks using PPP Over Ethernet (PPPoE) [RFC2516], and the Digital Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH) using PPP over SONET/SDH [RFC2615].

PPP:IETFは、シリアル回線プロトコル、高レベルデータリンク制御(ビット同期又は同期バイト)フレーミングを使用するポイントツーポイントプロトコル(PPP)[RFC1661]を定義しています。 IPv4の適応仕様は[RFC1332]であり、IPv6の適応仕様は[RFC5072]です。このプロトコルの現在の使用は、従来のシリアルラインであるDSLネットワークにおける認証交換は、SONET上にPPPを使用してPPPオーバーイーサネット(PPPoEの)[RFC2516]、およびデジタルシグナル階層(一般パケット・オン・SONET / SDHと呼ばれる)を使用して/ 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.

このセクションでは、UDP、TCP、SCTP、およびDCCPの機能の概要を説明します。 UDPとTCPは最もよく知られており、SCTPやDCCPは、特定の目的のために建設された新しいプロトコルでありながら、最も広く、今日のインターネットで使用されています。必要なときに、他のトランスポートプロトコルを構築することができます。

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

TCP [RFC0793]はインターネットで使用される主要なトランスポートプロトコルです。この用語は、プロトコルの設計に使用されているように、それは、「信頼性」である:それはそのピアにデータを配信し、送信者に確認を提供し、またはそれをしようとして死にます。これは、輻輳制御[RFC5681]と明示的輻輳通知[RFC3168]のための拡張機能を持っています。

The user interface for TCP is a byte stream interface -- an application using TCP might "write" to it several times only to have the data compacted into a common segment and delivered as such to its peer. For message-stream interfaces, ACSE/ROSE uses the ISO Transport Service on TCP [RFC1006][RFC2126] in the application.

TCPのためのユーザインタフェースは、バイト・ストリーム・インタフェースである - それに数回「書き込み」可能性があるTCPを使用するアプリケーションは、唯一の共通セグメントに圧縮し、そのピアにような配信データを持っています。メッセージストリームインタフェースに、ACSE / ROSEは、アプリケーションにTCP上にISOトランスポートサービス[RFC1006]、[RFC2126]を使用します。

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.

最後に、それが書かれていたので、TCPは、現在進行中の研究開発の対象となっていることに注意してください。 TCP仕様書[RFC4614]のためのロードマップは、この歴史をキャプチャし、地域における現在および将来の開発者へのガイドであることを意図しています。

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のデザインは、適切な輻輳回避行動や洪水への耐性やなりすまし攻撃が含まれています。それはメッセージストリームインタフェースを使用するので、それはまた、メッセージインタフェースにTCPのオクテットストリームをオンにするRFC 2126分の1006を使用するよりも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 [RFC4340]は、輻輳制御信頼性のないデータグラムの双方向のユニキャスト接続を提供する「信頼できない」トランスポート・プロトコル(例えば、メッセージの配信を保証しないもの)です。 DCCPはデータのかなり大きな金額を転送し、それがタイムリーかつ信頼性の間のトレードオフを制御の恩恵を受けることができるアプリケーションに適しています。

DCCP implements a simple "cookie" mechanism intended to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer. Datagram Transport Layer Security [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, DCCP can run over IPsec.


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

ネットワーク管理および操作を容易にするために、インターネットコミュニティは、ドメインネームシステム(DNS)[RFC1034]、[RFC1035]を定義しています。名前は階層的です:example.comのような名前が.COMレジストラに登録された、および関連するネットワーク内baldur.cincinatti.example.comのような他の名前は明らかに階層で、定義することができます。レジストリは、それが含まれているので、その信憑性を実証行う際に、DNSセキュリティ拡張[RFC4033] [RFC4034] [RFC4035]で定義されたレコードに署名することを可能にするセキュリティ拡張機能、。

Devices can also optionally update their own DNS record. For example, a sensor that is using Stateless Address Autoconfiguration [RFC4862] to create an address might want to associate it with a name using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update [RFC3007].


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.

3.2.2で説明したように、IPv4アドレスの割り当ては、一般に、DHCP [RFC2131]を使用して実行されます。対照的に、セクション3.2.3は、IPv6アドレスの割り当てを自動[RFC4862]、[RFC4941]またはDHCPv6の[RFC3315]のいずれかを用いて達成することができることを指摘しています。自動設定を使用するための最良の引数には、アドレスとして乱数より少しを必要とするシステムの数が多いです。 DHCPのための引数は、管理制御です。

There are other parameters that may need to be allocated to hosts requiring administrative configuration; examples include the addresses of DNS servers, keys for Secure DNS, and Network Time servers.


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


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.

SNMPとNETCONF:IETFは、ネットワーク管理のための2つのプロトコルを開発しました。 SNMPは、セクション3.5.1で説明されており、NETCONFは、セクション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 Message Processing and Dispatching [RFC3412]


o SNMP Applications [RFC3413]


o User-based Security Model (USM) for SNMP version 3 [RFC3414]


o View-based Access Control Model (VACM) [RFC3415]


o Version 2 of the SNMP Protocol Operations [RFC3416]

SNMPプロトコル操作のOバージョン2 [RFC3416]

o Transport Mappings [RFC3417]


o Management Information Base (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 Using NETCONF over the Simple Object Access Protocol (SOAP) [RFC4743]


o Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) [RFC4744]


o NETCONF Event Notifications [RFC5277]

O NETCONFイベント通知[RFC5277]

o NETCONF over Transport Layer Security (TLS) [RFC5539]

トランスポート層セキュリティを超えるO NETCONF(TLS)[RFC5539]

o Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717]

NETCONF [RFC5717]のためのO分ロックリモートプロシージャコール(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].

一般的に、サービス発見は、マルチキャストDNS [マルチキャストDNS]およびDHCP(3.4.2項)を介してネットワークサービスの自動位置、DNSサービスディスカバリ(DNS-SD)を介して、ホスト名の解像度及び分布に関係して[DNS -SD](AppleのBonjourテクノロジーの一部)、およびサービスロケーションプロトコル(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 Commonly understood semantics


o Conformance to existing and emerging standards


o International scope and applicability


o Extensibility


o Interoperability among collections and indexing systems


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.

制約アプリケーションプロトコル(CoAP)[COAP]は、念頭に置いて、これらの目標にIETFで開発されています。特に、CoAPは、制約されたリソースのネットワークでの使用のためにと、スマートエネルギー、ビル・オートメーションなどのマシン・ツー・マシンアプリケーション用に設計されています。これは、RESTfulな転送プロトコル[安らか]、内蔵リソースディスカバリプロトコルを提供し、そのようなURIとコンテンツタイプとしてウェブの概念を含みます。 CoAPは、ユニキャストとマルチキャストの両方のリソース発見を提供し、リソース記述の属性をフィルタする能力を含みます。最後に、CoAP資源の発見はまた、HTTPリソースを発見するために使用することができます。

For simplicity, CoAP makes the assumption that all CoAP servers listen on the default CoAP port or otherwise have been configured or discovered using some general service discovery mechanism such as DNS Service Discovery (DNS-SD) [DNS-SD].


Resource discovery in CoAP is accomplished through the use of well-known resources that describe the links offered by a CoAP server. CoAP defines a well-known URI for discovery: "/.well-known/r" [RFC5785]. For example, the query [GET /.well-known/r] returns a list of links (representing resources) available from the queried CoAP server. A query such as [GET /.well-known/r?n=Voltage] returns the resources with the name Voltage.

CoAPでのリソースの発見は、CoAPサーバによって提供されるリンクを記述し、よく知られたリソースを使用することにより達成されます。 "/.well-known/r" [RFC5785]:CoAPは発見のための周知のURIを定義します。例えば、クエリは、[GET /.well-known/r]は照会CoAPサーバから利用可能なリンク(リソースを表す)のリストを返します。こうした[GET /.well-known/r?n=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.

セッション開始プロトコル[RFC3261]、[RFC3265]、[RFC3853]、[RFC4320]、[RFC4916]、[RFC5393]、[RFC5621]は、作成、変更、およびインターネット上のマルチメディアセッションを終了するためのアプリケーション層制御(シグナリング)プロトコルであり、意味されますH.323よりスケーラブルになるように。マルチメディアセッションは、音声、ビデオ、インスタントメッセージング、共有データ、および/またはイベントのサブスクリプションすることができます。 SIPは、TCP上のTCP、UDP、SCTP、またはTLSの上で実行することができます。 SIPは、トランスポート層から独立して、およびその下のIPv4 / v6のバージョンとは無関係です。実際には、SIPメッセージのように変更することができる使用されるトランスポートプロトコルは、ソースから宛先へのSIPエンティティを横切ります。

SIP itself does not choose whether a session is voice or video, nor does it identify the actual endpoints' IP addresses. The Session Description Protocol (SDP) [RFC4566] is intended for those purposes. Within the SDP, which is transported by SIP, codecs are offered and accepted (or not), and the port number and IP address at which each endpoint wants to receive their Real-time Transport Protocol (RTP) [RFC3550] packets are determined. The introduction of Network Address Translation (NAT) technology into the profile, whether IPv4/

SIP自体は、セッションは音声またはビデオであるかどうかを選択しません。また、実際のエンドポイントのIPアドレスを特定しません。セッション記述プロトコル(SDP)[RFC4566]は、これらの目的のために意図されています。 SIPによって輸送されるSDP内に、コーデックが提供され、受け入れられた(又はしない)、および各エンドポイントは、それらのリアルタイムトランスポートプロトコル(RTP)[RFC3550]パケットが決定される受信したいポート番号とIPアドレスされています。プロファイルへのネットワークアドレス変換(NAT)技術の導入、IPv4のか/

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

IPv4のはIPv4 / IPv6などは、セクション3.2.1.3に記載され、またはIPv6 / IPv6は、SIP / SDP配備の複雑さを増大させます。これはさらに、[RFC2993]及び[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)[RFC6120]は、任意の2つのネットワークエンドポイントとの間でリアルタイムに近い構造化情報を交換するために、拡張マークアップ言語(XML)要素をストリーミングするためのプロトコルです。 XMPPは、XMLデータを交換するための一般化された、拡張可能なフレームワークを提供するので、組み込みデバイスとセンサの間の交換のためのアプリケーション構造として提案されています。現在では、インスタントメッセージングとプレゼンス[RFC6121]とリアルタイムの通信モードのさまざまな使用されます。これらは、マルチユーザーチャット、パブリッシュ・サブスクライブ、アラートと通知、サービスの発見、マルチメディアセッション管理、デバイス構成、およびリモート・プロシージャ・コールが含まれます。 XMPPはSASL [RFC4422]を使用してTLS [RFC5246]と(PKIX証明書の認証を含む)強力な認証を使用して、チャネルの暗号化をサポートしています。また、ユニコード対応のアドレスと国際化のためのUTF-8 [RFC3629]のデータ交換を利用します。

XMPP allows for End-to-End Signing and Object Encryption [RFC3923], access to objects named using Uniform Resource Names (URN) [RFC4854], use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) [RFC5122], and the presentation of Notifications [RFC5437].

XMPPは、エンド・ツー・エンドの署名とオブジェクトの暗号化が可能になります[RFC3923]、統一リソース名(URN)[RFC4854]を使用して、指定されたオブジェクトへのアクセス、国際資源識別子(IRIを)とURI(Uniform Resource Identifier)の使用[RFC5122]そして、通知[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].

アップルのiCal、Microsoft OutlookおよびEntourageの、とGoogleカレンダーで実装されているインターネットカレンダー、インターネットカレンダーとスケジュールのコアオブジェクト仕様(iCalendar形式)[RFC5545]で指定し、iCalendar形式のXML表現のXMLスキーマに更新されている処理中です【XCAL]。いくつかのプロトコルは、iCalendarのトランスポートに依存しない相互運用プロトコル(のiTIP)[RFC5546]、iCalendarのメッセージベースの相互運用プロトコル(iMIPの)[RFC6047]、およびAtom出版プロトコル[RFC5023]にオープンソースの作業を含むカレンダーイベントを実行するために存在します。

4. A Simplified View of the Business Architecture
ビジネス・アーキテクチャの4 A簡略図

The Internet is a network of networks in which networks are interconnected in specific ways and are independently operated. It is important to note that the underlying Internet architecture puts no restrictions on the ways that networks are interconnected; interconnection is a business decision. As such, the Internet interconnection architecture can be thought of as a "business structure" for the Internet.


Central to the Internet business structure are the networks that provide connectivity to other networks, called "transit networks". These networks sell bulk bandwidth and routing services to each other and to other networks as customers. Around the periphery of the transit network are companies, schools, and other networks that provide services directly to individuals. These might generally be divided into "enterprise networks" and "access networks"; enterprise networks provide "free" connectivity to their own employees or members, and also provide them a set of services including electronic mail, web services, and so on. Access networks sell broadband connectivity (DSL, Cable Modem, 802.11 wireless, or 3GPP wireless) or "dial" services (including PSTN dial-up and ISDN) to subscribers. The subscribers are typically either residential or small office/home office (SOHO) customers. Residential customers are generally entirely dependent on their access provider for all services, while a SOHO buys some services from the access provider and may provide others for itself. Networks that sell transit services to nobody else -- SOHO, residential, and enterprise networks -- are generally refereed to as "edge networks"; transit networks are considered to be part of the "core" of the Internet, and access networks are between the two. This general structure is depicted in Figure 3.

インターネットビジネスの構造の中心は「トランジット・ネットワーク」と呼ばれ、他のネットワークへの接続を提供ネットワークです。これらのネットワークは、相互に顧客のような他のネットワークに大量の帯域幅とルーティングサービスを販売します。トランジットネットワークの周囲に直接個人にサービスを提供する企業、学校、およびその他のネットワークがあります。これらは一般的に「企業ネットワーク」と「アクセスネットワーク」に分けることがあります。エンタープライズネットワークは、自分の従業員やメンバーへの「フリー」の接続性を提供し、またそれらにように、電子メール、Webサービスなどを含む一連のサービスを提供しています。アクセスネットワークは、加入者にブロードバンド接続(DSL、ケーブルモデム、802.11無線、または3GPPワイヤレス)または(PSTNダイヤルアップやISDN含む)「ダイヤル」サービスを販売します。加入者は、通常、住宅や小規模オフィス/ホームオフィス(SOHO)顧客のどちらかです。 SOHOは、アクセスプロバイダからいくつかのサービスを購入し、自分自身のために他人を提供することができる一方で住宅の顧客は、一般的に、すべてのサービスのためのアクセス・プロバイダーに完全に依存しています。他の誰にもトランジットサービスを販売ネットワーク - SOHO、住宅、および企業ネットワークは、 - 一般に「エッジ・ネットワーク」と審判されています。トランジットネットワークは、インターネットの「コア」の一部とみなされ、アクセスネットワークは、両者の間にされています。この一般的な構造を図3に示されています。

                            ------                  ------
                           /      \                /      \
                 /--\     /        \              /        \
                |SOHO|---+  Access  |            |Enterprise|
                 \--/    |  Service |            | Network  |
                 /--\    |  Provider|            |          |
                |Home|---+          |   ------   |          |
                 \--/     \        +---+      +---+        /
                           \      /   /        \   \      /
                            ------   | Transit  |   ------
                                     | Service  |
                                     | Provider |
                                     |          |
                                      \        /
                                       \      /

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 Cox Communications, an access network using Cable Modem technology,


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


<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:>フレッド%のtraceroute www.ucsb.eduトレースルートに、64のホップマックス、40のバイトパケット1フレッド-VPN( MS 1.108ミリ1.133ミリ2ミリ... 3 ... 4 ... 5 langbbr01- ... 6 ... 7 ... 8 DC-lax- ... 9 ... 10 ... 11 ... 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.


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

ファイアウォールのパフォーマンスのためのベンチマーク用語[RFC2647] O

o Behavior of and Requirements for Internet Firewalls [RFC2979]


o Benchmarking Methodology for Firewall Performance [RFC3511]

ファイアウォールのパフォーマンスのためのベンチマーク方法論[RFC3511] O

o Mobile IPv6 and Firewalls: Problem Statement [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:

ネットワークアドレス変換は、1990年代半ばにおけるISPの行動に応じて開発された技術です。 [RFC1918]が出版されたとき、多くのISPは、アドレスの単一または少数を配って開始し、エッジネットワークを変換するために余儀なくされました。時間では、これは良いことだと考えられ、あるいは悪いことではありません少なくともになりました。それは公共のアドレス空間を増幅し、そしてそれは、ファイアウォールであるかのようにそれが販売されていました。当然のことではありません。従来の動的NATのが唯一のセッションの検出期間中、内部および外部のセッションアドレス/ポートの組の間で翻訳しながら、そのセッション状態ははるかに長く、それがエンド・システム上に存在するよりも、ネットワーク内に存在し、その結果、攻撃ベクトルを構成してもよいです。デザイン、値、およびネットワークアドレス変換の制限はで説明されています。

o IP Network Address Translator Terminology and Considerations [RFC2663]

O IPネットワークアドレス変換用語と考慮事項[RFC2663]

o Traditional IP Network Address Translator [RFC3022]


o Protocol Complications with the IP Network Address Translator [RFC3027]


o Network Address Translator Friendly Application Design Guidelines [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 State of Peer-to-Peer Communication across Network Address Translators [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インIPまたはGREトンネル、MPLSのLSP [RFC3031]、[RFC3032]を含みます。

5. Security Considerations

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


6. Acknowledgements

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.1. Normative References
7.1. 引用規格

[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。

[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.

[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。

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

[RFC4294] Loughney、J.、 "IPv6のノードの要件"、RFC 4294、2006年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.

[6LOWPAN-HC]ホイ、J.とP. Thubert、 "低消費電力とロッシーネットワークにおけるIPv6のデータグラムのための圧縮フォーマット(6LoWPAN)"、進歩、2011年2月での作業。

[ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, March 2011.

[ABFAB-ARCH]ハウレット、J.、ハルトマン、S.、Tschofenig、H.、およびE.リア、進歩、2011年3月ワーク "アプリケーションは、フェデレーションアクセスを越えてウェブ(ABFAB)アーキテクチャのためのブリッジング"。

[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]マグリュー、D.、ベイリー、D.、カンパーニャ、M.、およびR. Dugal、 "TLSのためのAES-CCM ECC暗号スイート"、進歩、2011年1月での作業。

[COAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", Work in Progress, March 2011.

[COAP]シェルビー、Z.、HARTKE、K.、ボルマン、C.、およびB.フランク、 "制約アプリケーションプロトコル(CoAP)"、進歩、2011年3月に作業。

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

[DIME-BASE]ファハルド、V.、編、Arkko、J.、Loughney、J.、およびG.ゾルン、 "直径ベースプロトコル"、進歩、2011年1月に働いています。

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

[DNS-SD]チェシャー、S.とM. Krochmal、 "DNSベースのサービス発見"、進歩、2011年2月での作業。

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

[DTLS]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティバージョン1.2"、進歩、2011年3月に作業。

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

[DYMO] Chakeres、I.およびC.パーキンス、 "ダイナミックMANETオンデマンド(DYMO)ルーティング"、進歩、2010年7月での作業。

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

[IEC61850]ウィキペディア、 "ウィキペディアの記事:IEC 61850"、2011年6月、< index.phpのタイトル= IEC_61850&oldid = 433437827?>。

[IEC62351-3] International Electrotechnical Commission Technical Committee 57, "POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE. DATA AND COMMUNICATIONS SECURITY -- Part 3: Communication network and system security Profiles including TCP/IP", May 2007.

[IEC62351-3]国際電気技術委員会57、「POWERのシステム管理と関連情報Exchangeデータや通信セキュリティ - 第3部:TCP / IPなどの通信ネットワークとシステムのセキュリティプロファイル」、2007年5月。

[IEEE802.1X] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks - Port based Network Access Control", IEEE Standard 802.1X-2010, February 2010.

[IEEE802.1X]電気電子学会、「地方とメトロポリタンエリアネットワークのIEEE標準 - ポートベースのネットワークアクセスコントロール」、IEEE標準802.1X-2010、2010年2月。

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

[IP-SEC] Gont、F.、 "インターネットプロトコルバージョン4のセキュリティ評価"、進歩、2011年4月の作業。

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

[IPv6の-NODE-REQ] Jankiewicz、E.、Loughney、J.、およびT. Narten氏、 "IPv6のノード要件"、進歩、2011年5月に働いています。

[MULTICAST-DNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, February 2011.

[マルチキャストDNS]チェシャー、S.とM. Krochmal、 "マルチキャスト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 /パブ/スマートグリッド/ SGIPConceptualModelDevelopmentSGAC / Smart_Grid_Conceptual_Model_20100420.doc"。

[OAUTHv2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Authorization Protocol", Work in Progress, May 2011.

[OAUTHv2]ハンマー - Lahav、E.、Recordon、D.、およびD.ハルト、 "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]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。

[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.

[RFC0792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 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]プラマー、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]ローズ、M.とD.キャス、 "TCPの上のISO輸送サービス:バージョン3"、STD 35、RFC 1006、1987年5月。

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。

[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.

[RFC1058]ヘドリック、C.、​​ "ルーティング情報プロトコル"、RFC 1058、1988年6月。

[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.

[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.

[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。

[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.

[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル(IPCP)"、RFC 1332、1992年5月。

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

[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル(PPP)"、STD 51、RFC 1661、1994年7月。

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。

[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.

[RFC1964]リン、J.、 "Kerberosバージョン5 GSS-APIメカニズム"、RFC 1964、1996年6月。

[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.

[RFC2080]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。

[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top of TCP (ITOT)", RFC 2126, March 1997.

"TCPの上にISOトランスポートサービス(ITOT)" [RFC2126] Pouffary、Y.およびA.ヤング、RFC 2126、1997年3月。

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.

[RFC2136]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新(DNS更新)"、RFC 2136、1997年4月。

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[RFC2328]モイ、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]マンキン、A.、ロマノフ、A.、RFC 2357、1998年6月ブラドナーの、S.、およびV.パクソン、 "信頼性の高いマルチキャストトランスポートとアプリケーションプロトコルを評価するためのIETF基準"。

[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.

[RFC2453]マルキン、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]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6(IPv6)の仕様"、RFC 2460、1998年12月。

[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.

[RFC2464]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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]ブレイク、S.、ブラ​​ック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年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.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット(PPPoEを)送信するための方法"、RFC 2516年2月1999。

[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.

[RFC2545]マルケス、P.およびF.デュポン、RFC 2545 "IPv6のドメイン間ルーティングのためのBGP-4マルチプロトコル拡張機能の使用"、1999年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]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。

[RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999.

[RFC2588]フィンレイソン、R.、 "IPマルチキャストとファイアウォール"、RFC 2588、1999年5月。

[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.

[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.、およびM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。

[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.

[RFC2615] Malis、A.とW.シンプソン、 "SONET / SDH上のPPP"、RFC 2615、1999年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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。

[RFC2647] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, August 1999.

[RFC2647]ニューマン、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.ホールドレッジ、 "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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見(MLD)"、RFC 2710、1999年10月。

[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.

[RFC2743]リン、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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化(GRE)"、RFC 2784、2000年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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス(RADIUS)でリモート認証ダイヤル"。

[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]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。

[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.

[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム(DNS)動的更新をセキュア"。

[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]ホールドレッジ、M.とP. Srisuresh、RFC 3027、2001年1月 "IPネットワークアドレス変換とプロトコル合併症"。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "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.

"IPに明示的輻輳通知の添加(ECN)" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。

[RFC3235] Senie, D., "Network Address Translator (NAT)- Friendly Application Design Guidelines", RFC 3235, January 2002.

[RFC3235] Senie、D.、 "ネットワークアドレス変換(NAT) - フレンドリーなアプリケーション設計ガイドライン"、RFC 3235、2002年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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、RFC 3261、2002年6月。

[RFC3265] Roach, A., "Session Initiation Protocol (SIP)- Specific Event Notification", RFC 3265, June 2002.

[RFC3265]ローチ、A.、 "セッション開始プロトコル(SIP) - 特定のイベント通知"、RFC 3265、2002年6月。

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

[RFC3275]イーストレーク、D.、Reagle、J.、およびD.ソロ "(拡張マークアップ言語)、XML署名の構文および処理"、RFC 3275、2002年3月。

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル(DHCPv6)"、RFC 3315、2003年7月。

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.

[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]ハリントン、D.、Presuhn、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]ケース、J.、ハリントン、D.、Presuhn、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]レビ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコル(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.

、STD 62、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル(SNMPv3の)のバージョン3のためのユーザベースセキュリティモデル(USM)" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。

[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、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル(VACM)(SNMP)"、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] Presuhn、R.、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル(SNMP)のためのプロトコル操作のバージョン2"。

[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.

[RFC3417] Presuhn、R.、 "簡易ネットワーク管理プロトコルのためのマッピングを輸送します(SNMP)"、STD 62、RFC 3417、2002年12月。

[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.

、STD 62、RFC 3418、2002年12月 "簡易ネットワーク管理プロトコル(SNMP)管理情報ベース(MIB)" [RFC3418] Presuhn、R.、。

[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.

、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項(UNSAF)" [RFC3424] Daigle氏、L.とIAB、。

[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.

[RFC3436] Jungmaier、A.、レスコラ、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]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正(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]ヒックマン、B.、ニューマン、D.、Tadjudin、S.、およびT.マーティン、 "ファイアウォールのパフォーマンスのためのベンチマーク方法論"、RFC 3511、2003年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.、フレデリック、R.、およびV.ヤコブソン、 "RTP:リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。

[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.

[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。

[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.

[RFC3561]パーキンス、C.、ベルディング・ロイヤー、E.、およびS.ダス、 "アドホックオンデマンド距離ベクトル(AODV)ルーティング"、RFC 3561、2003年7月。

[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.

[RFC3569]バッタチャリヤ、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]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]ハーバーマン、B.、 "Multicast Listener Discovery(MLD)プロトコルのためのソースアドレス選択"、RFC 3590、2003年9月。

[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.

[RFC3626]クラウゼン、T.およびP.ジャケ、 "最適化されたリンクステートルーティングプロトコル(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.ディクソン、 "IPsecでネットワークアドレス変換(NAT)の互換性の要件"、RFC 3715、2004年3月。

[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

"IPv6のマルチキャストリスナ発見バージョン2(MLDv2の)" [RFC3810]ヴィーダ、R.とL.コスタ、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.、ピンク、S.、ヨンソン、L-E。、およびG. Fairhurst、 "軽量ユーザーデータグラムプロトコル(UDP-Liteの)"、RFC 3828、2004年7月。

[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.

[RFC3853]ピーターソン、J.、 "S / MIMEのAdvanced Encryption Standard(AES)セッション開始プロトコル(SIP)のための要件"、RFC 3853、2004年7月。

[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923, October 2004.

[RFC3923]サンアンドレ、P.、「エンド・ツー・エンドの拡張メッセージングおよびプレゼンスプロトコル(XMPP)のための署名とオブジェクトの暗号化」、RFC 3923、2004年10月に。

[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索(SEND)"、RFC 3971、2005年3月。

[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.

[RFC3973]アダムス、A.、ニコラス、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]スタンレー、D.、ウォーカー、J.、およびB. Aboba、 "無線LANのための拡張認証プロトコル(EAP)メソッド要件"、RFC 4017、2005年3月。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。

[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.

[RFC4108] Housley氏、R.、 "ファームウェアパッケージを保護するために暗号メッセージ構文(CMS)の使用"、RFC 4108、2005年8月。

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.

[RFC4120]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス(V5)"、RFC 4120、2005年7月。

[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.

[RFC4121]朱、L.、Jaganathan、K.、およびS.ハートマン、 "Kerberosバージョン5の汎用セキュリティサービスアプリケーションプログラムインタフェース(GSS-API)メカニズム:バージョン2"、RFC 4121、2005年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]アダムス、C.、ファレル、S.、Kause、T.、およびT. Mononen、 "インターネットX.509公開鍵基盤証明書管理プロトコル(CMP)"、RFC 4210、2005年9月。

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.

[RFC4213] Nordmarkと、E.とR.ギリガン、 "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.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4(BGP-4)"、RFC 4271、2006年1月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[RFC4303]ケント、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]シラー、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]スパークス、R.、RFC 4320、2006年1月 "セッション開始プロトコル(SIP)非INVITEトランザクションと特定された問題への対処アクション"。

[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル(DCCP)"、RFC 4340、2006年3月。

[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.

[RFC4347]レスコラ、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]ローゼン、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]プーレン、M.、趙、F.、およびD.コーエン、 "選択的信頼性の高いマルチキャストプロトコル(SRMP)"、RFC 4410、2006年2月。

[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.

[RFC4422]メルニコフ、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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン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]ル、F.、Faccin、S.、パティル、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]ブレイク・ウィルソン、S.、Bolyard、N.、グプタ、V.、ホーク、C.、​​およびB.メラー、 "楕円曲線暗号(ECC)暗号スイートトランスポート層セキュリティ(TLS)のための"、RFC 4492 、2006年5月。

[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

"ケルベロス(PKINIT)における初期認証のための公開鍵暗号" [RFC4556]朱、L.とB.桐、RFC 4556、2006年6月。

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP:セッション記述プロトコル"、RFC 4566、2006年7月。

[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.

[RFC4594] Babiarz、J.、チャン、K.、およびF.ベイカー、 "DiffServのサービスクラスの設定時の注意事項"、RFC 4594、2006年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]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード(PIM-SM):プロトコル仕様(改訂)"、RFC 4601、2006年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]ホルブルック、H.、カイン、B.、およびB.ハーバーマン、 "ソース固有マルチキャストのためにインターネットグループ管理プロトコルバージョン3(IGMPv3の)およびマルチキャストリスナ発見プロトコルバージョン2(MLDv2の)の使用"、RFC 4604、8月2006。

[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。

[RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006.

[RFC4608]マイヤー、D.、ロッケル、R.、およびG.シェパード、 "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]デューク、M.、ブレーデン、R.、エディ、W.、及びE.ブラントン、RFC 4614、2006年9月 "伝送制御プロトコル(TCP)仕様書のためのロードマップ"。

[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.

[RFC4741]エンス、R.、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。

[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.

[RFC4742]ワッサーマン、M.とT.ゴダード、 "セキュアシェル上でNETCONF構成プロトコルを使用して(SSH)"、RFC 4742、2006年12月。

[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.

[RFC4743]ゴダード、T.、RFC 4743、2006年12月 "簡易オブジェクトアクセスプロトコル(SOAP)の上にNETCONFを使用します"。

[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.

[RFC4744]リア、E.およびK.クロージャー、 "ブロック拡張可能交換プロトコル(BEEP)の上にNETCONFプロトコルの使用"、RFC 4744、2006年12月。

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、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.ジェニングス、 "ネットワークアドレス変換(NAT)ユニキャストUDPのための行動の要件"、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.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード(ESP)と認証ヘッダー(AH)のための暗号アルゴリズム実装要件"。

[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]サンアンドレ、P.、RFC 4854、2007年4月「拡張メッセージングおよびプレゼンスプロトコル(XMPP)への拡張のための統一リソース名(URN)名前空間」。

[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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6(IPv6)のための近隣探索"、RFC 4861、2007年9月。

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。

[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.

[RFC4916]エルウェル、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]クシャルナガル、N.、モンテネグロ、G.、およびC.シューマッハ、 "低消費電力無線パーソナルエリアネットワーク(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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年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.、クシャルナガル、N.、ホイ、J.、およびD. Culler、 "IEEE 802.15.4ネットワークの上のIPv6パケットの送信"、RFC 4944、2007年9月。

[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.

[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。

[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.

[RFC4987]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、RFC 4987、2007年8月。

[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007.

[RFC5023]グレゴリオ、J.とB.デ・ホラ、 "Atom出版プロトコル"、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]スチュワート、R.、謝、Q.、Tuexen、M.、丸山、S.、およびM.小塚、 "ストリーム制御伝送プロトコル(SCTP)動的アドレス再構成"、RFC 5061、2007年9月。

[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.

[RFC5072] Varada、S.、エド。、ハスキンズ、D.、およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 5072、2007年9月。

[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]サンアンドレ、P.、「国際化資源識別子(IRIを)および拡張メッセージングおよびプレゼンスプロトコル(XMPP)のためのユニフォームリソース識別子(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.、フォード、B.、およびD.ケーゲル、2008年3月、RFC 5128 "ネットワーク全体のピア・ツー・ピア(P2P)通信状態が翻訳器(NAT)のアドレス"。

[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]ウイング、D.とT.エッカート、BCP 135、RFC 5135、2008年2月、 "ネットワークアドレス変換(NAT)とネットワークアドレスポート翻訳(NAPT)のためのIPマルチキャストの要件"。

[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]フォースバーグ、D.、オオバ、Y.、パティル、B.、Tschofenig、H.、およびA. Yegin、RFC 5191、2008年5月 "ネットワークアクセス(PANA)の認証を搬送するプロトコル"。

[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.

[RFC5207] Stiemerling、M.、Quittek、J.、およびL.エッゲルト、 "NATおよびホスト識別プロトコル(HIP)コミュニケーションのファイアウォール越えの問題"、RFC 5207、2008年4月。

[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.

[RFC5216]サイモン、D.、Aboba、B.、およびR.ハースト、 "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]フェラン、T.、RFC 5238、2008年5月、 "データグラム輻輳制御プロトコル(DCCP)を超えるデータグラムトランスポート層セキュリティ(DTLS)"。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ(TLS)プロトコルバージョン1.2"、RFC 5246、2008年8月。

[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.

[RFC5272] Schaad、J.とM.マイヤーズ、 "CMSオーバー証明書の管理(CMC)"、RFC 5272、2008年6月。

[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.

[RFC5277]チザム、S.およびH.トレビノ、 "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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)のプロフィール」、RFC 5280、2008年5月。

[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008.

[RFC5289]レスコラ、E.、 "SHA-384分の256とTLS楕円曲線暗号スイートとAESガロア・カウンタ・モード(GCM)"、RFC 5289、2008年8月。

[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.

"IS-ISとルーティングのIPv6" [RFC5308] Hoppsが、C.、RFC 5308、2008年10月。

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.

[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年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]は、RFC 5393、2008年12月 "セッション開始プロトコル(SIP)フォーキングプロキシにおける増幅脆弱性への対処"、R.、ローレンス、S.、Hawrylyshen、A.およびB. Campenをスパーク。

[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.

[RFC5405]エッゲルト、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]ソルター、M.、レスコラ、E.、およびR. Housley氏、RFC 5430、2009年3月 "トランスポート層セキュリティ(TLS)のためのスイートBプロファイル"。

[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009.

[RFC5433]クランシー、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]サンアンドレ、P.およびA.メルニコフ、 "ふるい通知メカニズム:拡張メッセージングおよびプレゼンスプロトコル(XMPP)"、RFC 5437、2009年1月。

[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.

[RFC5539] Badra、M.、RFC 5539、2009年5月、 "トランスポート層セキュリティ(TLS)の上にNETCONF"。

[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.

[RFC5545] Desruisseaux、B.、 "インターネットカレンダーとスケジュールのコアオブジェクト仕様(iCalendar形式)"、RFC 5545、2009年9月。

[RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009.

[RFC5546] Daboo、C.、 "iCalendarのトランスポートに依存しない相互運用性プロトコル(のiTIP)"、RFC 5546、2009年12月。

[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.

[RFC5548]のDohler、M.、Watteyne、T.、冬、T.、およびD.バーセル、 "都市の低消費電力とロッシーネットワークのルーティング要件"、RFC 5548、2009年5月。

[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.

[RFC5569]デプレ、R.、 "IPv4の基盤のIPv6のRapid Deployment(6rd)"、RFC 5569、2010年1月。

[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009.

[RFC5621]キャマリロ、G.、RFC 5621 "メッセージ本文は、セッション開始プロトコル(SIP)で処理" を、2009年9月。

[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.

[RFC5626]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル(SIP)におけるクライアント開始された接続の管理"。

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.

[RFC5652] Housley氏、R.、 "暗号メッセージ構文(CMS)"、STD 70、RFC 5652、2009年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]ピスター教授、K.、Thubert、P.、Dwars、S.、およびT.フィニー、 "低消費電力とロッシーネットワークにおける産業ルーティング要件"、RFC 5673、2009年10月。

[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.

[RFC5681]オールマン、M.、パクソン、V.、およびE.ブラントン、 "TCP輻輳制御"、RFC 5681、2009年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 5717、2009年12月。

[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.

[RFC5740]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "NACK指向高信頼マルチキャスト(NORM)トランスポートプロトコル"、RFC 5740、2009年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.ターナー、 "/セキュア多目的インターネットメール拡張(S / MIME)バージョン3.2メッセージ仕様"、RFC 5751、2010年1月。

[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.

[RFC5785]ノッティンガム、M.とE.ハンマー - Lahav、 "既知のUniform Resource Identifier(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]ブラント、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.、ロイ、A.、バーンズ、M.、およびR.アガルワル、RFC 5838、2010年4月 "のOSPFv3におけるアドレスファミリのサポート"。

[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010.

[RFC5849]ハンマー - 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.、デ・ミル、P.、Riouの、N.、およびW. Vermeylen、 "低消費電力とロッシーネットワークにおけるビルオートメーションルーティング要件"、RFC 5867、2010年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]ミルズ、D.、マーティン、J.、バーバンク、J.、およびW. Kasch、 "ネットワークタイムプロトコルバージョン4:プロトコルとアルゴリズムの仕様"、RFC 5905、2010年6月。

[RFC5932] Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher Suites for TLS", RFC 5932, June 2010.

[RFC5932]加藤、A.、神田、M.、およびS.菅野、 "TLSの椿暗号スイート"、RFC 5932、2010年6月。

[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.

[RFC5958]ターナー、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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2(IKEv2の)"、RFC 5996、2010年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.シェファー、 "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]ターナー、S.とR. Housley氏、 "暗号メッセージ構文(CMS)対称鍵パッケージのコンテンツタイプ"、RFC 6031、2010年12月。

[RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, December 2010.

[RFC6047]メルニコフ、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]バオ、C.、のHuitema、C.、Bagnulo、M.、Boucadair、M.、およびX.李、RFC 6052、2010年10月の "IPv6は、IPv4 / IPv6の翻訳者のアドレス指定"。

[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.

[RFC6090]マグリュー、D.、Igoe、K.、およびM.ソルター、 "基礎楕円曲線暗号アルゴリズム"、RFC 6090、2011年2月。

[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.

[RFC6120]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル(XMPP):コア"、RFC 6120、2011年3月。

[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.

[RFC6121]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル(XMPP):インスタントメッセージングとプレゼンス"、RFC 6121、2011年3月。

[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC RFC6144, April 2011.

[RFC6144]、RFC RFC6144、2011年4月ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "のIPv4 / IPv6変換のためのフレームワーク"。

[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.

[RFC6145]のLi、X.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年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.、マシューズ、P.、およびI. Beijnum、 "ステートフルNAT64:IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、RFC 6146、2011年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.、サリバン、A.、マシューズ、P.、およびI. Beijnum、 "DNS64:IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNS拡張機能"、RFC 6147、2011年4月。

[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.

[RFC6180] Arkko、J.およびF.ベーカー、 "IPv6移行中のIPv6移行メカニズムを使用するためのガイドライン"、RFC 6180、2011年5月。

[RPL] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2011.

[RPL]冬、T.、Thubert、P.、ブラント、A.、Clausenの、T.、ホイ、J.、ケルシー、R.、リーバイス、P.、ピスター教授、K.、Struik、R.、およびJ 。Vasseur、「RPL:低消費電力とロッシーネットワークのためのIPv6ルーティングプロトコル」、進歩、2011年3月に作業。

[SP-MULPIv3.0] CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I10- 090529", May 2009.

[SP-MULPIv3.0] CableLabsの、 "DOCSIS 3.0 MAC上位層プロトコルインタフェース仕様、CM-SP-MULPIv3.0-I10- 090529"、2009年5月。

[SmartGrid] Wikipedia, "Wikipedia Article: Smart Grid", February 2011, < index.php?title=Smart_grid&oldid=415838933>.

[スマートグリッド]ウィキペディア、 "ウィキペディアの記事:スマートグリッド"、2011年2月、<? index.phpのタイトル= Smart_grid&oldid = 415838933>。

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

[TCP-SEC] Gont、F.、進歩、2011年1月の作業 "伝送制御プロトコル(TCP)のセキュリティ評価"。

[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]ボルトBeranekとニューマン株式会社、「インターフェイスメッセージプロセッサ - ホストの相互接続とIMPの仕様、レポートNo. 1822」、1976年1月。

[xCAL] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML format for iCalendar", Work in Progress, April 2011.

【XCAL] Daboo、C.、ダグラス、M.、およびS.リーズ "のxCal:iCalendar形式のXMLフォーマット"、進歩、2011年4月ワーク。

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

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:


* 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?


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


2. Appendix A.3 repeats the first example, but presuming that the utility directly accesses appliances within the HAN from the collector.


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.


A.1. How to Structure a Network


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

インターネットでの重要な検討事項は、時間の経過とともに、新たなリンク層技術の開発でした。 ARPANETはもともとBBN 1822 [r1822]と呼ばれる独自のBBNリンク層を使用しました。 1970年代後半には、ARPANETは1822ネットワークへのインタフェースとしてX.25に切り替えます。 1980年代初頭におけるIEEE 802シリーズの技術の展開では、IPは、イーサネット(IEEE 802.3)、トークンリング(IEEE 802.5)と無線LAN(IEEE 802.11)ならびにアークネット、様々な種類のシリアル回線、フレームリレー上で展開されました、およびATM。この進化の重要な問題は、アプリケーションがIPSに関連したインターネット利用のAPIで実行するために開発されたということでしたし、その結果、新しいリンク層アーキテクチャまたはそれらの混合物で動作し続けることをほとんど、あるいはまったく変更を必要とします。

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が含まれます。他の技術が将来開発されることを期待するのが妥当です。ジグビー・アライアンスは、学習している(および組み込まもたらしスマートエネルギー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        +----+-----+
                    \       /   ---

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のドメインを使用して一方が2つの単純なネットワークを示している、との一つは、家庭内の任意のLANを使用し、IEEE 802.3 /イーサネット(登録商標)である可能性があり、IEEE 802.15.4、IEEE 1901、IEEE 802.11 、またはコンテキストで意味をなさない何か。双方は、エネルギー管理システム(EMS)とは別のルータとして、それらの間の接続性を示します。これは明確にするためです。二人はもちろん、単一のシステムに組み込むことができ、かつ1は、そのメーカーはHANインターフェースと無線LANインターフェースの両方をサポートするのではなく、ルータに依存と通信したい機器を想像できます。これらはすべて、メーカーの設計上の決定です。

A.1.1. HAN Routing

A.1.1。 HANルーティング

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。 HANセキュリティ

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/

リンク層:なぜあなたのマシンは、私のネットワークに話をすることができますか?無線LANのSSIDは、多くの場合、単純な暗号化されたパスワードメカニズムであってもよいし、暗号化とIEEE 802.1X + EAP-TLS認証を組み合わせて使用​​することがある、認証されたアクセス制御のいくつかのフォームを使用します/

Authorization to ensure that only authorized communicants can use it. If a LAN has a router attached, the router may also implement a firewall to filter remote accesses.

承認は唯一認可のコミュニはそれを使用できることを確認します。 LANルータ接続されている場合、ルータは、リモートアクセスをフィルタリングするために、ファイアウォールを実装することができます。

Network Layer: Given that your machine is authorized access to my network, why is your machine talking with my machine? IPsec is a way of ensuring that computers that can use a network are allowed to talk with each other, may also enforce confidentiality, and may provide VPN services to make a device or network appear to be part of a remote network.

ネットワーク層:あなたのマシンが私のネットワークへのアクセスを許可されていることを考えると、なぜあなたのマシンは、私のマシンと話していますか? IPsecは、ネットワークを使用することができるコンピュータがお互いに話をすることが許可されていることを保証する方法でも、機密性を強制することができ、デバイスまたはネットワークがリモートネットワークの一部であることを表示させるためにVPNサービスを提供することができます。

Application: Given that your machine is authorized access to my network and my machine, why is your application talking with my application? The fact that your machine and mine are allowed to talk for some applications doesn't mean they are allowed to for all applications. (D)TLS, https, and other such mechanisms enable an application to impose application-to-application controls similar to the network layer controls provided by IPsec.

アプリケーション:あなたのマシンが私のネットワークと私のマシンへのアクセスが許可されていることを考えると、なぜあなたのアプリケーションが自分のアプリケーションと話していますか?お使いのマシンと私はいくつかのアプリケーションのために話すことを許可されているという事実は、彼らはすべてのアプリケーションのために許可されているわけではありません。 (D)TLS、HTTPS、および他のこのような機構は、IPsecによって提供されるネットワーク層コントロールと同様アプリケーション間の制御を課すためのアプリケーションを可能にします。

Remote Application: How do I know that the data I received is the data you sent? Especially in applications like electronic mail, where data passes through a number of intermediaries that one may or may not really want munging it (how many times have you seen a URL broken by a mail server?), we have tools (DKIM, S/MIME, and W3C XML Signatures to name a few) to provide non-repudiability and integrity verification. This may also have legal ramifications: if a record of a meter reading is to be used in billing, and the bill is disputed in court, one could imagine the court wanting proof that the record in fact came from that meter at that time and contained that data.

リモートアプリケーション:どのように私は私が受け取ったデータを使用して、送信されたデータであることを知っていますか?特に、データが1つのまたは実際にそれをいじるたくないかもしれ仲介の数を通過する電子メール、などのアプリケーションに(何回すると、メールサーバーによって壊れたURLを見ている?)、私たちは、ツール(DKIM、Sを/持っていますMIME、およびW3C XML署名は)数名に非repudiabilityと整合性の検証を提供します。また、これは法的な問題を有していてもよい:検針のレコードは、課金に使用されるべきである、と法案が法廷で争われている場合、1は、裁判所は、実際にレコードがその時点でそのメートルから来たことを証明したいとして含まれている想像できますそのデータ。

Application-specific security: In addition, applications often provide security services of their own. The fact that I can access a file system, for example, doesn't mean that I am authorized to access everything in it; the file system may well prevent my access to some of its contents. Routing protocols like BGP are obsessed with the question "what statements that my peer made am I willing to believe", and monitoring protocols like SNMP may not be willing to answer every question they are asked, depending on access configuration.

アプリケーション固有のセキュリティは:また、アプリケーションは、多くの場合、独自のセキュリティサービスを提供しています。私は、ファイルシステムにアクセスできるという事実は、例えば、私はそれにすべてのものにアクセスすることを許可していますという意味ではありません。ファイルシステムはよく、その内容の一部に私のアクセスを防ぐことができます。 BGPなどのルーティングプロトコルは、「私の仲間が作った文が信じて、私は喜んで何を」という質問に取りつかれている、およびSNMPなどのプロトコルを監視するアクセス設定に応じて、それらが聞かれ、すべての質問に答えることをいとわないかもしれません。

Devices in the HAN want controlled access to the LAN in question for obvious reasons. In addition, there should be some form of mutual authentication between devices -- the lamp controller will want to know that the light switch telling it to change state is the right light switch, for example. The EMS may well want strong authentication of accesses -- the parents may not want the children 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.

HAN内のデバイスは、明白な理由のために問題のLANへのアクセスを制御します。また、デバイス間の相互認証のいくつかのフォームがあるべき - ランプコントローラが状態を変更するためにそれを伝える光スイッチは、例えば、右の光スイッチであることを知ることになるでしょう。 EMSはよくアクセスの強力な認証をすることができ - 親は、子どもたちが、設定を変更したくないかもしれない、とユーティリティと顧客が定期的にアクセスを許可している間、他の当事者(犯意と特に関係者)が除外される必要があります。

A.2. Model 1: AMI with Separated Domains


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.

図7に示すように、この場合には、それはNANのホストとしてコレクタ、メーター、およびEMSを設計することが最も理にかなって - 起源とNANに交換またはセッションを終了することができ、そのアプリケーションシステムとして設計しますしかし、他のデバイスからかにトラフィックを転送しません。

In such a configuration, Demand Response has to be performed by having the EMS accept messages such as price signals from the "pole top", apply some form of policy, and then orchestrate actions within the home. Another possibility is to have the EMS communicate with the ESI located in the meter. If the thermostat has high demand and low demand (day/night or morning/day/evening/night) settings, Demand Response might result in it moving to a lower demand setting, and the EMS might also turn off specified circuits in the home to diminish lighting.


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 QoSを提供するために、適切なNANサービスを使用する必要があります。 WiMAXは使用されている場合、それは通常の交換のためのルーチンレベルのサービスが、これらのメッセージの優先順位の高いサービスを使用する場合があります。

A.3. Model 2: AMI with Neighborhood Access to the Home


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.

この第2のモデルでは、のは、ユーティリティが直接HAN内の機器にアクセスすることを想像してみましょう。 EMSは、デマンドレスポンスで価格シグナルに応答することを期待するのではなく、それが直接の状態を変更するためにエアコンのようなデバイスをコマンド、またはにまたは家庭内の回路上のリレーをスローします。

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

1想像の通り、このモデルでは、重大なセキュリティ上の考慮事項があります。 NANと家庭用ブロードバンドネットワーク間のトラフィックをフィルタリングする必要がある、との付録A.1.2に提起された問題は、意味の新しいレベルに取ります。最大の脅威の一つは、法的または少なくとも広報の問題がある可能性があります。ユーティリティは故意的にまたは生命を脅かす時に回路を無効にした場合(居住者の腎臓透析機は、その上にある、または、例えば人工呼吸器は、)、問題は論文を作るかもしれません。不正アクセスは、同様に、若年いたずらや他のものの一部である可能性があります。だから、1は本当に唯一の厳格な認証/認可制御の下でコマンドに従うようにアプライアンスを望んでいます。

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


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.

付録A.3と同様に、このモデルでは、重大なセキュリティ上の考慮事項があります。転送されるトラフィックはフィルタリングされなければならない、と付録A.1.2に提起された問題は、意味の新しいレベルに取る - ユーティリティのメインフレームではなく、この時間。不正アクセスはインターネットで起こる他の財政的・意欲的な攻撃に可能性が似ていますが、おそらく何らかの方法で共同オプトインされているHAN内のデバイスから来ることになります。一つは、実際には、厳密な認証/認可制御の下でコマンドに従うようにアプライアンスを望んでいます。

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

フレッドベイカーシスコシステムズサンタバーバラ、カリフォルニア93117 USA



David Meyer Cisco Systems Eugene, Oregon 97403 USA

デビッド・マイヤーシスコシステムズユージン、オレゴン州97403 USA