idnits 2.17.1 draft-ietf-ipfix-information-model-rfc5102bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2013) is 4091 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2629' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 904, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-protocol-rfc5101bis-04 -- Possible downref: Normative reference to a draft: ref. 'RFC5101bis' -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-mediation-protocol-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Claise, Ed. 3 Internet Draft Cisco Systems, Inc. 4 Obsoletes: 5102 B. Trammell, Ed. 5 Category: Standards Track ETH Zurich 6 Expires: August 16, 2013 February 12, 2013 8 Information Model for IP Flow Information eXport (IPFIX) 9 draft-ietf-ipfix-information-model-rfc5102bis-10.txt 11 Abstract 12 This document defines the datatypes and management policy for the 13 information model for the IP Flow Information eXport (IPFIX) 14 protocol. This information model is maintained as the IANA IPFIX 15 Information Element Registry, the initial contents of which were 16 defined by RFC 5102. This information model is used by the IPFIX 17 Protocol for encoding measured traffic information and information 18 related to the traffic Observation Point, the traffic Metering 19 Process, and the Exporting Process. Although developed for the IPFIX 20 Protocol, the model is defined in an open way that easily allows 21 using it in other protocols, interfaces, and applications. This 22 document obsoletes RFC 5102. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute working 31 documents as Internet-Drafts. The list of current Internet-Drafts is 32 at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 16, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Changes since RFC 5102 . . . . . . . . . . . . . . . . . . 4 60 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 61 2. Properties of IPFIX Protocol Information Elements . . . . . . 5 62 2.1. Information Element Specification Template . . . . . . . . 5 63 2.2. Scope of Information Elements . . . . . . . . . . . . . . 7 64 2.3. Naming Conventions for Information Elements . . . . . . . 7 65 3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Abstract Data Types . . . . . . . . . . . . . . . . . . . 8 67 3.1.1. unsigned8 . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1.2. unsigned16 . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1.3. unsigned32 . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.4. unsigned64 . . . . . . . . . . . . . . . . . . . . . . 9 71 3.1.5. signed8 . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.6. signed16 . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1.7. signed32 . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.8. signed64 . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.1.9. float32 . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1.10. float64 . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1.11. boolean . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.1.12. macAddress . . . . . . . . . . . . . . . . . . . . . 10 79 3.1.13. octetArray . . . . . . . . . . . . . . . . . . . . . 10 80 3.1.14. string . . . . . . . . . . . . . . . . . . . . . . . 10 81 3.1.15. dateTimeSeconds . . . . . . . . . . . . . . . . . . . 10 82 3.1.16. dateTimeMilliseconds . . . . . . . . . . . . . . . . 10 83 3.1.17. dateTimeMicroseconds . . . . . . . . . . . . . . . . 10 84 3.1.18. dateTimeNanoseconds . . . . . . . . . . . . . . . . . 11 85 3.1.19. ipv4Address . . . . . . . . . . . . . . . . . . . . . 11 86 3.1.20. ipv6Address . . . . . . . . . . . . . . . . . . . . . 11 87 3.1.21. basicList . . . . . . . . . . . . . . . . . . . . . . 11 88 3.1.22. subTemplateList . . . . . . . . . . . . . . . . . . . 11 89 3.1.23. subTemplateMultiList . . . . . . . . . . . . . . . . 11 90 3.2. Data Type Semantics . . . . . . . . . . . . . . . . . . . 11 91 3.2.1. quantity . . . . . . . . . . . . . . . . . . . . . . . 11 92 3.2.2. totalCounter . . . . . . . . . . . . . . . . . . . . . 12 93 3.2.3. deltaCounter . . . . . . . . . . . . . . . . . . . . . 12 94 3.2.4. identifier . . . . . . . . . . . . . . . . . . . . . . 12 95 3.2.5. flags . . . . . . . . . . . . . . . . . . . . . . . . 12 96 4. Information Element Identifiers . . . . . . . . . . . . . . . 13 97 5. Information Elements . . . . . . . . . . . . . . . . . . . . . 13 98 6. Extending the Information Model . . . . . . . . . . . . . . . 15 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 100 7.1. IPFIX Information Elements . . . . . . . . . . . . . . . . 16 101 7.2. MPLS Label Type Identifier . . . . . . . . . . . . . . . . 16 102 7.3. XML Namespace and Schema . . . . . . . . . . . . . . . . . 17 103 7.4. Addition, Revision, and Deprecation . . . . . . . . . . . 17 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 108 10.2. Informative References . . . . . . . . . . . . . . . . . 19 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 110 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 112 1. Introduction 114 The IP Flow Information eXport (IPFIX) protocol serves for 115 transmitting information related to network traffic measurement. The 116 protocol specification in [RFC5101bis] defines how Information 117 Elements are transmitted. For Information Elements, it specifies the 118 encoding of a set of basic data types. However, the list of 119 Information Elements that can be transmitted by the protocol, such as 120 Flow attributes (source IP address, number of packets, etc.) and 121 information about the Metering and Exporting Process (packet 122 Observation Point, sampling rate, Flow timeout interval, etc.), is 123 not specified in [RFC5101bis]. 125 The IANA IPFIX Information Element registry [IPFIX-IANA] is the 126 current complete reference for IPFIX Information Elements. The 127 initial values for this registry were provided by [RFC5102]. 129 This document complements the IPFIX protocol specification 130 [RFC5101bis] by providing an overview of the IPFIX information model 131 and specifying data types for it. IPFIX-specific terminology used in 132 this document is defined in Section 2 of [RFC5101bis]. As in 133 [RFC5101bis], these IPFIX-specific terms have the first letter of a 134 word capitalized when used in this document. 136 The use of the term 'information model' is not fully in line with the 137 definition of this term in [RFC3444], as the IPFIX information model 138 does not specify relationships between Information Elements. Nor does 139 the IPFIX information model specify a concrete encoding of 140 Information Elements; for an encoding suitable for use with the IPFIX 141 protocol, see [RFC5101bis]. Besides the encoding used by the IPFIX 142 protocol, other encodings of IPFIX Information Elements can be 143 applied, for example, XML-based encodings. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 1.1. Changes since RFC 5102 151 This document obsoletes the Proposed Standard revision of the IPFIX 152 Protocol Specification [RFC5102]. The following changes have been 153 made to this document with respect to the previous document: 155 - All outstanding technical and editorial errata filed on the 156 [RFC5102] as of publication time have been corrected. 157 - All references into [RFC5101] have been updated to [RFC5101bis], 158 reflecting changes in that document as necessary. 159 - Information element definitions have been removed, as the 160 reference for these is now [IPFIX-IANA]; a historical note on 161 categorizations of information elements as defined in [RFC5102] has 162 been retained in section 5. 163 - The process for modifying [IPFIX-IANA] has been improved, and is 164 now described in [IPFIX-IE-DOCTORS]; Section 6 has been updated 165 accordingly, and a new section 7.3 gives IANA considerations for this 166 process. 167 - Definitions of timestamp data types have been clarified. 168 - Appendices A and B have been removed 170 1.2. IPFIX Documents Overview 172 The IPFIX protocol provides network administrators with access to 173 network flow information. The architecture for the export of 174 measured flow information out of an IPFIX Exporting Process to a 175 Collecting Process is defined in [RFC5470], per the requirements 176 defined in [RFC3917]. The IPFIX Protocol Specification [RFC5101bis] 177 defines how IPFIX data records and templates are carried via a number 178 of transport protocols from IPFIX Exporting Processes to IPFIX 179 Collecting Processes. 181 Four IPFIX optimizations/extensions are currently specified: a 182 bandwidth saving method for the IPFIX protocol in [RFC5473], an 183 efficient method for exporting bidirectional flows in [RFC5103], a 184 method for the definition and export of complex data structures in 185 [RFC6313], and the specification of the Protocol for IPFIX Mediations 186 [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183]. 188 IPFIX has a formal description of IPFIX Information Elements, their 189 name, type and additional semantic information, as specified in this 190 document, with the export of the Information Element types specified 191 in [RFC5610]. 193 [RFC6728] specifies a data model for configuring and monitoring IPFIX 194 and PSAMP compliant devices using the NETCONF protocol, while 195 [RFC6615] specifies a MIB module for monitoring. 197 In terms of development, [RFC5153] provides guidelines for the 198 implementation and use of the IPFIX protocol, while [RFC5471] 199 provides guidelines for testing. 201 Finally, [RFC5472] describes what type of applications can use the 202 IPFIX protocol and how they can use the information provided. It 203 furthermore shows how the IPFIX framework relates to other 204 architectures and frameworks. 206 2. Properties of IPFIX Protocol Information Elements 208 2.1. Information Element Specification Template 210 Information in messages of the IPFIX protocol is modeled in terms of 211 Information Elements of the IPFIX information model. The IPFIX 212 Information Elements mentioned in Section 5 are specified in [IPFIX- 213 IANA]. 215 All Information Elements specified for the IPFIX protocol MUST have 216 the following properties defined. 218 name - A unique and meaningful name for the Information Element. 220 elementId - A numeric identifier of the Information Element. If this 221 identifier is used without an enterprise identifier (see 222 [RFC5101bis] and enterpriseId below), then it is globally unique 223 and the list of allowed values is administered by IANA. It is 224 used for compact identification of an Information Element when 225 encoding Templates in the protocol. 227 description - The semantics of this Information Element. Describes 228 how this Information Element is derived from the Flow or other 229 information available to the observer. Information Elements of 230 dataType string or octetArray which have length constraints (fixed 231 length, minimum and/or maximum length) MUST note these constraints 232 in their description. 234 dataType - One of the types listed in Section 3.1 of this document or 235 registered in the IANA IPFIX Information Element Data Types 236 registry. The type space for attributes is constrained to 237 facilitate implementation. The existing type space encompasses 238 most primitive types used in modern programming languages, as well 239 as some derived types (such as ipv4Address) that are common to 240 this domain. 242 status - The status of the specification of this Information Element. 243 Allowed values are 'current' and 'deprecated'. All newly-defined 244 Information Elements have 'current' status. The process for moving 245 Information Elements to the 'deprecated' status is defined in 246 Section 5.2 of [IPFIX-IE-DOCTORS]. 248 Enterprise-specific Information Elements MUST have the following 249 property defined: 251 enterpriseId - Enterprises may wish to define Information Elements 252 without registering them with IANA, for example, for 253 enterprise-internal purposes. For such Information Elements, the 254 Information Element identifier described above is not sufficient 255 when the Information Element is used outside the enterprise. If 256 specifications of enterprise-specific Information Elements are 257 made public and/or if enterprise-specific identifiers are used by 258 the IPFIX protocol outside the enterprise, then the 259 enterprise-specific identifier MUST be made globally unique by 260 combining it with an enterprise identifier. Valid values for the 261 enterpriseId are defined by IANA as Structure of Management 262 Information (SMI) network management private enterprise numbers, 263 defined at [PEN-IANA]. 265 All Information Elements specified for the IPFIX protocol either in 266 this document or by any future extension MAY have the following 267 properties defined: 269 dataTypeSemantics - The integral types are qualified by additional 270 semantic details. Valid values for the data type semantics are 271 specified in Section 3.2 of this document or in a future extension 272 of the information model. 274 units - If the Information Element is a measure of some kind, the 275 units identify what the measure is. 277 range - Some Information Elements may only be able to take on a 278 restricted set of values that can be expressed as a range (e.g., 0 279 through 511 inclusive). If this is the case, the valid inclusive 280 range SHOULD be specified; values for this Information Element 281 outside the range are invalid and MUST NOT be exported. 283 reference - Identifies additional specifications that more precisely 284 define this item or provide additional context for its use. 286 The following two Information Element properties are defined to allow 287 the management of an Information Element registry with Information 288 Element definitions that may be updated over time, per the process 289 defined in Section 5.2 of [IPFIX-IE-DOCTORS]. 291 revision - The revision number of an Information Element, starting at 292 0 for Information Elements at time of definition, and incremented 293 by one for each revision. 295 date - The date of the entry of this revision of the Information 296 Element into the registry. 298 A template for specifying Information Elements in Internet-Drafts is 299 given in Section 9.1 of [IPFIX-IE-DOCTORS], and an XML Schema for 300 specifying Information Elements in the IANA IPFIX registry [IPFIX- 301 IANA] at [IPFIX-XML-SCHEMA]. 303 2.2. Scope of Information Elements 305 By default, most Information Elements have a scope specified in their 306 definitions. Within Data Records defined by Option Templates, the 307 IPFIX protocol allows further limiting of the Information Element 308 scope. The new scope is specified by one or more scope fields and 309 defined as the combination of all specified scope values; see Section 310 3.4.2.1 on IPFIX scopes in [RFC5101bis]. 312 2.3. Naming Conventions for Information Elements 314 The following naming conventions were used for naming Information 315 Elements in this document. It is recommended that extensions of the 316 model use the same conventions. 318 o Names of Information Elements SHOULD be descriptive. 320 o Names of Information Elements MUST be unique within the IANA IPFIX 321 registry [IPFIX-IANA]. Enterprise-specific Information Elements 322 SHOULD be prefixed with a vendor name. 324 o Names of Information Elements MUST start with non-capitalized 325 letters. 327 o Composed names MUST use capital letters for the first letter of 328 each component (except for the first one). All other letters are 329 non-capitalized, even for acronyms. Exceptions are made for 330 acronyms containing non-capitalized letters, such as 'IPv4' and 331 'IPv6'. Examples are sourceMacAddress and destinationIPv4Address. 333 o Middleboxes [RFC3234] may change Flow properties, such as the 334 Differentiated Service Code Point (DSCP) value or the source IP 335 address. If an IPFIX Observation Point is located in the path of 336 a Flow before one or more middleboxes that potentially modify 337 packets of the Flow, then it may be desirable to also report Flow 338 properties after the modification performed by the middleboxes. 339 An example is an Observation Point before a packet marker changing 340 a packet's IPv4 Type of Service (TOS) field that is encoded in 341 Information Element ipClassOfService. Then the value observed and 342 reported by Information Element ipClassOfService is valid at the 343 Observation Point, but not after the packet passed the packet 344 marker. For reporting the change value of the TOS field, the 345 IPFIX information model uses Information Elements that have a name 346 prefix "post", for example, "postIpClassOfService". Information 347 Elements with prefix "post" report on Flow properties that are not 348 necessarily observed at the Observation Point, but which are 349 obtained within the Flow's Observation Domain by other means 350 considered to be sufficiently reliable, for example, by analyzing 351 the packet marker's marking tables. 353 3. Type Space 355 This section describes the abstract data types that can be used for 356 the specification of IPFIX Information Elements in Section 4. 357 Section 3.1 describes the set of abstract data types. 359 Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, 360 signed8, signed16, signed32, and signed64 are integral data types. 361 As described in Section 3.2, their data type semantics can be further 362 specified, for example, by 'totalCounter', 'deltaCounter', 363 'identifier', or 'flags'. 365 3.1. Abstract Data Types 367 This section describes the set of valid abstract data types of the 368 IPFIX information model, independent of encoding. Note that further 369 abstract data types may be specified by future updates to this 370 document. Changes to the associated IPFIX Information Element Data 371 Types subregistry [IPFIX-IANA] specified in [RFC5610] require a 372 Standards Action [RFC5226]. 374 The current encodings of these data types for use with the IPFIX 375 protocol is defined in [RFC5101bis]; encodings allowing the use of 376 the IPFIX Information Elements [IPFIX-IANA] with other protocols may 377 be defined in the future by referencing this document. 379 3.1.1. unsigned8 381 The type "unsigned8" represents a non-negative integer value in the 382 range of 0 to 255. 384 3.1.2. unsigned16 386 The type "unsigned16" represents a non-negative integer value in the 387 range of 0 to 65535. 389 3.1.3. unsigned32 391 The type "unsigned32" represents a non-negative integer value in the 392 range of 0 to 4294967295. 394 3.1.4. unsigned64 396 The type "unsigned64" represents a non-negative integer value in the 397 range of 0 to 18446744073709551615. 399 3.1.5. signed8 401 The type "signed8" represents an integer value in the range of -128 402 to 127. 404 3.1.6. signed16 406 The type "signed16" represents an integer value in the range of 407 -32768 to 32767. 409 3.1.7. signed32 411 The type "signed32" represents an integer value in the range of 412 -2147483648 to 2147483647. 414 3.1.8. signed64 416 The type "signed64" represents an integer value in the range of 417 -9223372036854775808 to 9223372036854775807. 419 3.1.9. float32 421 The type "float32" corresponds to an IEEE single-precision 32-bit 422 floating point type as defined in [IEEE.754.1985]. 424 3.1.10. float64 426 The type "float64" corresponds to an IEEE double-precision 64-bit 427 floating point type as defined in [IEEE.754.1985]. 429 3.1.11. boolean 431 The type "boolean" represents a binary value. The only allowed 432 values are "true" and "false". 434 3.1.12. macAddress 436 The type "macAddress" represents a MAC-48 address as in 437 [IEEE.802-3.2002]. 439 3.1.13. octetArray 441 The type "octetArray" represents a finite-length string of octets. 443 3.1.14. string 445 The type "string" represents a finite-length string of valid 446 characters from the Unicode coded character set [ISO.10646]. Unicode 447 incorporates ASCII [RFC20] and the characters of many other 448 international character sets. 450 3.1.15. dateTimeSeconds 452 The data type "dateTimeSeconds" represents a time value expressed 453 with second-level precision. 455 3.1.16. dateTimeMilliseconds 457 The data type "dateTimeMilliseconds" represents a time value 458 expressed with millisecond-level precision. 460 3.1.17. dateTimeMicroseconds 462 The type "dateTimeMicroseconds" represents a time value expressed 463 with microsecond-level precision. 465 3.1.18. dateTimeNanoseconds 467 The type "dateTimeNanoseconds" represents a time value expressed with 468 nanosecond-level precision. 470 3.1.19. ipv4Address 472 The type "ipv4Address" represents an IPv4 address. 474 3.1.20. ipv6Address 476 The type "ipv6Address" represents an IPv6 address. 478 3.1.21. basicList 480 The type "basicList" supports structured data export as described in 481 [RFC6313]; see section 4.5.1 of that document for encoding details. 483 3.1.22. subTemplateList 485 The type "subTemplateList" supports structured data export as 486 described in [RFC6313]; see section 4.5.2 of that document for 487 encoding details. 489 3.1.23. subTemplateMultiList 491 The type "subTemplateMultiList" supports structured data export as 492 described in [RFC6313]; see section 4.5.3 of that document for 493 encoding details. 495 3.2. Data Type Semantics 497 This section describes the set of valid data type semantics of the 498 IPFIX information model. A sub-registry of data type semantics 499 [IPFIX-IANA] is established in [RFC5610]; the restrictions on the use 500 of semantics below are compatible with those specified in section 501 3.10 of that document. These semantics apply only to numeric types, 502 as noted in the description of each semantic below. 504 Further data type semantics may be specified by future updates to 505 this document. Changes to the associated IPFIX Information Element 506 Semantics sub-registry [IPFIX-IANA] require a Standards Action 507 [RFC5226]. 509 3.2.1. quantity 511 A numeric (integral or floating point) value representing a measured 512 value pertaining to the record. This is distinguished from counters 513 that represent an ongoing measured value whose "odometer" reading is 514 captured as part of a given record. This is the default semantic type 515 of all numeric data types. 517 3.2.2. totalCounter 519 An integral value reporting the value of a counter. Counters are 520 unsigned and wrap back to zero after reaching the limit of the type. 521 For example, an unsigned64 with counter semantics will continue to 522 increment until reaching the value of 2**64 - 1. At this point, the 523 next increment will wrap its value to zero and continue counting from 524 zero. The semantics of a total counter is similar to the semantics of 525 counters used in SNMP, such as Counter32 defined in [RFC2578]. The 526 only difference between total counters and counters used in SNMP is 527 that the total counters have an initial value of 0. A total counter 528 counts independently of the export of its value. 530 3.2.3. deltaCounter 532 An integral value reporting the value of a counter. Counters are 533 unsigned and wrap back to zero after reaching the limit of the type. 534 For example, an unsigned64 with counter semantics will continue to 535 increment until reaching the value of 2**64 - 1. At this point, the 536 next increment will wrap its value to zero and continue counting from 537 zero. The semantics of a delta counter is similar to the semantics of 538 counters used in SNMP, such as Counter32 defined in RFC 2578 539 [RFC2578]. The only difference between delta counters and counters 540 used in SNMP is that the delta counters have an initial value of 0. A 541 delta counter is reset to 0 each time it is exported and/or expires 542 without export. 544 3.2.4. identifier 546 An integral value that serves as an identifier. Specifically, 547 mathematical operations on two identifiers (aside from the equality 548 operation) are meaningless. For example, Autonomous System ID 1 * 549 Autonomous System ID 2 is meaningless. Identifiers MUST be one of the 550 signed or unsigned data types. 552 3.2.5. flags 554 An integral value that represents a set of bit fields. Logical 555 operations are appropriate on such values, but not other mathematical 556 operations. Flags MUST always be of an unsigned data type. 558 4. Information Element Identifiers 560 All Information Elements defined in the IANA IPFIX Information 561 Element registry [IPFIX-IANA] have their identifiers assigned by 562 IANA. 564 The value of these identifiers is in the range of 1-32767. Within 565 this range, Information Element identifier values in the sub-range of 566 1-127 are compatible with field types used by NetFlow version 9 567 [RFC3954] for historical reasons. 569 In general, IANA will add newly registered Information Elements to 570 the registry, assigning the lowest available Information Element 571 identifier in the range 128-32767. 573 Enterprise-specific Information Element identifiers have the same 574 range of 1-32767, but they are coupled with an additional enterprise 575 identifier. For enterprise-specific Information Elements, Information 576 Element identifier 0 is also reserved. Enterprise-specific 577 Information Element identifiers can be chosen by an enterprise 578 arbitrarily within the range of 1-32767. The same identifier may be 579 assigned by other enterprises for different purposes; these 580 Information Elements are distinct because the Information Element 581 identifier is coupled with an enterprise identifier. 583 Enterprise identifiers are to be registered as SMI network management 584 private enterprise code numbers with IANA. The registry can be found 585 at [PEN-IANA]. 587 5. Information Elements 589 [IPFIX-IANA] is now the normative reference for IPFIX Information 590 Elements. At the time of publication of [RFC5102], this section 591 defined the initial contents of that registry. 593 As a historical note, Information Elements were organized into 594 categories in [RFC5102] according to their semantics and their 595 applicability; these categories were not carried forward into [IPFIX- 596 IANA] as an organizing principle. The categories (with example IEs) 597 were: 599 1. Identifiers (e.g. ingressInterface) 600 2. Metering and Exporting Process Configuration 601 (e.g. exporterIPv4Address) 602 3. Metering and Exporting Process Statistics 603 (e.g. exportedOctetTotalCount) 604 4. IP Header Fields (e.g. sourceIPv4Address) 605 5. Transport Header Fields (e.g. sourceTransportPort) 606 6. Sub-IP Header Fields (e.g. sourceMacAddress) 607 7. Derived Packet Properties (e.g. bgpSourceAsNumber) 608 8. Min/Max Flow Properties (e.g. minimumIpTotalLength) 609 9. Flow Timestamps (e.g. flowStartTimeMilliseconds) 610 10. Per-Flow Counters (e.g. octetDeltaCount) 611 11. Miscellaneous Flow Properties (e.g. flowEndReason) 612 12. Padding (paddingOctets) 614 Information Elements derived from fields of packets or from packet 615 treatment can typically serve as Flow Keys used for mapping packets 616 to Flows. These Information Elements were placed in categories 4-7 in 617 the original categorization. 619 Information Elements not serving as Flow Keys may have different 620 values for each packet in a Flow. For Information Elements with 621 values derived from packets fields or packet treatment, and for which 622 the value may change from packet to packet within a single Flow, the 623 exported value of an Information Element is by default determined by 624 the first packet observed for the corresponding Flow; the description 625 of the Information Element may however explicitly specify different 626 semantics. This simple rule allows writing all Information Elements 627 related to header fields once when the first packet of the Flow is 628 observed. For further observed packets of the same Flow, only Flow 629 properties that depend on more than one packet need to be updated; 630 these Information Elements were placed in categories 8-11 in the 631 original categorization. 633 Information Elements with a name having the "post" prefix (e.g. 634 postIpClassOfService), do not necessarily report properties that were 635 actually observed at the Observation Point, but may be retrieved by 636 other means within the Observation Domain. These Information Elements 637 can be used if there are middlebox functions within the Observation 638 Domain changing Flow properties after packets passed the Observation 639 Point; they may also be reported directly by the Observation Point if 640 the Observation Point is situated such as to observe packets on both 641 sides of the middlebox. 643 6. Extending the Information Model 645 A key requirement for IPFIX is to allow for extension of the 646 Information Model via the IANA IPFIX registry [IPFIX-IANA]. New 647 Information Element definitions can be added to this registry subject 648 to an Expert Review [RFC5226], with additional process considerations 649 decribed in [IPFIX-IE-DOCTORS]; that document also provides 650 guidelines for authors and reviewers of new Information Element 651 definitions. 653 For new Information Elements, the type space defined in Section 3 can 654 be used. If required, new abstract data types can be added to the 655 data type subregistry [IPFIX-IANA] defined in [RFC5610]. New abstract 656 data types and semantics are subject to Standards Action [RFC5226], 657 and MUST be defined in IETF Standards Track documents updating this 658 document. 660 Enterprises may wish to define Information Elements without 661 registering them with IANA. IPFIX explicitly supports 662 enterprise-specific Information Elements. Enterprise-specific 663 Information Elements are described in Sections 2.1 and 4; guidelines 664 for using them appear in [IPFIX-IE-DOCTORS]. 666 7. IANA Considerations 668 As this document obsoletes [RFC5102], upon publication of this 669 document, IANA will update the Reference to the IPFIX Information 670 Element registry [IPFIX-IANA], the IPFIX MPLS Label Type subregistry 671 of that registry, the urn:ietf:params:xml:ns:ipfix-info XML 672 namespace, and the urn:ietf:params:xml:schema:ipfix-info XML schema 673 to refer to this document. 675 However, [RFC5102] still provides a historical reference for the 676 initial entries in the IPFIX Information Element registry. Therefore, 677 IANA will keep [RFC5102] as the Requestor of those Information 678 Elements in the IPFIX Information Element registry which list 679 [RFC5102] as their Requestor, and add the following explanatory note 680 to the IPFIX Information Element registry upon publication of this 681 document: 683 "RFC XXXX has obsoleted RFC 5102; references to RFC 5102 in this 684 registry remain as part of the historical record." 686 The Information Element Specification Template in Section 2.1 687 contains two new columns not present in [RFC5102]. On publication of 688 this document, IANA will create a new Revision column in the IPFIX 689 Information Element Registry, and set the Revision of existing 690 Information Elements to 0. IANA will also create a new Date column in 691 the IPFIX Information Element Registry, and set the Date of all 692 existing Information Elements to the publication date of this 693 document. 695 To identify Information Elements with identifiers 127 or below as 696 NetFlow v9 [RFC3954] compatible, upon publication of this document, 697 IANA will set the Name of all existing Reserved Information Elements 698 with identifier 127 or less to "Assigned for NetFlow v9 699 compatibility", and the Reference of those Information Elements to 700 [RFC3954]. 702 As IANA now has change control of the schema used for the IANA IPFIX 703 Information Element Registry [IPFIX-IANA], IANA will deprecate the 704 previous XML Schema for the description of Information Elements 705 urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA]. 707 To support the process described in Section 7.4, IANA will establish 708 a mailing list for communicating with the IE-DOCTORS experts, named 709 ie-doctors@ietf.org. 711 The remaining subsections of this section contain no actions for 712 IANA. 714 7.1. IPFIX Information Elements 716 This document refers to Information Elements, for which the Internet 717 Assigned Numbers Authority (IANA) has created the IPFIX Information 718 Element Registry [IPFIX-IANA]. The columns of this registry must at 719 minimum be able to store the information defined in the template in 720 Section 2.1; it may contain other information as necessary for the 721 management of the registry. 723 The process for making additions or other changes to the IPFIX 724 Information Element Registry is given in Section 7.4. 726 7.2. MPLS Label Type Identifier 728 Information Element #46, named mplsTopLabelType, carries MPLS label 729 types. Values for 5 different types have initially been defined. 730 For ensuring extensibility of this information, IANA has created a 731 new subregistry for MPLS label types and filled it with the initial 732 list from the description Information Element #46, mplsTopLabelType. 734 New assignments for MPLS label types are administered by IANA through 735 Expert Review [RFC5226], i.e., review by one of a group of experts 736 designated by an IETF Area Director. The group of experts must 737 double check the label type definitions with already defined label 738 types for completeness, accuracy, and redundancy. The specification 739 of new MPLS label types MUST be published using a well-established 740 and persistent publication medium. 742 7.3. XML Namespace and Schema 744 The prior version of this document [RFC5102] specified an XML schema 745 for IPFIX Information Element definitions [IPFIX-XML-SCHEMA], which 746 was used in the generation of the document text itself. When the IANA 747 IPFIX Information Element registry [IPFIX-IANA] was created, change 748 control on the registry and the schema used to validate it passed to 749 IANA. 751 The use of a machine-readable syntax for the registry enables the 752 creation of IPFIX tools that can automatically adapt to extensions to 753 the information model. It should be noted that the use of XML in 754 Exporters, Collectors, or other tools is not mandatory for the 755 deployment of IPFIX. In particular, Exporting Processes do not 756 produce or consume XML as part of their operation. IPFIX Collectors 757 MAY take advantage of the machine-readability of the information 758 model vs. hard coding their behavior or inventing proprietary means 759 for accommodating extensions. However, Collectors SHOULD NOT poll the 760 IANA registry [IPFIX-IANA] directly at runtime, in order to avoid 761 unnecessary load on the IANA infrastructure serving the registry. 763 The reference to the current schema is embedded in the registry 764 [IPFIX-IANA]; this schema may change from time to time as necessary 765 to support the maintenance of the registry. As such, the schema 766 urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA] specified in 767 [RFC5102] has been deprecated. 769 7.4. Addition, Revision, and Deprecation 771 New assignments for IPFIX Information Elements are administered by 772 IANA through Expert Review [RFC5226]. These experts are referred to 773 as IE-DOCTORS experts, and are appointed by the IESG. The process 774 they follow is defined in [IPFIX-IE-DOCTORS]. 776 Information Element identifiers in the range 1-127 are compatible 777 with field types used by NetFlow version 9 [RFC3954] for historical 778 reasons, and must not be assigned unless the Information Element is 779 compatible with the NetFlow version 9 protocol, as determined by an 780 IE-DOCTORS expert designated by the IESG as a Netflow version 9 781 expert. 783 Future assignments added to the IPFIX Information Element Registry 784 which require subregistries for enumerated values (e.g. section 7.2, 785 below) must have those subregistries added simultaneously with the 786 new assignment; additions to these subregistries must be subject to 787 Expert Review [RFC5226]. Unless specified at assignment time, the 788 experts for the subregistry will be the same as for the Information 789 Element registry as a whole. 791 When IANA receives a request to add, revise, or deprecate an 792 Information Element in the IPFIX Information Elements Registry, it 793 forwards the request to the IE-DOCTORS experts for review. 795 When IANA receives an approval for a request to add an Information 796 Element definition from the IE-DOCTORS experts, it adds that 797 Information Element to the registry. The approved request may include 798 changes made by the requestor and/or reviewers as compared to the 799 original request. 801 When IANA receives an approval for a request to revise an Information 802 Element definition from the IE-DOCTORS experts, it changes that 803 Information Element's definition in the registry, and updates the 804 Revision and Date columns as appropriate. The approved request may 805 include changes from the original request. If the original 806 Information Element was added to the registry with IETF consensus 807 (i.e., was defined by an RFC), the revision will require IETF 808 consensus as well. 810 When IANA receives an approval for a request to deprecate an 811 Information Element definition from the IE-DOCTORS experts, it 812 changes that Information Element's definition in the registry, and 813 updates the Revision and Date columns as appropriate. The approved 814 request may include changes from the original request. If the 815 original Information Element was added to the registry with IETF 816 consensus (i.e., was defined by an RFC), the deprecation will require 817 IETF consensus as well. 819 8. Security Considerations 821 The IPFIX information model itself does not directly introduce 822 security issues. Rather, it defines a set of attributes that may for 823 privacy or business issues be considered sensitive information. 825 For example, exporting values of header fields may make attacks 826 possible for the receiver of this information, which would otherwise 827 only be possible for direct observers of the reported Flows along the 828 data path. 830 The underlying protocol used to exchange the information described 831 here must therefore apply appropriate procedures to guarantee the 832 integrity and confidentiality of the exported information. These 833 protocols are defined in separate documents, specifically the IPFIX 834 protocol document [RFC5101bis]. 836 9. Acknowledgements 838 This document is substantially based on [RFC5102]; the editors thank 839 the authors of that document, listed below as contributors. Special 840 thanks to Paul Aitken, for the detailed review. 842 10. References 844 10.1. Normative References 846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 847 Requirement Levels", BCP 14, RFC 2119, March 1997. 849 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 850 "Export of Structured Data in IP Flow Information Export 851 (IPFIX)", RFC6313, July 2011. 853 [RFC5101bis] 854 Claise, B., and B. Trammell, Editors, "Specification of 855 the IP Flow Information eXport (IPFIX) Protocol for the 856 Exchange of IP Traffic Flow Information", draft-ietf- 857 ipfix-protocol-rfc5101bis-04, Work in Progress, December 858 2012. 860 [IPFIX-IE-DOCTORS] 861 Trammell, B., and B. Claise, "Guidelines for Authors and 862 Reviewers of IPFIX Information Elements", draft-ietf- 863 ipfix-ie-doctors-07, Work in Progress, October 2012. 865 10.2. Informative References 867 [IEEE.802-3.2002] 868 Insitute of Electrical and Electronics Engineers, 869 "Information technology - Telecommunications and 870 information exchange between systems - Local and 871 metropolitan area networks - Specific requirements - Part 872 3: Carrier sense multiple access with collision detection 873 (CSMA/CD) access method and physical layer 874 specifications", IEEE Standard 802.3, September 2002. 876 [IEEE.754.1985] 877 Institute of Electrical and Electronics Engineers, 878 "Standard for Binary Floating-Point Arithmetic", IEEE 879 Standard 754, August 1985. 881 [ISO.10646] 882 International Organization for Standardization, 883 "Information technology - Universal Coded Character Set 884 (UCS)", ISO/IEC 10646:2012(E), June 2012. 886 [RFC20] 887 V. Cerf, "ASCII format for Network Interchange", RFC 20, 888 October 1969. 890 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 891 "Structure of Management Information Version 2 (SMIv2)", 892 STD 58, RFC 2578, April 1999. 894 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 895 June 1999. 897 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 898 Issues", RFC 3234, February 2002. 900 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 901 Information Models and Data Models", RFC 3444, January 902 2003. 904 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 905 January 2004. 907 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 908 "Requirements for IP Flow Information Export (IPFIX)", RFC 909 3917, October 2004. 911 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 912 Version 9", RFC 3954, October 2004. 914 [RFC5101] Claise, B., Bryant, S., Leinen, S., Dietz, T., and 915 Trammell, B., "Specification of the IPFIX Protocol for the 916 Exchange of IP Traffic Flow Information", RFC 5101, 917 January 2008. 919 [RFC5102] Quittek, J., Bryant, S. Claise, B., Aitken, P., and Meyer, 920 J., "Information Model for IP Flow Information Export", 921 RFC 5102, January 2008. 923 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow Export 924 Using IP Flow Information Export (IPFIX)", RFC 5103, 925 January 2008. 927 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow 928 Information Export (IPFIX) Implementation Guidelines", 929 RFC5153, April 2008. 931 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 932 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 933 May 2008. 935 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 936 "Architecture for IP Flow Information Export", RFC5470, 937 March 2009. 939 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP 940 Flow Information Export (IPFIX) Testing", RFC5471, March 941 2009. 943 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 944 Flow Information Export (IPFIX) Applicability", RFC5472, 945 March 2009. 947 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy 948 in IP Flow Information Export (IPFIX) and Packet Sampling 949 (PSAMP) Reports", RFC5473, March 2009. 951 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 952 "Exporting Type Information for IP Flow Information Export 953 (IPFIX) Information Elements", July 2009. 955 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP 956 Flow Information Export (IPFIX) Mediation: Framework", 957 RFC6183, April 2011. 959 [RFC6615] 960 Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 961 "Definitions of Managed Objects for IP Flow Information 962 Export", RFC6615, June 2012. 964 [RFC6728] 965 Muenz, G., Claise, B., and P. Aitken, "Configuration Data 966 Model for IPFIX and PSAMP", RFC 6728, October 2012. 968 [IPFIX-MED-PROTO] 969 Claise, B., Kobayashi, A., and B. Trammell, "Operation of 970 the IP Flow Information Export (IPFIX) Protocol on IPFIX 971 Mediators", draft-ietf-ipfix-mediation-protocol-02, Work 972 in Progress, July 2012. 974 [IPFIX-IANA] 975 http://www.iana.org/assignments/ipfix/ipfix.xml 977 [PEN-IANA] 978 http://www.iana.org/assignments/enterprise-numbers 980 [IPFIX-XML-SCHEMA] 981 http://www.iana.org/assignments/xml- 982 registry/schema/ipfix.xsd 984 Authors' Addresses 986 Benoit Claise (Ed.) 987 Cisco Systems 988 De Kleetlaan 6a b1 989 1831 Diegem 990 Belgium 992 Phone: +32 2 704 5622 993 EMail: bclaise@cisco.com 995 Brian Trammell (Ed.) 996 Swiss Federal Institute of Technology Zurich 997 Gloriastrasse 35 998 8092 Zurich 999 Switzerland 1001 Phone: +41 44 632 70 13 1002 EMail: trammell@tik.ee.ethz.ch 1004 Contributors' Addresses 1006 Juergen Quittek 1007 NEC 1008 Kurfuersten-Anlage 36 1009 Heidelberg 69115 1010 Germany 1012 Phone: +49 6221 90511-15 1013 EMail: quittek@nw.neclab.eu 1014 URI: http://www.neclab.eu/ 1015 Stewart Bryant 1016 Cisco Systems, Inc. 1017 250, Longwater Ave., Green Park 1018 Reading RG2 6GB 1019 United Kingdom 1021 EMail: stbryant@cisco.com 1023 Paul Aitken 1024 Cisco Systems, Inc. 1025 96 Commercial Quay 1026 Edinburgh EH6 6LX 1027 Scotland 1029 Phone: +44 131 561 3616 1030 EMail: paitken@cisco.com 1032 Jeff Meyer 1033 PayPal 1034 2211 N. First St. 1035 San Jose, CA 95131-2021 1036 US 1038 Phone: +1 408 976-9149 1039 EMail: jemeyer@paypal.com 1040 URI: http://www.paypal.com