[要約] 要約：RFC 4540は、NECのSIMCOプロトコルのバージョン3.0に関する仕様です。SIMCOプロトコルは、ネットワーク機器の簡単な設定を可能にするために設計されています。目的：SIMCOプロトコルの目的は、ネットワーク機器の設定を簡素化し、効率的なネットワーク管理を実現することです。
Network Working Group M. Stiemerling
Request for Comments: 4540 J. Quittek
Category: Experimental NEC
C. Cadar
May 2006
NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
NECのシンプルなミドルボックス構成（SIMCO）プロトコルバージョン3.0
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
IESG Note
IESGノート
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 [RFC3932] for more information.
このRFCの内容は、一度にIETFによって考慮されていたため、現在のIETF作業または公開されているIETF作業に似ている可能性があります。このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このRFCの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932 [RFC3932]を参照してください。
Abstract
概要
This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements.
このドキュメントでは、ファイアウォールやネットワークアドレス翻訳者などのミドルボックスを制御するためのプロトコルについて説明します。これは、RFC 3989で説明されているMiddlebox Communications（MIDCOM）セマンティクスの完全に準拠した実装です。SIMCOプロトコルの以前の実験バージョンと比較して、このバージョン（3.0）はリソース要件を削減するためにバイナリメッセージエンコーディングを使用します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Binary Encodings ...........................................4
2. Compliance with MIDCOM Protocol Semantics .......................5
3. SIMCO Sessions ..................................................6
4. SIMCO Message Components ........................................6
4.1. Message Types ..............................................7
4.2. The SIMCO Header ...........................................7
4.2.1. Basic Message Types .................................8
4.2.2. Message Sub-types for Requests and Positive
Replies .............................................8
4.2.3. Message Sub-types for Negative Replies ..............8
4.2.4. Message Sub-types for Notifications .................9
4.2.5. Transaction Identifier ..............................9
4.3. The SIMCO Payload .........................................10
4.3.1. SIMCO Protocol Version Attribute ...................11
4.3.2. Authentication Attributes ..........................11
4.3.3. Middlebox Capabilities Attribute ...................12
4.3.4. Policy Rule Identifier Attribute ...................13
4.3.5. Group Identifier Attribute .........................13
4.3.6. Policy Rule Lifetime Attribute .....................13
4.3.7. Policy Rule Owner Attribute ........................14
4.3.8. Address Tuple Attribute ............................14
4.3.9. PRR Parameter Set Attribute ........................16
4.3.10. PER Parameter Set Attribute .......................18
5. SIMCO Message Formats ..........................................19
5.1. Protocol Error Replies and Notifications ..................19
5.1.1. BFM Notification ...................................19
5.1.2. Protocol Error Negative Replies ....................19
5.2. Session Control Messages ..................................20
5.2.1. SE Request .........................................20
5.2.2. SE Positive Reply ..................................21
5.2.3. SA Positive Reply ..................................21
5.2.4. SA Request .........................................21
5.2.5. ST Request and ST Positive Reply ...................22
5.2.6. SE Negative Replies ................................22
5.2.7. AST Notification ...................................23
5.3. Policy Rule Control Messages ..............................23
5.3.1. Policy Events and Asynchronous Notifications .......24
5.3.2. PRR Request ........................................24
5.3.3. PER Request ........................................25
5.3.4. PEA Request ........................................26
5.3.5. PLC Request ........................................26
5.3.6. PRS Request ........................................27
5.3.7. PRL Request ........................................27
5.3.8. PDR Request ........................................27
5.3.9. PRR Positive Reply .................................28
5.3.10. PER Positive Reply ................................28
5.3.11. PLC Positive Reply ................................29
5.3.12. PRD Positive Reply ................................29
5.3.13. PRS Positive Reply ................................30
5.3.14. PES Positive Reply ................................31
5.3.15. PDS Positive Reply ................................32
3.5.16. PRL Positive Reply ................................32
5.3.17. PDR Positive Replies ..............................33
5.3.18. Policy Rule Control Negative Replies ..............33
5.3.19. ARE Notification ..................................33
6. Message Format Checking ........................................34
7. Session Control Message Processing .............................36
7.1. Session State Machine .....................................36
7.2. Processing SE Requests ....................................37
7.3. Processing SA Requests ....................................38
7.4. Processing ST Requests ....................................39
7.5. Generating AST Notifications ..............................39
7.6. Session Termination by Interruption of Connection .........39
8. Policy Rule Control Message Processing .........................40
8.1. Policy Rule State Machine .................................40
8.2. Processing PRR Requests ...................................41
8.2.1. Initial Checks .....................................41
8.2.2. Processing on Pure Firewalls .......................43
8.2.3. Processing on Network Address Translators ..........44
8.3. Processing PER Requests ...................................45
8.3.1. Initial Checks .....................................46
8.3.2. Processing on Pure Firewalls .......................48
8.3.3. Processing on Network Address Translators ..........49
8.3.4. Processing on Combined Firewalls and NATs ..........51
8.4. Processing PEA Requests ...................................51
8.4.1. Initial Checks .....................................51
8.4.2. Processing on Pure Firewalls .......................53
8.4.3. Processing on Network Address Translators ..........54
8.5. Processing PLC Requests ...................................55
8.6. Processing PRS Requests ...................................56
8.7. Processing PRL Requests ...................................57
8.8. Processing PDR requests ...................................57
8.8.1. Extending the MIDCOM semantics .....................58
8.8.2. Initial Checks .....................................58
8.8.3. Processing on Pure Firewalls .......................61
8.8.4. Processing on Network Address Translators ..........61
8.8.5. Processing on Combined Firewalls and NATs ..........62
8.9. Generating ARE Notifications ..............................62
9. Security Considerations ........................................63
9.1. Possible Threats to SIMCO .................................63
9.2. Securing SIMCO with IPsec .................................63
10. IAB Considerations on UNSAF ...................................64
11. Acknowledgements ..............................................64
12. Normative References ..........................................65
13. Informative References ........................................65
The Simple Middlebox Configuration (SIMCO) protocol is used to control firewalls and Network Address Translators (NATs). As defined in [RFC3234], firewalls and NATs are classified as middleboxes. A middlebox is a device on the datagram path between the source and destination that performs other functions than just IP routing. As outlined in [RFC3303], firewalls and NATs are potential obstacles to packet streams, for example, if dynamically negotiated UDP or TCP port numbers are used, as in many peer-to-peer communication applications.
シンプルなミドルボックス構成（SIMCO）プロトコルは、ファイアウォールとネットワークアドレス翻訳者（NAT）を制御するために使用されます。[RFC3234]で定義されているように、ファイアウォールとNATはミドルボックスとして分類されます。ミドルボックスは、単なるIPルーティング以外の機能を実行するソースと宛先の間のデータグラムパス上のデバイスです。[RFC3303]で概説されているように、ファイアウォールとNATは、多くのピアツーピア通信アプリケーションのように、動的にネゴシエートされたUDPまたはTCPポート番号が使用される場合、パケットストリームに対する潜在的な障害です。
SIMCO allows applications to communicate with middleboxes on the datagram path in order to request a dynamic configuration at the middlebox that enables datagram streams to pass the middlebox. Applications can request pinholes at firewalls and address bindings at NATs.
SIMCOでは、アプリケーションがデータグラムパスのミドルボックスと通信して、Datagramストリームがミドルボックスを通過できるようにするミドルボックスで動的な構成を要求することができます。アプリケーションは、ファイアウォールでピンホールを要求し、NATでバインディングに対処できます。
The semantics for the SIMCO protocol are described in [RFC3989].
SIMCOプロトコルのセマンティクスは[RFC3989]で説明されています。
The terminology used in this document is fully aligned with the terminology defined in [RFC3989]. In the remainder of the text, the term SIMCO refers to SIMCO version 3.0. The term "prefix-length" is used as described in [RFC4291] and [RFC1519]. With respect to wildcarding, the prefix length determines the part of an IP address that will be used in address match operations.
このドキュメントで使用される用語は、[RFC3989]で定義されている用語と完全に整合しています。テキストの残りの部分では、Simcoという用語はSimcoバージョン3.0を指します。「プレフィックスレングス」という用語は、[RFC4291]および[RFC1519]で説明されているように使用されます。ワイルドカードに関しては、プレフィックスの長さは、アドレスマッチ操作で使用されるIPアドレスの部分を決定します。
Previous experimental versions of SIMCO used simple ASCII encodings with augmented BNF for syntax specification. This encoding requires more resources than binary encodings do for generation and parsing of messages. This applies to resources for coding agents and middleboxes as well as to resources for executing a SIMCO stack.
SIMCOの以前の実験バージョンでは、構文仕様のために拡張BNFを使用した単純なASCIIエンコーディングを使用しました。このエンコードには、メッセージの生成と解析のためにバイナリエンコーディングが行うよりも多くのリソースが必要です。これは、コーディングエージェントとミドルボックスのリソースと、SIMCOスタックを実行するためのリソースに適用されます。
Low resource requirements are important properties for two main reasons:
低リソース要件は、2つの主な理由で重要なプロパティです。
- For many applications (for example, IP telephony), session setup times are critical. Users do accept setup times only up to some limit, and some signaling protocols start retransmitting messages if setup is not completed within a certain time.
- 多くのアプリケーション（たとえば、IPテレフォニーなど）では、セッションのセットアップ時間が重要です。ユーザーは、セットアップ時間までの制限のみを受け入れ、一部の信号プロトコルは、特定の時間内にセットアップが完了しない場合、メッセージの再送信を開始します。
- Many middleboxes are rather small and relatively low-cost devices. For these, support of resource-intensive protocols might be a problem. The acceptance of a protocol on these devices depends, among other things, on the cost of implementing the protocol and of its hardware requirements.
- 多くのミドルボックスはかなり小さく、比較的低コストのデバイスです。これらの場合、リソース集約型のプロトコルのサポートが問題になる可能性があります。これらのデバイスでのプロトコルの受け入れは、とりわけ、プロトコルを実装するコストとそのハードウェア要件に依存します。
Therefore, we decided to use a simple and efficient binary encoding for SIMCO version 3.0, which is described in this document.
したがって、このドキュメントで説明されているSIMCOバージョン3.0のシンプルで効率的なバイナリエンコードを使用することにしました。
SIMCO version 3 is fully compliant with the MIDCOM protocol semantics defined by [RFC3989]. SIMCO implements protocol transactions as defined in Section 2.1.1 of [RFC3989]. All message types defined in Section 2.1.2 of [RFC3989] are supported by SIMCO, and all mandatory transactions are implemented. SIMCO does not implement the optional group transactions. For all implemented transactions, SIMCO implements all parameters concerning the information contained.
SIMCOバージョン3は、[RFC3989]で定義されたMIDCOMプロトコルセマンティクスに完全に準拠しています。SIMCOは、[RFC3989]のセクション2.1.1で定義されているように、プロトコルトランザクションを実装します。[RFC3989]のセクション2.1.2で定義されているすべてのメッセージタイプはSIMCOによってサポートされており、すべての必須トランザクションが実装されています。SIMCOは、オプションのグループトランザクションを実装していません。実装されたすべてのトランザクションについて、SIMCOは含まれる情報に関するすべてのパラメーターを実装します。
SIMCO defines a few new terms to reference functionality in the semantics. Among these terms are Session Authentication (SA) and Policy Enable Rule After reservation (PEA) messages. SA is used to model the state transition given in Figure 2 of [RFC3989] from NOAUTH to OPEN. PEA is used to model the state transition given in Figure 4 of [RFC3989] from RESERVED to ENABLED.
SIMCOは、セマンティクスの参照機能にいくつかの新しい用語を定義しています。これらの用語には、セッション認証（SA）とポリシーが予約後（PEA）メッセージを有効にします。SAは、[RFC3989]の図2に示されている状態遷移をNOAUTHから開くためにモデル化するために使用されます。PEAは、[RFC3989]の図4に示されている状態遷移を予約済みから有効にするためにモデル化するために使用されます。
SIMCO implements one additional transaction, the Policy Disable Rule (PDR) transaction, to those defined in [RFC3989]. PDR transactions are used by security functions such as intrusion detection and attack detection. They allow the agent to block a specified kind of traffic. PDRs have priority above Policy Enable Rules (PERs). When a PDR is established, all conflicting PERs (including PERs with just a partial overlap) are terminated, and no new conflicting PER can be established before the PDR is terminated. Support of the PDR transaction by SIMCO is optional. For a detailed description of the PDR transaction semantics, see Section 8.8.
SIMCOは、[RFC3989]で定義されているものに、追加のトランザクション、ポリシー無効ルール（PDR）トランザクションを実装しています。PDRトランザクションは、侵入検知や攻撃検出などのセキュリティ関数で使用されます。エージェントが指定された種類のトラフィックをブロックできるようにします。PDRには、ポリシーを有効にするルール（PERS）よりも優先されます。PDRが確立されると、すべての競合するPERS（部分的な重複だけのPERSを含む）が終了し、PDRが終了する前に新しい矛盾を確立することはできません。SIMCOによるPDRトランザクションのサポートはオプションです。PDRトランザクションセマンティクスの詳細な説明については、セクション8.8を参照してください。
The SIMCO protocol uses a session model with two parties: an agent representing one or more applications and a middlebox. Both parties may participate in multiple sessions. An agent may simultaneously communicate with several middleboxes using one session per middlebox. A middlebox may simultaneously communicate with several agents using one session per agent.
SIMCOプロトコルは、1つ以上のアプリケーションを表すエージェントとミドルボックスの2つのパーティーを持つセッションモデルを使用します。両当事者は複数のセッションに参加する場合があります。エージェントは、ミドルボックスごとに1つのセッションを使用して、いくつかのミドルボックスと同時に通信できます。ミドルボックスは、エージェントごとに1つのセッションを使用して、複数のエージェントと同時に通信できます。
+-------+ SIMCO protocol +-----------+
| agent +------------------+ middlebox |
+-------+ +-----------+
Figure 1: Participants in a SIMCO session
図1：SIMCOセッションの参加者
SIMCO sessions must run over a reliable transport layer protocol and are initiated by the agent. SIMCO implementations must support TCP, while other reliable transport protocols can be used as transport for SIMCO as well. When using TCP as transport, middleboxes must wait for agents to connect on port 7626. This port is assigned to SIMCO servers by IANA (see http://www.iana.org/assignments/port-numbers). The session may be secured, if required, by either IPsec or TLS [RFC4346] to guarantee authentication, message integrity and confidentiality. The use of IPsec is outlined in Section 9, "Security Considerations".
SIMCOセッションは、信頼できる輸送層プロトコルを介して実行され、エージェントによって開始されなければなりません。SIMCOの実装はTCPをサポートする必要がありますが、他の信頼できる輸送プロトコルもSIMCOの輸送として使用できます。TCPを輸送として使用する場合、ミドルボックスはエージェントがポート7626で接続するのを待つ必要があります。このポートは、IANAによってSIMCOサーバーに割り当てられています（http://www.iana.org/assignments/port-numbersを参照）。認証、メッセージの整合性、機密性を保証するために、必要に応じてIPSECまたはTLS [RFC4346]のいずれかによってセッションを確保できます。IPSECの使用は、セクション9「セキュリティ上の考慮事項」に概説されています。
The transaction semantics of sessions is explained in [RFC3989] Section 2.2.
セッションのトランザクションセマンティクスは、[RFC3989]セクション2.2で説明されています。
All SIMCO messages from agent to middlebox and from middlebox to agent are sent over the transport protocol as specified in Section 3. SIMCO messages are Type-Length-Value (TLV) encoded using big endian (network ordered) binary data representations.
セクション3で指定されているように、エージェントからミドルボックスへのすべてのSIMCOメッセージは、ミドルボックスからエージェントからエージェントからエージェントまで送信されます。SIMCOメッセージは、Big Endian（ネットワーク順序付け）バイナリデータ表現を使用してエンコードされたタイプ長値（TLV）です。
All SIMCO messages start with the SIMCO header containing message type, message length, and a message identifier. The rest of the message, the payload, contains zero, one, or more TLV message attributes.
すべてのSIMCOメッセージは、メッセージの種類、メッセージの長さ、メッセージ識別子を含むSIMCOヘッダーから始まります。メッセージの残りの部分であるペイロードには、ゼロ、1つ、またはそれ以上のTLVメッセージ属性が含まれています。
The message type in the SIMCO header is divided into a basic type and a sub-type. There are four basic types of SIMCO messages:
SIMCOヘッダーのメッセージタイプは、基本タイプとサブタイプに分割されます。SIMCOメッセージには4つの基本的なタイプがあります。
- request, - positive reply, - negative reply, - notification.
- リクエスト、 - 肯定的な返信、 - 否定的な返信、 - 通知。
Messages sent from the agent to the middlebox are always of basic type 'request message', while the basic type of messages sent from the middlebox to the agent is one of the three other types. Request messages and positive and negative reply messages belong to request transactions. From the agent's point of view, notification messages belong to notification transactions only. From the middlebox's point of view, a notification message may also belong to a request transaction. See section 2.3.4. of [RFC3989] for a detailed discussion of this issue.
エージェントからミドルボックスに送信されたメッセージは常に基本的なタイプの「リクエストメッセージ」です。一方、ミドルボックスからエージェントに送信される基本的なタイプのメッセージは、他の3つのタイプの1つです。リクエストメッセージと肯定的および否定的な返信メッセージは、リクエストトランザクションに属します。エージェントの観点から、通知メッセージは通知トランザクションのみに属します。Middleboxの観点から、通知メッセージはリクエストトランザクションに属する場合があります。セクション2.3.4を参照してください。[RFC3989]のこの問題の詳細な議論について。
The message sub-type gives further information on the message type within the context of the basic message type. Only the combination of basic type and sub-type clearly identify the type of a message.
メッセージサブタイプは、基本メッセージタイプのコンテキスト内のメッセージタイプに関する詳細情報を提供します。基本タイプとサブタイプの組み合わせのみが、メッセージのタイプを明確に識別します。
The SIMCO header is the first part of all SIMCO messages. It contains four fields: the basic message type, the message sub-type, the message length (excluding the SIMCO header) in octets, and the transaction identifier. The SIMCO header has a size of 64 bits. Its layout is defined in Figure 2.
SIMCOヘッダーは、すべてのSIMCOメッセージの最初の部分です。基本メッセージタイプ、メッセージサブタイプ、オクテットのメッセージ長（SIMCOヘッダーを除く）、およびトランザクション識別子の4つのフィールドが含まれています。SIMCOヘッダーのサイズは64ビットです。そのレイアウトは図2に定義されています。
Message Type
_______________^_______________
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Basic Type | Sub-Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier (TID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SIMCO header
図2：SIMCOヘッダー
For the basic type field, the following values are defined:
基本型フィールドの場合、次の値が定義されています。
0x01 : Request Message 0x02 : Positive Reply Message 0x03 : Negative Reply Message 0x04 : Notification Message
0x01：リクエストメッセージ0x02：肯定的な返信メッセージ0x03：ネガティブ返信メッセージ0x04：通知メッセージ
For basic types 0x01 (request) and 0x02 (positive reply), a common set of values for the sub-type field is defined. Most of the sub-types can be used for both basic types. Restricted sub-types are marked accordingly.
基本タイプ0x01（リクエスト）および0x02（正の応答）の場合、サブタイプフィールドの共通の値セットが定義されています。ほとんどのサブタイプは、両方の基本タイプに使用できます。それに応じて、制限付きサブタイプがマークされています。
0x01 : (SE) session establishment 0x02 : (SA) session authentication 0x03 : (ST) session termination 0x11 : (PRR) policy reserve rule 0x12 : (PER) policy enable rule 0x13 : (PEA) PER after reservation (request only) 0x14 : (PDR) policy disable rule 0x15 : (PLC) policy rule lifetime change 0x16 : (PRD) policy rule deletion (positive reply only) 0x21 : (PRS) policy rule status 0x22 : (PRL) policy rule list 0x23 : (PES) policy enable rule status (positive reply only) 0x24 : (PDS) policy disable rule status (positive reply only)
0x01：（SE）セッションの確立0x02 ：（ SA）セッション認証0x03 ：（ ST）セッション終了0x11 ：（ PRR）ポリシーリザーブルール0x12 ：（あたり）ポリシーを有効にするルール0x13 ：（ eaのみ）（リクエストのみ）0x144：（PDR）ポリシー無効規則0x15：（PLC）ポリシールールライフタイム変更0x16 ：（ PRD）ポリシールールの削除のみ（肯定的な返信のみ）0x21 ：（ PRS）ポリシールールステータス0x22 ：（ PRL）ポリシールールリスト0x23：（PES）（PES）ポリシー有効ルールステータス（肯定的な返信のみ）0x24 ：（ PDS）ポリシーはルールステータスのみを無効にします（肯定的な返信のみ）
For basic type 0x03 (negative reply message), the following values of the sub-type field are defined:
基本タイプ0x03（負の返信メッセージ）の場合、サブタイプフィールドの次の値が定義されています。
Replies concerning general message handling 0x10 : wrong basic request message type 0x11 : wrong request message sub-type 0x12 : badly formed request 0x13 : reply message too big
一般的なメッセージの処理に関する返信0x10：間違った基本要求メッセージタイプ0x11：間違ったリクエストメッセージサブタイプ0x12：badly formed request 0x13：返信メッセージが大きすぎる
Replies concerning sessions 0x20 : request not applicable 0x21 : lack of resources 0x22 : protocol version mismatch 0x23 : authentication failed 0x24 : no authorization 0x25 : transport protocol problem 0x26 : security of underlying protocol layers insufficient
セッションに関する返信0x20：リクエストリクエスト該当なし0x21：リソースの欠如0x22：プロトコルバージョンのミスマッチ0x23：認証失敗0x24：許可なし0x25：輸送プロトコル問題0x26：基礎となるプロトコルレイヤーのセキュリティ不十分な
Replies concerning policy rules 0x40 : transaction not supported 0x41 : agent not authorized for this transaction 0x42 : no resources available for this transaction 0x43 : specified policy rule does not exist 0x44 : specified policy rule group does not exist 0x45 : not authorized for accessing specified policy 0x46 : not authorized for accessing specified group 0x47 : requested address space not available 0x48 : lack of IP addresses 0x49 : lack of port numbers 0x4A : middlebox configuration failed 0x4B : inconsistent request 0x4C : requested wildcarding not supported 0x4D : protocol type doesn't match 0x4E : NAT mode not supported 0x4F : IP version mismatch 0x50 : conflict with existing rule 0x51 : not authorized to change lifetime 0x52 : lifetime can't be extended 0x53 : illegal IP Address 0x54 : protocol type not supported 0x55 : illegal port number 0x56 : illegal number of subsequent ports (NOSP) 0x57 : already enable PID 0x58 : parity doesn't match
ポリシールールに関する回答0x40：サポートされていないトランザクション0x41：エージェントはこのトランザクションで許可されていません0x46：指定されたグループへのアクセスに対して許可されていません0x47：要求されたアドレススペースは利用できません0x4E：NATモードはサポートされていません0x4F：IPバージョンのミスマッチ0x50：既存のルールとの競合0x51：ライフタイムを変更することは許可されていません違法な数の後続のポート（NOSP）0x57：すでに有効になります0x58：パリティが一致しません
For basic type 0x04, the following values of the sub-type field are defined:
基本タイプ0x04の場合、サブタイプフィールドの次の値が定義されています。
0x01 : (BFM) badly formed message received 0x02 : (AST) asynchronous session termination 0x03 : (ARE) asynchronous policy rule event
0x01：（BFM）著しく形成されたメッセージ受信0x02 ：（ AST）非同期セッション終了0x03 ：（ are）非同期ポリシールールイベントイベント
The transaction identifier (TID) is an arbitrary number identifying the transaction. In a request message, the agent chooses an agent-unique TID, such that the same agent never uses the same TID in two different request messages belonging to the same session. Reply messages must contain the same TID as the corresponding request message. In a notification message, the middlebox chooses a middlebox-unique TID, such that the same middlebox never uses the same TID in two different notification messages belonging to the same session.
トランザクション識別子（TID）は、トランザクションを識別する任意の番号です。リクエストメッセージで、エージェントはエージェントとユニークのTIDを選択します。これにより、同じエージェントが同じセッションに属する2つの異なる要求メッセージで同じTIDを使用しないようにします。返信メッセージには、対応するリクエストメッセージと同じTIDが含まれている必要があります。通知メッセージでは、MiddleboxはMiddlebox-Unique TIDを選択します。これにより、同じミドルボックスが同じセッションに属する2つの異なる通知メッセージで同じTIDを使用することはありません。
A SIMCO payload consists of zero, one, or more type-length-value (TLV) attributes. Each TLV attribute starts with a 16-bit type field and a 16-bit length field, as shown in Figure 3.
SIMCOペイロードは、ゼロ、1つ、またはそれ以上のタイプ長価値（TLV）属性で構成されています。図3に示すように、各TLV属性は16ビット型フィールドと16ビットの長さフィールドから始まります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| attribute type | attribute length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Structure of TLV attribute
図3：TLV属性の構造
The attribute length field contains the length of the value field in octets.
属性の長さフィールドには、オクテットの値フィールドの長さが含まれています。
The following attribute types are defined:
次の属性タイプが定義されています。
type description length
----------------------------------------------------
0x0001 : SIMCO protocol version 32 bits
0x0002 : authentication challenge <= 4096 octets
0x0003 : authentication token <= 4096 octets
0x0004 : middlebox capabilities 64 bits
0x0005 : policy rule identifier 32 bits
0x0006 : group identifier 32 bits
0x0007 : policy rule lifetime 32 bits
0x0008 : policy rule owner <= 255 octets
0x0009 : address tuple 32, 96 or 192 bits
0x000A : PRR parameter set 32 bits
0x000B : PER parameter set 32 bits
The SIMCO protocol version attribute has a length of four octets. The first two octets contain the version number, one the major version number and the other the minor version number. Two remaining octets are reserved.
SIMCOプロトコルバージョン属性の長さは4オクターです。最初の2つのオクテットにはバージョン番号が含まれています。1つはメジャーバージョン番号、もう1つはマイナーバージョン番号です。残りの2つのオクテットが予約されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|major version #|minor version #| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Protocol version attribute
図4：プロトコルバージョン属性
The SIMCO protocol specified within this document is version 3.0. The version numbers carried in the protocol version attribute are 3 for major version number and 0 for minor version number.
このドキュメント内で指定されたSIMCOプロトコルはバージョン3.0です。プロトコルバージョン属性に掲載されたバージョン番号は、メジャーバージョン番号が3、マイナーバージョン番号が0です。
The authentication challenge attribute and the authentication token attribute have the same format. Both contain a single value field with variable length. For both, the maximum length is limited to 4096 octets. Please note that the length of these attributes may have values that are not multiples of 4 octets. In case of an authentication challenge attribute, the value field contains an authentication challenge sent from one peer to the other, requesting that the other peer authenticate itself.
Authentication Challenge属性と認証トークン属性は同じ形式です。どちらも可変長の単一の値フィールドを含んでいます。両方の場合、最大長は4096オクテットに制限されています。これらの属性の長さには、4オクテットの倍数ではない値がある場合があることに注意してください。認証チャレンジ属性の場合、バリューフィールドには、一方のピアから他のピアに送信される認証チャレンジが含まれており、他のピアがそれ自体を認証することを要求します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 | challenge length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Authentication challenge attribute
図5：認証チャレンジ属性
The authentication token attribute is used for transmitting an authentication token.
認証トークン属性は、認証トークンの送信に使用されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0003 | authentication length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authentication token
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Authentication attribute
図6：認証属性
The middlebox capabilities attribute has a length of eight octets.
Middlebox機能属性の長さは8オクターです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | 0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MB type |I|E|P|S|IIV|EIV| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max policy rule lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Capabilities attribute
図7：機能属性
The first parameter field carries a bit field called MB type and provides information about the middlebox type. The following bits within the field are defined. The remaining ones are reserved.
最初のパラメーターフィールドは、MBタイプと呼ばれるビットフィールドを持ち、ミドルボックスタイプに関する情報を提供します。フィールド内の次のビットが定義されています。残りのものは予約されています。
0x80 : packet filter firewall 0x40 : network address translator 0x10 : support of PDR transaction 0x01 : port translation (requires 0x40 set) 0x02 : protocol translation (requires 0x40 set) 0x04 : twice NAT support (requires 0x40 set)
0x80：パケットフィルターファイアウォール0x40：ネットワークアドレス翻訳者0x10：PDRトランザクションのサポート0x01：ポート変換（0x40セットが必要）0x02：プロトコル変換（0x40セットが必要）0x04：2回NATサポート（0x40セットが必要）
For middleboxes that implement combinations of NAT and firewalls, combinations of those flags are possible. For instance, for a Network Address and Port Translator (NAPT) with packet filter and PDR transaction support, the value of the MB type parameter field is 0xD1.
NATとファイアウォールの組み合わせを実装するミドルボックスの場合、これらのフラグの組み合わせが可能です。たとえば、パケットフィルターとPDRトランザクションサポートを備えたネットワークアドレスとポート翻訳者（NAPT）の場合、MBタイプパラメーターフィールドの値は0xD1です。
The following four parameters fields are binary flags with a size of one bit:
次の4つのパラメーターフィールドは、1ビットのサイズのバイナリフラグです。
I : internal IP address wildcard support E : external IP address wildcard support P : port wildcard support S : persistent storage of policy rules
I：内部IPアドレスワイルドカードサポートE：外部IPアドレスワイルドカードサポートP：ポートワイルドカードサポートs：ポリシールールの永続的なストレージ
The supported IP version for the internal and external network are coded into the IIV (Internal IP version) and EIV (external IP version) parameter fields. They both have a size of two bits. Allowed values are 0x1 for IP version 4 (IPv4), 0x2 for IP version 6 (IPv6), and the combination of both (0x3) for IPv4 and IPv6 dual stack.
内部および外部ネットワークのサポートされているIPバージョンは、IIV（内部IPバージョン）およびEIV（外部IPバージョン）パラメーターフィールドにコーディングされます。どちらも2ビットのサイズです。許可された値は、IPバージョン4（IPv4）の場合は0x1、IPバージョン6（IPv6）の場合は0x2、IPv4およびIPv6デュアルスタックの両方（0x3）の組み合わせです。
The next parameter field with a length of 16 bits is reserved.
長さ16ビットの次のパラメーターフィールドは予約されています。
The max policy rule lifetime parameter field specifies the maximum lifetime a policy rule may have.
Max Policy Rule Lifetimeパラメーターフィールドは、ポリシールールが持つ可能性のある最大寿命を指定します。
The policy rule identifier (PID) attribute contains an identifier of a policy rule. The identifier has a length of four octets.
ポリシールール識別子（PID）属性には、ポリシールールの識別子が含まれています。識別子の長さは4オクテットです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0005 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| policy rule identifier (PID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Policy rule identifier attribute
図8：ポリシールール識別子属性
The group identifier (GID) attribute contains an identifier of a policy rule group. The identifier has a length of four octets.
グループ識別子（GID）属性には、ポリシールールグループの識別子が含まれています。識別子の長さは4オクテットです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group identifier (GID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Group identifier attribute
図9：グループ識別子属性
The policy rule lifetime attribute specifies the requested or actual remaining lifetime of a policy rule, in seconds. Its value field contains a 32-bit unsigned integer.
ポリシールールのライフタイム属性は、秒単位で、ポリシールールの要求または実際の残りの寿命を指定します。その値フィールドには、32ビットの符号なし整数が含まれています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0007 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| policy rule lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Policy rule lifetime attribute
図10：ポリシールールのライフタイム属性
The policy rule owner attribute specifies the authenticated agent that created and owns the policy rule. Its value field does not have a fixed length, but its length is limited to 255 octets. Please note that the length of this attribute may have values that are not multiples of 4 octets. The owner is set by the middlebox.
ポリシールールの所有者属性は、ポリシールールを作成および所有する認証されたエージェントを指定します。その値フィールドには固定された長さはありませんが、その長さは255オクテットに制限されています。この属性の長さには、4オクテットの倍数ではない値がある場合があることに注意してください。所有者はミドルボックスによって設定されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0008 | owner length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| owner
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Policy rule owner attribute
図11：ポリシールール所有者属性
The address tuple attribute contains a set of parameters specifying IP and transport addresses. The length of this attribute is 32, 96, or 192 bits.
アドレスタプル属性には、IPおよび輸送アドレスを指定する一連のパラメーターが含まれています。この属性の長さは32、96、または192ビットです。
The first parameter field has a length of 4 bits. It indicates whether the contained parameters specify just the used protocols or also concrete addresses. Defined values for this field are:
最初のパラメーターフィールドの長さは4ビットです。含まれているパラメーターが使用されているプロトコルのみを指定するのか、それともコンクリートアドレスを指定するかを示します。このフィールドの定義された値は次のとおりです。
0x0 : full addresses 0x1 : protocols only
0x0：フルアドレス0x1：プロトコルのみ
The second parameter field also has a length of 4 bits. It specifies the IP version number. Defined values for this field are:
2番目のパラメーターフィールドには、4ビットの長さもあります。IPバージョン番号を指定します。このフィールドの定義された値は次のとおりです。
0x1 : IPv4 0x2 : IPv6
0x1：IPv4 0x2：IPv6
The third parameter field has a length of 8 bits. It specifies a prefix length to be used for IP address wildcarding (see Section 1.1).
3番目のパラメーターフィールドの長さは8ビットです。IPアドレスのワイルドカードに使用するプレフィックスの長さを指定します（セクション1.1を参照）。
The fourth parameter field has also a length of 8 bits. It specifies the transport protocol. Defined values for this field are all values that are allowed in the 'Protocol' field of the IPv4 header [RFC791] or in the 'Next Header field' of the IPv6 header [RFC2460]. The set of defined numbers for these fields is maintained by the Internet Assigned Numbers Authority (IANA) under the label 'PROTOCOL NUMBERS'.
4番目のパラメーターフィールドには、8ビットの長さもあります。輸送プロトコルを指定します。このフィールドの定義値は、IPv4ヘッダー[RFC791]の「プロトコル」フィールドまたはIPv6ヘッダー[RFC2460]の「次のヘッダーフィールド」で許可されるすべての値です。これらのフィールドの定義された数値のセットは、ラベル「プロトコル番号」の下にあるインターネット割り当てされた数字の権限（IANA）によって維持されます。
The fifth parameter field has also a length of 8 bits. It specifies the location of the address. Defined values for this field are:
5番目のパラメーターフィールドの長さは8ビットです。アドレスの場所を指定します。このフィールドの定義された値は次のとおりです。
0x00 : internal (A0) 0x01 : inside (A1) 0x02 : outside (A2) 0x03 : external (A3)
0x00：内部（a0）0x01：内部（a1）0x02：outseer（a2）0x03：external（a3）
Port and address wildcarding can only be used in PER and PEA transactions. The address tuple attribute carries a port number of 0 if the port should be wildcarded. For IPv4, a prefix length less than 0x20 is IP address wildcarding. For IPv6, a prefix length less than 0x80 is IP address wildcarding.
ポートおよびアドレスワイルドカードは、PERおよびPEAトランザクションでのみ使用できます。アドレスタプル属性は、ポートをワイルドカードする必要がある場合、ポート番号0のポート番号を保持します。IPv4の場合、0x20未満のプレフィックスの長さはIPアドレスのワイルドカードです。IPv6の場合、0x80未満のプレフィックスの長さはIPアドレスのワイルドカードです。
The port range field must be always greater than zero, but at least 1.
ポートレンジフィールドは常にゼロより大きくなければなりませんが、少なくとも1は必要です。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0009 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |IP ver.| prefix length |trnsp. protocol| location |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0009 | 0x000C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x1 | prefix length |trnsp. protocol| location |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number | port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0009 | 0x0018 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x2 | prefix length |trnsp. protocol| location |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number | port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Address tuple attributes
図12：アドレスタプル属性
The policy reserve rule (PRR) parameter set attribute contains all parameters of the PRR request except the group identifier:
ポリシーリザーブルール（PRR）パラメーターセット属性には、グループ識別子を除くPRR要求のすべてのパラメーターが含まれます。
- NAT mode - port parity - requested inside IP version - requested outside IP version - transport protocol - port range
- NATモード - ポートパリティ - 内部IPバージョンの要求 - 外部IPバージョン - 輸送プロトコル - ポートレンジ
The attribute value field has a total size of 32 bits. It is sub-divided into six parameter fields.
属性値フィールドの合計サイズは32ビットです。6つのパラメーターフィールドに細分されます。
The first parameter field, called NM, has a length of 2 bits and specifies the requested NAT mode of the middlebox at which a reservation is requested. Defined values for this field are:
NMと呼ばれる最初のパラメーターフィールドの長さは2ビットで、予約が要求されるミドルボックスの要求されたNATモードを指定します。このフィールドの定義された値は次のとおりです。
01 : traditional 10 : twice
01：従来の10：2回
The second parameter field, called PP, has also a length of 2 bits. It specifies the requested port parity. Defined values for this field are:
PPと呼ばれる2番目のパラメーターフィールドには、2ビットの長さもあります。要求されたポートパリティを指定します。このフィールドの定義された値は次のとおりです。
00 : any 01 : odd 10 : even
00：任意の01：奇数10：偶数
The third and the fourth parameter fields are called IPi and IPo, respectively. Both have a length of 2 bits. They specify the requested version of the IP protocol at the inside (IPi) or outside (IPo) of the middlebox, respectively. Defined values for these fields are:
3番目と4番目のパラメーターフィールドは、それぞれIPIとIPOと呼ばれます。どちらも2ビットの長さです。彼らは、それぞれミドルボックスの内側（IPI）または外部（IPO）で要求されたバージョンのIPプロトコルを指定します。これらのフィールドの定義された値は次のとおりです。
00 : any 01 : IPv4 10 : IPv6
00：任意の01：IPv4 10：IPv6
The fifth parameter field has a length of 8 bits. It specifies the transport protocol for which the reservation should be made. A value of zero indicates that the reservation is requested for an IP address without specific selection of a protocol and a port number. Allowed non-zero values are the defined values for the 'protocol' field in the IPv4 header and IPv6 extension headers. The set of defined numbers for these fields is maintained by the Internet Assigned Numbers Authority (IANA) under the label 'PROTOCOL NUMBERS'.
5番目のパラメーターフィールドの長さは8ビットです。予約を行うべき輸送プロトコルを指定します。ゼロの値は、プロトコルとポート番号を具体的に選択することなく、IPアドレスの予約が要求されることを示します。許可されている非ゼロ値は、IPv4ヘッダーとIPv6拡張ヘッダーの「プロトコル」フィールドの定義値です。これらのフィールドの定義された数値のセットは、ラベル「プロトコル番号」の下にあるインターネット割り当てされた数字の権限（IANA）によって維持されます。
The sixth parameter field has a length of 16 bits. It contains an unsigned integer specifying the length of the port range that should be supported. A value of 0xFFFF indicates that the reservation should be made for all port numbers of the specified transport protocol. A port range field with the value of 0x0001 specifies that only a single port number should be reserved. Values greater than one indicate the number of consecutive port numbers to be reserved. A value of zero is not valid for this field.
6番目のパラメーターフィールドの長さは16ビットです。サポートする必要があるポート範囲の長さを指定する署名のない整数が含まれています。0xffffの値は、指定された輸送プロトコルのすべてのポート番号に対して予約を行う必要があることを示しています。0x0001の値を持つポートレンジフィールドは、単一のポート番号のみを予約する必要があることを指定します。1より大きい値は、保留される連続したポート番号の数を示します。ゼロの値は、このフィールドには無効です。
Please note that the wildcarding value 0xFFFF can only be used in the port range field in the PRR parameter set attribute. In the address tuple attribute, wildcarding of port numbers is specified by the port number field having a value of zero (see Section 4.3.8).
ワイルドカード値0xffffは、PRRパラメーターセット属性のポートレンジフィールドでのみ使用できます。アドレスタプル属性では、ポート番号のワイルドカードがゼロの値を持つポート番号フィールドによって指定されています（セクション4.3.8を参照）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000A | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NM |PP |IPi|IPo|trnsp. protocol| port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: PRR parameter set attribute
図13：PRRパラメーターセット属性
The policy enable rule (PER) parameter set attribute contains two parameters: the requested port parity, and the direction of the enabled data stream. The attribute value field has a total size of 32 bits, and it is sub-divided into 3 parameter fields.
ポリシーの有効化ルール（PER）パラメーターセット属性には、要求されたポートパリティと有効なデータストリームの方向という2つのパラメーターが含まれています。属性値フィールドの合計サイズは32ビットで、3つのパラメーターフィールドに下位されます。
The first parameter field has a length of 8 bits. It specifies the requested port parity. Defined values for this field are:
最初のパラメーターフィールドの長さは8ビットです。要求されたポートパリティを指定します。このフィールドの定義された値は次のとおりです。
0x00 : any 0x03 : same
0x00：任意の0x03：同じ
The second parameter field has a length of 8 bits. It specifies the direction of the enabled data stream. Defined values for this field are:
2番目のパラメーターフィールドの長さは8ビットです。有効なデータストリームの方向を指定します。このフィールドの定義された値は次のとおりです。
0x01 : inbound 0x02 : outbound 0x03 : bi-directional
0x01：インバウンド0x02：アウトバウンド0x03：双方向
The third parameter field has a length of 16 bits and is reserved.
3番目のパラメーターフィールドの長さは16ビットで、予約されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000B | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port parity | direction | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PER parameter set attribute
図14：パラメーターセット属性ごと
In the following, the formats of the different SIMCO message types are defined. The definitions are grouped into protocol error messages, session control messages, and policy rule control messages.
以下では、さまざまなSIMCOメッセージタイプの形式が定義されています。定義は、プロトコルエラーメッセージ、セッション制御メッセージ、およびポリシールール制御メッセージにグループ化されます。
When processing a received message, the middlebox might run into message processing problems before it can identify whether the message concerns session control or policy rule control. Also, it might not be possible to determine the message type, or it might detect a wrong message format. In these cases, the Badly Formed Message (BFM) notification or one of the following negative replies is sent:
受信したメッセージを処理すると、メッセージがセッション制御またはポリシールールコントロールに関係するかどうかを識別する前に、ミドルボックスがメッセージ処理の問題に遭遇する可能性があります。また、メッセージタイプを決定することも、間違ったメッセージ形式を検出することもできない場合があります。これらの場合、ひどく形成されたメッセージ（BFM）通知または次の否定的な応答のいずれかが送信されます。
0x0401 : BFM notification 0x0310 : wrong basic request message type 0x0311 : wrong request message sub-type 0x0312 : badly formed request
0x0401：BFM通知0x0310：間違った基本要求メッセージタイプ0x0311：誤ったリクエストメッセージサブタイプ0x0312：badly formed request
The Badly Formed Message (BFM) notification message is sent from the middlebox to the agent after a message was received that does not comply to the SIMCO message format definition. The BFM notification has no attributes and contains the SIMCO header only.
simcoメッセージ形式の定義に準拠していないメッセージが受信された後、ひどく形成されたメッセージ（BFM）通知メッセージがミドルボックスからエージェントに送信されます。BFM通知には属性がなく、SIMCOヘッダーのみが含まれています。
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 15: BFM notification structure
図15：BFM通知構造
Protocol error negative replies are sent from the middlebox to the agent if a message cannot be clearly interpreted, as it does not comply with any defined message format. Protocol error negative replies include 'wrong basic request message type' (0x0310), 'wrong request message sub-type' (0x0311), and 'badly formed request' (0x0312). These replies have no attributes. They consist of the SIMCO header only.
メッセージを明確に解釈できない場合、プロトコルエラーネガティブ応答は、メッセージを明確に解釈できない場合、ミドルボックスからエージェントに送信されます。プロトコルエラーの負の応答には、「間違った基本要求メッセージタイプ」（0x0310）、「間違った要求メッセージサブタイプ」（0x0311）、および「ひどく形成されたリクエスト」（0x0312）が含まれます。これらの応答には属性がありません。それらはSIMCOヘッダーのみで構成されています。
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 16: Protocol error negative reply structure
図16：プロトコルエラー負の応答構造
Session control messages include the following list of message types (composed of basic type and sub-type):
セッション制御メッセージには、次のメッセージタイプのリスト（基本タイプとサブタイプで構成されています）が含まれます。
0x0101 : SE request
0x0102 : SA request
0x0103 : ST request
0x0201 : SE positive reply
0x0202 : SA positive reply
0x0203 : ST positive reply
0x0310 : negative reply: wrong basic request message type
0x0311 : negative reply: wrong request message sub-type
0x0312 : negative reply: badly formed request
0x0320 : negative reply: request not applicable
0x0321 : negative reply: lack of resources
0x0322 : negative reply: protocol version mismatch
0x0323 : negative reply: authentication failed
0x0324 : negative reply: no authorization
0x0325 : negative reply: transport protocol problem
0x0326 : negative reply: security of underlying protocol layers
insufficient
0x0401 : BFM notification
0x0402 : AST notification
The Session Establishment (SE) request message is sent from the agent to the middlebox to request establishment of a session. The SE request message contains one or two attributes: a mandatory SIMCO version number attribute and an optional authentication challenge attribute requesting that the middlebox authenticate itself.
セッションの確立（SE）要求メッセージは、エージェントからミドルボックスに送信され、セッションの確立を要求します。SE要求メッセージには、1つまたは2つの属性が含まれています。必須のSIMCOバージョン番号属性と、ミドルボックスが認証するように要求するオプションの認証チャレンジ属性。
+--------------------------+
| SIMCO header |
+--------------------------+
| SIMCO protocol version |
+--------------------------+
| authentication challenge | optional
+--------------------------+
Figure 17: Structure of SE request
図17：SEリクエストの構造
The Session Establishment (SE) reply message indicates completion of session establishment. It contains a single mandatory attribute: the middlebox capabilities attribute.
セッション設立（SE）返信メッセージは、セッション設立の完了を示します。単一の必須属性が含まれています：Middlebox機能属性。
+--------------------------+
| SIMCO header |
+--------------------------+
| middlebox capabilities |
+--------------------------+
Figure 18: Structure of SE positive reply
図18：SE肯定的な応答の構造
If the agent requested middlebox authentication, or if the middlebox wants the agent to authenticate itself, then the middlebox replies on the SE request with a Session Authentication (SA) reply message instead of an SE reply message. The SA reply message contains two optional attributes, but at least one of them needs to be present. The first one is an authentication challenge attribute requesting that the agent authenticate itself. The second one is an authentication token attribute authenticating the middlebox as the reply to an authentication request by the agent.
エージェントがミドルボックス認証を要求した場合、またはミドルボックスがエージェントに自分自身を認証することを望んでいる場合、SE応答メッセージの代わりにセッション認証（SA）応答メッセージを使用して、SEリクエストでミドルボックスが応答します。SA返信メッセージには2つのオプションの属性が含まれていますが、少なくとも1つは存在する必要があります。最初のものは、エージェントが自らを認証することを要求する認証チャレンジ属性です。2つ目は、エージェントによる認証要求への返信として、ミドルボックスを認証する認証トークン属性です。
+--------------------------+
| SIMCO header |
+--------------------------+
| authentication challenge | optional
+--------------------------+
| authentication token | optional
+--------------------------+
Figure 19: Structure of SA positive reply
図19：SAの肯定的な応答の構造
The Session Authentication (SA) request message is sent from the agent to the middlebox after an initial SE request was answered by an SA reply. The SE request message contains one optional attribute: an authentication token attribute authenticating the agent as the response to an authentication challenge sent by the middlebox in an SA reply.
セッション認証（SA）リクエストメッセージは、最初のSEリクエストがSA返信によって回答された後、エージェントからミドルボックスに送信されます。SEリクエストメッセージには、1つのオプションの属性が含まれています。AETUNITIONTOKEN属性は、SA返信でミドルボックスから送信された認証チャレンジへの応答としてエージェントを認証する属性です。
+--------------------------+
| SIMCO header |
+--------------------------+
| authentication token | optional
+--------------------------+
Figure 20: Structure of SA request
図20：SAリクエストの構造
The Session Termination (ST) request message is sent from the agent to the middlebox to request termination of a session. The ST positive reply is returned, acknowledging the session termination. Both messages have no attributes and contain the SIMCO header only.
セッション終了（ST）要求メッセージは、エージェントからミドルボックスに送信され、セッションの終了を要求します。ST肯定的な応答が返され、セッション終了を認めています。両方のメッセージには属性がなく、SIMCOヘッダーのみが含まれています。
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 21: Structure of ST request and positive reply
図21：STリクエストの構造と肯定的な返信
There are nine different negative reply messages that can be sent from a middlebox to the agent if the middlebox rejects an SE request. Three of them are protocol error negative replies (0x031X) already covered in Section 4.1.2.
ミドルボックスがSEリクエストを拒否した場合、ミドルボックスからエージェントに送信できる9つの異なるネガティブ応答メッセージがあります。そのうちの3つは、セクション4.1.2ですでにカバーされているプロトコルエラーネガティブ応答（0x031x）です。
The remaining six negative replies are specific to session establishment. One of them, the 'protocol version mismatch' negative reply (0x0322), contains a single attribute: the protocol version attribute.
残りの6つの否定的な応答は、セッションの確立に固有です。そのうちの1つである「プロトコルバージョンの不一致」否定的な応答（0x0322）には、単一の属性が含まれています：プロトコルバージョン属性。
+--------------------------+
| SIMCO header |
+--------------------------+
| SIMCO protocol version |
+--------------------------+
Figure 22a: Structure of SE negative replies
図22a：SE陰性応答の構造
The remaining three replies include 'request not applicable' (0x0320), 'lack of resources' (0x0321), 'authentication failed' (0x0323), 'no authorization' (0x0324), 'transport protocol problem' (0x0325), and 'security of underlying protocol layers insufficient' (0x0326). They consist of the SIMCO header only.
残りの3つの返信には、「該当なし」（0x0320）、「リソースの不足」（0x0321）、「認証が失敗した」（0x0323）、「認可なし」（0x0324）、「輸送プロトコルの問題」（0x0325）、および '基礎となるプロトコル層のセキュリティが不十分である」（0x0326）。それらはSIMCOヘッダーのみで構成されています。
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 22b: Structure of SE negative replies
図22b：SE陰性応答の構造
The Asynchronous Session Termination (AST) notification message is sent from the middlebox to the agent, if the middlebox wants to terminate a SIMCO session. It has no attributes and contains the SIMCO header only.
ミドルボックスがSIMCOセッションを終了する場合、非同期セッション終了（AST）通知メッセージは、ミドルボックスからエージェントに送信されます。属性はなく、SIMCOヘッダーのみが含まれています。
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 22a: Structure of AST notifications
図22a：AST通知の構造
Policy Rule control messages include the following list of message types (composed of basic type and sub-type):
ポリシールール制御メッセージには、メッセージタイプの次のリスト（基本タイプとサブタイプで構成されています）が含まれます。
0x0111 : PRR request
0x0112 : PER request
0x0113 : PEA request
0x0114 : PDR request
0x0115 : PLC request
0x0121 : PRS request
0x0122 : PRL request
0x0211 : PRR positive reply
0x0212 : PER positive reply
0x0214 : PDR positive reply
0x0215 : PLC positive reply
0x0216 : PRD positive reply
0x0221 : PRS positive reply
0x0223 : PES positive reply
0x0224 : PDS positive reply
0x0222 : PRL positive reply
0x0310 : negative reply: wrong basic request message type
0x0311 : negative reply: wrong request message sub-type
0x0312 : negative reply: badly formed request
0x0340 : negative reply: transaction not supported
0x0341 : negative reply: agent not authorized for this transaction
0x0342 : negative reply: no resources available for this
transaction
0x0343 : negative reply: specified policy rule does not exist
0x0344 : negative reply: specified policy rule group does not exist
0x0345 : negative reply: not authorized for accessing this policy
0x0346 : negative reply: not authorized for accessing specified
group
0x0347 : negative reply: requested address space not available
0x0348 : negative reply: lack of IP addresses
0x0349 : negative reply: lack of port numbers
0x034A : negative reply: middlebox configuration failed
0x034B : negative reply: inconsistent request
0x034C : negative reply: requested wildcarding not supported
0x034D : negative reply: protocol type doesn't match
0x034E : negative reply: NAT mode not supported
0x034F : negative reply: IP version mismatch
0x0350 : negative reply: conflict with existing rule
0x0351 : negative reply: not authorized to change lifetime
0x0352 : negative reply: lifetime can't be extended
0x0353 : negative reply: illegal IP Address
0x0354 : negative reply: protocol type not supported
0x0355 : negative reply: illegal port number
0x0356 : negative reply: illegal NOSP
0x0357 : negative reply: already enable PID
0x0358 : negative reply: parity doesn't match
0x0401 : negative reply: BFM notification
0x0403 : negative reply: ARE notification
SIMCO maintains an owner attribute for each policy rule at the middlebox. Depending on the configuration of the middlebox, several agents may access the same policy rule; see also [RFC3989], Sections 2.1.5 and 2.3.4.
Simcoは、Middleboxの各ポリシールールの所有者属性を維持しています。ミドルボックスの構成に応じて、いくつかのエージェントが同じポリシールールにアクセスする場合があります。[RFC3989]、セクション2.1.5および2.3.4も参照してください。
To keep all agents synchronized about the state of their policy rules, SIMCO generates Asynchronous Rule Event (ARE) notifications. When an agent is reserving or enabling a policy rule, the middlebox sends an ARE to all agents that are authorized to access this policy rule. The middlebox sends an ARE to all agents authorized to access this policy rule when the rule lifetime is modified or if the rule is deleted.
すべてのエージェントをポリシールールの状態について同期させるために、SIMCOは非同期ルールイベント（ARE）の通知を生成します。エージェントがポリシールールを予約または有効にしている場合、ミドルボックスは、このポリシールールにアクセスすることを許可されたすべてのエージェントに送信します。ミドルボックスは、ルールのライフタイムが変更された場合、またはルールが削除された場合、このポリシールールにアクセスすることを許可されたすべてのエージェントに送信します。
The Policy Reserve Rule (PRR) request message is sent from the agent to the middlebox to request reservation of an IP address (and potentially also a range of port numbers) at the middlebox. Besides the SIMCO header, the request message contains two or three attributes. The first one is the PRR parameter set attribute specifying all parameters of the request except the requested policy rule lifetime and the group identifier. The missing parameters are covered by the following two attributes. The last attribute, the group identifier, is optional.
ポリシーリザーブルール（PRR）リクエストメッセージは、エージェントからミドルボックスに送信され、MiddleboxのIPアドレス（および潜在的にもさまざまなポート番号）の予約をリクエストします。SIMCOヘッダーに加えて、リクエストメッセージには2つまたは3つの属性が含まれています。最初のものは、要求されたポリシールールのライフタイムとグループ識別子を除く、リクエストのすべてのパラメーターを指定するPRRパラメーターセット属性です。欠落しているパラメーターは、次の2つの属性でカバーされています。最後の属性であるグループ識別子はオプションです。
+--------------------------+
| SIMCO header |
+--------------------------+
| PRR parameter set |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| group identifier | optional
+--------------------------+
Figure 23: Structure of PRR request
図23：PRR要求の構造
The Policy Enable Rule (PER) request message is sent from the agent to the middlebox to request enabling of data communication between an internal and an external address. Besides the SIMCO header, the request message contains four or five attributes. The first one is the PER parameter set attribute specifying all parameters of the request except the internal address, the external address, the requested policy rule lifetime, and the group identifier. The missing parameters are covered by the following four attributes. Two address tuple parameters specify internal and external address tuples. Much like the PRR request, the last two attributes specify the requested lifetime and group identifier. The group identifier attribute is optional.
ポリシーを有効にするルール（PER）リクエストメッセージは、エージェントからミドルボックスに送信され、内部アドレスと外部アドレス間のデータ通信の有効化を要求します。SIMCOヘッダーに加えて、リクエストメッセージには4つまたは5つの属性が含まれています。最初のものは、内部アドレス、外部アドレス、要求されたポリシールールの寿命、およびグループ識別子を除く、要求のすべてのパラメーターを指定するパラメーターセット属性ごとです。欠落しているパラメーターは、次の4つの属性でカバーされています。2つのアドレスタプルパラメーターは、内部および外部アドレスタプルを指定します。PRRリクエストと同じように、最後の2つの属性は、要求された生涯およびグループ識別子を指定します。グループ識別子属性はオプションです。
+--------------------------+
| SIMCO header |
+--------------------------+
| PER parameter set |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| group identifier | optional
+--------------------------+
Figure 24: Structure of PER request
図24：リクエストごとの構造
The Policy Enable rule After reservation (PEA) request message is sent from the agent to the middlebox to request enabling of data communication between an internal and an external address. It is similar to the PER request. There is just one difference. The optional group identifier attribute of the PER request is replaced by a mandatory policy rule identifier attribute referencing an already established policy reserve rule established by a PRR transaction.
ポリシーを有効にして、予約後（PEA）要求メッセージがエージェントからミドルボックスに送信され、内部アドレスと外部アドレス間のデータ通信の有効化を要求します。リクエストごとに似ています。違いは1つだけです。PERリクエストのオプションのグループ識別子属性は、PRRトランザクションによって確立されたすでに確立されたポリシーリザーブルールを参照する必須ポリシールール識別子属性に置き換えられます。
+--------------------------+
| SIMCO header |
+--------------------------+
| PER parameter set |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| policy rule identifier |
+--------------------------+
Figure 25: Structure of PEA request
図25：PEAリクエストの構造
The group identifier attribute is not included in the PEA request, since the group membership of the policy enable rule is inherited of the policy reserve rule.
グループ識別子属性は、ポリシー有効化ルールのグループメンバーシップがポリシーリザーブルールに継承されているため、PEAリクエストには含まれていません。
The Policy Rule Lifetime Change (PLC) request message is sent from the agent to the middlebox to request a change of the remaining policy lifetime. Besides the SIMCO header, the request message contains two attributes specifying the policy rule to which the change should be applied and specifying the requested remaining lifetime.
ポリシールールのライフタイム変更（PLC）リクエストメッセージは、エージェントからミドルボックスに送信され、残りのポリシー寿命の変更を要求します。SIMCOヘッダーに加えて、リクエストメッセージには、変更を適用するポリシールールを指定し、要求された残りの寿命を指定する2つの属性が含まれています。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 26: Structure of PLC request
図26：PLC要求の構造
The Policy Rule Status (PRS) request message is sent from the agent to the middlebox to request a report on the status of a specified policy rule. Besides the SIMCO header, the request message contains just one attribute specifying the policy rule for which the report is requested.
ポリシールールステータス（PRS）リクエストメッセージは、エージェントからミドルボックスに送信され、指定されたポリシールールのステータスに関するレポートをリクエストします。SIMCOヘッダーに加えて、リクエストメッセージには、レポートが要求されるポリシールールを指定する属性が1つだけ含まれています。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
Figure 27: Structure of PRS request
図27：PRSリクエストの構造
The Policy Rule List (PRL) request message is sent from the agent to the middlebox to request a list of all policy rules accessible to the agent. The message consists of the SIMCO header only.
ポリシールールリスト（PRL）リクエストメッセージはエージェントからミドルボックスに送信され、エージェントがアクセスできるすべてのポリシールールのリストをリクエストします。メッセージは、Simcoヘッダーのみで構成されています。
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 28: Structure of PRL request
図28：PRL要求の構造
The Policy Disable Rule (PDR) request message is sent from the agent to the middlebox to request a disable rule. The message consists of the SIMCO header, an internal address tuple, an external address tuple, and a lifetime attribute.
ポリシー無効化ルール（PDR）要求メッセージは、エージェントからミドルボックスに送信され、無効ルールを要求します。メッセージは、Simcoヘッダー、内部アドレスタプル、外部アドレスタプル、および生涯属性で構成されています。
+--------------------------+
| SIMCO header |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 29: Structure of PDR request
図29：PDR要求の構造
The Policy Reserve Rule (PRR) positive reply is sent after successful reservation of an address at the inside or outside of the middlebox. The message contains four mandatory attributes and an optional attribute: the policy rule identifier of the new policy reserve rule, the corresponding group identifier, the remaining lifetime of the policy rule, the reserved outside address tuple, and the optional reserved inside address tuple. The reserved inside address tuple is only returned when the middlebox is of type twice-NAT.
ポリシーリザーブルール（PRR）は、ミドルボックスの内側または外側の住所の予約が成功した後に送信されます。メッセージには、4つの必須属性とオプションの属性が含まれています。新しいポリシーリザーブルールのポリシールール識別子、対応するグループ識別子、ポリシールールの残りの寿命、予約済みの外部アドレスタプル、およびオプションの予約された内部アドレスタプル。内部のアドレスタプルは、ミドルボックスがタイプの2倍のネットの場合にのみ返されます。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (inside) | optional
+--------------------------+
Figure 30: Structure of PRR positive reply
図30：PRR肯定的な応答の構造
The Policy Enable Rule (PER) positive reply is sent after the middlebox successfully enables data transfer between an internal and an external address (by using a PER or PEA request message). The message contains five attributes: the policy rule identifier of the new policy enable rule, the corresponding group identifier, the remaining lifetime of the policy rule, the address tuple at the outside of the middlebox, and the address tuple at the inside of the middlebox.
ミドルボックスが内部アドレスと外部アドレス間のデータ転送を正常に有効にすると、ポリシーを有効にするルール（PER）が送信されます（PERまたはPEAリクエストメッセージを使用して）。メッセージには5つの属性が含まれています。新しいポリシーを有効にするポリシールール識別子、対応するグループ識別子、ポリシールールの残りの寿命、ミドルボックスの外側のアドレスタプル、およびミドルボックスの内側のアドレスタプル。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (inside) |
+--------------------------+
Figure 31: Structure of PER positive reply
図31：肯定的な応答ごとの構造
The Policy Lifetime Change (PLC) positive reply is sent after the middlebox changes the lifetime of a policy rule to a positive (non-zero) value. The message contains just a single attribute: the remaining lifetime of the policy rule.
ポリシーライフタイム変更（PLC）肯定的な返信は、ミドルボックスがポリシールールの寿命を肯定的な（非ゼロ）値に変更した後に送信されます。メッセージには、ポリシールールの残りの寿命という単一の属性のみが含まれています。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 32: Structure of PLC positive reply
図32：PLC陽性応答の構造
The Policy Rule Deleted (PRD) positive reply is sent after the middlebox changes the remaining lifetime of a policy rule to zero, which means that it terminates the policy rule. The message consists of the SIMCO header only.
削除されたポリシールール（PRD）は、ミドルボックスがポリシールールの残りの寿命をゼロに変更した後に送信されます。つまり、ポリシールールを終了します。メッセージは、Simcoヘッダーのみで構成されています。
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 33: Structure of PRD positive reply
図33：PRD肯定的な応答の構造
The Policy Reserve Rule Status (PRS) positive reply is used for reporting the status of a policy reserve rule. The message format is identical with the format of the PRR positive reply except that it contains, in addition, a policy rule owner attribute.
ポリシーリザーブルールステータス（PRS）肯定的な返信は、ポリシーリザーブルールのステータスを報告するために使用されます。メッセージ形式は、PRRの肯定的な応答の形式と同一です。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (inside) | optional
+--------------------------+
| policy rule owner |
+--------------------------+
Figure 34: Structure of PRS positive reply
図34：PRS肯定的な応答の構造
The Policy Enable Rule Status (PES) positive reply is used for reporting the status of a policy enable rule.
ポリシーを有効にするルールステータス（PES）肯定的な返信は、ポリシーイネーブルルールのステータスを報告するために使用されます。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| PER parameter set |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (inside) |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| policy rule owner |
+--------------------------+
Figure 35: Structure of PES positive reply
図35：PES肯定的な応答の構造
The Policy Disable Rule Status (PDS) positive reply is used for reporting the status of a policy disable rule. The message contains five attributes: the policy rule identifier, the internal and external address tuples, the policy disable rule lifetime, and the policy rule owner.
ポリシーを無効にするルールステータス（PDS）肯定的な返信は、ポリシー無効のルールのステータスを報告するために使用されます。このメッセージには、5つの属性が含まれています。ポリシールール識別子、内部および外部アドレスのタプル、ポリシーはルールの寿命を無効にし、ポリシールール所有者です。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| policy rule owner |
+--------------------------+
Figure 36: Structure of PDS positive reply
図36：PDS肯定的な応答の構造
The Policy Rule List (PRL) positive reply is used for reporting the list of all established policy rules. The number of attributes of this message is variable. The message contains one policy rule identifier attribute per established policy rule.
ポリシールールリスト（PRL）は、確立されたすべてのポリシールールのリストを報告するために使用されます。このメッセージの属性の数は変動します。メッセージには、確立されたポリシールールごとに1つのポリシールール識別子属性が含まれています。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule identifier |
+--------------------------+
| |
. . .
| |
+--------------------------+
| policy rule identifier |
+--------------------------+
Figure 37: Structure of PRL positive reply
図37：PRL陽性応答の構造
The Policy Disable Rule (PDR) positive reply is sent after the middlebox successfully enables the policy disable rule and removal of conflicting policy rules. The message contains two attributes: the policy rule identifier of the new policy disable rule, and the remaining lifetime of the policy rule.
ポリシーは、ミドルボックスがポリシーを無効にして矛盾するポリシールールの削除を無効にすることを正常に有効にすると、肯定的な返信が送信されます。メッセージには、2つの属性が含まれています。新しいポリシーを無効にするポリシールール識別子と、ポリシールールの残りの寿命です。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 38: Structure of PDR positive reply
図38：PDR陽性応答の構造
Session establishment negative replies are sent from the middlebox to the agent if a middlebox rejects a policy rule control request. Beyond protocol error replies, a number of policy rule control-specific negative reply messages that can be sent. They are listed at the beginning of Section 5.3. They all have no attributes. They consist of the SIMCO header only.
ミドルボックスがポリシールール制御要求を拒否した場合、セッションの確立否定的な返信はミドルボックスからエージェントに送信されます。プロトコルエラーを超えて、送信できる多くのポリシールール制御固有のネガティブ応答メッセージ。セクション5.3の冒頭にリストされています。それらにはすべて属性がありません。それらはSIMCOヘッダーのみで構成されています。
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 39: Structure of Policy rule control negative replies
図39：ポリシールール制御の構造否定的な応答
The Asynchronous Policy Rule Event (ARE) notification message is sent from the middlebox to the agent. All agents participating in an open SIMCO session that are authorized to access this policy rule and are not explicitly requesting an action (i.e., reserving, enabling, and changing lifetime) receive such an ARE notification, when:
非同期ポリシールールイベント（ARE）通知メッセージは、ミドルボックスからエージェントに送信されます。このポリシールールにアクセスすることが許可されているオープンSIMCOセッションに参加し、アクションを明示的に要求していないすべてのエージェント（つまり、寿命の予約、有効化、変更）は、次の場合に通知を受け取ります。
- a policy rule is deleted (lifetime attribute = 0)
- ポリシールールが削除されます（Lifetime属性= 0）
- a policy rule is reserved (lifetime attribute = lifetime)
- ポリシールールは予約されています（生涯属性= lifetime）
- a policy rule is enabled (lifetime attribute = lifetime)
- ポリシールールが有効になります（Lifetime属性= lifetime）
- a policy rule's lifetime changed (lifetime attribute = lifetime)
- ポリシールールの寿命が変更されました（生涯属性=生涯）
Besides the SIMCO header, the request message contains two attributes specifying the policy rule that is concerned and the current lifetime.
SIMCOヘッダーに加えて、リクエストメッセージには、関係するポリシールールと現在の生涯を指定する2つの属性が含まれています。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 40: Structure of ARE notification
図40：ARE通知の構造
This section describes common processing of all messages that are received by a middlebox.
このセクションでは、ミドルボックスで受信されるすべてのメッセージの一般的な処理について説明します。
1) When a message arrives at a middlebox, the header is checked for consistency before the payload is processed.
1) メッセージがミドルボックスに到着すると、ペイロードが処理される前にヘッダーの一貫性が確認されます。
o If the header checks fail, the middlebox sends a BFM notification.
o ヘッダーチェックが失敗した場合、MiddleboxはBFM通知を送信します。
o If a session is already established, then the middlebox also sends an AST notification and closes the connection.
o セッションが既に確立されている場合、MiddleBoxはAST通知も送信し、接続を閉じます。
2) The middlebox waits until it has received as many octets from the agent as specified by the message length plus 8 octets (the length of the SIMCO header).
2) ミドルボックスは、メッセージの長さと8オクテット（SIMCOヘッダーの長さ）で指定されているように、エージェントから多くのオクテットを受信するまで待機します。
o If the middlebox is still waiting and does not receive any more octets from the agent for 60 seconds, it sends a BFM notification.
o ミドルボックスがまだ待っていて、エージェントから60秒間これ以上オクテットを受け取らない場合、BFM通知を送信します。
o If a session is already established, then the middlebox also sends an AST notification and closes the connection after sending the BFM notification; otherwise, it closes the connection without sending another message.
o セッションが既に確立されている場合、MiddleBoxはAST通知も送信し、BFM通知を送信した後に接続を閉じます。それ以外の場合、別のメッセージを送信せずに接続を閉じます。
3) After receiving a sufficient number of octets, the middlebox reads the transaction identifier and the basic message type.
3) 十分な数のオクテットを受信した後、ミドルボックスはトランザクション識別子と基本メッセージタイプを読み取ります。
o If the value of the basic message type fields does not equal 0x01 (request message), then the middlebox stops processing the message and sends a negative reply of type 'wrong basic request message type' (0x0310) to the agent.
o 基本メッセージタイプフィールドの値が0x01（リクエストメッセージ）に等しくない場合、MiddleBoxはメッセージの処理を停止し、「間違った基本要求メッセージタイプ」（0x0310）の否定的な返信をエージェントに送信します。
o If no session is established, then the middlebox closes the connection after sending the 0x0310 reply.
o セッションが確立されていない場合、0x0310の返信を送信した後、Middleboxは接続を閉じます。
4) Then the middlebox checks the message sub-type.
4) 次に、MiddleBoxがメッセージサブタイプをチェックします。
o If no session is established, then only sub-type 'session establishment' (0x01) is accepted. For all other sub-types, the middlebox sends a reply of type 'wrong request message sub-type' (0x0311) to the agent and closes the connection after sending the reply.
o セッションが確立されていない場合、サブタイプの「セッション確立」（0x01）のみが受け入れられます。他のすべてのサブタイプについて、Middleboxはタイプ「誤った要求メッセージサブタイプ」（0x0311）の返信をエージェントに送信し、返信を送信した後に接続を閉じます。
o If a session is already established, then the middlebox checks if the message sub-type is one of the sub-types defined in Section 4.2.2. (excluding 'session establishment' (0x01), 'session termination' (0x03), and 'policy rule deletion'(0x15)).
o セッションが既に確立されている場合、MiddleBoxはメッセージサブタイプがセクション4.2.2で定義されているサブタイプの1つであるかどうかを確認します。（「セッション確立」（0x01）、「セッション終了」（0x03）、および「ポリシールール削除」（0x15）を除く）。
o If not, then the middlebox stops processing the message and sends a reply of type 'wrong request message sub-type' (0x0311) to the agent.
o そうでない場合、Middleboxはメッセージの処理を停止し、タイプ「誤った要求メッセージサブタイプ」（0x0311）の返信をエージェントに送信します。
5) Then the middlebox checks the TLV-structured attributes in the message.
5) 次に、MiddleBoxはメッセージ内のTLV構造属性をチェックします。
o If their type or number does not comply with the defined format for this message type, the middlebox stops processing the message and sends a reply of type 'badly formed request' (0x0312) to the agent.
o このタイプまたは番号がこのメッセージタイプの定義された形式に準拠していない場合、MiddleBoxはメッセージの処理を停止し、タイプの「Badly Formed Request」（0x0312）の返信をエージェントに送信します。
o If no session is established, then the middlebox closes the connection after sending the 0x0312 reply.
o セッションが確立されていない場合、0x0312の返信を送信した後、Middleboxは接続を閉じます。
6) After all message format checks are passed, the middlebox processes the content of the attributes as described in the following sections.
6) すべてのメッセージ形式のチェックが渡された後、ミドルボックスは、次のセクションで説明されているように属性のコンテンツを処理します。
For session control, the agent can send SE, SA, and ST request messages. The middlebox then sends per request a single reply back to the agent. Additionally, the middlebox may send unsolicited AST notifications.
セッション制御のために、エージェントはSE、SA、およびSTリクエストメッセージを送信できます。その後、ミドルボックスは要求ごとにエージェントに1回の返信を送信します。さらに、ミドルボックスは未承諾のAST通知を送信する場合があります。
For each session, there is a session state machine illustrated by the figure below.
各セッションについて、下の図に示されているセッション状態マシンがあります。
SE/BFM
SE/0x031X
SE/0x032X
+-------+
| v
+----------+
| CLOSED |----------------+
+----------+ |
| ^ ^ |
| | | SA/BFM | SE/SA
| | | SA/0x031X |
| | | SA/0x032X |
SE/SE | | | ST/ST v
| | | AST +----------+
| | +------------| NOAUTH |
| | +----------+
| | AST |
v | ST/ST | SA/SE
+----------+ |
| OPEN |<---------------+
+----------+
Figure 41: Session state machine
図41：セッション状態マシン
The figure illustrates all possible state transitions of a session. Request transactions (SE, SA, ST) are denoted by a descriptor of the request message, a '/' symbol, and a descriptor of the reply message. Notification transactions are denoted just by the a notification descriptor. For example, a successful SE transaction is denoted by 'SE/SE', and an AST notification is denoted by 'AST'.
この図は、セッションのすべての可能な状態遷移を示しています。リクエストトランザクション（SE、SA、ST）は、リクエストメッセージの記述子、「/」記号、および返信メッセージの記述子によって示されます。通知トランザクションは、A通知記述子のみによって示されます。たとえば、SEトランザクションの成功は「SE/SE」で示され、AST通知は「AST」で示されます。
Initially, all sessions are in state CLOSED. From there, a successful SE transaction can change its state either to NOAUTH or to OPEN. From state NOAUTH, a successful SA transaction changes session state to OPEN. A failed SA transaction changes session state from NOAUTH back to CLOSED. Successful ST transactions and AST notifications change sessions from state NOAUTH or from state OPEN to state CLOSED.
当初、すべてのセッションは州が閉鎖されています。そこから、SEトランザクションが成功すると、その状態をNOAUTHまたは開くことに変更できます。STATE NOAUTHから、SAトランザクションが成功したため、セッション状態が開きます。失敗したSAトランザクションは、Noauthから閉じた状態にセッション状態を変更します。STトランザクションとAST通知の成功は、State NoauthまたはState OpenからState Closedへのセッションを変更します。
A SIMCO session is established in state OPEN, which is the only state in which the middlebox accepts requests other than SE, SA, and ST.
SIMCOセッションはState Openで確立されています。これは、MiddleboxがSE、SA、ST以外のリクエストを受け入れる唯一の状態です。
The SE request is only applicable if the session is in state CLOSED. If a session is in state NOAUTH or OPEN, then the middlebox sends a negative reply message of type 'request not applicable' (0x0320) to the agent, leaving the state of the session unchanged.
SE要求は、セッションが州が閉じられている場合にのみ適用されます。セッションがState NoauthまたはOpenにある場合、MiddleBoxはタイプ「リクエスト該当なし」（0x0320）の否定的な返信メッセージをエージェントに送信し、セッションの状態を変更せずに残します。
Before processing the content of the SE request message, the middlebox may check its resources and decide that available resources are not sufficient to serve the agent. In such a case, the middlebox returns a negative reply of type 'lack of resources' (0x0321) and closes the connection. Furthermore, the middlebox may decide to reject the SE request if the selected network connection and its protocol specific parameters are not acceptable for the middlebox. In such a case, the middlebox returns a negative reply of type 'transport protocol problem' (0x0325) and closes the connection. The middlebox returns a negative reply of type 'security of underlying protocol layers insufficient' (0x0326) and closes the connection, if the security properties of the network connection do not match the middlebox's requirements.
SE要求メッセージのコンテンツを処理する前に、MiddleBoxはリソースを確認し、利用可能なリソースがエージェントにサービスを提供するのに十分ではないと判断する場合があります。そのような場合、ミドルボックスは「リソースの欠如」（0x0321）のタイプの否定的な応答を返し、接続を閉じます。さらに、Middleboxは、選択したネットワーク接続とそのプロトコル固有のパラメーターがミドルボックスに受け入れられない場合、SE要求を拒否することを決定する場合があります。そのような場合、MiddleBoxは「輸送プロトコル問題」（0x0325）のタイプの否定的な応答を返し、接続を閉じます。ミドルボックスは、ネットワーク接続のセキュリティプロパティがMiddleboxの要件と一致しない場合、「基礎となるプロトコル層のセキュリティが不十分」（0x0326）（0x0326）のタイプの否定的な応答を返します。
Processing of an SE request message starts with checking the major and minor protocol version number in the protocol version attribute. If the middlebox does not support the specified version number, then the middlebox returns a negative reply message of type 'protocol version mismatch' (0x0322) with the protocol version attribute indicating a version number that is supported by the middlebox. After sending this reply, the middlebox closes the connection.
SE要求メッセージの処理は、プロトコルバージョン属性の主要なプロトコルバージョン番号をチェックすることから始まります。Middleboxが指定されたバージョン番号をサポートしていない場合、MiddleBoxは、MiddleBoxでサポートされているバージョン番号を示すプロトコルバージョン属性を使用して、「プロトコルバージョンの不一致」（0x0322）のタイプ「プロトコルバージョンのMismatch」（0x0322）の否定的な返信メッセージを返します。この返信を送信した後、ミドルボックスは接続を閉じます。
If the agent is already sufficiently authenticated by means of the underlying network connection (for instance, IPsec or TLS), then the middlebox checks whether the agent is authorized to configure the middlebox. If it is not, the middlebox returns a negative reply of type 'no authorization' (0x0324) and closes the connection.
エージェントが基礎となるネットワーク接続（たとえば、IPSECまたはTLS）によってすでに十分に認証されている場合、ミドルボックスはエージェントがミドルボックスの構成を許可されているかどうかを確認します。そうでない場合、MiddleBoxはタイプ「認証なし」（0x0324）の否定的な応答を返し、接続を閉じます。
A positive reply on the SE request may be of sub-type SE or SA. An SE request is sent after both parties sufficiently authenticate and authorize each other. An SA reply message is sent if explicit authentication is requested by any party. The agent requests explicit authentication by adding an authentication challenge attribute to the SE request message. The middlebox requests explicit authentication by returning an SA reply message with an authentication challenge attribute to the agent. If both parties request explicit authentication, then the SA reply message contains both an authentication challenge attribute for the agent and an authentication token attribute authenticating the middlebox.
SEリクエストに対する肯定的な返信は、サブタイプのSEまたはSAのものである場合があります。両当事者がお互いを十分に認証し、承認した後、SEリクエストが送信されます。任意の当事者が明示的な認証が要求された場合、SA返信メッセージが送信されます。エージェントは、SE要求メッセージに認証チャレンジ属性を追加することにより、明示的な認証を要求します。Middleboxは、Ateruthince Challenge属性を使用してSA Replyメッセージを返すことにより、明示的な認証を要求します。両方の当事者が明示的な認証を要求する場合、SA Replyメッセージには、エージェントの認証チャレンジ属性と、ミドルボックスを認証する認証トークン属性の両方が含まれています。
If the SE request message contains an authentication challenge attribute, then the middlebox checks if it can authenticate itself. If yes, it adds a corresponding authentication token attribute to the SA reply. If it cannot authenticate based on the authentication challenge attribute, it adds an authentication token attribute to the SA reply message with a value field of length zero.
SE要求メッセージに認証チャレンジ属性が含まれている場合、MiddleBoxはそれ自体を認証できるかどうかをチェックします。はいの場合、SA応答に対応する認証トークン属性を追加します。Authentication Challenge属性に基づいて認証できない場合、長さゼロの値フィールドを持つSA応答メッセージに認証トークン属性を追加します。
If the middlebox wants the agent to explicitly authenticate itself, then the middlebox creates an authentication challenge attribute for the agent and adds it to the SA reply message.
ミドルボックスがエージェントに明示的に認証することを望んでいる場合、ミドルボックスはエージェントの認証チャレンジ属性を作成し、SA応答メッセージに追加します。
If the middlebox replies to the SE request message with an SA reply message, then the session state changes from CLOSED to NO_AUTH.
MiddleboxがSA Replectメッセージを使用してSE要求メッセージに返信すると、セッション状態はクローズドからNO_AUTHに変更されます。
If the SE request message did not contain an authentication challenge attribute and if the middlebox does not request the agent to explicitly authenticate itself, then the middlebox sends an SE reply message in response to the SE request message. This implies that the session state changes from CLOSED to OPEN.
SE要求メッセージに認証チャレンジ属性が含まれておらず、ミドルボックスがエージェントに明示的に認証するようにエージェントに要求しない場合、MiddleBoxはSE要求メッセージに応じてSE応答メッセージを送信します。これは、セッション状態が閉じて開いてから変化することを意味します。
The SE reply message contains a capabilities attribute describing the middlebox capabilities.
SE Replyメッセージには、ミドルボックス機能を説明する機能属性が含まれています。
The SA request is only applicable if the session is in state NOAUTH. If a session is in state CLOSED or OPEN, then the middlebox sends a negative reply message of type 'request not applicable' (0x0320) to the agent. The state of the session remains unchanged.
SA要求は、セッションがState Noauthにある場合にのみ適用されます。セッションが状態が閉じているか、開いている場合、ミドルボックスは「リクエストは該当しない」（0x0320）の否定的な返信メッセージをエージェントに送信します。セッションの状態は変わらないままです。
After receiving an SA request message in state NOAUTH, the middlebox checks if the agent is sufficiently authenticated. Authentication may be based on an authentication token attribute that is optionally contained in the SA request message. If the agent is not sufficiently authenticated, then the middlebox returns a negative reply of type 'authentication failed' (0x0323) and closes the connection.
State NoauthでSA要求メッセージを受信した後、Middleboxはエージェントが十分に認証されているかどうかを確認します。認証は、SA要求メッセージにオプションで含まれる認証トークン属性に基づいている場合があります。エージェントが十分に認証されていない場合、MiddleBoxは「認証が失敗した」（0x0323）のタイプの否定的な応答を返し、接続を閉じます。
If authentication of the agent is successful, the middlebox checks if the agent is authorized to configure the middlebox. If not, the middlebox returns a negative reply of type 'no authorization' (0x0324) and closes the connection.
エージェントの認証が成功した場合、ミドルボックスはエージェントがミドルボックスの構成を許可されているかどうかをチェックします。そうでない場合、ミドルボックスは「認証なし」（0x0324）のタイプの否定的な返信を返し、接続を閉じます。
If authorization is successful, then the session state changes from NOAUTH to OPEN, and the agent returns an SE reply message that concludes session setup. The middlebox states its capabilities in the capability attribute contained in the SE reply message.
許可が成功した場合、セッション状態はNOAUTHからオープンに変更され、エージェントはセッションのセットアップを終了するSE応答メッセージを返します。ミドルボックスは、SE応答メッセージに含まれる機能属性にその機能を述べています。
The ST request is only applicable if the session is in state NOAUTH or OPEN. If a session is in state CLOSED, then the middlebox sends a negative reply message of type 'request not applicable' (0x0320) to the agent. The state of the session remains unchanged.
STリクエストは、セッションがState NoauthまたはOpenにある場合にのみ適用されます。セッションが状態が閉じられている場合、MiddleBoxはタイプ「リクエストは該当しない」（0x0320）の否定的な返信メッセージをエージェントに送信します。セッションの状態は変わらないままです。
The middlebox always replies to a correct ST request with a positive ST reply. The state of the session changes from OPEN or from NOAUTH to CLOSED. After sending the ST reply, the middlebox closes the connection. Requests received after receiving the ST request and before closing the connection are ignored by the middlebox.
ミドルボックスは、常に正のST応答で正しいSTリクエストに返信します。セッションの状態は、オープンまたはノアースから閉じて変化します。ST応答を送信した後、Middleboxは接続を閉じます。STリクエストを受信した後、接続を閉じる前に受け取ったリクエストは、ミドルボックスによって無視されます。
At any time, the middlebox may terminate an established session and change the session state from OPEN or from NOAUTH to CLOSED. Session termination is indicated to the agent by sending an AST notification.
いつでも、ミドルボックスは確立されたセッションを終了し、セッション状態をオープンまたはノアースからクローズに変更する場合があります。セッション終了は、AST通知を送信することにより、エージェントに示されます。
Before sending the notification, the middlebox ensures that for all requests that have been processed, according replies are returned to the agent, such that the agent exactly knows the state of the middlebox at the time of session termination. After sending the AST notification, the middlebox sends no more messages to the agent, and it closes the connection.
通知を送信する前に、ミドルボックスは、処理されたすべての要求に対して、返信がエージェントに返されることを保証し、エージェントがセッション終了時にミドルボックスの状態を正確に知っているようにします。AST通知を送信した後、ミドルボックスはエージェントにこれ以上メッセージを送信しず、接続を閉じます。
Section 2.2.4 of [RFC3989] describes the session behavior when the network connection is interrupted. The behavior is defined for the middlebox (i.e., the SIMCO server) only and does not consider the behavior of the SIMCO agent in such an event.
[RFC3989]のセクション2.2.4では、ネットワーク接続が中断されたときのセッション動作について説明します。動作は、ミドルボックス（つまり、SIMCOサーバー）のみで定義されており、そのようなイベントでのSIMCOエージェントの動作を考慮していません。
If the SIMCO agent detects an interruption of the underlying network connection, it can terminate the session. The detection of the interrupted network connection can be done by several means, for instance, feedback of the operating system or a connection timeout. The definition of this detection mechanism is out of the scope of this memo.
SIMCOエージェントが基礎となるネットワーク接続の中断を検出した場合、セッションを終了できます。中断されたネットワーク接続の検出は、たとえば、オペレーティングシステムのフィードバックまたは接続タイムアウトなど、いくつかの手段で実行できます。この検出メカニズムの定義は、このメモの範囲外です。
For policy rule control and monitoring, the agent can send the PRR, PER, PEA, PLC, PRS, and PRL requests. The middlebox then sends a single reply message per request message back to the agent. Additionally, the middlebox may send unsolicited ARE notifications at any time.
ポリシールールの制御と監視のために、エージェントはPRR、Per、PEA、PLC、PRS、およびPRLリクエストを送信できます。その後、Middleboxは、要求メッセージごとに1つの返信メッセージをエージェントに送信します。さらに、MiddleBoxはいつでも通知を送信する場合があります。
The transaction semantics of policy rule control messages is explained in detail in [RFC3989], Section 2.3.
ポリシールール制御メッセージのトランザクションセマンティクスについては、[RFC3989]、セクション2.3で詳しく説明しています。
For examples about protocol operation, see Section 4 of [RFC3989].
プロトコル操作に関する例については、[RFC3989]のセクション4を参照してください。
Policy rules are established by successful PRR, PEA, or PER transactions. Each time a policy rule is created, an unused policy rule identifier (PID) is assigned to the new policy rule. For each policy rule identifier, a state machine exists at the middlebox. The state machine is illustrated by the figure below.
ポリシールールは、PRR、PEA、またはトランザクションごとに成功することによって確立されます。ポリシールールが作成されるたびに、未使用のポリシールール識別子（PID）が新しいポリシールールに割り当てられます。各ポリシールール識別子について、マシンがミドルボックスに存在します。状態マシンは、下の図に示されています。
PRR/PRR +---------------+
+----+ +-----------------+ PID UNUSED |<-+
| | | +---------------+ |
| v v PLC(lt=0)/ ^ | |
| +-------------+ PRD | | PER/PER | ARE(lt=0)
| | RESERVED +------------+ | | PLC(lt=0)/
| +-+----+------+ ARE(lt=0) v | PRD
| | | +---------------+ |
+----+ +---------------->| ENABLED +--+
PLC(lt>0)/ PEA/PER +-+-------------+
PLC | ^
+-----------+
lt = lifetime PLC(lt>0)/PLC
Figure 42: Policy rule state machine
図42：ポリシールール状態マシン
The figure illustrates all possible state transitions of a PID and its associated policy. Successful configuration request transactions (PER, PRR, PEA, PLC) are denoted by a descriptor of the request message, a '/' symbol, and a descriptor of the reply message. Failed configuration request transactions are not displayed, because they do not change the PID state. Notification transactions are denoted just by the a notification descriptor. For example, a successful PRR request transaction is denoted by 'PRR/PRR', and an ARE notification is denoted by 'ARE'. For PLC request transactions, the descriptor for the request message is extended by an indication of the value of the lifetime parameter contained in the message.
この図は、PIDのすべての可能な状態遷移とそれに関連するポリシーを示しています。成功した構成要求トランザクション（PER、PRR、PEA、PLC）は、リクエストメッセージの記述子、「/」記号、および返信メッセージの記述子によって示されます。故障した構成要求トランザクションは、PID状態を変更しないため、表示されません。通知トランザクションは、A通知記述子のみによって示されます。たとえば、成功したPRRリクエストトランザクションは「PRR/PRR」で示され、ARE通知は「ARE」で示されます。PLC要求トランザクションの場合、リクエストメッセージの記述子は、メッセージに含まれる生涯パラメーターの値を示すことによって拡張されます。
A successful PRR transaction (PRR/PRR) picks a PID in state UNUSED and changes the state to RESERVED. A successful PER transitions picks a PID in state UNUSED and changes the state to ENABLED. A PID in state RESERVED is changed to ENABLED by a successful PEA transaction. In state RESERVED or UNUSED, a successful PLC transaction with a lifetime parameter greater than zero does not change the PID's state. A successful PLC transaction with a lifetime parameter equal to zero changes the state of a PID from RESERVED to UNUSED or from ENABLED to UNUSED.
成功したPRRトランザクション（PRR/PRR）は、州の未使用のPIDを選択し、州を予約に変更します。成功した1回の移行は、州の未使用のPIDを選択し、状態を有効にします。州の予約されたPIDは、PEAトランザクションが成功することにより有効になるように変更されます。予約または未使用の状態では、生涯パラメーターをゼロよりも大きいPLCトランザクションを成功させても、PIDの状態は変わりません。ゼロに等しい生涯パラメーターで成功したPLCトランザクションは、PIDの状態が予約済みから未使用、有効化から未使用に変化します。
A failed request transaction does not change state at the middlebox.
失敗した要求トランザクションは、ミドルボックスの状態を変更しません。
An ARE notification transaction with the lifetime attribute set to zero has the same effect as a successful PLC transaction with a lifetime parameter equal to zero.
ゼロに設定されたLifetime属性を使用したIS通知トランザクションは、ゼロに等しいライフタイムパラメーターで成功したPLCトランザクションと同じ効果があります。
Processing PRR requests is much simpler on pure firewalls than on middleboxes with NAT functions. Therefore, this section has three sub-sections: The first one describes initial checks that are performed in any case. The second sub-section describes processing of PRR requests on pure firewalls, and the third one describes processing on all devices with NAT functions.
PRRリクエストの処理は、NAT機能を備えたミドルボックスよりも純粋なファイアウォールよりもはるかに簡単です。したがって、このセクションには3つのサブセクションがあります。最初のセクションでは、いずれの場合でも実行される初期チェックについて説明します。2番目のサブセクションでは、純粋なファイアウォールでのPRRリクエストの処理について、3番目のサブセクションでは、NAT機能を備えたすべてのデバイスでの処理について説明します。
When a middlebox receives a PRR request message, it first checks if the authenticated agent is authorized for requesting reservations. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
MiddleboxがPRR要求メッセージを受信すると、最初に認証されたエージェントが予約を要求することが許可されているかどうかを確認します。そうでない場合、「このトランザクションで許可されていないエージェント」（0x0341）のタイプの否定的な返信メッセージを返します。
If the request contains the optional group identifier, then the middlebox checks if the group already exists. If not, the middlebox returns a negative reply message of type 'specified policy rule group does not exist' (0x0344).
リクエストにオプションのグループ識別子が含まれている場合、ミドルボックスはグループが既に存在するかどうかを確認します。そうでない場合、Middleboxは「指定されたポリシールールグループが存在しない」タイプの否定的な返信メッセージを返します（0x0344）。
If the request contains the optional group identifier, then the middlebox checks if the authenticated agent is authorized for adding members to this group. If not, the middlebox returns a negative reply message of type 'not authorized for accessing specified group' (0x0346).
リクエストにオプションのグループ識別子が含まれている場合、Middleboxは、このグループにメンバーを追加するために認証されたエージェントが許可されているかどうかを確認します。そうでない場合、ミドルボックスは、「指定されたグループへのアクセスが許可されていない」タイプの否定的な返信メッセージ（0x0346）を返します。
The middlebox may then check the PRR parameter set. A negative reply of type 'IP version mismatch' (0x034F) is returned if the IPi field does not match the inside IP version of the address at the middlebox. A negative reply of type 'IP version mismatch' (0x034F) is returned if the IPo field does not match the outside IP version of the address at the middlebox. The requested transport protocol type is checked, and a negative reply of type 'protocol type not supported' (0x0354) is returned if it is not supported. The middlebox may return a negative reply of type 'requested address space not available' (0x0347) if the requested address space is completely blocked or not supported by the middlebox in any way; for example, if a UDP port number is requested and all UDP packets are blocked by a middlebox acting as firewall.
ミドルボックスは、PRRパラメーターセットを確認できます。IPIフィールドがMiddleboxのアドレスの内部IPバージョンと一致しない場合、「IPバージョンの不一致」（0x034F）のタイプの否定的な返信が返されます。IPOフィールドがミドルボックスのアドレスの外部IPバージョンと一致しない場合、「IPバージョンの不一致」（0x034F）のタイプの否定的な返信が返されます。要求された輸送プロトコルタイプがチェックされ、サポートされていない場合は「サポートされていない」タイプ「プロトコルタイプ」（0x0354）の否定的な返信が返されます。ミドルボックスは、要求されたアドレススペースが完全にブロックされているか、ミドルボックスによってサポートされていない場合、「要求されたアドレススペース」（0x0347）のタイプの否定的な返信を返す場合があります。たとえば、UDPポート番号が要求され、すべてのUDPパケットがファイアウォールとして機能するミドルボックスによってブロックされている場合。
The latter check at the middlebox is optional. If the check would fail and is not performed at this transaction, then two superfluous transactions will follow. First, the agent will send a request message for a corresponding PER transaction and will receive a negative reply on this. Second, either the agent will send a corresponding PLC request message with lifetime set to zero in order to delete the reservation, or the reservation will time out and the middlebox will send an ARE notification message with the lifetime attribute set to zero. Both transactions can be avoided if the middlebox initially performs this check.
ミドルボックスでの後者のチェックはオプションです。チェックが失敗し、このトランザクションで実行されない場合、2つの余分なトランザクションが続きます。最初に、エージェントは、トランザクションごとに対応するリクエストメッセージを送信し、これについて否定的な返信を受け取ります。第二に、エージェントは、予約を削除するために、Lifetimeセットをゼロに設定した対応するPLC要求メッセージを送信するか、予約がタイムアウトし、MiddleBoxはLifetime属性がゼロに設定されたIS通知メッセージを送信します。ミドルボックスが最初にこのチェックを実行する場合、両方のトランザクションを回避できます。
A reason for avoiding this check might be its complexity. If the check is passed, the same check will have to be performed again for a subsequent corresponding PEA request. If processing two more transactions is considered to consume less resources than performing the check twice, it might be desirable not to perform it during the PRR transaction.
このチェックを避ける理由は、その複雑さかもしれません。小切手が渡された場合、その後の対応するPEAリクエストのために同じチェックを再度実行する必要があります。さらに2つのトランザクションを処理すると、小切手を2回実行するよりも少ないリソースを消費すると考えられている場合、PRRトランザクション中に実行しないことが望ましい場合があります。
After checking the PRR parameter set, the middlebox chooses a lifetime value for the new policy rule to be created, which is greater than or equal to zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox capabilities attribute at session setup. Formally, the lifetime is chosen such that
PRRパラメーターセットをチェックした後、MiddleBoxは作成される新しいポリシールールの生涯値を選択します。これは、要求された値の最小値とミドルボックスで指定された最大寿命の最小値以上で、セッションセットアップ時の機能属性。正式には、そのように寿命が選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup.
ホールド、「LT_Granted」はミドルボックスによって選択された実際の寿命であり、「LT_REQUESTED」はエージェントが要求する寿命であり、「LT_MAXIMUM」はセッションセットアップ時の能力交換中に指定された最大寿命です。
If there are further sessions in state OPEN with authenticated agents authorized to access the policy rule, then to each of these agents a corresponding ARE notification with lifetime set to lt_granted is sent.
Policyルールにアクセスすることを許可された認証エージェントを使用してState Openにさらにセッションがある場合、これらの各エージェントに、LT_Grantedに設定されたLifetimeが送信されることに対応する各エージェントが送信されます。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
選択された寿命がゼロの場合、Middleboxはタイプ「Middlebox構成が失敗した」（0x034a）の否定的な応答をエージェントに送信します。
If the middlebox is configured as a pure firewall, then it accepts the request after the initial checks. It establishes a new policy reserve rule and assigns to it a policy rule identifier in state RESERVED. It generates a positive PRR reply and sets the attributes as specified below. No configuration of the firewall function is required.
ミドルボックスが純粋なファイアウォールとして構成されている場合、最初のチェック後にリクエストを受け入れます。これは、新しいポリシーリザーブルールを確立し、州の予約された州のポリシールール識別子を割り当てます。正のPRR応答を生成し、以下に指定した属性を設定します。ファイアウォール関数の構成は必要ありません。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PRR reply.
新しいポリシールールに選択された識別子は、PRR応答のポリシールール識別子属性に報告されます。
If a group identifier attribute is contained in the PRR request, then the middlebox adds the new policy rule to the members of this group. If the PRR request does not contain a group identifier attribute, then the middlebox creates a new group with the new policy rule as the only member. In any case, the middlebox reports the group of which the new policy rule is a member in the group identifier attribute of the PRR reply.
グループ識別子属性がPRR要求に含まれている場合、MiddleBoxはこのグループのメンバーに新しいポリシールールを追加します。PRR要求にグループ識別子属性が含まれていない場合、MiddleBoxは新しいポリシールールを唯一のメンバーとして新しいグループを作成します。いずれにせよ、Middleboxは、新しいポリシールールがPRR応答のグループ識別子属性のメンバーであるグループを報告します。
The chosen lifetime is reported in the lifetime attribute of the PRR reply.
選択された寿命は、PRR応答の生涯属性で報告されています。
In the address tuple (outside) attribute of the PRR reply, the first parameter field is set to 'protocols only' (0x1). Consequently, the attribute has a length of 32 bits. The IP version parameter field is set according to the IPo parameter field in the PRR parameter set attribute of the PRR request message. The prefix length parameter field is set to 0x00, and the transport protocol parameter field in the address tuple (outside) attribute of the PRR reply is set identically to the transport protocol attribute in the PRR parameter set attribute of the PRR request message. The location parameter field is set to 'outside' (0x02).
PRR応答のアドレスタプル（外側）属性では、最初のパラメーターフィールドは「プロトコルのみ」（0x1）に設定されます。その結果、属性の長さは32ビットです。IPバージョンパラメーターフィールドは、PRR要求メッセージのPRRパラメーターセット属性のIPOパラメーターフィールドに従って設定されます。接頭辞の長さパラメーターフィールドは0x00に設定され、PRR応答のアドレスタプル（外側）属性の輸送プロトコルパラメーターフィールドは、PRR要求メッセージのPRRパラメーターセット属性のTransport Protocol属性と同じように設定されます。位置パラメーターフィールドは「外側」（0x02）に設定されています。
If the middlebox is configured as a Network Address Translator (NAT), then it tries to reserve a NAT binding.
ミドルボックスがネットワークアドレス翻訳者（NAT）として構成されている場合、NATバインディングを予約しようとします。
The middlebox first checks the PRR parameter set further if the NM (NAT mode) parameter matches its configuration. A negative reply of type 'NAT mode not supported' (0x034E) is returned by the middlebox if the configuration is not matched.
NM（NATモード）パラメーターが構成と一致する場合、MiddleBoxは最初にPRRパラメーターをさらにチェックします。構成が一致しない場合、「NATモードがサポートされていない」（0x034E）のタイプの否定的な返信（0x034E）がミドルボックスによって返されます。
The following actions are performed, depending on the middlebox NAT type:
ミドルボックスNATタイプに応じて、次のアクションが実行されます。
- traditional NAT A NAT binding at the outside (A2) with the requested transport protocol, external IP version, port range, and port parity is reserved.
- リクエストされたトランスポートプロトコル、外部IPバージョン、ポートレンジ、およびポートパリティを使用して、外側（A2）での従来のNATバインディングが予約されています。
- twice NAT A NAT binding at the outside (A2) with the requested transport protocol, external IP version, port range, and port parity is reserved. Furthermore, the middlebox reserves an inside (A1) NAT binding with the requested transport protocol, internal IP version, port range, and port parity.
- リクエストされたトランスポートプロトコル、外部IPバージョン、ポートレンジ、およびポートパリティを使用して、外側（A2）で2回NAT A NATバインディングが予約されています。さらに、Middleboxは、要求された輸送プロトコル、内部IPバージョン、ポートレンジ、およびポートパリティとの内部（A1）NATバインディングを留保します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PRR reply.
新しいポリシールールに選択された識別子は、PRR応答のポリシールール識別子属性に報告されます。
After the checks are successfully performed, the middlebox establishes a new policy reserve rule, with the requested PRR parameter set, and assigns to it a policy rule identifier in state RESERVED. It generates a positive PRR reply and sets the attributes as specified below.
小切手が正常に実行された後、Middleboxは要求されたPRRパラメーターセットを使用して、新しいポリシーリザーブルールを確立し、州のポリシールール識別子を割り当てます。正のPRR応答を生成し、以下に指定した属性を設定します。
If a group identifier attribute is contained in the PRR request, then the middlebox adds the new policy rule to the members of this group. If the PRR request does not contain a group identifier attribute, then the middlebox creates a new group with the new policy rule as the only member. In any case, the middlebox reports the group of which the new policy rule is a member in the group identifier attribute of the PRR reply.
グループ識別子属性がPRR要求に含まれている場合、MiddleBoxはこのグループのメンバーに新しいポリシールールを追加します。PRR要求にグループ識別子属性が含まれていない場合、MiddleBoxは新しいポリシールールを唯一のメンバーとして新しいグループを作成します。いずれにせよ、Middleboxは、新しいポリシールールがPRR応答のグループ識別子属性のメンバーであるグループを報告します。
The chosen lifetime is reported in the lifetime attribute of the PRR reply.
選択された寿命は、PRR応答の生涯属性で報告されています。
In the address tuple (outside) attribute of the PRR reply, the first parameter field is set to 'full addresses' (0x0). The location parameter field is set to 'outside' (0x02). The IP version parameter field is set according to the IPo parameter field in the PRR parameter set attribute of the PRR request message. For IPv4 addresses, the prefix length field is set to 0x20 to indicate a full address, and the reserved outside IPv4 address is set in the address field. For IPv6 addresses, the prefix length field is set to 0x80 to indicate a full address, and the reserved outside IPv6 address is set in the address field. The transport protocol parameter field in the address tuple (outside) attribute of the PRR reply is set identically to the transport protocol attribute in the PRR parameter set attribute of the PRR request message. The reserved outside base port number (i.e., the lowest port number of the allocated range) is stored in the port number parameter field, and the allocated port range is stored in the port range parameter field.
PRR応答のアドレスタプル（外側）属性では、最初のパラメーターフィールドは「フルアドレス」（0x0）に設定されています。位置パラメーターフィールドは「外側」（0x02）に設定されています。IPバージョンパラメーターフィールドは、PRR要求メッセージのPRRパラメーターセット属性のIPOパラメーターフィールドに従って設定されます。IPv4アドレスの場合、接頭辞の長さフィールドは0x20に設定され、完全なアドレスを示し、予約されたIPv4アドレスがアドレスフィールドに設定されています。IPv6アドレスの場合、接頭辞の長さフィールドは0x80に設定されて完全なアドレスを示し、予約されたIPv6アドレスがアドレスフィールドに設定されています。PRR応答のアドレスタプル（外側）属性のトランスポートプロトコルパラメーターフィールドは、PRR要求メッセージのPRRパラメーターセット属性のTransport Protocol属性と同じように設定されます。予約済みのベースポート番号（つまり、割り当てられた範囲の最低ポート番号）は、ポート番号パラメーターフィールドに保存され、割り当てられたポート範囲はポート範囲パラメーターフィールドに保存されます。
If the NM (NAT mode) parameter in the PRR parameter set attribute of the PRR request message has the value 'traditional', then the PRR reply message does not contain an address tuple (inside) attribute. If otherwise (it has the value 'twice'), then the PRR reply message contains an address tuple (inside) attribute. In the address tuple (inside) attribute of the PRR reply, the first parameter field is set to 'full addresses' (0x0). The location parameter field is set to 'inside' (0x01). The IP version parameter field is set according to the IPi parameter field in the PRR parameter set attribute of the PRR request message. For IPv4 addresses, the prefix length field is set to 0x20 to indicate a full address, and the reserved inside IPv4 address is set in the address field. For IPv6 addresses, the prefix length field is set to 0x80 to indicate a full address, and the reserved inside IPv6 address is set in the address field. The transport protocol parameter field in the address tuple (inside) attribute of the PRR reply is set identically to the transport protocol attribute in the PRR parameter set attribute of the PRR request message. The reserved inside base port number (i.e., the lowest port number of the allocated range) is stored in the port number parameter field, and the allocated port range is stored in the port range parameter field.
PRRリクエストメッセージのPRRパラメーターセット属性のNM（NATモード）パラメーターに値「従来」がある場合、PRR応答メッセージにはアドレスタプル（内部）属性が含まれません。それ以外の場合（値「2回」）、PRR応答メッセージにはアドレスタプル（内部）属性が含まれています。PRR応答のアドレスタプル（内部）属性では、最初のパラメーターフィールドは「フルアドレス」（0x0）に設定されています。位置パラメーターフィールドは「内部」（0x01）に設定されています。IPバージョンパラメーターフィールドは、PRR要求メッセージのPRRパラメーターセット属性のIPIパラメーターフィールドに従って設定されます。IPv4アドレスの場合、接頭辞の長さフィールドは0x20に設定されて完全なアドレスを示し、内部IPv4アドレスはアドレスフィールドに設定されています。IPv6アドレスの場合、接頭辞の長さフィールドは0x80に設定されて完全なアドレスを示し、IPv6アドレス内の内部はアドレスフィールドに設定されています。PRR応答のアドレスタプル（内部）属性のトランスポートプロトコルパラメーターフィールドは、PRR要求メッセージのPRRパラメーターセット属性のトランスポートプロトコル属性と同じように設定されます。内部のベースポート番号（つまり、割り当てられた範囲の最低ポート番号）は、ポート番号パラメーターフィールドに保存され、割り当てられたポート範囲はポート範囲パラメーターフィールドに保存されます。
Processing PER requests is much simpler on pure firewalls than on middleboxes with NAT functions. Therefore, this section has three sub-sections: The first one describes initial checks that are performed in any case. The second sub-section describes processing of PER requests on pure firewalls, and the third one describes processing on all devices with NAT functions.
リクエストごとの処理は、NAT機能を備えたミドルボックスよりも純粋なファイアウォールよりもはるかに簡単です。したがって、このセクションには3つのサブセクションがあります。最初のセクションでは、いずれの場合でも実行される初期チェックについて説明します。2番目のサブセクションでは、純粋なファイアウォールでのリクエストごとの処理について、3番目のサブセクションでは、NAT機能を備えたすべてのデバイスでの処理について説明します。
When a middlebox receives a PER request message, it first checks if the authenticated agent is authorized for requesting middlebox configurations for enabling communication. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
ミドルボックスが要求ごとのメッセージを受信すると、最初に認証されたエージェントが通信を有効にするためのミドルボックス構成を要求する権限があるかどうかを確認します。そうでない場合、「このトランザクションで許可されていないエージェント」（0x0341）のタイプの否定的な返信メッセージを返します。
If the request contains the optional group identifier, then the middlebox checks if the group already exists. If not, the middlebox returns a negative reply message of type 'specified policy rule group does not exist' (0x0344).
リクエストにオプションのグループ識別子が含まれている場合、ミドルボックスはグループが既に存在するかどうかを確認します。そうでない場合、Middleboxは「指定されたポリシールールグループが存在しない」タイプの否定的な返信メッセージを返します（0x0344）。
If the request contains the optional group identifier, then the middlebox checks if the authenticated agent is authorized for adding members to this group. If not, the middlebox returns a negative reply message of type 'not authorized for accessing specified group' (0x0346).
リクエストにオプションのグループ識別子が含まれている場合、Middleboxは、このグループにメンバーを追加するために認証されたエージェントが許可されているかどうかを確認します。そうでない場合、ミドルボックスは、「指定されたグループへのアクセスが許可されていない」タイプの否定的な返信メッセージ（0x0346）を返します。
Then the middlebox checks the contained address tuple attributes.
次に、Middleboxは、含まれているアドレスタプル属性をチェックします。
If the first one does not have the location parameter field set to 'internal' (0x00), or if the second one does not have the location parameter field set to 'external' (0x03), then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
最初のものに「内部」（0x00）に設定された位置パラメーターフィールドがない場合、または2番目のパラメーターが「外部」に設定された場所パラメーターフィールド（0x03）に設定されていない場合、MiddleBoxはの否定的な返信メッセージを返します。「一貫性のない要求」（0x034b）と入力します。
If the transport protocol parameter field does not have the same value in both address tuple attributes, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
Transport Protocolパラメーターフィールドが両方のアドレスタプル属性に同じ値を持っていない場合、MiddleBoxはタイプ「一貫性のない要求」（0x034b）の否定的な応答メッセージを返します。
If both address tuple attributes contain a port range parameter field, if both port range parameter fields have values not equal to 0xFFFF, and if the values of both port range parameter fields are different, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
両方のアドレスタプル属性にポート範囲パラメーターフィールドが含まれている場合、両方のポート範囲パラメーターフィールドが0xFFFFに等しくない場合、両方のポート範囲パラメーターフィールドの値が異なる場合、ミドルボックスはタイプの否定的な応答メッセージを返します。リクエスト '（0x034b）。
Then the agent checks if wildcarding is requested and if the requested wildcarding is supported by the middlebox. Wildcarding support may be different for internal address tuples and external address tuples. The following parameter fields of the address tuple attribute can indicate wildcarding:
次に、エージェントは、ワイルドカードが要求されているかどうか、要求されたワイルドカードがミドルボックスによってサポートされているかどうかを確認します。ワイルドカードのサポートは、内部アドレスのタプルや外部アドレスのタプルで異なる場合があります。アドレスタプル属性の次のパラメーターフィールドは、ワイルドカードを示すことができます。
- the first parameter field If it is set to 'protocols only' (0x1), then IP addresses and port numbers are completely wildcarded.
- 最初のパラメーターフィールドは、「プロトコルのみ」（0x1）に設定されている場合、IPアドレスとポート番号は完全にワイルドカードされています。
- the transport protocol field If it is set to 0x00, then the transport protocol is completely wildcarded. Please note that a completely wildcarded transport protocol might still support only a limited set of transport protocols according to the capabilities of the middlebox. For example, a typical NAT implementation may apply transport wildcarding to UDP and TCP transport only. Wildcarding the transport protocol implies wildcarding of port numbers. If this field is set to 0x00, then the values of the port number field and the port range field are irrelevant.
- トランスポートプロトコルフィールドが0x00に設定されている場合、トランスポートプロトコルは完全にワイルドカードされています。完全にワイルドカードされた輸送プロトコルは、ミドルボックスの機能に従って限られた輸送プロトコルのみをサポートする可能性があることに注意してください。たとえば、典型的なNAT実装は、UDPおよびTCP輸送のみに輸送のワイルドカードを適用する場合があります。ワイルドカード輸送プロトコルは、ポート番号のワイルドカードを意味します。このフィールドが0x00に設定されている場合、ポート番号フィールドとポートレンジフィールドの値は無関係です。
- the prefix length field If the IP version number field indicates IPv4 and the value of this field is less than 0x20, then IP addresses are wildcarding according to this prefix length. If the IP version number field indicates IPv6 and the value of this field is less than 0x80, then IP addresses are wildcarding according to this prefix length. If the first parameter field is set to 'protocols only' (0x1), then the value of the prefix length field is irrelevant.
- IPバージョン番号フィールドがIPv4を示し、このフィールドの値が0x20未満である場合、IPアドレスがこのプレフィックスの長さに応じてワイルドカードになります。IPバージョン番号フィールドがIPv6を示し、このフィールドの値が0x80未満の場合、IPアドレスはこのプレフィックスの長さに従ってワイルドカードです。最初のパラメーターフィールドが「プロトコルのみ」（0x1）に設定されている場合、プレフィックス長フィールドの値は無関係です。
- the port number field If it is set to zero, then port numbers are completely wildcarded. In this case, the value of the port range field is irrelevant.
- ポート番号フィールドがゼロに設定されている場合、ポート番号は完全にワイルドカードされています。この場合、ポートレンジフィールドの値は無関係です。
If any of these kinds of wildcarding is used, and if this is in conflict with wildcarding support for internal or external addresses of the middlebox, then the middlebox returns a negative reply message of type 'requested wildcarding not supported' (0x034C).
これらの種類のワイルドカードのいずれかが使用され、これがミドルボックスの内部アドレスまたは外部アドレスのワイルドカードサポートと競合している場合、ミドルボックスは「サポートされていない」（0x034c）タイプの否定的な返信メッセージを返します。
Please note that the port range field cannot be used for wildcarding. If it is set to a value greater than one, then middlebox configuration is requested for all port numbers in the interval starting with the specified port number and containing as many consecutive port numbers as specified by the parameter.
ポートレンジフィールドはワイルドカードに使用できないことに注意してください。1より大きい値に設定されている場合、指定されたポート番号から始まり、パラメーターで指定されているように多くの連続したポート番号を含む間隔のすべてのポート番号に対してMiddleBox構成が要求されます。
If the direction parameter field in the PER parameter set attribute has the value 'bi-directional', then only transport protocol wildcarding is allowed. If any other kind of wildcarding is specified in one or both of the IP address tuple attributes, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
パラメーターセット属性の方向パラメーターフィールドに値「双方向」がある場合、輸送プロトコルのワイルドカードのみが許可されます。IPアドレスタプル属性の1つまたは両方で他の種類のワイルドカードが指定されている場合、MiddleBoxはタイプ「一貫性のない要求」（0x034b）の否定的な返信メッセージを返します。
If the PER request conflicts with any policy disable rule (see Section 8.8.1), then the middlebox returns a negative reply message of type 'conflict with existing rule' (0x0350).
要求ごとのリクエストが任意のポリシーを無効にするルール（セクション8.8.1を参照）と競合する場合、MiddleBoxは「既存のルールとの競合」（0x0350）のタイプの否定的な返信メッセージを返します。
After checking the address tuple attributes, the middlebox chooses a lifetime value for the new policy rule to be created, which is greater than or equal to zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox capabilities attribute at session setup. Formally, the lifetime is chosen such that
アドレスタプル属性をチェックした後、MiddleBoxは作成される新しいポリシールールの生涯値を選択します。セッションセットアップ時の機能属性。正式には、そのように寿命が選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup.
ホールド、「LT_Granted」はミドルボックスによって選択された実際の寿命であり、「LT_REQUESTED」はエージェントが要求する寿命であり、「LT_MAXIMUM」はセッションセットアップ時の能力交換中に指定された最大寿命です。
If there are further sessions in state OPEN with authenticated agents authorized to access the policy rule, then to each of these agents a corresponding ARE notification with lifetime set to lt_granted is sent.
Policyルールにアクセスすることを許可された認証エージェントを使用してState Openにさらにセッションがある場合、これらの各エージェントに、LT_Grantedに設定されたLifetimeが送信されることに対応する各エージェントが送信されます。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
選択された寿命がゼロの場合、Middleboxはタイプ「Middlebox構成が失敗した」（0x034a）の否定的な応答をエージェントに送信します。
If the middlebox is acting as a pure firewall, then it tries to configure the requested pinhole. The firewall configuration ignores the port parity parameter field in the PER parameter set attribute, but it considers the direction parameter field in this attribute. The pinhole is configured such that communication between the specified internal and external address tuples is enabled in the specified direction and covering the specified wildcarding. If the configuration fails (for example, because the pinhole would conflict with high-level firewall policies), then the middlebox returns a negative reply message of type 'middlebox configuration failed' (0x034A).
ミドルボックスが純粋なファイアウォールとして機能している場合、要求されたピンホールを構成しようとします。ファイアウォールの構成は、パラメーターセット属性ごとにポートパリティパラメーターフィールドを無視しますが、この属性の方向パラメーターフィールドを考慮します。ピンホールは、指定された内部アドレスと外部アドレスのタプル間の通信が指定された方向で有効になり、指定されたワイルドカードをカバーするように構成されています。構成が失敗した場合（たとえば、ピンホールが高レベルのファイアウォールポリシーと競合するため）、ミドルボックスは「ミドルボックス構成が失敗した」タイプの否定的な応答メッセージを返します（0x034a）。
If the configuration was successful, the middlebox establishes a new policy enable rule and assigns to it a policy rule identifier in state ENABLED. It generates a positive PER reply and sets the attributes as specified below.
構成が成功した場合、Middleboxは新しいポリシーを有効にするルールを確立し、州の有効化のポリシールール識別子を割り当てます。返信ごとに正の生成を生成し、以下に指定した属性を設定します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
新しいポリシールールに選択された識別子は、返信ごとのポリシールール識別子属性に報告されます。
If a group identifier attribute is contained in the PER request, then the middlebox adds the new policy rule to the members of this group. If the PRR request does not contain a group identifier attribute, then the middlebox creates a new group with the new policy rule as the only member. In any case, the middlebox reports the group of which the new policy rule is a member in the group identifier attribute of the PER reply.
グループ識別子属性がPERリクエストに含まれている場合、MiddleBoxはこのグループのメンバーに新しいポリシールールを追加します。PRR要求にグループ識別子属性が含まれていない場合、MiddleBoxは新しいポリシールールを唯一のメンバーとして新しいグループを作成します。いずれにせよ、Middleboxは、新しいポリシールールが回答ごとのグループ識別子属性のメンバーであるグループを報告します。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
選択された寿命は、返信ごとの生涯属性で報告されています。
The address tuple (internal) attribute of the PER request is reported as address tuple (outside) attribute of the PER reply. The address tuple (external) attribute of the PER request is reported as address tuple (inside) attribute of the PER reply.
リクエストごとのアドレスタプル（内部）属性は、返信ごとのアドレスタプル（外側）属性として報告されます。要求ごとのアドレスタプル（外部）属性は、返信ごとのアドレスタプル（内部）属性として報告されます。
If the middlebox is configured as a NAT, then it tries to configure the requested NAT binding. The actions taken by the NAT are quite similar to the actions of the Policy Reserve Rule (PRR) request, but in the PER request a NAT binding is enabled.
ミドルボックスがNATとして構成されている場合、要求されたNATバインディングを構成しようとします。NATがとるアクションは、ポリシーリザーブルール（PRR）リクエストのアクションと非常に似ていますが、要求ごとにNATバインディングが有効になります。
The following actions are performed, depending on the middlebox NAT type:
ミドルボックスNATタイプに応じて、次のアクションが実行されます。
- traditional NAT A NAT binding is established between the internal and external address tuple with the requested transport protocol, port range, direction, and port parity. The outside address tuple is created.
- 従来のNAT A NATバインディングは、要求された輸送プロトコル、ポートレンジ、方向、および港湾パリティを使用して、内部および外部アドレスタプルの間に確立されています。外側のアドレスタプルが作成されます。
- twice NAT A NAT binding is established between the internal and external address tuple with the requested transport protocol, port range, and port parity. But two address tuples are created: an outside address tuple and an inside address tuple.
- 2回のNAT A NATバインディングは、要求された輸送プロトコル、ポートレンジ、およびポートパリティを使用して、内部および外部アドレスのタプルの間に確立されます。ただし、2つのアドレスタプルが作成されます。外部アドレスタプルと内側のアドレスタプル。
Should the configuration fail in either NAT case, a negative reply 'middlebox configuration failed' (0x034A) is returned.
いずれかのNATケースで構成が失敗した場合、否定的な応答「Middlebox構成が失敗した」（0x034a）が返されます。
If the configuration was successful, the middlebox establishes a new policy enable rule and assigns to it a policy rule identifier in state ENABLED. It generates a positive PER reply and sets the attributes as specified below.
構成が成功した場合、Middleboxは新しいポリシーを有効にするルールを確立し、州の有効化のポリシールール識別子を割り当てます。返信ごとに正の生成を生成し、以下に指定した属性を設定します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
新しいポリシールールに選択された識別子は、返信ごとのポリシールール識別子属性に報告されます。
If a group identifier attribute is contained in the PER request, then the middlebox adds the new policy rule to the members of this group. If the PRR request does not contain a group identifier attribute, then the middlebox creates a new group with the new policy rule as the only member. In any case, the middlebox reports the group of which the new policy rule is a member in the group identifier attribute of the PER reply.
グループ識別子属性がPERリクエストに含まれている場合、MiddleBoxはこのグループのメンバーに新しいポリシールールを追加します。PRR要求にグループ識別子属性が含まれていない場合、MiddleBoxは新しいポリシールールを唯一のメンバーとして新しいグループを作成します。いずれにせよ、Middleboxは、新しいポリシールールが回答ごとのグループ識別子属性のメンバーであるグループを報告します。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
選択された寿命は、返信ごとの生涯属性で報告されています。
In the address tuple (outside) attribute of the PER reply, the first parameter field is set to 'full addresses' (0x0). The location parameter field is set to 'outside' (0x02). The IP version parameter field is set according to the IP version parameter field in the PER parameter set attribute of the PER request message. For IPv4 addresses, the prefix length field is set to 0x20 to indicate a full address, and the reserved outside IPv4 address is set in the address field. For IPv6 addresses, the prefix length field is set to 0x80 to indicate a full address, and the reserved outside IPv6 address is set in the address field. The transport protocol parameter field in the address tuple (outside) attribute of the PER reply is set identically to the transport protocol attribute in the PER parameter set attribute of the PER request message. The reserved outside base port number (i.e., the lowest port number of the allocated range) is stored in the port number parameter field, and the allocated port range is stored in the port range parameter field.
アドレスタプル（外側）属性ごとの属性では、最初のパラメーターフィールドは「フルアドレス」（0x0）に設定されています。位置パラメーターフィールドは「外側」（0x02）に設定されています。IPバージョンパラメーターフィールドは、PERパラメーターセット属性のIPバージョンパラメーターフィールドに従って設定されています。IPv4アドレスの場合、接頭辞の長さフィールドは0x20に設定され、完全なアドレスを示し、予約されたIPv4アドレスがアドレスフィールドに設定されています。IPv6アドレスの場合、接頭辞の長さフィールドは0x80に設定されて完全なアドレスを示し、予約されたIPv6アドレスがアドレスフィールドに設定されています。アドレスタプル（外側）属性のトランスポートプロトコルパラメーターフィールドは、PERリクエストメッセージのパラメーターセット属性のパラメーターセット属性のトランスポートプロトコル属性と同じように設定されます。予約済みのベースポート番号（つまり、割り当てられた範囲の最低ポート番号）は、ポート番号パラメーターフィールドに保存され、割り当てられたポート範囲はポート範囲パラメーターフィールドに保存されます。
The address tuple (inside) is only returned if the middlebox is a twice NAT; otherwise, it is omitted. In the address tuple (inside) attribute of the PER reply, the first parameter field is set to 'full addresses' (0x0). The location parameter field is set to 'inside' (0x01). The IP version parameter field is set according to the IP version parameter field in the PER parameter set attribute of the PER request message. For IPv4 addresses, the prefix length field is set to 0x20 to indicate a full address, and the reserved inside IPv4 address is set in the address field. For IPv6 addresses, the prefix length field is set to 0x80 to indicate a full address, and the reserved inside IPv6 address is set in the address field. The transport protocol parameter field in the address tuple (inside) attribute of the PER reply is set identically to the transport protocol attribute in the PER parameter set attribute of the PER request message. The reserved inside base port number (i.e., the lowest port number of the allocated range) is stored in the port number parameter field, and the allocated port range is stored in the port range parameter field.
アドレスタプル（内側）は、ミドルボックスが2回NATである場合にのみ返されます。それ以外の場合は、省略されています。アドレスタプル（内部）属性ごとの属性では、最初のパラメーターフィールドは「フルアドレス」（0x0）に設定されています。位置パラメーターフィールドは「内部」（0x01）に設定されています。IPバージョンパラメーターフィールドは、PERパラメーターセット属性のIPバージョンパラメーターフィールドに従って設定されています。IPv4アドレスの場合、接頭辞の長さフィールドは0x20に設定されて完全なアドレスを示し、内部IPv4アドレスはアドレスフィールドに設定されています。IPv6アドレスの場合、接頭辞の長さフィールドは0x80に設定されて完全なアドレスを示し、IPv6アドレス内の内部はアドレスフィールドに設定されています。アドレスタプル（内部）属性のトランスポートプロトコルパラメーターフィールドは、PERリクエストメッセージのパラメーターセット属性のパラメーターセット属性のトランスポートプロトコル属性と同じように設定されます。内部のベースポート番号（つまり、割り当てられた範囲の最低ポート番号）は、ポート番号パラメーターフィールドに保存され、割り当てられたポート範囲はポート範囲パラメーターフィールドに保存されます。
Middleboxes that are combinations of firewalls and NATs are configured in such a way that first the NAT bindings are configured and afterwards the firewall pinholes. This sequence is needed since the firewall rules must be configured according to the outside address tuples and for twice NATs the inside address tuples as well. This aspect of middlebox operation may be irrelevant to SIMCO, since some NATs already do firewall configuration on their own.
ファイアウォールとNATの組み合わせであるミドルボックスは、最初にNATバインディングが構成され、その後ファイアウォールのピンホールを構成するように構成されます。このシーケンスは、ファイアウォールルールを外部アドレスタプルに従って構成する必要があり、2回のNATの場合も内部アドレスタプルにも従って構成する必要があるためです。一部のNATはすでに独自にファイアウォール構成を行っているため、Middlebox操作のこの側面はSIMCOとは関係ありません。
Processing PEA requests is much simpler on pure firewalls than on middleboxes with NAT functions. Therefore, this section has three sub-sections: The first one describes initial checks that are performed in any case. The second sub-section describes processing of PEA requests on pure firewalls, and the third one describes processing on all devices with NAT functions.
PEAのリクエストの処理は、NAT機能を備えたミドルボックスよりも純粋なファイアウォールよりもはるかに簡単です。したがって、このセクションには3つのサブセクションがあります。最初のセクションでは、いずれの場合でも実行される初期チェックについて説明します。2番目のサブセクションでは、純粋なファイアウォールでのPEAリクエストの処理について、3番目のサブセクションでは、NAT機能を備えたすべてのデバイスでの処理について説明します。
When a middlebox receives a PEA request message, it first checks if the authenticated agent is authorized for requesting middlebox configurations for enabling communication. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
MiddleboxがPEAリクエストメッセージを受信すると、最初に認証されたエージェントが通信を有効にするためのMiddlebox構成を要求する権限があるかどうかを確認します。そうでない場合、「このトランザクションで許可されていないエージェント」（0x0341）のタイプの否定的な返信メッセージを返します。
Then the middlebox checks the policy rule identifier attribute contained in the PEA message. If no policy rule with this identifier exists, then the middlebox returns a negative reply message of type 'specified policy rule does not exist' (0x0343). If there exists a policy with this identifier and if it is in a state other than RESERVED, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
次に、Middleboxは、PEAメッセージに含まれるポリシールール識別子属性をチェックします。この識別子にポリシールールが存在しない場合、ミドルボックスは「指定されたポリシールールが存在しない」タイプの否定的な応答メッセージを返します（0x0343）。この識別子にポリシーが存在し、それが予約済み以外の状態にある場合、ミドルボックスはタイプ「一貫性のない要求」（0x034b）の否定的な返信メッセージを返します。
If a policy rule with this identifier exists, but the authenticated agent is not authorized for terminating this policy reserve rule, then the middlebox returns a negative reply message of type 'agent not authorized for accessing this policy' (0x0345).
この識別子のポリシールールが存在するが、認証されたエージェントがこのポリシーリザーブルールを終了することを許可されていない場合、MiddleBoxは、「このポリシーへのアクセスが許可されていないエージェント」（0x0345）のタイプの否定的な返信メッセージを返します。
Then the middlebox checks the contained address tuple attributes.
次に、Middleboxは、含まれているアドレスタプル属性をチェックします。
If the first one does not have the location parameter field set to 'internal' (0x00) or if the second one does not have the location parameter field set to 'external' (0x03), then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
最初のものに「内部」（0x00）に設定された位置パラメーターフィールドがない場合、または2番目のパラメーターに「外部」に設定された場所パラメーターフィールドがない場合（0x03）、ミドルボックスはタイプの否定的な応答メッセージを返します「一貫性のないリクエスト」（0x034b）。
If the transport protocol parameter field does not have the same value in both address tuple attributes, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
Transport Protocolパラメーターフィールドが両方のアドレスタプル属性に同じ値を持っていない場合、MiddleBoxはタイプ「一貫性のない要求」（0x034b）の否定的な応答メッセージを返します。
If both address tuple attributes contain a port range parameter field, if both port range parameter fields have values not equal to 0xFFFF, and if the values of both port range parameter fields are different, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
両方のアドレスタプル属性にポート範囲パラメーターフィールドが含まれている場合、両方のポート範囲パラメーターフィールドが0xFFFFに等しくない場合、両方のポート範囲パラメーターフィールドの値が異なる場合、ミドルボックスはタイプの否定的な応答メッセージを返します。リクエスト '（0x034b）。
Then the agent checks if wildcarding is requested and if the requested wildcarding is supported by the middlebox. Wildcarding support may be different for internal address tuples and external address tuples. The following parameter fields of the address tuple attribute can indicate wildcarding:
次に、エージェントは、ワイルドカードが要求されているかどうか、要求されたワイルドカードがミドルボックスによってサポートされているかどうかを確認します。ワイルドカードのサポートは、内部アドレスのタプルや外部アドレスのタプルで異なる場合があります。アドレスタプル属性の次のパラメーターフィールドは、ワイルドカードを示すことができます。
- the first parameter field If it is set to 'protocols only' (0x1), then IP addresses and port numbers are completely wildcarded.
- 最初のパラメーターフィールドは、「プロトコルのみ」（0x1）に設定されている場合、IPアドレスとポート番号は完全にワイルドカードされています。
- the transport protocol field If it is set to 0x00, then IP the transport protocol is completely wildcarded. Please note that a completely wildcarded transport protocol might still support only a limited set of transport protocols according to the capabilities of the middlebox. For example, a typical NAT implementation may apply transport wildcarding to UDP and TCP transport only.
- トランスポートプロトコルフィールドが0x00に設定されている場合、IPトランスポートプロトコルは完全にワイルドカードされています。完全にワイルドカードされた輸送プロトコルは、ミドルボックスの機能に従って限られた輸送プロトコルのみをサポートする可能性があることに注意してください。たとえば、典型的なNAT実装は、UDPおよびTCP輸送のみに輸送のワイルドカードを適用する場合があります。
- the prefix length field If the IP version number field indicates IPv4 and the value of this field is less than 0x20, then IP addresses are wildcarding according to this prefix length. If the IP version number field indicates IPv6 and the value of this field is less than 0x80, then IP addresses are wildcarding according to this prefix length. If the first parameter field is set to 'protocols only' (0x1), then the value of the prefix length field is irrelevant.
- IPバージョン番号フィールドがIPv4を示し、このフィールドの値が0x20未満である場合、IPアドレスがこのプレフィックスの長さに応じてワイルドカードになります。IPバージョン番号フィールドがIPv6を示し、このフィールドの値が0x80未満の場合、IPアドレスはこのプレフィックスの長さに従ってワイルドカードです。最初のパラメーターフィールドが「プロトコルのみ」（0x1）に設定されている場合、プレフィックス長フィールドの値は無関係です。
- the port number field If it is set to zero, then port numbers are completely wildcarded.
- ポート番号フィールドがゼロに設定されている場合、ポート番号は完全にワイルドカードされています。
- the port range field If it is set to a value greater than one, then port numbers are wildcarded within an interval starting with the specified port number and containing as many consecutive port numbers as specified by the parameter.
- ポートレンジフィールドが1より大きい値に設定されている場合、ポート番号は指定されたポート番号から始まり、パラメーターで指定されているように多くの連続したポート番号を含む間隔内でワイルドカードされます。
If any of these kinds of wildcarding is used, and if this is in conflict with wildcarding support for internal or external addresses of the middlebox, then the middlebox returns a negative reply message of type 'requested wildcarding not supported' (0x034C).
これらの種類のワイルドカードのいずれかが使用され、これがミドルボックスの内部アドレスまたは外部アドレスのワイルドカードサポートと競合している場合、ミドルボックスは「サポートされていない」（0x034c）タイプの否定的な返信メッセージを返します。
If the PEA request conflicts with any policy disable rule (see Section 8.8.1), then the middlebox returns a negative reply message of type 'conflict with existing rule' (0x0350).
PEA要求がポリシーを無効にするルールと競合する場合（セクション8.8.1を参照）、MiddleBoxは「既存のルールとの競合」のタイプの否定的な返信メッセージを返します（0x0350）。
After checking the address tuple attributes, the middlebox chooses a lifetime value for the new policy enable rule to be created, which is greater than or equal to zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox capabilities attribute at session setup. Formally, the lifetime is chosen such that
アドレスタプル属性をチェックした後、MiddleBoxは、要求された値の最小値と最小寿命の最小値と等または等しい、新しいポリシーを有効にするルールを作成するために生涯値を選択します。セッションセットアップ時のMiddlebox機能属性。正式には、そのように寿命が選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup.
ホールド、「LT_Granted」はミドルボックスによって選択された実際の寿命であり、「LT_REQUESTED」はエージェントが要求する寿命であり、「LT_MAXIMUM」はセッションセットアップ時の能力交換中に指定された最大寿命です。
If there are further sessions in state OPEN with authenticated agents authorized to access the policy rule, then to each of these agents a corresponding ARE notification with lifetime set to lt_granted is sent.
Policyルールにアクセスすることを許可された認証エージェントを使用してState Openにさらにセッションがある場合、これらの各エージェントに、LT_Grantedに設定されたLifetimeが送信されることに対応する各エージェントが送信されます。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
選択された寿命がゼロの場合、Middleboxはタイプ「Middlebox構成が失敗した」（0x034a）の否定的な応答をエージェントに送信します。
If the middlebox is configured as a pure firewall, then it tries to configure the requested pinhole. The firewall configuration ignores the port parity parameter field in the PER parameter set attribute, but it considers the direction parameter field in this attribute. The pinhole is configured such that communication between the specified internal and external address tuples is enabled in the specified direction and covering the specified wildcarding. If the configuration fails, then the middlebox returns a negative reply message of type 'middlebox configuration failed' (0x034A).
ミドルボックスが純粋なファイアウォールとして構成されている場合、要求されたピンホールを構成しようとします。ファイアウォールの構成は、パラメーターセット属性ごとにポートパリティパラメーターフィールドを無視しますが、この属性の方向パラメーターフィールドを考慮します。ピンホールは、指定された内部アドレスと外部アドレスのタプル間の通信が指定された方向で有効になり、指定されたワイルドカードをカバーするように構成されています。構成が失敗した場合、MiddleBoxは「Middlebox構成が失敗した」タイプの否定的な応答メッセージ（0x034a）を返します。
If the configuration was successful, the middlebox replaces the policy reserve rule referenced by the policy rule identifier attribute in the PEA request message with a new policy enable rule. The policy enable rule re-uses the policy rule identifier of the replaced policy reserve rule. The state of the policy rule identifier changes from RESERVED to ENABLED. The policy reserve rule is a member of the same group as the replaced policy reserve rule was.
構成が成功した場合、ミドルボックスは、PEAリクエストメッセージのポリシールール識別子属性が参照されるポリシーリザーブルールを、新しいポリシーを有効にするルールに置き換えます。ポリシーを有効にするルールは、置き換えられたポリシーリザーブルールのポリシールール識別子を再利用します。ポリシールール識別子の状態は、予約から有効になります。ポリシーリザーブルールは、交換されたポリシーリザーブルールと同じグループのメンバーです。
Then the middlebox generates a positive PER reply and sets the attributes as specified below.
次に、ミドルボックスは応答ごとに正の生成を生成し、以下に指定した属性を設定します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
新しいポリシールールに選択された識別子は、返信ごとのポリシールール識別子属性に報告されます。
The group identifier is reported in the group identifier attribute of the PER reply.
グループ識別子は、返信ごとのグループ識別子属性に報告されます。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
選択された寿命は、返信ごとの生涯属性で報告されています。
The address tuple (internal) attribute of the PER request is reported as the address tuple (outside) attribute of the PER reply. The address tuple (external) attribute of the PER request is reported as the address tuple (inside) attribute of the PER reply.
要求ごとのアドレスタプル（内部）属性は、返信ごとのアドレスタプル（外側）属性として報告されます。要求ごとのアドレスタプル（外部）属性は、返信ごとのアドレスタプル（内部）属性として報告されます。
If the middlebox is configured as a NAT, then it tries to configure the requested NAT binding, i.e., enabling the already reserved binding. The already reserved NAT binding from the PRR request is now enabled in the middlebox.
ミドルボックスがNATとして構成されている場合、要求されたNATバインディング、つまりすでに予約されたバインディングを可能にするために構成しようとします。PRRリクエストから既に予約されているNATバインディングは、ミドルボックスで有効になっています。
If the enable configuration was successful, the middlebox replaces the policy reserve rule referenced by the policy rule identifier attribute in the PEA request message with a new policy enable rule. The policy enable rule re-uses the policy rule identifier of the replaced policy reserve rule. The state of the policy rule identifier changes from RESERVED to ENABLED. The policy reserve rule is a member of the same group as the replaced policy reserve rule was.
有効な構成が成功した場合、MiddleBoxは、PEAリクエストメッセージのポリシールール識別子属性が参照されるポリシーリザーブルールを新しいポリシー有効化ルールに置き換えます。ポリシーを有効にするルールは、置き換えられたポリシーリザーブルールのポリシールール識別子を再利用します。ポリシールール識別子の状態は、予約から有効になります。ポリシーリザーブルールは、交換されたポリシーリザーブルールと同じグループのメンバーです。
Then the middlebox generates a positive PER reply and sets the attributes as specified below.
次に、ミドルボックスは応答ごとに正の生成を生成し、以下に指定した属性を設定します。
The reserved outside address tuple is reported as the address tuple (outside) attribute of the PER reply. The reserved inside address tuple is reported as the address tuple (inside) attribute of the PER reply. Both reserved outside and inside address tuples are taken from the reserve policy rule generated during the PRR transaction.
予約済みの外部アドレスタプルは、返信ごとのアドレスタプル（外側）属性として報告されます。予約された内部アドレスタプルは、返信ごとのアドレスタプル（内部）属性として報告されます。外部および内部のアドレスの両方のタプルは、PRRトランザクション中に生成された予備政策規則から取得されます。
When a middlebox receives a PLC request message, it first checks if the authenticated agent is authorized for requesting policy rule lifetime changes. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
MiddleboxがPLC要求メッセージを受信すると、最初に認証されたエージェントがポリシールールのライフタイムの変更を要求する許可されているかどうかを確認します。そうでない場合、「このトランザクションで許可されていないエージェント」（0x0341）のタイプの否定的な返信メッセージを返します。
Then the middlebox checks the policy rule identifier attribute contained in the PLC message. If no policy rule with this identifier exists, then the middlebox returns a negative reply message of type 'specified policy rule does not exist' (0x0343).
次に、MiddleBoxはPLCメッセージに含まれるポリシールール識別子属性をチェックします。この識別子にポリシールールが存在しない場合、ミドルボックスは「指定されたポリシールールが存在しない」タイプの否定的な応答メッセージを返します（0x0343）。
If a policy rule with this identifier exists, but the authenticated agent is not authorized for changing the lifetime of this policy rule, then the middlebox returns a negative reply message of type 'agent not authorized for accessing this policy' (0x0345).
この識別子のポリシールールが存在するが、認証されたエージェントがこのポリシールールの寿命を変更することを許可されていない場合、MiddleBoxは、このポリシーへのアクセスを許可されていないタイプエージェント」（0x0345）の否定的な返信メッセージを返します。
Then the middlebox chooses a lifetime value for the new policy rule, which is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox capabilities attribute at session setup. Formally, the lifetime is chosen such that
次に、ミドルボックスは、セッションセットアップ時にミドルボックス機能属性によって指定された要求値の最小値と最小寿命よりも大きく、ゼロよりも大きく、等しい新しいポリシールールの生涯値を選択します。正式には、そのように寿命が選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup. This procedure implies that the chosen lifetime is zero if the requested lifetime is zero.
ホールド、「LT_Granted」はミドルボックスによって選択された実際の寿命であり、「LT_REQUESTED」はエージェントが要求する寿命であり、「LT_MAXIMUM」はセッションセットアップ時の能力交換中に指定された最大寿命です。この手順は、要求された寿命がゼロの場合、選択された寿命がゼロであることを意味します。
If the chosen lifetime is greater than zero, the middlebox changes the lifetime of the policy rule to the chosen value and generates a PLC reply message. The chosen lifetime is reported in the lifetime attribute of the message.
選択した寿命がゼロより大きい場合、ミドルボックスはポリシールールの寿命を選択した値に変更し、PLC返信メッセージを生成します。選択された寿命は、メッセージの生涯属性に報告されています。
If otherwise (the chosen lifetime is zero), then the middlebox terminates the policy rule and changes the PID state from ENABLED or RESERVED, respectively, to UNUSED.
それ以外の場合（選択した寿命がゼロ）、ミドルボックスはポリシールールを終了し、PID状態をそれぞれ有効または予約していないことから未使用に変更します。
The middlebox generates a PRD reply message and sends it to the requesting agent. If there are further sessions in state OPEN with authenticated agents authorized to access the policy rule, then to each of these agents a corresponding ARE notification with lifetime set to zero is sent.
ミドルボックスはPRD応答メッセージを生成し、要求エージェントに送信します。Policyルールにアクセスすることを許可された認証エージェントを使用してState Openにさらにセッションがある場合、これらのエージェントのそれぞれに、対応するゼロにセットされたLifetimeが送信される通知が送信されます。
When a middlebox receives a PRS request message, it first checks if the authenticated agent is authorized for receiving policy status information. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
MiddleboxがPRS要求メッセージを受信すると、最初に認証されたエージェントがポリシーステータス情報の受信が許可されているかどうかを確認します。そうでない場合、「このトランザクションで許可されていないエージェント」（0x0341）のタイプの否定的な返信メッセージを返します。
Then the middlebox checks the policy rule identifier attribute contained in the PRS message. If no policy rule with this identifier exists in state RESERVED or ENABLED, then the middlebox returns a negative reply message of type 'specified policy rule does not exist' (0x0343).
次に、MiddleboxはPRSメッセージに含まれるポリシールール識別子属性をチェックします。この識別子が予約または有効になっていることにこの識別子に存在しない場合、ミドルボックスは「指定されたポリシールールが存在しない」タイプの否定的な返信メッセージを返します（0x0343）。
If a policy rule with this identifier exists, but the authenticated agent is not authorized to receive status information for this policy rule, then the middlebox returns a negative reply message of type 'agent not authorized for accessing this policy' (0x0345).
この識別子のポリシールールが存在するが、認証されたエージェントがこのポリシールールのステータス情報を受信することを許可されていない場合、MiddleBoxは、このポリシーへのアクセスが許可されていないエージェント」（0x0345）のタイプの否定的な返信メッセージを返します。
If the checks described above are passed, the middlebox accepts the requests and generates a reply. If the policy rule for which status information is requested is in state RESERVED, then a PRS reply is generated and sent to the agent. If otherwise (the policy rule is in state ENABLED), then a PES reply is generated and sent to the agent. For policy disable rules, a PDS reply is generated and sent to the agent.
上記のチェックが渡された場合、MiddleBoxはリクエストを受け入れ、返信を生成します。ステータス情報が要求されるポリシールールが州の予約されている場合、PRS応答が生成され、エージェントに送信されます。それ以外の場合（ポリシールールが州が有効になっている場合）、PES応答が生成され、エージェントに送信されます。ポリシーを無効にするルールの場合、PDS返信が生成され、エージェントに送信されます。
In both message formats, the lifetime attribute reports the current remaining lifetime of the policy rule, and the owner attribute reports the owner of the policy rule for which status information is requested.
両方のメッセージ形式で、Lifetime属性はポリシールールの現在の残りの寿命を報告し、所有者属性は、どのステータス情報が要求されるかについてのポリシールールの所有者に報告します。
The PRS reply message format is identical to the PRR reply message format except for an appended owner attribute. In the PRS reply, the attributes that are common with the PRR reply (except for the lifetime attribute) have exactly the same values as the corresponding attributes of the PRR reply that was sent as part of the PRR transaction that established the policy reserve rule.
PRS応答メッセージ形式は、Apped eded Owner属性を除き、PRR Replyメッセージ形式と同一です。PRSの応答では、PRR応答（生涯属性を除く）で一般的な属性は、ポリシーリザーブルールを確立したPRRトランザクションの一部として送信されたPRR応答の対応する属性とまったく同じ値を持っています。
In the PES reply message, the PER parameter set attribute, the address tuple (internal) attribute, and the address tuple (external) attribute have exactly the same values as the corresponding attributes of the PER or PEA request that were sent as part of the corresponding transaction that established the policy enable rule.
PES応答メッセージでは、パラメーターセット属性、アドレスタプル（内部）属性、およびアドレスタプル（外部）属性は、PERまたはPEA要求の対応する属性とまったく同じ値を持っています。ポリシーを確立した対応するトランザクションは、ルールを有効にします。
In the PES reply message, the policy rule identifier attribute, the group identifier attribute, the address tuple (inside) attribute, and the address tuple (outside) attribute have exactly the same values as the corresponding attributes of the PER reply that was sent as part of the PER or PEA transaction that established the policy enable rule.
PES応答メッセージでは、ポリシールール識別子属性、グループ識別子属性、アドレスタプル（内部）属性、およびアドレスタプル（外側）属性は、送信されたごとの応答の対応する属性とまったく同じ値を持っています。ポリシーを確立したPERまたはPEAトランザクションの一部を有効にするルールを有効にします。
In the PDS reply message, the policy rule identifier attribute, the address tuple (internal) attribute, and the address tuple (external) attribute have exactly the same values as the corresponding attributes of the PDR request message.
PDS応答メッセージでは、ポリシールール識別子属性、アドレスタプル（内部）属性、およびアドレスタプル（外部）属性は、PDR要求メッセージの対応する属性とまったく同じ値を持っています。
This transaction does not change the state of any policy rule.
このトランザクションは、ポリシールールの状態を変更しません。
When a middlebox receives a PRL request message, it first checks if the authenticated agent is authorized for receiving policy information. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
MiddleboxがPRL要求メッセージを受信すると、最初に認証されたエージェントがポリシー情報の受信が許可されているかどうかを確認します。そうでない場合、「このトランザクションで許可されていないエージェント」（0x0341）のタイプの否定的な返信メッセージを返します。
Then the middlebox generates a PRL reply message. For each policy rule at the middlebox in state RESERVED or ENABLED that the authenticated agent can access, a policy rule identifier attribute is generated and added to the PRL reply message before the message is sent to the agent. A negative reply message of type 'reply message too big' (0x0313) is generated if the number of policy rule attributes to be returned exceeds the maximum transport unit size of the underlying network connection or the maximum length of a SIMCO message. The total size of a SIMCO message is limited to 65,536 octets in total (see Section 4.2 for the SIMCO header).
次に、MiddleBoxはPRL応答メッセージを生成します。認証されたエージェントがアクセスできるように予約または有効になっているMiddleboxの各ポリシールールについて、メッセージがエージェントに送信される前にポリシールール識別子属性が生成され、PRL応答メッセージに追加されます。タイプ「返信メッセージが大きすぎる」（0x0313）の否定的な返信メッセージが生成されます。返されるポリシールール属性の数が、基礎となるネットワーク接続の最大輸送単位サイズまたはSIMCOメッセージの最大長を超えています。SIMCOメッセージの合計サイズは、合計65,536オクテットに制限されています（SIMCOヘッダーについてはセクション4.2を参照）。
This transaction does not change the state of any policy rule.
このトランザクションは、ポリシールールの状態を変更しません。
Processing of PDR requests is structured into five sub-sections. The first one describes the general extension of the MIDCOM protocol semantics by PDR. The second sub-section describes the initial checks that are performed in any case. The third sub-section describes the processing of PDR requests on pure firewalls. The fourth one describes processing on devices with NATs, and the fifth describes processing of devices with combined firewall and NAT functions.
PDR要求の処理は、5つのサブセクションに構成されています。最初のものは、PDRによるMIDCOMプロトコルセマンティクスの一般的な拡張について説明しています。2番目のサブセクションは、いずれにせよ実行される初期チェックについて説明します。3番目のサブセクションでは、純粋なファイアウォールでのPDR要求の処理について説明しています。4番目のものは、NATを使用したデバイスでの処理について説明し、5番目はファイアウォールとNAT機能を組み合わせたデバイスの処理について説明します。
The Policy Disable Rule (PDR) extends the MIDCOM protocol semantics [RFC3989] by another policy rule type. The PDR is intended to be used for dynamically blocking unwanted traffic, particularly in case of an attack, for example, a distributed denial of service attack.
ポリシーは、規則（PDR）を無効にして、MIDCOMプロトコルセマンティクス[RFC3989]を別のポリシールールタイプによって拡張します。PDRは、特に攻撃の場合、たとえば分散されたサービス攻撃の場合に、不要なトラフィックを動的にブロックするために使用することを目的としています。
PDR requests follow the same ownership concept as all other transactions do (see [RFC3989], Section 2.1.5). However, PDR prioritization over PERs is independent of ownership. A PDR always overrules a conflicting PER, even if the respective owners are different. Typically, only a highly privileged agent will be allowed to issue PDR requests.
PDRリクエストは、他のすべてのトランザクションと同じ所有権の概念に従います（[RFC3989]、セクション2.1.5を参照）。ただし、PERSに対するPDRの優先順位付けは、所有権とは無関係です。PDRは、それぞれの所有者が異なっている場合でも、常に矛盾するPerを覆します。通常、非常に特権のあるエージェントのみがPDRリクエストを発行することが許可されます。
A PDR rule and PER rule conflict with each other if their address tuples overlap such that there exists at least one IP packet that matches address tuple A0 of both rules in the internal network and that matches address tuple A3 of both rules in the external network. Note that the packet may be translated from the internal to external network, or vice versa.
PDRルールとルールごとのルールごとの競合アドレスタプルが重複する場合、内部ネットワーク内の両方のルールのアドレスタプルA0と一致する少なくとも1つのIPパケットが存在し、外部ネットワークの両方のルールの両方のルールのアドレスタプルA3に一致するようになります。パケットは、内部から外部ネットワークから翻訳されること、またはその逆にすることができることに注意してください。
Let's assume, for instance, that a policy enable rule (PER) enables all traffic from any external host using any UDP port to a certain UDP port of a certain internal host:
たとえば、ポリシーを有効にするルール（PER）は、任意のUDPポートを使用して特定の内部ホストの特定のUDPポートに任意の外部ホストからすべてのトラフィックを有効にすることを可能にします。
PER A3={ any external IP address, UDP, any port }
PER A0={ internal IP address 10.1.8.3, UDP, port 12345 }
Then this conflicts with a policy disable rule (PDR) blocking all UDP traffic from a potentially attacking host:
次に、これは、攻撃する可能性のあるホストからのすべてのUDPトラフィックをブロックするポリシー無効ルール（PDR）と競合します。
PDR A3={ external IP address 192.0.2.100, UDP, any port }
PDR A0={ any internal IP address, UDP, any port }
If a new PDR is established, then all conflicting PERS are terminated immediately. A new PER can only be established if it does not conflict with any already existing PDR.
新しいPDRが確立された場合、すべての競合するPERSはすぐに終了します。既存のPDRと矛盾しない場合にのみ、新しいPer Perは確立できます。
When a middlebox receives a PDR request message, it first checks if the authenticated agent is authorized for requesting middlebox configurations for disabling communication. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
MiddleboxがPDR要求メッセージを受信すると、最初に認証されたエージェントが通信を無効にするためのミドルボックス構成を要求する許可されているかどうかを確認します。そうでない場合、「このトランザクションで許可されていないエージェント」（0x0341）のタイプの否定的な返信メッセージを返します。
Then the middlebox checks the contained address tuple attributes.
次に、Middleboxは、含まれているアドレスタプル属性をチェックします。
If the first one does not have the location parameter field set to 'internal' (0x00), or if the second one does not have the location parameter field set to 'external' (0x03), then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
最初のものに「内部」（0x00）に設定された位置パラメーターフィールドがない場合、または2番目のパラメーターが「外部」に設定された場所パラメーターフィールド（0x03）に設定されていない場合、MiddleBoxはの否定的な返信メッセージを返します。「一貫性のない要求」（0x034b）と入力します。
If the transport protocol parameter field does not have the same value in both address tuple attributes, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
Transport Protocolパラメーターフィールドが両方のアドレスタプル属性に同じ値を持っていない場合、MiddleBoxはタイプ「一貫性のない要求」（0x034b）の否定的な応答メッセージを返します。
If both address tuple attributes contain a port range parameter field, if both port range parameter fields have values not equal to 0xFFFF, and if the values of both port range parameter fields are different, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
両方のアドレスタプル属性にポート範囲パラメーターフィールドが含まれている場合、両方のポート範囲パラメーターフィールドが0xFFFFに等しくない場合、両方のポート範囲パラメーターフィールドの値が異なる場合、ミドルボックスはタイプの否定的な応答メッセージを返します。リクエスト '（0x034b）。
Then the agent checks if wildcarding is requested and if the requested wildcarding is supported by the middlebox. Wildcarding support may be different for internal address tuples and external address tuples. The following parameter fields of the address tuple attribute can indicate wildcarding:
次に、エージェントは、ワイルドカードが要求されているかどうか、要求されたワイルドカードがミドルボックスによってサポートされているかどうかを確認します。ワイルドカードのサポートは、内部アドレスのタプルや外部アドレスのタプルで異なる場合があります。アドレスタプル属性の次のパラメーターフィールドは、ワイルドカードを示すことができます。
- the first parameter field If it is set to 'protocols only' (0x1), then IP addresses and port numbers are completely wildcarded.
- 最初のパラメーターフィールドは、「プロトコルのみ」（0x1）に設定されている場合、IPアドレスとポート番号は完全にワイルドカードされています。
- the transport protocol field If it is set to 0x00, then the transport protocol is completely wildcarded. Please note that a completely wildcarded transport protocol might still support only a limited set of transport protocols according to the capabilities of the middlebox. For example, a typical NAT implementation may apply transport wildcarding to UDP and TCP transport only. Wildcarding the transport protocol implies wildcarding of port numbers. If this field is set to 0x00, then the values of the port number field and the port range field are irrelevant.
- トランスポートプロトコルフィールドが0x00に設定されている場合、トランスポートプロトコルは完全にワイルドカードされています。完全にワイルドカードされた輸送プロトコルは、ミドルボックスの機能に従って限られた輸送プロトコルのみをサポートする可能性があることに注意してください。たとえば、典型的なNAT実装は、UDPおよびTCP輸送のみに輸送のワイルドカードを適用する場合があります。ワイルドカード輸送プロトコルは、ポート番号のワイルドカードを意味します。このフィールドが0x00に設定されている場合、ポート番号フィールドとポートレンジフィールドの値は無関係です。
- the prefix length field If the IP version number field indicates IPv4 and the value of this field is less than 0x20, then IP addresses are wildcarding according to this prefix length. If the IP version number field indicates IPv6 and the value of this field is less than 0x80, then IP addresses are wildcarding according to this prefix length. If the first parameter field is set to 'protocols only' (0x1), then the value of the prefix length field is irrelevant.
- IPバージョン番号フィールドがIPv4を示し、このフィールドの値が0x20未満である場合、IPアドレスがこのプレフィックスの長さに応じてワイルドカードになります。IPバージョン番号フィールドがIPv6を示し、このフィールドの値が0x80未満の場合、IPアドレスはこのプレフィックスの長さに従ってワイルドカードです。最初のパラメーターフィールドが「プロトコルのみ」（0x1）に設定されている場合、プレフィックス長フィールドの値は無関係です。
- the port number field If it is set to zero, then port numbers are completely wildcarded. In this case, the value of the port range field is irrelevant.
- ポート番号フィールドがゼロに設定されている場合、ポート番号は完全にワイルドカードされています。この場合、ポートレンジフィールドの値は無関係です。
If any of these kinds of wildcarding is used, and if this is in conflict with wildcarding support for internal or external addresses of the middlebox, then the middlebox returns a negative reply message of type 'requested wildcarding not supported' (0x034C).
これらの種類のワイルドカードのいずれかが使用され、これがミドルボックスの内部アドレスまたは外部アドレスのワイルドカードサポートと競合している場合、ミドルボックスは「サポートされていない」（0x034c）タイプの否定的な返信メッセージを返します。
Please note that the port range field cannot be used for wildcarding. If it is set to a value greater than one, then middlebox configuration is requested for all port numbers in the interval starting with the specified port number and containing as many consecutive port numbers as specified by the parameter.
ポートレンジフィールドはワイルドカードに使用できないことに注意してください。1より大きい値に設定されている場合、指定されたポート番号から始まり、パラメーターで指定されているように多くの連続したポート番号を含む間隔のすべてのポート番号に対してMiddleBox構成が要求されます。
The specified policy disable rule is activated, and the middlebox will terminate any conflicting policy enable rule immediately. Conflicts are defined in Section 8.8.1. Agents with open sessions that have access to the policy rules to be terminated are notified via the ARE notification.
指定されたポリシー無効ルールがアクティブ化され、ミドルボックスは競合するポリシーをすぐに有効にすることを終了します。競合は、セクション8.8.1で定義されています。終了するポリシールールにアクセスできるオープンセッションを備えたエージェントは、IS通知を介して通知されます。
The middlebox will reject all requests for new policy enable rules that conflict with the just established PDR as long as the PDR is not terminated. In such a case, a negative 'conflict with existing rule' (0x0350) reply will be generated.
Middleboxは、PDRが終了しない限り、新しいポリシーのすべての要求を拒否します。そのような場合、「既存のルールとの矛盾」（0x0350）の返信が生成されます。
After checking the address tuple attributes, the middlebox chooses a lifetime value for the new policy rule to be created, which is greater than or equal to zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox capabilities attribute at session setup. Formally, the lifetime is chosen such that
アドレスタプル属性をチェックした後、MiddleBoxは作成される新しいポリシールールの生涯値を選択します。セッションセットアップ時の機能属性。正式には、そのように寿命が選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup.
ホールド、「LT_Granted」はミドルボックスによって選択された実際の寿命であり、「LT_REQUESTED」はエージェントが要求する寿命であり、「LT_MAXIMUM」はセッションセットアップ時の能力交換中に指定された最大寿命です。
If there are further sessions in state OPEN with authenticated agents authorized to access the policy rule, then to each of these agents a corresponding ARE notification with lifetime set to lt_granted is sent.
Policyルールにアクセスすることを許可された認証エージェントを使用してState Openにさらにセッションがある場合、これらの各エージェントに、LT_Grantedに設定されたLifetimeが送信されることに対応する各エージェントが送信されます。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
選択された寿命がゼロの場合、Middleboxはタイプ「Middlebox構成が失敗した」（0x034a）の否定的な応答をエージェントに送信します。
If the middlebox is acting as a pure firewall, then it tries to configure the requested disable rule, i.e., configuring a blocking rule at the firewall. The disable rule is configured such that communication between the specified internal and external address tuples is blocked, covering the specified wildcarding. If the configuration fails (for example, because the blocking rule would conflict with high-level firewall policies), then the middlebox returns a negative reply message of type 'middlebox configuration failed' (0x034A).
ミドルボックスが純粋なファイアウォールとして機能している場合、要求された無効ルールを構成しようとします。つまり、ファイアウォールでブロッキングルールを構成します。特定された内部アドレスと外部アドレスのタプル間の通信がブロックされ、指定されたワイルドカードをカバーするように、無効ルールが構成されています。構成が失敗した場合（たとえば、ブロッキングルールが高レベルのファイアウォールポリシーと競合するため）、MiddleBoxはタイプ「Middlebox構成が失敗した」（0x034a）の否定的な返信メッセージを返します。
If the configuration was successful, the middlebox establishes a new policy disable rule and assigns to it a policy rule identifier in state ENABLED. It generates a positive PDR reply and sets the attributes as specified below.
構成が成功した場合、Middleboxは新しいポリシーを無効にするルールを確立し、州の有効化のポリシールール識別子を割り当てます。正のPDR応答を生成し、以下に指定した属性を設定します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PDR reply.
新しいポリシールールに選択された識別子は、PDR応答のポリシールール識別子属性に報告されます。
The chosen lifetime is reported in the lifetime attribute of the PDR reply.
選択された寿命は、PDR応答の生涯属性で報告されています。
If the middlebox is configured as a NAT, then it tries to block the specified address tuple in the NAT. The mechanisms used for this depend on the implementation and capabilities of the NAT.
ミドルボックスがNATとして構成されている場合、NATの指定されたアドレスタプルをブロックしようとします。これに使用されるメカニズムは、NATの実装と機能に依存します。
Should the configuration fail in either NAT case, a negative reply 'middlebox configuration failed' (0x034A) is returned.
いずれかのNATケースで構成が失敗した場合、否定的な応答「Middlebox構成が失敗した」（0x034a）が返されます。
If the configuration was successful, the middlebox establishes a new policy disable rule and assigns to it a policy rule identifier in state ENABLED. It generates a positive PDR reply and sets the attributes as specified below.
構成が成功した場合、Middleboxは新しいポリシーを無効にするルールを確立し、州の有効化のポリシールール識別子を割り当てます。正のPDR応答を生成し、以下に指定した属性を設定します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PDR reply.
新しいポリシールールに選択された識別子は、PDR応答のポリシールール識別子属性に報告されます。
The chosen lifetime is reported in the lifetime attribute of the PDR reply.
選択された寿命は、PDR応答の生涯属性で報告されています。
Middleboxes that are combinations of firewall and NAT are configured in such a way that first the firewall is configured with the blocking rule and afterwards the NAT is configured to block the address tuple. This aspect of middlebox operation may be irrelevant to SIMCO, since some NATs already do firewall configuration on their own.
ファイアウォールとNATの組み合わせであるミドルボックスは、最初にファイアウォールがブロッキングルールで構成され、その後NATがアドレスタプルをブロックするように構成されているように構成されます。一部のNATはすでに独自にファイアウォール構成を行っているため、Middlebox操作のこの側面はSIMCOとは関係ありません。
At any time, the middlebox may terminate a policy rule by deleting the configuration of the rule and by changing the corresponding PID state from ENABLED or from RESERVED, respectively, to UNUSED.
いつでも、ミドルボックスは、ルールの構成を削除し、対応するPID状態をそれぞれ有効または予約済みから未使用に変更することにより、ポリシールールを終了する場合があります。
For each session in state OPEN with authenticated agents authorized to access the policy rule, the middlebox generates a corresponding ARE notification with the lifetime attribute set to zero and sends it to the respective agent. The identifier of the terminated policy rule is reported in the policy rule identifier attribute of the ARE notification.
Policyルールにアクセスすることを許可された認証エージェントを使用して、State Openの各セッションについて、MiddleBoxは、対応するLifetime属性がゼロに設定された通知を生成し、それぞれのエージェントに送信します。終了したポリシールールの識別子は、ASの通知のポリシールール識別子属性に報告されます。
After sending the notification, the middlebox will consider the policy rule non-existent. It will not process any further transaction on this policy rule.
通知を送信した後、ミドルボックスはポリシールールが存在しないと見なします。このポリシールールに関するさらなるトランザクションは処理されません。
In the case of PRR, PER, PEA, and PLC (reserving and enabling policy rules and changes of the lifetime), the middlebox generates an ARE notification after processing the request. This ARE notification is generated for each session in state OPEN with authenticated agents (other than the requesting agent) who are authorized to access the policy rule. Through this ARE notification all other agents are kept synchronized with the latest state of the policy rules.
PRR、PER、PEA、およびPLCの場合（ポリシールールと生涯の変更を予約および有効にする）、ミドルボックスはリクエストの処理後にALS通知を生成します。これは、Policyルールにアクセスする権限を与えられた認証エージェント（要求エージェント以外）を使用して、State Openの各セッションに対して生成されます。これを通じて通知を通じて、他のすべてのエージェントは、ポリシールールの最新の状態と同期しています。
Middleboxes, such as firewalls and NATs, are usually operated for improving the network security and for extending the IP address space (note that stand-alone NATs are not considered to improve security; see [RFC2663]). The configuration of middleboxes from an external entity looks quite counterproductive on the first glimpse, since an attacker using this can possibly configure the middlebox in such way that no filtering is applied anymore or that NAT bindings are configured for malicious use. So the middlebox is not performing the intended function anymore. Possible threats to SIMCO are:
ファイアウォールやNATなどのミドルボックスは、通常、ネットワークセキュリティを改善し、IPアドレス空間を拡張するために操作されます（スタンドアロンNATはセキュリティを改善するとは見なされないことに注意してください。[RFC2663]を参照）。外部エンティティからのミドルボックスの構成は、最初の垣間見ることで非常に逆効果に見えます。これを使用する攻撃者は、フィルタリングがもう適用されなく、NATバインディングが悪意のある使用のために構成されているようにミドルボックスを構成できる可能性があるためです。したがって、ミドルボックスは意図した関数を実行しなくなりました。Simcoに対する考えられる脅威は次のとおりです。
- Man-in-the-middle attack A malicious host intercepts messages exchanged between then SIMCO agent and middlebox and can change the content of the messages on the fly. This man-in-the-middle attack would result, from the agent's view, in a proper middlebox configuration, but the middlebox would not be configured accordingly. The man in the middlebox could open pinholes that compromise the protected network's security.
- 中間の攻撃悪意のあるホストは、その後のSimcoエージェントとMiddleboxの間で交換されたメッセージをインターセプトし、その場でメッセージのコンテンツを変更することができます。この中間の攻撃は、エージェントの見解から適切なミドルボックス構成で生じますが、それに応じてミドルボックスは構成されません。ミドルボックスの男性は、保護されたネットワークのセキュリティを妥協するピンホールを開くことができました。
- Changing content The message content could be changed in such a way that the requested policy rule configuration is not configured in the middlebox, but that any other unwanted configuration could be. That way, an attacker can open the firewall for his own traffic.
- コンテンツの変更メッセージコンテンツは、要求されたポリシールール構成がミドルボックスで構成されていないが、他の不要な構成が可能になるように変更できます。そうすれば、攻撃者は自分のトラフィックのためにファイアウォールを開くことができます。
- Replaying Already sent messages could be re-sent in order to configure the middlebox in such a way that hosts could configure policy rules without the permission of an application-level gateway or system administrator.
- 既に送信されたメッセージのリプレイは、ホストがアプリケーションレベルのゲートウェイまたはシステム管理者の許可なしにポリシールールを構成できるようにミドルボックスを構成するために再配置する可能性があります。
- Wiretapping An already configured policy rule could be re-used by other hosts if the policy rule is configured with too broad a wildcarding (see below). These hosts could send unwanted traffic.
- 賞賛されているポリシールールを盗聴すると、ポリシールールがワイルドカードが広すぎると構成されている場合、他のホストによって再利用される可能性があります（以下を参照）。これらのホストは、不要なトラフィックを送信できます。
The previous subsection identifies several issues on security for SIMCO. SIMCO can rely on IPsec mechanisms, as defined in [RFC4302] and [RFC4303], for ensuring proper operations.
以前のサブセクションでは、SIMCOのセキュリティに関するいくつかの問題を特定しています。SIMCOは、適切な操作を確保するために、[RFC4302]および[RFC4303]で定義されているように、IPSECメカニズムに依存できます。
When SIMCO relies on IPsec, it uses IPsec in transport mode with an authentication header (AH) [RFC4302] and an encapsulating security payload (ESP) [RFC4303], so that IP traffic between SIMCO agent and middlebox is protected. The authentication header is used for protecting the whole packet against content changes and replaying. The ESP header is used to prevent wiretapping.
SIMCOがIPSECに依存する場合、認証ヘッダー（AH）[RFC4302]とセキュリティペイロード（ESP）[RFC4303]を使用して輸送モードでIPSECを使用して、SIMCOエージェントとMiddlebox間のIPトラフィックが保護されます。認証ヘッダーは、コンテンツの変更とリプレイからパケット全体を保護するために使用されます。ESPヘッダーは、盗聴を防ぐために使用されます。
At either the agent or middlebox side, the following should be pre-configured: the IP addresses of the agent or middlebox, TCP (as the transport protocol), and the port numbers (if possible). Only packets from the pre-configured address of the agents or middlebox should be accepted.
エージェント側またはミドルボックス側のいずれかで、以下を事前に構成する必要があります。エージェントまたはミドルボックス、TCP（トランスポートプロトコルとして）のIPアドレス、およびポート番号（可能であれば）。エージェントまたはミドルボックスの事前に構成されたアドレスからのパケットのみを受け入れる必要があります。
The keys for authentication for both the SIMCO agent and middlebox are pre-configured at each side. For replay protection, the use of a key management system is recommended. For the Internet Key Exchange (IKE) protocol, see [RFC4306].
SIMCOエージェントとミドルボックスの両方の認証用のキーは、両側に事前に構成されています。リプレイ保護には、主要な管理システムの使用が推奨されます。インターネットキーエクスチェンジ（IKE）プロトコルについては、[RFC4306]を参照してください。
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that attempt to determine or fix the address (and port) by which they are known to another endpoint. UNSAF proposals, such as STUN [RFC3489], are considered a general class of work-arounds for NAT traversal and solutions for scenarios with no middlebox communication (MIDCOM).
一方的な自己アドレス固定（UNSAF）は、[RFC3424]で、別のエンドポイントに知られているアドレス（およびポート）を決定または修正しようとする発信エンドポイントのプロセスとして説明されています。Stun [RFC3489]などのUNSAFの提案は、NATトラバーサルのワークアラウンドの一般的なクラスおよびミドルボックス通信（MIDCOM）のないシナリオのソリューションのソリューションの一般的なクラスと見なされます。
This document describes a protocol implementation of the MIDCOM semantics and thus implements a middlebox communication (MIDCOM) solution. MIDCOM is not intended as a short-term work-around, but more as a long-term solution for middlebox communication. In MIDCOM, endpoints are not involved in allocating, maintaining, and deleting addresses and ports at the middlebox. The full control of addresses and ports at the middlebox is located at the SIMCO server.
このドキュメントでは、MIDCOMセマンティクスのプロトコル実装について説明し、ミドルボックス通信（MIDCOM）ソリューションを実装しています。MIDCOMは、短期的な作業アラウンドとしてではなく、ミドルボックス通信の長期的なソリューションとして意図されています。Midcomでは、エンドポイントは、ミドルボックスでアドレスとポートの割り当て、維持、削除に関与していません。ミドルボックスのアドレスとポートの完全な制御は、SIMCOサーバーにあります。
Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution.
したがって、このドキュメントは、長期的な代替ソリューションを提案することにより、[RFC3424]のUNSAF考慮事項に対処します。
The authors would like to thank Sebastian Kiesel and Andreas Mueller for valuable feedback from their SIMCO implementation and Mary Barnes for a thorough document review.
著者は、Simcoの実装からの貴重なフィードバックについて、Sebastian KieselとAndreas Muellerに、徹底的な文書レビューについてはMary Barnesに感謝します。
[RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 3989, February 2005.
[RFC3989] Stiemerling、M.、Quittek、J。、およびT. Taylor、「Middlebox Communications（Midcom）プロトコルセマンティクス」、RFC 3989、2005年2月。
[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月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：住所割り当てと集約戦略」、1993年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[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月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、RFC 3303、2002年8月。
[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月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「スタン - ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H。、「IESGおよびRFCエディタードキュメント：手順」、BCP 92、RFC 3932、2004年10月。
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
Authors' Addresses
著者のアドレス
Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Kurfuersten-Anlage 36 69115 Heidelberg Germany
Martin Stiemerling Nec Europe Ltd. Network Laboratories Europe Kurfuersten-Anlage 36 69115ハイデルベルクドイツ
Phone: +49 6221 4342-113
EMail: stiemerling@netlab.nec.de
Juergen Quittek NEC Europe Ltd. Network Laboratories Europe Kurfuersten-Anlage 36 69115 Heidelberg Germany
Juergen Quittek Nec Europe Ltd. Network Laboratories Europe Kurfuersten-Anlage 36 69115 Heidelbergドイツ
Phone: +49 6221 4342-115
EMail: quittek@netlab.nec.de
Cristian Cadar Muelheimer Strasse 23 40239 Duesseldorf Germany
クリスティアン・カダール・ムエルハイマー・ストラス23 40239 Duesseldorfドイツ
EMail: ccadar2@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。