idnits 2.17.1 draft-ietf-ipfix-information-model-rfc5102bis-09.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 (January 7, 2013) is 4120 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) == 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 (~~), 4 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: July 11, 2013 January 7, 2013 8 Information Model for IP Flow Information eXport (IPFIX) 9 draft-ietf-ipfix-information-model-rfc5102bis-09.txt 11 Abstract 13 This document provides an overview of the information model for the IP 14 Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX 15 Information Element Registry. It is used by the IPFIX Protocol for 16 encoding measured traffic information and information related to the 17 traffic Observation Point, the traffic Metering Process, and the 18 Exporting Process. Although developed for the IPFIX Protocol, the model 19 is defined in an open way that easily allows using it in other 20 protocols, interfaces, and applications. This document obsoletes RFC 21 5102. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute working 30 documents as Internet-Drafts. The list of current Internet-Drafts is 31 at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 23, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Changes since RFC 5102 . . . . . . . . . . . . . . . . . . 4 59 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 60 2. Properties of IPFIX Protocol Information Elements . . . . . . 5 61 2.1. Information Element Specification Template . . . . . . . . 5 62 2.2. Scope of Information Elements . . . . . . . . . . . . . . 7 63 2.3. Naming Conventions for Information Elements . . . . . . . 7 64 3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1. Abstract Data Types . . . . . . . . . . . . . . . . . . . 8 66 3.1.1. unsigned8 . . . . . . . . . . . . . . . . . . . . . . 8 67 3.1.2. unsigned16 . . . . . . . . . . . . . . . . . . . . . . 8 68 3.1.3. unsigned32 . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1.4. unsigned64 . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.5. signed8 . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.1.6. signed16 . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.7. signed32 . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1.8. signed64 . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.9. float32 . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.1.10. float64 . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1.11. boolean . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.1.12. macAddress . . . . . . . . . . . . . . . . . . . . . 9 78 3.1.13. octetArray . . . . . . . . . . . . . . . . . . . . . 10 79 3.1.14. string . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.1.15. dateTimeSeconds . . . . . . . . . . . . . . . . . . . 10 81 3.1.16. dateTimeMilliseconds . . . . . . . . . . . . . . . . 10 82 3.1.17. dateTimeMicroseconds . . . . . . . . . . . . . . . . 10 83 3.1.18. dateTimeNanoseconds . . . . . . . . . . . . . . . . . 10 84 3.1.19. ipv4Address . . . . . . . . . . . . . . . . . . . . . 10 85 3.1.20. ipv6Address . . . . . . . . . . . . . . . . . . . . . 10 86 3.1.21. basicList . . . . . . . . . . . . . . . . . . . . . . 10 87 3.1.22. subTemplateList . . . . . . . . . . . . . . . . . . . 11 88 3.1.23. subTemplateMultiList . . . . . . . . . . . . . . . . 11 89 3.2. Data Type Semantics . . . . . . . . . . . . . . . . . . . 11 90 3.2.1. quantity . . . . . . . . . . . . . . . . . . . . . . . 11 91 3.2.2. totalCounter . . . . . . . . . . . . . . . . . . . . . 11 92 3.2.3. deltaCounter . . . . . . . . . . . . . . . . . . . . . 12 93 3.2.4. identifier . . . . . . . . . . . . . . . . . . . . . . 12 94 3.2.5. flags . . . . . . . . . . . . . . . . . . . . . . . . 12 96 4. Information Element Identifiers . . . . . . . . . . . . . . . 12 97 5. Information Elements . . . . . . . . . . . . . . . . . . . . . 13 98 6. Extending the Information Model . . . . . . . . . . . . . . . 14 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 100 7.1. IPFIX Information Elements . . . . . . . . . . . . . . . . 15 101 7.2. MPLS Label Type Identifier . . . . . . . . . . . . . . . . 15 102 7.3. XML Namespace and Schema . . . . . . . . . . . . . . . . . 16 103 7.4. Addition, Revision, and Deprecation . . . . . . . . . . . 17 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 108 10.2. Informative References . . . . . . . . . . . . . . . . . 19 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 111 1. Introduction 113 The IP Flow Information eXport (IPFIX) protocol serves for 114 transmitting information related to network traffic measurement. The 115 protocol specification in [RFC5101bis] defines how Information 116 Elements are transmitted. For Information Elements, it specifies the 117 encoding of a set of basic data types. However, the list of 118 Information Elements that can be transmitted by the protocol, such as 119 Flow attributes (source IP address, number of packets, etc.) and 120 information about the Metering and Exporting Process (packet 121 Observation Point, sampling rate, Flow timeout interval, etc.), is 122 not specified in [RFC5101bis]. 124 The canonical reference for IPFIX Information Elements is the IANA 125 IPFIX Information Element registry [IPFIX-IANA]; the initial values 126 for this registry were provided by [RFC5102]. 128 This document complements the IPFIX protocol specification 129 [RFC5101bis] by providing an overview of the IPFIX information model 130 and specifying data types for it. IPFIX-specific terminology used in 131 this document is defined in Section 2 of [RFC5101bis]. As in 132 [RFC5101bis], these IPFIX-specific terms have the first letter of a 133 word capitalized when used in this document. 135 The use of the term 'information model' is not fully in line with the 136 definition of this term in [RFC3444], as the IPFIX information model 137 does not specify relationships between Information Elements. Nor does 138 the IPFIX informaiton model specify a concrete encoding of 139 Information Elements; for an encoding suitable for use with the IPFIX 140 protocol, see [RFC5101bis]. Besides the encoding used by the IPFIX 141 protocol, other encodings of IPFIX Information Elements can be 142 applied, for example, XML-based encodings. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 1.1. Changes since RFC 5102 150 This document obsoletes the Proposed Standard revision of the IPFIX 151 Protocol Specification [RFC5102]. The following changes have been 152 made to this document with respect to the previous document: 154 - All outstanding technical and editorial errata filed on the 155 [RFC5102] as of publication time have been corrected. 156 - All references into [RFC5101] have been updated to [RFC5101bis], 157 reflecting changes in that document as necessary. 158 - Information element definitions have been removed, as the 159 reference for these is now [IPFIX-IANA]; a historical note on 160 categorizations of information elements as defined in [RFC5102] has 161 been retained in section 5. 162 - The process for modifying [IPFIX-IANA] has been improved, and is 163 now described in [IPFIX-IE-DOCTORS]; Section 6 has been updated 164 accordingly, and a new section 7.3 gives IANA considerations for this 165 process. 166 - Definitions of timestamp data types have been clarified. 167 - Appendices A and B have been removed 169 1.2. IPFIX Documents Overview 171 The IPFIX protocol provides network administrators with access to 172 network flow information. The architecture for the export of 173 measured flow information out of an IPFIX Exporting Process to a 174 Collecting Process is defined in [RFC5470], per the requirements 175 defined in [RFC3917]. The IPFIX Protocol Specification [RFC5101bis] 176 defines how IPFIX data records and templates are carried via a number 177 of transport protocols from IPFIX Exporting Processes to IPFIX 178 Collecting Processes. 180 Four IPFIX optimizations/extensions are currently specified: a 181 bandwidth saving method for the IPFIX protocol in [RFC5473], an 182 efficient method for exporting bidirectional flows in [RFC5103], a 183 method for the definition and export of complex data structures in 184 [RFC6313], and the specification of the Protocol for IPFIX Mediations 185 [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183]. 187 IPFIX has a formal description of IPFIX Information Elements, their 188 name, type and additional semantic information, as specified in this 189 document, with the export of the Information Element types specified 190 in [RFC5610]. 192 [RFC6728] specifies a data model for configuring and monitoring IPFIX 193 and PSAMP compliant devices using the NETCONF protocol, while 194 [RFC6615] specifies a MIB module for monitoring. 196 In terms of development, [RFC5153] provides guidelines for the 197 implementation and use of the IPFIX protocol, while [RFC5471] 198 provides guidelines for testing. 200 Finally, [RFC5472] describes what type of applications can use the 201 IPFIX protocol and how they can use the information provided. It 202 furthermore shows how the IPFIX framework relates to other 203 architectures and frameworks. 205 2. Properties of IPFIX Protocol Information Elements 207 2.1. Information Element Specification Template 209 Information in messages of the IPFIX protocol is modeled in terms of 210 Information Elements of the IPFIX information model. The IPFIX 211 Information Elements mentioned in Section 5 are specified in [IPFIX- 212 IANA]. 214 All Information Elements specified for the IPFIX protocol MUST have 215 the following properties defined. 217 name - A unique and meaningful name for the Information Element. 219 elementId - A numeric identifier of the Information Element. If this 220 identifier is used without an enterprise identifier (see 221 [RFC5101bis] and enterpriseId below), then it is globally unique 222 and the list of allowed values is administered by IANA. It is 223 used for compact identification of an Information Element when 224 encoding Templates in the protocol. 226 description - The semantics of this Information Element. Describes 227 how this Information Element is derived from the Flow or other 228 information available to the observer. Information Elements of 229 dataType string or octetArray which have length constraints (fixed 230 length, minimum and/or maximum length) MUST note these constraints 231 in their description. 233 dataType - One of the types listed in Section 3.1 of this document or 234 registered in the IANA IPFIX Information Element Data Types 235 registry. The type space for attributes is constrained to 236 facilitate implementation. The existing type space encompasses 237 most primitive types used in modern programming languages, as well 238 as some derived types (such as ipv4Address) that are common to 239 this domain. 241 status - The status of the specification of this Information Element. 242 Allowed values are 'current' and 'deprecated'. All newly-defined 243 Information Elements have 'current' status. The process for moving 244 Information Elements to the 'deprecated' status is defined in 245 Section 5.2 of [IPFIX-IE-DOCTORS]. 247 Enterprise-specific Information Elements MUST have the following 248 property defined: 250 enterpriseId - Enterprises may wish to define Information Elements 251 without registering them with IANA, for example, for 252 enterprise-internal purposes. For such Information Elements, the 253 Information Element identifier described above is not sufficient 254 when the Information Element is used outside the enterprise. If 255 specifications of enterprise-specific Information Elements are 256 made public and/or if enterprise-specific identifiers are used by 257 the IPFIX protocol outside the enterprise, then the 258 enterprise-specific identifier MUST be made globally unique by 259 combining it with an enterprise identifier. Valid values for the 260 enterpriseId are defined by IANA as Structure of Management 261 Information (SMI) network management private enterprise numbers, 262 defined at [PEN-IANA]. 264 All Information Elements specified for the IPFIX protocol either in 265 this document or by any future extension MAY have the following 266 properties defined: 268 dataTypeSemantics - The integral types are qualified by additional 269 semantic details. Valid values for the data type semantics are 270 specified in Section 3.2 of this document or in a future extension 271 of the information model. 273 units - If the Information Element is a measure of some kind, the 274 units identify what the measure is. 276 range - Some Information Elements may only be able to take on a 277 restricted set of values that can be expressed as a range (e.g., 0 278 through 511 inclusive). If this is the case, the valid inclusive 279 range should be specified; values for this Information Element 280 outside the range are invalid and MUST NOT be exported. 282 reference - Identifies additional specifications that more precisely 283 define this item or provide additional context for its use. 285 The following two Information Element properties are defined to allow 286 the management of an Information Element registry with Information 287 Element definitions that may be updated over time, per the process 288 defined in Section 5.2 of [IPFIX-IE-DOCTORS]. 290 revision - The revision number of an Information Element, starting at 291 0 for Information Elements at time of definition, and incremented 292 by one for each revision. 294 date - The date of the entry of this revision of the Information 295 Element into the registry. 297 A template for specifying Information Elements in Internet-Drafts is 298 given in Section 9.1 of [IPFIX-IE-DOCTORS], and an XML Schema for 299 specifying Information Elements in the IANA IPFIX registry [IPFIX- 300 IANA] at [IPFIX-XML-SCHEMA]. 302 2.2. Scope of Information Elements 304 By default, most Information Elements have a scope specified in their 305 definitions. Within Data Records defined by Option Templates, the 306 IPFIX protocol allows further limiting of the Information Element 307 scope. The new scope is specified by one or more scope fields and 308 defined as the combination of all specified scope values; see Section 309 3.4.2.1 on IPFIX scopes in [RFC5101bis]. 311 2.3. Naming Conventions for Information Elements 313 The following naming conventions were used for naming Information 314 Elements in this document. It is recommended that extensions of the 315 model use the same conventions. 317 o Names of Information Elements SHOULD be descriptive. 319 o Names of Information Elements MUST be unique within the IANA IPFIX 320 registry [IPFIX-IANA]. Enterprise-specific Information Elements 321 SHOULD be prefixed with a vendor name. 323 o Names of Information Elements MUST start with non-capitalized 324 letters. 326 o Composed names MUST use capital letters for the first letter of 327 each component (except for the first one). All other letters are 328 non-capitalized, even for acronyms. Exceptions are made for 329 acronyms containing non-capitalized letters, such as 'IPv4' and 330 'IPv6'. Examples are sourceMacAddress and destinationIPv4Address. 332 o Middleboxes [RFC3234] may change Flow properties, such as the 333 Differentiated Service Code Point (DSCP) value or the source IP 334 address. If an IPFIX Observation Point is located in the path of 335 a Flow before one or more middleboxes that potentially modify 336 packets of the Flow, then it may be desirable to also report Flow 337 properties after the modification performed by the middleboxes. 338 An example is an Observation Point before a packet marker changing 339 a packet's IPv4 Type of Service (TOS) field that is encoded in 340 Information Element ipClassOfService. Then the value observed and 341 reported by Information Element ipClassOfService is valid at the 342 Observation Point, but not after the packet passed the packet 343 marker. For reporting the change value of the TOS field, the 344 IPFIX information model uses Information Elements that have a name 345 prefix "post", for example, "postIpClassOfService". Information 346 Elements with prefix "post" report on Flow properties that are not 347 necessarily observed at the Observation Point, but which are 348 obtained within the Flow's Observation Domain by other means 349 considered to be sufficiently reliable, for example, by analyzing 350 the packet marker's marking tables. 352 3. Type Space 354 This section describes the abstract data types that can be used for 355 the specification of IPFIX Information Elements in Section 4. 356 Section 3.1 describes the set of abstract data types. 358 Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, 359 signed8, signed16, signed32, and signed64 are integral data types. 360 As described in Section 3.2, their data type semantics can be further 361 specified, for example, by 'totalCounter', 'deltaCounter', 362 'identifier', or 'flags'. 364 3.1. Abstract Data Types 366 This section describes the set of valid abstract data types of the 367 IPFIX information model. Note that further abstract data types may 368 be specified by future updates to this document. Changes to the 369 associated IPFIX Information Element Data Types subregistry [IPFIX- 370 IANA] specified in [RFC5610] require a Standards Action [RFC5226]. 372 3.1.1. unsigned8 374 The type "unsigned8" represents a non-negative integer value in the 375 range of 0 to 255. 377 3.1.2. unsigned16 379 The type "unsigned16" represents a non-negative integer value in the 380 range of 0 to 65535. 382 3.1.3. unsigned32 384 The type "unsigned32" represents a non-negative integer value in the 385 range of 0 to 4294967295. 387 3.1.4. unsigned64 389 The type "unsigned64" represents a non-negative integer value in the 390 range of 0 to 18446744073709551615. 392 3.1.5. signed8 394 The type "signed8" represents an integer value in the range of -128 395 to 127. 397 3.1.6. signed16 399 The type "signed16" represents an integer value in the range of 400 -32768 to 32767. 402 3.1.7. signed32 404 The type "signed32" represents an integer value in the range of 405 -2147483648 to 2147483647. 407 3.1.8. signed64 409 The type "signed64" represents an integer value in the range of 410 -9223372036854775808 to 9223372036854775807. 412 3.1.9. float32 414 The type "float32" corresponds to an IEEE single-precision 32-bit 415 floating point type as defined in [IEEE.754.1985]. 417 3.1.10. float64 419 The type "float64" corresponds to an IEEE double-precision 64-bit 420 floating point type as defined in [IEEE.754.1985]. 422 3.1.11. boolean 424 The type "boolean" represents a binary value. The only allowed 425 values are "true" and "false". 427 3.1.12. macAddress 429 The type "macAddress" represents a MAC-48 address as in 431 [IEEE.802-3.2002]. 433 3.1.13. octetArray 435 The type "octetArray" represents a finite-length string of octets. 437 3.1.14. string 439 The type "string" represents a finite-length string of valid 440 characters from the Unicode character encoding set 441 [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many 442 other international character sets to be used. 444 3.1.15. dateTimeSeconds 446 The data type dateTimeSeconds represents the number of seconds since 447 the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 449 3.1.16. dateTimeMilliseconds 451 The data type dateTimeMilliseconds represents the number of 452 milliseconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as 453 defined in [POSIX.1]. 455 3.1.17. dateTimeMicroseconds 457 The type "dateTimeMicroseconds" represents a time value with 458 microsecond precision according to the NTP Timestamp format as 459 defined in section 6 of [RFC5905]. 461 3.1.18. dateTimeNanoseconds 463 The type "dateTimeNanoseconds" represents a time value with 464 nanosecond precision according to the NTP Timestamp format as defined 465 in section 6 of [RFC5905]. 467 3.1.19. ipv4Address 469 The type "ipv4Address" represents an IPv4 address. 471 3.1.20. ipv6Address 473 The type "ipv6Address" represents an IPv6 address. 475 3.1.21. basicList 477 The type "basicList" supports structured data export as described in 478 [RFC6313]; see section 4.5.1 of that document for encoding details. 480 3.1.22. subTemplateList 482 The type "subTemplateList" supports structured data export as 483 described in [RFC6313]; see section 4.5.2 of that document for 484 encoding details. 486 3.1.23. subTemplateMultiList 488 The type "subTemplateMultiList" supports structured data export as 489 described in [RFC6313]; see section 4.5.3 of that document for 490 encoding details. 492 3.2. Data Type Semantics 494 This section describes the set of valid data type semantics of the 495 IPFIX information model. A sub-registry of data type semantics 496 [IPFIX-IANA] is established in [RFC5610]; the restrictions on the use 497 of semantics below are compatible with those specified in section 498 3.10 of that document. These semantics apply only to numeric types, 499 as noted in the description of each semantic below. 501 Further data type semantics may be specified by future updates to 502 this document. Changes to the associated IPFIX Information Element 503 Semantics sub-registry [IPFIX-IANA] require a Standards Action 504 [RFC5226]. 506 3.2.1. quantity 508 A numeric (integral or floating point) value representing a measured 509 value pertaining to the record. This is distinguished from counters 510 that represent an ongoing measured value whose "odometer" reading is 511 captured as part of a given record. This is the default semantic type 512 of all numeric data types. 514 3.2.2. totalCounter 516 An numeric value reporting the value of a counter. Counters are 517 unsigned and wrap back to zero after reaching the limit of the type. 518 For example, an unsigned64 with counter semantics will continue to 519 increment until reaching the value of 2**64 - 1. At this point, the 520 next increment will wrap its value to zero and continue counting from 521 zero. The semantics of a total counter is similar to the semantics of 522 counters used in SNMP, such as Counter32 defined in [RFC2578]. The 523 only difference between total counters and counters used in SNMP is 524 that the total counters have an initial value of 0. A total counter 525 counts independently of the export of its value. 527 3.2.3. deltaCounter 529 An numeric value reporting the value of a counter. Counters are 530 unsigned and wrap back to zero after reaching the limit of the type. 531 For example, an unsigned64 with counter semantics will continue to 532 increment until reaching the value of 2**64 - 1. At this point, the 533 next increment will wrap its value to zero and continue counting from 534 zero. The semantics of a delta counter is similar to the semantics of 535 counters used in SNMP, such as Counter32 defined in RFC 2578 536 [RFC2578]. The only difference between delta counters and counters 537 used in SNMP is that the delta counters have an initial value of 0. A 538 delta counter is reset to 0 each time it is exported and/or expires 539 without export. 541 3.2.4. identifier 543 An integral value that serves as an identifier. Specifically, 544 mathematical operations on two identifiers (aside from the equality 545 operation) are meaningless. For example, Autonomous System ID 1 * 546 Autonomous System ID 2 is meaningless. Identifiers MUST be one of the 547 signed or unsigned data types. 549 3.2.5. flags 551 An integral value that represents a set of bit fields. Logical 552 operations are appropriate on such values, but not other mathematical 553 operations. Flags MUST always be of an unsigned data type. 555 4. Information Element Identifiers 557 All Information Elements defined in the IANA IPFIX Information 558 Element registry [IPFIX-IANA] have their identifiers assigned by 559 IANA. 561 The value of these identifiers is in the range of 1-32767. Within 562 this range, Information Element identifier values in the sub-range of 563 1-127 are compatible with field types used by NetFlow version 9 564 [RFC3954] for historical reasons. 566 In general, IANA will add newly registered Information Elements to 567 the registry, assigning the lowest available Information Element 568 identifier in the range 128-32767. 570 Enterprise-specific Information Element identifiers have the same 571 range of 1-32767, but they are coupled with an additional enterprise 572 identifier. For enterprise-specific Information Elements, Information 573 Element identifier 0 is also reserved. Enterprise-specific 574 Information Element identifiers can be chosen by an enterprise 575 arbitrarily within the range of 1-32767. The same identifier may be 576 assigned by other enterprises for different purposes; these 577 Information Elements are distinct because the Information Element 578 identifier is coupled with an enterprise identifier. 580 Enterprise identifiers are be registered as SMI network management 581 private enterprise code numbers with IANA. The registry can be found 582 at [PEN-IANA]. 584 5. Information Elements 586 [IPFIX-IANA] is now the normative reference for IPFIX Information 587 Elements. At the time of publication of [RFC5102], this section 588 defined the initial contents of that registry. 590 As a historical note, Information Elements were organized into 591 categories in [RFC5102] according to their semantics and their 592 applicability; these categories were not carried forward into [IPFIX- 593 IANA] as an organizing principle. The categories (with example IEs) 594 were: 596 1. Identifiers (e.g. ingressInterface) 597 2. Metering and Exporting Process Configuration 598 (e.g. exporterIPv4Address) 599 3. Metering and Exporting Process Statistics 600 (e.g. exportedOctetTotalCount) 601 4. IP Header Fields (e.g. sourceIPv4Address) 602 5. Transport Header Fields (e.g. sourceTransportPort) 603 6. Sub-IP Header Fields (e.g. sourceMacAddress) 604 7. Derived Packet Properties (e.g. bgpSourceAsNumber) 605 8. Min/Max Flow Properties (e.g. minimumIpTotalLength) 606 9. Flow Timestamps (e.g. flowStartTimeMilliseconds) 607 10. Per-Flow Counters (e.g. octetDeltaCount) 608 11. Miscellaneous Flow Properties (e.g. flowEndReason) 609 12. Padding (paddingOctets) 611 Information Elements derived from fields of packets or from packet 612 treatment can typically serve as Flow Keys used for mapping packets 613 to Flows. These Information Elements were placed in categories 4-7 in 614 the original categorization. 616 Information Elements not serving as Flow Keys may have different 617 values for each packet in a Flow. For Information Elements with 618 values derived from packets fields or packet treatment, and for which 619 the value may change from packet to packet within a single Flow, the 620 exported value of an Information Element is by default determined by 621 the first packet observed for the corresponding Flow; the description 622 of the Information Element may however explicitly specify different 623 semantics. This simple rule allows writing all Information Elements 624 related to header fields once when the first packet of the Flow is 625 observed. For further observed packets of the same Flow, only Flow 626 properties that depend on more than one packet need to be updated; 627 these Information Elements were placed in categories 8-11 in the 628 original categorization. 630 Information Elements with a name having the "post" prefix (e.g. 631 postIpClassOfService), do not necessarily report properties that were 632 actually observed at the Observation Point, but may be retrieved by 633 other means within the Observation Domain. These Information Elements 634 can be used if there are middlebox functions within the Observation 635 Domain changing Flow properties after packets passed the Observation 636 Point; they may also be reported directly by the Observation Point if 637 the Observation Point is situated such as to observe packets on both 638 sides of the middlebox. 640 6. Extending the Information Model 642 A key requirement for IPFIX is to allow for extension of the 643 Information Model via the IANA IPFIX registry [IPFIX-IANA]. New 644 Information Element definitions can be added to this registry subject 645 to an Expert Review [RFC5226], with additional process considerations 646 decribed in [IPFIX-IE-DOCTORS]; that document also provides 647 guidelines for authors and reviewers of new Information Element 648 definitions. 650 For new Information Elements, the type space defined in Section 3 can 651 be used. If required, new abstract data types can be added to the 652 data type subregistry [IPFIX-IANA] defined in [RFC5610]. New abstract 653 data types and semantics are subject to Standards Action [RFC5226], 654 and MUST be defined in IETF Standards Track documents updating this 655 document. 657 Enterprises may wish to define Information Elements without 658 registering them with IANA. IPFIX explicitly supports 659 enterprise-specific Information Elements. Enterprise-specific 660 Information Elements are described in Sections 2.1 and 4; guidelines 661 for using them appear in [IPFIX-IE-DOCTORS]. 663 7. IANA Considerations 665 7.1. IPFIX Information Elements 667 This document refers to Information Elements, for which the Internet 668 Assigned Numbers Authority (IANA) has created the IPFIX Information 669 Element Registry [IPFIX-IANA]. The columns of this registry must at 670 minimum be able to store the information defined in the template in 671 Section 2.1; it may contain other information as necessary for the 672 management of the registry. 674 The process for making additions or other changes to the IPFIX 675 Information Element Registry is given in Section 7.4. 677 [NOTE to IANA: please update the Reference for the IPFIX Information 678 Element Registry to refer to this document.] 680 [NOTE to IANA: on publication of this document, please create a new 681 Revision column in the the IPFIX Information Element Registry, and set 682 the Revision of all existing Information Elements to 0.] 684 [NOTE to IANA: on publication of this document, please create a new Date 685 column in the the IPFIX Information Element Registry, and set the Date 686 of all existing Information Elements to the publication date of this 687 document.] 689 [NOTE to IANA: on publication of this document, please set the Name of 690 all existing Reserved Information Elements with identifier 127 or less 691 to "Assigned for NetFlow v9 compatibility", and the Reference to 692 [RFC3954].] 694 7.2. MPLS Label Type Identifier 696 Information Element #46, named mplsTopLabelType, carries MPLS label 697 types. Values for 5 different types have initially been defined. For 698 ensuring extensibility of this information, IANA has created a new 699 subregistry for MPLS label types and filled it with the initial list 700 from the description Information Element #46, mplsTopLabelType. 702 New assignments for MPLS label types are administered by IANA through 703 Expert Review [RFC5226], i.e., review by one of a group of experts 704 designated by an IETF Area Director. The group of experts must double 705 check the label type definitions with already defined label types for 706 completeness, accuracy, and redundancy. The specification of new MPLS 707 label types MUST be published using a well-established and persistent 708 publication medium. 710 [NOTE to IANA: please update the Reference for the IPFIX MPLS Label Type 711 subregistry to refer to this document.] 713 7.3. XML Namespace and Schema 715 [IPFIX-XML-SCHEMA] defines an XML schema for IPFIX Information Element 716 definitions. All Information Elements specified in [IPFIX-IANA] are 717 defined by this schema. This schema may also be used for specifying 718 further Information Elements in future extensions of the IPFIX 719 information model in a machine-readable way. 721 [IPFIX-XML-SCHEMA] uses URNs to describe an XML namespace and an XML 722 schema for IPFIX Information Elements conforming to a registry mechanism 723 described in [RFC3688]. Two URI assignments have been made. 725 1. Registration for the IPFIX information model namespace 726 * URI: urn:ietf:params:xml:ns:ipfix-info 727 * Registrant Contact: IETF IPFIX Working Group , 728 as designated by the IESG . 729 * XML: None. Namespace URIs do not represent an XML. 731 2. Registration for the IPFIX information model schema 732 * URI: urn:ietf:params:xml:schema:ipfix-info 733 * Registrant Contact: IETF IPFIX Working Group , 734 as designated by the IESG . 736 Using a machine-readable syntax for the information model enables the 737 creation of IPFIX-aware tools that can automatically adapt to 738 extensions to the information model, by simply reading updated 739 information model specifications. 741 The wide availability of XML-aware tools and libraries for client 742 devices is a primary consideration for this choice. In particular, 743 libraries for parsing XML documents are readily available. Also, 744 mechanisms such as the Extensible Stylesheet Language (XSL) allow for 745 transforming a source XML document into other documents. This 746 document was authored in XML and transformed according to [RFC2629]. 748 It should be noted that the use of XML in Exporters, Collectors, or 749 other tools is not mandatory for the deployment of IPFIX. In 750 particular, Exporting Processes do not produce or consume XML as part 751 of their operation. It is expected that IPFIX Collectors MAY take 752 advantage of the machine readability of the information model vs. 753 hard coding their behavior or inventing proprietary means for 754 accommodating extensions. 756 [NOTE to IANA: please update the Reference for the the IPFIX 757 information model namespace and schema to refer to this document.] 758 7.4. Addition, Revision, and Deprecation 760 New assignments for IPFIX Information Elements are administered by IANA 761 through Expert Review [RFC5226]. These experts are referred to as IE- 762 DOCTORS experts, and are appointed by the IESG. The process they follow 763 is defined in [IPFIX-IE-DOCTORS]. 765 [IANA NOTE: please establish an ie-doctors mailing list for 766 communicating with the IE-DOCTORS experts.] 768 Information Element identifiers in the range 1-127 are compatible with 769 field types used by NetFlow version 9 [RFC3954] for historical reasons, 770 and must not be assigned unless the Information Element is compatible 771 with the NetFlow version 9 protocol, as determined by an IE-DOCTORS 772 expert designated by the IESG as a Netflow version 9 expert. 774 Future assignments added to the IPFIX Information Element Registry which 775 require subregistries for enumerated values (e.g. section 7.2, below) 776 must have those subregistries added simultaneously with the new 777 assignment; additions to these subregistries must be subject to Expert 778 Review [RFC5226]. Unless specified at assignment time, the experts for 779 the subregistry will be the same as for the Information Element registry 780 as a whole. 782 When IANA receives a request to add, revise, or deprecate an Information 783 Element in the IPFIX Information Elements Registry, it forwards the 784 request to the IE-DOCTORS experts for review. 786 When IANA receives an approval for a request to add an Information 787 Element definition from the IE-DOCTORS experts, it adds that Information 788 Element to the registry. The approved request may include changes made 789 by the requestor and/or reviewers as compared to the original request. 791 When IANA receives an approval for a request to revise an Information 792 Element definition from the IE-DOCTORS experts, it changes that 793 Information Element's definition in the registry, and updates the 794 Revision and Date columns as appropriate. The approved request may 795 include changes from the original request. If the original Information 796 Element was added to the registry with IETF consensus (i.e., was defined 797 by an RFC), the revision will require IETF consensus as well. 799 When IANA receives an approval for a request to deprecate an Information 800 Element definition from the IE-DOCTORS experts, it changes that 801 Information Element's definition in the registry, and updates the 802 Revision and Date columns as appropriate. The approved request may 803 include changes from the original request. If the original Information 804 Element was added to the registry with IETF consensus (i.e., was defined 805 by an RFC), the deprecation will require IETF consensus as well. 807 8. Security Considerations 809 The IPFIX information model itself does not directly introduce security 810 issues. Rather, it defines a set of attributes that may for privacy or 811 business issues be considered sensitive information. 813 For example, exporting values of header fields may make attacks possible 814 for the receiver of this information, which would otherwise only be 815 possible for direct observers of the reported Flows along the data path. 817 The underlying protocol used to exchange the information described here 818 must therefore apply appropriate procedures to guarantee the integrity 819 and confidentiality of the exported information. Such protocols are 820 defined in separate documents, specifically the IPFIX protocol document 821 [RFC5101bis]. 823 This document does not specify any Information Element carrying keying 824 material. If future extensions will do so, then appropriate precautions 825 need to be taken for properly protecting such sensitive information. 827 9. Acknowledgements 829 The editors would like to thank the authors of [RFC5102], as this 830 document is directly based upon this original RFC: Juergen Quittek, 831 Stewart Bryant, Paul Aitken, and Jeff Meyer. Thanks to Paul Aitken for 832 his detailed review. 834 10. References 836 10.1. Normative References 838 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 839 Requirement Levels", BCP 14, RFC 2119, March 1997. 841 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and W. 842 Kasch, "Network Time Protocol Version 4: Protocol and 843 Algorithms Specification", RFC 5905, June 2010 845 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 846 "Export of Structured Data in IP Flow Information Export 847 (IPFIX)", RFC6313, July 2011. 849 [RFC5101bis] 850 Claise, B., and B. Trammell, Editors, "Specification of 851 the IP Flow Information eXport (IPFIX) Protocol for the 852 Exchange of IP Traffic Flow Information", draft-ietf- 853 ipfix-protocol-rfc5101bis-04, Work in Progress, December 854 2012. 856 [IPFIX-IE-DOCTORS] 857 Trammell, B., and B. Claise, "Guidelines for Authors and 858 Reviewers of IPFIX Information Elements", draft-ietf- 859 ipfix-ie-doctors-07, Work in Progress, October 2012. 861 10.2. Informative References 863 [IEEE.802-3.2002] 864 Insitute of Electrical and Electronics Engineers, 865 "Information technology - Telecommunications and 866 information exchange between systems - Local and 867 metropolitan area networks - Specific requirements - Part 868 3: Carrier sense multiple access with collision detection 869 (CSMA/CD) access method and physical layer 870 specifications", IEEE Standard 802.3, September 2002. 872 [IEEE.754.1985] 873 Institute of Electrical and Electronics Engineers, 874 "Standard for Binary Floating-Point Arithmetic", IEEE 875 Standard 754, August 1985. 877 [ISO.10646-1.1993] 878 International Organization for Standardization, 879 "Information Technology - Universal Multiple-octet coded 880 Character Set (UCS) - Part 1: Architecture and Basic 881 Multilingual Plane", ISO Standard 10646-1, May 1993. 883 [ISO.646.1991] 884 International Organization for Standardization, 885 "Information technology - ISO 7-bit coded character set 886 for information interchange", ISO Standard 646, 1991. 888 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 889 Technology - Portable Operating System Interface, IEEE, 890 2008. 892 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 893 "Structure of Management Information Version 2 (SMIv2)", 894 STD 58, RFC 2578, April 1999. 896 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 897 June 1999. 899 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 900 Issues", RFC 3234, February 2002. 902 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 903 Information Models and Data Models", RFC 3444, January 904 2003. 906 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 907 January 2004. 909 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 910 "Requirements for IP Flow Information Export (IPFIX)", RFC 911 3917, October 2004. 913 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 914 Version 9", RFC 3954, October 2004. 916 [RFC5101] Claise, B., Bryant, S., Leinen, S., Dietz, T., and 917 Trammell, B., "Specification of the IPFIX Protocol for the 918 Exchange of IP Traffic Flow Information", RFC 5101, 919 January 2008. 921 [RFC5102] Quittek, J., Bryant, S. Claise, B., Aitken, P., and Meyer, 922 J., "Information Model for IP Flow Information Export", 923 RFC 5102, January 2008. 925 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow Export 926 Using IP Flow Information Export (IPFIX)", RFC 5103, 927 January 2008. 929 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow 930 Information Export (IPFIX) Implementation Guidelines", 931 RFC5153, April 2008. 933 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 934 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 935 May 2008. 937 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 938 "Architecture for IP Flow Information Export", RFC5470, 939 March 2009. 941 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP 942 Flow Information Export (IPFIX) Testing", RFC5471, March 943 2009. 945 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 946 Flow Information Export (IPFIX) Applicability", RFC5472, 947 March 2009. 949 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy 950 in IP Flow Information Export (IPFIX) and Packet Sampling 951 (PSAMP) Reports", RFC5473, March 2009. 953 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 954 "Exporting Type Information for IP Flow Information Export 955 (IPFIX) Information Elements", July 2009. 957 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP 958 Flow Information Export (IPFIX) Mediation: Framework", 959 RFC6183, April 2011. 961 [RFC6615] 962 Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 963 "Definitions of Managed Objects for IP Flow Information 964 Export", RFC6615, June 2012. 966 [RFC6728] 967 Muenz, G., Claise, B., and P. Aitken, "Configuration Data 968 Model for IPFIX and PSAMP", RFC 6728, October 2012. 970 [IPFIX-MED-PROTO] 971 Claise, B., Kobayashi, A., and B. Trammell, "Operation of 972 the IP Flow Information Export (IPFIX) Protocol on IPFIX 973 Mediators", draft-ietf-ipfix-mediation-protocol-02, Work 974 in Progress, July 2012. 976 [IPFIX-IANA] 977 http://www.iana.org/assignments/ipfix/ipfix.xml 979 [PEN-IANA] 980 http://www.iana.org/assignments/enterprise-numbers 982 [IPFIX-XML-SCHEMA] 983 http://www.iana.org/assignments/xml- 984 registry/schema/ipfix.xsd 986 Authors' Addresses 988 Benoit Claise 989 Cisco Systems, Inc. 990 De Kleetlaan 6a b1 991 1831 Diegem 992 Belgium 994 Phone: +32 2 704 5622 995 EMail: bclaise@cisco.com 997 Brian Trammell 998 Swiss Federal Institute of Technology Zurich 999 Gloriastrasse 35 1000 8092 Zurich 1001 Switzerland 1003 Phone: +41 44 632 70 13 1004 EMail: trammell@tik.ee.ethz.ch