[要約] RFC 6272は、スマートグリッドのためのインターネットプロトコルに関する規格です。このRFCの目的は、スマートグリッドの通信と制御におけるインターネットプロトコルの使用を促進することです。
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
スマートグリッド用のインターネットプロトコル
Abstract
概要
This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here.
このメモは、スマートグリッドで使用するインターネットプロトコルスイートの主要なインフラストラクチャプロトコルを識別します。ターゲットオーディエンスは、スマートグリッド用の適切なインターネットプロトコルスイートプロファイルを構築する方法に関するガイダンスを求めている人々です。実際には、このようなプロファイルは、ここに示されている写真からスマートグリッドの展開に必要なものを選択することで構成されます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6272.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6272で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 6
2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 6
2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 9
2.1.3.2. Lower-Layer Networks . . . . . . . . . . . . . . . 9
2.1.4. Media Layers: Physical and Link . . . . . . . . . . . 9
2.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Physical and Data Link Layer Security . . . . . . . . 10
2.2.2. Network, Transport, and Application Layer Security . . 11
2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 13
2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 13
2.3.2. Network Management . . . . . . . . . . . . . . . . . . 13
3. Specific Protocols . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Security Toolbox . . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Authentication, Authorization, and Accounting (AAA) . 14
3.1.2. Network Layer Security . . . . . . . . . . . . . . . . 15
3.1.3. Transport Layer Security . . . . . . . . . . . . . . . 16
3.1.4. Application Layer Security . . . . . . . . . . . . . . 17
3.1.5. Secure Shell . . . . . . . . . . . . . . . . . . . . . 18
3.1.6. Key Management Infrastructures . . . . . . . . . . . . 18
3.1.6.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.6.2. Kerberos . . . . . . . . . . . . . . . . . . . . . 19
3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19
3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 19
3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 20
3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 20
3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 21
3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 22
3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 22
3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 22
3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 23
3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 23
3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 24
3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 24
3.2.4.1. Routing Information Protocol . . . . . . . . . . . 24
3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 24
3.2.4.3. ISO Intermediate System to Intermediate System . . 25
3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 25
3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing . . . . . . 25
3.2.4.6. Optimized Link State Routing Protocol . . . . . . 26
3.2.4.7. Routing for Low-Power and Lossy Networks . . . . . 26
3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 27
3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 27
3.2.6. Adaptation to Lower-Layer Networks and Link Layer
Protocols . . . . . . . . . . . . . . . . . . . . . . 28
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 28
3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 29
3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 29
3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 30
3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 30
3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 31
3.4.3. Network Time . . . . . . . . . . . . . . . . . . . . . 31
3.5. Network Management . . . . . . . . . . . . . . . . . . . . 31
3.5.1. Simple Network Management Protocol (SNMP) . . . . . . 31
3.5.2. Network Configuration (NETCONF) Protocol . . . . . . . 32
3.6. Service and Resource Discovery . . . . . . . . . . . . . . 33
3.6.1. Service Discovery . . . . . . . . . . . . . . . . . . 33
3.6.2. Resource Discovery . . . . . . . . . . . . . . . . . . 33
3.7. Other Applications . . . . . . . . . . . . . . . . . . . . 34
3.7.1. Session Initiation Protocol . . . . . . . . . . . . . 34
3.7.2. Extensible Messaging and Presence Protocol . . . . . . 35
3.7.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 35
4. A Simplified View of the Business Architecture . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Normative References . . . . . . . . . . . . . . . . . . . 40
7.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Example: Advanced Metering Infrastructure . . . . . . 58
A.1. How to Structure a Network . . . . . . . . . . . . . . . . 59
A.1.1. HAN Routing . . . . . . . . . . . . . . . . . . . . . 62
A.1.2. HAN Security . . . . . . . . . . . . . . . . . . . . . 62
A.2. Model 1: AMI with Separated Domains . . . . . . . . . . . 64
A.3. Model 2: AMI with Neighborhood Access to the Home . . . . 65
A.4. Model 3: Collector Is an IP Router . . . . . . . . . . . . 66
This document provides Smart Grid designers with advice on how to best "profile" the Internet Protocol Suite (IPS) for use in Smart Grids. It provides an overview of the IPS and the key infrastructure protocols that are critical in integrating Smart Grid devices into an IP-based infrastructure.
このドキュメントは、スマートグリッドデザイナーに、スマートグリッドで使用するためのインターネットプロトコルスイート（IPS）を最適に「プロファイル」する方法に関するアドバイスを提供します。これは、IPSベースのインフラストラクチャにスマートグリッドデバイスを統合する上で重要なIPSおよび主要なインフラストラクチャプロトコルの概要を提供します。
In the words of Wikipedia [SmartGrid]:
ウィキペディアの言葉では[SmartGrid]：
A Smart Grid is a form of electricity network utilizing digital technology. A Smart Grid delivers electricity from suppliers to consumers using two-way digital communications to control appliances at consumers' homes; this saves energy, reduces costs and increases reliability and transparency. It overlays the ordinary electrical Grid with an information and net metering system, that includes smart meters. Smart Grids are being promoted by many governments as a way of addressing energy independence, global warming and emergency resilience issues.
スマートグリッドは、デジタルテクノロジーを利用する電気ネットワークの一種です。スマートグリッドは、サプライヤから消費者に電力を供給し、双方向のデジタル通信を使用して消費者の家の家電製品を制御します。これにより、エネルギーが節約され、コストが削減され、信頼性と透明性が向上します。スマートメーターを含む情報とネットメータリングシステムで通常の電気グリッドをオーバーレイします。スマートグリッドは、エネルギーの独立性、地球温暖化、緊急回復力の問題に対処する方法として、多くの政府によって促進されています。
A Smart Grid is made possible by applying sensing, measurement and control devices with two-way communications to electricity production, transmission, distribution and consumption parts of the power Grid that communicate information about Grid condition to system users, operators and automated devices, making it possible to dynamically respond to changes in Grid condition.
センシング、測定、および制御デバイスを、双方向通信を備えたセンシング、測定、および制御デバイスを電力生産、送電、流通、消費装置を適用することにより、グリッド条件に関する情報をシステムユーザー、オペレーター、自動デバイスに伝達し、それを作成することで可能になります。グリッド条件の変化に動的に応答することができます。
A Smart Grid includes an intelligent monitoring system that keeps track of all electricity flowing in the system. It also has the capability of integrating renewable electricity such as solar and wind. When power is least expensive the user can allow the smart Grid to turn on selected home appliances such as washing machines or factory processes that can run at arbitrary hours. At peak times it could turn off selected appliances to reduce demand.
スマートグリッドには、システム内のすべての電力を追跡するインテリジェント監視システムが含まれています。また、太陽光や風などの再生可能電力を統合する能力もあります。電力が最も高い場合、ユーザーはスマートグリッドが任意の時間に実行できる洗濯機や工場プロセスなどの選択した家電製品をオンにすることができます。ピーク時には、選択したアプライアンスをオフにして需要を減らすことができます。
Other names for a Smart Grid (or for similar proposals) include smart electric or power Grid, intelligent Grid (or intelliGrid), futureGrid, and the more modern interGrid and intraGrid.
スマートグリッド（または同様の提案）のその他の名前には、スマートエレクトリックまたはパワーグリッド、インテリジェントグリッド（またはIntelligRID）、FutureGrid、およびよりモダンなインターグリッドとイントリッドが含まれます。
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].
この執筆時点では、スマートグリッドの国際的に合意された基準を含むと説明できる文書はありません。それは、その開発において対処されている問題の一部です。最も近い近似は、おそらくスマートグリッド相互運用性パネルの概念モデル[モデル]と[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は、伝送制御プロトコル（TCP）[RFC0793]、ストリーム制御伝送プロトコル（SCTP）[RFC4960]、およびデータグラムの混雑制御プロトコル（DCCP）[2つのシステム間の従来の輸送機能のいくつかの選択肢を提供します。RFC4340]。別のオプションは、ユーザーデータグラムプロトコル（UDP）[RFC0768]などのカプセル化を選択することです。これにより、アプリケーションが独自の輸送サービスを実装できるようになります。実際には、設計者は、解決される問題に適したトランスポートプロトコルを選択します。
The IPS is standardized by the Internet Engineering Task Force (IETF). IETF protocols are documented in the Request for Comments (RFC) series. Several RFCs have been written describing how the IPS should be implemented. These include:
IPSは、インターネットエンジニアリングタスクフォース（IETF）によって標準化されています。IETFプロトコルは、コメントのリクエスト（RFC）シリーズで文書化されています。IPSの実装方法を説明するいくつかのRFCが作成されています。これらには以下が含まれます：
o Requirements for Internet Hosts - Communication Layers [RFC1122],
o インターネットホストの要件 - 通信レイヤー[RFC1122]、
o Requirements for Internet Hosts - Application and Support [RFC1123],
o インターネットホストの要件 - アプリケーションとサポート[RFC1123]、
o Requirements for IP Version 4 Routers [RFC1812], and
o IPバージョン4ルーターの要件[RFC1812]、および
o IPv6 Node Requirements [RFC4294].
o IPv6ノード要件[RFC4294]。
At the time of this writing, RFC 4294 is in the process of being updated, in [IPv6-NODE-REQ].
この執筆時点で、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:
このドキュメントは、スマートグリッドアーキテクトとデザイナーに関連するRFC（およびある程度のインターネットドラフト）の大要を提供することを目的としており、RFCの注釈付きリストとして編成されています。そのために、このドキュメントの残りの部分は次のように整理されています。
o Section 2 describes the Internet Architecture and its protocol suite.
o セクション2では、インターネットアーキテクチャとそのプロトコルスイートについて説明します。
o Section 3 outlines a set of protocols that may be useful in Smart Grid deployment. It is not exhaustive.
o セクション3では、スマートグリッドの展開に役立つ可能性のある一連のプロトコルの概要を説明します。それは網羅的ではありません。
o Finally, Section 4 provides an overview of the business architecture embodied in the design and deployment of the IPS.
o 最後に、セクション4では、IPSの設計と展開に具体化されたビジネスアーキテクチャの概要を説明します。
Before enumerating the list of Internet protocols relevant to Smart Grid, we discuss the layered architecture of the IPS, the functions of the various layers, and their associated protocols.
スマートグリッドに関連するインターネットプロトコルのリストを列挙する前に、IPSの層状アーキテクチャ、さまざまなレイヤーの機能、および関連するプロトコルについて説明します。
While Internet architecture uses the definitions and language similar to language used by the ISO Open System Interconnect (ISO-OSI) reference model (Figure 1), it actually predates that model. As a result, there is some skew in terminology. For example, the ISO-OSI model uses "end system" while the Internet architecture uses "host". Similarly, an "intermediate system" in the ISO-OSI model is called an "internet gateway" or "router" in Internet parlance. Notwithstanding these differences, the fundamental concepts are largely the same.
インターネットアーキテクチャは、ISO Open System Interconnect（ISO-OSI）リファレンスモデル（図1）で使用される言語と同様の定義と言語を使用していますが、実際にはそのモデルよりも前のものです。その結果、用語にはいくつかのスキューがあります。たとえば、ISO-OSIモデルは「エンドシステム」を使用し、インターネットアーキテクチャは「ホスト」を使用します。同様に、ISO-OSIモデルの「中間システム」は、インターネット用語の「インターネットゲートウェイ」または「ルーター」と呼ばれます。これらの違いにもかかわらず、基本的な概念はほぼ同じです。
+--------------------+
| 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.
インターネット参照モデルの構造を図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：インターネット参照モデル
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.
インターネットモデルでは、アプリケーション、プレゼンテーション、およびセッションレイヤーが「アプリケーション」と呼ばれる単一のエンティティに圧縮されます。たとえば、Simple Network Management Protocol（SNMP）[RFC3411]は、ASN.1プロファイルでデータをエンコードし、ネットワーク要素を管理するセッションに従事するアプリケーションを説明します。ここでのポイントは、インターネットでは、これらのレイヤー間の区別が存在するが、強調されていないということです。さらに、図2では、これらの機能が必ずしもきれいに層状になっているわけではないことに注意してください。アプリケーションプロトコルが何らかの形でデータをエンコードし、何らかの方法でセッションを管理することは、それらのプロセス間の階層を意味するものではないことに注意してください。むしろ、アプリケーションは、エンコード、セッション管理、およびその他のさまざまなサービスを、作業中に使用するツールセットとして表示します。
The term "transport" is perhaps among the most confusing concepts in the communication architecture, to a large extent because people with various backgrounds use it to refer to "the layer below that which I am interested in, which gets my data to my peer". For example, optical network engineers refer to optical fiber and associated electronics as "the transport", while web designers refer to the Hypertext Transfer Protocol (HTTP) [RFC2616] (an application layer protocol) as "the transport".
「輸送」という用語は、おそらくコミュニケーションアーキテクチャで最も混乱する概念の1つであり、さまざまな背景を持つ人々が「私が興味を持っているレイヤーの下のレイヤー、それが私のピアに取得する」を参照するために使用するため、大部分があります。。たとえば、光学ネットワークエンジニアは光ファイバと関連する電子機器を「トランスポート」と呼び、Webデザイナーはハイパーテキスト転送プロトコル（HTTP）[RFC2616]（アプリケーションレイヤープロトコル）を「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つのポート番号、1つは送信者と受信者用に1つを使用してこれを達成します。ポート番号は、アプリケーションインスタンスを識別します。これは、ピアやクライアントがセッションを開く可能性のある一般的な「リスナー」、またはそのような「リスナー」との特定の特派員である可能性があります。IPデータグラムのセッション識別は、多くの場合「Five-Tuple」と呼ばれ、ソースと宛先IPアドレス、ソースおよび宛先ポート、および使用中の輸送プロトコルの識別子で構成されています。
In addition, the responsibilities of a specific transport layer protocol typically include the delivery of data (either as a stream of messages or a stream of bytes) in a stated sequence with stated expectations regarding delivery rate and loss. For example, TCP will reduce its rate in response to loss, as a congestion control trigger, while DCCP accepts some level of loss if necessary to maintain timeliness.
さらに、特定の輸送層プロトコルの責任には、通常、配信率と損失に関する定めの期待を伴う記載されたシーケンスでのデータ（メッセージのストリームまたはバイトのストリームとして）の配信が含まれます。たとえば、TCPは輻輳制御トリガーとして損失に応じてそのレートを引き下げますが、DCCPは適時性を維持するために必要に応じてある程度の損失を受け入れます。
The main function of the network layer is to identify a remote destination and deliver data to it. In connection-oriented networks such as Multi-protocol Label Switching (MPLS) [RFC3031] or Asynchronous Transfer Mode (ATM), a path is set up once, and data is delivered through it. In connectionless networks such as Ethernet and IP, data is delivered as datagrams. Each datagram contains both the source and destination network layer addresses, and the network is responsible for delivering it. In the Internet Protocol Suite, the Internet Protocol is the network that runs end to end. It may be encapsulated over other LAN and WAN technologies, including both IP networks and networks of other types.
ネットワークレイヤーの主な機能は、リモートの宛先を識別し、データを配信することです。マルチプロトコルラベルスイッチング（MPLS）[RFC3031]または非同期転送モード（ATM）などの接続指向ネットワークでは、パスが一度セットアップされ、データが提供されます。イーサネットやIPなどのコネクションレスネットワークでは、データがデータグラムとして配信されます。各データグラムには、ソースネットワークレイヤーアドレスと宛先ネットワークレイヤーの両方のアドレスが含まれており、ネットワークはそれを配信する責任があります。インターネットプロトコルスイートでは、インターネットプロトコルはエンドツーエンドで実行されるネットワークです。IPネットワークと他のタイプのネットワークの両方を含む、他のLANおよびWANテクノロジーにカプセル化される場合があります。
IPv4 and IPv6, each of which is called the Internet Protocol, are connectionless ("datagram") architectures. They are designed as common elements that interconnect network elements across a network of lower-layer networks. In addition to the basic service of identifying a datagram's source and destination, they offer services to fragment and reassemble datagrams when necessary, assist in diagnosis of network failures, and carry additional information necessary in special cases.
IPv4とIPv6は、それぞれがインターネットプロトコルと呼ばれ、ConnectionLess（ "Datagram"）アーキテクチャです。これらは、低層ネットワークのネットワーク全体でネットワーク要素を相互接続する一般的な要素として設計されています。データグラムのソースと目的地を識別する基本的なサービスに加えて、必要に応じてデータグラムを断片化および再組み立てするためのサービスを提供し、ネットワーク障害の診断を支援し、特別な場合に必要な追加情報を提供します。
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ネットワークに結合できるようにするレイヤーです。新しいネットワークテクノロジーは、IPがこれらのテクノロジーをどのように繰り越すかを定義することにより、IPプロトコルスイートに導入でき、それらのプロトコルを変更しないIPSおよびアプリケーションの他のレイヤーを残します。
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.
ネットワークレイヤーは、必要に応じて再帰的に細分化できます。これは、Tunnelingによって達成される場合があります。Tunnelingでは、IPデータグラムが別のIPヘッダーにカプセル装置にカプセル化されており、脱カプセレータに配信されます。IPは、IPSEC、IP-in-IP、および一般的なルートカプセル化（GRE）のトンネルモードなどのトンネルモード（GRE）[RFC2784]などのトンネルテクノロジーを使用して、パブリックインターネット全体で仮想プライベートネットワーク（VPN）で頻繁に運ばれます。さらに、IPは、MPLS [RFC4364]、GMPLS、ATMなどの回路ネットワークでも頻繁に運ばれます。最後に、IPはワイヤレスネットワーク（IEEE 802.11、802.15.4、または802.16）にも持ち運ばれ、イーサネット（IEEE 802.3）ネットワークを切り替えます。
At the lowest layer of the IP architecture, data is encoded in messages and transmitted over the physical media. While the IETF specifies algorithms for carrying IPv4 and IPv6 various media types, it rarely actually defines the media -- it happily uses specifications from IEEE, ITU, and other sources.
IPアーキテクチャの最低層では、データがメッセージにエンコードされ、物理メディアを介して送信されます。IETFは、IPv4およびIPv6のさまざまなメディアタイプを運ぶためのアルゴリズムを指定しますが、実際にメディアを定義することはめったにありません。IEEE、ITU、およびその他のソースの仕様を喜んで使用します。
While complaining about the security of the Internet is popular, it is important to distinguish between attacks on protocols and attacks on users (e.g., phishing). Attacks on users are largely independent of protocol details, reflecting interface design issues or user education problems, and are out of scope for this document. Security problems with Internet protocols are in scope, of course, and can often be mitigated using existing security features already specified for the protocol, or by leveraging the security services offered by other IETF protocols. See the Security Assessment of the Transmission Control Protocol (TCP) [TCP-SEC] and the Security Assessment of the Internet Protocol version 4 [IP-SEC] for more information on TCP and IPv4 issues, respectively.
インターネットのセキュリティについて不平を言うことは人気がありますが、プロトコルに対する攻撃とユーザーへの攻撃（フィッシングなど）を区別することが重要です。ユーザーへの攻撃は、インターフェイスの設計の問題やユーザー教育の問題を反映して、プロトコルの詳細とほとんど独立しており、このドキュメントの範囲外です。もちろん、インターネットプロトコルのセキュリティ上の問題は範囲内であり、プロトコルに既に指定されている既存のセキュリティ機能を使用して、または他のIETFプロトコルが提供するセキュリティサービスを活用することにより、多くの場合緩和できます。TCPおよびIPv4の問題の詳細については、それぞれTCPおよびIPv4の問題の詳細については、それぞれTransmission Control Protocol（TCP）[TCP-SEC]のセキュリティ評価と、それぞれインターネットプロトコルバージョン4 [IP-SEC]のセキュリティ評価を参照してください。
These solutions do, however, need to get deployed as well. The road to widespread deployment can sometimes be painful since often multiple stakeholders need to take actions. Experience has shown that this takes some time, and very often only happens when the incentives are high enough in relation to the costs.
ただし、これらのソリューションも展開する必要があります。多くの場合、複数の利害関係者が行動を起こす必要があるため、広範囲にわたる展開への道は苦痛になることがあります。経験には、これには時間がかかることが示されており、コストに関連してインセンティブが十分に高い場合にのみ非常に頻繁に発生します。
Furthermore, it is important to stress that available standards are important, but the range of security problems is larger than a missing standard; many security problems are the result of implementation bugs and the result of certain deployment choices. While these are outside the realm of standards development, they play an important role in the security of the overall system. Security has to be integrated into the entire process.
さらに、利用可能な標準が重要であることを強調することが重要ですが、セキュリティの問題の範囲は欠落している標準よりも大きくなります。多くのセキュリティ問題は、実装バグの結果であり、特定の展開の選択の結果です。これらは標準開発の領域外にありますが、システム全体のセキュリティにおいて重要な役割を果たしています。セキュリティはプロセス全体に統合する必要があります。
The IETF takes security seriously in the design of their protocols and architectures; every IETF specification has to have a Security Considerations section to document the offered security threats and countermeasures. RFC 3552 [RFC3552] provides recommendations on writing such a Security Considerations section. It also describes the classical Internet security threat model and lists common security goals.
IETFは、プロトコルとアーキテクチャの設計においてセキュリティを真剣に受け止めています。すべてのIETF仕様には、提供されるセキュリティの脅威と対策を文書化するために、セキュリティ上の考慮事項セクションが必要です。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.
セキュリティの脅威と利用可能なセキュリティメカニズムの議論は、一般的に登場する設計の側面のいくつかを説明することを目的としています。
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ネットワークは、メーターとそれを管理するデバイスの間に金属製の接地板を頻繁に配置することが多いことが広く注目されています。繊維は、それが手に負えないと考えられていたため、一度に展開されていました。それ以来、繊維を曲げて偶発的な光を収集することでそれをタップすることを学び、バックホーについて学びました。その結果、一部のインストールでは、可愛らしいシースに光ファイバーケーブルを包み込みます。
While there are protocol behaviors that can detect certain classes of physical faults, such as keep-alive exchanges, physical security is generally not considered to be a protocol problem.
キープアライブ交換など、特定のクラスの物理的障害を検出できるプロトコルの動作がありますが、物理的セキュリティは一般にプロトコルの問題とは見なされません。
For wireless transmission technologies, eavesdropping on the transmitted frames is also typically a concern. Additionally, those operating networks may want to ensure that access to their infrastructure is restricted to those who are authenticated and authorized (typically called 'network access authentication'). This procedure is often offered by security primitives at the data link layer.
ワイヤレス送信技術の場合、送信されたフレームを盗聴することも通常懸念事項です。さらに、これらの運用ネットワークは、インフラストラクチャへのアクセスが認証および承認された人（通常は「ネットワークアクセス認証」と呼ばれる）に制限されるようにすることをお勧めします。この手順は、多くの場合、データリンクレイヤーのセキュリティプリミティブによって提供されます。
At the network, transport, and application layers, it is common to demand a few basic security requirements, commonly referred to as CIA (Confidentiality, Integrity, and Availability):
ネットワーク、輸送、およびアプリケーション層では、一般にCIA（機密性、整合性、および可用性）と呼ばれるいくつかの基本的なセキュリティ要件を要求することが一般的です。
1. Confidentiality: Protect the transmitted data from unauthorized disclosure (i.e., keep eavesdroppers from learning what was transmitted). For example, for trust in e-commerce applications, credit card transactions are exchanged encrypted between the Web browser and a Web server.
1. 機密性：送信されたデータを許可されていない開示から保護します（つまり、盗聴者が送信されたものを学習しないようにします）。たとえば、eコマースアプリケーションへの信頼の場合、クレジットカードトランザクションは、WebブラウザーとWebサーバーの間で暗号化されて交換されます。
2. Integrity: Protect against unauthorized changes to exchanges, including both intentional change or destruction and accidental change or loss, by ensuring that changes to exchanges are detectable. It has two parts: one for the data and one for the peers.
2. 整合性：交換の変更が検出可能であることを確認することにより、意図的な変更または破壊、偶発的な変更または損失の両方を含む、交換への不正な変更から保護します。2つの部分があります。1つはデータ用、もう1つはピア用です。
* 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'.
* ピアは、信頼できるピアからのものであると思われる情報が本当にその仲間からであることを確認する必要があります。これは通常、「Data Origin Authentication」と呼ばれます。
* Peers need to validate that the content of the data exchanged is unmodified. The term typically used for this property is 'data integrity'.
* ピアは、交換されたデータのコンテンツが変更されていないことを検証する必要があります。通常、このプロパティに使用される用語は「データの整合性」です。
3. Availability: Ensure that the resource is accessible by mitigating of denial-of-service attacks.
3. 可用性：サービス拒否攻撃を緩和することにより、リソースにアクセスできることを確認してください。
To this we add authenticity, which requires that the communicating peers prove that they are in fact who they say they are to each other (i.e., mutual authentication). This generally means knowing "who" the peer is, and that they demonstrate the possession of a "secret" as part of the security protocol interaction.
これには、信頼性を追加します。これには、通信仲間が実際に彼らがお互いにそうであると言う人であることを証明することが必要です（つまり、相互認証）。これは一般に、ピアが「誰であるか」を知ることを意味し、セキュリティプロトコルの相互作用の一部として「秘密」の所有を実証することを意味します。
The following three examples aim to illustrate these security requirements.
次の3つの例は、これらのセキュリティ要件を説明することを目的としています。
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セッションに対する一般的な攻撃の1つは、リセットメッセージでセッションを攻撃することです。TCPに対するその他の攻撃には、攻撃者がTCP状態を作成してターゲットの記憶を使い果たしようとする「Syn Flooding」攻撃が含まれます。特に、攻撃者は、多数の一意のTCP接続を開くことにより、ターゲットのメモリを使い果たしようとします。それぞれが伝送制御ブロック（TCB）で表されます。攻撃者がターゲットをTCBで記憶に満たすことができる場合、攻撃は成功します。
A number of mechanisms have been developed to deal with these types of denial-of-service attacks. One, "SYN Cookies", delays state establishment on the server side to a later phase in the protocol exchange. Another mechanism, specifically targeting the reset attack cited above, provides authentication services in TCP itself to ensure that fake resets are rejected.
これらのタイプのサービス拒否攻撃に対処するために、多くのメカニズムが開発されています。「Syn Cookies」の1つは、プロトコル交換の後期フェーズまで、サーバー側の状態施設を遅らせます。上記のリセット攻撃をターゲットにする別のメカニズムは、偽のリセットが拒否されることを確認するために、TCP自体の認証サービスを提供します。
Another approach would be to offer security protection already at a lower layer, such as IPsec (see Section 3.1.2) or TLS (see Section 3.1.3), so that a host can identify legitimate messages and discard the others, thus mitigating any damage that may have been caused by the attack.
別のアプローチは、IPSEC（セクション3.1.2を参照）やTLS（セクション3.1.3を参照）などの下層層で既にセキュリティ保護を提供し、ホストが正当なメッセージを識別し、他のメッセージを破棄し、したがって任意のものを軽減できるようにすることです。攻撃によって引き起こされた可能性のある損害。
Another common attack involves unauthorized access to resources. For example, an unauthorized party might try to attach to a network. To protect against such an attack, an Internet Service Provider (ISP) typically requires network access authentication of new hosts demanding access to the network and to the Internet prior to offering access. This exchange typically requires authentication of that entity and a check in the ISPs back-end database to determine whether corresponding subscriber records exist and are still valid (e.g., active subscription and sufficient credits).
別の一般的な攻撃には、リソースへの不正アクセスが含まれます。たとえば、許可されていない当事者は、ネットワークに添付しようとする場合があります。このような攻撃から保護するために、インターネットサービスプロバイダー（ISP）は通常、アクセスを提供する前に、ネットワークとインターネットへのアクセスを要求する新しいホストのネットワークアクセス認証を必要とします。この交換では、通常、そのエンティティの認証とISPSバックエンドデータベースのチェックを必要とし、対応するサブスクライバーレコードが存在し、まだ有効かどうかを判断します（たとえば、アクティブサブスクリプションや十分なクレジット）。
From the discussion above, establishing a secure communication channel is clearly an important concept frequently used to mitigate a range of attacks. Unfortunately, focusing only on channel security may not be enough for a given task. Threat models have evolved and even some of the communication endpoints cannot be considered fully trustworthy, i.e., even trusted peers may act maliciously.
上記の議論から、安全な通信チャネルを確立することは、明らかにさまざまな攻撃を軽減するために頻繁に使用される重要な概念です。残念ながら、チャネルセキュリティのみに焦点を当てるだけでは、特定のタスクには十分ではない場合があります。脅威モデルは進化しており、通信エンドポイントの一部でさえ完全に信頼できると見なすことはできません。つまり、信頼できるピアでさえ悪意を持って行動する可能性があります。
Furthermore, many protocols are more sophisticated in their protocol interaction and involve more than two parties in the protocol exchange. Many of the application layer protocols, such as email, instant messaging, voice over IP, and presence-based applications, fall into this category. With this class of protocols, secure data, such as DNS records, and secure communications with middleware, intermediate servers, and supporting applications need to be considered as well as the security of the direct communication. A detailed treatment of the security threats and requirements of these multi-party protocols is beyond this specification but the interested reader is referred to the above-mentioned examples for an illustration of what technical mechanisms have been investigated and proposed in the past.
さらに、多くのプロトコルは、プロトコルの相互作用がより洗練されており、プロトコル交換には2つ以上の関係者が関与しています。電子メール、インスタントメッセージング、ボイスオーバーIP、プレゼンスベースのアプリケーションなど、アプリケーションレイヤープロトコルの多くがこのカテゴリに分類されます。このクラスのプロトコルを使用すると、DNSレコードなどの安全なデータ、ミドルウェア、中間サーバーとの安全な通信、およびサポートアプリケーションと直接通信のセキュリティを考慮する必要があります。これらのマルチパーティプロトコルのセキュリティの脅威と要件の詳細な扱いはこの仕様を超えていますが、興味のある読者は、過去に調査および提案されてきた技術メカニズムがどのような技術メカニズムが提案されていたかを示す上記の例を参照しています。
While the following protocols are not critical to the design of a specific system, they are important to running a network, and as such are surveyed here.
次のプロトコルは特定のシステムの設計にとって重要ではありませんが、ネットワークを実行するために重要であるため、ここで調査されます。
The DNS' main function is translating names to numeric IP addresses. While this is not critical to running a network, certain functions are made a lot easier if numeric addresses can be replaced with mnemonic names. This facilitates renumbering of networks and generally improves the manageability and serviceability of the network. DNS has a set of security extensions called DNSSEC, which can be used to provide strong cryptographic authentication to the DNS. DNS and DNSSEC are discussed further in Section 3.4.1.
DNSの主な関数は、名前を数値IPアドレスに変換することです。これはネットワークを実行するために重要ではありませんが、数値アドレスをニーモニック名に置き換えることができれば、特定の機能がはるかに簡単になります。これにより、ネットワークの変更が容易になり、一般にネットワークの管理可能性と保守性が向上します。DNSには、DNSSECと呼ばれる一連のセキュリティ拡張機能があり、DNSに強力な暗号認証を提供するために使用できます。DNSとDNSSECについては、セクション3.4.1でさらに説明します。
Network management has proven to be a difficult problem. As such, various solutions have been proposed, implemented, and deployed. Each solution has its proponents, all of whom have solid arguments for their viewpoints. The IETF has two major network management solutions for device operation: SNMP, which is ASN.1-encoded and is primarily used for monitoring of system variables, and NETCONF [RFC4741], which is XML-encoded and primarily used for device configuration.
ネットワーク管理は難しい問題であることが証明されています。そのため、さまざまなソリューションが提案、実装、展開されています。それぞれのソリューションには支持者があり、全員が視点に対してしっかりと議論しています。IETFには、デバイス操作のための2つの主要なネットワーク管理ソリューションがあります。SNMPはASN.1エンコードされており、主にシステム変数の監視に使用されます。NetConf[RFC4741]はXMLエンコードされ、主にデバイス構成に使用されます。
Another aspect of network management is the initial provisioning and configuration of hosts, which is discussed in Section 3.4.2. Note that Smart Grid deployments may require identity authentication and authorization (as well as other provisioning and configuration) that may not be within the scope of either DHCP or Neighbor Discovery. While the IP Protocol Suite has limited support for secure provisioning and configuration, these problems have been solved using IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0].
ネットワーク管理のもう1つの側面は、セクション3.4.2で説明されているホストの初期プロビジョニングと構成です。スマートグリッドの展開には、DHCPまたは近隣発見の範囲内ではない可能性のあるID認証と認証（およびその他のプロビジョニングと構成）が必要になる場合があります。IPプロトコルスイートは安全なプロビジョニングと構成のサポートが限られていますが、これらの問題は、DOCSIS 3.0 [SP-Mulpiv3.0]などの仕様のIPプロトコルを使用して解決されています。
In this section, having briefly laid out the IP architecture and some of the problems that the architecture tries to address, we introduce specific protocols that might be appropriate to various Smart Grid use cases. Use cases should be analyzed along with privacy, Authentication, Authorization, and Accounting (AAA), transport, and network solution dimensions. The following sections provide guidance for such analysis.
このセクションでは、IPアーキテクチャとアーキテクチャが対処しようとする問題のいくつかを簡単に説明したため、さまざまなスマートグリッドユースケースに適した特定のプロトコルを導入します。ユースケースは、プライバシー、認証、承認、会計（AAA）、輸送、ネットワークソリューションの寸法とともに分析する必要があります。次のセクションでは、そのような分析のガイダンスを提供します。
As noted, a key consideration in security solutions is a good threat analysis coupled with appropriate mitigation strategies at each layer. The IETF has over time developed a number of building blocks for security based on the observation that protocols often demand similar security services. The following sub-sections outline a few of those commonly used security building blocks. Reusing them offers several advantages, such as availability of open source code, experience with existing systems, a number of extensions that have been developed, and the confidence that the listed technologies have been reviewed and analyzed by a number of security experts.
前述のように、セキュリティソリューションの重要な考慮事項は、各レイヤーでの適切な緩和戦略と組み合わされた優れた脅威分析です。IETFは、プロトコルがしばしば同様のセキュリティサービスを要求するという観察に基づいて、セキュリティのための多くのビルディングブロックを時間の経過とともに開発しました。次のサブセクションは、一般的に使用されるセキュリティビルディングブロックのいくつかの概要を示しています。それらを再利用することで、オープンソースコードの可用性、既存のシステムでの経験、開発された多くの拡張機能、リストされたテクノロジーが多くのセキュリティ専門家によってレビューおよび分析されているという自信など、いくつかの利点があります。
It is important to highlight that in addition to the mentioned security tools, every protocol often comes with additional, often unique security considerations that are specific to the domain in which the protocol operates. Many protocols include features specifically designed to mitigate these protocol-specific risks. In other cases, the security considerations will identify security-relevant services that are required from other network layers to achieve appropriate levels of security.
上記のセキュリティツールに加えて、すべてのプロトコルには、プロトコルが動作するドメインに固有の追加の、しばしばユニークなセキュリティに関する考慮事項があることが多いことを強調することが重要です。多くのプロトコルには、これらのプロトコル固有のリスクを緩和するために特別に設計された機能が含まれています。それ以外の場合、セキュリティ上の考慮事項は、適切なレベルのセキュリティを実現するために他のネットワークレイヤーから必要なセキュリティ関連サービスを特定します。
While the term AAA sounds generic and applicable to all sorts of security protocols, it has been, in the IETF, used in relation to network access authentication and is associated with the RADIUS ([RFC2865]) and the Diameter protocol ([RFC3588], [DIME-BASE]) in particular.
AAAという用語は一般的に聞こえ、あらゆる種類のセキュリティプロトコルに適用できますが、IETFでは、ネットワークアクセス認証に関連して使用され、半径（[RFC2865]）と直径プロトコル（[RFC3588]に関連付けられています。[ダイムベース]）特に。
The authentication procedure for network access aims to deal with the task of verifying that a peer is authenticated and authorized prior to accessing a particular resource (often connectivity to the Internet). Typically, the authentication architecture for network access consists of the following building blocks: the Extensible Authentication Protocol (EAP [RFC4017]) as a container to encapsulate EAP methods, an EAP Method (as a specific way to perform cryptographic authentication and key exchange, such as described in RFC 5216 [RFC5216] and RFC 5433 [RFC5433]), a protocol that carries EAP payloads between the end host and a server-side entity (such as a network access server), and a way to carry EAP payloads to back-end server infrastructure (potentially in a cross-domain scenario) to provide authorization and accounting functionality. The latter part is provided by RADIUS and Diameter. To carry EAP payloads between the end host and a network access server, different mechanisms have been standardized, such as the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191] and IEEE 802.1X [IEEE802.1X]. For access to remote networks, such as enterprise networks, the ability to utilize EAP within IKEv2 [RFC5996] has also been developed.
ネットワークアクセスの認証手順は、特定のリソース（多くの場合、インターネットへの接続性）にアクセスする前に、ピアが認証および承認されていることを確認するタスクに対処することを目的としています。通常、ネットワークアクセスの認証アーキテクチャは、次のビルディングブロックで構成されています。EAPメソッドをカプセル化するためのコンテナとしての拡張可能な認証プロトコル（EAP [RFC4017]）、EAPメソッド（暗号化認証とキー交換を実行する特定の方法として）RFC 5216 [RFC5216]およびRFC 5433 [RFC5433]）で説明されているように、エンドホストとサーバー側のエンティティ（ネットワークアクセスサーバーなど）の間にEAPペイロードを搭載するプロトコル、およびEAPペイロードを運ぶ方法-And Serverインフラストラクチャ（潜在的にクロスドメインシナリオで）認可と会計機能を提供します。後者の部分は、半径と直径によって提供されます。エンドホストとネットワークアクセスサーバーの間にEAPペイロードを携帯するために、ネットワークアクセス（PANA）[RFC5191]およびIEEE 802.1x [IEEE802.1x]の認証を運ぶプロトコルなど、さまざまなメカニズムが標準化されています。エンタープライズネットワークなどのリモートネットワークへのアクセスのために、IKEV2 [RFC5996]内でEAPを利用する機能も開発されています。
More recently, the same architecture with EAP and RADIUS/Diameter is being reused for application layer protocols. More details about this architectural variant can be found in [ABFAB-ARCH].
最近では、EAPと半径/直径の同じアーキテクチャがアプリケーションレイヤープロトコルのために再利用されています。このアーキテクチャバリアントの詳細については、[abfab-arch]をご覧ください。
IP security, as described in [RFC4301], addresses security at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms. It offers a set of security services for traffic at the IP layer, in both the IPv4 and IPv6 environment. The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic-flow confidentiality. These services are provided at the IP layer, offering protection in a standard fashion for all protocols that may be carried over IP (including IP itself).
[RFC4301]で説明されているように、IPセキュリティは、暗号化とプロトコルのセキュリティメカニズムの組み合わせを使用して提供されるIPレイヤーのセキュリティに対処します。IPv4環境とIPv6環境の両方で、IPレイヤーでのトラフィックのセキュリティサービスのセットを提供します。提供される一連のセキュリティサービスには、アクセス制御、コネクションレスの整合性、データの起源認証、回復の検出と拒否（部分シーケンスの整合性の形式）、機密性（暗号化による）、および限られたトラフィックフローの機密性が含まれます。これらのサービスはIPレイヤーで提供されており、IP（IP自体を含む）で運ばれるすべてのプロトコルに対して標準的な方法で保護を提供します。
The architecture foresees a split between the rather time-consuming (a) authentication and key exchange protocol step that also establishes a security association (a data structure with keying material and security parameters) and (b) the actual data traffic protection.
アーキテクチャは、セキュリティ協会（キーイングマテリアルおよびセキュリティパラメーターを備えたデータ構造）と（b）実際のデータトラフィック保護も確立するかなり時間がかかる（a）認証と主要な交換プロトコルステップとの間の分割を予見しています。
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)
実際のデータ保護のために、2種類のプロトコルが歴史的に使用されてきました。つまり、IP認証ヘッダー（AH）
[RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. The two differ in the security services they offer; the most important distinction is that ESP offers confidentiality protection while AH does not. Since ESP can also provide authentication services, most recent protocol developments making use of IPsec only specify use of ESP and do not use AH.
[RFC4302]およびカプセル化セキュリティペイロード（ESP）[RFC4303]。2つは、提供するセキュリティサービスが異なります。最も重要な区別は、ESPが機密保護を提供しますが、AHはそうではないことです。ESPも認証サービスを提供できるため、IPSECを使用する最新のプロトコル開発はESPの使用のみを指定し、AHを使用しないことです。
In addition to these base line protocol mechanisms a number of extensions have been developed for IKEv2 (e.g., an extension to perform EAP-only authentication [RFC5998]) and since the architecture supports flexible treatment of cryptographic algorithms a number of them have been specified (e.g., [RFC4307] for IKEv2, and [RFC4835] for AH and ESP).
これらのベースラインプロトコルメカニズムに加えて、IKEV2のために多くの拡張機能が開発されています（例：EAPのみの認証を実行するための拡張[RFC5998]）。アーキテクチャは暗号化アルゴリズムの柔軟な処理をサポートしているため、それらの多くは指定されています（たとえば、IKEV2の[RFC4307]、およびAHおよびESPの[RFC4835]）。
Transport Layer Security v1.2 [RFC5246] are security services that protect data above the transport layer. The protocol allows client/ server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. TLS is application protocol independent.
トランスポートレイヤーセキュリティv1.2 [RFC5246]は、輸送層の上のデータを保護するセキュリティサービスです。このプロトコルにより、クライアント/サーバーアプリケーションは、盗聴、改ざん、またはメッセージの偽造を防ぐように設計された方法で通信できます。TLSはアプリケーションプロトコル独立です。
TLS is composed of two layers: the TLS Record protocol and the TLS Handshake protocol. The TLS Record protocol provides connection security that has two basic properties: (a) confidentiality protection and (b) integrity protection.
TLSは、TLSレコードプロトコルとTLSハンドシェイクプロトコルの2つのレイヤーで構成されています。TLSレコードプロトコルは、2つの基本的なプロパティを備えた接続セキュリティを提供します。（a）機密保護と（b）整合性保護。
The TLS Handshake protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The negotiated parameters and the derived keying material is then used by the TLS Record protocol to perform its job.
TLSハンドシェイクプロトコルにより、サーバーとクライアントは互いに認証され、アプリケーションプロトコルがデータの最初のバイトを送信または受信する前に、暗号化アルゴリズムと暗号化キーを交渉できます。交渉されたパラメーターと導出されたキーイング材料は、TLSレコードプロトコルによって使用されてジョブを実行します。
Unlike IKEv2/IPsec, TLS negotiates these cryptographic parameters in suites, so-called 'cipher suites'. Examples of cipher suites that can be negotiated with TLS include Elliptic Curve Cryptography (ECC) [RFC4492] [RFC5289] [AES-CCM-ECC], Camellia [RFC5932], and the Suite B Profile [RFC5430]. [IEC62351-3] outlines the use of different TLS cipher suites for use in the Smart Grid. The basic cryptographic mechanisms for ECC have been documented in [RFC6090].
IKEV2/IPSECとは異なり、TLSはスイートのこれらの暗号化パラメーター、いわゆる「暗号スイート」を交渉します。TLSと交渉できる暗号スイートの例には、楕円曲線暗号化（ECC）[RFC4492] [RFC5289] [AES-CCM-ECC]、Camellia [RFC5932]、およびスイートBプロファイル[RFC5430]が含まれます。[IEC62351-3]は、スマートグリッドで使用するためのさまざまなTLS暗号スイートの使用の概要を示しています。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.
TLSは、信頼できる輸送チャネル（通常はTCP）を介して実行する必要があります。UDPなどの信頼できないデータグラムトラフィックに同じセキュリティサービスを提供するために、データグラムトランスポートレイヤーセキュリティ（DTLS [RFC4347] [DTLS]）が開発されました。
In certain cases, the application layer independent security mechanisms described in the previous sub-sections are not sufficient to deal with all the identified threats. For this purpose, a number of security primitives are additionally available at the application layer where the semantic of the application can be considered.
特定の場合、以前のサブセクションで説明されているアプリケーション層の独立したセキュリティメカニズムは、特定されたすべての脅威に対処するのに十分ではありません。この目的のために、アプリケーションのセマンティックを考慮できるアプリケーションレイヤーで、多くのセキュリティプリミティブがさらに利用可能です。
We will focus our description on a few mechanisms that are commonly used throughout the Internet.
インターネット全体で一般的に使用されるいくつかのメカニズムに説明を集中させます。
Cryptographic Message Syntax (CMS [RFC5652]) is an encapsulation syntax to sign, digest, authenticate, or encrypt arbitrary message content. It also allows arbitrary attributes, such as signing time, to be signed along with the message content, and it provides for other attributes such as countersignatures to be associated with a signature. The CMS can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX (Public Key Infrastructure using X.509) working group [RFC5280]. The CMS has been leveraged to supply security services in a variety of protocols, including secure email [RFC5751], key management [RFC5958] [RFC6031], and firmware updates [RFC4108].
暗号化メッセージ構文（CMS [RFC5652]）は、任意のメッセージコンテンツに署名、消化、認証、または暗号化するカプセル化構文です。また、署名時間などの任意の属性をメッセージコンテンツとともに署名することもでき、副署名などの他の属性が署名に関連付けられることを提供します。CMSは、PKIX（X.509を使用して公開キーインフラストラクチャ）ワーキンググループ[RFC5280]で定義されたものなど、証明書ベースのキー管理のさまざまなアーキテクチャをサポートできます。CMSは、安全なメール[RFC5751]、キー管理[RFC5958] [RFC6031]、ファームウェアの更新[RFC4108]など、さまざまなプロトコルでセキュリティサービスを提供するために活用されています。
Related work includes the use of digital signatures on XML-encoded documents, which has been jointly standardized by W3C and the IETF [RFC3275]. Digitally signed XML is a good choice where applications natively support XML-encoded data, such as the Extensible Messaging and Presence Protocol (XMPP).
関連する作業には、XMLエンコードドキュメントでのデジタル署名の使用が含まれます。これは、W3CとIETF [RFC3275]によって共同で標準化されています。デジタルで署名されたXMLは、アプリケーションが拡張可能なメッセージングやプレゼンスプロトコル（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アプリケーションによって要求される委任された認証と認証に関する作業は、Open Web Authentication（OAUTH）プロトコル[RFC5849] [OAUTHV2]で開発されました。OAUTHは、リソースの所有者に長期的な資格をそのサードパーティと共有することなく、保護されたリソース（特定の世帯に関するエネルギー消費情報など）にアクセスするためにサードパーティのアプリケーションで使用されます。OAUTHでは、サードパーティのアプリケーションは、リソース所有者によって制御され、リソースサーバーによってホストされているリソースへのアクセスを要求し、リソース所有者とは異なる資格情報を発行されます。より具体的には、サードパーティのアプリケーションは、OAuthプロトコル交換中にアクセストークンを取得します。このトークンは、特定の範囲、期間、およびその他のアクセス属性を示します。その結果、リソース所有者の同意を得て、保護されたリソースへのアクセスを安全に獲得します。
The Secure Shell (SSH) protocol [RFC4253] has been widely used by administrators and others for secure remote login, but is also usable for secure tunneling. More recently, protocols have chosen to layer on top of SSH for transport security services; for example, the NETCONF network management protocol (see Section 3.5.2) uses SSH as its main communications security protocol.
Secure Shell（SSH）プロトコル[RFC4253]は、管理者やその他が安全なリモートログインに広く使用していますが、安全なトンネルにも使用できます。最近では、プロトコルが輸送セキュリティサービスのためにSSHの上に階層化することを選択しました。たとえば、NetConfネットワーク管理プロトコル（セクション3.5.2を参照）は、SSHをメイン通信セキュリティプロトコルとして使用しています。
All of the security protocols discussed above depend on cryptography for security, and hence require some form of key management. Most IETF protocols at least nominally require some scalable form of key management to be defined as mandatory to implement; indeed the lack of such key management features has in the past been a reason to delay approval of protocols. There are two generic key management schemes that are widely used by other Internet protocols, PKIX and Kerberos, each of which is briefly described below.
上記のすべてのセキュリティプロトコルは、セキュリティの暗号化に依存するため、何らかの形の主要な管理が必要です。ほとんどのIETFプロトコルは、少なくとも名目上、実装するための必須として定義されるために、いくつかのスケーラブルな形式のキー管理を必要とします。実際、このような主要な管理機能の欠如は、過去にプロトコルの承認を遅らせる理由でした。他のインターネットプロトコルであるPKIXとKerberosで広く使用されている2つの一般的な重要な管理スキームがあり、それぞれが以下に簡単に説明します。
Public Key Infrastructure (PKI) refers to the kind of key management that is based on certification authorities (CAs) issuing public key certificates for other key holders. By chaining from a trust anchor (a locally trusted copy of a CA public key) down to the public key of some protocol peer, PKI allows for secure binding between keys and protocol-specific names, such as email addresses, and hence enables security services such as data and peer authentication, data integrity, and confidentiality (encryption).
公開キーインフラストラクチャ（PKI）とは、他のキー保有者に公開キー証明書を発行する認定当局（CAS）に基づいたキー管理の種類を指します。トラストアンカー（CA公開鍵のローカル信頼できるコピー）から一部のプロトコルピアの公開鍵にチェーンすることにより、PKIはキーと電子メールアドレスなどのプロトコル固有の名前の間の安全なバインディングを可能にするため、セキュリティサービスが可能になります。データやピア認証、データの整合性、機密性（暗号化）など。
The main Internet standard for PKI is [RFC5280], which is a profile of the X.509 public key certificate format. There are a range of private and commercial CAs operating today providing the ability to manage and securely distribute keys for all protocols that use public key certificates, e.g., TLS and S/MIME. In addition to the profile standard, the PKIX working group has defined a number of management protocols (e.g., [RFC5272] and [RFC4210]) as well as protocols for handling revocation of public key certificates such as the Online Certificate Status Protocol (OCSP) [RFC2560].
PKIの主なインターネット標準は[RFC5280]であり、X.509公開キー証明書形式のプロファイルです。現在、公開キー証明書など、TLSやS/MIMEを使用するすべてのプロトコルのキーを管理および安全に配布する機能を提供する、現在、さまざまなプライベートおよび商業用のCAが運営されています。プロファイル標準に加えて、PKIXワーキンググループは、オンライン証明書ステータスプロトコル（OCSP）などの公開キー証明書の取り消しを処理するためのプロトコルと同様に、多くの管理プロトコル（[RFC5272]および[RFC4210]など）を定義しています。[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.
Kerberos Network認証システム[RFC4120]は、一般的に組織内で、認証、承認、およびポリシーを1か所で集中化するために使用されます。Kerberosは、認証の基礎としてユーザー名とパスワードをネイティブにサポートしています。Kerberos（Pkinit）[RFC4556]の初期認証のための公開キー暗号化により、Kerberosは証明書または公開キーベースの認証をサポートしています。これは、証明書の検証と証明書のマッピングに関するポリシーを1つの場所でユーザーアカウントに集中することにより、利点を提供する場合があります。GSS-API [RFC1964] [RFC2743] [RFC4121]を介して、Kerberosを使用してほとんどのアプリケーションの認証を管理できます。Kerberosは組織や企業内で最適に機能しますが、管理ドメイン間で認証を共有できる施設があります。
The IPS specifies two network layer protocols: IPv4 and IPv6. The following sections describe the IETF's coexistence and transition mechanisms for IPv4 and IPv6.
IPSは、IPv4とIPv6の2つのネットワークレイヤープロトコルを指定します。次のセクションでは、IETFのIPv4およびIPv6の遷移メカニズムについて説明します。
Note that on 3 February 2011, the IANA's IPv4 free pool (the pool of available, unallocated IPv4 addresses) was exhausted, and the Regional Internet Registrars' (RIRs') free pools are expected to be exhausted during the coming year, if not sooner. The IETF, the IANA, and the RIRs recommend that new deployments use IPv6, and that IPv4 infrastructures be supported via the mechanisms described in Section 3.2.1.
2011年2月3日に、IANAのIPv4フリープール（利用可能な未割り当てのIPv4アドレスのプール）が使い果たされ、地域のインターネットレジストラ（RIRS '）フリープールは、来年には疲れ果てていると予想されます。。IETF、IANA、およびRIRSは、新しい展開がIPv6を使用することを推奨し、セクション3.2.1で説明したメカニズムを介してIPv4インフラストラクチャをサポートすることを推奨します。
The IETF has specified a variety of mechanisms designed to facilitate IPv4/IPv6 coexistence. The IETF actually recommends relatively few of them: the current advice to network operators is found in Guidelines for Using IPv6 Transition Mechanisms [RFC6180]. The thoughts in that document are replicated here.
IETFは、IPv4/IPv6共存を促進するように設計されたさまざまなメカニズムを指定しています。IETFは実際には比較的少数を推奨しています。ネットワークオペレーターへの現在のアドバイスは、IPv6遷移メカニズム[RFC6180]を使用するためのガイドラインにあります。そのドキュメントの考えはここで再現されています。
The simplest coexistence approach is to
最も単純な共存アプローチは次のとおりです
o provide a network that routes both IPv4 and IPv6,
o IPv4とIPv6の両方をルーティングするネットワークを提供します。
o ensure that servers and their applications similarly support both protocols, and
o サーバーとそのアプリケーションが同様に両方のプロトコルをサポートしていることを確認し、
o require that all new systems and applications purchased or upgraded support both protocols.
o 購入またはアップグレードされたすべての新しいシステムとアプリケーションが両方のプロトコルをサポートする必要があります。
The net result is that over time all systems become protocol agnostic, and that eventually maintenance of IPv4 support becomes a business decision. This approach is described in the Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213].
最終的な結果は、時間の経過とともにすべてのシステムがプロトコル不可欠なものになり、最終的にIPv4サポートのメンテナンスがビジネス上の決定になることです。このアプローチは、IPv6ホストとルーターの基本的な遷移メカニズムで説明されています[RFC4213]。
In those places in the network that support only IPv4, the simplest and most reliable approach to coexistence is to provide virtual connectivity using tunnels or encapsulations. Early in IPv6 deployment, this was often done using static tunnels. A more dynamic approach is documented in IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5569].
IPv4のみをサポートするネットワーク内のこれらの場所では、共存に対する最も単純で信頼できるアプローチは、トンネルまたはカプセルを使用して仮想接続を提供することです。IPv6の展開の初期段階では、これは静的トンネルを使用して行われることがよくありました。より動的なアプローチは、IPv4インフラストラクチャ（6番目）[RFC5569]の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.
IPv4のみのホストがIPv6のみのホストと通信したい場合（またはその逆）、プロトコル翻訳の必要性が示される場合があります。最初は、プロトコルの翻訳が些細なように見えるかもしれません。より深い検査では、プロトコルの翻訳が複雑になる可能性があることがわかります。
The most reliable approach to protocol translation is to provide application layer proxies or gateways, which natively enable application-to-application connections using both protocols and can use whichever is appropriate. For example, a web proxy might use both protocols and as a result enable an IPv4-only system to run HTTP across an IPv6-only network or to a web server that implements only IPv6. Since this approach is a service of a protocol-agnostic server, it is not the subject of standardization by the IETF.
プロトコル変換に対する最も信頼できるアプローチは、アプリケーションレイヤープロキシまたはゲートウェイを提供することです。これにより、両方のプロトコルを使用してアプリケーションとアプリケーションへの接続をネイティブに有効にし、適切な方を使用できます。たとえば、Webプロキシは両方のプロトコルを使用し、その結果、IPv4のみのシステムがIPv6のみのネットワークでHTTPまたはIPv6のみを実装するWebサーバーに実行できるようにする場合があります。このアプローチはプロトコルに依存しないサーバーのサービスであるため、IETFによる標準化の対象ではありません。
For those applications in which network layer translation is indicated, the IETF has designed a translation mechanism, which is described in the following documents:
ネットワーク層の翻訳が示されているアプリケーションについては、IETFは次のドキュメントで説明されている翻訳メカニズムを設計しています。
o Framework for IPv4/IPv6 Translation [RFC6144]
o IPv4/IPv6翻訳のフレームワーク[RFC6144]
o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]
o IPv4/IPv6翻訳者のアドレス指定[RFC6052]
o DNS extensions [RFC6147]
o DNS拡張機能[RFC6147]
o IP/ICMP Translation Algorithm [RFC6145]
o IP/ICMP翻訳アルゴリズム[RFC6145]
o Translation from IPv6 Clients to IPv4 Servers [RFC6146] 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.
o IPv6クライアントからIPv4サーバー[RFC6146]への翻訳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アドレスとIPv4アドレスを埋め込んだIPv4アドレスとIPv4/IPv4アドレス間のIPv4/IPv4翻訳と同様のステートフルな翻訳の2種類のサービスを2種類のサービスに提供します。ステートレスモードは実装するのが簡単ですが、埋め込みにより、IPv4アドレスをIPv6のみのネットワークに割り当てる必要があり、主にIPv6ネットワークで実装されたIPv4-アクセス可能なサーバーに役立ちます。Statefulモードにより、IPv6ネットワーク内のクライアントはIPv4ネットワークのサーバーにアクセスできますが、IPv4クライアントにIPv6ピアまたは一般的なアドレスを持つサーバーにアクセスするためにそのようなサービスを提供しません。このメカニズムを使用して、ホストのIPv6アドレスに一意のIPv4アドレスを埋め込む必要がないという利点があります。
Finally, note that some site networks are IPv6 only while some transit networks are IPv4 only. In these cases, it may be necessary to tunnel IPv6 over IPv4 or translate between IPv6 and IPv4.
最後に、一部のサイトネットワークはIPv6のみであり、一部のトランジットネットワークはIPv4のみであることに注意してください。これらの場合、IPv4を介してIPv6をトンネルするか、IPv6とIPv4を翻訳する必要がある場合があります。
IPv4 [RFC0791] and the Internet Control Message Protocol (ICMP) [RFC0792] comprise the IPv4 network layer. IPv4 provides unreliable delivery of datagrams.
IPv4 [RFC0791]およびインターネット制御メッセージプロトコル（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 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.
IPv4はもともと、軍事電話の要件の後にスタイルが整った8つのレベルの運用上の優先順位を特定した実験的なタイプのサービスフィールドをサポートしました。[RFC2328]は、コントロールトラフィックと解釈されます。このコントロールトラフィックは、他のトラフィックが削除されていても、キュー時代または受領時に削除されないことが保証されています。これらのコントロールビットは、デザイナーが望んでいたよりも有用ではないことが判明しました。それらは、データグラムに適用されるアルゴリズム（「PERホップの動作」）を選択するために使用される6ビットコードポイントを含む、差別化されたサービスアーキテクチャ[RFC2474] [RFC2475]に置き換えられました。IETFは、DiffServサービスクラス[RFC4594]の構成ガイドラインのセットも作成しました。これは、ネットワークオペレーターに役立つ可能性のあるサービスクラスのセットを説明しています。
IPv4 addresses are administratively assigned, usually using automated methods, using the Dynamic Host Configuration Protocol (DHCP) [RFC2131]. On most interface types, neighboring systems identify each others' addresses using the Address Resolution Protocol (ARP) [RFC0826].
IPv4アドレスは、通常は自動化されたメソッドを使用して、動的ホスト構成プロトコル（DHCP）[RFC2131]を使用して管理上割り当てられます。ほとんどのインターフェイスタイプでは、隣接するシステムは、アドレス解像度プロトコル（ARP）[RFC0826]を使用して互いのアドレスを識別します。
Routing for the IPv4 Internet is accomplished by routing applications that exchange connectivity information and build semi-static destination routing databases. If a datagram is directed to a given destination address, the address is looked up in the routing database, and the most specific ("longest") prefix found that contains it is used to identify the next-hop router or the end system to which it will be delivered. This is not generally implemented on hosts, although it can be; a host normally sends datagrams to a router on its local network, and the router carries out the intent.
IPv4インターネットのルーティングは、接続性情報を交換し、半静的な宛先ルーティングデータベースを構築するアプリケーションをルーティングすることによって達成されます。データグラムが特定の宛先アドレスに向けられている場合、アドレスはルーティングデータベースで検索され、最も具体的な（「最長」）プレフィックスが含まれていることがわかりました。配信されます。これは一般にホストに実装されていませんが、可能です。ホストは通常、ローカルネットワーク上のルーターにデータグラムを送信し、ルーターは意図を実行します。
IETF specified routing protocols include RIP Version 2 [RFC2453], OSI IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4 [RFC4271]. Active research exists in mobile ad hoc routing and other routing paradigms; these result in new protocols and modified forwarding paradigms.
IETF指定されたルーティングプロトコルには、RIPバージョン2 [RFC2453]、IPv4 [RFC1195]のOSI IS、OSPFバージョン2 [RFC2328]、およびBGP-4 [RFC4271]が含まれます。モバイルアドホックルーティングやその他のルーティングパラダイムには、アクティブな研究が存在します。これらは、新しいプロトコルと転送パラダイムを変更します。
IPv4 was originally specified as a unicast (point to point) protocol, and was extended to support multicast in [RFC1112]. This uses the Internet Group Management Protocol [RFC3376] [RFC4604] to enable applications to join multicast groups, and for most applications uses Source-Specific Multicast [RFC4607] for routing and delivery of multicast messages.
IPv4はもともとユニキャスト（ポイントトゥポイント）プロトコルとして指定されており、[RFC1112]のマルチキャストをサポートするために拡張されました。これは、インターネットグループ管理プロトコル[RFC3376] [RFC4604]を使用してマルチキャストグループに参加するアプリケーションを有効にし、ほとんどのアプリケーションでは、マルチキャストメッセージのルーティングと配信にソース固有のマルチキャスト[RFC4607]を使用します。
An experiment carried out in IPv4 that is not part of the core Internet architecture but may be of interest in the Smart Grid is the development of so-called "Reliable Multicast". This is "so-called" because it is not "reliable" in the strict sense of the word -- it is perhaps better described as "enhanced reliability". A best effort network by definition can lose traffic, duplicate it, or reorder it, something as true for multicast as for unicast. Research in
コアインターネットアーキテクチャの一部ではないが、スマートグリッドに関心がある可能性があるIPv4で実施された実験は、いわゆる「信頼できるマルチキャスト」の開発です。これは、単語の厳格な意味では「信頼性が高い」わけではないため、「いわゆる」ものです。おそらく「信頼性の強化」と呼ばれる方が良いでしょう。定義上、最良の努力ネットワークは、トラフィックを失いたり、複製したり、並べ替えたりすることができます。これは、ユニキャストと同様にマルチキャストに当てはまります。研究
"Reliable Multicast" technology intends to improve the probability of delivery of multicast traffic.
「信頼性の高いマルチキャスト」テクノロジーは、マルチキャストトラフィックの配信確率を改善する予定です。
In that research, the IETF imposed guidelines [RFC2357] on the research community regarding what was desirable. Important results from that research include a number of papers and several proprietary protocols including some that have been used in support of business operations. RFCs in the area include The Use of Forward Error Correction (FEC) in Reliable Multicast [RFC3453], the Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) [RFC4410].
その研究では、IETFは、何が望ましいものかに関する研究コミュニティにガイドライン[RFC2357]を課しました。その研究の重要な結果には、多くの論文と、事業運営をサポートするために使用されているものを含むいくつかの独自のプロトコルが含まれます。この地域のRFCには、信頼性の高いマルチキャスト[RFC3453]でのフォワードエラー補正（FEC）の使用、ネガティブクーナル留置（NACK）指向の信頼できるマルチキャスト（NORM）プロトコル[RFC5740]、および選択的に信頼できる信頼できるマルチキャストプロトコル（SRMP）[RFC4410]。
IPv6 [RFC2460], with the Internet Control Message Protocol "v6" [RFC4443], constitutes the next generation protocol for the Internet. IPv6 provides for transmission of datagrams from source to destination hosts, which are identified by fixed-length addresses.
IPv6 [RFC2460]は、インターネット制御メッセージプロトコル「V6」[RFC4443]を使用して、インターネットの次世代プロトコルを構成します。IPv6は、ソースから宛先ホストへのデータグラムの送信を提供します。これは、固定長のアドレスによって識別されます。
IPv6 also provides for fragmentation and reassembly of long datagrams by the originating host, if necessary, for transmission through "small packet" networks. ICMPv6, which is a separate protocol implemented along with IPv6, enables the network to report errors and other issues to hosts that originate problematic datagrams.
IPv6は、「小型パケット」ネットワークを介した送信のために、必要に応じて、発信元のホストによる長いデータグラムの断片化と再組み立ても提供します。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.
IPv6は、データグラムに適用されるアルゴリズム（「PERホップの動作」）を選択するために使用される6ビットコードポイントを含む、差別化されたサービスアーキテクチャ[RFC2474] [RFC2475]を採用しました。
The IPv6 over Low-Power Wireless Personal Area Networks RFC [RFC4919] and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks document [6LOWPAN-HC] addresses IPv6 header compression and subnet architecture in at least some sensor networks, and may be appropriate to the Smart Grid Advanced Metering Infrastructure or other sensor domains.
低電力ワイヤレスパーソナルエリアネットワークRFC [RFC4919]を超えるIPv6のIPv6データグラムの圧縮形式は、6lowpanネットワークドキュメント[6lowpan-HC]の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アドレスもAutoConfiguredを使用できます。Autoconfigurationは、さまざまなユースケースで有利になる可能性のあるネットワーク管理のさまざまなモデルを可能にします。自動構成手順は、[RFC4862]および[RFC4941]で定義されています。IPv6の隣人は、Neighbor Discovery（ND）[RFC4861]を使用して互いのアドレスを識別します。セキュアネイバーディスカバリー（送信）[RFC3971]を使用して、これらの操作を保護することができます。
Routing for the IPv6 Internet is accomplished by routing applications that exchange connectivity information and build semi-static destination routing databases. If a datagram is directed to a given destination address, the address is looked up in the routing database, and the most specific ("longest") prefix found that contains it is used to identify the next-hop router or the end system to which it will be delivered. Routing is not generally implemented on hosts (although it can be); generally, a host sends datagrams to a router on its local network, and the router carries out the intent.
IPv6インターネットのルーティングは、接続性情報を交換し、半静的な宛先ルーティングデータベースを構築するアプリケーションをルーティングすることによって達成されます。データグラムが特定の宛先アドレスに向けられている場合、アドレスはルーティングデータベースで検索され、最も具体的な（「最長」）プレフィックスが含まれていることがわかりました。配信されます。ルーティングは通常、ホストに実装されていません（ただしますが）。一般に、ホストはローカルネットワーク上のルーターにデータグラムを送信し、ルーターは意図を実行します。
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 [RFC5308]のIS-IS、IPv6 [RFC5340]のOSPF、IPv6 [RFC2545]のBGP-4が含まれます。モバイルアドホックルーティング、低電力ネットワーク（センサーとスマートグリッド）のルーティング、およびその他のルーティングパラダイムには、アクティブな研究が存在します。これらは、新しいプロトコルと転送パラダイムを変更します。
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 [RFC2080]およびRIPバージョン2 [RFC2453]にRIPNGを展開する傾向があります。簡単に言えば、RIPは、広く知られているBellman-Fordアルゴリズムの分散バリアントに基づいた距離ベクトルルーティングプロトコルです。距離ベクトルルーティングプロトコルでは、各ルーターがルートテーブルの内容を隣接するルーターに発表し、結果をルートテーブルと統合し、他の人に再び解放します。それは「噂によるルーティング」として特徴付けられており、人間のゴシップで私たちが見つけた多くの病気に苦しんでいます - 特定の障害シナリオで古くなったり誤った情報を繁殖させたり、トポロジの変化に反応しない場合。[RFC1058]は、これらの問題を軽減するためにアルゴリズム設計者にガイダンスを提供します。
The Open Shortest Path First (OSPF) routing protocol is one of the more widely used protocols in the Internet. OSPF is based on Dijkstra's well known Shortest Path First (SPF) algorithm. It is implemented as OSPF Version 2 [RFC2328] for IPv4, OSPF for IPv6 [RFC5340] for IPv6, and the Support of Address Families in OSPFv3 [RFC5838] to enable [RFC5340] routing both IPv4 and IPv6.
Open Shortest Path First（OSPF）ルーティングプロトコルは、インターネットで最も広く使用されているプロトコルの1つです。OSPFは、Dijkstraのよく知られている最短経路First（SPF）アルゴリズムに基づいています。IPv4のOSPFバージョン2 [RFC2328]、IPv6のIPv6 [RFC5340]のOSPF、およびOSPFv3 [RFC5838]の住所ファミリーのサポートとして実装され、[RFC5340]を有効にします。
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ベースのプロトコルの欠点は、各ルーターがドメイン内の各ルーターの接続性に関する一人称声明を保存する必要があることです。
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）ルーティングプロトコルは、インターネットで最も広く使用されているプロトコルの1つです。IS-ISは、Dijkstraの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のポジティブは、主にネットワークがサブネットおよび分離ホストへの接続性を備えたルーターの格子として説明されていることです。ルーティングドメイン内のすべてのホストには、ドメイン内の各ルーターの接続性に関する一人称声明があるため、「噂によるルーティング」の問題なしに、単に変更を発表することで、トポロジーが迅速かつ簡単に変更されます。ネガは結果です。各ルーターは、ドメイン内の各ルーターの接続性に関する一人称声明を保存する必要があります。
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.
Border Gateway Protocol（BGP）[RFC4271]は、IPv4インターネットで広く使用されており、特定のポリシーを適用しながら、サービスプロバイダー、ピア、上流のネットワーク、および顧客などの管理エンティティ間のルートを交換します。Multiprotocol拡張[RFC4760]からBGPからBGPにより、BGPはIPv6間ドメインルーティング[RFC2545]、マルチキャストの到達可能性情報、およびVPN情報を運ぶことができます。
Considerations that apply with BGP deal with the flexibility and complexity of the policies that must be defined. Flexibility is a good thing; in a network that is not run by professionals, the complexity is burdensome.
BGPに適用される考慮事項は、定義する必要があるポリシーの柔軟性と複雑さに対処します。柔軟性は良いことです。専門家によって実行されていないネットワークでは、複雑さは負担です。
The Mobile Ad Hoc working group of the IETF developed, among other protocols, Ad hoc On-Demand Distance Vector (AODV) Routing [RFC3561]. This protocol captured the minds of some in the embedded devices industry, but experienced issues in wireless networks such as 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].
IETFのモバイルアドホックワーキンググループは、他のプロトコルの中でも、アドホックオンデマンド距離ベクトル（AODV）ルーティング[RFC3561]を開発しました。このプロトコルは、組み込みデバイス業界の一部の心を捉えましたが、802.15.4や802.11のアドホックモードなどのワイヤレスネットワークで問題を経験しました。その結果、ダイナミックマネのオンデマンド（DYMO）ルーティングプロトコル[DYMO]で更新される過程にあります。
AODV and DYMO are essentially reactive routing protocols designed for mobile ad hoc networks, and usable in other forms of ad hoc networks. They provide connectivity between a device within a distributed subnet and a few devices (including perhaps a gateway or router to another subnet) without tracking connectivity to other devices. In essence, routing is calculated and discovered upon need, and a host or router need only maintain the routes that currently work and are needed.
AODVとDymoは、モバイルアドホックネットワーク向けに設計された本質的にリアクティブルーティングプロトコルであり、他の形式のアドホックネットワークで使用可能です。他のデバイスへの接続を追跡せずに、分散サブネット内のデバイスといくつかのデバイス（おそらく別のサブネットへのゲートウェイまたはルーターを含む）間の接続を提供します。本質的に、ルーティングは必要に応じて計算および発見され、ホストまたはルーターは現在機能し、必要なルートのみを維持する必要があります。
The Optimized Link State Routing Protocol (OLSR) [RFC3626] is a proactive routing protocol designed for mobile ad hoc networks, and can be used in other forms of ad hoc networks. It provides arbitrary connectivity between systems within a distributed subnet. As with protocols designed for wired networks, routing is calculated whenever changes are detected, and maintained in each router's tables. The set of nodes that operate as routers within the subnet, however, are fairly fluid, and dependent on this instantaneous topology of the subnet.
最適化されたリンク状態ルーティングプロトコル（OLSR）[RFC3626]は、モバイルアドホックネットワーク向けに設計されたプロアクティブルーティングプロトコルであり、アドホックネットワークの他の形式で使用できます。分散サブネット内のシステム間の任意の接続を提供します。有線ネットワーク用に設計されたプロトコルと同様に、ルーティングは変更が検出されるたびに計算され、各ルーターのテーブルで維持されます。ただし、サブネット内のルーターとして動作するノードのセットは、かなり流動的であり、サブネットのこの瞬間的なトポロジーに依存します。
The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [RPL] is a reactive routing protocol designed for use in resource constrained networks. Requirements for resource constrained networks are defined in [RFC5548], [RFC5673], [RFC5826], and [RFC5867].
低電力および損失ネットワーク（RPL）[RPL]用のIPv6ルーティングプロトコルは、リソース制約ネットワークで使用するために設計されたリアクティブルーティングプロトコルです。リソース制約ネットワークの要件は、[RFC5548]、[RFC5673]、[RFC5826]、および[RFC5867]で定義されています。
Briefly, a constrained network is comprised of nodes that:
簡単に言えば、制約されたネットワークは次のノードで構成されています。
o Are built with limited processing power and memory, and sometimes energy when operating on batteries.
o 制限された処理能力とメモリ、およびバッテリーで動作するときにエネルギーで構築されます。
o Are interconnected through a low-data-rate network interface and are potentially vulnerable to communication instability and low packet delivery rates.
o 低データレートネットワークインターフェイスを介して相互接続されており、通信不安定性と低パケット配信率に対して脆弱になる可能性があります。
o Potentially have a mix of roles such as being able to act as a host (i.e., generating traffic) and/or a router (i.e., both forwarding and generating RPL traffic).
o 潜在的に、ホスト（つまり、トラフィックを生成する）やルーター（つまり、転送とRPLトラフィックの両方の両方）として行動できるなどの役割が混在しています。
IPv6 specifies both unicast and multicast datagram exchange. This uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] [RFC3590] [RFC3810] [RFC4604] to enable applications to join multicast groups, and for most applications uses Source-Specific Multicast [RFC4607] for routing and delivery of multicast messages.
IPv6は、ユニキャストとマルチキャストの両方のデータグラム交換の両方を指定します。これは、マルチキャストリスナーディスカバリープロトコル（MLDV2）[RFC2710] [RFC3590] [RFC3810] [RFC4604]を使用して、アプリケーションがマルチキャストグループに参加できるようにします。
The mechanisms experimentally developed for reliable multicast in IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.
セクション3.2.2.3で説明されているIPv4の信頼性の高いマルチキャスト用に実験的に開発されたメカニズムもIPv6で使用できます。
A multicast routing protocol has two basic functions: building the multicast distribution tree and forwarding multicast traffic. Multicast routing protocols generally contain a control plane for building distribution trees, and a forwarding plane that uses the distribution tree when forwarding multicast traffic.
マルチキャストルーティングプロトコルには、マルチキャストディストリビューションツリーの構築とマルチキャストトラフィックの転送という2つの基本的な機能があります。マルチキャストルーティングプロトコルには、通常、配布ツリーを構築するための制御プレーンと、マルチキャストトラフィックを転送するときに配布ツリーを使用する転送面が含まれています。
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モデルでは、どのホストもグループに送信し、ドメイン間マルチキャストが困難でした。プロトコル独立マルチキャストなどのプロトコル - 密度モード（PIM -DM）：プロトコル仕様（改訂）[RFC3973]およびプロトコル独立したマルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）[RFC4601]は、ASMモデル向けに設計されました。。
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モデルでは、ホストはソースとグループ（g）で構成される「チャネル」に関心を表明します。分布ツリーは、送信ホスト（「（s、g）ツリー」と呼ばれる）に根ざしています。ソースSのみがグループに送信できるため、SSMには固有のアンチジャミング機能があります。さらに、ドメイン間マルチキャストは、受信に関心のある（s、g）チャネルが（ネットワークではなく）レシーバーの責任であることを見つけるため、簡素化されます。これは、SSMが何らかの形のディレクトリサービスを必要とすることを意味し、レシーバーが（s、g）チャネルを見つけることができるようにします。
In general, the layered architecture of the Internet enables the IPS to run over any appropriate layer two architecture. The ability to change the link or physical layer without having to rethink the network layer, transports, or applications has been a great benefit in the Internet.
一般に、インターネットの階層化されたアーキテクチャにより、IPSは適切なレイヤー2アーキテクチャを実行できます。ネットワークレイヤー、トランスポート、またはアプリケーションを再考することなくリンクまたは物理レイヤーを変更する機能は、インターネットで大きな利益をもたらしました。
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は、[RFC0894]を使用して、イーサネットヘッダー（10および100 Mbpsの有線イーサネット、1および10 Gbps有線イーサネット、IEEE 802.11のさまざまなバージョンを使用する各リンクレイヤー環境で実行されています。IPv6は[RFC2464]を使用して同じことをします。
PPP: The IETF has defined a serial line protocol, the Point-to-Point Protocol (PPP) [RFC1661], that uses High-Level Data Link Control (bit-synchronous or byte synchronous) framing. The IPv4 adaptation specification is [RFC1332], and the IPv6 adaptation specification is [RFC5072]. Current use of this protocol is in traditional serial lines, authentication exchanges in DSL networks using PPP Over Ethernet (PPPoE) [RFC2516], and the Digital Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH) using PPP over SONET/SDH [RFC2615].
PPP：IETFは、高レベルのデータリンクコントロール（ビット同期またはバイト同期）フレーミングを使用するシリアルラインプロトコル、ポイントツーポイントプロトコル（PPP）[RFC1661]を定義しました。IPv4適応仕様は[RFC1332]であり、IPv6適応仕様は[RFC5072]です。このプロトコルの現在の使用は、従来のシリアルライン、イーサネット上のPPPを使用したDSLネットワークの認証交換[RFC2516]、およびSONET/over Sonet/上のPPPを使用したデジタルシグナル伝達階層（一般にパケットオンソネット/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.
ATM、フレームリレー、X.25、その他の標準化された独自のLANテクノロジーなど、他の多くの適応仕様が存在します。
This section outlines the functionality of UDP, TCP, SCTP, and DCCP. UDP and TCP are best known and most widely used in the Internet today, while SCTP and DCCP are newer protocols that were built for specific purposes. Other transport protocols can be built when required.
このセクションでは、UDP、TCP、SCTP、およびDCCPの機能の概要を説明します。UDPとTCPは最もよく知られており、今日ではインターネットで最も広く使用されていますが、SCTPとDCCPは特定の目的で構築された新しいプロトコルです。必要に応じて、他の輸送プロトコルを構築できます。
The User Datagram Protocol [RFC0768] and the Lightweight User Datagram Protocol [RFC3828] are properly not "transport" protocols in the sense of "a set of rules governing the exchange or transmission of data electronically between devices". They are labels that provide for multiplexing of applications directly on the IP layer, with transport functionality embedded in the application.
ユーザーデータグラムプロトコル[RFC0768]および軽量ユーザーデータグラムプロトコル[RFC3828]は、「デバイス間でデータの交換またはデータの交換または送信を管理するルールのセット」という意味で、「輸送」プロトコルではありません。これらは、アプリケーションに輸送機能が埋め込まれているIPレイヤー上のアプリケーションのマルチプレックスを直接提供するラベルです。
Many exchange designs have been built using UDP, and many of them have not worked out. As a result, the use of UDP really should be treated as designing a new transport. Advice on the use of UDP in new applications can be found in Unicast UDP Usage Guidelines for Application Designers [RFC5405].
多くの交換デザインはUDPを使用して構築されており、それらの多くは解決していません。その結果、UDPの使用は本当に新しい輸送機関の設計として扱われるべきです。新しいアプリケーションでのUDPの使用に関するアドバイスは、アプリケーションデザイナーのユニキャストUDP使用ガイドライン[RFC5405]に記載されています。
Datagram Transport Layer Security [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery for applications that run over UDP. Alternatively, UDP can run over IPsec.
Datagramトランスポートレイヤーセキュリティ[RFC5238]を使用して、UDPを介して実行されるアプリケーションの盗聴、改ざん、またはメッセージ偽造を防ぐことができます。または、UDPはIPSECを介して実行できます。
TCP [RFC0793] is the predominant transport protocol used in the Internet. It is "reliable", as the term is used in protocol design: it delivers data to its peer and provides acknowledgement to the sender, or it dies trying. It has extensions for Congestion Control [RFC5681] and Explicit Congestion Notification [RFC3168].
TCP [RFC0793]は、インターネットで使用される主要な輸送プロトコルです。この用語はプロトコル設計で使用されているため、「信頼性が高く」。これは、ピアにデータを配信し、送信者に謝辞を提供するか、試して死ぬ。混雑制御[RFC5681]および明示的な輻輳通知[RFC3168]の拡張機能があります。
The user interface for TCP is a byte stream interface -- an application using TCP might "write" to it several times only to have the data compacted into a common segment and delivered as such to its peer. For message-stream interfaces, ACSE/ROSE uses the ISO Transport Service on TCP [RFC1006][RFC2126] in the application.
TCPのユーザーインターフェイスはバイトストリームインターフェイスです。TCPを使用するアプリケーションは、データを共通セグメントにコンパクトし、そのようにピアに配信するために数回だけ「書き込む」ことができます。メッセージストリームインターフェイスの場合、ACSE/Roseは、アプリケーションでTCP [RFC1006] [RFC2126]のISO輸送サービスを使用します。
Transport Layer Security [RFC5246] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, TCP can run over IPsec. Additionally, [RFC4987] discusses mechanisms similar to SCTP's and DCCP's "cookie" approach that may be used to secure TCP sessions against flooding attacks.
輸送層のセキュリティ[RFC5246]を使用して、盗聴、改ざん、またはメッセージ偽造を防ぐことができます。または、TCPはIPSECを介して実行できます。さらに、[RFC4987]は、洪水攻撃に対するTCPセッションを確保するために使用できるSCTPおよびDCCPの「Cookie」アプローチに似たメカニズムについて説明します。
Finally, note that TCP has been the subject of ongoing research and development since it was written. The Roadmap for TCP Specification Documents [RFC4614] captures this history, and is intended to be a guide to current and future developers in the area.
最後に、TCPは書かれてから進行中の研究開発の対象であることに注意してください。TCP仕様文書[RFC4614]のロードマップは、この歴史を捉えており、この地域の現在および将来の開発者のガイドになることを目的としています。
SCTP [RFC4960] is a more recent reliable transport protocol that can be imagined as a TCP-like context containing multiple separate and independent message streams (unlike TCP's byte streams). The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. As it uses a message stream interface, it may also be more appropriate for the ISO Transport Service than using RFC 1006/2126 to turn TCP's octet streams into a message interface.
SCTP [RFC4960]は、複数の個別の独立したメッセージストリームを含むTCP様コンテキストとして想像できる、より最近の信頼性の高い輸送プロトコルです（TCPのバイトストリームとは異なります）。SCTPの設計には、適切な混雑回避行動と洪水および仮面舞踏会攻撃に対する抵抗が含まれます。メッセージストリームインターフェイスを使用するため、RFC 1006/2126を使用してTCPのOctetストリームをメッセージインターフェイスに変えるよりも、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にはいくつかの配信オプションがあります。基本サービスは、使用中のストリームごとに、ストリーム内のメッセージの連続的に複製されていない配信です。ストリームは独立しているため、1つのストリームが頭のブロックのために一時停止する場合がありますが、同じセッションの別のストリームがデータを提供し続けます。さらに、SCTPは、シーケンスされた配信サービスをバイパスするためのメカニズムを提供します。このメカニズムを使用して送信されるユーザーメッセージは、受信したらすぐにSCTPユーザーに配信されます。
SCTP implements a simple "cookie" mechanism intended to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer. Mechanisms also exist for Dynamic Address Reconfiguration [RFC5061], enabling peers to change addresses during the session and yet retain connectivity. Transport Layer Security [RFC3436] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, SCTP can run over IPsec.
SCTPは、相互認証による洪水攻撃の有効性を制限することを目的とした単純な「Cookie」メカニズムを実装しています。これは、アプリケーションが同じピアに接続されているが、ピアを識別しないことを示しています。動的アドレス再構成[RFC5061]にはメカニズムも存在し、ピアがセッション中にアドレスを変更し、接続性を保持できるようにします。輸送層のセキュリティ[RFC3436]を使用して、盗聴、改ざん、またはメッセージ偽造を防ぐことができます。または、SCTPはIPSECを介して実行できます。
DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that does not guarantee message delivery) that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.
DCCP [RFC4340]は、輻輳制御された信頼性のないデータグラムの双方向ユニキャスト接続を提供する「信頼できない」輸送プロトコル（例：メッセージ配信を保証しないもの）です。DCCPは、かなり大量のデータを転送し、適時性と信頼性の間のトレードオフの制御から利益を得ることができるアプリケーションに適しています。
DCCP implements a simple "cookie" mechanism intended to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer. Datagram Transport Layer Security [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, DCCP can run over IPsec.
DCCPは、相互認証による洪水攻撃の有効性を制限することを目的とした単純な「Cookie」メカニズムを実装しています。これは、アプリケーションが同じピアに接続されているが、ピアを識別しないことを示しています。データグラムトランスポートレイヤーセキュリティ[RFC5238]を使用して、盗聴、改ざん、またはメッセージ偽造を防ぐことができます。または、DCCPがIPSECを介して実行できます。
In order to facilitate network management and operations, the Internet community has defined the Domain Name System (DNS) [RFC1034] [RFC1035]. Names are hierarchical: a name like example.com is found registered with a .com registrar, and within the associated network other names like baldur.cincinatti.example.com can be defined, with obvious hierarchy. Security extensions, which allow a registry to sign the records it contains and in so doing demonstrate their authenticity, are defined by the DNS Security Extensions [RFC4033] [RFC4034] [RFC4035].
ネットワーク管理と運用を促進するために、インターネットコミュニティはドメイン名システム（DNS）[RFC1034] [RFC1035]を定義しました。名前は階層です：example.comのような名前は.comレジストラに登録されています。関連ネットワーク内では、Baldur.cincinatti.example.comのような他の名前を明確に定義できます。レジストリが含まれるレコードに署名することを可能にするセキュリティ拡張機能は、その信頼性を実証することで、DNSセキュリティエクステンション[RFC4033] [RFC4034] [RFC4035]によって定義されます。
Devices can also optionally update their own DNS record. For example, a sensor that is using Stateless Address Autoconfiguration [RFC4862] to create an address might want to associate it with a name using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update [RFC3007].
デバイスは、オプションで独自のDNSレコードを更新することもできます。たとえば、ステートレスアドレスAutoconfiguration [RFC4862]を使用してアドレスを作成しているセンサーは、DNSダイナミックアップデート[RFC2136]またはDNSセキュアダイナミックアップデート[RFC3007]を使用して名前を付けることをお勧めします。
As discussed in Section 3.2.2, IPv4 address assignment is generally performed using DHCP [RFC2131]. By contrast, Section 3.2.3 points out that IPv6 address assignment can be accomplished using either autoconfiguration [RFC4862] [RFC4941] or DHCPv6 [RFC3315]. The best argument for the use of autoconfiguration is a large number of systems that require little more than a random number as an address; the argument for DHCP is administrative control.
セクション3.2.2で説明したように、IPv4アドレスの割り当ては通常、DHCP [RFC2131]を使用して実行されます。対照的に、セクション3.2.3は、Autoconfiguration [RFC4862] [RFC4941]またはDHCPV6 [RFC3315]のいずれかを使用してIPv6アドレスの割り当てを達成できることを指摘しています。自動構成の使用に関する最良の議論は、アドレスとして乱数以外のものを必要とする多数のシステムです。DHCPの議論は管理制御です。
There are other parameters that may need to be allocated to hosts requiring administrative configuration; examples include the addresses of DNS servers, keys for Secure DNS, and Network Time servers.
管理構成を必要とするホストに割り当てる必要がある他のパラメーターがあります。例には、DNSサーバーのアドレス、安全なDNS用のキー、ネットワークタイムサーバーが含まれます。
The Network Time Protocol was originally designed by Dave Mills of the University of Delaware and CSNET, implementing a temporal metric in the Fuzzball Routing Protocol and generally coordinating time experiments. The current versions of the time protocol are the Network Time Protocol [RFC5905].
ネットワークタイムプロトコルは、もともとデラウェア大学とCSNETのデイブミルズによって設計され、ファズボールルーティングプロトコルで時間メートルートを実装し、一般的に時間実験を調整しました。Timeプロトコルの現在のバージョンは、ネットワークタイムプロトコル[RFC5905]です。
The IETF has developed two protocols for network management: SNMP and NETCONF. SNMP is discussed in Section 3.5.1, and NETCONF is discussed in Section 3.5.2.
IETFは、ネットワーク管理のための2つのプロトコルを開発しました：SNMPとNetConf。SNMPについてはセクション3.5.1で説明し、NetConfについてはセクション3.5.2で説明します。
The Simple Network Management Protocol, originally specified in the late 1980's and having passed through several revisions, is specified in several documents:
もともと1980年代後半に指定され、いくつかの改訂を通過したシンプルなネットワーク管理プロトコルは、いくつかのドキュメントで指定されています。
o An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks [RFC3411]
o シンプルなネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ[RFC3411]
o Message Processing and Dispatching [RFC3412]
o メッセージ処理と発送[RFC3412]
o SNMP Applications [RFC3413] o User-based Security Model (USM) for SNMP version 3 [RFC3414]
o SNMPアプリケーション[RFC3413] o SNMPバージョン3のユーザーベースのセキュリティモデル（USM）[RFC3414]
o View-based Access Control Model (VACM) [RFC3415]
o ビューベースのアクセス制御モデル（VACM）[RFC3415]
o Version 2 of the SNMP Protocol Operations [RFC3416]
o SNMPプロトコル操作のバージョン2 [RFC3416]
o Transport Mappings [RFC3417]
o 輸送マッピング[RFC3417]
o Management Information Base (MIB) [RFC3418]
o 管理情報ベース（MIB）[RFC3418]
It provides capabilities for polled and event-driven activities, and for both monitoring and configuration of systems in the field. Historically, it has been used primarily for monitoring nodes in a network. Messages and their constituent data are encoded using a profile of ASN.1.
ポーリングされたアクティビティとイベント主導のアクティビティ、およびフィールド内のシステムの監視と構成の両方に機能を提供します。歴史的には、主にネットワーク内のノードの監視に使用されてきました。メッセージとその構成データは、asn.1のプロファイルを使用してエンコードされます。
The NETCONF Configuration Protocol is specified in one basic document, with supporting documents for carrying it over the IPS. These documents include:
NetConf構成プロトコルは、1つの基本ドキュメントで指定されており、IPSに携帯するためのドキュメントをサポートしています。これらのドキュメントには以下が含まれます。
o NETCONF Configuration Protocol [RFC4741]
o NetConf構成プロトコル[RFC4741]
o Using the NETCONF Configuration Protocol over Secure SHell (SSH) [RFC4742]
o Secure Shell（SSH）を介したNetConf構成プロトコルを使用[RFC4742]
o Using NETCONF over the Simple Object Access Protocol (SOAP) [RFC4743]
o Simple Object Access Protocol（SOAP）[RFC4743]でNetConfを使用する
o Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) [RFC4744]
o ブロック上でNetConfプロトコルを使用して拡張可能な交換プロトコル（BEEP）[RFC4744]
o NETCONF Event Notifications [RFC5277]
o NetConfイベント通知[RFC5277]
o NETCONF over Transport Layer Security (TLS) [RFC5539]
o NetConf Over Transport Layer Security（TLS）[RFC5539]
o Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717]
o NetConf [RFC5717]の部分ロックリモートプロシージャコール（RPC）
NETCONF was developed in response to operator requests for a common configuration protocol based on ASCII text, unlike ASN.1. In essence, it carries XML-encoded remote procedure call (RPC) data. In response to Smart Grid requirements, there is consideration of a variant of the protocol that could be used for polled and event-driven management activities, and for both monitoring and configuration of systems in the field.
NetConfは、ASN.1とは異なり、ASCIIテキストに基づく一般的な構成プロトコルのオペレーター要求に応じて開発されました。本質的に、XMLエンコードされたリモートプロシージャコール（RPC）データが含まれています。スマートグリッドの要件に応じて、ポーリングやイベント主導の管理活動に使用できるプロトコルのバリアント、およびフィールド内のシステムの監視と構成の両方に考慮されます。
Service and resource discovery are among the most important protocols for constrained resource self-organizing networks. These include various sensor networks as well as the Home Area Networks (HANs), Building Area Networks (BANs), and Field Area Networks (FANs) envisioned by Smart Grid architects.
サービスとリソースの発見は、制約されたリソース自己組織化ネットワークの最も重要なプロトコルの1つです。これらには、さまざまなセンサーネットワーク、ホームエリアネットワーク（HANS）、ビルディングエリアネットワーク（BAN）、およびスマートグリッドアーキテクトが想定するフィールドエリアネットワーク（ファン）が含まれます。
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]。
Resource Discovery is concerned with the discovery of resources offered by end-points and is extremely important in machine-to-machine closed-loop applications (i.e., those with no humans in the loop). The goals of resource discovery protocols include:
リソースの発見は、エンドポイントによって提供されるリソースの発見に関係しており、機械間閉ループアプリケーション（つまり、ループに人間がない人）で非常に重要です。リソースディスカバリープロトコルの目標は次のとおりです。
o Simplicity of creation and maintenance of resources
o リソースの作成とメンテナンスのシンプルさ
o Commonly understood semantics
o よく理解されているセマンティクス
o Conformance to existing and emerging standards
o 既存および新興基準への適合
o International scope and applicability
o 国際的な範囲と適用性
o Extensibility
o 拡張性
o Interoperability among collections and indexing systems
o コレクションとインデックスシステム間の相互運用性
The Constrained Application Protocol (CoAP) [COAP] is being developed in IETF with these goals in mind. In particular, CoAP is designed for use in constrained resource networks and for machine-to-machine applications such as smart energy and building automation. It provides a RESTful transfer protocol [RESTFUL], a built-in resource discovery protocol, and includes web concepts such as URIs and content-types. CoAP provides both unicast and multicast resource discovery and includes the ability to filter on attributes of resource descriptions. Finally, CoAP resource discovery can also be used to discover HTTP resources.
制約付きアプリケーションプロトコル（COAP）[COAP]は、これらの目標を念頭に置いてIETFで開発されています。特に、COAPは、制約付きリソースネットワークで使用され、Smart EnergyやBuilding Automationなどの機械間アプリケーションに使用するように設計されています。Restful Transfer Protocol [Restful]、組み込みのリソースディスカバリープロトコルを提供し、URISやコンテンツタイプなどのWebコンセプトが含まれています。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].
簡単にするために、COAPは、すべてのCOAPサーバーがデフォルトのCOAPポートでリスニングされるか、DNSサービスディスカバリー（DNS-SD）[DNS-SD]などの一般的なサービスディスカバリーメカニズムを使用して構成または検出されたという仮定を行います。
Resource discovery in CoAP is accomplished through the use of well-known resources that describe the links offered by a CoAP server. CoAP defines a well-known URI for discovery: "/.well-known/r" [RFC5785]. For example, the query [GET /.well-known/r] returns a list of links (representing resources) available from the queried CoAP server. A query such as [GET /.well-known/r?n=Voltage] returns the resources with the name Voltage.
COAPでのリソースの発見は、COAPサーバーが提供するリンクを説明するよく知られたリソースを使用することで実現されます。Coapは、発見のためによく知られているURIを定義しています：「/.Well-Nowned/R」[RFC5785]。たとえば、クエリ[get /.well-nown /r]は、クエリCoapサーバーから利用可能なリンク（リソースを表す）のリストを返します。[get /.well-nown /r?n=voltage]などのクエリは、名前の電圧でリソースを返します。
There are many applications that rely on the IP infrastructure, but are not properly thought of as part of the IP infrastructure itself. These applications may be useful in the context of the Smart Grid. The choices made when constructing a profile of the Internet Profile Suite may impact how such applications could be used. Some of them, not by any means an exhaustive list, are discussed here.
IPインフラストラクチャに依存する多くのアプリケーションがありますが、IPインフラストラクチャ自体の一部とは適切に考えられていません。これらのアプリケーションは、スマートグリッドのコンテキストで役立つ場合があります。インターネットプロファイルスイートのプロファイルを構築するときに行われた選択は、そのようなアプリケーションの使用方法に影響を与える可能性があります。それらのいくつかは、決して網羅的なリストではなく、ここで議論されています。
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、UDP、SCTP、またはTCPを超えるTLSの上で実行できます。SIPは輸送層から独立しており、基礎となるIPv4/V6バージョンとは無関係です。実際、使用されるトランスポートプロトコルは、SIPメッセージがSIPエンティティをソースから宛先に通過するにつれて変更する可能性があります。
SIP itself does not choose whether a session is voice or video, nor does it identify the actual endpoints' IP addresses. The Session Description Protocol (SDP) [RFC4566] is intended for those purposes. Within the SDP, which is transported by SIP, codecs are offered and accepted (or not), and the port number and IP address at which each endpoint wants to receive their Real-time Transport Protocol (RTP) [RFC3550] packets are determined. The introduction of Network Address Translation (NAT) technology into the profile, whether IPv4/ IPv4, IPv4/IPv6 as described in Section 3.2.1.3, or IPv6/IPv6, increases the complexity of SIP/SDP deployment. This is further discussed in [RFC2993] and [RFC5626].
SIP自体は、セッションが音声であるかビデオであるかを選択しません。また、実際のエンドポイントのIPアドレスを識別しません。セッション説明プロトコル（SDP）[RFC4566]は、これらの目的を目的としています。SIPによって輸送されるSDP内では、コーデックが提供され、受け入れられます（またはそうでない）、および各エンドポイントがリアルタイムトランスポートプロトコル（RTP）[RFC3550]パケットを受信したいポート番号とIPアドレスが決定されます。セクション3.2.1.3、またはIPv6/IPv6で説明されているように、IPv4/IPv4、IPv4/IPv6、またはIPv6/IPv6であろうと、ネットワークアドレス変換（NAT）テクノロジーのプロファイルへの導入により、SIP/SDP展開の複雑さが増加します。これについては、[RFC2993]および[RFC5626]でさらに説明します。
The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. Since XMPP provides a generalized, extensible framework for exchanging XML data, it has been proposed as an application structure for interchange between embedded devices and sensors. It is currently used for Instant Messaging and Presence [RFC6121] and a wide variety of real-time communication modes. These include multi-user chat, publish-subscribe, alerts and notifications, service discovery, multimedia session management, device configuration, and remote procedure calls. XMPP supports channel encryption using TLS [RFC5246] and strong authentication (including PKIX certificate authentication) using SASL [RFC4422]. It also makes use of Unicode-compliant addresses and UTF-8 [RFC3629] data exchange for internationalization.
拡張可能なメッセージと存在プロトコル（XMPP）[RFC6120]は、拡張可能なマークアップ言語（XML）要素をストリーミングするためのプロトコルであり、構造化された情報を2つのネットワークエンドポイント間でリアルタイムに近づけます。XMPPは、XMLデータを交換するための一般化された拡張可能なフレームワークを提供するため、組み込みデバイスとセンサー間の交換のためのアプリケーション構造として提案されています。現在、インスタントメッセージングと存在感[RFC6121]、およびさまざまなリアルタイム通信モードに使用されています。これらには、マルチユーザーチャット、パブリッシュサブスクライブ、アラートと通知、サービス発見、マルチメディアセッション管理、デバイス構成、リモート手順コールが含まれます。XMPPは、TLS [RFC5246]を使用してチャネル暗号化をサポートし、SASL [RFC4422]を使用して強力な認証（PKIX証明書認証を含む）をサポートしています。また、Unicodeに準拠したアドレスとUTF-8 [RFC3629]データ交換を国際化のためのデータ交換も利用しています。
XMPP allows for End-to-End Signing and Object Encryption [RFC3923], access to objects named using Uniform Resource Names (URN) [RFC4854], use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) [RFC5122], and the presentation of Notifications [RFC5437].
XMPPでは、エンドツーエンドの署名とオブジェクト暗号化[RFC3923]、ユニフォームリソース名（URN）[RFC4854]を使用したオブジェクトへのアクセス、国際化されたリソース識別子（IRIS）およびユニフォームリソース識別子（URIS）[RFC5122]の使用が可能です。通知の提示[RFC5437]。
Internet calendaring, as implemented in Apple iCal, Microsoft Outlook and Entourage, and Google Calendar, is specified in Internet Calendaring and Scheduling Core Object Specification (iCalendar) [RFC5545] and is in the process of being updated to an XML schema in iCalendar XML Representation [xCAL]. Several protocols exist to carry calendar events, including the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the iCalendar Message-Based Interoperability Protocol (iMIP) [RFC6047], and open source work on the Atom Publishing Protocol [RFC5023].
Apple Ical、Microsoft Outlook、およびEntourage、およびGoogleカレンダーで実装されているインターネットカレンダーは、インターネットカレンダーとスケジューリングコアオブジェクト仕様（ICALENDAR）[RFC5545]で指定されており、ICALENDAR XML表現のXMLスキーマに更新されるプロセスにあります。[xcal]。ICALENDARトランスポートに依存しない相互運用性プロトコル（ITIP）[RFC5546]、ICALENDARメッセージベースの相互運用性プロトコル（IMIP）[RFC6047]、およびAtom Publishing Protocol [RFC5023]のオープンソース作業など、カレンダーイベントを実施するためにいくつかのプロトコルが存在します。
The Internet is a network of networks in which networks are interconnected in specific ways and are independently operated. It is important to note that the underlying Internet architecture puts no restrictions on the ways that networks are interconnected; interconnection is a business decision. As such, the Internet interconnection architecture can be thought of as a "business structure" for the Internet.
インターネットは、ネットワークが特定の方法で相互接続され、独立して動作されるネットワークのネットワークです。基礎となるインターネットアーキテクチャは、ネットワークが相互接続されている方法に制限をかけないことに注意することが重要です。相互接続はビジネス上の決定です。そのため、インターネットの相互接続アーキテクチャは、インターネットの「ビジネス構造」と考えることができます。
Central to the Internet business structure are the networks that provide connectivity to other networks, called "transit networks". These networks sell bulk bandwidth and routing services to each other and to other networks as customers. Around the periphery of the transit network are companies, schools, and other networks that provide services directly to individuals. These might generally be divided into "enterprise networks" and "access networks"; enterprise networks provide "free" connectivity to their own employees or members, and also provide them a set of services including electronic mail, web services, and so on. Access networks sell broadband connectivity (DSL, Cable Modem, 802.11 wireless, or 3GPP wireless) or "dial" services (including PSTN dial-up and ISDN) to subscribers. The subscribers are typically either residential or small office/home office (SOHO) customers. Residential customers are generally entirely dependent on their access provider for all services, while a SOHO buys some services from the access provider and may provide others for itself. Networks that sell transit services to nobody else -- SOHO, residential, and enterprise networks -- are generally refereed to as "edge networks"; transit networks are considered to be part of the "core" of the Internet, and access networks are between the two. This general structure is depicted in Figure 3.
インターネットのビジネス構造の中心は、「Transit Networks」と呼ばれる他のネットワークへの接続を提供するネットワークです。これらのネットワークは、顧客として互いに、他のネットワークにバルク帯域幅とルーティングサービスを販売しています。トランジットネットワークの周辺には、個人に直接サービスを提供する企業、学校、およびその他のネットワークがあります。これらは通常、「エンタープライズネットワーク」と「アクセスネットワーク」に分割される場合があります。エンタープライズネットワークは、自分の従業員またはメンバーに「無料」の接続性を提供し、電子メール、Webサービスなどを含む一連のサービスも提供します。アクセスネットワークは、ブロードバンド接続（DSL、ケーブルモデム、802.11ワイヤレス、または3GPPワイヤレス）または「ダイヤル」サービス（PSTNダイヤルアップおよびISDNを含む）を加入者に販売しています。購読者は通常、住宅または小規模オフィス/ホームオフィス（SOHO）の顧客です。住宅の顧客は一般に、すべてのサービスのアクセスプロバイダーに完全に依存していますが、Sohoはアクセスプロバイダーから一部のサービスを購入し、他のサービスを提供する場合があります。他の誰にも輸送サービスを販売するネットワーク - ソーホー、レジデンシャル、エンタープライズネットワークは、一般に「エッジネットワーク」として審判されます。トランジットネットワークはインターネットの「コア」の一部であると考えられており、アクセスネットワークは2つの間にあります。この一般的な構造を図3に示します。
------ ------
/ \ / \
/--\ / \ / \
|SOHO|---+ Access | |Enterprise|
\--/ | Service | | Network |
/--\ | Provider| | |
|Home|---+ | ------ | |
\--/ \ +---+ +---+ /
\ / / \ \ /
------ | Transit | ------
| Service |
| Provider |
| |
\ /
\ /
------
Figure 3: Conceptual Model of Internet Businesses
図3：インターネットビジネスの概念モデル
A specific example is shown in a traceroute from a home to a nearby school. Internet connectivity in Figure 4 passes through
具体的な例は、家から近くの学校までのトレーサーで示されています。図4のインターネット接続が通過します
o the home network,
o ホームネットワーク、
o Cox Communications, an access network using Cable Modem technology,
o Cox Communications、ケーブルモデムテクノロジーを使用したアクセスネットワーク、
o TransitRail, a commodity peering service for research and education (R&E) networks,
o Transitrail、研究と教育のための商品ピアリングサービス（R＆E）ネットワーク、
o Corporation for Education Network Initiatives in California (CENIC), a transit provider for educational networks, and
o カリフォルニア州の教育ネットワークイニシアチブ（CENIC）、教育ネットワークの輸送プロバイダー、および
o the University of California at Santa Barbara, which in this context might be viewed as an access network for its students and faculty or as an enterprise network.
o カリフォルニア大学サンタバーバラ校。この文脈では、学生と教員のためのアクセスネットワークまたはエンタープライズネットワークと見なされる可能性があります。
<stealth-10-32-244-218:> fred% traceroute www.ucsb.edu traceroute to web.ucsb.edu (128.111.24.41), 64 hops max, 40 byte packets 1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms 2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ... 3 68.6.13.101 ... 4 68.6.13.129 ... 5 langbbr01-as0.r2.la.cox.net ... 6 calren46-cust.lsanca01.transitrail.net ... 7 dc-lax-core1--lax-peer1-ge.cenic.net ... 8 dc-lax-agg1--lax-core1-ge.cenic.net ... 9 dc-ucsb--dc-lax-dc2.cenic.net ... 10 r2--r1--1.commserv.ucsb.edu ... 11 574-c--r2--2.commserv.ucsb.edu ... 12 * * *
<Stealth-10-32-244-218：> fred％traceroute www.ucsb.edu traceroute to web.ucsb.edu（128.111.24.41）、64 Hops max、40 byte packets 1 fred-vpn（10.32.244.217）1.560MS 1.108 MS 1.133 MS 2 WSIP-98-173-193-1.sb.sd.cox.net（98.173.193.1）12.540 MS ... 3 68.6.13.101 ... 4 68.6.13.129 ... 5 Langbbr01-AS0.R2.LA.COX.NET ... 6 Calren46-Cust.lsanca01.Transitrail.net ... 7 DC-Lax-Core1-Lax-Peer1-Ge.cenic.net ... 8 dc-lax-agg1 - lax-core1-ge.cenic.net ... 9 dc-ucsb - dc-lax-dc2.cenic.net ... 10 r2 - r1--1.commserv.ucsb.edu ...11 574-C - R2--2.CommServ.ucsb.edu ... 12 * * *
Figure 4: Traceroute from Residential Customer to Educational Institution
図4：住宅顧客から教育機関へのトレーサー
Another specific example could be shown in a traceroute from the home through a Virtual Private Network (VPN tunnel) from the home, crossing Cox Cable (an access network) and Pacific Bell (a transit network), and terminating in Cisco Systems (an enterprise network); a traceroute of the path doesn't show that as it is invisible within the VPN and the contents of the VPN are invisible, due to encryption, to the networks on the path. Instead, the traceroute in Figure 5 is entirely within Cisco's internal network.
別の具体的な例は、自宅から家から自宅からの仮想プライベートネットワーク（VPNトンネル）、Cox Cable（アクセスネットワーク）とPacific Bell（トランジットネットワーク）を介して、Cisco Systems（エンタープライズで終了する）を介してトレーサーで表示されます。通信網）;パスのトレーサーは、VPN内では見えないため、VPNの内容が暗号化のためにパス上のネットワークに見えないことを示していません。代わりに、図5のTracerouteは完全にCiscoの内部ネットワーク内にあります。
<stealth-10-32-244-218:~> fred% traceroute irp-view13
traceroute to irp-view13.cisco.com (171.70.120.60),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms
<tunneled path through Cox and Pacific Bell>
2 ****
3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms...
4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ...
5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ...
6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ...
7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ...
8 sjc12-dc5-gw2-ten3-1 ...
9 sjc5-dc4-gw1-ten8-1 ...
10 irp-view13 ...
Figure 5: Traceroute across VPN
図5：VPN全体のTraceroute
Note that in both cases, the home network uses private address space [RFC1918] while other networks generally use public address space, and that three middleware technologies are in use here. These are the uses of a firewall, a Network Address Translator (NAT), and a Virtual Private Network (VPN).
どちらの場合も、ホームネットワークはプライベートアドレススペース[RFC1918]を使用している一方、他のネットワークは一般にパブリックアドレススペースを使用しており、ここでは3つのミドルウェアテクノロジーが使用されていることに注意してください。これらは、ファイアウォール、ネットワークアドレス翻訳者（NAT）、および仮想プライベートネットワーク（VPN）の使用です。
Firewalls are generally sold as and considered by many to be a security technology. This is based on the fact that a firewall imposes a border between two administrative domains. Typically, a firewall will be deployed between a residential, SOHO, or enterprise network and its access or transit provider. In its essence, a firewall is a data diode, imposing a policy on what sessions may pass between a protected domain and the rest of the Internet. Simple policies generally permit sessions to be originated from the protected network but not from the outside; more complex policies may permit additional sessions from the outside, such as electronic mail to a mail server or a web session to a web server, and may prevent certain applications from global access even though they are originated from the inside.
ファイアウォールは一般に販売され、多くの人がセキュリティテクノロジーと見なしています。これは、ファイアウォールが2つの管理ドメイン間に境界を課すという事実に基づいています。通常、住宅、ソーホー、またはエンタープライズネットワークとそのアクセスまたはトランジットプロバイダーの間にファイアウォールが展開されます。本質的に、ファイアウォールはデータダイオードであり、保護されたドメインと他のインターネットの間でセッションが渡される可能性のあるポリシーを課しています。単純なポリシーでは、一般に、セッションが保護されたネットワークから発信されるが、外部からではなく、セッションを可能にすることができます。より複雑なポリシーでは、電子メールやWebセッションなどの電子メールやWebサーバーへのWebセッションなど、より複雑なポリシーでは、外部からの追加セッションが可能になり、内部から発信されている場合でも、特定のアプリケーションがグローバルアクセスからのアクセスを防ぐことができます。
Note that the effectiveness of firewalls remains controversial. While network managers often insist on deploying firewalls as they impose a boundary, others point out that their value as a security solution is debatable. This is because most attacks come from behind the firewall. In addition, firewalls do not protect against application layer attacks such as viruses carried in email. Thus, as a security solution, firewalls are justified as a layer in defense in depth. That is, while an end system must in the end be responsible for its own security, a firewall can inhibit or prevent certain kinds of attacks, for example the consumption of CPU time on a critical server.
ファイアウォールの有効性は議論の余地があることに注意してください。ネットワークマネージャーはしばしば境界を課すためにファイアウォールの展開を主張しますが、他の人はセキュリティソリューションとしての価値が議論の余地があることを指摘しています。これは、ほとんどの攻撃がファイアウォールの後ろから来るためです。さらに、ファイアウォールは、電子メールで運ばれるウイルスなどのアプリケーション層攻撃から保護しません。したがって、セキュリティソリューションとして、ファイアウォールは防御力のあるレイヤーとして正当化されます。つまり、最終的には最終的には独自のセキュリティに責任を負う必要がありますが、ファイアウォールは、重要なサーバーでのCPU時間の消費など、特定の種類の攻撃を阻害または防止できます。
Key documents describing firewall technology and the issues it poses include:
ファイアウォールテクノロジーとそれがもたらす問題を説明する重要な文書には以下が含まれます。
o IP Multicast and Firewalls [RFC2588]
o IPマルチキャストとファイアウォール[RFC2588]
o Benchmarking Terminology for Firewall Performance [RFC2647]
o ファイアウォールパフォーマンスのベンチマーク用語[RFC2647]
o Behavior of and Requirements for Internet Firewalls [RFC2979]
o インターネットファイアウォールの動作と要件[RFC2979]
o Benchmarking Methodology for Firewall Performance [RFC3511]
o ファイアウォールパフォーマンスのベンチマーク方法論[RFC3511]
o Mobile IPv6 and Firewalls: Problem Statement [RFC4487]
o モバイルIPv6およびファイアウォール：問題ステートメント[RFC4487]
o NAT and Firewall Traversal Issues of Host Identity Protocol Communication [RFC5207]
o ホストIDプロトコル通信の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 従来のIPネットワークアドレス翻訳者[RFC3022]
o Protocol Complications with the IP Network Address Translator [RFC3027]
o IPネットワークアドレス翻訳者とのプロトコルの合併症[RFC3027]
o Network Address Translator Friendly Application Design Guidelines [RFC3235]
o ネットワークアドレス翻訳者フレンドリーアプリケーションデザインガイドライン[RFC3235]
o IAB Considerations for Network Address Translation [RFC3424]
o ネットワークアドレス変換に関するIABの考慮事項[RFC3424]
o IPsec-Network Address Translation Compatibility Requirements [RFC3715]
o IPSEC-Networkアドレス翻訳互換性要件[RFC3715]
o Network Address Translation Behavioral Requirements for Unicast UDP [RFC4787]
o ユニキャストUDPのネットワークアドレス変換行動要件[RFC4787]
o State of Peer-to-Peer Communication across Network Address Translators [RFC5128]
o ネットワークアドレス翻訳者全体のピアツーピア通信の状態[RFC5128]
o IP Multicast Requirements for a Network Address Translator and a Network Address Port Translator [RFC5135]
o ネットワークアドレス翻訳者とネットワークアドレスポート翻訳者のIPマルチキャスト要件[RFC5135]
Virtual Private Networks come in many forms; what they have in common is that they are generally tunneled over the Internet backbone, so that as in Figure 5, connectivity appears to be entirely within the edge network although it is in fact across a service provider's network. Examples include IPsec tunnel-mode encrypted tunnels, IP-in-IP or GRE tunnels, and MPLS LSPs [RFC3031][RFC3032].
仮想プライベートネットワークには多くの形式があります。彼らが共通しているのは、一般的にインターネットのバックボーン上でトンネルされていることです。そのため、図5のように、実際にはサービスプロバイダーのネットワーク全体にあるものの、接続性は完全にエッジネットワーク内にあるように見えます。例には、IPSECトンネルモード暗号化されたトンネル、IP-in-IPまたはGREトンネル、およびMPLS LSP [RFC3031] [RFC3032]が含まれます。
Security is addressed in some detail in Section 2.2 and Section 3.1.
セキュリティについては、セクション2.2およびセクション3.1で詳細に説明します。
Review comments were made by Adrian Farrel, Andrew Yourtchenko, Ashok Narayanan, Bernie Volz, Chris Lonvick, Dan Romascanu, Dave McGrew, Dave Oran, David Harrington, David Su, Don Sturek, Francis Cleveland, Hemant Singh, James Polk, Jari Arkko, John Meylor, Joseph Salowey, Julien Abeille, Kerry Lynn, Lars Eggert, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, Peter Saint-Andre, Ralph Droms, Robert Sparks, Russ White, Sean Turner, Sheila Frankel, Stephen Farrell, Tim Polk, Toerless Eckert, Tom Herbst, Vint Cerf, and Yoshihiro Ohba. Several of the individuals suggested text, which was very useful, as the authors don't claim to know half as much as their reviewers collectively do.
レビューコメントは、エイドリアンファレル、アンドリュー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、ジョン・メイラー、ジョセフ・サロウィー、ジュリエン・アベイユ、ケリー・リン、ラース・エガート、マグナス・ウェスターランド、マルタザチバ、ポール・ダフィー、ポール・ホフマン、ピーター・サンアンドレ、ラルフ・ドロムス、ロバート・スパークス、ラス・ホワイト、ショーン・ターナー、シーラ・フランケル、ステフェン・ファレル、ティム・ポーク、Toerless Eckert、Tom Herbst、Vint Cerf、Yoshihiro Ohba。著者はレビュアーが集合的に行うほど半分を知らないと主張していないため、いくつかの個人がテキストを提案しましたが、これは非常に便利でした。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J。、「IPv6ノード要件」、RFC 4294、2006年4月。
[6LOWPAN-HC] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN)", Work in Progress, February 2011.
[6lowpan-hc] Hui、J。およびP. Thubert、「低電力および損失ネットワーク（6lowpan）のIPv6データグラムの圧縮形式」、2011年2月の作業。
[ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, March 2011.
[ABFAB-ARCH] Howlett、J.、Hartman、S.、Tschofenig、H。、およびE. Lear、「Web（ABFAB）アーキテクチャを超えたフェデレーションアクセスのためのアプリケーションブリッジング」、2011年3月に進行中。
[AES-CCM-ECC] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM ECC Cipher Suites for TLS", Work in Progress, January 2011.
[AES-CCM-ECC] McGrew、D.、Bailey、D.、Campagna、M。、およびR. Dugal、「AES-CCM ECC Cipher Suites for TLS」、2011年1月の進行中。
[COAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", Work in Progress, March 2011.
[COAP] Shelby、Z.、Hartke、K.、Bormann、C。、およびB. Frank、「制約付きアプリケーションプロトコル（COAP）」、2011年3月、Work in Progress。
[DIME-BASE] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", Work in Progress, January 2011.
[Dime-base] Fajardo、V.、ed。、Arkko、J.、Loughney、J.、およびG. Zorn、「Diameter Base Protocol」、2011年1月の進行中。
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, February 2011.
[DNS-SD] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリー」、Work in Progress、2011年2月。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security version 1.2", Work in Progress, March 2011.
[DTLS] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Securityバージョン1.2」、2011年3月の作業進行中。
[DYMO] Chakeres, I. and C. Perkins, "Dynamic MANET On-demand (DYMO) Routing", Work in Progress, July 2010.
[Dymo] Chakeres、I。およびC. Perkins、「ダイナミックマネオンデマンド（Dymo）ルーティング」、2010年7月の進行中。
[IEC61850] Wikipedia, "Wikipedia Article: IEC 61850", June 2011, <http://en.wikipedia.org/w/ index.php?title=IEC_61850&oldid=433437827>.
[IEC61850] Wikipedia、「Wikipediaの記事：IEC 61850」、2011年6月、<http://en.wikipedia.org/w/ index.php？title = iec_61850＆oldid = 433437827>。
[IEC62351-3] International Electrotechnical Commission Technical Committee 57, "POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE. DATA AND COMMUNICATIONS SECURITY -- Part 3: Communication network and system security Profiles including TCP/IP", May 2007.
[IEC62351-3]国際電気技術委員会技術委員会57、「電力システム管理と関連情報交換。データと通信セキュリティ - パート3：TCP/IPを含む通信ネットワークおよびシステムセキュリティプロファイル」、2007年5月。
[IEEE802.1X] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks - Port based Network Access Control", IEEE Standard 802.1X-2010, February 2010.
[IEEE802.1x]電気および電子機器エンジニアの研究所、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - ポートベースのネットワークアクセス制御」、IEEE Standard 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.
[MultiCast-DNS] Cheshire、S。およびM. Krochmal、「Multicast DNS」、2011年2月に進行中の作業。
[Model] SGIP, "Smart Grid Architecture Committee: Conceptual Model White Paper http://collaborate.nist.gov/ twiki-sggrid/pub/SmartGrid/ SGIPConceptualModelDevelopmentSGAC/ Smart_Grid_Conceptual_Model_20100420.doc".
[モデル] SGIP、「スマートグリッドアーキテクチャ委員会：概念モデルホワイトペーパーhttp://collaborate.nist.gov/ pub/smartgrid/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] Hammer-Lahav、E.、Recordon、D。、およびD. Hardt、「The Oauth 2.0 Authorization Protocol」、2011年5月の進行中。
[RESTFUL] Fielding, "Architectural Styles and the Design of Network-based Software Architectures", 2000.
[Restful]フィールディング、「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計」、2000。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC0894] Hornig、C。、「イーサネットネットワークを介したIPデータグラムの送信の標準」、STD 41、RFC 894、1984年4月。
[RFC1006] Rose, M. and D. Cass, "ISO transport services on top of the TCP: Version 3", STD 35, RFC 1006, May 1987.
[RFC1006] Rose、M。およびD. Cass、「TCPの上にあるISO輸送サービス：バージョン3」、STD 35、RFC 1006、1987年5月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058] Hedrick、C。、「ルーティング情報プロトコル」、RFC 1058、1988年6月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964] Linn、J。、「Kerberosバージョン5 GSS-APIメカニズム」、RFC 1964、1996年6月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080] Malkin、G。およびR. Minnear、「RIPNG for IPv6」、RFC 2080、1997年1月。
[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top of TCP (ITOT)", RFC 2126, March 1997.
[RFC2126] Pouffary、Y。およびA. Young、「TCPの上にあるISO輸送サービス（ITOT）」、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.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357] Mankin、A.、Romanov、A.、Bradner、S。、およびV. Paxson、「信頼できるマルチキャスト輸送およびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 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.、Carrel、D.、Simone、D。、およびR. Wheeler、「PPPをイーサネット上に送信する方法」、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] Marques、P。and F. Dupont、「IPv6インタードメインルーティングのBGP-4マルチプロトコル拡張の使用」、RFC 2545、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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999.
[RFC2588] Finlayson、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] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[RFC2615] Malis、A。およびW. Simpson、「PPP Over Sonet/SDH」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979] Freed、N。、「インターネットファイアウォールの行動と要件」、RFC 2979、2000年10月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027] Holdrege、M。およびP. Srisuresh、「IPネットワークアドレス翻訳者とのプロトコルの合併症」、RFC 3027、2001年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3235] Senie, D., "Network Address Translator (NAT)- Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235] Senie、D。、「ネットワークアドレス翻訳者（NAT） - フレンドリーなアプリケーション設計ガイドライン」、RFC 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)- Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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] EastLake、D.、Reagle、J。、およびD. Solo、「（拡張可能なマークアップ言語）XML-Signature構文と処理」、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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、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] Case、J.、Harrington、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] Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（SNMP）アプリケーション」、STD 62、RFC 3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414] Blumenthal、U.およびB. Wijnen、「Simple Network Management Protocol（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415] Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、2002年12月、RFC 3415、RFC 3415。
[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。、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417] 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.
[RFC3418] Presuhn、R。、「単純なネットワーク管理プロトコル（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、Rescorla、E。、およびM. Tuexen、「ストリーム制御伝送プロトコルを介した輸送層セキュリティ」、RFC 3436、2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
[RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, "Benchmarking Methodology for Firewall Performance", RFC 3511, April 2003.
[RFC3511] Hickman、B.、Newman、D.、Tadjudin、S。、およびT. Martin、「ファイアウォールパフォーマンスのためのベンチマーク方法」、RFC 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.、Frederick、R。、およびV. Jacobson、「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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[RFC3561] Perkins、C.、Belding-Royer、E。、およびS. Das、「アドホックオンデマンド距離ベクトル（AODV）ルーティング」、RFC 3561、2003年7月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3590] Haberman、B。、「マルチキャストリスナーディスカバリー（MLD）プロトコルのソースアドレス選択」、RFC 3590、2003年9月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626] Clausen、T。およびP. Jacquet、「最適化されたリンク状態ルーティングプロトコル（OLSR）」、RFC 3626、2003年10月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「Ipsec-Networkアドレス翻訳（NAT）互換性要件」、RFC 3715、2004年3月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、Pink、S.、Jonsson、L-E。、およびG. Fairhurst、「The Lightweight User Datagram Protocol（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] Peterson、J。、「S/MIME Advanced暗号化標準（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] Saint-Andre、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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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] Adams、A.、Nicholas、J。、およびW. Siadak、「プロトコル独立マルチキャスト - 密度モード（PIM -DM）：プロトコル仕様（改訂）」、RFC 3973、2005年1月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017] Stanley、D.、Walker、J。、およびB. Aboba、「ワイヤレスLANSの拡張可能な認証プロトコル（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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル修正」、RFC 4035、2005年3月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108] Housley、R。、「暗号化メッセージ構文（CMS）を使用してファームウェアパッケージを保護する」、RFC 4108、2005年8月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（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] Zhu、L.、Jaganathan、K。、およびS. Hartman、「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] Adams、C.、Farrell、S.、Kause、T。、およびT. Mononen、「Internet 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. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）輸送層プロトコル」、RFC 4253、2006年1月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 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. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（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] Sparks、R。、「セッション開始プロトコル（SIP）非インバイトトランザクションで特定された問題に対処するアクション」、RFC 4320、2006年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4410] Pullen, M., Zhao, F., and D. Cohen, "Selectively Reliable Multicast Protocol (SRMP)", RFC 4410, February 2006.
[RFC4410] Pullen、M.、Zhao、F。、およびD. Cohen、「選択的に信頼できるマルチキャストプロトコル（SRMP）」、RFC 4410、2006年2月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、RFC 4443、2006年3月。
[RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile IPv6 and Firewalls: Problem Statement", RFC 4487, May 2006.
[RFC4487] Le、F.、Faccin、S.、Patil、B。、およびH. Tschofenig、「モバイルIPv6およびファイアウォール：問題文」、RFC 4487、2006年5月。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C.、およびB. Moeller、 "楕円曲線暗号化（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.
[RFC4556] Zhu、L。およびB. Tung、「Kerberos（Pkinit）の初期認証のための公開キー暗号」、RFC 4556、2006年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、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.、Chan、K。、およびF. Baker、「Diffserv Service Classeの構成ガイドライン」、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] Fenner、B.、Handley、M.、Holbrook、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] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリーバージョンバージョン2（MLDV2）を使用して、ソース固有のマルチキャスト、RFC 4604、8月2006年。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「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] Meyer、D.、Rockell、R。、およびG. Shepherd、「232/8のソース固有のプロトコル独立マルチキャスト」、BCP 120、RFC 4608、2006年8月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614] Duke、M.、Braden、R.、Eddy、W。、およびE. Blanton、「伝送制御プロトコルのロードマップ（TCP）仕様文書」、RFC 4614、2006年9月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[RFC4742] Wasserman、M。およびT. Goddard、「Secure Shell（SSH）を介したNetConf構成プロトコルを使用」、RFC 4742、2006年12月。
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.
[RFC4743] Goddard、T。、「Simple Object Access Protocol（SOAP）でNetConfを使用」、RFC 4743、2006年12月。
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.
[RFC4744] Lear、E。およびK. Crozier、「ブロック拡張可能な交換プロトコル（BEEP）でNetConfプロトコルを使用」、RFC 4744、2006年12月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F。およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、2007年4月。
[RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)", RFC 4854, April 2007.
[RFC4854] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）への拡張用のユニフォームリソース名（URN）名前空間」、RFC 4854、2007年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、J。、「セッション開始プロトコル（SIP）の接続アイデンティティ」、RFC 4916、2007年6月。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007.
[RFC4919] Kushalnagar、N.、Montenegro、G。、およびC. Schumacher、「低電力ワイヤレスパーソナルエリアネットワーク（6lowpans）を超えるIPv6：概要、仮定、問題声明、および目標、RFC 4919、2007年8月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、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] Montenegro、G.、Kushalnagar、N.、Hui、J。、およびD. Culler、「IEEE 802.15.4ネットワーク上のIPv6パケットの伝送」、RFC 4944、2007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、RFC 4987、2007年8月。
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007.
[RFC5023] Gregorio、J。およびB. De Hora、「The Atom Publishing Protocol」、RFC 5023、2007年10月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（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.、Ed。、Haskins、D。、およびE. Allen、「PPP上のIPバージョン6」、RFC 5072、2007年9月。
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[RFC5122] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）の国際化されたリソース識別子（IRIS）および均一なリソース識別子（URI）」、RFC 5122、2008年2月。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008.
[RFC5128] Srisuresh、P.、Ford、B。、およびD. Kegel、「ネットワークアドレス翻訳者（NAT）全体のピアツーピア（P2P）通信」、RFC 5128、2008年3月。
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5135] Wing、D。およびT. Eckert、「ネットワークアドレス翻訳者（NAT）およびネットワークアドレスポート翻訳者（NAPT）のIPマルチキャスト要件」、BCP 135、RFC 5135、2008年2月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191] Forsberg、D.、Ohba、Y.、Patil、B.、Tschofenig、H。、およびA. Yegin、「ネットワークアクセスの認証を運ぶためのプロトコル（PANA）」、RFC 5191、2008年5月。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
[RFC5207] Stiemerling、M.、Quittek、J。、およびL. Eggert、「Nat and Firewall Traversal Issus of Host Identity Protocol（HIP）Communication」、RFC 5207、2008年4月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216] Simon、D.、Aboba、B。、およびR. Hurst、「EAP-TLS認証プロトコル」、RFC 5216、2008年3月。
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.
[RFC5238] Phelan、T。、「データグラムの混雑制御プロトコル（DCCP）上のデータグラム輸送層セキュリティ（DTLS）」、RFC 5238、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272] Schaad、J。およびM. Myers、「CMS（CMC）の証明書管理」、RFC 5272、2008年6月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277] Chisholm、S。およびH. Trevino、「NetConf Event Notifications」、RFC 5277、2008年7月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 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] Rescorla、E。、「SHA-256/384およびAES Galoisカウンターモード（GCM）を備えたTLS楕円曲線暗号」、RFC 5289、2008年8月。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[RFC5308] Hopps、C。、「IS-ISを使用したIPv6をルーティング」、RFC 5308、2008年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、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] Sparks、R.、Lawrence、S.、Hawrylyshen、A。、およびB. Campen、「セッション開始プロトコル（SIP）フォーキングプロキシの増幅脆弱性に対処する」、RFC 5393、2008年12月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーションデザイナーのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
[RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile for Transport Layer Security (TLS)", RFC 5430, March 2009.
[RFC5430] Salter、M.、Rescorla、E。、およびR. Housley、「輸送層セキュリティのためのスイートBプロファイル（TLS）」、RFC 5430、2009年3月。
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009.
[RFC5433] Clancy、T。およびH. Tschofenig、「拡張可能な認証プロトコル - 一般化された事前共有キー（EAP-GPSK）メソッド」、RFC 5433、2009年2月。
[RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)", RFC 5437, January 2009.
[RFC5437] Saint-Andre、P。and A. Melnikov、「ふるい通知メカニズム：拡張可能なメッセージと存在プロトコル（XMPP）」、RFC 5437、2009年1月。
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[RFC5539] Badra、M。、「NetConf Over Transport Layer Security（TLS）」、RFC 5539、2009年5月。
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
[RFC5545] Desruisseaux、B。、「インターネットカレンダーとスケジューリングコアオブジェクト仕様（ICALENDAR）」、RFC 5545、2009年9月。
[RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009.
[RFC5546] Daboo、C。、「Icalendar Transportに依存しない相互運用性プロトコル（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.、Winter、T.、およびD. Barthel、「都市の低電力と損失ネットワークのルーティング要件」、RFC 5548、2009年5月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569] DESPRES、R。、「IPv4インフラストラクチャのIPv6迅速な展開（6rd）」、RFC 5569、2010年1月。
[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5621] Camarillo、G。、「セッション開始プロトコル（SIP）でのメッセージ本文処理」、RFC 5621、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] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 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] Pister、K.、Thubert、P.、Dwars、S。、およびT. Phinney、「低電力および損失ネットワークの産業ルーティング要件」、RFC 5673、2009年10月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP混雑制御」、RFC 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] Adamson、B.、Bormann、C.、Handley、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. Turner、「Secure/Multipurpose Internet Mail Extensions（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] Nottingham、M。およびE. Hammer-Lahav、「有名なユニフォームリソース識別子（URI）の定義」、RFC 5785、2010年4月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826] Brandt、A.、Buron、J。、およびG. Porcu、「低電力および損失ネットワークのホームオートメーションルーティング要件」、RFC 5826、2010年4月。
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[RFC5838] Lindem、A.、Mirtorabi、S.、Roy、A.、Barnes、M。、およびR. Aggarwal、「Ospfv3の住所家族のサポート」、RFC 5838、2010年4月。
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010.
[RFC5849] Hammer-Lahav、E。、「The OAuth 1.0 Protocol」、RFC 5849、2010年4月。
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867] Martocci、J.、De Mil、P.、Riou、N。、およびW. Vermeylen、「低電力および損失ネットワークの自動化ルーティング要件の構築」、RFC 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] Mills、D.、Martin、J.、Burbank、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] Kato、A.、Kanda、M。、およびS. Kanno、「Camellia cipher Suites for 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] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン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. Sheffer、「IKEV2のEAPのみの認証の拡張」、RFC 5998、2010年9月。
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, December 2010.
[RFC6031] Turner、S。およびR. Housley、「暗号化メッセージ構文（CMS）対称キーパッケージコンテンツタイプ」、RFC 6031、2010年12月。
[RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, December 2010.
[RFC6047] Melnikov、A。、「ICALENDARメッセージベースの相互運用性プロトコル（IMIP）」、RFC 6047、2010年12月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M.、およびX. Li、「IPv4/IPv6翻訳者のアドレス指定」、RFC 6052、2010年10月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「基本楕円曲線暗号化アルゴリズム」、RFC 6090、2011年2月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：Core」、RFC 6120、2011年3月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121] Saint-Andre、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] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「IPv4/IPv6翻訳のフレームワーク」、RFC RFC6144、2011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP/ICMP翻訳アルゴリズム」、RFC 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.、Matthews、P。、およびI. Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、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.、Sullivan、A.、Matthews、P。、およびI. Beijnum、 "DNS64：DNS拡張IPv6クライアントからIPv4サーバーへのネットワークアドレス変換の拡張"、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. Baker、「IPv6展開中にIPv6遷移メカニズムを使用するためのガイドライン」、RFC 6180、2011年5月。
[RPL] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2011.
[RPL] Winter、T.、Thubert、P.、Brandt、A.、Clausen、T.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R。、およびJ。Vasseur、「RPL：低電力および損失ネットワーク向けのIPv6ルーティングプロトコル」、2011年3月、進行中の作業。
[SP-MULPIv3.0] CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I10- 090529", May 2009.
[SP-Mulpiv3.0] CableLabs、 "Docsis 3.0 Macおよび上層層プロトコルインターフェイス仕様、CM-SP-Mulpiv3.0-I10- 090529"、2009年5月。
[SmartGrid] Wikipedia, "Wikipedia Article: Smart Grid", February 2011, <http://en.wikipedia.org/w/ index.php?title=Smart_grid&oldid=415838933>.
[SmartGrid] Wikipedia、「Wikipediaの記事：Smart Grid」、2011年2月、<http://en.wikipedia.org/w/ index.php？title = smart_grid＆oldid = 415838933>。
[TCP-SEC] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, January 2011.
[TCP-SEC] Gont、F。、「送信制御プロトコル（TCP）のセキュリティ評価」、2011年1月の作業。
[r1822] Bolt Beranek and Newman Inc., "Interface Message Processor -- Specifications for the interconnection of a host and a IMP, Report No. 1822", January 1976.
[R1822] Bolt Beranek and Newman Inc.、「インターフェイスメッセージプロセッサ - ホストと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.、Douglass、M。、およびS. Lees、「Xcal：The XML Format for Icalendar」、2011年4月、進行中の作業。
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.
この付録は、Smart GridのAdvanced Metering Infrastructure（AMI）などのネットワークでインターネットプロトコルスイートの使用の実用的な例を提供します。いくつかの可能なモデルがあります。
Figure 6 shows the structure of the AMI as it reaches out towards a set of residences. In this structure, we have the home itself and its Home Area Network (HAN), the Neighborhood Area Network (NAN) that the utility uses to access the meter at the home, and the utility access network that connects a set of NANs to the utility itself. For the purposes of this discussion, assume that the NAN contains a distributed application in a set collectors, which is of course only one way the application could be implemented.
図6は、AMIが住宅のセットに到達するときのAMIの構造を示しています。この構造には、ホーム自体とそのホームエリアネットワーク（HAN）、ユーティリティが家庭のメーターにアクセスするために使用する近隣エリアネットワーク（NAN）、およびNANのセットを接続するユーティリティアクセスネットワークを持っています。ユーティリティ自体。この議論の目的のために、NANにはセットコレクターに分散アプリケーションが含まれていると仮定します。これはもちろん、アプリケーションを実装できる1つの方法のみです。
---
A thermostats, appliances, etc
| ------+-----------------------------------
| |
|"HAN" | <--- Energy Services Interface (ESI)
| +---+---+
| | Meter | Meter is generally an ALG between the AMI and the HAN
| +---+---+
V \
--- \
A \ | /
| \ | /
| "NAN" +--+-+-+---+ Likely a router but could
| |Collector | be a front-end application
V +----+-----+ gateway for utility
--- \
A \ | /
| \ | /
|"AMI" +--+-+-+--+
| | AMI |
| | Headend |
V +---------+
---
Figure 6: The HAN, NAN, and Utility in the Advanced Metering Infrastructure
図6：高度な計量インフラストラクチャのHAN、NAN、およびユーティリティ
There are several questions that have to be answered in describing this picture, which given possible answers yield different possible models. They include at least:
この写真を説明する際に答えなければならないいくつかの質問があります。少なくとも：
o How does Demand Response work? Either:
o 需要対応はどのように機能しますか？また：
* The utility presents pricing signals to the home,
* ユーティリティは自宅に価格設定シグナルを提示します、
* The utility presents pricing signals to individual devices (e.g., a Pluggable Electric Vehicle),
* ユーティリティは、個々のデバイス（たとえば、プラグ可能な電気自動車）に価格設定シグナルを提示します。
* The utility adjusts settings on individual appliances within the home.
* ユーティリティは、家庭内の個々のアプライアンスの設定を調整します。
o How does the utility access meters at the home?
o ユーティリティは家のメーターにどのようにアクセスしますか？
* The AMI Headend manages the interfaces with the meters, collecting metering data and passing it on to the appropriate applications over the Enterprise Bus, or
* AMIヘッドエンドはメーターとのインターフェイスを管理し、計量データを収集し、エンタープライズバス上の適切なアプリケーションに渡す、または
* Distributed application support ("collectors") might access and summarize the information; this device might be managed by the utility or by a service between the utility and its customers.
* 分散アプリケーションサポート（「コレクター」）は、情報にアクセスして要約する場合があります。このデバイスは、ユーティリティまたはユーティリティとその顧客の間のサービスによって管理される場合があります。
In implementation, these models are idealized; reality may include some aspects of each model in specified cases.
実装では、これらのモデルが理想化されています。現実には、指定されたケースで各モデルのいくつかの側面が含まれる場合があります。
The examples include:
例には次のものがあります。
1. Appendix A.2 presumes that the HAN, the NAN, and the utility's network are separate administrative domains and speak application to application across those domains.
1. 付録A.2は、HAN、NAN、およびユーティリティのネットワークが個別の管理ドメインであり、それらのドメイン全体のアプリケーションに適用を発言すると仮定しています。
2. Appendix A.3 repeats the first example, but presuming that the utility directly accesses appliances within the HAN from the collector.
2. 付録A.3は最初の例を繰り返しますが、ユーティリティがコレクターからHAN内のアプライアンスに直接アクセスすると仮定します。
3. Appendix A.4 repeats the first example, but presuming that the collector directly forwards traffic as a router in addition to distributed application chores. Note that this case implies numerous privacy and security concerns and as such is considered a less likely deployment model.
3. 付録A.4は最初の例を繰り返しますが、コレクターが分散用途の雑用に加えてトラフィックをルーターとして直接転送すると仮定します。このケースは多数のプライバシーとセキュリティの懸念を意味し、そのため展開モデルが低いと見なされることに注意してください。
A key consideration in the Internet has been the development of new link layer technologies over time. The ARPANET originally used a BBN proprietary link layer called BBN 1822 [r1822]. In the late 1970's, the ARPANET switched to X.25 as an interface to the 1822 network. With the deployment of the IEEE 802 series technologies in the early 1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE 802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of various kinds, Frame Relay, and ATM. A key issue in this evolution was that the applications developed to run on the Internet use APIs 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）、WiFi（IEEE 802.11）に展開されました。、およびatm。この進化の重要な問題は、インターネット上で実行されるために開発されたアプリケーションがIPに関連する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が含まれます。他の技術が将来開発されることを期待することは合理的です。Zigbee Allianceが学んだように（および結果としてIPSをSmart Energyプロファイル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
図7：ホームエリアネットワークの2つのビュー
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.
HANには2つの可能な通信モデルがあり、どちらも有用である可能性があります。デバイスは互いに直接通信する場合があります。または、一部の中央コントローラーによって管理される場合があります。直接通信の例は、ランプを直接コマンドしてオンまたはオフにするためのライトスイッチかもしれません。間接通信の例は、サーモスタットからテレメトリを受け入れ、何らかの形のポリシーを適用し、暖房および空調システムを制御する顧客または建物の制御アプリケーションである可能性があります。さらに、今日の市場には、住宅ブロードバンドを使用してメーカーと通信するハイエンドアプライアンスがあり、明らかにメーターはユーティリティと通信する必要があります。
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つの単純なネットワークを示しています。、または文脈で意味のあるもの。どちらも、エネルギー管理システム（EMS）とは別のルーターとしてそれらの間の接続性を示しています。これは明確なためです。2つはもちろん単一のシステムに組み込むことができ、Routerに依存するのではなく、HANインターフェイスとWiFiインターフェイスの両方をサポートするメーカーと通信したいアプライアンスを想像できます。これらはすべてメーカーの設計上の決定です。
The HAN can be seen as communicating with two kinds of non-HAN networks. One is the home LAN, which may in turn be attached to the Internet, and will generally either derive its prefix from the upstream ISP or use a self-generated Unique Local Addressing (ULA). Another is the utility's NAN, which through an ESI provides utility connectivity to the HAN; in this case the HAN will be addressed by a self-generated ULA (note, however, that in some cases ESI may also provide a prefix via DHCP [RFC3315]). In addition, the HAN will have link-local addresses that can be used between neighboring nodes. In general, an HAN will be comprised of both 802.15.4, 802.11, and possibly other networks.
HANは、2種類の非HANネットワークと通信していると見ることができます。1つはホームLANで、これはインターネットに順番に取り付けられている可能性があり、通常、上流のISPからそのプレフィックスを導き出すか、自己生成されたユニークなローカルアドレス（ULA）を使用します。もう1つはユーティリティのナンで、ESIを介してHANへのユーティリティ接続を提供します。この場合、HANは自己生成されたULAによって対処されます（ただし、場合によってはESIもDHCP [RFC3315]を介してプレフィックスを提供することもあります）。さらに、HANには、隣接するノード間で使用できるリンクローカルアドレスがあります。一般に、HANは802.15.4、802.11、およびおそらく他のネットワークの両方で構成されます。
The ESI is a node on the user's residential network, and will not typically provide stateful packet forwarding or firewall services between the HAN and the utility network(s). In general, the ESI is a node on the home network; in some cases, the meter may act as the ESI. However, the ESI must be capable of understanding that most home networks are not 802.15.4 enabled (rather, they are typically 802.11 networks), and that it must be capable of setting up ad hoc networks between various sensors in the home (e.g., between the meter and say, a thermostat) in the event there aren't other networks available.
ESIはユーザーの住宅ネットワーク上のノードであり、通常、HANとユーティリティネットワーク間でステートフルなパケット転送またはファイアウォールサービスを提供しません。一般に、ESIはホームネットワーク上のノードです。場合によっては、メーターがESIとして機能する場合があります。ただし、ESIは、ほとんどのホームネットワークが802.15.4を有効にしていないことを理解できる必要があります（むしろ、通常は802.11ネットワークです）。メーターとたとえば、サーモスタットの間）の間に、他のネットワークはありません。
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/ 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.
リンクレイヤー：なぜあなたのマシンは私のネットワークで話し合うことができるのですか？WiFi SSIDは、何らかの形の認証されたアクセス制御を使用することがよくあります。これは、単純な暗号化されたパスワードメカニズムであるか、暗号化とIEEE 802.1x EAP-TLS認証/承認の組み合わせを使用して、認定されたコミュニケーションのみが使用できるようにすることができます。LANにルーターが接続されている場合、ルーターはリモートアクセスをフィルタリングするファイアウォールを実装することもできます。
Network Layer: Given that your machine is authorized access to my network, why is your machine talking with my machine? IPsec is a way of ensuring that computers that can use a network are allowed to talk with each other, may also enforce confidentiality, and may provide VPN services to make a device or network appear to be part of a remote network.
ネットワークレイヤー：マシンが私のネットワークへのアクセス権を許可されていることを考えると、なぜあなたのマシンは私のマシンと話しているのですか？IPSECは、ネットワークを使用できるコンピューターが互いに通信できるようにし、機密性を実施し、VPNサービスを提供してデバイスまたはネットワークをリモートネットワークの一部であるようにすることを保証する方法です。
Application: Given that your machine is authorized access to my network and my machine, why is your application talking with my application? The fact that your machine and mine are allowed to talk for some applications doesn't mean they are allowed to for all applications. (D)TLS, https, and other such mechanisms enable an application to impose application-to-application controls similar to the network layer controls provided by IPsec.
アプリケーション：マシンが私のネットワークとマシンへのアクセス権が許可されていることを考えると、アプリケーションが私のアプリケーションと話をしているのはなぜですか？あなたのマシンと私のものがいくつかのアプリケーションのために話すことが許可されているという事実は、それらがすべてのアプリケーションに対して許可されることを意味するものではありません。（d）TLS、HTTPS、およびその他のそのようなメカニズムにより、アプリケーションはIPSECが提供するネットワークレイヤーコントロールと同様のアプリケーションからアプリケーションへのコントロールを課すことができます。
Remote Application: How do I know that the data I received is the data you sent? Especially in applications like electronic mail, where data passes through a number of intermediaries that one may or may not really want munging it (how many times have you seen a URL broken by a mail server?), we have tools (DKIM, S/MIME, and W3C XML Signatures to name a few) to provide non-repudiability and integrity verification. This may also have legal ramifications: if a record of a meter reading is to be used in billing, and the bill is disputed in court, one could imagine the court wanting proof that the record in fact came from that meter at that time and contained that data.
リモートアプリケーション：受け取ったデータが送信したデータであることをどのように知ることができますか？特に、データが実際にそれをムンすることを望んでいるかもしれないことがあるかもしれない多くの仲介者を通過する電子メールのようなアプリケーションでは（メールサーバーによってURLが壊れたのを見たことがありますか？）、ツールがあります（DKIM、S/mime、およびw3c xml署名がいくつか例を挙げて、非整合性と整合性の検証を提供します。これには法的な影響もあります。メーターの読み取り記録が請求で使用され、法案が法廷で争われている場合、その時点でその記録が実際にそのメーターから来たという証拠を望んでいると想像できます。そのデータ。
Application-specific security: In addition, applications often provide security services of their own. The fact that I can access a file system, for example, doesn't mean that I am authorized to access everything in it; the file system may well prevent my access to some of its contents. Routing protocols like BGP are obsessed with the question "what statements that my peer made am I willing to believe", and monitoring protocols like SNMP may not be willing to answer every question they are asked, depending on access configuration.
アプリケーション固有のセキュリティ：さらに、アプリケーションは多くの場合、独自のセキュリティサービスを提供します。たとえば、ファイルシステムにアクセスできるという事実は、すべてのファイルシステムにアクセスすることを許可されているという意味ではありません。ファイルシステムは、そのコンテンツの一部へのアクセスを十分に妨げる可能性があります。BGPのようなルーティングプロトコルには、「私のピアが私が信じていることを喜んで作った声明」という質問に取りつかれており、SNMPのような監視プロトコルは、アクセス構成に応じて、彼らが尋ねられたすべての質問に答えたくないかもしれません。
Devices in the HAN want controlled access to the LAN in question for obvious reasons. In addition, there should be some form of mutual authentication between devices -- the lamp controller will want to know that the light switch telling it to change state is the right light switch, for example. The EMS may well want strong authentication of accesses -- the parents may not want the children 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はアクセスの強力な認証を望んでいるかもしれません - 親は子どもたちが設定を変更することを望まないかもしれません、そして、ユーティリティと顧客は日常的にアクセスを許可されていますが、他の当事者（特に犯罪意図のある当事者）を除外する必要があります。
With the background given in Appendix A.1, we can now discuss the use of IP (IPv4 or IPv6) in the AMI.
付録A.1に示されている背景を使用すると、AMIでのIP（IPv4またはIPv6）の使用について説明できるようになりました。
In this first model, consider the three domains in Figure 6 to literally be separate administrative domains, potentially operated by different entities. For example, the NAN could be a WiMAX network operated by a traditional telecom operator, the utility's network (including the collector) is its own, and the residential network is operated by the resident. In this model, while communications between the collector and the Meter are normal, the utility has no other access to appliances in the home, and the collector doesn't directly forward messages from the NAN upstream.
この最初のモデルでは、図6の3つのドメインを考慮して、文字通り別々の管理ドメインであり、潜在的に異なるエンティティで動作する可能性があります。たとえば、NANは従来の通信事業者が運営するWiMAXネットワークである可能性があり、ユーティリティのネットワーク（コレクターを含む）は独自のものであり、住宅ネットワークは居住者によって運営されています。このモデルでは、コレクターとメーター間の通信は正常ですが、ユーティリティには家庭内の電化製品へのアクセスは他にありません。コレクターは、上流のNANから直接メッセージを転送しません。
In this case, as shown in Figure 7, it would make the most sense to design the collector, the Meter, and the EMS as hosts on the NAN -- design them as systems whose applications can originate and terminate exchanges or sessions in the NAN, but not forward traffic from or to other devices.
この場合、図7に示すように、NANのホストとしてコレクター、メーター、およびEMSを設計することが最も理にかなっています。、しかし、他のデバイスからまたは他のデバイスへの転送ではありません。
In such a configuration, Demand Response has to be performed by having the EMS accept messages such as price signals from the "pole top", apply some form of policy, and then orchestrate actions within the home. Another possibility is to have the EMS communicate with the ESI located in the meter. If the thermostat has high demand and low demand (day/night or morning/day/evening/night) settings, Demand Response might result in it moving to a lower demand setting, and the EMS might also turn off specified circuits in the home to diminish lighting.
このような構成では、「ポールトップ」からの価格信号などのメッセージをEMSに受け入れることにより、需要応答を実行する必要があり、何らかの形のポリシーを適用してから、家庭内のアクションを調整する必要があります。別の可能性は、EMSにメーターにあるESIと通信することです。サーモスタットの需要が高い（昼/夜または朝/夕方/夜）設定が低い場合、需要の応答により、需要の設定が低くなり、EMSは家の指定された回路をオフにする可能性があります。照明を減らします。
In this scenario, Quality of Service (QoS) issues reportedly arise when high precedence messages must be sent through the collector to the home; if the collector is occupied polling the meters or doing some other task, the application may not yield control of the processor to the application that services the message. Clearly, this is either an application or an Operating System problem; applications need to be designed in a manner that doesn't block high precedence messages. The collector also needs to use appropriate NAN services, if they exist, to provide the NAN QoS it needs. For example, if WiMax is in use, it might use a routine-level service for normal exchanges but a higher precedence service for these messages.
このシナリオでは、コレクターを介して家に高い優先メッセージを送信する必要がある場合、サービス品質（QOS）の問題が発生したと伝えられています。コレクターがメーターを投票したり、他のタスクを実行したりしている場合、アプリケーションはメッセージにサービスを提供するアプリケーションにプロセッサの制御をもたらさない可能性があります。明らかに、これはアプリケーションまたはオペレーティングシステムの問題です。アプリケーションは、高い優先順位メッセージをブロックしない方法で設計する必要があります。コレクターは、必要なNAN QoSを提供するために、適切なNANサービスを使用する必要があります。たとえば、Wimaxが使用されている場合、通常の交換にはルーチンレベルのサービスを使用する可能性がありますが、これらのメッセージにはより高い優先サービスが使用されます。
In this second model, let's imagine that the utility directly accesses appliances within the HAN. Rather than expect an EMS to respond to price signals in Demand Response, it directly commands devices like air conditioners to change state, or throws relays on circuits to or within the home.
この2番目のモデルでは、ユーティリティがHAN内のアプライアンスに直接アクセスすることを想像しましょう。EMSが需要応答の価格信号に応答することを期待するのではなく、エアコンのようなデバイスに直接コマンドして状態を変更したり、家庭内または家庭内で回路にリレーを投げたりします。
+----------+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
| +------/------ NAN
|Router|
| +------/------ Residential Broadband
+--+---+
|
----+--+------+----+----+---- IEEE P1901
| | | |
+-+-+ ++-+ ++-+ ++-+
|EMS| |D4| |D5| |D6|
+---+ +--+ +--+ +--+
Figure 8: Home Area Network
図8：ホームエリアネットワーク
In this case, as shown in Figure 8, the Meter and EMS act as hosts on the HAN, and there is a router between the HAN and the NAN.
この場合、図8に示すように、メーターとEMSはHANのホストとして機能し、漢とNANの間にルーターがあります。
As one might imagine, there are serious security considerations in this model. Traffic between the NAN and the residential broadband network should be filtered, and the issues raised in Appendix A.1.2 take on a new level of meaning. One of the biggest threats may be a legal or at least a public relations issue; if the utility intentionally disables a circuit in a manner or at a time that threatens life (the resident's kidney dialysis machine is on it, or a respirator, for example), the matter might make the papers. Unauthorized access could be part of juvenile pranks or other things as well. So one really wants the appliances to only obey commands under strict authentication/authorization controls.
想像するかもしれませんが、このモデルには深刻なセキュリティ上の考慮事項があります。NANと住宅ブロードバンドネットワーク間のトラフィックはフィルタリングする必要があり、付録A.1.2で提起された問題は新しいレベルの意味を帯びています。最大の脅威の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.2で提起されたQoSの問題に加えて、ルーターにキューイングの問題が発生する可能性があります。そのような場合、IPデータグラムはおそらく[RFC4594]で説明されている低遅延データサービスクラスを使用し、他のトラフィックに標準のサービスクラスまたは他のサービスクラスを使用できるようにする必要があります。
In this third model, the relationship between the NAN and the HAN is either as in Appendix A.2 or Appendix A.3; what is different is that the collector may be an IP router. In addition to whatever autonomous activities it is doing, it forwards traffic as an IP router in some cases.
この3番目のモデルでは、NANとHANの関係は、付録A.2または付録A.3のようにです。違うのは、コレクターがIPルーターである可能性があることです。それが行っている自律的な活動に加えて、場合によってはトラフィックをIPルーターとして転送します。
Analogous to Appendix A.3, there are serious security considerations in this model. Traffic being forwarded should be filtered, and the issues raised in Appendix A.1.2 take on a new level of meaning -- but this time at the utility mainframe. Unauthorized access is likely similar to other financially-motivated attacks that happen in the Internet, but presumably would be coming from devices in the HAN that have been co-opted in some way. One really wants the appliances to only obey commands under strict authentication/authorization controls.
付録A.3と同様に、このモデルには深刻なセキュリティ上の考慮事項があります。転送されるトラフィックはフィルタリングする必要があり、付録A.1.2で提起された問題は新しいレベルの意味を帯びていますが、今回はユーティリティメインフレームで。不正アクセスは、インターネットで発生する他の経済的に動機付けられた攻撃に似ている可能性がありますが、おそらく何らかの形で採用された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.
付録A.2で提起されたQoSの問題に加えて、コレクターに列の問題が発生する可能性があります。そのような場合、IPデータグラムはおそらく[RFC4594]で説明されている低遅延データサービスクラスを使用し、他のトラフィックに標準のサービスクラスまたは他のサービスクラスを使用できるようにする必要があります。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムサンタバーバラ、カリフォルニア93117 USA
EMail: fred@cisco.com
David Meyer Cisco Systems Eugene, Oregon 97403 USA
David Meyer Cisco Systems Eugene、Oregon 97403 USA
EMail: dmm@cisco.com