idnits 2.17.1 draft-ietf-ipfix-information-model-rfc5102bis-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2012) is 4150 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-03 -- 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 (~~), 3 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: June 17, 2013 December 14, 2012 8 Information Model for IP Flow Information eXport (IPFIX) 9 draft-ietf-ipfix-information-model-rfc5102bis-08.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 . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1.12. macAddress . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 86 3.2. Data Type Semantics . . . . . . . . . . . . . . . . . . . 11 87 3.2.1. quantity . . . . . . . . . . . . . . . . . . . . . . . 11 88 3.2.2. totalCounter . . . . . . . . . . . . . . . . . . . . . 11 89 3.2.3. deltaCounter . . . . . . . . . . . . . . . . . . . . . 11 90 3.2.4. identifier . . . . . . . . . . . . . . . . . . . . . . 12 91 3.2.5. flags . . . . . . . . . . . . . . . . . . . . . . . . 12 92 4. Information Element Identifiers . . . . . . . . . . . . . . . 12 93 5. Information Elements . . . . . . . . . . . . . . . . . . . . . 13 94 6. Extending the Information Model . . . . . . . . . . . . . . . 14 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 96 7.1. IPFIX Information Elements . . . . . . . . . . . . . . . . 15 97 7.2. MPLS Label Type Identifier . . . . . . . . . . . . . . . . 15 98 7.3. XML Namespace and Schema . . . . . . . . . . . . . . . . . 16 99 7.4. Addition, Revision, and Deprecation . . . . . . . . . . . 17 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 104 10.2. Informative References . . . . . . . . . . . . . . . . . 18 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 107 1. Introduction 109 The IP Flow Information eXport (IPFIX) protocol serves for 110 transmitting information related to network traffic measurement. The 111 protocol specification in [RFC5101bis] defines how Information 112 Elements are transmitted. For Information Elements, it specifies the 113 encoding of a set of basic data types. However, the list of 114 Information Elements that can be transmitted by the protocol, such as 115 Flow attributes (source IP address, number of packets, etc.) and 116 information about the Metering and Exporting Process (packet 117 Observation Point, sampling rate, Flow timeout interval, etc.), is 118 not specified in [RFC5101bis]. 120 The canonical reference for IPFIX Information Elements the IANA IPFIX 121 Information Element registry [IPFIX-IANA]; the initial values for 122 this registry were provided by [RFC5102]. 124 This document complements the IPFIX protocol specification 125 [RFC5101bis] by providing an overview of the IPFIX information model 126 and specifying data types for it. IPFIX-specific terminology used in 127 this document is defined in Section 2 of [RFC5101bis]. As in 128 [RFC5101bis], these IPFIX-specific terms have the first letter of a 129 word capitalized when used in this document. 131 The use of the term 'information model' is not fully in line with the 132 definition of this term in [RFC3444]. The IPFIX information model 133 does not specify relationships between Information Elements. It also 134 does not specify a concrete encoding of Information Elements; for an 135 encoding suitable for use with the IPFIX protocol, see [RFC5101bis]. 136 Besides the encoding used by the IPFIX protocol, other encodings of 137 IPFIX Information Elements can be applied, for example, XML-based 138 encodings. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 1.1. Changes since RFC 5102 146 This document obsoletes the Proposed Standard revision of the IPFIX 147 Protocol Specification [RFC5102]. The following changes have been 148 made to this document with respect to the previous document: 150 - All outstanding technical and editorial errata filed on the 151 [RFC5102] as of publication time have been corrected. 152 - All references into [RFC5101] have been updated to [RFC5101bis], 153 reflecting changes in that document as necessary. 154 - Information element definitions have been removed, as the 155 reference for these is now [IPFIX-IANA]; a historical note on 156 categorizations of information elements as defined in [RFC5102] has 157 been retained in section 5. 158 - The process for modifying [IPFIX-IANA] has been improved, and is 159 now described in [IPFIX-IE-DOCTORS]; Section 6 has been updated 160 accordingly, and a new section 7.3 gives IANA considerations for this 161 process. 162 - Definitions of timestamp data types have been clarified. 163 - Appendices A and B have been removed 165 1.2. IPFIX Documents Overview 167 The IPFIX protocol provides network administrators with access to 168 network flow information. The architecture for the export of 169 measured flow information out of an IPFIX Exporting Process to a 170 Collecting Process is defined in [RFC5470], per the requirements 171 defined in [RFC3917]. The IPFIX Protocol Specification [RFC5101bis] 172 defines how IPFIX data records and templates are carried via a number 173 of transport protocols from IPFIX Exporting Processes to IPFIX 174 Collecting Processes. 176 Four IPFIX optimizations/extensions are currently specified: a 177 bandwidth saving method for the IPFIX protocol in [RFC5473], an 178 efficient method for exporting bidirectional flows in [RFC5103], a 179 method for the definition and export of complex data structures in 180 [RFC6313], and the specification of the Protocol for IPFIX Mediations 181 [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183]. 183 IPFIX has a formal description of IPFIX Information Elements, their 184 name, type and additional semantic information, as specified in this 185 document, with the export of the Information Element types specified 186 in [RFC5610]. 188 [RFC6728] specifies a data model for configuring and monitoring IPFIX 189 and PSAMP compliant devices using the NETCONF protocol, while 190 [RFC6615] specifies a MIB module for monitoring. 192 In terms of development, [RFC5153] provides guidelines for the 193 implementation and use of the IPFIX protocol, while [RFC5471] 194 provides guidelines for testing. 196 Finally, [RFC5472] describes what type of applications can use the 197 IPFIX protocol and how they can use the information provided. It 198 furthermore shows how the IPFIX framework relates to other 199 architectures and frameworks. 201 2. Properties of IPFIX Protocol Information Elements 203 2.1. Information Element Specification Template 205 Information in messages of the IPFIX protocol is modeled in terms of 206 Information Elements of the IPFIX information model. The IPFIX 207 Information Elements mentioned in Section 5 are specified in [IPFIX- 208 IANA]. 210 All Information Elements specified for the IPFIX protocol MUST have 211 the following properties defined. 213 name - A unique and meaningful name for the Information Element. 215 elementId - A numeric identifier of the Information Element. If this 216 identifier is used without an enterprise identifier (see 217 [RFC5101bis] and enterpriseId below), then it is globally unique 218 and the list of allowed values is administered by IANA. It is 219 used for compact identification of an Information Element when 220 encoding Templates in the protocol. 222 description - The semantics of this Information Element. Describes 223 how this Information Element is derived from the Flow or other 224 information available to the observer. Information Elements of 225 dataType string or octetArray which have length constraints (fixed 226 length, minimum and/or maximum length) MUST note these constraints 227 in their description. 229 dataType - One of the types listed in Section 3.1 of this document or 230 registered in the IANA IPFIX Information Element Data Types 231 registry. The type space for attributes is constrained to 232 facilitate implementation. The existing type space encompasses 233 most primitive types used in modern programming languages, as well 234 as some derived types (such as ipv4Address) that are common to 235 this domain. 237 status - The status of the specification of this Information Element. 238 Allowed values are 'current' and 'deprecated'. All newly-defined 239 Information Elements have 'current' status. The process for moving 240 Information Elements to the 'deprecated' status is defined in 241 Section 5.2 of [IPFIX-IE-DOCTORS]. 243 Enterprise-specific Information Elements MUST have the following 244 property defined: 246 enterpriseId - Enterprises may wish to define Information Elements 247 without registering them with IANA, for example, for 248 enterprise-internal purposes. For such Information Elements, the 249 Information Element identifier described above is not sufficient 250 when the Information Element is used outside the enterprise. If 251 specifications of enterprise-specific Information Elements are 252 made public and/or if enterprise-specific identifiers are used by 253 the IPFIX protocol outside the enterprise, then the 254 enterprise-specific identifier MUST be made globally unique by 255 combining it with an enterprise identifier. Valid values for the 256 enterpriseId are defined by IANA as Structure of Management 257 Information (SMI) network management private enterprise numbers, 258 defined at [PEN-IANA]. 260 All Information Elements specified for the IPFIX protocol either in 261 this document or by any future extension MAY have the following 262 properties defined: 264 dataTypeSemantics - The integral types are qualified by additional 265 semantic details. Valid values for the data type semantics are 266 specified in Section 3.2 of this document or in a future extension 267 of the information model. 269 units - If the Information Element is a measure of some kind, the 270 units identify what the measure is. 272 range - Some Information Elements may only be able to take on a 273 restricted set of values that can be expressed as a range (e.g., 0 274 through 511 inclusive). If this is the case, the valid inclusive 275 range should be specified; values for this Information Element 276 outside the range are invalid and MUST NOT be exported. 278 reference - Identifies additional specifications that more precisely 279 define this item or provide additional context for its use. 281 The following two Information Element properties are defined to allow 282 the management of an Information Element registry with Information 283 Element definitions that may be updated over time, per the process 284 defined in Section 5.2 of [IPFIX-IE-DOCTORS]. 286 revision - The revision number of an Information Element, starting at 287 0 for Information Elements at time of definition, and incremented 288 by one for each revision. 290 date - The date of the entry of this revision of the Information 291 Element into the registry. 293 A template for specifying Information Elements in Internet-Drafts is 294 given in Section 9.1 of [IPFIX-IE-DOCTORS], and an XML Schema for 295 specifying Information Elements in the IANA IPFIX registry [IPFIX- 296 IANA] at [IPFIX-XML-SCHEMA]. 298 2.2. Scope of Information Elements 300 By default, most Information Elements have a scope specified in their 301 definitions. 303 o The Information Elements listed in Sections 5.2 and 5.3, and 304 similar Information Elements in [IPFIX-IANA], have a default of "a 305 specific Metering Process" or of "a specific Exporting Process", 306 respectively. 308 o The Information Elements listed in Sections 5.4-5.11, and similar 309 Information Elements in [IPFIX-IANA], have a scope of "a specific 310 Flow". 312 Within Data Records defined by Option Templates, the IPFIX protocol 313 allows further limiting of the Information Element scope. The new 314 scope is specified by one or more scope fields and defined as the 315 combination of all specified scope values; see Section 3.4.2.1 on 316 IPFIX scopes in [RFC5101bis]. 318 2.3. Naming Conventions for Information Elements 320 The following naming conventions were used for naming Information 321 Elements in this document. It is recommended that extensions of the 322 model use the same conventions. 324 o Names of Information Elements SHOULD be descriptive. 326 o Names of Information Elements MUST be unique within the IANA IPFIX 327 registry [IPFIX-IANA]. Enterprise-specific Information Elements 328 SHOULD be prefixed with a vendor name. 330 o Names of Information Elements MUST start with non-capitalized 331 letters. 333 o Composed names MUST use capital letters for the first letter of 334 each component (except for the first one). All other letters are 335 non-capitalized, even for acronyms. Exceptions are made for 336 acronyms containing non-capitalized letters, such as 'IPv4' and 337 'IPv6'. Examples are sourceMacAddress and destinationIPv4Address. 339 o Middleboxes [RFC3234] may change Flow properties, such as the 340 Differentiated Service Code Point (DSCP) value or the source IP 341 address. If an IPFIX Observation Point is located in the path of 342 a Flow before one or more middleboxes that potentially modify 343 packets of the Flow, then it may be desirable to also report Flow 344 properties after the modification performed by the middleboxes. 345 An example is an Observation Point before a packet marker changing 346 a packet's IPv4 Type of Service (TOS) field that is encoded in 347 Information Element ipClassOfService. Then the value observed and 348 reported by Information Element ipClassOfService is valid at the 349 Observation Point, but not after the packet passed the packet 350 marker. For reporting the change value of the TOS field, the 351 IPFIX information model uses Information Elements that have a name 352 prefix "post", for example, "postIpClassOfService". Information 353 Elements with prefix "post" report on Flow properties that are not 354 necessarily observed at the Observation Point, but which are 355 obtained within the Flow's Observation Domain by other means 356 considered to be sufficiently reliable, for example, by analyzing 357 the packet marker's marking tables. 359 3. Type Space 361 This section describes the abstract data types that can be used for 362 the specification of IPFIX Information Elements in Section 4. 363 Section 3.1 describes the set of abstract data types. 365 Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, 366 signed8, signed16, signed32, and signed64 are integral data types. 367 As described in Section 3.2, their data type semantics can be further 368 specified, for example, by 'totalCounter', 'deltaCounter', 369 'identifier', or 'flags'. 371 3.1. Abstract Data Types 373 This section describes the set of valid abstract data types of the 374 IPFIX information model. Note that further abstract data types may 375 be specified by future updates to this document. Changes to the 376 associated IPFIX Information Element Data Types subregistry [IPFIX- 377 IANA] specified in [RFC5610] require a Standards Action [RFC5226]. 379 3.1.1. unsigned8 380 The type "unsigned8" represents a non-negative integer value in the 381 range of 0 to 255. 383 3.1.2. unsigned16 385 The type "unsigned16" represents a non-negative integer value in the 386 range of 0 to 65535. 388 3.1.3. unsigned32 390 The type "unsigned32" represents a non-negative integer value in the 391 range of 0 to 4294967295. 393 3.1.4. unsigned64 395 The type "unsigned64" represents a non-negative integer value in the 396 range of 0 to 18446744073709551615. 398 3.1.5. signed8 400 The type "signed8" represents an integer value in the range of -128 401 to 127. 403 3.1.6. signed16 405 The type "signed16" represents an integer value in the range of 406 -32768 to 32767. 408 3.1.7. signed32 410 The type "signed32" represents an integer value in the range of 411 -2147483648 to 2147483647. 413 3.1.8. signed64 415 The type "signed64" represents an integer value in the range of 416 -9223372036854775808 to 9223372036854775807. 418 3.1.9. float32 420 The type "float32" corresponds to an IEEE single-precision 32-bit 421 floating point type as defined in [IEEE.754.1985]. 423 3.1.10. float64 425 The type "float64" corresponds to an IEEE double-precision 64-bit 426 floating point type as defined in [IEEE.754.1985]. 428 3.1.11. boolean 430 The type "boolean" represents a binary value. The only allowed 431 values are "true" and "false". 433 3.1.12. macAddress 435 The type "macAddress" represents a MAC-48 address as in 436 [IEEE.802-3.2002]. 438 3.1.13. octetArray 440 The type "octetArray" represents a finite-length string of octets. 442 3.1.14. string 444 The type "string" represents a finite-length string of valid 445 characters from the Unicode character encoding set 446 [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many 447 other international character sets to be used. 449 3.1.15. dateTimeSeconds 451 The data type dateTimeSeconds represents the number of seconds since 452 the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 454 3.1.16. dateTimeMilliseconds 456 The data type dateTimeMilliseconds represents the number of 457 milliseconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as 458 defined in [POSIX.1]. 460 3.1.17. dateTimeMicroseconds 462 The type "dateTimeMicroseconds" represents a time value with 463 microsecond precision according to the NTP Timestamp format as 464 defined in section 6 of [RFC5905]. 466 3.1.18. dateTimeNanoseconds 468 The type "dateTimeNanoseconds" represents a time value with 469 nanosecond precision according to the NTP Timestamp format as defined 470 in section 6 of [RFC5905]. 472 3.1.19. ipv4Address 474 The type "ipv4Address" represents an IPv4 address. 476 3.1.20. ipv6Address 478 The type "ipv6Address" represents an IPv6 address. 480 3.2. Data Type Semantics 482 This section describes the set of valid data type semantics of the 483 IPFIX information model. A sub-registry of data type semantics 484 [IPFIX-IANA] is established in [RFC5610]; the restrictions on the use 485 of semantics below are compatible with those specified in section 486 3.10 of that document. These semantics apply only to numeric types, 487 as noted in the description of each semantic below. 489 Further data type semantics may be specified by future updates to 490 this document. Changes to the associated IPFIX Information Element 491 Semantics sub-registry [IPFIX-IANA] require a Standards Action 492 [RFC5226]. 494 3.2.1. quantity 496 A numeric (integral or floating point) value representing a measured 497 value pertaining to the record. This is distinguished from counters 498 that represent an ongoing measured value whose "odometer" reading is 499 captured as part of a given record. This is the default semantic type 500 of all numeric data types. 502 3.2.2. totalCounter 504 An numeric value reporting the value of a counter. Counters are 505 unsigned and wrap back to zero after reaching the limit of the type. 506 For example, an unsigned64 with counter semantics will continue to 507 increment until reaching the value of 2**64 - 1. At this point, the 508 next increment will wrap its value to zero and continue counting from 509 zero. The semantics of a total counter is similar to the semantics of 510 counters used in SNMP, such as Counter32 defined in [RFC2578]. The 511 only difference between total counters and counters used in SNMP is 512 that the total counters have an initial value of 0. A total counter 513 counts independently of the export of its value. 515 3.2.3. deltaCounter 517 An numeric value reporting the value of a counter. Counters are 518 unsigned and wrap back to zero after reaching the limit of the type. 519 For example, an unsigned64 with counter semantics will continue to 520 increment until reaching the value of 2**64 - 1. At this point, the 521 next increment will wrap its value to zero and continue counting from 522 zero. The semantics of a delta counter is similar to the semantics of 523 counters used in SNMP, such as Counter32 defined in RFC 2578 525 [RFC2578]. The only difference between delta counters and counters 526 used in SNMP is that the delta counters have an initial value of 0. A 527 delta counter is reset to 0 each time it is exported and/or expires 528 without export. 530 3.2.4. identifier 532 An integral value that serves as an identifier. Specifically, 533 mathematical operations on two identifiers (aside from the equality 534 operation) are meaningless. For example, Autonomous System ID 1 * 535 Autonomous System ID 2 is meaningless. Identifiers MUST be one of the 536 signed or unsigned data types. 538 3.2.5. flags 540 An integral value that represents a set of bit fields. Logical 541 operations are appropriate on such values, but not other mathematical 542 operations. Flags MUST always be of an unsigned data type. 544 4. Information Element Identifiers 546 All Information Elements defined in the IANA IPFIX Information 547 Element registry [IPFIX-IANA] have their identifiers assigned by 548 IANA. 550 The value of these identifiers is in the range of 1-32767. Within 551 this range, Information Element identifier values in the sub-range of 552 1-127 are compatible with field types used by NetFlow version 9 553 [RFC3954]; Information Element identifiers in this range MUST NOT be 554 assigned unless the Information Element is compatible with the 555 NetFlow version 9 protocol. Such Information Elements may ONLY be 556 requested by a NetFlow v9 expert, to be designated by the IESG. 558 In general, IANA will add newly registered Information Elements to 559 the registry, assigning the lowest available Information Element 560 identifier in the range 128-32767. 562 Enterprise-specific Information Element identifiers have the same 563 range of 1-32767, but they are coupled with an additional enterprise 564 identifier. For enterprise-specific Information Elements, Information 565 Element identifier 0 is also reserved. Enterprise-specific 566 Information Element identifiers can be chosen by an enterprise 567 arbitrarily within the range of 1-32767. The same identifier may be 568 assigned by other enterprises for different purposes; these 569 Information Elements are distinct because the Information Element 570 identifier is coupled with an enterprise identifier. 572 Enterprise identifiers MUST be registered as SMI network management 573 private enterprise code numbers with IANA. The registry can be found 574 at [PEN-IANA]. 576 5. Information Elements 578 [IPFIX-IANA] is now the normative reference for IPFIX Information 579 Elements. At the time of publication of [RFC5102], this section 580 defined the initial contents of that registry. 582 As a historical note, Information Elements were organized into 583 categories in [RFC5102] according to their semantics and their 584 applicability; these categories were not carried forward into [IPFIX- 585 IANA] as an organizing principle. The categories (with example IEs) 586 were: 588 1. Identifiers (e.g. ingressInterface) 589 2. Metering and Exporting Process Configuration 590 (e.g. exporterIPv4Address) 591 3. Metering and Exporting Process Statistics 592 (e.g. exportedOctetTotalCount) 593 4. IP Header Fields (e.g. sourceIPv4Address) 594 5. Transport Header Fields (e.g. sourceTransportPort) 595 6. Sub-IP Header Fields (e.g. sourceMacAddress) 596 7. Derived Packet Properties (e.g. bgpSourceAsNumber) 597 8. Min/Max Flow Properties (e.g. minimumIpTotalLength) 598 9. Flow Timestamps (e.g. flowStartTimeMilliseconds) 599 10. Per-Flow Counters (e.g. octetDeltaCount) 600 11. Miscellaneous Flow Properties (e.g. flowEndReason) 601 12. Padding (paddingOctets) 603 Information Elements derived from fields of packets or from packet 604 treatment can typically serve as Flow Keys used for mapping packets 605 to Flows. These Information Elements were placed in categories 4-7 in 606 the original categorization. 608 Information Elements not serving as Flow Keys may have different 609 values for each packet in a Flow. For Information Elements with 610 values derived from packets fields or packet treatment, and for which 611 the value may change from packet to packet within a single Flow, the 612 exported value of an Information Element is by default determined by 613 the first packet observed for the corresponding Flow; the description 614 of the Information Element may however explicitly specify different 615 semantics. This simple rule allows writing all Information Elements 616 related to header fields once when the first packet of the Flow is 617 observed. For further observed packets of the same Flow, only Flow 618 properties that depend on more than one packet need to be updated; 619 these Information Elements were placed in categories 8-11 in the 620 original categorization. 622 Information Elements with a name having the "post" prefix (e.g. 623 postIpClassOfService), do not necessarily report properties that were 624 actually observed at the Observation Point, but may be retrieved by 625 other means within the Observation Domain. These Information Elements 626 can be used if there are middlebox functions within the Observation 627 Domain changing Flow properties after packets passed the Observation 628 Point; they may also be reported directly by the Observation Point if 629 the Observation Point is situated such as to observe packets on both 630 sides of the middlebox. 632 6. Extending the Information Model 634 A key requirement for IPFIX is to allow for extension of the 635 Information Model via the IANA IPFIX registry [IPFIX-IANA]. New 636 Information Element definitions can be added to this registry subject 637 to an Expert Review [RFC5226], with additional process considerations 638 decribed in [IPFIX-IE-DOCTORS]; that document also provides 639 guidelines for authors and reviewers of new Information Element 640 definitions. 642 For new Information Elements, the type space defined in Section 3 can 643 be used. If required, new abstract data types can be added to the 644 data type subregistry [IPFIX-IANA] defined in [RFC5610]. New abstract 645 data types and semantics are subject to Standards Action [RFC5226], 646 and MUST be defined in IETF Standards Track documents updating this 647 document. 649 Enterprises may wish to define Information Elements without 650 registering them with IANA. IPFIX explicitly supports 651 enterprise-specific Information Elements. Enterprise-specific 652 Information Elements are described in Sections 2.1 and 4; guidelines 653 for using them appear in [IPFIX-IE-DOCTORS]. 655 7. IANA Considerations 657 7.1. IPFIX Information Elements 659 This document refers to Information Elements, for which the Internet 660 Assigned Numbers Authority (IANA) has created the IPFIX Information 661 Element Registry [IPFIX-IANA]. The columns of this registry must at 662 minimum be able to store the information defined in the template in 663 Section 2.1; it may contain other information as necessary for the 664 management of the registry. 666 New assignments for IPFIX Information Elements are administered by IANA 667 through Expert Review [RFC5226], i.e., review by one of a group of 668 experts designated by the IESG. Further considerations for this review 669 are specified in [IPFIX-IE-DOCTORS]. 671 Future assignments added to the IPFIX Information Element Registry which 672 require subregistries for enumerated values (e.g. section 7.2, below) 673 must have those subregistries added simultaneously with the new 674 assignment; additions to these subregistries must be subject to Expert 675 Review [RFC5226]. Unless specified at assignment time, the experts for 676 the subregistry will be the same as for the Information Element registry 677 as a whole. 679 Changes may also be made to the entries in this registry from time to 680 time; the process for these changes are specified in [IPFIX-IE-DOCTORS]. 682 [NOTE to IANA: please update the Reference for the IPFIX Information 683 Element Registry to refer to this document.] 685 [NOTE to IANA: on publication of this document, please set the Revision 686 of all existing Information Elements to 0.] 688 [NOTE to IANA: on publication of this document, please set the Date of 689 all existing Information Elements to the publication date of this 690 document.] 692 [NOTE to IANA: on publication of this document, please set the Name of 693 all existing Reserved Information Elements to "Assigned for NetFlow v9 694 compatibility", and the reference to [RFC3954].] 696 7.2. MPLS Label Type Identifier 698 Information Element #46, named mplsTopLabelType, carries MPLS label 699 types. Values for 5 different types have initially been defined. For 700 ensuring extensibility of this information, IANA has created a new 701 subregistry for MPLS label types and filled it with the initial list 702 from the description Information Element #46, mplsTopLabelType. 704 New assignments for MPLS label types are administered by IANA through 705 Expert Review [RFC5226], i.e., review by one of a group of experts 706 designated by an IETF Area Director. The group of experts must double 707 check the label type definitions with already defined label types for 708 completeness, accuracy, and redundancy. The specification of new MPLS 709 label types MUST be published using a well-established and persistent 710 publication medium. 712 [NOTE to IANA: please update the Reference for the IPFIX MPLS Label Type 713 subregistry to refer to this document.] 715 7.3. XML Namespace and Schema 717 [IPFIX-XML-SCHEMA] defines an XML schema for IPFIX Information Element 718 definitions. All Information Elements specified in [IPFIX-IANA] are 719 defined by this schema. This schema may also be used for specifying 720 further Information Elements in future extensions of the IPFIX 721 information model in a machine-readable way. 723 [IPFIX-XML-SCHEMA] uses URNs to describe an XML namespace and an XML 724 schema for IPFIX Information Elements conforming to a registry mechanism 725 described in [RFC3688]. Two URI assignments have been made. 727 1. Registration for the IPFIX information model namespace 728 * URI: urn:ietf:params:xml:ns:ipfix-info 729 * Registrant Contact: IETF IPFIX Working Group , 730 as designated by the IESG . 731 * XML: None. Namespace URIs do not represent an XML. 733 2. Registration for the IPFIX information model schema 734 * URI: urn:ietf:params:xml:schema:ipfix-info 735 * Registrant Contact: IETF IPFIX Working Group , 736 as designated by the IESG . 738 Using a machine-readable syntax for the information model enables the 739 creation of IPFIX-aware tools that can automatically adapt to 740 extensions to the information model, by simply reading updated 741 information model specifications. 743 The wide availability of XML-aware tools and libraries for client 744 devices is a primary consideration for this choice. In particular, 745 libraries for parsing XML documents are readily available. Also, 746 mechanisms such as the Extensible Stylesheet Language (XSL) allow for 747 transforming a source XML document into other documents. This 748 document was authored in XML and transformed according to [RFC2629]. 750 It should be noted that the use of XML in Exporters, Collectors, or 751 other tools is not mandatory for the deployment of IPFIX. In 752 particular, Exporting Processes do not produce or consume XML as part 753 of their operation. It is expected that IPFIX Collectors MAY take 754 advantage of the machine readability of the information model vs. 755 hard coding their behavior or inventing proprietary means for 756 accommodating extensions. 758 [NOTE to IANA: please update the Reference for the the IPFIX 759 information model namespace and schema to refer to this document.] 761 7.4. Addition, Revision, and Deprecation 763 As stated in Section 6, addition, revision, and deletion of Information 764 Elements in the IPFIX Information Element registry is subject to a 765 process described in [IPFIX-IE-DOCTORS]. The IE-DOCTORS experts 766 mentioned in this process are to be appointed by the IESG. 768 When IANA receives a request to add, revise, or deprecate an Information 769 Element in the IPFIX Information Elements Registry, it forwards the 770 request to the IE-DOCTORS experts for review. 772 When IANA receives an approval for a request to add an Information 773 Element definition from the IE-DOCTORS experts, it adds that Information 774 Element to the registry. The approved request may include changes made 775 by the requestor and/or reviewers as compared to the original request. 777 When IANA receives an approval for a request to revise an Information 778 Element definition from the IE-DOCTORS experts, it changes that 779 Information Element's definition in the registry, and updates the 780 Revision and Date columns as appropriate. The approved request may 781 include changes from the original request. If the original Information 782 Element was added to the registry with IETF consensus (i.e., was defined 783 by an RFC), the revision will require IETF consensus as well. 785 When IANA receives an approval for a request to deprecate an Information 786 Element definition from the IE-DOCTORS experts, it changes that 787 Information Element's definition in the registry, and updates the 788 Revision and Date columns as appropriate. The approved request may 789 include changes from the original request. If the original Information 790 Element was added to the registry with IETF consensus (i.e., was defined 791 by an RFC), the deprecation will require IETF consensus as well. 793 8. Security Considerations 795 The IPFIX information model itself does not directly introduce security 796 issues. Rather, it defines a set of attributes that may for privacy or 797 business issues be considered sensitive information. 799 For example, exporting values of header fields may make attacks possible 800 for the receiver of this information, which would otherwise only be 801 possible for direct observers of the reported Flows along the data path. 803 The underlying protocol used to exchange the information described here 804 must therefore apply appropriate procedures to guarantee the integrity 805 and confidentiality of the exported information. Such protocols are 806 defined in separate documents, specifically the IPFIX protocol document 807 [RFC5101bis]. 809 This document does not specify any Information Element carrying keying 810 material. If future extensions will do so, then appropriate precautions 811 need to be taken for properly protecting such sensitive information. 813 9. Acknowledgements 815 The editors would like to thank the authors of [RFC5102], as this 816 document is directly based upon this original RFC: Juergen Quittek, 817 Stewart Bryant, Paul Aitken, and Jeff Meyer. Thanks to Paul Aitken for 818 his detailed review. 820 10. References 822 10.1. Normative References 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and W. 828 Kasch, "Network Time Protocol Version 4: Protocol and 829 Algorithms Specification", RFC 5905, June 2010 831 [RFC5101bis] 832 Claise, B., and B. Trammell, Editors, "Specification of 833 the IP Flow Information eXport (IPFIX) Protocol for the 834 Exchange of IP Traffic Flow Information", draft-ietf- 835 ipfix-protocol-rfc5101bis-03, Work in Progress, November 836 2012. 838 [IPFIX-IE-DOCTORS] 839 Trammell, B., and B. Claise, "Guidelines for Authors and 840 Reviewers of IPFIX Information Elements", draft-ietf- 841 ipfix-ie-doctors-07, Work in Progress, October 2012. 843 10.2. Informative References 845 [IEEE.802-3.2002] 846 Insitute of Electrical and Electronics Engineers, 847 "Information technology - Telecommunications and 848 information exchange between systems - Local and 849 metropolitan area networks - Specific requirements - Part 850 3: Carrier sense multiple access with collision detection 851 (CSMA/CD) access method and physical layer 852 specifications", IEEE Standard 802.3, September 2002. 854 [IEEE.754.1985] 855 Institute of Electrical and Electronics Engineers, 856 "Standard for Binary Floating-Point Arithmetic", IEEE 857 Standard 754, August 1985. 859 [ISO.10646-1.1993] 860 International Organization for Standardization, 861 "Information Technology - Universal Multiple-octet coded 862 Character Set (UCS) - Part 1: Architecture and Basic 863 Multilingual Plane", ISO Standard 10646-1, May 1993. 865 [ISO.646.1991] 866 International Organization for Standardization, 867 "Information technology - ISO 7-bit coded character set 868 for information interchange", ISO Standard 646, 1991. 870 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 871 Technology - Portable Operating System Interface, IEEE, 872 2008. 874 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 875 "Structure of Management Information Version 2 (SMIv2)", 876 STD 58, RFC 2578, April 1999. 878 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 879 June 1999. 881 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 882 Issues", RFC 3234, February 2002. 884 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 885 Information Models and Data Models", RFC 3444, January 886 2003. 888 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 889 January 2004. 891 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 892 "Requirements for IP Flow Information Export (IPFIX)", RFC 893 3917, October 2004. 895 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 896 Version 9", RFC 3954, October 2004. 898 [RFC5101] Claise, B., Bryant, S., Leinen, S., Dietz, T., and 899 Trammell, B., "Specification of the IPFIX Protocol for the 900 Exchange of IP Traffic Flow Information", RFC 5101, 901 January 2008. 903 [RFC5102] Quittek, J., Bryant, S. Claise, B., Aitken, P., and Meyer, 904 J., "Information Model for IP Flow Information Export", 905 RFC 5102, January 2008. 907 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow Export 908 Using IP Flow Information Export (IPFIX)", RFC 5103, 909 January 2008. 911 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow 912 Information Export (IPFIX) Implementation Guidelines", 913 RFC5153, April 2008. 915 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 916 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 917 May 2008. 919 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 920 "Architecture for IP Flow Information Export", RFC5470, 921 March 2009. 923 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP 924 Flow Information Export (IPFIX) Testing", RFC5471, March 925 2009. 927 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 928 Flow Information Export (IPFIX) Applicability", RFC5472, 929 March 2009. 931 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy 932 in IP Flow Information Export (IPFIX) and Packet Sampling 933 (PSAMP) Reports", RFC5473, March 2009. 935 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 936 "Exporting Type Information for IP Flow Information Export 937 (IPFIX) Information Elements", July 2009. 939 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP 940 Flow Information Export (IPFIX) Mediation: Framework", 941 RFC6183, April 2011. 943 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 944 "Export of Structured Data in IP Flow Information Export 945 (IPFIX)", RFC6313, July 2011. 947 [RFC6615] 948 Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 949 "Definitions of Managed Objects for IP Flow Information 950 Export", RFC6615, June 2012. 952 [RFC6728] 953 Muenz, G., Claise, B., and P. Aitken, "Configuration Data 954 Model for IPFIX and PSAMP", RFC 6728, October 2012. 956 [IPFIX-MED-PROTO] 957 Claise, B., Kobayashi, A., and B. Trammell, "Operation of 958 the IP Flow Information Export (IPFIX) Protocol on IPFIX 959 Mediators", draft-ietf-ipfix-mediation-protocol-02, Work 960 in Progress, July 2012. 962 [IPFIX-IANA] 963 http://www.iana.org/assignments/ipfix/ipfix.xml 965 [PEN-IANA] 966 http://www.iana.org/assignments/enterprise-numbers 968 [IPFIX-XML-SCHEMA] 969 http://www.iana.org/assignments/xml- 970 registry/schema/ipfix.xsd 972 Authors' Addresses 974 Benoit Claise 975 Cisco Systems, Inc. 976 De Kleetlaan 6a b1 977 1831 Diegem 978 Belgium 980 Phone: +32 2 704 5622 981 EMail: bclaise@cisco.com 983 Brian Trammell 984 Swiss Federal Institute of Technology Zurich 985 Gloriastrasse 35 986 8092 Zurich 987 Switzerland 989 Phone: +41 44 632 70 13 990 EMail: trammell@tik.ee.ethz.ch