Network Working Group M. Stiemerling
Request for Comments: 4540 J. Quittek
Category: Experimental NEC
C. Cadar
May 2006
Network Working Group M. Stiemerling
Request for Comments: 4540 J. Quittek
Category: Experimental NEC
C. Cadar
May 2006
NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
NEC的简单中间箱配置（SIMCO）协议版本3.0
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（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.
IETF曾考虑过本RFC的内容，因此它可能类似于当前正在进行的IETF工作或已发布的IETF工作。本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本RFC的读者应谨慎评估其实施和部署价值。有关更多信息，请参阅RFC 3932[RFC3932]。
Abstract
摘要
This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements.
本文档描述了用于控制防火墙和网络地址转换器等中间盒的协议。它是RFC3989中描述的Middlebox通信（MIDCOM）语义的完全兼容实现。与SIMCO协议的早期实验版本相比，该版本（3.0）使用二进制消息编码以减少资源需求。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Binary Encodings ...........................................4
2. Compliance with MIDCOM Protocol Semantics .......................5
3. SIMCO Sessions ..................................................6
4. SIMCO Message Components ........................................6
4.1. Message Types ..............................................7
4.2. The SIMCO Header ...........................................7
4.2.1. Basic Message Types .................................8
4.2.2. Message Sub-types for Requests and Positive
Replies .............................................8
4.2.3. Message Sub-types for Negative Replies ..............8
4.2.4. Message Sub-types for Notifications .................9
4.2.5. Transaction Identifier ..............................9
4.3. The SIMCO Payload .........................................10
4.3.1. SIMCO Protocol Version Attribute ...................11
4.3.2. Authentication Attributes ..........................11
4.3.3. Middlebox Capabilities Attribute ...................12
4.3.4. Policy Rule Identifier Attribute ...................13
4.3.5. Group Identifier Attribute .........................13
4.3.6. Policy Rule Lifetime Attribute .....................13
4.3.7. Policy Rule Owner Attribute ........................14
4.3.8. Address Tuple Attribute ............................14
4.3.9. PRR Parameter Set Attribute ........................16
4.3.10. PER Parameter Set Attribute .......................18
5. SIMCO Message Formats ..........................................19
5.1. Protocol Error Replies and Notifications ..................19
5.1.1. BFM Notification ...................................19
5.1.2. Protocol Error Negative Replies ....................19
5.2. Session Control Messages ..................................20
5.2.1. SE Request .........................................20
5.2.2. SE Positive Reply ..................................21
5.2.3. SA Positive Reply ..................................21
5.2.4. SA Request .........................................21
5.2.5. ST Request and ST Positive Reply ...................22
5.2.6. SE Negative Replies ................................22
5.2.7. AST Notification ...................................23
5.3. Policy Rule Control Messages ..............................23
5.3.1. Policy Events and Asynchronous Notifications .......24
5.3.2. PRR Request ........................................24
5.3.3. PER Request ........................................25
5.3.4. PEA Request ........................................26
5.3.5. PLC Request ........................................26
5.3.6. PRS Request ........................................27
5.3.7. PRL Request ........................................27
5.3.8. PDR Request ........................................27
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
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
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.
Simple Middlebox Configuration（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以前的实验版本使用简单的ASCII编码和增强的BNF作为语法规范。与二进制编码相比，这种编码需要更多的资源来生成和解析消息。这适用于用于编码代理和中间盒的资源，以及用于执行SIMCO堆栈的资源。
Low resource requirements are important properties for two main reasons:
低资源需求是重要的财产，主要原因有两个：
- For many applications (for example, IP telephony), session setup times are critical. Users do accept setup times only up to some limit, and some signaling protocols start retransmitting messages if setup is not completed within a certain time.
- 对于许多应用程序（例如，IP电话），会话设置时间至关重要。用户只接受一定限制的设置时间，如果设置未在一定时间内完成，某些信令协议将开始重新传输消息。
- Many middleboxes are rather small and relatively low-cost devices. For these, support of resource-intensive protocols might be a problem. The acceptance of a protocol on these devices depends, among other things, on the cost of implementing the protocol and of its hardware requirements.
- 许多中间盒都相当小，成本相对较低。对于这些，支持资源密集型协议可能是一个问题。在这些设备上是否接受协议，除其他外，取决于实现协议的成本及其硬件要求。
Therefore, we decided to use a simple and efficient binary encoding for SIMCO version 3.0, which is described in this document.
因此，我们决定对SIMCO 3.0版使用简单有效的二进制编码，本文对此进行了描述。
SIMCO version 3 is fully compliant with the MIDCOM protocol semantics defined by [RFC3989]. SIMCO implements protocol transactions as defined in Section 2.1.1 of [RFC3989]. All message types defined in Section 2.1.2 of [RFC3989] are supported by SIMCO, and all mandatory transactions are implemented. SIMCO does not implement the optional group transactions. For all implemented transactions, SIMCO implements all parameters concerning the information contained.
SIMCO版本3完全符合[RFC3989]定义的MIDCOM协议语义。SIMCO执行[RFC3989]第2.1.1节中定义的协议事务。SIMCO支持[RFC3989]第2.1.2节中定义的所有消息类型，并执行所有强制事务。SIMCO不实施可选的组事务。对于所有实现的事务，SIMCO实现与所包含信息有关的所有参数。
SIMCO defines a few new terms to reference functionality in the semantics. Among these terms are Session Authentication (SA) and Policy Enable Rule After reservation (PEA) messages. SA is used to model the state transition given in Figure 2 of [RFC3989] from NOAUTH to OPEN. PEA is used to model the state transition given in Figure 4 of [RFC3989] from RESERVED to ENABLED.
SIMCO定义了一些新术语来引用语义中的功能。这些术语包括会话身份验证（SA）和策略启用保留后规则（PEA）消息。SA用于模拟[RFC3989]图2中给出的从NOAUTH到OPEN的状态转换。PEA用于模拟[RFC3989]图4中给出的从保留到启用的状态转换。
SIMCO implements one additional transaction, the Policy Disable Rule (PDR) transaction, to those defined in [RFC3989]. PDR transactions are used by security functions such as intrusion detection and attack detection. They allow the agent to block a specified kind of traffic. PDRs have priority above Policy Enable Rules (PERs). When a PDR is established, all conflicting PERs (including PERs with just a partial overlap) are terminated, and no new conflicting PER can be established before the PDR is terminated. Support of the PDR transaction by SIMCO is optional. For a detailed description of the PDR transaction semantics, see Section 8.8.
SIMCO在[RFC3989]中定义的事务之外还实现了一个事务，即策略禁用规则（PDR）事务。PDR事务由入侵检测和攻击检测等安全功能使用。它们允许代理阻止特定类型的通信。PDR的优先级高于策略启用规则（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协议使用一个包含两方的会话模型：代表一个或多个应用程序的代理和一个中间箱。双方可参加多次会议。代理可以使用每个中间盒的一个会话同时与多个中间盒通信。中间盒可以使用每个代理的一个会话同时与多个代理通信。
+-------+ SIMCO protocol +-----------+
| agent +------------------+ middlebox |
+-------+ +-----------+
+-------+ SIMCO protocol +-----------+
| agent +------------------+ middlebox |
+-------+ +-----------+
Figure 1: Participants in a SIMCO session
图1：SIMCO会议的参与者
SIMCO sessions must run over a reliable transport layer protocol and are initiated by the agent. SIMCO implementations must support TCP, while other reliable transport protocols can be used as transport for SIMCO as well. When using TCP as transport, middleboxes must wait for agents to connect on port 7626. This port is assigned to SIMCO servers by IANA (see http://www.iana.org/assignments/port-numbers). The session may be secured, if required, by either IPsec or TLS [RFC4346] to guarantee authentication, message integrity and confidentiality. The use of IPsec is outlined in Section 9, "Security Considerations".
SIMCO会话必须通过可靠的传输层协议运行，并由代理启动。SIMCO实现必须支持TCP，而其他可靠的传输协议也可以用作SIMCO的传输协议。当使用TCP作为传输时，中间盒必须等待代理在端口7626上连接。IANA将此端口分配给SIMCO服务器（请参阅http://www.iana.org/assignments/port-numbers). 如果需要，可以通过IPsec或TLS[RFC4346]保护会话，以保证身份验证、消息完整性和机密性。第9节“安全注意事项”概述了IPsec的使用。
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.
从代理到中间箱以及从中间箱到代理的所有SIMCO消息均通过第3节规定的传输协议发送。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头开始。消息的其余部分，即有效负载，包含零个、一个或多个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头），以八位字节为单位，以及事务标识符。SIMCO标头的大小为64位。其布局如图2所示。
Message Type
_______________^_______________
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Basic Type | Sub-Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier (TID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Type
_______________^_______________
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Basic Type | Sub-Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier (TID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SIMCO header
图2:SIMCO标头
For the basic type field, the following values are defined:
对于“基本类型”字段，定义了以下值：
0x01 : Request Message 0x02 : Positive Reply Message 0x03 : Negative Reply Message 0x04 : Notification Message
0x01:请求消息0x02:肯定回复消息0x03:否定回复消息0x04:通知消息
For basic types 0x01 (request) and 0x02 (positive reply), a common set of values for the sub-type field is defined. Most of the sub-types can be used for both basic types. Restricted sub-types are marked accordingly.
对于基本类型0x01（请求）和0x02（肯定答复），定义了子类型字段的一组通用值。大多数子类型可用于这两种基本类型。相应地标记受限子类型。
0x01 : (SE) session establishment 0x02 : (SA) session authentication 0x03 : (ST) session termination 0x11 : (PRR) policy reserve rule 0x12 : (PER) policy enable rule 0x13 : (PEA) PER after reservation (request only) 0x14 : (PDR) policy disable rule 0x15 : (PLC) policy rule lifetime change 0x16 : (PRD) policy rule deletion (positive reply only) 0x21 : (PRS) policy rule status 0x22 : (PRL) policy rule list 0x23 : (PES) policy enable rule status (positive reply only) 0x24 : (PDS) policy disable rule status (positive reply only)
0x01:（SE）会话建立0x02:（SA）会话身份验证0x03:（ST）会话终止0x11:（PRR）策略保留规则0x12:（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:
对于基本类型0x03（否定回复消息），定义了子类型字段的以下值：
Replies concerning general message handling 0x10 : wrong basic request message type 0x11 : wrong request message sub-type 0x12 : badly formed request 0x13 : reply message too big
关于一般消息处理的答复0x10:错误的基本请求消息类型0x11:错误的请求消息子类型0x12:格式错误的请求0x13:答复消息太大
Replies concerning sessions 0x20 : request not applicable 0x21 : lack of resources 0x22 : protocol version mismatch 0x23 : authentication failed 0x24 : no authorization 0x25 : transport protocol problem
关于会话0x20:请求不适用的答复0x21:资源不足0x22:协议版本不匹配0x23:身份验证失败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的答复：不支持事务0x41：代理未对此事务授权0x42:没有可用于此事务的资源0x43:指定的策略规则不存在0x44:指定的策略规则组不存在0x45:未授权访问指定的策略0x46:未授权访问指定的组0x47:请求的地址空间不可用0x48:缺少IP地址0x49:缺少端口号0x4A:中间盒配置失败0x4B:请求不一致0x4C:请求的通配符不受支持0x4D:协议类型不匹配0x4E:NAT模式不受支持0x4F:IP版本不匹配0x50:与现有协议冲突规则0x51:无权更改生存期0x52:无法扩展生存期0x53:非法IP地址0x54:不支持协议类型0x55:非法端口号0x56:非法后续端口数（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:（BFM）收到格式错误的消息0x02:（AST）异步会话终止0x03:（ARE）异步策略规则事件
The transaction identifier (TID) is an arbitrary number identifying the transaction. In a request message, the agent chooses an agent-unique TID, such that the same agent never uses the same TID in two different request messages belonging to the same session. Reply messages must contain the same TID as the corresponding request message. In a notification message, the middlebox chooses a
事务标识符（TID）是标识事务的任意数字。在请求消息中，代理选择代理唯一的TID，以便同一代理从不在属于同一会话的两个不同请求消息中使用相同的TID。回复消息必须包含与相应请求消息相同的TID。在通知消息中，中间盒选择
middlebox-unique TID, such that the same middlebox never uses the same TID in two different notification messages belonging to the same session.
middlebox唯一的TID，因此同一个middlebox在属于同一会话的两个不同通知消息中从不使用相同的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有效负载由零、一或多个类型长度值（TLV）属性组成。每个TLV属性都以一个16位类型字段和一个16位长度字段开始，如图3所示。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| attribute type | attribute length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
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协议版本属性的长度为四个八位字节。前两个八位字节包含版本号，一个是主版本号，另一个是次版本号。剩下的两个八位组是保留的。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|major version #|minor version #| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|major version #|minor version #| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Protocol version attribute
图4：协议版本属性
The SIMCO protocol specified within this document is version 3.0. The version numbers carried in the protocol version attribute are 3 for major version number and 0 for minor version number.
本文件中指定的SIMCO协议为3.0版。协议版本属性中携带的版本号主要版本号为3，次要版本号为0。
The authentication challenge attribute and the authentication token attribute have the same format. Both contain a single value field with variable length. For both, the maximum length is limited to 4096 octets. Please note that the length of these attributes may have values that are not multiples of 4 octets. In case of an authentication challenge attribute, the value field contains an authentication challenge sent from one peer to the other, requesting that the other peer authenticate itself.
身份验证质询属性和身份验证令牌属性具有相同的格式。两者都包含一个长度可变的单值字段。对于这两种情况，最大长度限制为4096个八位字节。请注意，这些属性的长度可能不是4个八位字节的倍数。对于身份验证质询属性，值字段包含从一个对等方发送到另一个对等方的身份验证质询，请求另一个对等方进行自身身份验证。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 | challenge length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0003 | authentication length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authentication token
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Authentication attribute
图6：身份验证属性
The middlebox capabilities attribute has a length of eight octets.
middlebox capabilities属性的长度为八个八位字节。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | 0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MB type |I|E|P|S|IIV|EIV| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max policy rule lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | 0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MB type |I|E|P|S|IIV|EIV| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max policy rule lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Capabilities attribute
图7：能力属性
The first parameter field carries a bit field called MB type and provides information about the middlebox type. The following bits within the field are defined. The remaining ones are reserved.
第一个参数字段包含一个名为MB type的位字段，并提供有关中间盒类型的信息。定义了字段中的以下位。剩下的是保留的。
0x80 : packet filter firewall 0x40 : network address translator 0x10 : support of PDR transaction 0x01 : port translation (requires 0x40 set) 0x02 : protocol translation (requires 0x40 set) 0x04 : twice NAT support (requires 0x40 set)
0x80:数据包筛选器防火墙0x40:网络地址转换器0x10:支持PDR事务0x01:端口转换（需要0x40集）0x02:协议转换（需要0x40集）0x04:两次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:
以下四个参数字段是大小为一位的二进制标志：
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版本）参数字段中。它们都有两个位的大小。对于IP版本4（IPv4），允许的值为0x1；对于IP版本6（IPv6），允许的值为0x2；对于IPv4和IPv6双堆栈，允许的值为两者的组合（0x3）。
The next parameter field with a length of 16 bits is reserved.
保留长度为16位的下一个参数字段。
The max policy rule lifetime parameter field specifies the maximum lifetime a policy rule may have.
最大策略规则生存期参数字段指定策略规则可能具有的最大生存期。
The policy rule identifier (PID) attribute contains an identifier of a policy rule. The identifier has a length of four octets.
策略规则标识符（PID）属性包含策略规则的标识符。标识符的长度为四个八位字节。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0005 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| policy rule identifier (PID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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）属性包含策略规则组的标识符。标识符的长度为四个八位字节。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group identifier (GID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0008 | owner length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| owner
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Policy rule owner attribute
图11：策略规则所有者属性
The address tuple attribute contains a set of parameters specifying IP and transport addresses. The length of this attribute is 32, 96, or 192 bits.
地址元组属性包含一组指定IP和传输地址的参数。该属性的长度为32、96或192位。
The first parameter field has a length of 4 bits. It indicates whether the contained parameters specify just the used protocols or also concrete addresses. Defined values for this field are:
第一个参数字段的长度为4位。它指示所包含的参数是仅指定所使用的协议还是指定具体的地址。此字段的定义值为：
0x0 : full addresses 0x1 : protocols only
0x0:完整地址0x1:仅协议
The second parameter field also has a length of 4 bits. It specifies the IP version number. Defined values for this field are:
第二个参数字段的长度也为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).
第三个参数字段的长度为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）在“协议编号”标签下进行维护。
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）0x02:外部（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事务。如果端口应为通配符，则address tuple属性的端口号为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 | 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 | 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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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位。它被细分为六个参数字段。
The first parameter field, called NM, has a length of 2 bits and specifies the requested NAT mode of the middlebox at which a reservation is requested. Defined values for this field are:
第一个参数字段称为NM，长度为2位，并指定请求保留的中间盒的请求NAT模式。此字段的定义值为：
01 : traditional 10 : twice
01:传统10:两次
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位。它指定请求的端口奇偶校验。此字段的定义值为：
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:any 01:IPv4 10:IPv6
The fifth parameter field has a length of 8 bits. It specifies the transport protocol for which the reservation should be made. A value of zero indicates that the reservation is requested for an IP address without specific selection of a protocol and a port number. Allowed non-zero values are the defined values for the 'protocol' field in the IPv4 header and IPv6 extension headers. The set of defined numbers for these fields is maintained by the Internet Assigned Numbers Authority (IANA) under the label 'PROTOCOL NUMBERS'.
第五个参数字段的长度为8位。它指定了应该为其进行预订的传输协议。值为零表示请求保留的IP地址没有特定的协议和端口号选择。允许的非零值是IPv4标头和IPv6扩展标头中“协议”字段的定义值。这些字段的定义编号集由互联网分配编号管理局（IANA）在“协议编号”标签下进行维护。
The sixth parameter field has a length of 16 bits. It contains an unsigned integer specifying the length of the port range that should be supported. A value of 0xFFFF indicates that the reservation should be made for all port numbers of the specified transport protocol. A port range field with the value of 0x0001 specifies that only a single port number should be reserved. Values greater than one indicate the number of consecutive port numbers to be reserved. A value of zero is not valid for this field.
第六个参数字段的长度为16位。它包含一个无符号整数，指定应支持的端口范围的长度。0xFFFF值表示应为指定传输协议的所有端口号进行保留。值为0x0001的端口范围字段指定只保留一个端口号。大于1的值表示要保留的连续端口号的数量。零的值对此字段无效。
Please note that the wildcarding value 0xFFFF can only be used in the port range field in the PRR parameter set attribute. In the address tuple attribute, wildcarding of port numbers is specified by the port number field having a value of zero (see Section 4.3.8).
请注意，通配符值0xFFFF只能在PRR参数集属性的端口范围字段中使用。在地址元组属性中，端口号的通配符由值为零的端口号字段指定（参见第4.3.8节）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000A | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NM |PP |IPi|IPo|trnsp. protocol| port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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）参数集属性包含两个参数：请求的端口奇偶校验和启用的数据流的方向。属性值字段的总大小为32位，分为3个参数字段。
The first parameter field has a length of 8 bits. It specifies the requested port parity. Defined values for this field are:
第一个参数字段的长度为8位。它指定请求的端口奇偶校验。此字段的定义值为：
0x00 : any 0x03 : same
0x00:任何0x03:相同
The second parameter field has a length of 8 bits. It specifies the direction of the enabled data stream. Defined values for this field are:
第二个参数字段的长度为8位。它指定已启用数据流的方向。此字段的定义值为：
0x01 : inbound 0x02 : outbound 0x03 : bi-directional
0x01:入站0x02:出站0x03:双向
The third parameter field has a length of 16 bits and is reserved.
第三个参数字段的长度为16位，是保留的。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000B | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port parity | direction | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000B | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port parity | direction | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PER parameter set attribute
图14：每个参数集属性
In the following, the formats of the different SIMCO message types are defined. The definitions are grouped into protocol error messages, session control messages, and policy rule control messages.
在下文中，定义了不同SIMCO消息类型的格式。这些定义分为协议错误消息、会话控制消息和策略规则控制消息。
When processing a received message, the middlebox might run into message processing problems before it can identify whether the message concerns session control or policy rule control. Also, it might not be possible to determine the message type, or it might detect a wrong message format. In these cases, the Badly Formed Message (BFM) notification or one of the following negative replies is sent:
在处理收到的消息时，在确定消息是否涉及会话控制或策略规则控制之前，中间盒可能会遇到消息处理问题。此外，可能无法确定消息类型，或者可能检测到错误的消息格式。在这些情况下，将发送格式错误的消息（BFM）通知或以下否定回复之一：
0x0401 : BFM notification 0x0310 : wrong basic request message type 0x0311 : wrong request message sub-type 0x0312 : badly formed request
0x0401:BFM通知0x0310:错误的基本请求消息类型0x0311:错误的请求消息子类型0x0312:格式错误的请求
The Badly Formed Message (BFM) notification message is sent from the middlebox to the agent after a message was received that does not comply to the SIMCO message format definition. The BFM notification has no attributes and contains the SIMCO header only.
收到不符合SIMCO消息格式定义的消息后，将从中间盒向代理发送格式错误的消息（BFM）通知消息。BFM通知没有属性，只包含SIMCO头。
+--------------------------+
| SIMCO header |
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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 request
0x0102 : SA request
0x0103 : ST request
0x0201 : SE positive reply
0x0202 : SA positive reply
0x0203 : ST positive reply
0x0310 : negative reply: wrong basic request message type
0x0311 : negative reply: wrong request message sub-type
0x0312 : negative reply: badly formed request
0x0320 : negative reply: request not applicable
0x0321 : negative reply: lack of resources
0x0322 : negative reply: protocol version mismatch
0x0323 : negative reply: authentication failed
0x0324 : negative reply: no authorization
0x0325 : negative reply: transport protocol problem
0x0326 : negative reply: security of underlying protocol layers
insufficient
0x0401 : BFM notification
0x0402 : AST notification
The Session Establishment (SE) request message is sent from the agent to the middlebox to request establishment of a session. The SE request message contains one or two attributes: a mandatory SIMCO version number attribute and an optional authentication challenge attribute requesting that the middlebox authenticate itself.
会话建立（SE）请求消息从代理发送到中间盒，以请求建立会话。SE请求消息包含一个或两个属性：一个强制的SIMCO版本号属性和一个可选的身份验证质询属性，请求中间件进行自身身份验证。
+--------------------------+
| SIMCO header |
+--------------------------+
| SIMCO protocol version |
+--------------------------+
| authentication challenge | optional
+--------------------------+
+--------------------------+
| SIMCO header |
+--------------------------+
| SIMCO protocol version |
+--------------------------+
| authentication challenge | optional
+--------------------------+
Figure 17: Structure of SE request
图17：SE请求的结构
The Session Establishment (SE) reply message indicates completion of session establishment. It contains a single mandatory attribute: the middlebox capabilities attribute.
会话建立（SE）回复消息表示会话建立完成。它包含一个强制属性：middlebox capabilities属性。
+--------------------------+
| SIMCO header |
+--------------------------+
| middlebox capabilities |
+--------------------------+
+--------------------------+
| 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.
如果代理请求middlebox身份验证，或者如果middlebox希望代理进行自身身份验证，则middlebox将使用会话身份验证（SA）回复消息而不是SE回复消息对SE请求进行回复。SA回复消息包含两个可选属性，但至少需要存在其中一个属性。第一个是身份验证质询属性，请求代理对自身进行身份验证。第二个是身份验证令牌属性，该属性将中间盒作为代理对身份验证请求的回复进行身份验证。
+--------------------------+
| SIMCO header |
+--------------------------+
| authentication challenge | optional
+--------------------------+
| authentication token | optional
+--------------------------+
+--------------------------+
| SIMCO header |
+--------------------------+
| authentication challenge | optional
+--------------------------+
| authentication token | optional
+--------------------------+
Figure 19: Structure of SA positive reply
图19：SA肯定回复的结构
The Session Authentication (SA) request message is sent from the agent to the middlebox after an initial SE request was answered by an SA reply. The SE request message contains one optional attribute: an authentication token attribute authenticating the agent as the response to an authentication challenge sent by the middlebox in an SA reply.
会话身份验证（SA）请求消息在初始SE请求得到SA回复后从代理发送到中间箱。SE请求消息包含一个可选属性：身份验证令牌属性，将代理验证为对SA应答中的中间盒发送的身份验证质询的响应。
+--------------------------+
| SIMCO header |
+--------------------------+
| authentication token | optional
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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请求，则可以从中间箱向代理发送九条不同的否定回复消息。其中三个是协议错误否定回复（0x031X），已在第4.1.2节中介绍。
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.
其余六个否定答复是针对会话建立的。其中一个是“协议版本不匹配”否定回复（0x0322），它包含一个属性：协议版本属性。
+--------------------------+
| SIMCO header |
+--------------------------+
| SIMCO protocol version |
+--------------------------+
+--------------------------+
| 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.
其余三个答复包括“请求不适用”（0x0320）、“资源不足”（0x0321）、“身份验证失败”（0x0323）、“未授权”（0x0324）、“传输协议问题”（0x0325）和“基础协议层安全性不足”（0x0326）。它们仅由SIMCO收割台组成。
+--------------------------+
| SIMCO header |
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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 request
0x0112 : PER request
0x0113 : PEA request
0x0114 : PDR request
0x0115 : PLC request
0x0121 : PRS request
0x0122 : PRL request
0x0211 : PRR positive reply
0x0212 : PER positive reply
0x0214 : PDR positive reply
0x0215 : PLC positive reply
0x0216 : PRD positive reply
0x0221 : PRS positive reply
0x0223 : PES positive reply
0x0224 : PDS positive reply
0x0222 : PRL positive reply
0x0310 : negative reply: wrong basic request message type
0x0311 : negative reply: wrong request message sub-type
0x0312 : negative reply: badly formed request
0x0340 : negative reply: transaction not supported
0x0341 : negative reply: agent not authorized for this transaction
0x0342 : negative reply: no resources available for this
transaction
0x0343 : negative reply: specified policy rule does not exist
0x0344 : negative reply: specified policy rule group does not exist
0x0345 : negative reply: not authorized for accessing this policy
0x0346 : negative reply: not authorized for accessing specified
group
0x0347 : negative reply: requested address space not available
0x0348 : negative reply: lack of IP addresses
0x0349 : negative reply: lack of port numbers
0x034A : negative reply: middlebox configuration failed
0x034B : negative reply: inconsistent request
0x034C : negative reply: requested wildcarding not supported
0x034D : negative reply: protocol type doesn't match
0x034E : negative reply: NAT mode not supported
0x034F : negative reply: IP version mismatch
0x0350 : negative reply: conflict with existing rule
0x0351 : negative reply: not authorized to change lifetime
0x0352 : negative reply: lifetime can't be extended
0x0353 : negative reply: illegal IP Address
0x0354 : negative reply: protocol type not supported
0x0355 : negative reply: illegal port number
0x0356 : negative reply: illegal NOSP
0x0357 : negative reply: already enable PID
0x0358 : negative reply: parity doesn't match
0x0401 : negative reply: BFM notification
0x0403 : negative reply: ARE notification
0x0344 : negative reply: specified policy rule group does not exist
0x0345 : negative reply: not authorized for accessing this policy
0x0346 : negative reply: not authorized for accessing specified
group
0x0347 : negative reply: requested address space not available
0x0348 : negative reply: lack of IP addresses
0x0349 : negative reply: lack of port numbers
0x034A : negative reply: middlebox configuration failed
0x034B : negative reply: inconsistent request
0x034C : negative reply: requested wildcarding not supported
0x034D : negative reply: protocol type doesn't match
0x034E : negative reply: NAT mode not supported
0x034F : negative reply: IP version mismatch
0x0350 : negative reply: conflict with existing rule
0x0351 : negative reply: not authorized to change lifetime
0x0352 : negative reply: lifetime can't be extended
0x0353 : negative reply: illegal IP Address
0x0354 : negative reply: protocol type not supported
0x0355 : negative reply: illegal port number
0x0356 : negative reply: illegal NOSP
0x0357 : negative reply: already enable PID
0x0358 : negative reply: parity doesn't match
0x0401 : negative reply: BFM notification
0x0403 : negative reply: ARE notification
SIMCO maintains an owner attribute for each policy rule at the middlebox. Depending on the configuration of the middlebox, several agents may access the same policy rule; see also [RFC3989], Sections 2.1.5 and 2.3.4.
SIMCO在中间盒中为每个策略规则维护一个所有者属性。根据中间盒的配置，多个代理可以访问相同的策略规则；另见[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）通知。当代理保留或启用策略规则时，middlebox会向所有有权访问此策略规则的代理发送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
策略保留规则（PRR）请求消息从代理发送到中间箱，以请求在中间箱保留IP地址（可能还有一系列端口号）。除了SIMCO头之外，请求消息还包含两个或三个属性。第一个是PRR parameter set属性，指定请求的所有参数（请求的策略除外）
rule lifetime and the group identifier. The missing parameters are covered by the following two attributes. The last attribute, the group identifier, is optional.
规则生存期和组标识符。缺少的参数包含在以下两个属性中。最后一个属性组标识符是可选的。
+--------------------------+
| SIMCO header |
+--------------------------+
| PRR parameter set |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| group identifier | optional
+--------------------------+
+--------------------------+
| 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头之外，请求消息还包含四个或五个属性。第一个是每个参数集属性，指定请求的所有参数，但内部地址、外部地址、请求的策略规则生存期和组标识符除外。缺少的参数包含在以下四个属性中。两个地址元组参数指定内部和外部地址元组。与PRR请求非常相似，最后两个属性指定请求的生存期和组标识符。组标识符属性是可选的。
+--------------------------+
| SIMCO header |
+--------------------------+
| PER parameter set |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| group identifier | optional
+--------------------------+
+--------------------------+
| SIMCO header |
+--------------------------+
| PER parameter set |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| group identifier | optional
+--------------------------+
Figure 24: Structure of PER request
图24：每个请求的结构
The Policy Enable rule After reservation (PEA) request message is sent from the agent to the middlebox to request enabling of data communication between an internal and an external address. It is similar to the PER request. There is just one difference. The optional group identifier attribute of the PER request is replaced by a mandatory policy rule identifier attribute referencing an already established policy reserve rule established by a PRR transaction.
保留后策略启用规则（PEA）请求消息从代理发送到中间盒，以请求启用内部和外部地址之间的数据通信。它类似于每个请求。只有一个区别。PER请求的可选组标识符属性替换为引用PRR事务建立的已建立策略保留规则的强制策略规则标识符属性。
+--------------------------+
| SIMCO header |
+--------------------------+
| PER parameter set |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| policy rule identifier |
+--------------------------+
+--------------------------+
| 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头之外，请求消息还包含两个属性，指定应用更改的策略规则，并指定请求的剩余生存期。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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）肯定回复在成功保留位于中间盒内部或外部的地址后发送。该消息包含四个必需属性和一个可选属性：新策略保留规则的策略规则标识符、相应的组标识符、策略规则的剩余生存期、保留的外部地址元组和可选的保留的内部地址元组。只有当中间盒的类型为Tworth NAT时，才会返回保留的内部地址元组。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (inside) | optional
+--------------------------+
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (inside) | optional
+--------------------------+
Figure 30: Structure of PRR positive reply
图30：PRR肯定回复的结构
The Policy Enable Rule (PER) positive reply is sent after the middlebox successfully enables data transfer between an internal and an external address (by using a PER or PEA request message). The message contains five attributes: the policy rule identifier of the new policy enable rule, the corresponding group identifier, the remaining lifetime of the policy rule, the address tuple at the outside of the middlebox, and the address tuple at the inside of the middlebox.
策略启用规则（PER）肯定回复是在中间盒成功启用内部和外部地址之间的数据传输后发送的（通过使用PER或PEA请求消息）。该消息包含五个属性：新策略启用规则的策略规则标识符、相应的组标识符、策略规则的剩余生存期、位于中间盒外部的地址元组和位于中间盒内部的地址元组。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (inside) |
+--------------------------+
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (inside) |
+--------------------------+
Figure 31: Structure of PER positive reply
图31：每个肯定答复的结构
The Policy Lifetime Change (PLC) positive reply is sent after the middlebox changes the lifetime of a policy rule to a positive (non-zero) value. The message contains just a single attribute: the remaining lifetime of the policy rule.
在中间盒将策略规则的生存期更改为正值（非零值）后，将发送策略生存期更改（PLC）肯定回复。该消息只包含一个属性：策略规则的剩余生存期。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule lifetime |
+--------------------------+
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 32: Structure of PLC positive reply
图32:PLC肯定回复的结构
The Policy Rule Deleted (PRD) positive reply is sent after the middlebox changes the remaining lifetime of a policy rule to zero, which means that it terminates the policy rule. The message consists of the SIMCO header only.
在中间盒将策略规则的剩余生存期更改为零后，将发送策略规则已删除（PRD）肯定回复，这意味着它将终止策略规则。该消息仅由SIMCO头组成。
+--------------------------+
| SIMCO header |
+--------------------------+
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 33: Structure of PRD positive reply
图33：珠三角正面答复的结构
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 |
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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）肯定回复用于报告策略禁用规则的状态。该消息包含五个属性：策略规则标识符、内部和外部地址元组、策略禁用规则生存期和策略规则所有者。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| policy rule owner |
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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）肯定答复。该消息包含两个属性：新策略禁用规则的策略规则标识符和策略规则的剩余生存期。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
+--------------------------+
| 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 |
+--------------------------+
+--------------------------+
| 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头之外，请求消息还包含两个属性，指定相关的策略规则和当前生存期。
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
+--------------------------+
| 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).
2) 中间盒等待，直到它从代理接收到消息长度加上8个八位字节（SIMCO头的长度）指定的八位字节数。
o If the middlebox is still waiting and does not receive any more octets from the agent for 60 seconds, it sends a BFM notification.
o 如果中间盒仍在等待，并且在60秒内没有从代理接收到更多的八位字节，它将发送BFM通知。
o If a session is already established, then the middlebox also sends an AST notification and closes the connection after sending the BFM notification; otherwise, it closes the connection without sending another message.
o 如果已经建立了会话，则中间件还发送AST通知，并在发送BFM通知后关闭连接；否则，它将关闭连接而不发送另一条消息。
3) After receiving a sufficient number of octets, the middlebox reads the transaction identifier and the basic message type.
3) 在收到足够数量的八位字节后，中间盒将读取事务标识符和基本消息类型。
o If the value of the basic message type fields does not equal 0x01 (request message), then the middlebox stops processing the message and sends a negative reply of type 'wrong basic request message type' (0x0310) to the agent.
o 如果基本消息类型字段的值不等于0x01（请求消息），则中间盒停止处理消息，并向代理发送类型为“错误的基本请求消息类型”（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 如果未建立会话，则只接受子类型“会话建立”（0x01）。对于所有其他子类型，中间盒向代理发送“错误请求消息子类型”（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节中定义的子类型之一。（不包括“会话建立”（0x01）、“会话终止”（0x03）和“策略规则删除”（0x15））。
o If not, then the middlebox stops processing the message and sends a reply of type 'wrong request message sub-type' (0x0311) to the agent.
o 如果没有，则中间盒停止处理消息，并向代理发送“错误请求消息子类型”（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 |<---------------+
+----------+
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
最初，所有会话都处于关闭状态。从那里，成功的SE事务可以将其状态更改为NOAUTH或OPEN。从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.
诺伊斯回到了关闭状态。成功的ST事务和AST通知将会话从NOAUTH状态或从OPEN状态更改为CLOSED状态。
A SIMCO session is established in state OPEN, which is the only state in which the middlebox accepts requests other than SE, SA, and ST.
SIMCO会话在打开状态下建立，这是中间盒接受SE、SA和ST以外请求的唯一状态。
The SE request is only applicable if the session is in state CLOSED. If a session is in state NOAUTH or OPEN, then the middlebox sends a negative reply message of type 'request not applicable' (0x0320) to the agent, leaving the state of the session unchanged.
SE请求仅在会话处于关闭状态时适用。如果会话处于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）进行了充分的身份验证，则中间箱将检查代理是否有权配置中间箱。如果不是，则中间盒返回类型为“no authorization”（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
SE请求的肯定回复可以是子类型SE或SA。在双方充分地相互验证和授权后，发送SE请求。如果任何一方请求显式身份验证，则会发送SA回复消息。代理通过向SE请求消息添加身份验证质询属性来请求显式身份验证。中间盒请求显式
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.
通过向代理返回带有身份验证质询属性的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.
如果middlebox希望代理显式地对自己进行身份验证，那么middlebox将为代理创建一个身份验证质询属性，并将其添加到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请求消息，则会话状态将从CLOSED变为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请求消息。这意味着会话状态从关闭变为打开。
The SE reply message contains a capabilities attribute describing the middlebox capabilities.
SE回复消息包含描述中间盒功能的capabilities属性。
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状态时适用。如果会话处于关闭或打开状态，则中间盒将向代理发送类型为“请求不适用”（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.
如果代理的身份验证成功，则中间盒将检查代理是否有权配置中间盒。如果没有，中间盒将返回类型为“no authorization”（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更改为OPEN，并且代理返回结束会话设置的SE回复消息。中间盒在SE回复消息中包含的capability属性中声明其功能。
The ST request is only applicable if the session is in state NOAUTH or OPEN. If a session is in state CLOSED, then the middlebox sends a negative reply message of type 'request not applicable' (0x0320) to the agent. The state of the session remains unchanged.
ST请求仅在会话处于NOAUTH或OPEN状态时适用。如果会话处于关闭状态，则中间盒将向代理发送类型为“请求不适用”（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请求。会话的状态将从打开或从NOAUTH更改为关闭。发送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
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
该图说明了PID及其相关策略的所有可能状态转换。成功的配置请求事务（PER、PRR、PEA、PLC）由请求消息的描述符、“/”符号和回复消息的描述符表示。失败的配置请求事务不会显示，因为它们不会更改PID状态。通知事务仅由通知描述符表示。例如，成功的PRR请求事务由“PRR/PRR”和ARE通知表示
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.
由“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，并将状态更改为保留。成功的PER转换将拾取处于未使用状态的PID，并将状态更改为已启用。通过成功的PEA事务，处于保留状态的PID更改为启用。在保留或未使用状态下，生存期参数大于零的成功PLC事务不会更改PID的状态。生存期参数等于零的成功PLC事务将PID的状态从保留更改为未使用或从启用更改为未使用。
A failed request transaction does not change state at the middlebox.
失败的请求事务不会更改中间盒的状态。
An ARE notification transaction with the lifetime attribute set to zero has the same effect as a successful PLC transaction with a lifetime parameter equal to zero.
寿命属性设置为零的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功能的中间盒上简单得多。因此，本节有三个子节：第一个子节描述在任何情况下执行的初始检查。第二小节描述在纯防火墙上处理PRR请求，第三小节描述在所有具有NAT功能的设备上处理PRR请求。
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.
在中间框处的后一个复选框是可选的。如果检查失败并且没有在该事务中执行，则会出现两个多余的事务。首先，代理将为每个事务发送相应的请求消息，并将收到对此的否定答复。其次，代理将发送一条生命周期设置为零的对应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请求再次执行相同的检查。如果认为处理两个以上的事务比执行两次检查消耗更少的资源，则最好不要在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 <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup.
保留，其中'lt_grated'是由中间盒选择的实际生存期，'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.
如果有更多的会话处于打开状态，且经过身份验证的代理被授权访问策略规则，则会向这些代理中的每个代理发送一个相应的are通知，其生存期设置为lt_grated。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
如果选择的生存期为零，则中间盒将向代理发送类型为“middlebox configuration failed”（0x034A）的否定回复。
If the middlebox is configured as a pure firewall, then it accepts the request after the initial checks. It establishes a new policy reserve rule and assigns to it a policy rule identifier in state RESERVED. It generates a positive PRR reply and sets the attributes as specified below. No configuration of the firewall function is required.
如果中间件配置为纯防火墙，则在初始检查后接受请求。它建立一个新的策略保留规则，并以保留状态为其分配策略规则标识符。它生成一个肯定的PRR回复，并设置如下指定的属性。不需要配置防火墙功能。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PRR reply.
为新策略规则选择的标识符将在PRR应答的策略规则标识符属性中报告。
If a group identifier attribute is contained in the PRR request, then the middlebox adds the new policy rule to the members of this group. If the PRR request does not contain a group identifier attribute, then the middlebox creates a new group with the new policy rule as the only member. In any case, the middlebox reports the group of which the new policy rule is a member in the group identifier attribute of the PRR reply.
如果PRR请求中包含组标识符属性，则中间盒会将新策略规则添加到此组的成员。如果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参数集属性中的传输协议属性相同。位置参数字段设置为“外部”（0x02）。
If the middlebox is configured as a Network Address Translator (NAT), then it tries to reserve a NAT binding.
如果将中间盒配置为网络地址转换器（NAT），则它会尝试保留NAT绑定。
The middlebox first checks the PRR parameter set further if the NM (NAT mode) parameter matches its configuration. A negative reply of type 'NAT mode not supported' (0x034E) is returned by the middlebox if the configuration is not matched.
如果NM（NAT模式）参数与其配置匹配，则中间盒首先检查设置的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.
- 传统NAT保留外部（A2）NAT绑定和请求的传输协议、外部IP版本、端口范围和端口奇偶校验。
- 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.
- 两次NAT保留外部（A2）NAT绑定和请求的传输协议、外部IP版本、端口范围和端口奇偶校验。此外，中间盒保留与请求的传输协议、内部IP版本、端口范围和端口奇偶校验的内部（A1）NAT绑定。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PRR reply.
为新策略规则选择的标识符将在PRR应答的策略规则标识符属性中报告。
After the checks are successfully performed, the middlebox establishes a new policy reserve rule, with the requested PRR parameter set, and assigns to it a policy rule identifier in state RESERVED. It generates a positive PRR reply and sets the attributes as specified below.
成功执行检查后，中间盒将建立一个新的策略保留规则，并设置请求的PRR参数，并为其分配一个处于保留状态的策略规则标识符。它生成一个肯定的PRR回复，并设置如下指定的属性。
If a group identifier attribute is contained in the PRR request, then the middlebox adds the new policy rule to the members of this group. If the PRR request does not contain a group identifier attribute, then the middlebox creates a new group with the new policy rule as the only member. In any case, the middlebox reports the group of which the new policy rule is a member in the group identifier attribute of the PRR reply.
如果PRR请求中包含组标识符属性，则中间盒会将新策略规则添加到此组的成员。如果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
在PRR应答的地址元组（外部）属性中，第一个参数字段设置为“完整地址”（0x0）。位置参数字段设置为“外部”（0x02）。IP版本参数
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请求消息的PRR parameter set属性中的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 parameter set属性中的NM（NAT模式）参数的值为“传统”，则PRR回复消息不包含地址元组（内部）属性。否则（其值为“tweeps”），则PRR回复消息包含一个地址元组（内部）属性。在PRR应答的地址元组（内部）属性中，第一个参数字段设置为“完整地址”（0x0）。位置参数字段设置为“内部”（0x01）。IP版本参数字段根据PRR请求消息的PRR参数集属性中的IPi参数字段设置。对于IPv4地址，前缀长度字段设置为0x20以表示完整地址，保留的内部IPv4地址在地址字段中设置。对于IPv6地址，前缀长度字段设置为0x80以指示完整地址，保留的IPv6内部地址在地址字段中设置。PRR应答的地址元组（内部）属性中的传输协议参数字段的设置与PRR请求消息的PRR参数集属性中的传输协议属性相同。保留的内部基本端口号（即分配范围的最低端口号）存储在端口号参数字段中，分配的端口范围存储在端口范围参数字段中。
Processing PER requests is much simpler on pure firewalls than on middleboxes with NAT functions. Therefore, this section has three sub-sections: The first one describes initial checks that are performed in any case. The second sub-section describes processing of PER requests on pure firewalls, and the third one describes processing on all devices with NAT functions.
在纯防火墙上处理每个请求比在具有NAT功能的中间盒上要简单得多。因此，本节有三个子节：第一个子节描述在任何情况下执行的初始检查。第二小节描述在纯防火墙上处理PER请求，第三小节描述在所有具有NAT功能的设备上处理PER请求。
When a middlebox receives a PER request message, it first checks if the authenticated agent is authorized for requesting middlebox configurations for enabling communication. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
当一个中间箱收到每请求一条消息时，它首先检查经过身份验证的代理是否被授权请求中间箱配置以启用通信。如果没有，则返回类型为“代理未对此事务授权”的否定回复消息（0x0341）。
If the request contains the optional group identifier, then the middlebox checks if the group already exists. If not, the middlebox returns a negative reply message of type 'specified policy rule group does not exist' (0x0344).
如果请求包含可选的组标识符，则中间盒将检查该组是否已存在。如果不存在，则中间盒将返回类型为“指定的策略规则组不存在”（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).
如果第一个未将位置参数字段设置为“内部”（0x00），或者第二个未将位置参数字段设置为“外部”（0x03），则中间盒将返回类型为“不一致请求”（0x034B）的否定回复消息。
If the transport protocol parameter field does not have the same value in both address tuple attributes, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
如果传输协议参数字段在两个地址元组属性中的值不相同，则中间盒将返回“不一致请求”（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).
如果每个参数集属性中的方向参数字段的值为“双向”，则只允许传输协议通配符。如果在一个或两个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).
如果每个请求与任何策略禁用规则冲突（请参阅第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
在检查地址元组属性后，middlebox将为要创建的新策略规则选择一个生存期值，该值大于或等于零，小于或等于请求值的最小值和会话设置时middlebox capabilities属性指定的最大生存期。在形式上，生命周期的选择应确保
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup.
保留，其中'lt_grated'是由中间盒选择的实际生存期，'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.
如果有更多的会话处于打开状态，且经过身份验证的代理被授权访问策略规则，则会向这些代理中的每个代理发送一个相应的are通知，其生存期设置为lt_grated。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
如果选择的生存期为零，则中间盒将向代理发送类型为“middlebox configuration failed”（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).
如果中间包充当纯防火墙，则它会尝试配置请求的针孔。防火墙配置忽略每个参数集属性中的端口奇偶校验参数字段，但会考虑此属性中的方向参数字段。针孔的配置使指定的内部和外部地址元组之间的通信在指定方向上启用，并覆盖指定的通配符。如果配置失败（例如，因为针孔会与高级防火墙策略冲突），则中间盒将返回类型为“middlebox configuration failed”（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.
如果配置成功，则中间盒将建立新的策略启用规则，并为其分配处于启用状态的策略规则标识符。它会为每个回复生成一个肯定值，并设置以下指定的属性。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
为新策略规则选择的标识符将在每个答复的策略规则标识符属性中报告。
If a group identifier attribute is contained in the PER request, then the middlebox adds the new policy rule to the members of this group. If the PRR request does not contain a group identifier attribute, then the middlebox creates a new group with the new policy rule as
如果每个请求中包含组标识符属性，则中间盒会将新策略规则添加到此组的成员。如果PRR请求不包含组标识符属性，则中间盒将使用新策略规则创建一个新组，如下所示：
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.
唯一的成员。在任何情况下，中间盒都会在每个回复的“组标识符”属性中报告新策略规则所属的组。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
选择的生存期将在每个回复的生存期属性中报告。
The address tuple (internal) attribute of the PER request is reported as address tuple (outside) attribute of the PER reply. The address tuple (external) attribute of the PER request is reported as address tuple (inside) attribute of the PER reply.
每个请求的地址元组（内部）属性报告为每个应答的地址元组（外部）属性。每个请求的地址元组（外部）属性报告为每个应答的地址元组（内部）属性。
If the middlebox is configured as a NAT, then it tries to configure the requested NAT binding. The actions taken by the NAT are quite similar to the actions of the Policy Reserve Rule (PRR) request, but in the PER request a NAT binding is enabled.
如果将中间盒配置为NAT，则它将尝试配置请求的NAT绑定。NAT执行的操作与策略保留规则（PRR）请求的操作非常相似，但在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 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使用请求的传输协议、端口范围和端口奇偶校验在内部和外部地址元组之间建立NAT绑定。但是创建了两个地址元组：外部地址元组和内部地址元组。
Should the configuration fail in either NAT case, a negative reply 'middlebox configuration failed' (0x034A) is returned.
如果在任何一种NAT情况下配置失败，将返回否定回复“middlebox configuration failed”（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.
如果配置成功，则中间盒将建立新的策略启用规则，并为其分配处于启用状态的策略规则标识符。它会为每个回复生成一个肯定值，并设置以下指定的属性。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
为新策略规则选择的标识符将在每个答复的策略规则标识符属性中报告。
If a group identifier attribute is contained in the PER request, then the middlebox adds the new policy rule to the members of this group. If the PRR request does not contain a group identifier attribute,
如果每个请求中包含组标识符属性，则中间盒会将新策略规则添加到此组的成员。如果PRR请求不包含组标识符属性，
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.
然后，中间盒创建一个新组，其中新策略规则是唯一的成员。在任何情况下，中间盒都会在每个回复的“组标识符”属性中报告新策略规则所属的组。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
选择的生存期将在每个回复的生存期属性中报告。
In the address tuple (outside) attribute of the PER reply, the first parameter field is set to 'full addresses' (0x0). The location parameter field is set to 'outside' (0x02). The IP version parameter field is set according to the IP version parameter field in the PER parameter set attribute of the PER request message. For IPv4 addresses, the prefix length field is set to 0x20 to indicate a full address, and the reserved outside IPv4 address is set in the address field. For IPv6 addresses, the prefix length field is set to 0x80 to indicate a full address, and the reserved outside IPv6 address is set in the address field. The transport protocol parameter field in the address tuple (outside) attribute of the PER reply is set identically to the transport protocol attribute in the PER parameter set attribute of the PER request message. The reserved outside base port number (i.e., the lowest port number of the allocated range) is stored in the port number parameter field, and the allocated port range is stored in the port range parameter field.
在每个回复的地址元组（外部）属性中，第一个参数字段设置为“完整地址”（0x0）。位置参数字段设置为“外部”（0x02）。IP版本参数字段是根据每请求消息的每参数集属性中的IP版本参数字段设置的。对于IPv4地址，前缀长度字段设置为0x20以指示完整地址，保留的IPv4外部地址在地址字段中设置。对于IPv6地址，前缀长度字段设置为0x80以指示完整地址，保留的IPv6外部地址在地址字段中设置。每个回复的地址元组（外部）属性中的传输协议参数字段的设置与每个请求消息的每个参数集属性中的传输协议属性相同。保留的外部基本端口号（即分配范围的最低端口号）存储在端口号参数字段中，分配的端口范围存储在端口范围参数字段中。
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时，才会返回地址元组（内部）；否则，省略它。在每个回复的地址元组（内部）属性中，第一个参数字段设置为“完整地址”（0x0）。位置参数字段设置为“内部”（0x01）。IP版本参数字段是根据每请求消息的每参数集属性中的IP版本参数字段设置的。对于IPv4地址，前缀长度字段设置为0x20以表示完整地址，保留的内部IPv4地址在地址字段中设置。对于IPv6地址，前缀长度字段设置为0x80以指示完整地址，保留的IPv6内部地址在地址字段中设置。每个回复的地址元组（内部）属性中的传输协议参数字段的设置与每个请求消息的每个参数集属性中的传输协议属性相同。保留的内部基本端口号（即分配范围的最低端口号）存储在端口号参数字段中，分配的端口范围存储在端口范围参数字段中。
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绑定，然后配置防火墙针孔。由于防火墙规则必须根据外部地址元组进行配置，并且对于两次NAT，也必须根据内部地址元组进行配置，因此需要此序列。中间箱操作的这一方面可能与SIMCO无关，因为一些NAT已经自己进行防火墙配置。
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功能的中间盒上要简单得多。因此，本节有三个子节：第一个子节描述在任何情况下执行的初始检查。第二小节描述在纯防火墙上处理PEA请求，第三小节描述在所有具有NAT功能的设备上处理PEA请求。
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).
如果第一个未将位置参数字段设置为“内部”（0x00），或者第二个未将位置参数字段设置为“外部”（0x03），则中间盒返回类型为“不一致请求”（0x034B）的否定回复消息。
If the transport protocol parameter field does not have the same value in both address tuple attributes, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
如果传输协议参数字段在两个地址元组属性中的值不相同，则中间盒将返回“不一致请求”（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，则传输协议完全为通配符。请注意，完全通配符的传输协议可能仍然只支持有限的传输协议集，具体取决于中间盒的功能。例如，典型的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
在检查地址元组属性后，middlebox将为要创建的新策略启用规则选择一个生存期值，该值大于或等于零，小于或等于请求值的最小值和会话设置时middlebox capabilities属性指定的最大生存期。在形式上，生命周期的选择应确保
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup.
保留，其中'lt_grated'是由中间盒选择的实际生存期，'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.
如果有更多的会话处于打开状态，且经过身份验证的代理被授权访问策略规则，则会向这些代理中的每个代理发送一个相应的are通知，其生存期设置为lt_grated。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
如果选择的生存期为零，则中间盒将向代理发送类型为“middlebox configuration failed”（0x034A）的否定回复。
If the middlebox is configured as a pure firewall, then it tries to configure the requested pinhole. The firewall configuration ignores the port parity parameter field in the PER parameter set attribute, but it considers the direction parameter field in this attribute. The pinhole is configured such that communication between the specified internal and external address tuples is enabled in the specified direction and covering the specified wildcarding. If the configuration fails, then the middlebox returns a negative reply message of type 'middlebox configuration failed' (0x034A).
如果中间件配置为纯防火墙，则它会尝试配置请求的针孔。防火墙配置忽略每个参数集属性中的端口奇偶校验参数字段，但会考虑此属性中的方向参数字段。针孔的配置使指定的内部和外部地址元组之间的通信在指定方向上启用，并覆盖指定的通配符。如果配置失败，则中间盒返回类型为“middlebox configuration failed”（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
如果配置成功，则中间盒将使用新的策略启用规则替换PEA请求消息中策略规则标识符属性引用的策略保留规则。策略启用规则重新使用替换的策略保留规则的策略规则标识符。政策规则的状态
identifier changes from RESERVED to ENABLED. The policy reserve rule is a member of the same group as the replaced policy reserve rule was.
标识符从保留更改为启用。策略保留规则与替换的策略保留规则是同一组的成员。
Then the middlebox generates a positive PER reply and sets the attributes as specified below.
然后，中间盒生成一个肯定的每个回复，并设置如下指定的属性。
The identifier chosen for the new policy rule is reported in the policy rule identifier attribute of the PER reply.
为新策略规则选择的标识符将在每个答复的策略规则标识符属性中报告。
The group identifier is reported in the group identifier attribute of the PER reply.
组标识符在每个回复的组标识符属性中报告。
The chosen lifetime is reported in the lifetime attribute of the PER reply.
选择的生存期将在每个回复的生存期属性中报告。
The address tuple (internal) attribute of the PER request is reported as the address tuple (outside) attribute of the PER reply. The address tuple (external) attribute of the PER request is reported as the address tuple (inside) attribute of the PER reply.
每个请求的地址元组（内部）属性报告为每个回复的地址元组（外部）属性。每个请求的地址元组（外部）属性报告为每个回复的地址元组（内部）属性。
If the middlebox is configured as a NAT, then it tries to configure the requested NAT binding, i.e., enabling the already reserved binding. The already reserved NAT binding from the PRR request is now enabled in the middlebox.
如果中间件配置为NAT，则它会尝试配置请求的NAT绑定，即启用已保留的绑定。来自PRR请求的已保留NAT绑定现在在中间盒中启用。
If the enable configuration was successful, the middlebox replaces the policy reserve rule referenced by the policy rule identifier attribute in the PEA request message with a new policy enable rule. The policy enable rule re-uses the policy rule identifier of the replaced policy reserve rule. The state of the policy rule identifier changes from RESERVED to ENABLED. The policy reserve rule is a member of the same group as the replaced policy reserve rule was.
如果启用配置成功，则中间盒将使用新的策略启用规则替换PEA请求消息中策略规则标识符属性引用的策略保留规则。策略启用规则重新使用替换的策略保留规则的策略规则标识符。策略规则标识符的状态从保留更改为启用。策略保留规则与替换的策略保留规则是同一组的成员。
Then the middlebox generates a positive PER reply and sets the attributes as specified below.
然后，中间盒生成一个肯定的每个回复，并设置如下指定的属性。
The reserved outside address tuple is reported as the address tuple (outside) attribute of the PER reply. The reserved inside address tuple is reported as the address tuple (inside) attribute of the PER reply. Both reserved outside and inside address tuples are taken from the reserve policy rule generated during the PRR transaction.
保留的外部地址元组报告为每个回复的地址元组（外部）属性。保留的内部地址元组报告为每个回复的地址元组（内部）属性。保留的外部和内部地址元组均取自PRR事务期间生成的保留策略规则。
When a middlebox receives a PLC request message, it first checks if the authenticated agent is authorized for requesting policy rule lifetime changes. If not, it returns a negative reply message of type 'agent not authorized for this transaction' (0x0341).
当中间盒收到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
然后，middlebox为新策略规则选择一个生存期值，该值大于零，小于或等于请求值的最小值和会话设置时middlebox capabilities属性指定的最大生存期。在形式上，生命周期的选择应确保
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup. This procedure implies that the chosen lifetime is zero if the requested lifetime is zero.
保留，其中'lt_grated'是由中间盒选择的实际生存期，'lt_requested'是代理请求的生存期，'lt_maximum'是在会话设置时的能力交换期间指定的最大生存期。此过程意味着，如果请求的生存期为零，则选择的生存期为零。
If the chosen lifetime is greater than zero, the middlebox changes the lifetime of the policy rule to the chosen value and generates a PLC reply message. The chosen lifetime is reported in the lifetime attribute of the message.
如果选择的生存期大于零，则中间盒将策略规则的生存期更改为选择的值，并生成PLC回复消息。选择的生存期将在消息的生存期属性中报告。
If otherwise (the chosen lifetime is zero), then the middlebox terminates the policy rule and changes the PID state from ENABLED or RESERVED, respectively, to UNUSED.
否则（选择的生存期为零），则中间盒终止策略规则，并将PID状态分别从启用或保留更改为未使用。
The middlebox generates a PRD reply message and sends it to the requesting agent. If there are further sessions in state OPEN with authenticated agents authorized to access the policy rule, then to each of these agents a corresponding ARE notification with lifetime set to zero is sent.
中间盒生成PRD回复消息并将其发送给请求代理。如果有更多的会话处于打开状态，且经过身份验证的代理被授权访问策略规则，则会向这些代理中的每个代理发送一个相应的are通知，其生存期设置为零。
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.
如果上述检查通过，则中间盒接受请求并生成回复。如果请求状态信息的策略规则处于保留状态，则生成PRS回复并发送给代理。否则（策略规则处于启用状态），则生成PES回复并发送给代理。对于策略禁用规则，将生成PDS回复并发送给代理。
In both message formats, the lifetime attribute reports the current remaining lifetime of the policy rule, and the owner attribute reports the owner of the policy rule for which status information is requested.
在这两种消息格式中，lifetime属性报告策略规则的当前剩余生存期，owner属性报告请求状态信息的策略规则的所有者。
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请求的相应属性的值完全相同。
In the PES reply message, the policy rule identifier attribute, the group identifier attribute, the address tuple (inside) attribute, and the address tuple (outside) attribute have exactly the same values as the corresponding attributes of the PER reply that was sent as part of the PER or PEA transaction that established the policy enable rule.
在PES回复消息中，策略规则标识符属性、组标识符属性、地址元组（内部）属性和地址元组（外部）属性的值与作为建立策略启用规则的PER或PEA事务的一部分发送的PER回复的相应属性的值完全相同。
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消息的最大长度，则会生成类型为“reply message to big”（0x0313）的否定回复消息。SIMCO消息的总大小限制为总共65536个八位字节（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请求的处理分为五个子部分。第一个描述了通过PDR对MIDCOM协议语义的一般扩展。第二小节描述了在任何情况下执行的初始检查。第三小节描述在纯防火墙上处理PDR请求。第四个描述使用NAT的设备上的处理，第五个描述使用组合防火墙和NAT功能的设备的处理。
The Policy Disable Rule (PDR) extends the MIDCOM protocol semantics [RFC3989] by another policy rule type. The PDR is intended to be used for dynamically blocking unwanted traffic, particularly in case of an attack, for example, a distributed denial of service attack.
策略禁用规则（PDR）通过另一种策略规则类型扩展了MIDCOM协议语义[RFC3989]。PDR旨在用于动态阻止不需要的流量，特别是在发生攻击（例如，分布式拒绝服务攻击）的情况下。
PDR requests follow the same ownership concept as all other transactions do (see [RFC3989], Section 2.1.5). However, PDR prioritization over PERs is independent of ownership. A PDR always overrules a conflicting PER, even if the respective owners are different. Typically, only a highly privileged agent will be allowed to issue PDR requests.
PDR请求遵循与所有其他事务相同的所有权概念（参见[RFC3989]，第2.1.5节）。然而，PDR优先于PER独立于所有权。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规则的地址元组重叠，则PDR规则和PER规则彼此冲突，从而存在至少一个IP数据包，该IP数据包与内部网络中两个规则的地址元组A0相匹配，并且与外部网络中两个规则的地址元组A3相匹配。注意，分组可以从内部网络转换为外部网络，或者反之亦然。
Let's assume, for instance, that a policy enable rule (PER) enables all traffic from any external host using any UDP port to a certain UDP port of a certain internal host:
例如，让我们假设策略启用规则（PER）启用从任何外部主机使用任何UDP端口到某个内部主机的某个UDP端口的所有流量：
PER A3={ any external IP address, UDP, any port }
PER A0={ internal IP address 10.1.8.3, UDP, port 12345 }
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 }
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，则所有冲突的PER将立即终止。只有当新PER与任何现有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).
如果第一个未将位置参数字段设置为“内部”（0x00），或者第二个未将位置参数字段设置为“外部”（0x03），则中间盒将返回类型为“不一致请求”（0x034B）的否定回复消息。
If the transport protocol parameter field does not have the same value in both address tuple attributes, then the middlebox returns a negative reply message of type 'inconsistent request' (0x034B).
如果传输协议参数字段在两个地址元组属性中的值不相同，则中间盒将返回“不一致请求”（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节。具有要终止的策略规则访问权限的打开会话的代理将通过are通知进行通知。
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
在检查地址元组属性后，middlebox将为要创建的新策略规则选择一个生存期值，该值大于或等于零，小于或等于请求值的最小值和会话设置时middlebox capabilities属性指定的最大生存期。在形式上，生命周期的选择应确保
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
holds, where 'lt_granted' is the actual lifetime chosen by the middlebox, 'lt_requested' is the lifetime requested by the agent, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup.
保留，其中'lt_grated'是由中间盒选择的实际生存期，'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.
如果有更多的会话处于打开状态，且经过身份验证的代理被授权访问策略规则，则会向这些代理中的每个代理发送一个相应的are通知，其生存期设置为lt_grated。
If the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) to the agent.
如果选择的生存期为零，则中间盒将向代理发送类型为“middlebox configuration failed”（0x034A）的否定回复。
If the middlebox is acting as a pure firewall, then it tries to configure the requested disable rule, i.e., configuring a blocking rule at the firewall. The disable rule is configured such that communication between the specified internal and external address tuples is blocked, covering the specified wildcarding. If the configuration fails (for example, because the blocking rule would conflict with high-level firewall policies), then the middlebox returns a negative reply message of type 'middlebox configuration failed' (0x034A).
如果中间包充当纯防火墙，则它会尝试配置请求的禁用规则，即在防火墙上配置阻止规则。禁用规则配置为阻止指定的内部和外部地址元组之间的通信，覆盖指定的通配符。如果配置失败（例如，因为阻止规则将与高级防火墙策略冲突），则中间盒将返回“middlebox configuration failed”（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情况下配置失败，将返回否定回复“middlebox configuration failed”（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配置为阻止地址元组。中间箱操作的这一方面可能与SIMCO无关，因为一些NAT已经自己进行防火墙配置。
At any time, the middlebox may terminate a policy rule by deleting the configuration of the rule and by changing the corresponding PID state from ENABLED or from RESERVED, respectively, to UNUSED.
在任何时候，通过删除规则的配置并将相应的PID状态分别从ENABLED（启用）或RESERVED（保留）更改为UNUSED（未使用），中间件都可以终止策略规则。
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.
对于具有授权访问策略规则的经过身份验证的代理的处于打开状态的每个会话，middlebox将生成一个相应的ARE通知，其生存期属性设置为零，并将其发送给相应的代理。在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.
发送通知后，MealBox将考虑不存在策略规则。它将不会处理此策略规则的任何进一步交易。
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通知是为每个处于打开状态的会话生成的，该会话具有授权访问策略规则的已验证代理（请求代理除外）。通过此通知，所有其他代理将与策略规则的最新状态保持同步。
Middleboxes, such as firewalls and NATs, are usually operated for improving the network security and for extending the IP address space (note that stand-alone NATs are not considered to improve security; see [RFC2663]). The configuration of middleboxes from an external entity looks quite counterproductive on the first glimpse, since an attacker using this can possibly configure the middlebox in such way that no filtering is applied anymore or that NAT bindings are configured for malicious use. So the middlebox is not performing the intended function anymore. Possible threats to SIMCO are:
防火墙和NAT等中间盒通常用于提高网络安全性和扩展IP地址空间（请注意，独立NAT不被视为提高安全性；请参见[RFC2663]）。从外部实体配置的中间箱在第一眼看到时看起来会适得其反，因为使用此配置的攻击者可能会以这样的方式配置中间箱，即不再应用过滤或将NAT绑定配置为恶意使用。因此，中间盒不再执行预期功能。SIMCO可能面临的威胁有：
- Man-in-the-middle attack A malicious host intercepts messages exchanged between then SIMCO agent and middlebox and can change the content of the messages on the fly. This man-in-the-middle attack would result, from the agent's view, in a proper middlebox configuration, but the middlebox would not be configured accordingly. The man in the middlebox could open pinholes that compromise the protected network's security.
- 中间人攻击恶意主机拦截SIMCO agent和middlebox之间交换的消息，并可以动态更改消息内容。从代理的角度来看，这种中间人攻击将导致正确的中间箱配置，但不会相应地配置中间箱。中间人可能会打开针孔，危及受保护网络的安全。
- Changing content The message content could be changed in such a way that the requested policy rule configuration is not configured in the middlebox, but that any other unwanted configuration could be. That way, an attacker can open the firewall for his own traffic.
- 更改内容消息内容的更改方式可以使请求的策略规则配置不在中间盒中配置，但可以更改任何其他不需要的配置。这样，攻击者就可以为自己的流量打开防火墙。
- Replaying Already sent messages could be re-sent in order to configure the middlebox in such a way that hosts could configure policy rules without the permission of an application-level gateway or system administrator.
- 可以重新发送重播已发送的消息，以便以这样一种方式配置中间盒：主机可以在未经应用程序级网关或系统管理员许可的情况下配置策略规则。
- Wiretapping An already configured policy rule could be re-used by other hosts if the policy rule is configured with too broad a wildcarding (see below). These hosts could send unwanted traffic.
- 如果策略规则配置的通配符太宽（请参见下文），则对已配置的策略规则进行窃听可能会被其他主机重复使用。这些主机可能会发送不需要的流量。
The previous subsection identifies several issues on security for SIMCO. SIMCO can rely on IPsec mechanisms, as defined in [RFC4302] and [RFC4303], for ensuring proper operations.
上一小节确定了SIMCO的几个安全问题。SIMCO可以依靠[RFC4302]和[RFC4303]中定义的IPsec机制来确保正确的操作。
When SIMCO relies on IPsec, it uses IPsec in transport mode with an authentication header (AH) [RFC4302] and an encapsulating security payload (ESP) [RFC4303], so that IP traffic between SIMCO agent and middlebox is protected. The authentication header is used for protecting the whole packet against content changes and replaying. The ESP header is used to prevent wiretapping.
当SIMCO依赖IPsec时，它在传输模式下使用IPsec，带有身份验证头（AH）[RFC4302]和封装安全有效负载（ESP）[RFC4303]，因此SIMCO代理和middlebox之间的IP通信受到保护。身份验证头用于保护整个数据包不受内容更改和重播的影响。ESP割台用于防止窃听。
At either the agent or middlebox side, the following should be pre-configured: the IP addresses of the agent or middlebox, TCP (as the transport protocol), and the port numbers (if possible). Only packets from the pre-configured address of the agents or middlebox should be accepted.
在代理或中间盒端，应预先配置以下内容：代理或中间盒的IP地址、TCP（作为传输协议）和端口号（如果可能）。只接受来自预配置的代理或中间盒地址的数据包。
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 agent和middlebox的身份验证密钥都在每一侧预先配置。对于重播保护，建议使用密钥管理系统。有关Internet密钥交换（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).
[RFC3424]将单边自地址修复（UNSAF）描述为原始端点处的一个过程，试图确定或修复另一个端点已知的地址（和端口）。UNSAF的提案，如STUN[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.
作者要感谢Sebastian Kiesel和Andreas Mueller从SIMCO实施中获得的宝贵反馈，并感谢Mary Barnes对文件进行的全面审查。
[RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 3989, February 2005.
[RFC3989]Stieemerling，M.，Quittek，J.，和T.Taylor，“中间盒通信（MIDCOM）协议语义”，RFC 3989，2005年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，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]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519]Fuller，V.，Li，T.，Yu，J.，和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303]Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.，和A.Rayhan，“中间箱通信架构和框架”，RFC 33032002年8月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932]Alvestrand，H.，“IESG和RFC编辑文件：程序”，BCP 92，RFC 3932，2004年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
Authors' Addresses
作者地址
Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Kurfuersten-Anlage 36 69115 Heidelberg Germany
Martin Stieemerling NEC欧洲有限公司欧洲网络实验室Kurfuersten Anlage 36 69115德国海德堡
Phone: +49 6221 4342-113
EMail: stiemerling@netlab.nec.de
Phone: +49 6221 4342-113
EMail: stiemerling@netlab.nec.de
Juergen Quittek NEC Europe Ltd. Network Laboratories Europe Kurfuersten-Anlage 36 69115 Heidelberg Germany
Juergen Quittek NEC欧洲有限公司欧洲网络实验室Kurfuersten Anlage 36 69115德国海德堡
Phone: +49 6221 4342-115
EMail: quittek@netlab.nec.de
Phone: +49 6221 4342-115
EMail: quittek@netlab.nec.de
Cristian Cadar Muelheimer Strasse 23 40239 Duesseldorf Germany
克里斯蒂安·卡达尔·穆尔海默大街23 40239杜塞尔多夫德国
EMail: ccadar2@yahoo.com
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。