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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。この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.
この文書では、ファイアウォールやネットワークアドレス変換器としてミドルボックスを制御するためのプロトコルを記述しています。それはSIMCOプロトコルの以前の実験バージョンと比較RFC 3989.に記載ミドルコミュニケーションズ（MIDCOM）意味論の完全準拠した実装であり、このバージョン（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は、アプリケーションがミドルボックスを渡すために、データグラムの流れを可能にするミドルでの動的設定を要求するために、データグラムの経路上の中間装置と通信することを可能にします。アプリケーションは、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プロトコル意味論に完全に準拠しています。 [RFC3989]のセクション2.1.1で定義されるようにSIMCOプロトコルトランザクションを実装します。 [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は、オープンするNOAUTHから[RFC3989]の図2に示す状態遷移をモデル化するために使用されます。 PEAはRESERVEDから有効]に[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は、政策上の優先順位は、ルール（のPER）を有効にしています。 PDRが確立されると、（単に部分的に重複しているのPERを含む）すべての矛盾のPERが終了し、PDRが終了される前に、新たな競合PERを確立することはできません。 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のプロトコルは、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のトランスポートとして使用することができながら、SIMCOの実装は、TCPをサポートしている必要があります。トランスポートとしてTCPを使用する場合はエージェントがポート7626.上でこのポートを接続するために、ミドルボックスは待たなければなりませんIANA（http://www.iana.org/assignments/port-numbersを参照）によりSIMCOサーバに割り当てられています。認証、メッセージの整合性と機密性を保証するために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メッセージは、トランスポート・プロトコルを介して送信されているタイプレングス値（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メッセージの四つの基本的な種類があります。
- 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.
エージェントにミドルから送信されたメッセージの基本的なタイプは、他の三つのタイプのいずれかである一方、ミドルにエージェントから送信されたメッセージは、常に基本的な型「要求メッセージ」のです。要求メッセージと、正と負の応答メッセージは、トランザクションを要求するために属しています。ビューのエージェントの観点から、通知メッセージは通知のみの取引に属します。ビューのミドルの観点から、通知メッセージも要求トランザクションに属していてもよいです。セクション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
0×01：リクエストメッセージが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)
0×01（SE）セッション確立0x02の：（SA）セッション認証0x03の：（ST）セッション終了0x11を：（PRR）責任準備金ルール0x12を：（PER）ポリシー有効ルール0x13に：予約後（PEA）PER（のみリクエスト）0x14に：（PDR）ポリシーの無効ルール0x15の：（PLC）政策ルールの生涯変更0x16：（PRD）ポリシールールの削除（正の返信のみ）0x21で：（PRS）政策ルールの状態の0x22：（PRL）、ポリシールールリスト0x23：（PES）ポリシー（のみ肯定応答）0x24をルールステータスを有効にします（PDS）ポリシー禁止ルールのステータス（正の返信のみ）
For basic type 0x03 (negative reply message), the following values of the sub-type field are defined:
基本的なタイプ0×03（負の応答メッセージ）のために、サブタイプフィールドの次の値が定義されています。
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
間違った基本的な要求メッセージの種類0x11を：：間違った要求メッセージのサブタイプの0x12：ひどく形成要求0x13に：あまりにも大きな応答メッセージの0x10を扱う一般的なメッセージに関する回答
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
セッションの0x20に関する回答：リソースの不足の0x22：プロトコルのバージョンの不一致0x23：適用できない0x21での要求の認証は、0x24を失敗しました：なし、許可0x25：トランスポートプロトコルの問題を
0x26 : security of underlying protocol layers insufficient
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に関する回答：トランザクションは0×41をサポートしていません：このトランザクション0x43このために利用可能なリソースがない：このトランザクションの0x42のためのエージェント権限を与えられていない指定されたポリシールールは、0x44の存在しません：指定されたポリシールールグループは、0x45存在しません：指定されたポリシーにアクセスするための権限がありません0x46の：0x48利用できません要求されたアドレス空間：指定したグループ0x47にアクセスするための権限を与えられていないIPの欠如は、0x49をアドレス：ポート番号0x4Aの欠如：ミドル構成が0x4Bを失敗しました：矛盾した要求0x4Cを：要求されたワイルドカードは0x4Dをサポートしていません：プロトコルタイプが一致しません。 0x4E：0x4FをサポートしていないNATモード：IPバージョンの不一致0x50を：生涯0x52を変更する権限がありません：寿命は$ 53を拡張することができません：違法なIPアドレスが0x54：プロトコルタイプは0x55をサポートしていません：違法なポート番号0x56：既存のルール0x51との競合その後のポート（NOSP）0x57の違法数：すでにPID 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の：（AST）非同期セッション終了0x03の：（ARE）非同期ポリシールールイベント（BFM）ひどく形成されたメッセージは、0x02の受信しました
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）は、トランザクションを識別する任意の数です。要求メッセージでは、エージェントは同じエージェントが同じセッションに属する2つの異なる要求メッセージで同じTIDを使用したことがないように、エージェント固有のTIDを選択します。対応する要求メッセージと同じTIDが含まれている必要があり、メッセージを返信します。通知メッセージには、ミドルは同じミドルが同じセッションに属する2つの異なる通知メッセージで同じTIDを使用したことがないように、ミドル-ユニークな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つのオクテットは、バージョン番号、一つの大きなバージョン番号および他のマイナーバージョン番号が含まれています。残りの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です。プロトコルバージョン属性で運ばれたバージョン番号は、メジャーバージョン番号とマイナーバージョン番号の0 3です。
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.
認証チャレンジ属性と認証トークンの属性が同じフォーマットを持っています。両方が可変長の単一値フィールドを含みます。両方のために、最大長は4096オクテットに制限されます。これらの属性の長さは4つのオクテットの倍数でない値を持つ場合がありますのでご了承ください。認証チャレンジ属性の場合、値フィールドは、他のピアが自身を認証することを要求し、他の1つのピアから送信された認証チャレンジが含まれています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
ミドル能力属性は、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.
第1のパラメータフィールドは、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のサポート：ポート変換は、0x02の（0x40のセットが必要です）：プロトコル変換（0x40のセットが必要です）0x04を：二回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ビットの大きさを持っています。許容値は、IPv4とIPv6のデュアルスタックのためのIPバージョン4（IPv4）、IPバージョン6（IPv6）のために0x2の、両方の（0x3の）の組み合わせについては0x1です。
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.
最大政策ルール寿命パラメータフィールドは、ポリシールールを持っていることの最大存続期間を指定します。
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:
第1のパラメータフィールドは、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'.
第四のパラメータ・フィールドは、また、8ビットの長さを有します。これは、トランスポートプロトコルを指定します。このフィールドの定義された値は、IPv4ヘッダ[RFC791]またはIPv6ヘッダの「次ヘッダフィールド」に[RFC2460]の「プロトコル」フィールドで許可されたすべての値です。これらのフィールドの定義された番号のセットは、ラベルの下でIANA（Internet Assigned Numbers Authority）の「プロトコル番号」によって維持されています。
The fifth parameter field has also a length of 8 bits. It specifies the location of the address. Defined values for this field are:
第五のパラメータフィールドはまた、8ビットの長さを有します。これは、アドレスの場所を指定します。このフィールドの定義された値は次のとおりです。
0x00 : internal (A0) 0x01 : inside (A1) 0x02 : outside (A2) 0x03 : external (A3)
0x00の内部（A0）が0x01：内部（A1）0×02：外部（A2）0x03の外部（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と呼ばれる第1のパラメータフィールドは、2ビットの長さを有しており、予約が要求されたミドルの要求されたNATモードを指定します。このフィールドの定義された値は次のとおりです。
01 : traditional 10 : twice
01：伝統的な10：二回
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:
第三及び第四のパラメータフィールドは、それぞれ、IPIとIPOと呼ばれます。両方が2ビットの長さを有しています。これらはそれぞれ、ミドルボックスの内外（IPI）または（IPO）でIPプロトコルの要求されたバージョンを指定します。これらのフィールドの定義された値は次のとおりです。
00 : any 01 : IPv4 10 : IPv6
00：任意の01：10のIPv4：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'.
第五のパラメータフィールドは、8ビットの長さを有します。それは予約がなされるべき対象のトランスポートプロトコルを指定します。ゼロの値は、予約は、特定のプロトコルの選択とポート番号のないIPアドレスを要求していることを示します。可非ゼロ値は、IPv4ヘッダとIPv6拡張ヘッダの「プロトコル」フィールドに定義された値です。これらのフィールドの定義された番号のセットは、ラベルの下でIANA（Internet Assigned Numbers Authority）の「プロトコル番号」によって維持されています。
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.
第六のパラメータフィールドは、16ビットの長さを有します。それがサポートされるべきポート範囲の長さを指定する符号なし整数を含んでいます。 0xFFFFの値は、予約が指定されたトランスポートプロトコルのすべてのポート番号のために作られるべきであることを示しています。 0x0001という値を持つポート範囲フィールドは、1つのポート番号が予約されなければならないことを指定します。 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:
第1のパラメータフィールドは、8ビットの長さを有します。これは、要求されたポートのパリティを指定します。このフィールドの定義された値は次のとおりです。
0x00 : any 0x03 : same
$ 00：任意の0×03：同じ
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
0×01：インバウンド0x02の：アウトバウンド0×03：双方向
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：パラメータセットの属性PER
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：ひどく形成された要求
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.
不正な形式のメッセージ（BFM）通知メッセージがSIMCOメッセージフォーマット定義に準拠していないメッセージを受信した後エージェントにミドルから送信されます。 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
0x0101：SE要求0x0102：SA要求0x0103：ST要求0x0201：SE肯定応答0x0202：SA肯定応答0x0203：ST肯定応答0x0310：陰性応答：間違った基本的な要求メッセージタイプ0x0311：陰性応答：間違った要求メッセージサブタイプ0x0312：負の返信：ひどく形成要求0x0320：負の応答：要求なし0x0321：負の返信：リソース0x0322の不足：負の返信：プロトコルのバージョンの不一致0x0323：負の返信：負の返信：：いいえ承認0x0325：認証が0x0324に失敗した負の応答を：輸送プロトコルの問題0x0326：陰性応答：基礎となるプロトコル層のセキュリティが不十分0x0401：BFM通知0x0402：AST通知
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）要求メッセージは、セッションの確立を要求するために、ミドルにエージェントから送信されます。必須SIMCOバージョン番号属性とミドルが自身を認証することを要求するオプションの認証チャレンジ属性：SE要求メッセージは、1つのまたは2つの属性が含まれています。
+--------------------------+
| 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）応答メッセージは、セッション確立が完了したことを示しています。ミドル能力属性：これは、単一の必須属性が含まれています。
+--------------------------+
| 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つは存在する必要があります。一つ目は、エージェントが自身を認証することを要求する認証チャレンジ属性です。二つ目は、エージェントによる認証要求に対する応答として、ミドルボックスを認証する認証トークンの属性です。
+--------------------------+
| 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.
初期SE要求がSA応答によって応答した後にセッション認証（SA）要求メッセージがミドルにエージェントから送信されます。 SA応答でミドルにより送信された認証チャレンジへの応答として、エージェントを認証する認証トークン属性：SE要求メッセージには、オプションの属性が含まれています。
+--------------------------+
| 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つの陰性応答は、セッション確立に対して特異的です。プロトコルバージョン属性：そのうちの一つは、「プロトコルのバージョンの不一致」否定応答（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
0x0111：PRR要求0x0112：要求0x0113 PER：PEA要求0x0114：PDR要求0x0115：PLC要求0x0121：PRS要求0x0122：PRL要求0x0211：PRR肯定応答0x0212：PDR肯定応答0x0215：PLC肯定応答0x0216肯定応答0x0214 PER。 PRD肯定応答0x0221：PRS肯定応答0x0223：PES肯定応答0x0224：PDS肯定応答0x0222：PRL肯定応答0x0310：陰性応答：間違った基本的な要求メッセージタイプ0x0311：陰性応答：間違った要求メッセージサブタイプ0x0312：負返信：悪いです形成要求0x0340：負の返信：トランザクションは0x0341をサポートしていません：負の返信：このトランザクション0x0342のためのエージェント権限がありません：負の返信：このトランザクション0x0343ために利用可能なリソースがない：負の応答：指定されたポリシールールが存在しません。
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
0x0344：負の応答：指定されたポリシールールグループが0x0345に存在しません：負の応答：このポリシー0x0346にアクセスするための権限がありません：負の応答：指定したグループ0x0347にアクセスするための権限がありません：負の応答：要求されたアドレス空間を利用できない0x0348：負の返信：不足負の返信：IPは0x0349アドレスのポート番号0x034Aの欠如：負の返信：負の返信：一貫性のない要求0x034C：負の返信：0x034Dサポートされていません要求されたワイルドカード：負の返信：プロトコルタイプが0x034E一致しません：ミドル構成は0x034Bを失敗した負回答：NATモードは0x034Fをサポートしていません：負の返信：IPバージョンの不一致0x0350：負の返信：負の返信：生涯0x0352を変更する権限がありません：負の返信：寿命は0x0353を拡張することができません。負の返信：違法既存のルール・0x0351との競合IPアドレス0x0354：負の返信：プロトコルタイプ0x0355をサポートしていません：負の返信：違法なポート番号0x0356：負の返信：I llegal NOSP 0x0357：負の返信：すでにPID 0x0358を有効：負の返信：パリティは0x0401と一致しません：負の返信：BFM通知0x0403：負の返信：ARE通知
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はミドルの各ポリシールールの所有者属性を維持します。ミドルの構成に応じて、いくつかの薬剤は、同じ政策ルールにアクセスすることができ、参照[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）通知を生成します。エージェントが予約またはポリシールールを有効にした場合、ミドルは、この政策ルールにアクセスすることを許可されているすべてのエージェントにAREを送信します。ミドルは、ルールの有効期間が変更されたとき、またはルールが削除された場合、このポリシールールにアクセスする権限をすべてのエージェントに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）要求メッセージはミドルで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つの属性が含まれています。最初のものは、内部アドレス、外部アドレス、要求されたポリシールール寿命、及びグループ識別子を除くリクエストのすべてのパラメータを指定するPERパラメータ設定属性です。不足しているパラメータは、次の4つの属性によって覆われています。 2つのアドレスタプルパラメータは、内部と外部アドレスのタプルを指定します。多くのPRR要求のように、最後の2つの属性が要求された寿命とグループIDを指定します。グループ識別子属性はオプションです。
+--------------------------+
| SIMCO header |
+--------------------------+
| PER parameter set |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| group identifier | optional
+--------------------------+
Figure 24: Structure of PER request
図24：PER要求の構造
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）要求メッセージは、内部と外部アドレスとの間のデータ通信を可能に要求するミドルにエージェントから送信されます。それは、PER要求に似ています。一つだけ違いがあります。 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ヘッダのほかに、リクエストメッセージは、レポートが要求されたポリシールールを指定するだけつの属性が含まれています。
+--------------------------+
| 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つの必須属性とオプションの属性を含んでいます。唯一のミドルタイプ二回-NATである場合に返されるアドレスタプル内禁じます。
+--------------------------+
| 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又はPEA要求メッセージを使用して）、内部と外部アドレスとの間のデータ転送を可能にした後、ポリシールール（PER）陽性応答が送信されるイネーブル。メッセージは、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：PER肯定応答の構造
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）陽性の応答が送信されます。政策ルールの残りの寿命：メッセージは1つだけの属性が含まれています。
+--------------------------+
| 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.
ミドルボックスは、ITポリシールールを終了することを意味し、ゼロにポリシールールの残りの寿命を変更した後、ポリシー・ルール削除（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）正の回答がすべての確立ポリシールールのリストを報告するために使用されています。このメッセージの属性の数は可変です。メッセージは、確立されたポリシールールごとにポリシールール識別子属性が含まれています。
+--------------------------+
| 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.
ミドルが正常にポリシーを無効ルールと矛盾するポリシールールの除去を可能にした後、ポリシーを無効にするルール（PDR）正の応答が送信されます。新しいポリシーを無効ルールのポリシールール識別子、およびポリシールールの残りの寿命：メッセージには、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セッションに参加し、明示的に（即ち、予約可能、及び寿命を変化させる）作用を要求していないが、このようなARE通知を受信したときに：
- a policy rule is deleted (lifetime attribute = 0)
- 政策ルールが削除される（生涯属性= 0）
- a policy rule is reserved (lifetime attribute = lifetime)
- ポリシールールが予約されている（寿命属性=寿命）
- a policy rule is enabled (lifetime attribute = 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、ミドルボックスは、BFM通知を送信します。
o If a session is already established, then the middlebox also sends an AST notification and closes the connection.
セッションがすでに確立されている場合は、O、そしてミドルも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).
メッセージの長さを加えた8つのオクテット（SIMCOヘッダの長さ）によって指定されるように、エージェントからのような多くのオクテットを受信するまで、2）ミドル待ちます。
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.
ミドルはまだ待っていると60秒のエージェントから、それ以上のオクテットを受信しない場合は、O、それは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、そしてミドルも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.
基本的なメッセージタイプフィールドの値が等しい0x01の（要求メッセージ）がない場合はO、次いでミドルは、メッセージの処理を停止し、エージェントのタイプ「間違った基本的な要求メッセージタイプ」（0x0310）の負の応答を送信します。
o If no session is established, then the middlebox closes the connection after sending the 0x0310 reply.
何のセッションが確立されていない場合は、O、そしてミドルは0x0310応答を送信した後、接続を閉じます。
4) Then the middlebox checks the message sub-type.
4）次に、ミドルボックスは、メッセージのサブタイプをチェックします。
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全くセッションが確立されていない場合、唯一のサブタイプ「セッション確立」（0×01）が受け入れられます。他のすべてのサブタイプの場合、ミドルは、エージェントに型「間違った要求メッセージのサブタイプ」（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セッションがすでに確立されている場合、メッセージのサブタイプは、セクション4.2.2で定義されたサブタイプのいずれかであるミドルボックスをチェックした場合。 （ 'セッション確立'（0×01）、 'セッション終了'（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、次いでミドルは、メッセージの処理を停止し、エージェントのタイプ「間違った要求メッセージのサブタイプ」（0x0311）の応答を送信します。
5) Then the middlebox checks the TLV-structured attributes in the message.
5）次に、ミドルボックスは、メッセージ内の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、ミドルボックスは、メッセージの処理を停止し、エージェントに「ひどく形成要求」（0x0312）タイプの応答を送信します。
o If no session is established, then the middlebox closes the connection after sending the 0x0312 reply.
何のセッションが確立されていない場合は、O、そしてミドルは0x0312応答を送信した後、接続を閉じます。
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の要求メッセージを送信することができます。ミドルはその後戻ってエージェントに要求ごとに単一の応答を送信します。また、ミドルは迷惑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）は、要求メッセージ、「/」の記号、及び応答メッセージの記述子の記述子によって示されています。通知の取引は、単に通知記述子によって示されています。例えば、成功した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
最初は、すべてのセッションは状態CLOSEDです。そこから、成功したSEのトランザクションはNOAUTHするまたはオープンするか、その状態を変更することができます。状態NOAUTHからは、成功したSAのトランザクションがOPENにセッション状態を変更します。失敗したSAのトランザクションからセッション状態を変更します
NOAUTH back to CLOSED. Successful ST transactions and AST notifications change sessions from state NOAUTH or from state OPEN to state CLOSED.
バックCLOSEDにNOAUTH。成功したSTの取引およびAST通知は閉状態にOPEN状態NOAUTHまたは状態からのセッションを変更します。
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セッションはミドルはSE、SA、およびST以外の要求を受け入れているだけの状態である状態OPEN、で確立されています。
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要求にのみ適用されます。セッションが状態NOAUTHまたはOPENである場合には、ミドルは変わらず、セッションの状態を残して、エージェントにタイプ「は適用されません要求」（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要求メッセージの内容を処理する前に、ミドルは、そのリソースをチェックし、利用可能なリソースは、エージェントにサービスを提供するのに十分ではないことを決定することができます。このような場合には、ミドルボックスは、タイプ「リソース不足」（0x0321）の負の応答を返し、接続を閉じます。また、ミドルボックスは、選択したネットワーク接続とそのプロトコル固有のパラメータは、ミドルボックスのために許容されない場合にSE要求を拒否することを決定することができます。このような場合には、ミドルボックスは、タイプ「トランスポートプロトコル問題」（0x0325）の負の応答を返し、接続を閉じます。ミドルは、「基本的なプロトコル層のセキュリティが不十分」（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要求メッセージの処理には、プロトコルバージョン属性でメジャーとマイナープロトコルバージョン番号をチェックすることから始まります。ミドルボックスは、指定されたバージョン番号をサポートしていない場合には、ミドルボックスは、ミドルボックスによってサポートされているバージョン番号を示すプロトコルバージョン属性を持つタイプ「プロトコルバージョン不一致」（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）を用い、その後、ミドルチェックすることによって認証された場合。そうでない場合は、ミドルは「ノー承認」（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要求メッセージに認証チャレンジ属性を追加することで、明示的な認証を要求します。ミドルは、エージェントへの認証チャレンジ属性を持つSA応答メッセージを返すことで、明示的な認証を要求します。両当事者が明示的に認証を要求した場合、SA応答メッセージは、エージェントの認証チャレンジ属性とミドルを認証する認証トークン属性の両方が含まれています。
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要求メッセージは、認証チャレンジ属性が含まれている場合、ミドルのチェックは、それ自体を認証することができます。そうならば、それはSA応答に対応する認証トークン属性を追加します。それは認証チャレンジ属性に基づいて認証できない場合、それは長さゼロの値フィールドを持つ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.
ミドルボックスは、SA応答メッセージと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要求メッセージは、認証チャレンジ属性が含まれていなかった場合は、ミドルはSE要求メッセージに応答してSE応答メッセージを送信します。これはCLOSEDからセッション状態の変化がオープンすることを意味します。
The SE reply message contains a capabilities attribute describing the middlebox capabilities.
SEの応答メッセージは、ミドル能力を記述する能力属性が含まれています。
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要求は、セッションが状態NOAUTHにある場合にのみ適用されます。セッション状態で閉じられているか、OPEN場合、ミドルボックスは、エージェントに（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.
状態NOAUTHにSA要求メッセージを受信した後、ミドルチェック剤が十分に認証された場合。認証は、任意にSA要求メッセージに含まれる認証トークンの属性に基づいてもよいです。エージェントが十分に認証されていない場合は、ミドルは型「認証失敗」（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.
セッション状態NOAUTHまたはOPENであればST要求にのみ適用されます。セッション状態で閉じられている場合には、ミドルボックスは、エージェントに（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要求に応答します。 OPENからかNOAUTHからCLOSEDへのセッションの状態が変化します。 STの応答を送信した後、ミドルは接続を閉じます。 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.
いつでも、ミドルは、確立されたセッションを終了することと、OPENからかNOAUTHからCLOSEDにセッション状態を変更します。セッション終了は、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要求を送信することができます。ミドルはその後戻ってエージェントに要求メッセージごとに単一の応答メッセージを送信します。また、ミドルはいつでも迷惑ARE通知を送信することができます。
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、またはPER取引によって確立されています。ポリシールールが作成されるたびに、未使用のポリシールール識別子（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の状態を変更しないので、失敗した構成要求トランザクションは、表示されません。通知の取引は、単に通知記述子によって示されています。例えば、成功した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をピックアップしRESERVEDに状態を変更します。トランジションPER成功は、未使用の状態でPIDをピックアップして有効に状態を変更します。状態RESERVEDでのPIDは、成功したPEAのトランザクションによって使用可能に変更されます。状態RESERVEDまたはUNUSEDでは、ゼロより大きい寿命パラメータを使用して成功したPLCの取引はPIDの状態を変更しません。ゼロに等しい寿命パラメータを持つ成功したPLCトランザクションは、未使用又は未使用することが可能でRESERVEDから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.
ゼロに設定寿命属性を持つARE通知トランザクションはゼロに等しい寿命パラメータを使用して成功した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機能を備えたミドルボックスに純粋なファイアウォールではるかに簡単です。したがって、このセクションでは、三つのサブセクションがあります。最初のものは、いずれの場合に実行される初期チェックを記述する。第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).
ミドルボックスは、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).
グループが既に存在する場合、要求は、オプションのグループ識別子、その後ミドルチェックが含まれている場合。そうでない場合、ミドルタイプの負の応答メッセージを返信する（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).
要求は、オプショングループの識別子が含まれている場合、ミドルチェック認証エージェントは、このグループにメンバーを追加するための許可された場合。そうでない場合、ミドルタイプの負の応答メッセージを返信する（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フィールドがミドルのアドレスの内部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件の余分の取引が続きます。まず、エージェントが対応するPERトランザクションの要求メッセージを送信し、この上の負の応答を受け取ることになります。第二に、エージェントのいずれかが予約を削除するためにゼロに設定寿命に対応するPLCの要求メッセージを送信する、または予約がタイムアウトになるとミドルがゼロに設定寿命属性を持つARE通知メッセージを送信します。ミドルが最初にこのチェックを実行する場合、両方の取引を回避することができます。
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つのトランザクションを処理二回チェックを実行するよりも、少ないリソースを消費するために考えられている場合、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パラメータセットを確認した後、ミドルボックスは、ミドルボックスで指定された要求された値の最小値と最大寿命以上ゼロ及び以下で作成される新しいポリシールールのライフタイム値を、選択しました機能は、セッションセットアップ時に属性。正式には、寿命がそのように選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <=最小値（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.
次いで、対応するこれらの薬剤のそれぞれに認証された薬剤とOPENポリシールールにアクセスすることを許可の状態でさらにセッションがある場合、送信されるlt_grantedに設定寿命の通知です。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
選択された寿命がゼロの場合、ミドルは、エージェントに（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.
ミドルは純粋なファイアウォールとして構成されている場合は、それは初期チェックの後に要求を受け付けます。これは、新たな責任準備金のルールを確立し、状態RESERVEDでそれにポリシールール識別子を割り当てます。これは、正の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要求に含まれている場合、ミドルは、このグループのメンバーに新しいポリシールールを追加します。 PRR要求はグループ識別子属性が含まれていない場合は、ミドルは唯一のメンバーとして新しいポリシールールを使用して新しいグループを作成します。いずれにせよ、ミドルは、新しいポリシールールが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パラメータセット属性にトランスポートプロトコル属性に同一に設定されています。位置パラメータフィールドは、「外部」（0×02）に設定されています。
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モード）パラメータがその設定と一致した場合ミドルボックスは、第1のさらなるセットPRRパラメータをチェックします。コンフィギュレーションが一致していない場合は、ネガ型の応答「NATモードはサポートされていません」（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 A 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）で結合NAT A NATが予約されています。また、ミドルボックスは、（A1）NATは、要求されたトランスポート・プロトコル、内部IPバージョン、ポート範囲、およびポートパリティとの結合内部を留保します。
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.
チェックが正常に実行された後、ミドルボックスは、要求されたPRRパラメータセットを用いて、新しいポリシー準備ルールを確立し、状態RESERVEDでそれにポリシールール識別子を割り当てます。これは、正の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要求に含まれている場合、ミドルは、このグループのメンバーに新しいポリシールールを追加します。 PRR要求はグループ識別子属性が含まれていない場合は、ミドルは唯一のメンバーとして新しいポリシールールを使用して新しいグループを作成します。いずれにせよ、ミドルは、新しいポリシールールが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応答のアドレスタプル（外部）属性では、第1のパラメータフィールドが「完全アドレス」（は0x0）に設定されています。位置パラメータフィールドは、「外部」（0×02）に設定されています。 IPバージョンパラメータフィールドは、PRR要求メッセージのPRRパラメータセットの属性におけるIPOのパラメータフィールドに応じて設定されています。 IPv4アドレスは、プレフィックス長フィールドは、完全なアドレスを示すためには0x20に設定され、予約外部IPv4アドレスがアドレスフィールドに設定されています。 IPv6アドレスの場合は、プレフィックス長フィールドは、完全なアドレスを示すためには0x80に設定し、IPv6アドレスをアドレスフィールドに設定されている外に予約されています。 PRR応答のアドレスタプルのトランスポート・プロトコル・パラメータ・フィールド（外側の）属性は、PRR要求メッセージのPRRパラメータセット属性にトランスポートプロトコル属性に同一に設定されています。ベースポート番号（すなわち、割り当てられた範囲の最小ポート番号）の外側に予約ポート番号パラメータフィールドに格納され、割り当てられたポート範囲は、ポート範囲のパラメータフィールドに記憶されます。
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応答メッセージは、アドレスタプル（内部の）属性が含まれていません。それ以外の場合は（それは二度 'の値を持つ）場合には、PRR応答メッセージは、アドレスタプル（内部の）属性が含まれています。 PRR返信のアドレスタプル（内部の）属性では、最初のパラメータフィールドは、「完全なアドレス」（は0x0）に設定されています。位置パラメータフィールドが「内部」（0×01）に設定されています。 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機能を持つミドルボックスよりも純粋なファイアウォールではるかに簡単です。したがって、このセクションでは、三つのサブセクションがあります。最初のものは、いずれの場合に実行される初期チェックを記述する。第2のサブセクションでは、純粋なファイアウォール上のPER要求の処理を記述し、そして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).
ミドルボックスは、PER要求メッセージを受信すると、それが最初に確認認証エージェントは、通信を可能にするためのミドル構成を要求する許可された場合。そうでない場合、それは（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).
グループが既に存在する場合、要求は、オプションのグループ識別子、その後ミドルチェックが含まれている場合。そうでない場合、ミドルタイプの負の応答メッセージを返信する（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).
要求は、オプショングループの識別子が含まれている場合、ミドルチェック認証エージェントは、このグループにメンバーを追加するための許可された場合。そうでない場合、ミドルタイプの負の応答メッセージを返信する（0x0346）「指定されたグループにアクセスする権限がありません」。
Then the middlebox checks the contained address tuple attributes.
そして、ミドルが含まれているアドレスのタプルの属性をチェックします。
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).
最初のものは、位置パラメータフィールドは、（0×00）「内部」に設定、または第二一つは持っていない場合、位置パラメータフィールドは、（0×03）「外部」に設定されていない場合、ミドルボックスは、負の応答メッセージを返します'矛盾した要求'（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).
トランスポート・プロトコル・パラメータ・フィールドが両方のアドレスタプル属性に同じ値を持っていない場合は、ミドルボックスは、タイプ「矛盾要求」（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より大きい値に設定されている場合には、ミドル構成は、間隔内のすべてのポート番号が指定されたポート番号で開始し、パラメータで指定されたできるだけ多くの連続したポート番号を含むために要求されます。
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).
PERパラメータセット属性に方向パラメータフィールドの値が「双方向」を持っている場合は、唯一のトランスポートプロトコルのワイルドカードが許可されています。ワイルドカードの他の種類は、1つまたはIPアドレスタプル属性の両方に指定されている場合、ミドルボックスは、タイプ「矛盾要求」（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).
任意のポリシー禁止ルールにPERの要求が競合する場合（セクション8.8.1を参照）、次いで、ミドルは（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
アドレスタプル属性をチェックした後、ミドルボックスは、ミドルボックスで指定された要求された値の最小値と最大寿命以上ゼロ及び以下で作成される新しいポリシールールのライフタイム値を、選択しました機能は、セッションセットアップ時に属性。正式には、寿命がそのように選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <=最小値（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.
次いで、対応するこれらの薬剤のそれぞれに認証された薬剤とOPENポリシールールにアクセスすることを許可の状態でさらにセッションがある場合、送信されるlt_grantedに設定寿命の通知です。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
選択された寿命がゼロの場合、ミドルは、エージェントに（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).
ミドルは純粋なファイアウォールとして機能している場合、それは要求されたピンホールを設定しようとします。ファイアウォールの設定は、属性を設定PERパラメータでポートのパリティパラメータフィールドを無視しますが、それは、この属性で方向パラメータフィールドを検討します。ピンホールは、指定された内部および外部アドレスタプルとの間の通信は、特定の方向に有効であり、指定されたワイルドカードをカバーするように構成されています。 （ピンホールは、高レベルのファイアウォールポリシーと競合するため、など）の構成が失敗した場合は、ミドルボックスは、タイプ「失敗ミドル構成」（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.
設定が成功した場合、ミドルは、新しいポリシールールを有効に確立し、それに有効な状態での政策ルール識別子を割り当てます。これは、正のPER応答を生成し、以下の指定などの属性を設定します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
新しいポリシールールのために選ばれた識別子は、PER応答の政策ルール識別子属性で報告されます。
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要求に含まれている場合、ミドルは、このグループのメンバーに新しいポリシールールを追加します。 PRR要求はグループ識別子属性が含まれていない場合は、ミドルは唯一のメンバーとして新しいポリシールールを使用して新しいグループを作成します。いずれにせよ、ミドルは、新しいポリシールールがPER応答のグループ識別子属性に所属しているグループを報告します。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
選ばれた寿命はPER応答の寿命属性で報告されます。
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.
PER要求のアドレスタプル（内部）属性はPER応答のアドレスタプル（外部）属性として報告されます。 PER要求のアドレスタプル（外部の）属性は、PER応答のアドレスタプル（内部の）属性として報告されます。
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）要求の行為に非常に似ていますが、PERで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.
- 倍NAT A NATは、結合は、要求されたトランスポート・プロトコル、ポート範囲、およびポートパリティと内部と外部アドレスタプルとの間で確立されます。しかし、2つのアドレスのタプルが作成されます。外のアドレスタプルと内部のアドレスタプル。
Should the configuration fail in either NAT case, a negative reply 'middlebox configuration failed' (0x034A) is returned.
コンフィギュレーションは、どちらかのNATの場合には故障した場合、否定応答が返される（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.
設定が成功した場合、ミドルは、新しいポリシールールを有効に確立し、それに有効な状態での政策ルール識別子を割り当てます。これは、正のPER応答を生成し、以下の指定などの属性を設定します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
新しいポリシールールのために選ばれた識別子は、PER応答の政策ルール識別子属性で報告されます。
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要求に含まれている場合、ミドルは、このグループのメンバーに新しいポリシールールを追加します。 PRR要求はグループ識別子属性が含まれていない場合は、ミドルは唯一のメンバーとして新しいポリシールールを使用して新しいグループを作成します。いずれにせよ、ミドルは、新しいポリシールールがPER応答のグループ識別子属性に所属しているグループを報告します。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
選ばれた寿命はPER応答の寿命属性で報告されます。
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.
PER応答のアドレスタプル（外部）属性では、第1のパラメータフィールドが「完全アドレス」（は0x0）に設定されています。位置パラメータフィールドは、「外部」（0×02）に設定されています。 IPバージョンパラメータフィールドは、PER要求メッセージのPERパラメータセットの属性におけるIPバージョンパラメータフィールドに応じて設定されています。 IPv4アドレスは、プレフィックス長フィールドは、完全なアドレスを示すためには0x20に設定され、予約外部IPv4アドレスがアドレスフィールドに設定されています。 IPv6アドレスの場合は、プレフィックス長フィールドは、完全なアドレスを示すためには0x80に設定し、IPv6アドレスをアドレスフィールドに設定されている外に予約されています。 PER応答のアドレスタプルのトランスポート・プロトコル・パラメータ・フィールド（外側の）属性は、PER要求メッセージの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.
ミドルは二回NATの場合はアドレスの組は、（内側）のみ返されます。それ以外の場合は省略されています。 PER返信のアドレスタプル（内部の）属性では、最初のパラメータフィールドは、「完全なアドレス」（は0x0）に設定されています。位置パラメータフィールドが「内部」（0×01）に設定されています。 IPバージョンパラメータフィールドは、PER要求メッセージのPERパラメータセットの属性におけるIPバージョンパラメータフィールドに応じて設定されています。 IPv4アドレスは、プレフィックス長フィールドは、完全なアドレスを示すためには0x20に設定され、IPv4アドレスの内部に予約されたアドレスフィールドに設定されています。 IPv6アドレスの場合は、プレフィックス長フィールドは、完全なアドレスを示すためには0x80に設定され、IPv6アドレス内に確保アドレスフィールドに設定されています。 PER応答のアドレスタプルのトランスポート・プロトコル・パラメータ・フィールド（内部の）属性は、PER要求メッセージの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バインディングはその後、ファイアウォールピンホールを構成しているように構成されているのMiddleboxes。ファイアウォールルールが外部アドレスのタプルにし、同様に二度NATの内側のアドレスタプルのために応じて設定する必要がありますので、このシーケンスは必要とされています。いくつかのNATは、すでに自分でファイアウォールの設定を行うため、ミドル操作のこの局面は、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機能を備えたミドルボックスに純粋なファイアウォールではるかに簡単です。したがって、このセクションでは、三つのサブセクションがあります。最初のものは、いずれの場合に実行される初期チェックを記述する。第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).
ミドルボックスは、PEA要求メッセージを受信すると、それが最初に確認認証エージェントは、通信を可能にするためのミドル構成を要求する許可された場合。そうでない場合、それは（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).
そして、ミドルは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).
この識別子のポリシールールが存在するが、認証エージェントがこのポリシー予備ルールを終了するために許可されていない場合には、ミドルボックスは（0x0345） 'このポリシーにアクセスするために許可されていないエージェントのタイプの負の応答メッセージを返します。
Then the middlebox checks the contained address tuple attributes.
そして、ミドルが含まれているアドレスのタプルの属性をチェックします。
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).
最初のものは、（0×00）の内部 'に設定された位置パラメータフィールドを持たない場合、または第二の一方が「外部」に位置パラメータフィールドが設定されていない場合（0×03）、次いで、ミドルタイプの負の応答メッセージを返す場合'矛盾した要求'（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).
トランスポート・プロトコル・パラメータ・フィールドが両方のアドレスタプル属性に同じ値を持っていない場合は、ミドルボックスは、タイプ「矛盾要求」（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を参照）、次いで、ミドルは（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
アドレスタプル属性をチェックした後、ミドルボックスは、で指定された要求された値の最小値と最大寿命以上ゼロ及び以下で作成される新しいポリシールールの有効ライフタイム値を、選択しましたミドル能力は、セッションセットアップ時に属性。正式には、寿命がそのように選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <=最小値（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.
次いで、対応するこれらの薬剤のそれぞれに認証された薬剤とOPENポリシールールにアクセスすることを許可の状態でさらにセッションがある場合、送信されるlt_grantedに設定寿命の通知です。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
選択された寿命がゼロの場合、ミドルは、エージェントに（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).
ミドルは純粋なファイアウォールとして構成されている場合は、それは要求されたピンホールを設定しようとします。ファイアウォールの設定は、属性を設定PERパラメータでポートのパリティパラメータフィールドを無視しますが、それは、この属性で方向パラメータフィールドを検討します。ピンホールは、指定された内部および外部アドレスタプルとの間の通信は、特定の方向に有効であり、指定されたワイルドカードをカバーするように構成されています。コンフィギュレーションが失敗した場合は、ミドルボックスは、タイプ「ミドル設定失敗」（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要求メッセージ内のポリシールール識別子属性によって参照責任準備金規則に取って代わります。ポリシーを有効ルール置き換え責任準備金規則のポリシールール識別子を再使用しています。 RESERVEDからENABLEDへの政策ルール識別子の状態が変化します。置換ポリシー準備ルールがあったとして責任準備金ルールは、同じグループのメンバーです。
Then the middlebox generates a positive PER reply and sets the attributes as specified below.
そして、ミドルは、正のPER応答を生成し、以下の指定などの属性を設定します。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
新しいポリシールールのために選ばれた識別子は、PER応答の政策ルール識別子属性で報告されます。
The group identifier is reported in the group identifier attribute of the PER reply.
グループ識別子は、PER応答のグループ識別子属性で報告されます。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
選ばれた寿命はPER応答の寿命属性で報告されます。
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.
PER要求のアドレスタプル（内部）属性は、アドレスタプル（外側）PER応答の属性として報告されます。 PER要求のアドレスタプル（外部の）属性は、アドレスタプル（内部の）PER応答の属性として報告されます。
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.
有効な構成が成功した場合、ミドルは、ルールを有効にする新しいポリシーにPEA要求メッセージ内のポリシールール識別子属性によって参照責任準備金規則に取って代わります。ポリシーを有効ルール置き換え責任準備金規則のポリシールール識別子を再使用しています。 RESERVEDからENABLEDへの政策ルール識別子の状態が変化します。置換ポリシー準備ルールがあったとして責任準備金ルールは、同じグループのメンバーです。
Then the middlebox generates a positive PER reply and sets the attributes as specified below.
そして、ミドルは、正のPER応答を生成し、以下の指定などの属性を設定します。
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.
アドレスタプル外予約アドレスタプル（外側）PER応答の属性として報告されます。アドレスタプル内部予約アドレスタプル（内部の）PER応答の属性として報告されます。両方の外部予約と内部アドレスタプルは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).
ミドルボックスは、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).
そして、ミドルは、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).
この識別子のポリシールールが存在するが、認証エージェントがこのポリシールールの寿命を変更するために許可されていない場合には、ミドルボックスは（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)
0 <= lt_granted <=最小値（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の状態を変更する場合ENABLEDまたは未使用のために、それぞれ、RESERVED。
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応答メッセージを生成し、要求エージェントに送信します。次いで、対応するこれらの薬剤のそれぞれに認証された薬剤とOPENポリシールールにアクセスすることを許可の状態でさらにセッションがある場合、ゼロに設定さ寿命の通知が送信されているものです。
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).
ミドルボックスは、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).
そして、ミドルは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).
この識別子のポリシールールが存在するが、認証エージェントがこのポリシールールのステータス情報を受信することを許可されていない場合、ミドルボックスは（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.
上記チェックが渡された場合は、ミドルボックスは、要求を受け取り、応答を生成します。ステータス情報が要求されたポリシールールがRESERVEDの状態にある場合には、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.
両方のメッセージ・フォーマットで、寿命属性は、ポリシールールの現在の残存寿命を報告し、所有者の属性は、ステータス情報が要求されているポリシールールの所有者を報告します。
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応答メッセージのフォーマットは、特許所有者属性以外PRR応答メッセージのフォーマットと同一です。 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要求の対応する属性と全く同じ値を持つメッセージ、PERパラメータセットの属性、アドレスタプル（内部）属性、及びアドレスタプル（外部の）属性返信ルールを有効にする方針を確立したトランザクションに対応します。
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の対応する属性は、それがのように送信された応答と全く同じ値を有する属性ポリシールールを有効に確立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).
ミドルボックスは、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).
次いで、ミドルは、PRL応答メッセージを生成します。認証エージェントがアクセスできることを予約またはイネーブル状態でミドルにおける各ポリシールールのために、ポリシールール識別子属性が生成され、PRLに追加メッセージをエージェントに送信される前に、メッセージを返信。ポリシールールの数が返される属性の基本的なネットワーク接続またはSIMCOメッセージの最大長さの最大搬送ユニットのサイズを超えた場合、タイプ「大きすぎる応答メッセージ」（0x0313）の負の応答メッセージが生成されます。 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.
他のすべてのトランザクションが（[RFC3989]、セクション2.1.5を参照してください）ないようPDR要求は同じ所有権概念に従ってください。しかし、のPERを超える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ルールと相互にPER規則の競合そのアドレスタプルは、内部ネットワークの両方のルールのアドレスタプルA0と一致し、それが外部ネットワークに両方のルールのアドレスタプルA3と一致する少なくとも1つのIPパケットが存在するように重なった場合。パケットが外部ネットワーク、またはその逆に内部から翻訳されてもよいことに留意されたいです。
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:
ポリシーは、特定の内部ホストの特定のUDPポートに任意のUDPポートを使用して、任意の外部ホストからのすべてのトラフィックを可能にします（PER）のルールを有効にすること、のは、例えば、仮定しよう：
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にのみ確立することができます。
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).
ミドルボックスは、PDR要求メッセージを受信すると、それが最初に確認認証エージェントは、通信を無効にするためのミドル構成を要求する許可された場合。そうでない場合、それは（0x0341）タイプ「このトランザクションのために許可されていないエージェント」の否定応答メッセージを返します。
Then the middlebox checks the contained address tuple attributes.
そして、ミドルが含まれているアドレスのタプルの属性をチェックします。
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).
最初のものは、位置パラメータフィールドは、（0×00）「内部」に設定、または第二一つは持っていない場合、位置パラメータフィールドは、（0×03）「外部」に設定されていない場合、ミドルボックスは、負の応答メッセージを返します'矛盾した要求'（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).
トランスポート・プロトコル・パラメータ・フィールドが両方のアドレスタプル属性に同じ値を持っていない場合は、ミドルボックスは、タイプ「矛盾要求」（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より大きい値に設定されている場合には、ミドル構成は、間隔内のすべてのポート番号が指定されたポート番号で開始し、パラメータで指定されたできるだけ多くの連続したポート番号を含むために要求されます。
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項で定義されています。ポリシールールへのアクセス権を持っているセッションを開いている薬剤である通知を介して通知されて終了します。
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.
ミドルは、新しいポリシーのすべての要求限りPDRが終了していないとしてだけ確立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
アドレスタプル属性をチェックした後、ミドルボックスは、ミドルボックスで指定された要求された値の最小値と最大寿命以上ゼロ及び以下で作成される新しいポリシールールのライフタイム値を、選択しました機能は、セッションセットアップ時に属性。正式には、寿命がそのように選択されます
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <=最小値（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.
次いで、対応するこれらの薬剤のそれぞれに認証された薬剤とOPENポリシールールにアクセスすることを許可の状態でさらにセッションがある場合、送信されるlt_grantedに設定寿命の通知です。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
選択された寿命がゼロの場合、ミドルは、エージェントに（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).
ミドルは純粋なファイアウォールとして機能している場合、それはつまり、ファイアウォールでブロックルールを設定し、要求された無効化ルールを設定しようとします。無効ルールが指定ワイルドカードをカバーする、指定された内部および外部アドレスタプルとの間の通信が遮断されるように構成されています。 （ブロックルールは、ハイレベルのファイアウォールポリシーと競合するため、など）の構成が失敗した場合は、ミドルボックスは、タイプ「失敗ミドル構成」（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.
設定が成功した場合、ミドルは、新しいポリシーを無効にルールを確立し、それに有効な状態での政策ルール識別子を割り当てます。これは、正の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の場合には故障した場合、否定応答が返される（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.
設定が成功した場合、ミドルは、新しいポリシーを無効にルールを確立し、それに有効な状態での政策ルール識別子を割り当てます。これは、正の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は、すでに自分でファイアウォールの設定を行うため、ミドル操作のこの局面は、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.
いつでも、ミドルボックスは、ルールの設定を削除することによって、未使用の、それぞれ、ENABLEDまたはRESERVEDから対応する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.
認証された薬剤とOPENポリシールールへのアクセスを許可状態でセッションごとに、ミドルボックスは、ゼロに設定寿命属性を持つされた対応する通知を生成し、それぞれのエージェントに送信します。終了ポリシールールの識別子がARE通知の政策ルール識別子属性で報告されます。
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（予約とポリシールール及び寿命の変化を可能にする）の場合には、ミドルボックスは、要求を処理した後ARE通知を生成します。このARE通知は、ポリシールールにアクセスすることを許可されている（要求剤以外の）認証済みの薬剤とのOPEN状態でセッションごとに生成されます。このARE通知を通じて、他のすべてのエージェントは、ポリシールールの最新の状態で同期が維持されています。
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のような中間装置は、通常、（[RFC2663]を参照することは、スタンドアローンのNATは、セキュリティを向上させるために考慮されていない注意）ネットワークセキュリティを向上させるためとIPアドレス空間を拡張するために操作されます。これを使用して、攻撃者は、おそらく何のフィルタリングはもはや適用されていないか、その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エージェントとミドル間で交換し、その場でメッセージの内容を変更することができman-in-the-middle攻撃。このman-in-the-middle攻撃は、適切なミドル構成で、エージェントの観点から、結果だろうが、ミドルはそれに応じて構成されていないでしょう。ミドルの男は、保護されたネットワークのセキュリティを侵害ピンホールを開くことができます。
- 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のセキュリティ上のいくつかの問題を識別します。 [RFC4302]及び[RFC4303]で定義されるようSIMCOは、適切な動作を確保するため、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に依存している場合SIMCO剤とミドル間のIPトラフィックが保護されるように、それは、認証ヘッダ（AH）[RFC4302]とカプセル化セキュリティペイロード（ESP）[RFC4303]とトランスポートモードでIPsecを使用します。認証ヘッダは、コンテンツの変更およびリプレイに対してパケット全体を保護するために使用されます。 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としてUNSAF提案、[RFC3489]は、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の実装とメアリー・バーンズからの貴重なフィードバックのためのセバスチャン・キーセルとアンドレアス・ミュラーに感謝したいと思います。
[RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 3989, February 2005.
[RFC3989] Stiemerling、M.、Quittek、J.、およびT.テイラー、 "ミドル・コミュニケーションズ（MIDCOM）プロトコルのセマンティクス"、RFC 3989、2005年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、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]フラー、V.、李、T.、ゆう、J.、およびK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、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.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、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.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[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]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H.、 "IESGとRFC Editorのドキュメント：プロシージャ"、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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
Authors' Addresses
著者のアドレス
Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Kurfuersten-Anlage 36 69115 Heidelberg Germany
マーティンStiemerling NECヨーロッパ社ネットワーク研究所ヨーロッパKurfuersten-Anlageの36 69115ハイデルベルクドイツ
Phone: +49 6221 4342-113 EMail: stiemerling@netlab.nec.de
電話：+49 6221 4342-113電子メール：stiemerling@netlab.nec.de
Juergen Quittek NEC Europe Ltd. Network Laboratories Europe Kurfuersten-Anlage 36 69115 Heidelberg Germany
ユルゲンQuittek NECヨーロッパ社ネットワーク研究所ヨーロッパKurfuerstenコンディショニング36 69115ハイデルベルク、ドイツ
Phone: +49 6221 4342-115 EMail: quittek@netlab.nec.de
電話：+49 6221 4342-115電子メール：quittek@netlab.nec.de
Cristian Cadar Muelheimer Strasse 23 40239 Duesseldorf Germany
クリスティアンCadar Muelheimerシュトラーセ23 40239デュッセルドルフドイツ
EMail: ccadar2@yahoo.com
メールアドレス：ccadar2@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。