doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc5153.txt b/doc/rfc/rfc5153.txt
new file mode 100644
index 0000000..25d0e61
--- /dev/null
+++ b/doc/rfc/rfc5153.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+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
+
+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.).
+
+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
+
+
+
+Boschi, et al.               Informational                      [Page 1]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+       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
+
+
+
+
+
+
+
+Boschi, et al.               Informational                      [Page 2]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+1.  Introduction
+
+   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.
+
+   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.
+
+1.1.  IPFIX Documents Overview
+
+   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].
+
+   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 has a formal description of IPFIX Information Elements, their
+   name, type, and additional semantic information, as specified in the
+   IPFIX information model [RFC5102].
+
+   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.
+
+1.2.  Overview of the IPFIX Protocol
+
+   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.
+
+   Since Templates are sent very infrequently compared with Data
+   Records, this results in significant bandwidth savings.
+
+
+
+
+
+Boschi, et al.               Informational                      [Page 3]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+   The IPFIX information model [RFC5102] defines a large number of
+   standard Information Elements that provide the necessary
+   { type } information for Templates.
+
+   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.
+
+2.  Terminology
+
+   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]).
+
+   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].
+
+   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.
+
+3.  Template Management Guidelines
+
+3.1.  Template Management
+
+   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
+
+
+
+
+
+Boschi, et al.               Informational                      [Page 4]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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).
+
+   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.
+
+   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.
+
+3.2.  Template Records versus Options Template Records
+
+   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]).
+
+   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.
+
+   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].
+
+
+
+
+Boschi, et al.               Informational                      [Page 5]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+3.3.  Using Scopes
+
+   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.
+
+   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.
+
+   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).
+
+3.4.  Multiple Information Elements of the Same Type
+
+   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.
+
+3.5.  Selecting Message Size
+
+   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].
+
+
+
+
+Boschi, et al.               Informational                      [Page 6]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+4.  Exporting Process Guidelines
+
+4.1.  Sets
+
+   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.
+
+   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).
+
+   The arrival of a Set with a reserved Set ID should be logged, and the
+   Collector must ignore the Set.
+
+4.2.  Information Element Coding
+
+   [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.
+
+   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.
+
+
+
+
+
+
+
+Boschi, et al.               Informational                      [Page 7]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+4.3.  Using Counters
+
+   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:
+
+   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  the metering system must carefully maintain its counters and
+      report the running total using Total counters.
+
+   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].
+
+   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.
+
+4.4.  Padding
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+Boschi, et al.               Informational                      [Page 8]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+4.4.1.  Alignment of Information Elements within a Data Record
+
+   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.
+
+4.4.2.  Alignment of Information Element Specifiers within a Template
+        Record
+
+   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.
+
+4.4.3.  Alignment of Records within a Set
+
+   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.
+
+   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.
+
+4.4.4.  Alignment of Sets within an IPFIX Message
+
+   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.
+
+
+
+Boschi, et al.               Informational                      [Page 9]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+4.5.  Time Issues
+
+   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.
+
+   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.
+
+   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).
+
+4.6.  IPFIX Message Header Export Time and Data Record Time
+
+   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.
+
+   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.
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 10]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+4.7.  Devices without an Absolute Clock
+
+   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.
+
+   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.
+
+5.  Collecting Process Guidelines
+
+5.1.  Information Element (De)Coding
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 11]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+5.2.  Reduced-Size Encoding of Information Elements
+
+   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.
+
+5.3.  Template Management
+
+   Template IDs are generated dynamically by the Exporting Process.
+   They are unique per Transport Session and Observation Domain.
+
+   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.
+
+   Note that a restart of the Transport Session may lead to a Template
+   ID renumbering.
+
+6.  Transport-Specific Guidelines
+
+   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.
+
+6.1.  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.
+
+   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.
+
+   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
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 12]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   [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.
+
+
+
+Boschi, et al.               Informational                     [Page 13]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+   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.
+
+   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.
+
+   The following may be done to mitigate message loss:
+
+   o  Increase the SCTP buffer size on the Exporter.
+
+   o  Increase the bandwidth available for communicating the exported
+      Data Records.
+
+   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  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).
+
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 14]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   If the SCTP association is brought down because the IFPIX Messages
+   can't be exported reliably, the options are:
+
+   o  Increase the SCTP buffer size on the Exporter.
+
+   o  Increase the bandwidth available for communicating the exported
+      Data Records.
+
+   o  Use sampling, filtering, or aggregation in the Metering Process to
+      reduce the amount of exported data.
+
+   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.
+
+6.2.  UDP
+
+   UDP is useful in simple systems where an SCTP stack is not available,
+   and where there is insufficient memory for TCP buffering.
+
+   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:
+
+   o  A dedicated network,
+
+   o  within a single administrative domain,
+
+   o  where SCTP is not available due to implementation constraints, and
+
+   o  the Collector is as topologically close as possible to the
+      Exporter.
+
+
+
+Boschi, et al.               Informational                     [Page 15]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+   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.
+
+   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).
+
+   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]).
+
+   We recommend a default Template-resend time of 10 minutes,
+   configurable between 1 minute and 1 day.
+
+   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.
+
+   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.
+
+
+
+
+Boschi, et al.               Informational                     [Page 16]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   We recommend a default Template-resend interval of 20 packets,
+   configurable between 1 and 1000 data packets.
+
+   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.
+
+   The Collecting Process should use the Sequence Number in the IPFIX
+   Message Header to determine whether any messages are lost.
+
+   The following may be done to mitigate message loss:
+
+   o  Move the Collector topologically closer to the Exporter.
+
+   o  Increase the bandwidth of the links through which the Data Records
+      are exported.
+
+   o  Use sampling, filtering, or aggregation in the Metering Process to
+      reduce the amount of exported data.
+
+   o  Increase the buffer size at the Collector and/or the Exporter.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 17]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+6.3.  TCP
+
+   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.
+
+   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]:
+
+   "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:
+
+   o  Increase the TCP buffer size on the Exporter.
+
+   o  Increase the bandwidth of the links through which the Data Records
+      are exported.
+
+   o  Use sampling, filtering, or aggregation in the Metering Process to
+      reduce the amount of exported data.
+
+7.  Guidelines for Implementation on Middleboxes
+
+   The term middlebox is defined in [RFC3234] as:
+
+   "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."
+
+   The list of middleboxes discussed in [RFC3234] contains:
+
+   1.   Network Address Translation (NAT),
+
+   2.   NAT-Protocol Translation (NAT-PT),
+
+
+
+
+Boschi, et al.               Informational                     [Page 18]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   3.   SOCKS gateway,
+
+   4.   IP tunnel endpoints,
+
+   5.   packet classifiers, markers, schedulers,
+
+   6.   transport relay,
+
+   7.   TCP performance enhancing proxies,
+
+   8.   load balancers that divert/munge packets,
+
+   9.   IP firewalls,
+
+   10.  application firewalls,
+
+   11.  application-level gateways,
+
+   12.  gatekeepers / session control boxes,
+
+   13.  transcoders,
+
+   14.  proxies,
+
+   15.  caches,
+
+   16.  modified DNS servers,
+
+   17.  content and applications distribution boxes,
+
+   18.  load balancers that divert/munge URLs,
+
+   19.  application-level interceptors,
+
+   20.  application-level multicast,
+
+   21.  involuntary packet redirection,
+
+   22.  anonymizers.
+
+   It is likely that since the publication of RFC 3234 new kinds of
+   middleboxes have been added.
+
+   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.
+
+
+
+Boschi, et al.               Informational                     [Page 19]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+7.1.  Traffic Flow Scenarios at Middleboxes
+
+   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 ---->| middlebox |----> T'
+                                 +-----------+
+
+       Figure 1: Unidirectional traffic Flow traversing a middlebox
+
+   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.
+
+   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'''
+
+     Figure 2: Unidirectional traffic Flow traversing a middlebox with
+                            multicast function
+
+   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 <--->| middlebox |<---> T_r
+                                 +-----------+
+
+    Figure 3: Bidirectional unicast traffic Flow traversing a middlebox
+
+   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.
+
+
+
+Boschi, et al.               Informational                     [Page 20]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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
+
+                     Figure 4: Multiple data reduction
+
+   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.
+
+   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.
+
+7.2.  Location of the Observation Point
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+Boschi, et al.               Informational                     [Page 21]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   firewall dropped packets.  For this reason, [RFC5102] provides
+   Information Elements with prefix "post" for Flow properties that are
+   changed within a middlebox.
+
+   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.
+
+7.3.  Reporting Flow-Related Middlebox Internals
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 22]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+7.3.1.  Packet Dropping Middleboxes
+
+   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.
+
+   Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS gateway
+   (3), packet schedulers (5), IP firewalls (9) and application-level
+   firewalls (10).
+
+7.3.2.  Middleboxes Changing the DSCP
+
+   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.
+
+   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.
+
+   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.
+
+   This recommendation applies to packet markers (5).
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 23]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+7.3.3.  Middleboxes Changing IP Addresses and Port Numbers
+
+   If an IPFIX Observation Point is co-located with one or more
+   middleboxes that potentially modify the:
+
+   o  IP version field,
+
+   o  IP source address header field,
+
+   o  IP destination address header field,
+
+   o  Source transport port number, or
+
+   o  Destination transport port number
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 24]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+8.  Security Guidelines
+
+8.1.  Introduction to TLS and DTLS for IPFIX Implementers
+
+   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.
+
+   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.
+
+8.2.  X.509-Based Identity Verification for IPFIX over TLS or DTLS
+
+   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.
+
+   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.
+
+
+
+Boschi, et al.               Informational                     [Page 25]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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].
+
+8.3.  Implementing IPFIX over TLS over TCP
+
+   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.
+
+   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.
+
+8.4.  Implementing IPFIX over DTLS over UDP
+
+   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.
+
+   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.
+
+   Note that the selection of IPFIX Message sizes for DTLS over UDP must
+   account for overhead per packet introduced by the DTLS layer.
+
+
+
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 26]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+8.5.  Implementing IPFIX over DTLS over SCTP
+
+   As of this writing, there is no publicly available implementation of
+   DTLS over SCTP as described in [RFC4347] and [TUEXEN].
+
+   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.
+
+   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.
+
+9.  Extending the Information Model
+
+   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.
+
+   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.
+
+9.1.  Adding New IETF-Specified Information Elements
+
+   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.
+
+
+
+Boschi, et al.               Informational                     [Page 27]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+   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.
+
+9.2.  Adding Enterprise-Specific Information Elements
+
+   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.
+
+10.  Common Implementation Mistakes
+
+   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.
+
+10.1.  IPFIX and NetFlow Version 9
+
+   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.
+
+   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.
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 28]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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  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.
+
+   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  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  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  The version number is different.  NetFlow version 9 uses the
+      version number 9, while IPFIX uses the version number 10.
+
+10.2.  Padding of the Data Set
+
+   [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.
+
+   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.
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 29]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+10.3.  Field ID Numbers
+
+   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.
+
+10.4.  Template ID Numbers
+
+   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.
+
+11.  Security Considerations
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+Boschi, et al.               Informational                     [Page 30]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   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.
+
+12.  Acknowledgments
+
+   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.
+
+13.  References
+
+13.1.  Normative References
+
+   [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.
+
+   [RFC5102]         Quittek, J., Bryant, S., Claise, B., Aitken, P.,
+                     and J. Meyer, "Information Model for IP Flow
+                     Information Export", RFC 5102, January 2008.
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+13.2.  Informative References
+
+   [IPFIX-AS]        Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
+                     "IPFIX Applicability", Work in Progress, July 2007.
+
+   [IPFIX-ARCH]      Sadasivan, G., Brownlee, N., Claise, B., and J.
+                     Quittek, "Architecture for IP Flow Information
+                     Export", Work in Progress, September 2006.
+
+   [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.
+
+
+
+Boschi, et al.               Informational                     [Page 31]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   [PSAMP-PROTO]     Claise, B., Quittek, J., and A. Johnson, "Packet
+                     Sampling (PSAMP) Protocol Specifications", Work
+                     in Progress, December 2007.
+
+   [TUEXEN]          Tuexen, M. and E. Rescorla, "Datagram Transport
+                     Layer Security for Stream Control Transmission
+                     Protocol", Work in Progress, November 2007.
+
+   [TSVWG-UDP]       Eggert, L. and G. Fairhurst, "UDP Usage Guidelines
+                     for Application Designers", Work in Progress,
+                     February 2008.
+
+   [RFC1305]         Mills, D., "Network Time Protocol (Version 3)
+                     Specification, Implementation and Analysis",
+                     RFC 1305, March 1992.
+
+   [RFC1924]         Elz, R., "A Compact Representation of IPv6
+                     Addresses", RFC 1924, April 1996.
+
+   [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.
+
+   [RFC3234]         Carpenter, B. and S. Brim, "Middleboxes: Taxonomy
+                     and Issues", RFC 3234, February 2002.
+
+   [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.
+
+   [RFC3758]         Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and
+                     P. Conrad, "Stream Control Transmission Protocol
+                     (SCTP) Partial Reliability Extension", RFC 3758,
+                     May 2004.
+
+   [RFC3917]         Quittek, J., Zseby, T., Claise, B., and S. Zander,
+                     "Requirements for IP Flow Information Export
+                     (IPFIX)", RFC 3917, October 2004.
+
+   [RFC3954]         Claise, B., Ed., "Cisco Systems NetFlow Services
+                     Export Version 9", RFC 3954, October 2004.
+
+   [RFC4346]         Dierks, T. and E. Rescorla, "The Transport Layer
+                     Security (TLS) Protocol Version 1.1", RFC 4346,
+                     April 2006.
+
+
+
+
+Boschi, et al.               Informational                     [Page 32]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   [RFC4347]         Rescorla, E. and N. Modadugu, "Datagram Transport
+                     Layer Security", RFC 4347, April 2006.
+
+   [RFC4960]         Stewart, R., Ed., "Stream Control Transmission
+                     Protocol", RFC 4960, September 2007.
+
+   [OPENSSL]         OpenSSL, "OpenSSL: The Open Source toolkit for SSL/
+                     TLS", <http://www.openssl.org/>.
+
+   [PEN]             IANA, "PRIVATE ENTERPRISE NUMBERS", <http://
+                     www.iana.org/assignments/enterprise-numbers>.
+
+Authors' Addresses
+
+   Elisa Boschi
+   Hitachi Europe
+   c/o ETH Zurich
+   Gloriastr. 35
+   8092 Zurich
+   Switzerland
+
+   Phone: +41 44 6327057
+   EMail: elisa.boschi@hitachi-eu.com
+
+
+   Lutz Mark
+   Fraunhofer FOKUS
+   Kaiserin Augusta Allee 31
+   10589 Berlin
+   Germany
+
+   Phone: +49 421 2246-206
+   EMail: lutz.mark@ifam.fraunhofer.de
+
+
+   Juergen Quittek
+   NEC Europe Ltd.
+   Kurfuersten-Anlage 36
+   69115 Heidelberg
+   Germany
+
+   Phone: +49 6221 4342-115
+   EMail: quittek@nw.neclab.eu
+
+
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 33]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+   Martin Stiemerling
+   NEC Europe Ltd.
+   Kurfuersten-Anlage 36
+   69115 Heidelberg
+   Germany
+
+   Phone: +49 6221 4342-113
+   EMail: stiemerling@nw.neclab.eu
+
+
+   Paul Aitken
+   Cisco Systems, Inc.
+   96 Commercial Quay
+   Edinburgh  EH6 6LX
+   Scotland
+
+   Phone: +44 131 561 3616
+   EMail: paitken@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 34]
+
+RFC 5153            IPFIX Implementation Guidelines           April 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (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.
+
+   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.
+
+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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Boschi, et al.               Informational                     [Page 35]
+