RFC 5610
Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements
RFC 5610: Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements 🎀
Okay bestie, let's start with the title block 💅 This is RFC 5610, published in July 2009 as a Standards Track document in the Network Working Group. The authors are E. Boschi and B. Trammell from Hitachi Europe, L. Mark from Fraunhofer IFAM, and T. Zseby from Fraunhofer FOKUS. The title block doesn't list anything it obsoletes or updates, so this one stands on its own 🦋
Abstract ✨
So this doc extends IPFIX (IP Flow Information Export), the protocol that carries data from flow measurement devices to collection, storage, and analysis 🌸 It lets you encode IPFIX Information Model properties inside an IPFIX Message stream. That means you can export extended type info for enterprise-specific Information Elements and store that info in IPFIX Files. The payoff is way better interoperability and reusability across a whole bunch of apps and tools 💜
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. To check the standardization state and status of this protocol, look at the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🧚
Copyright Notice 🔐
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please read those carefully, because they spell out your rights and restrictions with respect to this document 🙈
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Type Information Export . . . . . . . . . . . . . . . . . . . 5
3.1. informationElementDataType . . . . . . . . . . . . . . . . 5
3.2. informationElementDescription . . . . . . . . . . . . . . 6
3.3. informationElementName . . . . . . . . . . . . . . . . . . 7
3.4. informationElementRangeBegin . . . . . . . . . . . . . . . 7
3.5. informationElementRangeEnd . . . . . . . . . . . . . . . . 7
3.6. informationElementSemantics . . . . . . . . . . . . . . . 8
3.7. informationElementUnits . . . . . . . . . . . . . . . . . 9
3.8. privateEnterpriseNumber . . . . . . . . . . . . . . . . . 9
3.9. Information Element Type Options Template . . . . . . . . 10
3.10. Data Type and Semantics Restrictions . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 171. Introduction ✨
IPFIX gives you a template mechanism for describing Data Records flexibly. A record is a collection of Information Elements defined in an IANA registry. The catch is that Templates only give limited info about the type of the data, since they encode just the size of the fields those Information Elements define. Right now there's no mechanism that provides full type information for these Information Elements, the way the IPFIX Information Model does for its own Information Elements [RFTC5102]. 😭
Hmm, correcting my own typo on that citation: it must be written exactly as in the original, so here it is with the correct citation:
This is a big deal for enterprise-specific Information Elements 🥺 Analysis tools can't use IPFIX records containing these partially defined Information Elements unless the tools were built knowing their types, because otherwise they can't decode them. They can only treat and store them as opaque octet arrays. But if richer information is available, things like efficient storage, display, and limited analysis become possible, even for Collecting Processes that were never specifically built to understand those Information Elements 🔥
This document defines a general mechanism to encode the full set of properties available for defining Information Elements in the IPFIX Information Model. It goes inline within an IPFIX Message stream using IPFIX Options. The mechanism can fully define type information for Information Elements used within a message stream, without needing an external reference or out-of-band configuration. That's how it improves interoperability for enterprise-specific Information Elements 👑
Note that this solution is not meant to replace registering generally useful Information Elements with IANA. It adds overhead and doesn't give you real interoperability the way standardization does. So we highly recommend standardizing all new generally useful Information Elements by registering them with IANA. Standardization is straightforward, and the type information you'd specify for this solution is a perfect basis for describing the Information Element you're standardizing 💅
It might happen that an Information Element previously described by this mechanism later becomes a standard, IANA-registered Information Element. In that case, old and new versions can coexist. A translation between Information Elements described by this solution and standardized ones is therefore not necessary, and it's out of scope for this document 🦋
1.1. IPFIX Documents Overview
Okay, so there's a family of IPFIX docs and this one builds on them. First up is "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information" [RFC5101], informally the IPFIX Protocol document. Together with its associated documents, it defines the IPFIX Protocol, which gives network engineers and administrators access to IP traffic flow information 🌈
Next is "Architecture for IP Flow Information Export" [RFC5470], the IPFIX Architecture document. It defines the architecture for exporting measured IP flow information from an IPFIX Exporting Process to an IPFIX Collecting Process, plus the basic terminology used to describe the parts of that architecture. It does this per the requirements in "Requirements for IP Flow Information Export" [RFC3917]. The IPFIX Protocol document [RFC5101] then covers how IPFIX Data Records and Templates get transported via a congestion-aware transport protocol from an IPFIX Exporting Process to an IPFIX Collecting Process 🚀
Then there's "Information Model for IP Flow Information Export" [RFC5102], informally the IPFIX Information Model document. It describes the Information Elements used by IPFIX, including details on Information Element naming, numbering, and data type encoding ⭐
This document references the Protocol and Architecture documents for terminology. It also extends the IPFIX Information Model with new Information Elements for representing Information Element properties. It draws data type definitions and data type semantics definitions from the Information Model, and the encodings of those data types are defined in [RFC5101] 🫶
2. Terminology 🧚
Terms used in this document that are defined in the Terminology section of the IPFIX Protocol [RFC5101] document are to be interpreted as defined there.
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 RFC 2119 [RFC2119] 🔥
3. Type Information Export 🌸
This section describes the mechanism for encoding Information Element type information within an IPFIX Message stream. The mechanism has two parts: an Options Template Record used to define Information Element type records, and a set of Information Elements required by those type records. We'll go over the necessary Information Elements first, then the structure of the Options Template describing the type records 💖
Information Element type records require one Information Element, informationElementId, which is defined in the Packet Sampling (PSAMP) Information Model [RFC5477]. This Information Element supports references only to IANA-defined Information Elements. To describe enterprise-specific Information Elements, the privateEnterpriseNumber Information Element is required alongside informationElementId 🍓
3.1. informationElementDataType
Description: A description of the abstract data type of an IPFIX information element. These are taken from the abstract data types defined in Section 3.1 of the IPFIX Information Model [RFC5102]. See that section for more information on the types described below. This field may take the values defined in Table 1 below.
+-------+----------------------+
| Value | Description |
+-------+----------------------+
| 0 | octetArray |
| 1 | unsigned8 |
| 2 | unsigned16 |
| 3 | unsigned32 |
| 4 | unsigned64 |
| 5 | signed8 |
| 6 | signed16 |
| 7 | signed32 |
| 8 | signed64 |
| 9 | float32 |
| 10 | float64 |
| 11 | boolean |
| 12 | macAddress |
| 13 | string |
| 14 | dateTimeSeconds |
| 15 | dateTimeMilliseconds |
| 16 | dateTimeMicroseconds |
| 17 | dateTimeNanoseconds |
| 18 | ipv4Address |
| 19 | ipv6Address |
+-------+----------------------+
Table 1: IE Data Type ValuesThese types are registered in the IANA IPFIX Information Element Data Type subregistry. This subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol. As such, it requires a Standards Action [RFC5226] to modify 🌷
Abstract Data Type: unsigned8
ElementId: 339
Status: current
Reference: Section 3.1 of the IPFIX Information Model [RFC5102]
3.2. informationElementDescription 📝
okay bestie, this one is the human-readable blurb for an Information Element 💖 It's a UTF-8 [RFC3629] encoded Unicode string, so it's basically the "here's what this thing is" caption. The content of the informationElementDescription MAY be annotated with one or more language tags [RFC4646], encoded in-line [RFC2482] within the UTF-8 string, so you can say which language it's written in 🌍 Multiple languages are allowed too. Each section can get its own language tag, and in that case the description in each language SHOULD have equivalent meaning 🫶 If there's no language tag at all, the "i-default" [RFC2277] language SHOULD be assumed ✨ Also, see the Security Considerations (Section 4) for notes on string handling for Information Element type records 🙈
Abstract Data Type: string
ElementId: 340
Status: current
3.3. informationElementName 🏷️
this is the name of an Information Element, kind of like its nickname 🎀 It's a UTF-8 [RFC3629] encoded Unicode string, and it's meant to be a simple identifier. Same deal as before: see the Security Considerations (Section 4) for notes on string handling for Information Element type records 💅
Abstract Data Type: string
ElementId: 341
Status: current
3.4. informationElementRangeBegin 🌸
this one holds the inclusive low end of the range of acceptable values for an Information Element. "Inclusive" means the bottom value counts as part of the range 🦋
Abstract Data Type: unsigned64
Data Type Semantics: quantity
ElementId: 342
Status: current
3.5. informationElementRangeEnd 🌈
the other end of the range! This is the inclusive high end of the range of acceptable values for an Information Element. Same energy as RangeBegin, just at the top 🧚
Abstract Data Type: unsigned64
Data Type Semantics: quantity
ElementId: 343
Status: current
3.6. informationElementSemantics 🧠
this is a description of the semantics of an IPFIX Information Element, so it tells you what kind of thing the value means 💜 The values are taken from the data type semantics defined in Section 3.2 of the IPFIX Information Model [RFC5102], so check that section if you want the deep dive on each one. This field may take the values in Table 2 below. The special value 0x00 (default) is used to note that no semantics apply to the field 🫠 It can't be manipulated by a Collecting Process or File Reader that doesn't understand it a priori, so no sneaking around it, periodt 💅
+-------+--------------+
| Value | Description |
+-------+--------------+
| 0 | default |
| 1 | quantity |
| 2 | totalCounter |
| 3 | deltaCounter |
| 4 | identifier |
| 5 | flags |
+-------+--------------+
Table 2: IE Semantics ValuesThese semantics are registered in the IANA IPFIX Information Element Semantics subregistry 📋 That subregistry is meant for assigning numbers to semantics names. It is not a way to add new semantics to the IPFIX Protocol, so it's giving "gatekeeping" 👑 Changing it takes a Standards Action [RFC5226].
Abstract Data Type: unsigned8
ElementId: 344
Status: current
Reference: Section 3.2 of the IPFIX Information Model [RFC5102]
3.7. informationElementUnits 📏
this is a description of the units of an IPFIX Information Element, like whether you're counting bits, octets, packets, or seconds 🍓 These line up with the units implicitly defined in the Information Element definitions in Section 5 of the IPFIX Information Model [RFC5102], so go there for more details on the types below. This field may take the values in Table 3 below. The special value 0x00 (none) means the field is unitless ✨
+-------+---------------+---------------------------+
| Value | Name | Notes |
+-------+---------------+---------------------------+
| 0 | none | |
| 1 | bits | |
| 2 | octets | |
| 3 | packets | |
| 4 | flows | |
| 5 | seconds | |
| 6 | milliseconds | |
| 7 | microseconds | |
| 8 | nanoseconds | |
| 9 | 4-octet words | for IPv4 header length |
| 10 | messages | for reliability reporting |
| 11 | hops | for TTL |
| 12 | entries | for MPLS label stack |
+-------+---------------+---------------------------+
Table 3: IE Units ValuesThese types are registered in the IANA IPFIX Information Element Units subregistry 🗂️ New types may be added on a First Come First Served [RFC5226] basis, so if you've got a unit in mind, you can get it in there 🙌
Abstract Data Type: unsigned16
ElementId: 345
Status: current
Reference: Section 5 of the IPFIX Information Model [RFC5102]
3.8. privateEnterpriseNumber 🏢
this is a private enterprise number, as assigned by IANA 🎟️ Inside an Information Element Type record, it can be used together with the informationElementId element to scope properties to one specific Information Element. It's giving "pair it with its ID" energy. If you want to export type information about an IANA-assigned Information Element, set the privateEnterpriseNumber to 0, or just don't export the privateEnterpriseNumber in the type record at all 🌷 If you want to export type information about an enterprise-specific Information Element instead, export the enterprise number in privateEnterpriseNumber, and export the Information Element number with the Enterprise bit cleared in informationElementId 💜 The Enterprise bit in the associated informationElementId Information Element MUST be ignored by the Collecting Process. Not optional, bestie 🚫
Abstract Data Type: unsigned32
Data Type Semantics: identifier
ElementId: 346
Status: current
Reference: Sections 3.2 and 3.4.1 of the IPFIX Protocol [RFC5101]; Section 8.2.3 of the PSAMP Information Model [RFC5477].
3.9. Information Element Type Options Template ✨
Okay bestie, this template is where type information gets attached to Information Elements used inside Template Records 💖 It's scoped to an Observation Domain within a Transport Session, so it's basically a way to ship an IPFIX Information Model inline, right inside the IPFIX Message stream 🦋 Data Records described by this template are called Information Element type records.
In deployments where interoperability across vendor implementations of IPFIX matters, an Exporting Process that exports data using Templates with enterprise-specific Information Elements SHOULD export an Information Element type record for each enterprise-specific Information Element it exports. Collecting Processes MAY use these type records to handle unknown enterprise-specific Information Elements better 🧚 Exporting Processes using enterprise-specific Information Elements to build proprietary features MAY omit type records for those Information Elements, no judgment 🫶
Information Element type records MUST be handled by Collecting Processes as scoped to the Transport Session they were sent in. This facility is not meant for permanently defining Information Elements, so don't try to make it do that 🙅♀️
Also, for security reasons, the type information for a given Information Element MUST NOT be redefined by Information Element type records, and a Collecting Process MUST NOT let an Information Element type record replace its own internal definition of an Information Element 🔒 Information Element type records SHOULD NOT be duplicated in a given Observation Domain within a Transport Session. Once a type record has been exported for a given Information Element within a given Transport Session, every later type record for that Information Element MUST be identical. If a Collecting Process gets conflicting semantic or type information for an Information Element, that Information Element MUST be ignored 💀
Note that while this template MAY be used to export information about any Information Element, including ones registered with IANA, Exporting Processes SHOULD NOT export any type records that could reasonably be assumed to duplicate type information the Collecting Process already has 👑 This mechanism is not a replacement for Exporting and Collecting Processes keeping up with changes to the IANA registry. That update mechanism is out of scope for this document, so it's a whole other story 📚
The template SHOULD contain the Information Elements in Table 4, below, as defined in the PSAMP Information Model [RFC5477] and in this document, above.
+-------------------------------+-----------------------------------+
| IE | Description |
+-------------------------------+-----------------------------------+
| informationElementId [scope] | The Information Element |
| | identifier of the Information |
| | Element described by this type |
| | record. This Information Element |
| | MUST be defined as a Scope Field. |
| | See the PSAMP Information Model |
| | [RFC5477] for a definition of |
| | this field. |
| privateEnterpriseNumber | The Private Enterprise number of |
| [scope] | the Information Element described |
| | by this type record. This |
| | Information Element MUST be |
| | defined as a Scope Field. |
| informationElementDataType | The storage type of the specified |
| | Information Element. |
| informationElementSemantics | The semantic type of the |
| | specified Information Element. |
| informationElementUnits | The units of the specified |
| | Information Element. This |
| | element SHOULD be omitted if the |
| | Information Element is a unitless |
| | quantity, or a not a quantity or |
| | counter. |
+-------------------------------+-----------------------------------+
| IE (Continued) | Description (Continued) |
+-------------------------------+-----------------------------------+
| informationElementRangeBegin | The low end of the range of |
| | acceptable values for the |
| | specified Information Element. |
| | This element SHOULD be omitted if |
| | the beginning of the Information |
| | Element's acceptable range is |
| | defined by its data type. |
| informationElementRangeEnd | The high end of the range of |
| | acceptable values for the |
| | specified Information Element. |
| | This element SHOULD be omitted if |
| | the end Information Element's |
| | acceptable range is defined by |
| | its data type. |
| informationElementName | The name of the specified |
| | Information Element. |
| informationElementDescription | A human-readable description of |
| | the specified Information |
| | Element. This element MAY be |
| | omitted in the interest of export |
| | efficiency. |
+-------------------------------+-----------------------------------+
Table 4: IE Type Options3.10. Data Type and Semantics Restrictions 🎀
Heads up, the informationElementSemantics values defined in Section 3.2 of [RFC5102] are mainly meant to tell apart how numeric values get interpreted. Not every combo of informationElementDataType and informationElementSemantics is valid. For example, a counter can't be encoded as an IPv4 address 🙈 Here are the acceptable values of informationElementSemantics:
- Any value is valid for unsigned informationElementDataType values (
"unsigned8","unsigned16","unsigned32", or"unsigned64"). - Any value except
"flags"is valid for signed informationElementDataType values ("signed8","signed16","signed32", or"signed64"). - Any value except
"identifier"or"flags"is valid for floating-point informationElementDataType values ("float32"or"float64"). - Only
"default"is valid for all other informationElementDataType values ("octetArray","boolean","macAddress","string","dateTimeSeconds","dateTimeMilliseconds","dateTimeMicroseconds","dateTimeNanoseconds","ipv4Address", or"ipv6Address").
Information Element type records with invalid combinations of informationElementSemantics and informationElementDataType MUST NOT be sent by Exporting Processes, and MUST be ignored by Collecting Processes 🚫
Future Standards Actions that modify the Information Element Data Type subregistry or the Information Element Semantics subregistry should contain a Data Type and Semantics Restrictions section like this one, to define which combinations of type and semantics information are allowed 💅
4. Security Considerations 🔐
The same security considerations as for the IPFIX Protocol [RFC5101] apply 🫶
On top of that, attention must be paid to how Information Element type records get handled at the Collecting Process 👀 The type information precedence rules defined above (a Collecting Process' current knowledge overrides type records, and types are not redefinable during a session) are designed to keep an attacker from maliciously redefining the data model. That's a big deal, so it's giving security-first energy ✨
Note that Information Element type records may contain two strings describing Information Elements: informationElementName and informationElementDescription. IPFIX strings on the wire are length-prefixed and UTF-8 [RFC3629] encoded, most often inside an IPFIX variable-length Information Element. That helps reduce the risk of unterminated-string attacks against IPFIX Collecting Processes. However, care should still be taken when handling strings within the type system of the Collecting Process 😭
First, Collecting Processes should pay particular attention to buffer sizes when converting between length-prefixed and null-terminated strings. Exporting Processes MUST NOT export, and Collecting Processes MUST ignore, any informationElementName or informationElementDescription content that contains null characters (U+0000), so that buffer and string lengths stay consistent 🧷
Also, there is no limit to IPFIX string length beyond the one inherent in the protocol. The maximum IPFIX string length is 65512 octets (maximum message length (65535), minus message header (16), minus set header (4), minus long variable length field (3)) 🧮
Specifically, even though the informationElementName of all IANA Information Elements at the time of this writing is less than about 40 octets, and the informationElementDescription is less than 4096 octets, either of these Information Elements may contain strings up to 65512 octets long. So don't assume the short lengths hold 🌈
5. IANA Considerations ✨
okay so IANA is the bestie who keeps the official registries, and this section is basically them saying "we added a bunch of new Information Elements to the IPFIX Information Element registry, as described in Section 3 above" 📋💅 the new IEs get these numbers:
- Information Element Number 339 for the informationElementDataType Information Element 🎀
- Information Element Number 340 for the informationElementDescription Information Element 🌸
- Information Element Number 341 for the informationElementName Information Element 🦋
- Information Element Number 342 for the informationElementRangeBegin Information Element 🍓
- Information Element Number 343 for the informationElementRangeEnd Information Element 🧚
- Information Element Number 344 for the informationElementSemantics Information Element 💜
- Information Element Number 345 for the informationElementUnits Information Element ⭐
- Information Element Number 346 for the privateEnterpriseNumber Information Element 👑
IANA also made three subregistries for the values these IEs can take, and the rules for adding to them are a little different:
- An Information Element Data Type subregistry for the values of the informationElementDataType Information Element. Entries may be added to this subregistry subject to a Standards Action [RFC5226]. 🔥
- An Information Element Semantics subregistry for the values of the informationElementSemantics Information Element. Entries may be added to this subregistry subject to a Standards Action [RFC5226]. 🔥
- An Information Element Units subregistry for the values of the informationElementUnits Information Element. Entries may be added to this subregistry on an Expert Review [RFC5226] basis. 🌈
6. Acknowledgements 🫶
thank you thank you to Paul Aitken and Gerhard Muenz for the detailed reviews 😭 and to David Moore for first raising this issue on the IPFIX mailing list 🙈 also a big shoutout to the PRISM project for supporting this work ✨
7. References 📚
7.1. Normative References
[RFC5101] Claise, B., "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.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports",
RFC 5477, March 2009.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode
Plain Text", RFC 2482, January 1999.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.7.2. Informative References
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)",
RFC 3917, October 2004.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
March 2009.Appendix A. Examples 🧁
okay the examples are where it all clicks bestie 🤩 this shows how the type information extension mechanism from this doc can describe the semantics of enterprise-specific Information Elements (the private ones that aren't in the standard list)
the two example IEs are:
- initialTCPFlags, an example private IE 14, 1 octet, the TCP flags on the first TCP packet in the flow. 🚩
- unionTCPFlags, an example private IE 15, 1 octet, the union of the TCP flags on all packets after the first TCP packet in the flow. 🚩
so an Exporting Process sending flows with these IEs might use a Template that looks like this:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationTransportPort 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| (initialTCPFlags) 14 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| (unionTCPFlags) 15 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Template with Enterprise-Specific IEs 🦋
BUT here's the catch bestie 😭 a Collecting Process that gets Data Sets described by this Template can only treat the enterprise-specific Information Elements as opaque octets. Specifically, there is no hint to the collector that they contain flag information. 💀 to fix that, the Exporting Process would first export the Information Element Type Options Template described in Section 3.9 above:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| priv.EnterpriseNumber 346 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| informationElementId 303 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| inf.El.DataType 339 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| inf.El.Semantics 344 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| inf.El.Name 341 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Example Information Element Type Options Template 🎀
then the Exporting Process exports two records described by the Example Information Element Type Options Template to describe the enterprise-specific Information Elements:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 257 | Length = 50 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| IE 14 |0x01 unsigned8 |0x05 flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 length | |
+-+-+-+-+-+-+-+-+ |
| "initialTCPFlags" |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| IE 15 |0x01 unsigned8 |0x05 flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 13 length | |
+-+-+-+-+-+-+-+-+ "unionTCPFlags" |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Type Record Example 🌸
Authors' Addresses 🏡
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
Phone: +41 44 632 70 57 EMail: elisa.boschi@hitachi-eu.com
Brian Trammell Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
Phone: +41 44 632 70 13 EMail: brian.trammell@hitachi-eu.com
Lutz Mark Fraunhofer Institute for Manufacturing Technology and Applied Materials Research Wiener Str. 12 28359 Bremen Germany
Phone: +49 421 2246206 EMail: lutz.mark@ifam.fraunhofer.de
Tanja Zseby Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany
Phone: +49 30 3463 7153 EMail: tanja.zseby@fokus.fraunhofer.de
📦 where this page comes from
- ietf: rfc5610 2009-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms