Network Working Group E. Boschi
Request for Comments: 5153 Hitachi Europe
Category: Informational L. Mark
Fraunhofer FOKUS
J. Quittek
M. Stiemerling
NEC
P. Aitken
Cisco Systems, Inc.
April 2008
Network Working Group E. Boschi
Request for Comments: 5153 Hitachi Europe
Category: Informational L. Mark
Fraunhofer FOKUS
J. Quittek
M. Stiemerling
NEC
P. Aitken
Cisco Systems, Inc.
April 2008
IP Flow Information Export (IPFIX) Implementation Guidelines
IP流信息导出（IPFIX）实施指南
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.).
IP流信息导出（IPFIX）协议定义了如何从路由器、测量探头或其他设备导出IP流信息。本文档提供了IPFIX协议的实施和使用指南。几套指导原则解决了模板管理、传输特定问题、导出和收集过程的实施以及中间盒（如防火墙、网络地址转换器、隧道端点、数据包分类器等）上的IPFIX实施。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3
1.2. Overview of the IPFIX Protocol . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Template Management Guidelines . . . . . . . . . . . . . . . . 4
3.1. Template Management . . . . . . . . . . . . . . . . . . . 4
3.2. Template Records versus Options Template Records . . . . . 5
3.3. Using Scopes . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Multiple Information Elements of the Same Type . . . . . . 6
3.5. Selecting Message Size . . . . . . . . . . . . . . . . . . 6
4. Exporting Process Guidelines . . . . . . . . . . . . . . . . . 7
4.1. Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Information Element Coding . . . . . . . . . . . . . . . . 7
4.3. Using Counters . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3
1.2. Overview of the IPFIX Protocol . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Template Management Guidelines . . . . . . . . . . . . . . . . 4
3.1. Template Management . . . . . . . . . . . . . . . . . . . 4
3.2. Template Records versus Options Template Records . . . . . 5
3.3. Using Scopes . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Multiple Information Elements of the Same Type . . . . . . 6
3.5. Selecting Message Size . . . . . . . . . . . . . . . . . . 6
4. Exporting Process Guidelines . . . . . . . . . . . . . . . . . 7
4.1. Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Information Element Coding . . . . . . . . . . . . . . . . 7
4.3. Using Counters . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.1. Alignment of Information Elements within a Data
Record . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Alignment of Information Element Specifiers within
a Template Record . . . . . . . . . . . . . . . . . . 9
4.4.3. Alignment of Records within a Set . . . . . . . . . . 9
4.4.4. Alignment of Sets within an IPFIX Message . . . . . . 9
4.5. Time Issues . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. IPFIX Message Header Export Time and Data Record Time . . 10
4.7. Devices without an Absolute Clock . . . . . . . . . . . . 11
5. Collecting Process Guidelines . . . . . . . . . . . . . . . . 11
5.1. Information Element (De)Coding . . . . . . . . . . . . . . 11
5.2. Reduced-Size Encoding of Information Elements . . . . . . 12
5.3. Template Management . . . . . . . . . . . . . . . . . . . 12
6. Transport-Specific Guidelines . . . . . . . . . . . . . . . . 12
6.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Guidelines for Implementation on Middleboxes . . . . . . . . . 18
7.1. Traffic Flow Scenarios at Middleboxes . . . . . . . . . . 20
7.2. Location of the Observation Point . . . . . . . . . . . . 21
7.3. Reporting Flow-Related Middlebox Internals . . . . . . . . 22
7.3.1. Packet Dropping Middleboxes . . . . . . . . . . . . . 23
7.3.2. Middleboxes Changing the DSCP . . . . . . . . . . . . 23
7.3.3. Middleboxes Changing IP Addresses and Port Numbers . . 24
8. Security Guidelines . . . . . . . . . . . . . . . . . . . . . 25
8.1. Introduction to TLS and DTLS for IPFIX Implementers . . . 25
8.2. X.509-Based Identity Verification for IPFIX over TLS
or DTLS . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Implementing IPFIX over TLS over TCP . . . . . . . . . . . 26
8.4. Implementing IPFIX over DTLS over UDP . . . . . . . . . . 26
8.5. Implementing IPFIX over DTLS over SCTP . . . . . . . . . . 27
9. Extending the Information Model . . . . . . . . . . . . . . . 27
9.1. Adding New IETF-Specified Information Elements . . . . . . 27
9.2. Adding Enterprise-Specific Information Elements . . . . . 28
10. Common Implementation Mistakes . . . . . . . . . . . . . . . . 28
10.1. IPFIX and NetFlow Version 9 . . . . . . . . . . . . . . . 28
10.2. Padding of the Data Set . . . . . . . . . . . . . . . . . 29
10.3. Field ID Numbers . . . . . . . . . . . . . . . . . . . . . 30
10.4. Template ID Numbers . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . . 31
4.4.1. Alignment of Information Elements within a Data
Record . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Alignment of Information Element Specifiers within
a Template Record . . . . . . . . . . . . . . . . . . 9
4.4.3. Alignment of Records within a Set . . . . . . . . . . 9
4.4.4. Alignment of Sets within an IPFIX Message . . . . . . 9
4.5. Time Issues . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. IPFIX Message Header Export Time and Data Record Time . . 10
4.7. Devices without an Absolute Clock . . . . . . . . . . . . 11
5. Collecting Process Guidelines . . . . . . . . . . . . . . . . 11
5.1. Information Element (De)Coding . . . . . . . . . . . . . . 11
5.2. Reduced-Size Encoding of Information Elements . . . . . . 12
5.3. Template Management . . . . . . . . . . . . . . . . . . . 12
6. Transport-Specific Guidelines . . . . . . . . . . . . . . . . 12
6.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Guidelines for Implementation on Middleboxes . . . . . . . . . 18
7.1. Traffic Flow Scenarios at Middleboxes . . . . . . . . . . 20
7.2. Location of the Observation Point . . . . . . . . . . . . 21
7.3. Reporting Flow-Related Middlebox Internals . . . . . . . . 22
7.3.1. Packet Dropping Middleboxes . . . . . . . . . . . . . 23
7.3.2. Middleboxes Changing the DSCP . . . . . . . . . . . . 23
7.3.3. Middleboxes Changing IP Addresses and Port Numbers . . 24
8. Security Guidelines . . . . . . . . . . . . . . . . . . . . . 25
8.1. Introduction to TLS and DTLS for IPFIX Implementers . . . 25
8.2. X.509-Based Identity Verification for IPFIX over TLS
or DTLS . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Implementing IPFIX over TLS over TCP . . . . . . . . . . . 26
8.4. Implementing IPFIX over DTLS over UDP . . . . . . . . . . 26
8.5. Implementing IPFIX over DTLS over SCTP . . . . . . . . . . 27
9. Extending the Information Model . . . . . . . . . . . . . . . 27
9.1. Adding New IETF-Specified Information Elements . . . . . . 27
9.2. Adding Enterprise-Specific Information Elements . . . . . 28
10. Common Implementation Mistakes . . . . . . . . . . . . . . . . 28
10.1. IPFIX and NetFlow Version 9 . . . . . . . . . . . . . . . 28
10.2. Padding of the Data Set . . . . . . . . . . . . . . . . . 29
10.3. Field ID Numbers . . . . . . . . . . . . . . . . . . . . . 30
10.4. Template ID Numbers . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . . 31
The IPFIX protocol [RFC5101] defines how IP Flow information can be exported from routers, measurement probes, or other devices. In this document, we provide guidelines for its implementation.
IPFIX协议[RFC5101]定义了如何从路由器、测量探头或其他设备导出IP流信息。在本文件中，我们提供了实施指南。
The guidelines are split into seven main sets. These sets address implementation aspects for Template management, Exporting Process, Collecting Process, transport, implementation on middleboxes, security, and extending the information model.
这些准则分为七套主要准则。这些集合解决了模板管理、导出过程、收集过程、传输、中间盒实现、安全性和扩展信息模型的实现方面。
Finally, this document contains a list of common mistakes related to issues that had been misinterpreted in the first IPFIX implementations and that created (and still might create) interoperability problems.
最后，本文档包含一个与问题相关的常见错误列表，这些问题在第一次IPFIX实现中被误解，并导致（现在仍然可能导致）互操作性问题。
The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX architecture [IPFIX-ARCH], per the requirements defined in [RFC3917].
IPFIX协议[RFC5101]为网络管理员提供了访问IP流信息的权限。根据[RFC3917]中定义的要求，IPFIX体系结构[IPFIX-ARCH]中定义了将测量的IP流信息从IPFIX导出过程导出到收集过程的体系结构。
The IPFIX architecture [IPFIX-ARCH] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes.
IPFIX体系结构[IPFIX-ARCH]指定如何通过拥塞感知传输协议将IPFIX数据记录和模板从IPFIX导出进程传送到IPFIX收集进程。
IPFIX has a formal description of IPFIX Information Elements, their name, type, and additional semantic information, as specified in the IPFIX information model [RFC5102].
按照IPFIX信息模型[RFC5102]的规定，IPFIX对IPFIX信息元素、它们的名称、类型和附加语义信息有一个正式的描述。
Finally, the IPFIX applicability statement [IPFIX-AS] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
最后，IPFIX适用性声明[IPFIX-AS]描述了什么类型的应用程序可以使用IPFIX协议以及它们如何使用提供的信息。它还展示了IPFIX框架与其他体系结构和框架的关系。
In the IPFIX protocol, { type, length, value } tuples are expressed in Templates containing { type, length } pairs, specifying which { value } fields are present in Data Records conforming to the Template, giving great flexibility as to what data is transmitted.
在IPFIX协议中，{type，length，value}元组在包含{type，length}对的模板中表示，指定符合模板的数据记录中存在哪些{value}字段，从而在传输什么数据方面提供了极大的灵活性。
Since Templates are sent very infrequently compared with Data Records, this results in significant bandwidth savings.
由于与数据记录相比，发送模板的频率非常低，因此可以显著节省带宽。
Different Data Records may be transmitted simply by sending new Templates specifying the { type, length } pairs for the new data format. See [RFC5101] for more information.
只需发送指定新数据格式的{type，length}对的新模板，就可以传输不同的数据记录。有关更多信息，请参阅[RFC5101]。
The IPFIX information model [RFC5102] defines a large number of standard Information Elements that provide the necessary { type } information for Templates.
IPFIX信息模型[RFC5102]定义了大量标准信息元素，为模板提供必要的{type}信息。
The use of standard elements enables interoperability among different vendors' implementations. The list of standard elements may be extended in the future through the process defined in Section 9, below. Additionally, non-standard enterprise-specific elements may be defined for private use.
使用标准元素可以实现不同供应商实现之间的互操作性。标准元素列表可能在未来通过下文第9节中定义的过程进行扩展。此外，非标准企业特定元素可定义为私人使用。
The terminology used in this document is fully aligned with the terminology defined in [RFC5101]. Therefore, the terms defined in the IPFIX terminology are capitalized in this document, as in other IPFIX documents ([RFC5101], [RFC5102], [IPFIX-ARCH]).
本文件中使用的术语与[RFC5101]中定义的术语完全一致。因此，与其他IPFIX文件（[RFC5101]、[RFC5102]、[IPFIX-ARCH]）一样，IPFIX术语中定义的术语在本文件中大写。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document is Informational. It does not specify a protocol and does not use RFC 2119 key words [RFC2119] such as "MUST" and "SHOULD", except in quotations and restatements from the IPFIX standards documents. The normative specification of the protocol is given in the IPFIX protocol [RFC5101] and information model [RFC5102] documents.
本文件仅供参考。它没有规定协议，也没有使用RFC 2119关键词[RFC2119]，如“必须”和“应该”，IPFIX标准文件中的引用和重述除外。IPFIX协议[RFC5101]和信息模型[RFC5102]文档中给出了该协议的规范性规范。
The Exporting Process should always endeavor to send Template Records before the related Data Records. However, since the Template Record may not arrive before the corresponding Data Records, the Collecting Process MAY store Data Records with an unknown Template ID pending the arrival of the corresponding Template (see Section 9 of [RFC5101]). If no Template becomes available, we recommend logging the event and discarding the corresponding Data Records, and for SCTP and TCP we recommend resetting the Transport Session. The amount of time the Collecting Process waits for a Template before resetting should be configurable. We recommend a default of 30 minutes. Note
导出过程应始终努力在相关数据记录之前发送模板记录。然而，由于模板记录可能不会在相应的数据记录之前到达，收集过程可能会在相应模板到达之前存储具有未知模板ID的数据记录（参见[RFC5101]第9节）。如果没有可用的模板，我们建议记录事件并丢弃相应的数据记录，对于SCTP和TCP，我们建议重置传输会话。收集过程在重置之前等待模板的时间量应该是可配置的。我们建议默认为30分钟。笔记
that when using UDP as the transport protocol, this delay should be bound, when possible, by the Template Retransmit and the Template Expiry times (see Section 6.2).
当使用UDP作为传输协议时，此延迟应尽可能受到模板重传和模板到期时间的限制（见第6.2节）。
The Exporting Process must be able to resend active Templates. Templates must be resent in the case of a Stream Control Transport Protocol (SCTP) association restart, a User Datagram Protocol (UDP) template refresh, or a Transmission Control Protocol (TCP) connection restart.
导出过程必须能够重新发送活动模板。在流控制传输协议（SCTP）关联重新启动、用户数据报协议（UDP）模板刷新或传输控制协议（TCP）连接重新启动的情况下，必须重新发送模板。
The Exporting Process is responsible for the management of Template IDs. Should an insufficient number of Template IDs be available, the Exporting Process must send a Template Withdrawal Message in order to free up the allocation of unused Template IDs. Note that UDP doesn't use the Template Withdrawal Message, and the Template lifetime on the Collecting Process relies on timeout.
导出过程负责模板ID的管理。如果可用的模板ID数量不足，则导出过程必须发送模板撤回消息，以便释放未使用模板ID的分配。请注意，UDP不使用模板撤回消息，收集过程中的模板生存期依赖于超时。
The IPFIX protocol [RFC5101] defines and specifies the use of Templates and Options Templates. Templates define the layout of Data Records, which represent Flow data. Options Templates additionally specify scope Information Elements, which can be used to define scoped Data Records. Scoped Data Records generally export control plane data (such as metadata about processes in the IPFIX collection architecture) or data otherwise applicable to multiple Flow Data Records (such as common properties as in [IPFIX-REDUCING]).
IPFIX协议[RFC5101]定义并指定模板和选项模板的使用。模板定义表示流数据的数据记录的布局。选项模板还指定范围信息元素，可用于定义范围数据记录。作用域数据记录通常导出控制平面数据（如IPFIX收集体系结构中有关进程的元数据）或适用于多个流数据记录的数据（如[IPFIX-REDUCTION]中的公共属性）。
Aside from Section 4 of [RFC5101], which defines specific Options Templates to use for reporting Metering Process and Exporting Process statistics and configuration information, the choice to use Options Templates is left up to the implementer. Indeed, there is a trade-off between bandwidth efficiency and complexity in the use of Options Templates and scoped Data Records.
[RFC5101]第4节定义了用于报告计量过程和导出过程统计信息和配置信息的特定选项模板，除此之外，使用选项模板的选择权留给实施者。事实上，在使用选项模板和作用域数据记录时，带宽效率和复杂性之间存在权衡。
For example, control plane information about an Observation Point could be exported with every Flow Record measured at that Observation Point, or in a single Data Record described by an Options Template, scoped to the Observation Point identifier. In the former case, simplicity of decoding the data is gained in exchange for redundant export of the same data with every applicable Flow Record. The latter case is more bandwidth-efficient, but at the expense of requiring the Collecting Process to maintain the relationship between each applicable Flow Record and the Observation Point.
例如，有关观测点的控制平面信息可以与在该观测点测量的每个流量记录一起导出，或者在选项模板描述的单个数据记录中导出，范围为观测点标识符。在前一种情况下，通过每个适用的流记录冗余输出相同的数据，可以获得数据解码的简单性。后一种情况的带宽效率更高，但代价是要求收集过程保持每个适用流量记录和观测点之间的关系。
A generalized method of using Options Templates to increase bandwidth efficiency is fully described in [IPFIX-REDUCING].
[IPFIX-REDUCTION]中详细介绍了使用选项模板提高带宽效率的通用方法。
The root scope for all IPFIX Messages is the Observation Domain, which appears in the Message Header. In other words, all Data Records within a message implicitly belong to the Observation Domain. All Data Records described by Options Templates (and only those) must be restricted to an additional scope within the Observation Domain, as defined by the scope Information Elements in the Options Template Record.
所有IPFIX消息的根作用域都是观察域，它出现在消息头中。换句话说，消息中的所有数据记录都隐式地属于观察域。选项模板描述的所有数据记录（仅限于这些）必须限制在观察域内的附加范围内，如选项模板记录中的范围信息元素所定义。
In IPFIX, any Information Element can be used for scope. However, Information Elements such as counters, timestamps, padding elements, Flow properties like timeout, Flow end reason, duration, or Min/Max Flow properties [RFC5102] may not be appropriate.
在IPFIX中，任何信息元素都可以用于作用域。但是，计数器、时间戳、填充元素等信息元素、流属性（如超时、流结束原因、持续时间或最小/最大流属性[RFC5102]）可能不合适。
Note that it is sometimes necessary to export information about entities that exist outside any Observation Domain, or within multiple Observation Domains (e.g., information about Metering Processes scoped to meteringProcessID). Such information SHOULD be exported in an IPFIX Message with Observation Domain ID 0 (see [RFC5101], Section 3.1).
请注意，有时需要导出有关存在于任何观察域之外或多个观察域内的实体的信息（例如，有关范围为meteringProcessID的计量过程的信息）。此类信息应在观察域ID为0的IPFIX消息中导出（见[RFC5101]，第3.1节）。
The Exporting Process and Collecting Process MUST support the use of multiple Information Elements of the same type in a single Template [RFC5101]. This was first required by Packet Sampling (PSAMP) [PSAMP-PROTO] for the export of multiple Selector IDs. Note that the IPFIX protocol recommends that Metering Processes SHOULD use packet treatment order when exporting multiple Information Elements of the same type in the same record ([RFC5101] Section 8). This implies that ordering is important, and changes to the order of multiple identical Information Elements could cause information loss. Therefore, we strongly recommend preservation of the order of multiple Information Elements of the same type by Exporting and Collecting Processes for correct processing and storage.
导出过程和收集过程必须支持在单个模板中使用相同类型的多个信息元素[RFC5101]。这是数据包采样（PSAMP）[PSAMP-PROTO]在导出多个选择器ID时首先需要的。请注意，IPFIX协议建议计量过程在导出同一记录中相同类型的多个信息元素时应使用数据包处理顺序（[RFC5101]第8节）。这意味着排序很重要，更改多个相同信息元素的顺序可能会导致信息丢失。因此，我们强烈建议通过导出和收集正确处理和存储的过程来保持相同类型的多个信息元素的顺序。
Section 10.3.3 of the IPFIX protocol defines the maximum message size for IPFIX Messages transported over UDP to be constrained by the path MTU, or if the path MTU is not available, 512 bytes, which is the minimum datagram size all IP implementations must support (see also Section 8.4). However, no maximum message size is imposed on other transport protocols, beyond the 65535-byte limit imposed by the 16- bit Message Length field in the IPFIX Message Header specified in Section 3.1 of [RFC5101].
IPFIX协议第10.3.3节定义了通过UDP传输的IPFIX消息的最大消息大小，该消息大小受路径MTU约束，或者如果路径MTU不可用，则为512字节，这是所有IP实现必须支持的最小数据报大小（另请参见第8.4节）。但是，除了[RFC5101]第3.1节中规定的IPFIX消息头中的16位消息长度字段施加的65535字节限制之外，其他传输协议上没有施加最大消息大小。
An IPFIX Exporting Process operating over SCTP or TCP may export IPFIX Messages up to this 64-kB limit, and an IPFIX Collecting Process must accept any IPFIX Message up to that size.
在SCTP或TCP上运行的IPFIX导出进程可以导出最大为64 kB的IPFIX消息，IPFIX收集进程必须接受最大为该大小的任何IPFIX消息。
A Set is identified by a Set ID [RFC5101]. A Set ID has an integral data type and its value is in the range of 0-65535. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. A value of 2 identifies a Template Set. A value of 3 identifies an Options Template Set. Values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. In this case, the Set ID corresponds to the Template ID of the used Template.
集合由集合ID[RFC5101]标识。集合ID具有整数数据类型，其值在0-65535范围内。由于历史原因，设置的ID值0和1未被使用[RFC3954]。值为2表示模板集。值为3表示选项模板集。4到255之间的值保留供将来使用。大于255的值用于数据集。在这种情况下，集合ID对应于所用模板的模板ID。
A Data Set received with an unknown Set ID may be stored pending the arrival of the corresponding Template (see Section 9 of [RFC5101]). If no Template becomes available, we recommend logging the event and discarding the corresponding Data Records, and for SCTP and TCP we recommend resetting the Transport Session. The amount of time the Collecting Process waits for a Template before resetting should be configurable. We recommend a default of 30 minutes. Note that when using UDP as the transport protocol, this delay should be bound, when possible, by the Template Retransmit and the Template Expiry times (see Section 6.2).
接收到的具有未知集合ID的数据集合可在相应模板到达之前进行存储（参见[RFC5101]第9节）。如果没有可用的模板，我们建议记录事件并丢弃相应的数据记录，对于SCTP和TCP，我们建议重置传输会话。收集过程在重置之前等待模板的时间量应该是可配置的。我们建议默认为30分钟。请注意，当使用UDP作为传输协议时，如果可能，此延迟应受到模板重新传输和模板到期时间的限制（参见第6.2节）。
The arrival of a Set with a reserved Set ID should be logged, and the Collector must ignore the Set.
应记录具有保留集合ID的集合的到达，收集器必须忽略该集合。
[IPFIX-ARCH] does not specify which entities are responsible for the encoding and decoding of Information Elements transferred via IPFIX. An IPFIX device can do the encoding either within the Metering Process or within the Exporting Process. The decoding of the Information Elements can be done by the Collecting Process or by the data processing application.
[IPFIX-ARCH]未指定哪些实体负责对通过IPFIX传输的信息元素进行编码和解码。IPFIX设备可以在计量过程或导出过程中进行编码。信息元素的解码可以通过收集过程或数据处理应用程序来完成。
If an IPFIX node simply relays IPFIX Records (like a proxy), then no decoding or encoding of Information Elements is needed. In this case, the Exporting Process may export unknown Information Elements, i.e., Information Elements with an unknown Information Element identifier.
如果IPFIX节点只是中继IPFIX记录（如代理），则不需要对信息元素进行解码或编码。在这种情况下，导出过程可以导出未知信息元素，即具有未知信息元素标识符的信息元素。
IPFIX offers both Delta and Total counters (e.g., octetDeltaCount, octetTotalCount). If information about a Flow is only ever exported once, then it's not important whether Delta or Total counters are used. However, if further information about additional packets in a Flow is exported after the first export, then either:
IPFIX同时提供增量和总计计数器（例如，octetDeltaCount、octetTotalCount）。如果关于流的信息只导出一次，那么是否使用增量或总数计数器并不重要。但是，如果在第一次导出后导出流中其他数据包的进一步信息，则：
o the metering system must reset its counters to zero after the first export and report the new counter values using Delta counters, or
o 计量系统必须在首次导出后将其计数器重置为零，并使用增量计数器报告新的计数器值，或
o the metering system must carefully maintain its counters and report the running total using Total counters.
o 计量系统必须仔细维护其计数器，并使用总计计数器报告运行总计。
At first, reporting the running total may seem to be the obvious choice. However, this requires that the system accurately maintains information about the Flow over a long time without any loss or error, because when reported to a Collecting Process, the previous total values will be replaced with the new information.
首先，报告运行总数似乎是一个明显的选择。但是，这要求系统在长时间内准确地维护有关流量的信息，而不会出现任何损失或错误，因为当向收集流程报告时，以前的总值将替换为新信息。
Delta counters offer some advantages: information about Flows doesn't have to be permanently maintained, and any loss of information has only a small impact on the total stored at the Collecting Process. Finally, Deltas may be exported in fewer bytes than Total counters using the IPFIX "Reduced Size Encoding" scheme [RFC5101].
增量计数器提供了一些优势：有关流的信息不必永久性地维护，任何信息丢失对收集过程中存储的总量的影响都很小。最后，使用IPFIX“缩减大小编码”方案[RFC5101]，可以以比总计数器更少的字节导出增量。
Note that Delta counters have an origin of zero and that a Collecting Process receiving Delta counters for a Flow that is new to the Collecting Process must assume the Deltas are from zero.
请注意，增量计数器的原点为零，对于收集进程新的流，接收增量计数器的收集进程必须假定增量为零。
The IPFIX information model defines an Information Element for padding called paddingOctets [RFC5102]. It is of type octetArray, and the IPFIX protocol allows encoding it as a fixed-length array as well as a variable-length array.
IPFIX信息模型定义了一个用于填充的信息元素，称为paddingOctets[RFC5102]。它是octetArray类型，IPFIX协议允许将其编码为固定长度数组和可变长度数组。
The padding Information Element can be used to align Information Elements within Data Records, Records within Sets, and Sets within IPFIX Messages, as described below.
填充信息元素可用于对齐数据记录中的信息元素、集合中的记录以及IPFIX消息中的集合，如下所述。
The padding Information Element gives flexible means for aligning Information Elements within a Data Record. Aligning within a Data Record can be useful, because internal data structures can be easily converted into Flow Records at the Exporter and vice versa at the Collecting Process.
填充信息元素提供了在数据记录中对齐信息元素的灵活方法。在数据记录内对齐可能很有用，因为内部数据结构可以在导出器处轻松转换为流记录，在收集过程中也可以轻松转换为流记录。
Alignment of Information Elements within a Data Record is achieved by inserting an instance of the paddingOctets Information Element with appropriate length before each unaligned Information Element. This insertion is explicitly specified within the Template Record or Options Template Record, respectively, that corresponds to the Data Record.
通过在每个未对齐的信息元素之前插入具有适当长度的paddingOctets信息元素实例，可以实现数据记录中信息元素的对齐。此插入分别在与数据记录对应的模板记录或选项模板记录中明确指定。
4.4.2. Alignment of Information Element Specifiers within a Template Record
4.4.2. 模板记录中信息元素说明符的对齐
There is no means for aligning Information Element specifiers within Template Records. However, there is limited need for such a method, as Information Element specifiers are always 32-bit aligned, and 32- bit alignment is generally sufficient.
没有方法在模板记录中对齐信息元素说明符。然而，这种方法的需求是有限的，因为信息元素说明符总是32位对齐的，并且32位对齐通常就足够了。
There is no means for aligning Template Records within a Set. However, there is limited need for such a method, as Information Element specifiers are always 32-bit aligned, and 32-bit alignment is generally sufficient.
在一个集合中没有对齐模板记录的方法。然而，这种方法的需求是有限的，因为信息元素说明符总是32位对齐的，并且32位对齐通常就足够了。
Data Records can be aligned within a Set by appending instances of the paddingOctets Information Element at the end of the Record. Since all Data Records within a Set have the same structure and size, aligning one Data Record implies aligning all the Data Records within a single Set.
通过在记录末尾附加paddingOctets信息元素的实例，可以在一个集合内对齐数据记录。由于一个集合中的所有数据记录具有相同的结构和大小，因此对齐一个数据记录意味着对齐单个集合中的所有数据记录。
If Records are already aligned within a Set by using paddingOctets Information Elements, then this alignment will already be achieved. But for aligning Sets within an IPFIX Message, padding Information Elements can be used at the end of the Set so that the subsequent Set starts at an aligned boundary. This padding mechanism is described in Section 3.3.1 of [RFC5101] and can be applied even if the Records within the Set are not aligned. However, it should be noted that this method is limited by the constraint that "the padding length MUST be shorter than any allowable Record in the Set", to prevent the padding from being misinterpreted as an additional Data Record.
如果记录已经使用paddingOctets信息元素在一个集合内对齐，那么这个对齐就已经实现了。但是，对于在IPFIX消息中对齐集合，可以在集合的末尾使用填充信息元素，以便后续集合从对齐的边界开始。[RFC5101]第3.3.1节描述了这种填充机制，即使集合中的记录未对齐，也可以应用该机制。然而，应注意，该方法受到“填充长度必须短于集合中任何允许记录”的约束的限制，以防止填充被误解为附加数据记录。
IPFIX Messages contain the export time in the Message Header. In addition, there is a series of Information Elements defined to transfer time values. [RFC5102] defines four abstract data types to transfer time values in second, millisecond, microsecond, and nanosecond resolution.
IPFIX消息在消息头中包含导出时间。此外，还定义了一系列信息元素来传递时间值。[RFC5102]定义了四种抽象数据类型，用于以秒、毫秒、微秒和纳秒分辨率传输时间值。
The accuracy and precision of these values depend on the accuracy and the precision of the Metering Process clock. The accuracy and precision of the Exporting Process clock, and the synchronization of the Metering Process and Exporting Process clocks, are also important when using the delta timestamp Information Elements. To ensure accuracy, the clocks should be synchronized to a UTC time source. Normally, it would be sufficient to derive the time from a remote time server using the Network Time Protocol (NTP) [RFC1305]. IPFIX Devices operating with time values of microsecond or nanosecond resolution need direct access to a time source, for example, to a GPS (Global Positioning System) unit.
这些值的准确度和精度取决于计量过程时钟的准确度和精度。在使用增量时间戳信息元素时，导出过程时钟的准确性和精度以及计量过程和导出过程时钟的同步也很重要。为确保准确性，时钟应与UTC时间源同步。通常，使用网络时间协议（NTP）[RFC1305]从远程时间服务器获取时间就足够了。以微秒或纳秒分辨率的时间值运行的IPFIX设备需要直接访问时间源，例如GPS（全球定位系统）单元。
The most important consideration in selecting timestamp Information Elements is to use a precision appropriate for the timestamps as generated from the Metering Process. Specifically, an IPFIX Device should not export timestamp Information Elements of higher precision than the timestamps used by the Metering Process (e.g., millisecond-precision Flows should not be exported with flowStartMicroseconds and flowEndMicroseconds).
在选择时间戳信息元素时，最重要的考虑是使用适合于从计量过程生成的时间戳的精度。具体而言，IPFIX设备不应导出精度高于计量过程使用的时间戳的时间戳信息元素（例如，毫秒精度流不应使用flowStartMicroseconds和flowEndMicroseconds导出）。
Section 5 of [RFC5101] defines a method for optimized export of time-related Information Elements based upon the Export Time field of the IPFIX Message Header. The architectural separation of the Metering Process and Exporting Process in [IPFIX-ARCH] raises some difficulties with this method, of which implementers should be aware.
[RFC5101]第5节定义了基于IPFIX消息头的导出时间字段优化导出时间相关信息元素的方法。[IPFIX-ARCH]中计量过程和导出过程的体系结构分离给这种方法带来了一些困难，实现者应该了解到这一点。
Since the Metering Process has no information about the export time of the IPFIX Message (that is, when the message leaves the Exporting Process), it cannot properly use the delta time Information Elements; it must store absolute timestamps and transmit these to the Exporting Process. The Exporting Process must then convert these to delta timestamps once the export time is known. This increases the processing burden on the Exporting Process. Note also that the absolute timestamps require more storage than their delta timestamp counterparts. However, this method can result in reduced export bandwidth.
由于计量进程没有关于IPFIX消息导出时间的信息（即消息离开导出进程时），因此无法正确使用增量时间信息元素；它必须存储绝对时间戳并将其传输到导出进程。一旦导出时间已知，导出过程必须将这些时间戳转换为增量时间戳。这增加了出口过程的处理负担。还请注意，绝对时间戳比其增量时间戳对应项需要更多的存储。但是，此方法可能导致导出带宽减少。
Alternatively, the Exporting Process may simply export absolute timestamp Information Elements. This simplifies the Exporting Process' job and reduces processing burden, but increases export bandwidth requirements.
或者，导出过程可以简单地导出绝对时间戳信息元素。这简化了导出过程的工作并减少了处理负担，但增加了导出带宽要求。
Exporting just relative times in a device without an absolute clock is often not sufficient. For instance, observed traffic could be retained in the device's cache for some time before being exported (e.g., if the Exporter runs once per minute), or stuck in an Inter Process Communication (IPC) queue, or stuck in the export stack, or delayed in the network between the Exporter and Collector.
在没有绝对时钟的设备中仅导出相对时间通常是不够的。例如，观察到的流量可能在导出之前在设备缓存中保留一段时间（例如，如果导出器每分钟运行一次），或者卡在进程间通信（IPC）队列中，或者卡在导出堆栈中，或者在导出器和收集器之间的网络中延迟。
For these reasons, it can be difficult for the Collecting Process to convert the relative times exported using the flowStartSysUpTime and flowEndSysUpTime Information Elements to absolute times with any sort of accuracy without knowing the systemInitTimeMilliseconds. Therefore, the sending of the flowStartSysUpTime and flowEndSysUpTime Information Elements without also sending the systemInitTimeMilliseconds Information Element is not recommended.
由于这些原因，在不知道SystemInitTimeMillics的情况下，收集过程可能很难将使用flowStartSysUpTime和flowEndSysUpTime信息元素导出的相对时间转换为具有任何精度的绝对时间。因此，不建议发送flowStartSysUpTime和flowEndSysUpTime信息元素而不同时发送SystemInitTimeMillicles信息元素。
Section 9 of [RFC5101] specifies: "The Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from the Flow Record". The Collecting Process may accept Templates with Information Elements of unknown types. In this case, the value received for these Information Elements should be decoded as an octet array.
[RFC5101]第9节规定：“收集过程必须注意其不理解的任何信息元素的信息元素标识符，并且可以从流记录中丢弃该信息元素”。收集过程可能会接受包含未知类型信息元素的模板。在这种情况下，为这些信息元素接收的值应解码为八位字节数组。
Alternatively, the Collecting Process may ignore Templates and subsequent Data Sets that contain Information Elements of unknown types.
或者，收集过程可能会忽略包含未知类型信息元素的模板和后续数据集。
It is recommended that Collecting Processes provide means to flexibly add types of new Information Elements to their knowledge base. An example is a configuration file that is read by the Collecting Process and that contains a list of Information Element identifiers and their corresponding types. Particularly for adding enterprise-specific Information Elements, such a feature can be very useful.
建议收集过程提供灵活地向其知识库添加新信息元素类型的方法。例如，由收集过程读取的配置文件包含信息元素标识符及其对应类型的列表。特别是对于添加特定于企业的信息元素，这样的功能非常有用。
Since a Collector may receive data from the same device and Observation Domain in two Templates using different reduced-size encodings, it is recommended that the data be stored using full-size encoding, to ensure that the values can be stored or even aggregated together.
由于采集器可能会在两个模板中使用不同的缩减编码接收来自同一设备和观测域的数据，因此建议使用全尺寸编码存储数据，以确保值可以存储甚至聚合在一起。
Template IDs are generated dynamically by the Exporting Process. They are unique per Transport Session and Observation Domain.
模板ID由导出过程动态生成。每个传输会话和观察域都是唯一的。
Therefore, for each Transport Session, the Collecting Process has to maintain a list of Observation Domains. For each Observation Domain, the Collecting Process has to maintain a list of current Template IDs in order to decode subsequent Data Records.
因此，对于每个传输会话，收集过程必须维护观察域列表。对于每个观察域，收集过程必须维护当前模板ID的列表，以便解码后续数据记录。
Note that a restart of the Transport Session may lead to a Template ID renumbering.
请注意，重新启动传输会话可能会导致模板ID重新编号。
IPFIX can use SCTP, TCP, or UDP as a transport protocol. IPFIX implementations MUST support SCTP with partial reliability extensions (PR-SCTP), and MAY support TCP and/or UDP (see [RFC5101], Section 10.1). In the IPFIX documents, the terms SCTP and PR-SCTP are often used interchangeably to mean SCTP with partial reliability extensions.
IPFIX可以使用SCTP、TCP或UDP作为传输协议。IPFIX实现必须支持带有部分可靠性扩展（PR-SCTP）的SCTP，并且可以支持TCP和/或UDP（请参阅[RFC5101]，第10.1节）。在IPFIX文件中，术语SCTP和PR-SCTP通常互换使用，以表示具有部分可靠性扩展的SCTP。
PR-SCTP is the preferred transport protocol for IPFIX because it is congestion-aware, reducing total bandwidth usage in the case of congestion, but with a simpler state machine than TCP. This saves resources on lightweight probes and router line cards.
PR-SCTP是IPFIX的首选传输协议，因为它具有拥塞感知功能，在拥塞情况下减少了总带宽使用量，但使用了比TCP更简单的状态机。这节省了轻量级探测器和路由器线路卡上的资源。
SCTP, as specified in [RFC4960] with the PR-SCTP extension defined in [RFC3758], provides several features not available in TCP or UDP. The two of these most universally applicable to IPFIX implementations, and which IPFIX implementers need to know about, are multiple streams and per-message partial reliability.
[RFC4960]中规定的SCTP以及[RFC3758]中定义的PR-SCTP扩展提供了TCP或UDP中不可用的若干功能。其中两个最普遍适用于IPFIX实现，IPFIX实现者需要了解的是多流和每条消息的部分可靠性。
An SCTP association may contain multiple streams. Streams are useful for avoiding head-of-line blocking, thereby minimizing end-to-end delay from the Exporting Process to the Collecting Process. Example
SCTP关联可能包含多个流。流有助于避免线头阻塞，从而最大限度地减少从导出过程到收集过程的端到端延迟。实例
applications for this feature would be using one SCTP stream per Observation Domain, one stream per type of data (or Template ID), or one stream for Flow data and one for metadata.
此功能的应用程序将为每个观察域使用一个SCTP流，为每种类型的数据（或模板ID）使用一个流，或为流数据使用一个流，为元数据使用一个流。
An Exporting Process may request any number of streams, and may send IPFIX Messages containing any type of Set (Data Set, Template Set, etc.) on any stream. A Collecting Process MUST be able to process any Message received on any stream.
导出过程可以请求任意数量的流，并且可以在任何流上发送包含任何类型的集合（数据集合、模板集合等）的IPFIX消息。收集进程必须能够处理在任何流上接收的任何消息。
Stream negotiation is a feature of the SCTP protocol. Note, however, that the IPFIX protocol doesn't provide any mechanism for the Exporter to convey any information about which streams are in use to the Collector. Therefore, stream configuration must be done out of band.
流协商是SCTP协议的一个特性。但是，请注意，IPFIX协议没有为导出器提供任何机制来向收集器传递有关正在使用哪些流的任何信息。因此，流配置必须在带外完成。
One extra advantage of the PR-SCTP association is its ability to send messages with different levels of reliability, selected according to the application. For example, billing or security applications might require reliable delivery of all their IPFIX Messages, while capacity planning applications might be more tolerant of message loss. SCTP allows IPFIX Messages for all these applications to be transported over the same association with the appropriate level of reliability.
PR-SCTP关联的一个额外优势是，它能够发送根据应用程序选择的具有不同可靠性级别的消息。例如，计费或安全应用程序可能需要可靠地传递其所有IPFIX消息，而容量规划应用程序可能更能容忍消息丢失。SCTP允许所有这些应用程序的IPFIX消息通过具有适当可靠性级别的相同关联进行传输。
IPFIX Messages may be sent with full or partial reliability, on a per-message basis. Fully reliable delivery guarantees that the IPFIX Message will be received at the Collecting Process or that that SCTP association will be reset, as with TCP. Partially reliable delivery does not guarantee the receipt of the IPFIX Message at the Collecting Process. This feature may be used to allow Messages to be dropped during network congestion, i.e., while observing a Denial of Service attack.
IPFIX消息可以完全或部分可靠地按每条消息发送。完全可靠的传递保证了IPFIX消息将在收集过程中被接收，或者SCTP关联将被重置，就像TCP一样。部分可靠的传递不能保证在收集过程中收到IPFIX消息。此功能可用于允许在网络拥塞期间（即观察到拒绝服务攻击时）丢弃消息。
[RFC3758] defines the concept of a Partial Reliability policy, which specifies the interface used to control partially reliable delivery. It also defines a single example Partial Reliability policy called "timed reliability", which uses a single parameter: lifetime. The lifetime is specified per message in milliseconds, and after it expires, no further attempt will be made to transmit the message. Longer lifetimes specify more retransmission attempts per message and therefore higher reliability; however, it should be noted that the absolute reliability provided by a given lifetime is highly dependent on network conditions, so an Exporting Process using the timed reliability service should provide a mechanism for configuring the lifetime of exported IPFIX Messages. Another possible Partial Reliability policy could be limited retransmission, which guarantees a specified number of retransmissions for each message. It is up to the implementer to decide which Partial Reliability policy is most appropriate for its application.
[RFC3758]定义了部分可靠性策略的概念，该策略指定了用于控制部分可靠交付的接口。它还定义了一个称为“定时可靠性”的单一示例部分可靠性策略，该策略使用一个参数：寿命。每个消息的生存期以毫秒为单位指定，在它过期后，将不再尝试传输该消息。更长的生命周期指定了每条消息更多的重传尝试，因此可靠性更高；但是，应注意，给定生存期提供的绝对可靠性高度依赖于网络条件，因此使用定时可靠性服务的导出过程应提供配置导出IPFIX消息生存期的机制。另一种可能的部分可靠性策略可能是有限重传，它保证每个消息的指定重传次数。由实施者决定哪个部分可靠性策略最适合其应用。
There is an additional service provided by SCTP and useful in conjunction with PR-SCTP: unordered delivery. This also works on a per-message basis by declaring that a given message should be delivered to the receiver as soon as it is queued rather than kept in sequence; however, it should be noted that unless explicitly requested by the sender, even messages sent partially reliably will still be delivered in order. Unordered delivery should not be used when the order of IPFIX Messages may matter: e.g., a Template or Options Template. Unordered delivery should not be used when Total counters are used, as reordering could result in the counter value decreasing at the Collecting Process and even being left with a stale value if the last message processed is stale.
SCTP提供了一项附加服务，该服务与PR-SCTP结合使用：无序交付。这也适用于每条消息，它声明一条给定的消息在排队时应立即传递给接收方，而不是按顺序传递；但是，应该注意的是，除非发送方明确要求，否则即使部分可靠发送的消息也将按顺序传递。当IPFIX消息的顺序可能很重要时，不应使用无序传递：例如，模板或选项模板。当使用总计数器时，不应使用无序传递，因为重新排序可能会导致收集过程中计数器值减少，如果最后处理的消息已过时，甚至会留下过时值。
By convention, when the IPFIX documents state a requirement for reliable delivery (as, for example, the IPFIX protocol document does for Template Sets, Options Template Sets, and Template Withdrawal Messages), an IPFIX Exporting Process must not use partially reliable delivery for those Messages. By default, and explicitly if the IPFIX documents call for "partially reliable" or "unreliable" delivery, an IPFIX Exporting Process may use partially reliable delivery if the other requirements of the application allow.
按照惯例，当IPFIX文档说明可靠传递的要求时（例如，IPFIX协议文档对模板集、选项模板集和模板撤回消息的要求），IPFIX导出过程不得对这些消息使用部分可靠传递。默认情况下，如果IPFIX文档要求“部分可靠”或“不可靠”交付，则IPFIX导出过程可以使用部分可靠交付，前提是应用程序的其他要求允许。
The Collecting Process may check whether IPFIX Messages are lost by checking the Sequence Number in the IPFIX header. The Collecting Process should use the Sequence Number in the IPFIX Message Header to determine whether any messages are lost when sent with partial reliability. Sequence Numbers should be tracked independently for each stream.
收集过程可以通过检查IPFIX头中的序列号来检查IPFIX消息是否丢失。收集过程应使用IPFIX消息头中的序列号来确定以部分可靠性发送时是否丢失任何消息。对于每个流，应单独跟踪序列号。
The following may be done to mitigate message loss:
可以执行以下操作以减轻消息丢失：
o Increase the SCTP buffer size on the Exporter.
o 增加导出器上的SCTP缓冲区大小。
o Increase the bandwidth available for communicating the exported Data Records.
o 增加用于传输导出数据记录的可用带宽。
o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data (see [RFC5101], Section 10.4.2.3).
o 在计量过程中使用采样、过滤或聚合来减少导出数据量（见[RFC5101]，第10.4.2.3节）。
o If partial reliability is used, switch to fully reliable delivery on the Exporting Process or increase the level of partial reliability (e.g., when using timed reliability, by specifying a longer lifetime for exported IPFIX Messages).
o 如果使用了部分可靠性，请在导出过程中切换到完全可靠传递，或提高部分可靠性级别（例如，在使用定时可靠性时，通过为导出的IPFIX消息指定更长的生存期）。
If the SCTP association is brought down because the IFPIX Messages can't be exported reliably, the options are:
如果由于无法可靠导出IFPIX消息而导致SCTP关联关闭，则选项为：
o Increase the SCTP buffer size on the Exporter.
o 增加导出器上的SCTP缓冲区大小。
o Increase the bandwidth available for communicating the exported Data Records.
o 增加用于传输导出数据记录的可用带宽。
o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data.
o 在计量过程中使用采样、筛选或聚合来减少导出的数据量。
Note that Templates must not be resent when using SCTP, without an intervening Template Withdrawal or SCTP association reset. Note also that since Template Sets and Template Withdrawal Messages may be sent on any SCTP stream, a Template Withdrawal Message may withdraw a Template sent on a different stream, and a Template Set may reuse a Template ID withdrawn by a Template Withdrawal Message sent on a different stream. Therefore, an Exporting Process sending Template Withdrawal Messages should ensure to the extent possible that the Template Withdrawal Messages and subsequent Template Sets reusing the withdrawn Template IDs are received and processed at the Collecting Process in proper order. The Exporting Process can achieve this by one of two possible methods: 1. by sending a Template Withdrawal Message reliably, in order, and on the same stream as the subsequent Template Set reusing its ID; or 2. by waiting an appropriate amount of time (on the scale of one minute) after sending a Template Withdrawal Message before attempting to reuse the withdrawn Template ID.
请注意，在使用SCTP时，如果不进行模板撤回或SCTP关联重置，则不得重新发送模板。还要注意，由于模板集和模板撤回消息可以在任何SCTP流上发送，因此模板撤回消息可以撤回在不同流上发送的模板，并且模板集可以重用由在不同流上发送的模板撤回消息撤回的模板ID。因此，发送模板撤回消息的导出流程应尽可能确保在收集流程中以适当的顺序接收并处理模板撤回消息和重用撤回模板ID的后续模板集。导出过程可以通过以下两种可能的方法之一实现：1。通过可靠地、有序地在与后续模板集相同的流上发送模板撤回消息，重用其ID；或2。发送模板撤回消息后，在尝试重新使用撤回的模板ID之前，等待适当的时间（以一分钟为单位）。
UDP is useful in simple systems where an SCTP stack is not available, and where there is insufficient memory for TCP buffering.
UDP在SCTP堆栈不可用且没有足够内存用于TCP缓冲的简单系统中非常有用。
However, UDP is not a reliable transport protocol, and IPFIX Messages sent over UDP might be lost as with partially reliable SCTP streams. UDP is not the recommended protocol for IPFIX and is intended for use in cases in which IPFIX is replacing an existing NetFlow infrastructure, with the following properties:
但是，UDP不是可靠的传输协议，通过UDP发送的IPFIX消息可能会丢失，就像部分可靠的SCTP流一样。UDP不是IPFIX的推荐协议，用于IPFIX替换现有NetFlow基础结构的情况，具有以下属性：
o A dedicated network,
o 专用网络，
o within a single administrative domain,
o 在单个管理域内，
o where SCTP is not available due to implementation constraints, and
o 由于实施限制，SCTP不可用，以及
o the Collector is as topologically close as possible to the Exporter.
o 收集器在拓扑上尽可能靠近导出器。
Note that because UDP itself provides no congestion control mechanisms, it is recommended that UDP transport be used only on managed networks, where the network path has been explicitly provisioned for IPFIX traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations.
请注意，由于UDP本身不提供拥塞控制机制，因此建议仅在托管网络上使用UDP传输，其中已通过流量工程机制（如速率限制或容量保留）为IPFIX流量显式设置了网络路径。
An important example of an explicitly provisioned, managed network for IPFIX is the use of IPFIX to replace a functioning NetFlow implementation on a dedicated network. In this situation, the dedicated network should be provisioned in accordance with the NetFlow deployment experience that Flow export traffic generated by monitoring an interface will amount to 2-5% of the monitored interface's bandwidth.
IPFIX的显式配置、托管网络的一个重要示例是使用IPFIX替换专用网络上正常运行的NetFlow实现。在这种情况下，应根据NetFlow部署经验来配置专用网络，即通过监视接口生成的流导出流量将达到被监视接口带宽的2-5%。
As recommended in [TSVWG-UDP], an application should not send UDP messages that result in IP packets that exceed the MTU of the path to the destination and should enable UDP checksums (see Sections 3.2 and 3.4 of [TSVWG-UDP], respectively).
按照[TSVWG-UDP]中的建议，应用程序不应发送导致IP数据包超过目标路径MTU的UDP消息，并应启用UDP校验和（分别参见[TSVWG-UDP]第3.2节和第3.4节）。
Since IPFIX assumes reliable transport of Templates over SCTP, this necessitates some changes for IPFIX Template management over UDP. Templates sent from the Exporting Process to the Collecting Process over UDP MUST be resent at regular time intervals; these intervals MUST be configurable (see Section 10.3 of [RFC5101]).
由于IPFIX假定模板通过SCTP可靠传输，因此需要对UDP上的IPFIX模板管理进行一些更改。必须定期重新发送通过UDP从导出进程发送到收集进程的模板；这些间隔必须是可配置的（见[RFC5101]第10.3节）。
We recommend a default Template-resend time of 10 minutes, configurable between 1 minute and 1 day.
我们建议默认的模板重新发送时间为10分钟，可在1分钟到1天之间进行配置。
Note that this could become an interoperability problem; e.g., if an Exporter resends Templates once per day, while a Collector expires Templates hourly, then they may both be IPFIX-compatible, but not be interoperable.
注意，这可能成为互操作性问题；e、 例如，如果导出器每天重新发送一次模板，而收集器每小时终止一次模板，那么它们可能都是IPFIX兼容的，但不可互操作。
Retransmission time intervals that are too short waste bandwidth on unnecessary Template retransmissions. On the other hand, time intervals that are too long introduce additional costs or risk of data loss by potentially requiring the Collector to cache more data without having the Templates available to decode it.
太短的重传时间间隔会浪费不必要的模板重传带宽。另一方面，过长的时间间隔可能会要求收集器缓存更多数据，而无需模板对其进行解码，从而带来额外的成本或数据丢失风险。
To increase reliability and limit the amount of potentially lost data, the Exporting Process may resend additional Templates using a packet-based schedule. In this case, Templates are resent depending on the number of data packets sent. Similarly to the time interval, resending a Template every few packets introduces additional overhead, while resending after a large amount of packets have already been sent means high costs due to the data caching and potential data loss.
为了提高可靠性并限制可能丢失的数据量，导出过程可以使用基于分组的时间表重新发送额外的模板。在这种情况下，根据发送的数据包数量重新发送模板。与时间间隔类似，每隔几个数据包重新发送一个模板会带来额外的开销，而在发送了大量数据包之后重新发送意味着由于数据缓存和潜在的数据丢失而产生的高成本。
We recommend a default Template-resend interval of 20 packets, configurable between 1 and 1000 data packets.
我们建议默认的模板重发间隔为20个数据包，可配置为1到1000个数据包。
Note that a sufficiently small resend time or packet interval may cause a system to become stuck, continually resending Templates or Options Data. For example, if the resend packet interval is 2 (i.e., Templates or Options Data are to be sent in every other packet) but more than two packets are required to send all the information, then the resend interval will have expired by the time the information has been sent, and Templates or Options Data will be sent continuously -- possibly preventing any data from being sent at all. Therefore, the resend intervals should be considered from the last data packet, and should not be tied to specific Sequence Numbers.
请注意，足够小的重新发送时间或数据包间隔可能会导致系统卡住，从而持续重新发送模板或选项数据。例如，如果重发分组间隔为2（即，模板或选项数据将每隔一个分组发送），但发送所有信息需要两个以上的分组，则重发间隔将在发送信息时过期，模板或选项数据将被连续发送——可能会阻止任何数据的发送。因此，重发间隔应从最后一个数据包开始考虑，并且不应与特定的序列号相关联。
The Collecting Process should use the Sequence Number in the IPFIX Message Header to determine whether any messages are lost.
收集过程应使用IPFIX消息头中的序列号来确定是否有任何消息丢失。
The following may be done to mitigate message loss:
可以执行以下操作以减轻消息丢失：
o Move the Collector topologically closer to the Exporter.
o 从拓扑上将收集器移近导出器。
o Increase the bandwidth of the links through which the Data Records are exported.
o 增加用于导出数据记录的链路的带宽。
o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data.
o 在计量过程中使用采样、筛选或聚合来减少导出的数据量。
o Increase the buffer size at the Collector and/or the Exporter.
o 增加收集器和/或导出器处的缓冲区大小。
Before using a Template for the first time, the Exporter may send it in several different IPFIX Messages spaced out over a period of packets in order to increase the likelihood that the Collector has received the Template.
在第一次使用模板之前，导出器可以在若干不同的IPFIX消息中发送该模板，这些消息在一段数据包期间间隔开，以增加收集器接收到该模板的可能性。
Template Withdrawal Messages MUST NOT be sent over UDP (per Section 10.3.6 of [RFC5101]). The Exporter must rely on expiration at the Collector to expire old Templates or to reuse Template IDs.
模板撤回消息不得通过UDP发送（根据[RFC5101]第10.3.6节）。导出器必须依赖收集器的过期来过期旧模板或重用模板ID。
We recommend that the Collector implements a Template Expiry of three times the Exporter refresh rate.
我们建议收集器实现三倍于导出器刷新率的模板过期。
However, since the IPFIX protocol doesn't provide any mechanism for the Exporter to convey any information about the Template Expiry time to the Collector, configuration must be done out of band.
但是，由于IPFIX协议没有为导出器提供任何机制来向收集器传递有关模板过期时间的任何信息，因此必须在带外进行配置。
If no out-of-band configuration is made, we recommend to initially set a Template Expiry time at the Collector of 60 minutes. The Collecting Process may estimate each Exporting Process's resend time and adapt the Expiry time for the corresponding Templates accordingly.
如果未进行带外配置，我们建议最初在收集器上将模板到期时间设置为60分钟。收集过程可以估计每个导出过程的重新发送时间，并相应地调整相应模板的到期时间。
TCP can be used as a transport protocol for IPFIX if one of the endpoints has no support for SCTP, but a reliable transport is needed and/or the network between the Exporter and the Collector has not explicitly been provisioned for the IPFIX traffic. TCP is one of the core protocols of the Internet and is widely supported.
如果其中一个端点不支持SCTP，但需要可靠的传输和/或导出器和收集器之间的网络尚未明确为IPFIX流量配置，则TCP可用作IPFIX的传输协议。TCP是Internet的核心协议之一，得到了广泛的支持。
The Exporting Process may resend Templates (per UDP, above), but it's not required to do so, per Section 10.4.2.2 of [RFC5101]:
根据[RFC5101]第10.4.2.2节，导出过程可以重新发送模板（根据UDP，如上所述），但无需重新发送：
"A Collecting Process MUST record all Template and Options Template Records for the duration of the connection, as an Exporting Process is not required to re-export Template Records."
收集过程必须记录连接期间的所有模板和选项模板记录，因为重新导出模板记录不需要导出过程
If the available bandwidth between Exporter and Collector is not sufficient or the Metering Process generates more Data Records than the Collector is capable of processing, then TCP congestion control may cause the Exporter to block. Options in this case are:
如果导出器和采集器之间的可用带宽不足，或者计量过程生成的数据记录超过采集器的处理能力，则TCP拥塞控制可能会导致导出器阻塞。在这种情况下，选项包括：
o Increase the TCP buffer size on the Exporter.
o 增加导出器上的TCP缓冲区大小。
o Increase the bandwidth of the links through which the Data Records are exported.
o 增加用于导出数据记录的链路的带宽。
o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data.
o 在计量过程中使用采样、筛选或聚合来减少导出的数据量。
The term middlebox is defined in [RFC3234] as:
[RFC3234]中将术语“中间盒”定义为：
"any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host."
在源主机和目标主机之间的数据报路径上执行IP路由器正常、标准功能以外的任何中间设备
The list of middleboxes discussed in [RFC3234] contains:
[RFC3234]中讨论的中间盒列表包括：
1. Network Address Translation (NAT),
1. 网络地址转换（NAT），
2. NAT-Protocol Translation (NAT-PT),
2. NAT协议转换（NAT-PT），
3. SOCKS gateway,
3. 袜子网关，
4. IP tunnel endpoints,
4. IP隧道端点，
5. packet classifiers, markers, schedulers,
5. 数据包分类器、标记、调度程序、，
6. transport relay,
6. 运输接力，
7. TCP performance enhancing proxies,
7. TCP性能增强代理，
8. load balancers that divert/munge packets,
8. 转移/咀嚼数据包的负载均衡器，
9. IP firewalls,
9. IP防火墙，
10. application firewalls,
10. 应用防火墙，
11. application-level gateways,
11. 应用程序级网关，
12. gatekeepers / session control boxes,
12. 网关守卫/会话控制盒，
13. transcoders,
13. 转码器，
14. proxies,
14. 代理，
15. caches,
15. 储藏室，
16. modified DNS servers,
16. 修改DNS服务器，
17. content and applications distribution boxes,
17. 内容和应用程序配电箱，
18. load balancers that divert/munge URLs,
18. 转移/munge URL的负载平衡器，
19. application-level interceptors,
19. 应用程序级拦截器，
20. application-level multicast,
20. 应用层多播，
21. involuntary packet redirection,
21. 非自愿数据包重定向，
22. anonymizers.
22. 匿名者。
It is likely that since the publication of RFC 3234 new kinds of middleboxes have been added.
自RFC 3234发布以来，很可能添加了新类型的中间盒。
While the IPFIX specifications [RFC5101] based the requirements on the export protocol only (as the IPFIX name implies), these sections cover the guidelines for the implementation of the Metering Process by recommending which Information Elements to export for the different middlebox considerations.
虽然IPFIX规范[RFC5101]仅基于导出协议的要求（如IPFIX名称所示），但这些章节通过建议针对不同的中间盒考虑导出哪些信息元素来涵盖计量过程的实施指南。
Middleboxes may delay, reorder, drop, or multiply packets; they may change packet header fields and change the payload. All these actions have an impact on traffic Flow properties. In general, a middlebox transforms a unidirectional original traffic Flow T that arrives at the middlebox into a transformed traffic Flow T' that leaves the middlebox.
中间盒可以延迟、重新排序、丢弃或增加数据包；它们可以更改数据包头字段和有效负载。所有这些动作都会对交通流特性产生影响。通常，中间箱将到达中间箱的单向原始交通流T转换为离开中间箱的转换交通流T’。
+-----------+
T ---->| middlebox |----> T'
+-----------+
+-----------+
T ---->| middlebox |----> T'
+-----------+
Figure 1: Unidirectional traffic Flow traversing a middlebox
图1：穿过中间箱的单向交通流
Note that in an extreme case, T' may be an empty traffic Flow (a Flow with no packets), for example, if the middlebox is a firewall and blocks the Flow.
请注意，在极端情况下，T'可能是空流量（没有数据包的流量），例如，如果中间箱是防火墙并阻止流量。
In case of a middlebox performing a multicast function, a single original traffic Flow may be transformed into more than one transformed traffic Flow.
在中间盒执行多播功能的情况下，单个原始业务流可以转换为多个转换后的业务流。
+------> T'
|
+---------+-+
T ---->| middlebox |----> T''
+---------+-+
|
+------> T'''
+------> T'
|
+---------+-+
T ---->| middlebox |----> T''
+---------+-+
|
+------> T'''
Figure 2: Unidirectional traffic Flow traversing a middlebox with multicast function
图2：通过具有多播功能的中间盒的单向流量
For bidirectional traffic Flows, we identify Flows on different sides of the middlebox; say, T_l on the left side and T_r on the right side.
对于双向交通流，我们识别中间盒不同侧面的交通流；比如说，左T_l和右T_r。
+-----------+
T_l <--->| middlebox |<---> T_r
+-----------+
+-----------+
T_l <--->| middlebox |<---> T_r
+-----------+
Figure 3: Bidirectional unicast traffic Flow traversing a middlebox
图3：穿过中间盒的双向单播业务流
In case of a NAT, T_l might be a traffic Flow in a private address realm and T_r the translated traffic Flow in the public address realm. If the middlebox is a NAT-PT, then T_l may be an IPv4 traffic Flow and T_r the translated IPv6 traffic Flow.
在NAT的情况下，T_l可能是专用地址域中的流量，而T_r可能是公共地址域中的转换流量。如果中间盒是NAT-PT，则T_l可能是IPv4通信流，而T_r可能是转换后的IPv6通信流。
At tunnel endpoints, Flows are multiplexed or demultiplexed. In general, tunnel endpoints can deal with bidirectional traffic Flows.
在隧道端点，流被多路复用或解多路复用。通常，隧道端点可以处理双向交通流。
+------> T_r1
v
+---------+-+
T_l <--->| middlebox |<---> T_r2
+---------+-+
^
+------> T_r3
+------> T_r1
v
+---------+-+
T_l <--->| middlebox |<---> T_r2
+---------+-+
^
+------> T_r3
Figure 4: Multiple data reduction
图4：多重数据缩减
An example is a traffic Flow T_l of a tunnel and Flows T_rx that are multiplexed into or demultiplexed out of a tunnel. According to the IPFIX definition of traffic Flows in [RFC5101], T and T' or T_l and T_rx, respectively, are different Flows in general.
一个示例是隧道的交通流T_l和多路复用到隧道中或多路复用出隧道的流T_rx。根据[RFC5101]中IPFIX对流量的定义，T和T'或T_l和T_rx通常是不同的流量。
However, from an application point of view, they might be considered as closely related or even as the same Flow, for example, if the payloads they carry are identical.
但是，从应用程序的角度来看，它们可能被视为密切相关，甚至是相同的流，例如，如果它们承载的有效负载相同。
Middleboxes might be integrated with other devices. An example is a router with a NAT or a firewall at a line card. If an IPFIX Observation Point is located at the line card, then the properties of measured traffic Flows may depend on the side of the integrated middlebox at which packets were captured for traffic Flow measurement.
中间盒可以与其他设备集成。例如，在线路卡上有NAT或防火墙的路由器。如果IPFIX观测点位于线路卡上，则测量流量的属性可能取决于集成中间盒的侧面，在该侧面捕获数据包以进行流量测量。
Consequently, an Exporting Process reporting traffic Flows measured at a device that hosts one or more middleboxes should clearly indicate to Collecting Processes the location of the used Observation Point(s) with respect to the middlebox(es). This can be done by using Options with Observation Point as scope and elements like, for instance, lineCardID or samplerID. Otherwise, processing the measured Flow data could lead to wrong results.
因此，报告在承载一个或多个中间箱的设备上测量的流量的导出过程应向收集过程清楚地指示所使用的观察点相对于中间箱的位置。这可以通过使用以观察点为范围和元素（例如lineCardID或samplerID）的选项来实现。否则，处理测量的流量数据可能会导致错误的结果。
At first glance, choosing an Observation Point that covers the entire middlebox looks like an attractive choice. But this leads to ambiguities for all kinds of middleboxes. Within the middlebox, properties of packets are modified, and it should be clear at a Collecting Process whether packets were observed and metered before or after modification. For example, it must be clear whether a reported source IP address was observed before or after a NAT changed it or whether a reported packet count was measured before or after a
乍一看，选择一个覆盖整个中间盒的观察点看起来是一个很有吸引力的选择。但这导致了所有类型的中间盒的歧义。在中间盒中，数据包的属性被修改，在收集过程中应该清楚数据包是在修改之前还是之后被观察和计量的。例如，必须明确报告的源IP地址是在NAT更改之前还是之后观察到的，或者报告的数据包计数是在NAT更改之前还是之后测量的
firewall dropped packets. For this reason, [RFC5102] provides Information Elements with prefix "post" for Flow properties that are changed within a middlebox.
防火墙丢弃数据包。因此，[RFC5102]为在中间盒中更改的流属性提供前缀为“post”的信息元素。
If an Observation Point is located inside a middlebox, the middlebox must have well-defined and well-separated internal functions, for example, a combined NAT and firewall, and the Observation Point should be located on a boundary between middlebox functions rather than within one of the functions.
如果观察点位于中间箱内部，则中间箱必须具有定义明确且分离良好的内部功能，例如，组合NAT和防火墙，并且观察点应位于中间箱功能之间的边界上，而不是其中一个功能内。
While this document recommends IPFIX implementations using Observation Points outside of middlebox functions, there are a few special cases where reporting Flow-related internals of a middlebox is of interest.
虽然本文档建议使用middlebox函数之外的观察点来实现IPFIX，但在一些特殊情况下，报告middlebox中与流相关的内部结构是有意义的。
For many applications that use traffic measurement results, it is desirable to get more information than can be derived from just observing packets on one side of a middlebox. If, for example, packets are dropped by the middlebox acting as a firewall, NAT, or traffic shaper, then information about how many observed packets are dropped may be of high interest.
对于使用流量测量结果的许多应用程序，希望获得比仅通过观察中间盒一侧的数据包得到的信息更多的信息。例如，如果作为防火墙、NAT或流量整形器的中间盒丢弃数据包，那么关于丢弃了多少个观察到的数据包的信息可能非常重要。
This section gives recommendations on middlebox internal information that may be reported if the IPFIX Observation Point is co-located with one or more middleboxes. Since the internal information to be reported depends on the kind of middlebox, it is discussed per kind.
本节提供了有关中间箱内部信息的建议，如果IPFIX观测点与一个或多个中间箱位于同一位置，则可能会报告这些信息。由于要报告的内部信息取决于中间盒的种类，因此将按种类进行讨论。
The recommendations cover middleboxes that act per packet and that do not modify the application-level payload of the packet (except by dropping the entire packet) and that do not insert additional packets into an application-level or transport-level traffic stream.
这些建议包括对每个数据包起作用、不修改数据包的应用程序级有效负载（除去丢弃整个数据包）以及不向应用程序级或传输级流量流插入额外数据包的中间盒。
Covered are the packet-level middleboxes of kinds 1, 2, 3, 5, 9, 10, 21, and 22 (according to the enumeration given at the beginning of Section 7 of this document). Not covered are 4, 6-8 and 11-20. TCP performance-enhancing proxies (7) are not covered because they may add ACK packets to a TCP connection.
包括类型1、2、3、5、9、10、21和22的数据包级中间盒（根据本文件第7节开头给出的枚举）。不包括4、6-8和11-20。不包括TCP性能增强代理（7），因为它们可能会向TCP连接添加ACK数据包。
Still, if possible, IPFIX implementations co-located with uncovered middleboxes (i.e., of type 7 or 11-20) should follow the recommendations given in this section if they can be applied in a way that reflects the intention of these recommendations.
尽管如此，如果可能，与未覆盖的中间盒（即7型或11-20型）共存的IPFIX实施应遵循本节给出的建议，前提是它们的应用方式能够反映这些建议的意图。
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially drop packets, then the corresponding IPFIX Exporting Process should be able to report the number of packets that were dropped per reported Flow.
如果IPFIX观察点与一个或多个可能丢弃数据包的中间盒位于同一位置，则相应的IPFIX导出过程应能够报告每个报告流丢弃的数据包数量。
Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS gateway (3), packet schedulers (5), IP firewalls (9) and application-level firewalls (10).
与之相关的中间盒有NAT（1）、NAT-PT（2）、SOCKS网关（3）、数据包调度器（5）、IP防火墙（9）和应用层防火墙（10）。
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially modify the Diffserv Code Point (DSCP, see [RFC2474]) in the IP header, then the corresponding IPFIX Exporting Process should be able to report both the observed incoming DSCP value and also the DSCP value on the 'other' side of the middlebox (if this is a constant value for the particular traffic flow). The related Information Elements specified in [RFC5102] are: IpClassOfService and postIpClassOfService.
如果IPFIX观察点与一个或多个可能修改IP报头中的Diffserv代码点（DSCP，请参阅[RFC2474]）的中间盒位于同一位置，则相应的IPFIX导出过程应能够报告观察到的传入DSCP值以及中间盒“另一侧”的DSCP值[RFC5102]中指定的相关信息元素为：IpClassOfService和postIpClassOfService。
Note that the current IPFIX information model only contains Information Elements supporting packets observed before the DSCP change, i.e. ipClassOfService and postIpClassOfService, where the latter reports the value of the IP TOS field after the DSCP change. We recommend, whenever possible, to move the Observation Point to the point before the DSCP change and report the Observed and post-values. If reporting the value of the IP TOS field before DSCP change is required, "pre" values can be exported using enterprise-specific Information Elements.
请注意，当前IPFIX信息模型仅包含支持DSCP更改前观察到的数据包的信息元素，即ipClassOfService和postIpClassOfService，后者报告DSCP更改后IP TOS字段的值。我们建议尽可能将观测点移动到DSCP变化前的点，并报告观测值和post值。如果在需要更改DSCP之前报告IP TOS字段的值，则可以使用特定于企业的信息元素导出“pre”值。
Note also that a classifier may change the same DSCP value of packets from the same Flow to different values depending on the packet or other conditions. Also, it is possible that packets of a single unidirectional arriving Flow contain packets with different DSCP values that are all set to the same value by the middlebox. In both cases, there is a constant value for the DSCP field in the IP packet header to be observed on one side of the middlebox, but on the other side the value may vary. In such a case, reliable reporting of the DSCP value on the 'other' side of the middlebox is not possible by just reporting a single value. According to the IPFIX information model [RFC5102], the first value observed for the DSCP is reported by the IPFIX protocol in that case.
还要注意，分类器可以根据分组或其他条件将来自相同流的分组的相同DSCP值改变为不同的值。此外，单个单向到达流的分组可能包含具有不同DSCP值的分组，这些DSCP值都由中间盒设置为相同值。在这两种情况下，IP数据包报头中的DSCP字段在中间盒的一侧有一个常量值，但在另一侧，该值可能会有所不同。在这种情况下，仅报告一个值是不可能在中间盒的“另一方”可靠报告DSCP值的。根据IPFIX信息模型[RFC5102]，在这种情况下，观察到的DSCP的第一个值由IPFIX协议报告。
This recommendation applies to packet markers (5).
本建议适用于分组标记（5）。
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially modify the:
如果一个IPFIX观测点与一个或多个可能修改以下内容的中间盒位于同一位置：
o IP version field,
o IP版本字段，
o IP source address header field,
o IP源地址头字段，
o IP destination address header field,
o IP目标地址头字段，
o Source transport port number, or
o 源传输端口号，或
o Destination transport port number
o 目的地运输端口号
in one of the headers, then the corresponding IPFIX Exporting Process should be able to report the 'translated' value of these fields, as far as they have constant values for the particular traffic Flow, in addition to the observed values of these fields.
在其中一个报头中，相应的IPFIX导出过程应该能够报告这些字段的“转换”值，只要这些字段对于特定流量具有恒定值，以及这些字段的观察值。
If the changed values are not constant for the particular traffic Flow but still reporting is desired, then it is recommended that the general rule from [RFC5102] for Information Elements with changing values is applied: the reported value is the one that applies to the first packet observed for the reported Flow.
如果改变的值对于特定的交通流不是恒定的，但仍然需要报告，则建议应用[RFC5102]中关于具有变化值的信息元素的一般规则：报告的值适用于为报告的流量观察到的第一个数据包。
Note that the 'translated' value of the fields can be the values before or after the translation depending on the Flow direction and the location of the Observation Point with respect to the middlebox. We always call the value that is not the one observed at the Observation Point the translated value.
请注意，字段的“转换”值可以是转换之前或之后的值，具体取决于流向和观察点相对于中间箱的位置。我们总是把在观察点观察到的值称为转换值。
Note also that a middlebox may change the same port number value of packets from the same Flow to different values depending on the packet or other conditions. Also, it is possible that packets of different unidirectional arriving Flows with different source/ destination port number pairs may be mapped to a single Flow with a single source/destination port number pair by the middlebox. In both cases, there is a constant value for the port number pair to be observed on one side of the middlebox, but on the other side the values may vary. In such a case, reliable reporting of the port number pairs on the 'other' side of the middlebox is not possible. According to the IPFIX information model [RFC5102], the first value observed for each port number is reported by the IPFIX protocol in that case.
还要注意，根据分组或其他条件，中间盒可以将来自相同流的分组的相同端口号值更改为不同的值。此外，具有不同源/目的地端口号对的不同单向到达流的分组可以通过中间盒映射到具有单个源/目的地端口号对的单个流。在这两种情况下，在中间盒的一侧观察到端口号对的值是恒定的，但在另一侧，值可能会有所不同。在这种情况下，不可能可靠地报告中间盒“另一侧”的端口号对。根据IPFIX信息模型[RFC5102]，在这种情况下，IPFIX协议会报告每个端口号的第一个观察值。
This recommendation applies to NAT (1), NAT-PT (2), SOCKS gateway (3) and involuntary packet redirection (21) middleboxes. It may also be applied to anonymizers (22), though it should be noted that this carries the risk of losing the effect of anonymization.
本建议适用于NAT（1）、NAT-PT（2）、SOCKS网关（3）和非自愿分组重定向（21）中间盒。它也适用于匿名化者（22），但应注意，这有失去匿名化效果的风险。
Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer Security (DTLS) [RFC4347] are the REQUIRED protocols for securing network traffic exported with IPFIX (see Section 11 of [RFC5101]). TLS requires a reliable transport channel and is selected as the security mechanism for TCP. DTLS is a version of TLS capable of securing datagram traffic and is selected for UDP, SCTP, and PR-SCTP.
传输层安全性（TLS）[RFC4346]和数据报传输层安全性（DTLS）[RFC4347]是保护使用IPFIX导出的网络流量所需的协议（见[RFC5101]第11节）。TLS需要可靠的传输通道，并被选为TCP的安全机制。DTLS是TLS的一个版本，能够保护数据报流量，并选择用于UDP、SCTP和PR-SCTP。
When mapping TLS terminology used in [RFC4346] to IPFIX terminology, keep in mind that the IPFIX Exporting Process, as it is the connection initiator, corresponds to the TLS client, and the IPFIX Collecting Process corresponds to the TLS server. These terms apply only to the bidirectional TLS handshakes done at Transport Session establishment and completion time; aside from TLS connection set up between the Exporting Process and the Collecting Process, and teardown at the end of the session, the unidirectional Flow of messages from Exporting Process to Collecting Process operates over TLS just as over any other transport layer for IPFIX.
将[RFC4346]中使用的TLS术语映射到IPFIX术语时，请记住，作为连接启动器的IPFIX导出过程对应于TLS客户端，而IPFIX收集过程对应于TLS服务器。这些术语仅适用于在传输会话建立和完成时完成的双向TLS握手；除了在导出进程和收集进程之间建立TLS连接以及在会话结束时断开之外，从导出进程到收集进程的单向消息流在TLS上运行，就像在IPFIX的任何其他传输层上运行一样。
When using TLS or DTLS to secure an IPFIX Transport Session, the Collecting Process and Exporting Process must use strong mutual authentication. In other words, each IPFIX endpoint must have its own X.509 certificate [RFC3280] and private key, and the Collecting Process, which acts as the TLS or DTLS server, must send a Certificate Request to the Exporting Process during the TLS handshake, and fail to establish a session if the Exporting Process does not present a valid certificate.
使用TLS或DTL保护IPFIX传输会话时，收集过程和导出过程必须使用强相互身份验证。换句话说，每个IPFIX端点都必须有自己的X.509证书[RFC3280]和私钥，作为TLS或DTLS服务器的收集进程必须在TLS握手期间向导出进程发送证书请求，如果导出进程不提供有效证书，则无法建立会话。
Each Exporting Process and Collecting Process must verify the identity of its peer against a set of authorized peers. This may be done by configuring a set of authorized distinguished names and comparing the peer certificate's subject distinguished name against each name in the set. However, if a private certification authority (CA) is used to sign the certificates identifying the Collecting Processes and Exporting Processes, and the set of certificates signed by that private CA may be restricted to those identifying peers authorized to communicate with each other, it is sufficient to merely verify that the peer's certificate is issued by this private CA.
每个导出进程和收集进程必须对照一组授权的对等方验证其对等方的身份。这可以通过配置一组授权的可分辨名称并将对等证书的使用者可分辨名称与该组中的每个名称进行比较来实现。但是，如果使用私有证书颁发机构（CA）对标识收集过程和导出过程的证书进行签名，并且由该私有CA签名的证书集可能仅限于标识授权相互通信的对等方的证书集，仅验证对等方的证书是否由该私有CA颁发就足够了。
When verifying the identity of its peer, an IPFIX Exporting Process or Collecting Process must verify that the peer certificate's subject common name or subjectAltName extension dNSName matches the fully-qualified domain name (FQDN) of the peer. This involves retrieving the expected domain name from the peer certificate and the address of the peer, then verifying that the two match via a DNS lookup. Such verification should require both that forward lookups (FQDN to peer address) and reverse lookups (peer address to FQDN) match. In deployments without DNS infrastructure, it is acceptable to represent the FQDN as an IPv4 dotted-quad or a textual IPv6 address as in [RFC1924].
验证其对等方的标识时，IPFIX导出进程或收集进程必须验证对等方证书的subject公用名或subjectAltName扩展名dNSName是否与对等方的完全限定域名（FQDN）匹配。这涉及从对等方证书和对等方地址检索期望的域名，然后通过DNS查找验证两者是否匹配。此类验证应要求前向查找（FQDN到对等地址）和反向查找（对等地址到FQDN）匹配。在没有DNS基础设施的部署中，可以将FQDN表示为IPv4虚线四元组或文本IPv6地址，如[RFC1924]中所示。
Of the security solutions specified for IPFIX, TLS over TCP is as of this writing the most mature and widely implemented. Until stable implementations of DTLS over SCTP are widely available (see Section 8.5, below), it is recommended that applications requiring secure transport for IPFIX Messages use TLS over TCP.
在为IPFIX指定的安全解决方案中，TCP上的TLS是到撰写本文时为止最成熟、实现最广泛的。在通过SCTP稳定地实现DTL之前（见下文第8.5节），建议需要IPFIX消息安全传输的应用程序使用TCP上的TLS。
When using TLS over TCP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using TCP as the transport protocol, especially as regards the handling of Templates and Template withdrawals.
通过TCP使用TLS时，IPFIX导出进程和收集进程在所有其他方面的行为应与使用TCP作为传输协议一样，特别是在处理模板和模板提取方面。
An implementation of the DTLS protocol version 1, described in [RFC4347] and required to secure IPFIX over UDP, is available in OpenSSL [OPENSSL] as of version 0.9.8. However, DTLS support is as of this writing under active development and certain implementations might be unstable. We recommend extensive testing of DTLS-based IPFIX implementations to build confidence in the DTLS stack over which your implementation runs.
[RFC4347]中描述的DTLS协议版本1的实现，以及通过UDP保护IPFIX所需的实现，从版本0.9.8开始，在OpenSSL[OpenSSL]中可用。然而，截至本文撰写时，DTLS支持仍处于积极开发阶段，某些实现可能不稳定。我们建议对基于DTLS的IPFIX实现进行广泛测试，以建立对运行实现的DTLS堆栈的信心。
When using DTLS over UDP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using UDP as the transport protocol, especially as regards the handling of Templates and Template timeouts.
在UDP上使用DTL时，IPFIX导出进程和收集进程在所有其他方面的行为应与使用UDP作为传输协议一样，特别是在处理模板和模板超时方面。
Note that the selection of IPFIX Message sizes for DTLS over UDP must account for overhead per packet introduced by the DTLS layer.
请注意，通过UDP为DTLS选择IPFIX消息大小必须考虑DTLS层引入的每个数据包的开销。
As of this writing, there is no publicly available implementation of DTLS over SCTP as described in [RFC4347] and [TUEXEN].
在撰写本文时，没有[RFC4347]和[TUEXEN]中所述的通过SCTP公开实现DTL。
When using DTLS over SCTP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using SCTP as the transport protocol, especially as regards the handling of Templates and the use of reliable transport for Template and scope information.
当通过SCTP使用DTL时，IPFIX导出过程和收集过程在所有其他方面的行为应与使用SCTP作为传输协议一样，特别是在处理模板以及使用模板和范围信息的可靠传输方面。
An implementation of the DTLS protocol version 1, described in [RFC4347] and required to secure IPFIX over SCTP, is available in OpenSSL [OPENSSL] as of version 0.9.8. However, DTLS support is as of this writing under active development and certain implementations might be unstable. We recommend extensive testing of DTLS-based IPFIX implementations to build confidence in the DTLS stack over which your implementation runs.
[RFC4347]中描述的DTLS协议版本1的实现，以及通过SCTP保护IPFIX所需的实现，从版本0.9.8开始，在OpenSSL[OpenSSL]中提供。然而，截至本文撰写时，DTLS支持仍处于积极开发阶段，某些实现可能不稳定。我们建议对基于DTLS的IPFIX实现进行广泛测试，以建立对运行实现的DTLS堆栈的信心。
IPFIX supports two sets of Information Elements: IANA-registered Information Elements and enterprise-specific Information Elements. New Information Elements can be added to both sets as described in this section. If an Information Element is considered of general interest, it should be added to the set of IETF-specified Information Elements that is maintained by IANA.
IPFIX支持两组信息元素：IANA注册信息元素和企业特定信息元素。如本节所述，可以将新的信息元素添加到这两个集合中。如果认为某个信息元素具有普遍意义，则应将其添加到IANA维护的IETF指定信息元素集中。
Alternatively, private enterprises can define proprietary Information Elements for internal purposes. There are several potential reasons for doing so. For example, the Information Element might only relate to proprietary features of a device or protocol of the enterprise. Also, pre-standard product delivery or commercially sensitive product features might cause the need for enterprise-specific Information Elements.
或者，私营企业可以为内部目的定义专有信息元素。这样做有几个潜在的原因。例如，信息元素可能仅与企业的设备或协议的专有功能相关。此外，预标准产品交付或商业敏感产品功能可能导致需要特定于企业的信息元素。
The IPFIX information model [RFC5102] document contains an XML-based specification of Template, abstract data types, and IPFIX Information Elements, which may be used to create consistent machine-readable extensions to the IPFIX information model. This description can be used for automatically checking syntactic correctness of the specification of IPFIX Information Elements and for generating code that deals with processing IPFIX Information Elements.
IPFIX信息模型[RFC5102]文档包含基于XML的模板、抽象数据类型和IPFIX信息元素规范，可用于创建IPFIX信息模型的一致机器可读扩展。此描述可用于自动检查IPFIX信息元素规范的语法正确性，并生成处理IPFIX信息元素的代码。
New IPFIX Information Elements that are considered to be of general interest should be added to the set of IETF-specified Information Elements that is maintained by IANA.
被认为具有普遍意义的新IPFIX信息元素应添加到IANA维护的IETF指定信息元素集中。
The introduction of new Information Elements in the IANA registry is subject to expert review. As described in Section 7.1 of [RFC5102], an expert review is performed by one of a group of experts designated by an IETF Operations and Management Area Director. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. The group of experts must double check the Information Elements definitions with already defined Information Elements for completeness, accuracy, redundancy, and correct naming following the naming conventions in [RFC5102], Section 2.3.
在IANA登记册中引入新的信息元素需要专家审查。如[RFC5102]第7.1节所述，专家评审由IETF运行和管理区域总监指定的专家组之一进行。专家最初将来自IPFIX和PSAMP工作组的工作组主席和文件编辑。专家组必须按照[RFC5102]第2.3节中的命名约定，使用已定义的信息元素对信息元素定义进行双重检查，以确保其完整性、准确性、冗余性和正确命名。
The specification of new IPFIX Information Elements must use the Template specified in [RFC5102], Section 2.1, and must be published using a well-established and persistent publication medium.
新IPFIX信息元素的规范必须使用[RFC5102]第2.1节中规定的模板，并且必须使用成熟且持久的发布介质发布。
Enterprises or other organizations holding a registered Structure of Management Information (SMI) network management private enterprise code number can specify enterprise-specific Information Elements. Their identifiers can be chosen arbitrarily within the range of 1-32767 and have to be coupled with a Private Enterprise Identifier [PEN]. Enterprise identifiers MUST be registered as SMI network management private enterprise code numbers with IANA. The registry can be found at http://www.iana.org/assignments/enterprise-numbers.
拥有注册管理信息结构（SMI）网络管理私有企业代码号的企业或其他组织可以指定特定于企业的信息元素。它们的标识符可以在1-32767范围内任意选择，并且必须与私有企业标识符[PEN]耦合。企业标识符必须在IANA中注册为SMI网络管理专用企业代码。可在以下网址找到注册表：http://www.iana.org/assignments/enterprise-numbers.
The issues listed in this section were identified during implementation and interoperability testing. They do not stem from insufficient clarity in the protocol, but each of these was an actual mistake made in a tested IPFIX implementation. They are listed here for the convenience of future implementers.
本节中列出的问题是在实施和互操作性测试期间确定的。它们并非源于协议不够清晰，但每一个都是在经过测试的IPFIX实现中犯下的实际错误。这里列出它们是为了方便将来的实现者。
A large group of mistakes stems from the fact that many implementers started implementing IPFIX from an existing version of NetFlow version 9 [RFC3954]. Despite their similarity, the two protocols differ in many aspects. We list here some of the most important differences.
大量错误源于这样一个事实，即许多实现者从NetFlow版本9[RFC3954]的现有版本开始实现IPFIX。尽管它们相似，但这两个协议在许多方面都不同。我们在此列出一些最重要的区别。
o Transport protocol: NetFlow version 9 initially ran over UDP, while IPFIX must have a congestion-aware transport protocol. IPFIX specifies PR-SCTP as its mandatory protocol, while TCP and UDP are optional.
o 传输协议：NetFlow版本9最初通过UDP运行，而IPFIX必须具有拥塞感知传输协议。IPFIX将PR-SCTP指定为其强制协议，而TCP和UDP是可选的。
o IPFIX differentiates between IANA-registered and enterprise-specific Information Elements. Enterprise-specific Information Elements can be specified by coupling a non-IANA-registered Information Element identifier with an Enterprise ID (corresponding to the vendor that defined the Information Element).
o IPFIX区分IANA注册信息元素和企业特定信息元素。通过将非IANA注册的信息元素标识符与企业ID（对应于定义信息元素的供应商）耦合，可以指定特定于企业的信息元素。
o Options Templates: in IPFIX, an Options Template must have a scope, and the scope is not allowed to be of length zero. The NetFlow version 9 specifications [RFC3954] don't specify that the scope must not be of length zero.
o 选项模板：在IPFIX中，选项模板必须具有作用域，且作用域的长度不允许为零。NetFlow版本9规范[RFC3954]未规定作用域的长度不得为零。
Message Header:
消息头：
o Set ID: Even if the packet headers are different between IPFIX and NetFlow version 9, similar fields are used in both of them. The difference between the two protocols is in the values that these fields can assume. A typical example is the Set ID values: the Set ID values of 0 and 1 are used in NetFlow version 9, while they are not used in IPFIX.
o Set ID：即使IPFIX和NetFlow版本9之间的数据包头不同，它们中也会使用类似的字段。这两个协议之间的区别在于这些字段可以假定的值。一个典型的例子是Set ID值：Set ID值0和1在NetFlow版本9中使用，而在IPFIX中不使用。
o Length field: in NetFlow version 9, this field (called count) contains the number of Records. In IPFIX, it indicates the total length of the IPFIX Message, measured in octets (including Message Header and Set(s)).
o 长度字段：在NetFlow版本9中，此字段（称为计数）包含记录数。在IPFIX中，它表示IPFIX消息的总长度，以八位字节为单位（包括消息头和集合）。
o Timestamp: the NetFlow version 9 header has an additional timestamp: sysUpTime. It indicates the time in milliseconds since the last reboot of the Exporting Process.
o 时间戳：NetFlow版本9标头有一个附加的时间戳：sysUpTime。它表示自上次重新启动导出进程以来的时间（以毫秒为单位）。
o The version number is different. NetFlow version 9 uses the version number 9, while IPFIX uses the version number 10.
o 版本号不同。NetFlow版本9使用版本号9，而IPFIX使用版本号10。
[RFC5101] specifies that the Exporting Process MAY insert some octets for set padding to align Data Sets within a Message. The padding length must be shorter than any allowable Record in that set.
[RFC5101]指定导出过程可以插入一些八位字节用于设置填充，以对齐消息中的数据集。填充长度必须小于该集合中任何允许的记录。
It is important to respect this limitation: if the padding length is equal to or longer than the length of the shortest Record, it will be interpreted as another Record.
尊重这一限制很重要：如果填充长度等于或大于最短记录的长度，它将被解释为另一条记录。
An alternative is to use the paddingOctets Information Element in the Template definition.
另一种方法是在模板定义中使用paddingOctets信息元素。
Information Element numbers in IPFIX have the range 0-32767 (0-0x7FFF). Information Element numbers outside this range (i.e., with the high bit set) are taken to be enterprise-specific Information Elements, which have an additional four-byte Private Enterprise Number following the Information Element number and length. Inadvertently setting the high bit of the Information Element number by selecting a number out of this range will therefore cause Template scanning errors.
IPFIX中的信息元素编号的范围为0-32767（0-0x7FFF）。超出此范围的信息元素编号（即，具有高位集）被视为特定于企业的信息元素，在信息元素编号和长度之后有一个额外的四字节私有企业编号。因此，通过选择超出此范围的数字无意中设置信息元素编号的高位将导致模板扫描错误。
Template IDs are generated as required by the Exporting Process. When the same set of Information Elements is exported at different times, the corresponding Template is usually identified by different Template IDs. Similarly, if multiple co-existing Templates are composed of the same set of Information Elements, they are also identified by different Template IDs. The Collecting Process does not know in advance which Template ID a particular Template will use.
模板ID是根据导出过程的要求生成的。当在不同的时间导出同一组信息元素时，相应的模板通常由不同的模板ID标识。类似地，如果多个共存的模板由同一组信息元素组成，则它们也由不同的模板ID标识。收集过程事先不知道特定模板将使用哪个模板ID。
This document describes the implementation guidelines of IPFIX. The security requirements for the IPFIX target applications are addressed in the IPFIX requirements document [RFC3917]. These requirements are considered for the specification of the IPFIX protocol [RFC5101], for which a Security Considerations Section exists.
本文档描述了IPFIX的实施指南。IPFIX目标应用程序的安全要求在IPFIX要求文档[RFC3917]中有说明。IPFIX协议[RFC5101]的规范考虑了这些要求，其中有一个安全注意事项部分。
Section 7 of this document recommends that IPFIX Exporting Processes report internals about middleboxes. These internals may be security-relevant, and the reported information needs to be protected appropriately for reasons given below.
本文件第7节建议IPFIX导出流程报告有关中间盒的内部信息。这些内部构件可能与安全相关，出于以下原因，需要对报告的信息进行适当保护。
Reporting of packets dropped by firewalls and other packet-dropping middleboxes carries the risk that this information can be used by attackers for analyzing the configuration of the middlebox and for developing attacks against it. Address translation may be used for hiding the network structure behind an address translator. If an IPFIX Exporting Process reports the translations performed by an address translator, then parts of the network structure may be revealed. If an IPFIX Exporting Process reports the translations performed by an anonymizer, the main function of the anonymizer may be compromised.
报告防火墙和其他数据包丢弃中间盒丢弃的数据包存在这样的风险，即攻击者可以利用这些信息来分析中间盒的配置并对其发起攻击。地址转换可用于将网络结构隐藏在地址转换器后面。如果IPFIX导出过程报告地址转换器执行的翻译，则可能会显示部分网络结构。如果IPFIX导出过程报告匿名者执行的翻译，则匿名者的主要功能可能会受损。
Note that there exist vulnerabilities in DTLS over SCTP as specified in the IPFIX protocol, such that a third party could cause messages to be undetectably lost, or an SCTP association to shut down. These
请注意，在IPFIX协议中指定的通过SCTP的DTL中存在漏洞，例如第三方可能导致无法检测到的消息丢失，或SCTP关联关闭。这些
vulnerabilities are addressed by [TUEXEN]; however, it is unclear whether initial OpenSSL-based implementations of DTLS over SCTP will contain the required fixes. DTLS over SCTP should be used with caution in production environments until these issues are completely addressed.
漏洞由[TUEXEN]解决；然而，尚不清楚最初基于OpenSSL的SCTP DTL实现是否包含所需的修复。在完全解决这些问题之前，在生产环境中应谨慎使用SCTP上的DTL。
We would like to thank the MoMe project for organizing two IPFIX Interoperability Events in July 2005 and in March 2006, and Fraunhofer Fokus for organizing the third one in November 2006. The Interoperability Events provided us precious input for this document. Thanks to Brian Trammell for his contributions to the SCTP section and the security guidelines and for the multiple thorough reviews. We would also like to thank Benoit Claise, Carsten Schmoll, and Gerhard Muenz for the technical review and feedback, and Michael Tuexen, Randall Stewart, and Peter Lei for reviewing the SCTP section.
我们要感谢MoMe项目在2005年7月和2006年3月组织了两次IPFIX互操作性活动，并感谢Fraunhofer Fokus在2006年11月组织了第三次活动。互操作性事件为我们提供了本文档的宝贵输入。感谢Brian Trammell对SCTP部分和安全指南的贡献，以及多次全面审查。我们还要感谢Benoit Claise、Carsten Schmoll和Gerhard Muenz的技术审查和反馈，以及Michael Tuexen、Randall Stewart和Peter Lei对SCTP部分的审查。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101]Claise，B.，Ed.，“交换IP流量信息的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102]Quitek，J.，Bryant，S.，Claise，B.，Aitken，P.，和J.Meyer，“IP流信息导出的信息模型”，RFC 5102，2008年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, July 2007.
[IPFIX-AS]Zseby，T.，Boschi，E.，Brownlee，N.，和B.Claise，“IPFIX适用性”，正在进行的工作，2007年7月。
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", Work in Progress, September 2006.
[IPFIX-ARCH]Sadasivan，G.，Brownlee，N.，Claise，B.，和J.Quitek，“IP流信息导出的体系结构”，正在进行的工作，2006年9月。
[IPFIX-REDUCING] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", Work in Progress, May 2007.
[IPFIX-减少]Boschi，E.，Mark，L.，和B.Claise，“减少IP流信息导出（IPFIX）和数据包采样（PSAMP）报告中的冗余”，正在进行的工作，2007年5月。
[PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet Sampling (PSAMP) Protocol Specifications", Work in Progress, December 2007.
[PSAMP-PROTO]Claise，B.，Quittek，J.，和A.Johnson，“数据包采样（PSAMP）协议规范”，正在进行的工作，2007年12月。
[TUEXEN] Tuexen, M. and E. Rescorla, "Datagram Transport Layer Security for Stream Control Transmission Protocol", Work in Progress, November 2007.
[TUEXEN]TUEXEN，M.和E.Rescorla，“流控制传输协议的数据报传输层安全”，正在进行的工作，2007年11月。
[TSVWG-UDP] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for Application Designers", Work in Progress, February 2008.
[TSVWG-UDP]Eggert，L.和G.Fairhurst，“应用程序设计者的UDP使用指南”，正在进行的工作，2008年2月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC1305，1992年3月。
[RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", RFC 1924, April 1996.
[RFC1924]Elz，R.，“IPv6地址的紧凑表示”，RFC19241996年4月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917]Quitek，J.，Zseby，T.，Claise，B.，和S.Zander，“IP流信息导出（IPFIX）的要求”，RFC 39172004年10月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954]Claise，B.，Ed.，“Cisco Systems NetFlow服务导出版本9”，RFC 3954，2004年10月。
[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月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[OPENSSL] OpenSSL, "OpenSSL: The Open Source toolkit for SSL/ TLS", <http://www.openssl.org/>.
[OPENSSL]OPENSSL，“OPENSSL:SSL/TLS的开源工具包”<http://www.openssl.org/>.
[PEN] IANA, "PRIVATE ENTERPRISE NUMBERS", <http:// www.iana.org/assignments/enterprise-numbers>.
[PEN]IANA，“私营企业编号”，<http://www.IANA.org/assignments/ENTERPRISE NUMBERS>。
Authors' Addresses
作者地址
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastr. 35 8092 Zurich Switzerland
Elisa Boschi Hitachi Europe，由苏黎世格洛里亚斯特ETH转交。358092苏黎世瑞士
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.com
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.com
Lutz Mark Fraunhofer FOKUS Kaiserin Augusta Allee 31 10589 Berlin Germany
卢茨马克·弗劳恩霍夫·福库斯·凯瑟林·奥古斯塔·阿莱31 10589德国柏林
Phone: +49 421 2246-206
EMail: lutz.mark@ifam.fraunhofer.de
Phone: +49 421 2246-206
EMail: lutz.mark@ifam.fraunhofer.de
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
德国海德堡Juergen Quittek NEC欧洲有限公司Kurfuersten Anlage 36 69115
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
Martin Stieemerling NEC欧洲有限公司Kurfuersten Anlage 36 69115德国海德堡
Phone: +49 6221 4342-113
EMail: stiemerling@nw.neclab.eu
Phone: +49 6221 4342-113
EMail: stiemerling@nw.neclab.eu
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland
Paul Aitken Cisco Systems，Inc.96爱丁堡商业码头EH6 6LX苏格兰
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.