idnits 2.17.1 draft-ietf-ipfix-information-model-rfc5102bis-03.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 (July 13, 2012) is 4277 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-00 -- Possible downref: Normative reference to a draft: ref. 'RFC5101bis' == Outdated reference: A later version (-07) exists of draft-ietf-ipfix-ie-doctors-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5102 (ref. 'RFC5103') (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-11) exists of draft-ietf-ipfix-configuration-model-10 == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-mediation-protocol-00 == Outdated reference: A later version (-03) exists of draft-ietf-ipfix-rfc5815bis-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 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: January 14, 2013 July 13, 2012 8 Information Model for IP Flow Information eXport (IPFIX) 9 draft-ietf-ipfix-information-model-rfc5102bis-03.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 . . . . . . . 8 64 3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.1. Abstract Data Types . . . . . . . . . . . . . . . . . . . 9 66 3.1.1. unsigned8 . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.1.7. signed32 . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.1.8. signed64 . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.1.9. float32 . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.1.10. float64 . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 11 81 3.1.16. dateTimeMilliseconds . . . . . . . . . . . . . . . . 11 82 3.1.17. dateTimeMicroseconds . . . . . . . . . . . . . . . . 11 83 3.1.18. dateTimeNanoseconds . . . . . . . . . . . . . . . . . 11 84 3.1.19. ipv4Address . . . . . . . . . . . . . . . . . . . . . 11 85 3.1.20. ipv6Address . . . . . . . . . . . . . . . . . . . . . 11 86 3.2. Data Type Semantics . . . . . . . . . . . . . . . . . . . 11 87 3.2.1. quantity . . . . . . . . . . . . . . . . . . . . . . . 11 88 3.2.2. totalCounter . . . . . . . . . . . . . . . . . . . . . 12 89 3.2.3. deltaCounter . . . . . . . . . . . . . . . . . . . . . 12 90 3.2.4. identifier . . . . . . . . . . . . . . . . . . . . . . 12 91 3.2.5. flags . . . . . . . . . . . . . . . . . . . . . . . . 12 92 4. Information Element Identifiers . . . . . . . . . . . . . . . 12 93 4.1. NetFlow version 9 compatible Information Element 94 Identifiers . . . . . . . . . . . . . . . . . . . . . . . 13 96 5. Information Element Categories . . . . . . . . . . . . . . . . 15 97 5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 16 98 5.3. Metering and Exporting Process Statistics . . . . . . . . 17 99 5.4. IP Header Fields . . . . . . . . . . . . . . . . . . . . . 17 100 5.5. Transport Header Fields . . . . . . . . . . . . . . . . . 18 101 5.6. Sub-IP Header Fields . . . . . . . . . . . . . . . . . . . 19 102 5.7. Derived Packet Properties . . . . . . . . . . . . . . . . 19 103 5.9. Flow Timestamps . . . . . . . . . . . . . . . . . . . . . 20 104 5.10. Per-Flow Counters . . . . . . . . . . . . . . . . . . . . 20 105 5.11. Miscellaneous Flow Properties . . . . . . . . . . . . . . 21 106 5.12. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 6. Extending the Information Model . . . . . . . . . . . . . . . 22 108 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 109 7.1. IPFIX Information Elements . . . . . . . . . . . . . . . . 23 110 7.2. MPLS Label Type Identifier . . . . . . . . . . . . . . . . 23 111 7.3. XML Namespace and Schema . . . . . . . . . . . . . . . . . 23 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 115 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 116 10.2. Informative References . . . . . . . . . . . . . . . . . 25 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 119 OPEN ISSUES: 121 review the NetFlow V9-compatible Information Elements table in 122 Section 4 to ensure that it includes V9 IEs recently made 123 compatible/non-proprietary: 82, 83, 91, 98, 99. What about 124 deltaFlowCount (3)? On second thought, consider removing these 125 tables, they add nothing and ignore the last five years. 127 1. Introduction 129 The IP Flow Information eXport (IPFIX) protocol serves for 130 transmitting information related to measured IP traffic over the 131 Internet. The protocol specification in [RFC5101bis] defines how 132 Information Elements are transmitted. For Information Elements, it 133 specifies the encoding of a set of basic data types. However, the 134 list of Information Elements that can be transmitted by the protocol, 135 such as Flow attributes (source IP address, number of packets, etc.) 136 and information about the Metering and Exporting Process (packet 137 Observation Point, sampling rate, Flow timeout interval, etc.), is 138 not specified in [RFC5101bis]. 140 The canonical reference for IPFIX Information Elements the IANA IPFIX 141 Information Element registry [IPFIX-IANA]; the initial values for 142 this registry were provided by [RFC5102]. 144 This document complements the IPFIX protocol specification by 145 providing an overview of the IPFIX information model and specifying 146 data types for it. IPFIX-specific terminology used in this document 147 is defined in Section 2 of [RFC5101bis]. As in [RFC5101bis], these 148 IPFIX-specific terms have the first letter of a word capitalized when 149 used in this document. 151 The use of the term 'information model' is not fully in line with the 152 definition of this term in [RFC3444]. The IPFIX information model 153 does not specify relationships between Information Elements, but also 154 it does not specify a concrete encoding of Information Elements. 155 Besides the encoding used by the IPFIX protocol, other encodings of 156 IPFIX Information Elements can be applied, for example, XML-based 157 encodings. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 1.1. Changes since RFC 5102 165 This document obsoletes the Proposed Standard revision of the IPFIX 166 Protocol Specification [RFC5102]. The following changes have been 167 made to this document with respect to the previous document: 169 - EDITOR'S NOTE: not sure if we need to this information 170 Errata ID: 1307 (technical) 171 Errata ID: 1492 (technical) 172 Errata ID: 1736 (technical) 173 Errata ID: 2879 (editorial) 174 Errata ID: 2944, which updates 1737 (technical) 175 Errata ID: 2945, which updates 1738 (technical) 176 Errata ID: 2946, which updates 1739 (technical) 177 Updated the reference to RFC5101bis 178 Clarified the time-related IEs 180 - Since this document is based on the IPFIX Draft Standard 181 [RFC5101bis], all improvements have been taken into account. For 182 example, the timestamps.- Instead of repeating every Information 183 Elements from [RFC5102], a reference to the IPFIX IANA registry 184 [IPFIX-IANA] is introduced. However the category in section 5 have 185 been kept.- The appendix A and B have been removed- Introduced 186 [IPFIX-IE-DOCTORS] 188 1.2. IPFIX Documents Overview 189 The IPFIX protocol provides network administrators with access to IP 190 flow information. The architecture for the export of measured IP 191 flow information out of an IPFIX Exporting Process to a Collecting 192 Process is defined in [RFC5470], per the requirements defined in 193 [RFC3917]. The IPFIX specifications [RFC5101bis] document specifies 194 how IPFIX data records and templates are carried via a number of 195 transport protocols from IPFIX Exporting Processes to IPFIX 196 Collecting Processes. 198 Four IPFIX optimizations/extensions are currently specified: a 199 bandwidth saving method for the IPFIX protocol in [RFC5473], an 200 efficient method for exporting bidirectional flow in [RFC5103], a 201 method for the definition and export of complex data structures in 202 [RFC6313], and the specification of the Protocol for IPFIX Mediations 203 [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183]. 205 IPFIX has a formal description of IPFIX Information Elements, their 206 name, type and additional semantic information, as specified in this 207 document, with the export of the Information Element types specified 208 in [RFC5610]. 210 [IPFIX-CONF] specifies a data model for configuring and monitoring 211 IPFIX and PSAMP compliant devices using the NETCONF protocol, while 212 the [RFC5815bis] specifies a MIB module for monitoring. 214 In terms of development, [RFC5153] provides guidelines for the 215 implementation and use of the IPFIX protocol, while [RFC5471] 216 provides guidelines for testing. 218 Finally, [RFC5472] describes what type of applications can use the 219 IPFIX protocol and how they can use the information provided. It 220 furthermore shows how the IPFIX framework relates to other 221 architectures and frameworks. 223 2. Properties of IPFIX Protocol Information Elements 225 2.1. Information Element Specification Template 227 Information in messages of the IPFIX protocol is modeled in terms of 228 Information Elements of the IPFIX information model. The IPFIX 229 Information Elements mentioned in Section 5 are specified in [IPFIX- 230 IANA]. For specifying these Information Elements, a template is used 231 that is described below. 233 All Information Elements specified for the IPFIX protocol MUST have 234 the following properties defined: 236 name - A unique and meaningful name for the Information Element. 238 elementId - A numeric identifier of the Information Element. If this 239 identifier is used without an enterprise identifier (see 240 [RFC5101bis] and enterpriseId below), then it is globally unique 241 and the list of allowed values is administered by IANA. It is 242 used for compact identification of an Information Element when 243 encoding Templates in the protocol. 245 description - The semantics of this Information Element. Describes 246 how this Information Element is derived from the Flow or other 247 information available to the observer. Information Elements of 248 dataType string or octetArray which have a length constraints 249 (fixed length, minimum and/or maximum length) MUST note these 250 constraints in their description. 252 dataType - One of the types listed in Section 3.1 of this document or 253 registered in the IANA IPFIX Information Element Data Types 254 registry. The type space for attributes is constrained to 255 facilitate implementation. The existing type space does however 256 encompass most basic types used in modern programming languages, 257 as well as some derived types (such as ipv4Address) that are 258 common to this domain and useful to distinguish. 260 status - The status of the specification of this Information Element. 261 Allowed values are 'current', 'deprecated', and 'obsolete'. All 262 newly-defined Information Elements have 'current' status. The 263 process for moving Information Elements to the 'deprecated' or 264 'obsolete' status is defined in Section 5.2 of [IPFIX-IE-DOCTORS]. 266 Enterprise-specific Information Elements MUST have the following 267 property defined: 269 enterpriseId - Enterprises may wish to define Information Elements 270 without registering them with IANA, for example, for 271 enterprise-internal purposes. For such Information Elements, the 272 Information Element identifier described above is not sufficient 273 when the Information Element is used outside the enterprise. If 274 specifications of enterprise-specific Information Elements are 275 made public and/or if enterprise-specific identifiers are used by 276 the IPFIX protocol outside the enterprise, then the 277 enterprise-specific identifier MUST be made globally unique by 278 combining it with an enterprise identifier. Valid values for the 279 enterpriseId are defined by IANA as Structure of Management 280 Information (SMI) network management private enterprise codes. 281 They are defined at http://www.iana.org/assignments/enterprise- 282 numbers. 284 All Information Elements specified for the IPFIX protocol either in 285 this document or by any future extension MAY have the following 286 properties defined: 288 dataTypeSemantics - The integral types may be qualified by additional 289 semantic details. Valid values for the data type semantics are 290 specified in Section 3.2 of this document or in a future extension 291 of the information model. 293 units - If the Information Element is a measure of some kind, the 294 units identify what the measure is. 296 range - Some Information Elements may only be able to take on a 297 restricted set of values that can be expressed as a range (e.g., 0 298 through 511 inclusive). If this is the case, the valid inclusive 299 range should be specified. 301 reference - Identifies additional specifications that more precisely 302 define this item or provide additional context for its use. 304 Information Elements replacing an enterprise-specific Information 305 Element used for experimental or pre-standardization purposes SHOULD 306 define the following property, as outlined in Section 4.9 of [IPFIX- 307 IE-DOCTORS]. 309 enterpriseSpecificReference - The enterpriseId and elementId of the 310 enterprise-specific Information Element(s) replaced by this 311 Information Element. 313 The following two Information Element properties are defined to allow 314 the management of an Information Element registry with Information 315 Element definitions that may be updated over time, per the process 316 defined in Section 5.2 of [IPFIX-IE-DOCTORS]. 318 revision - The revision number of an Information Element, starting at 319 0 for Information Elements at time of definition, and incremented 320 by one for each revision. 322 date - The date of the entry of this revision of the Information 323 Element into the registry. 325 For Information Elements of the string or octetArray data types which 326 have size limits (minimum and/or maximum size, or fixed length), the 327 limits MUST be defined within the description of the Information 328 Element. 330 2.2. Scope of Information Elements 332 By default, most Information Elements have a scope specified in their 333 definitions. 335 o The Information Elements listed in Sections 5.2 and 5.3, and 336 similar Information Elements in [IPFIX-IANA], have a default of "a 337 specific Metering Process" or of "a specific Exporting Process", 338 respectively. 340 o The Information Elements listed in Sections 5.4-5.11, and similar 341 Information Elements in [IPFIX-IANA], have a scope of "a specific 342 Flow". 344 Within Data Records defined by Option Templates, the IPFIX protocol 345 allows further limiting of the Information Element scope. The new 346 scope is specified by one or more scope fields and defined as the 347 combination of all specified scope values; see Section 3.4.2.1 on 348 IPFIX scopes in [RFC5101bis]. 350 2.3. Naming Conventions for Information Elements 352 The following naming conventions were used for naming Information 353 Elements in this document. It is recommended that extensions of the 354 model use the same conventions. 356 o Names of Information Elements SHOULD be descriptive. 358 o Names of Information Elements MUST be unique within the IANA 359 registry. Enterprise-specific Information Elements SHOULD be 360 prefixed with a vendor name. 362 o Names of Information Elements MUST start with non-capitalized 363 letters. 365 o Composed names MUST use capital letters for the first letter of 366 each component (except for the first one). All other letters are 367 non-capitalized, even for acronyms. Exceptions are made for 368 acronyms containing non-capitalized letters, such as 'IPv4' and 369 'IPv6'. Examples are sourceMacAddress and destinationIPv4Address. 371 o Middleboxes [RFC3234] may change Flow properties, such as the 372 Differentiated Service Code Point (DSCP) value or the source IP 373 address. If an IPFIX Observation Point is located in the path of 374 a Flow before one or more middleboxes that potentially modify 375 packets of the Flow, then it may be desirable to also report Flow 376 properties after the modification performed by the middleboxes. 377 An example is an Observation Point before a packet marker changing 378 a packet's IPv4 Type of Service (TOS) field that is encoded in 379 Information Element ipClassOfService. Then the value observed and 380 reported by Information Element ipClassOfService is valid at the 381 Observation Point, but not after the packet passed the packet 382 marker. For reporting the change value of the TOS field, the 383 IPFIX information model uses Information Elements that have a name 384 prefix "post", for example, "postIpClassOfService". Information 385 Elements with prefix "post" report on Flow properties that are not 386 necessarily observed at the Observation Point, but which are 387 obtained within the Flow's Observation Domain by other means 388 considered to be sufficiently reliable, for example, by analyzing 389 the packet marker's marking tables. 391 3. Type Space 393 This section describes the abstract data types that can be used for 394 the specification of IPFIX Information Elements in Section 4. 395 Section 3.1 describes the set of abstract data types. 397 Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, 398 signed8, signed16, signed32, and signed64 are integral data types. 399 As described in Section 3.2, their data type semantics can be further 400 specified, for example, by 'totalCounter', 'deltaCounter', 401 'identifier', or 'flags'. 403 3.1. Abstract Data Types 405 This section describes the set of valid abstract data types of the 406 IPFIX information model. Note that further abstract data types may 407 be specified by future extensions of the IPFIX information model. 409 3.1.1. unsigned8 411 The type "unsigned8" represents a non-negative integer value in the 412 range of 0 to 255. 414 3.1.2. unsigned16 416 The type "unsigned16" represents a non-negative integer value in the 417 range of 0 to 65535. 419 3.1.3. unsigned32 421 The type "unsigned32" represents a non-negative integer value in the 422 range of 0 to 4294967295. 424 3.1.4. unsigned64 426 The type "unsigned64" represents a non-negative integer value in the 427 range of 0 to 18446744073709551615. 429 3.1.5. signed8 430 The type "signed8" represents an integer value in the range of -128 431 to 127. 433 3.1.6. signed16 435 The type "signed16" represents an integer value in the range of 436 -32768 to 32767. 438 3.1.7. signed32 440 The type "signed32" represents an integer value in the range of 441 -2147483648 to 2147483647. 443 3.1.8. signed64 445 The type "signed64" represents an integer value in the range of 446 -9223372036854775808 to 9223372036854775807. 448 3.1.9. float32 450 The type "float32" corresponds to an IEEE single-precision 32-bit 451 floating point type as defined in [IEEE.754.1985]. 453 3.1.10. float64 455 The type "float64" corresponds to an IEEE double-precision 64-bit 456 floating point type as defined in [IEEE.754.1985]. 458 3.1.11. boolean 460 The type "boolean" represents a binary value. The only allowed 461 values are "true" and "false". 463 3.1.12. macAddress 465 The type "macAddress" represents a string of 6 octets. 467 3.1.13. octetArray 469 The type "octetArray" represents a finite-length string of octets. 471 3.1.14. string 473 The type "string" represents a finite-length string of valid 474 characters from the Unicode character encoding set 475 [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many 476 other international character sets to be used. 478 3.1.15. dateTimeSeconds 480 The data type dateTimeSeconds is an unsigned 32-bit integer 481 representing the number of seconds since the UNIX epoch, 1 January 482 1970 at 00:00 UTC, as defined in [POSIX.1]. 484 3.1.16. dateTimeMilliseconds 486 The data type dateTimeMilliseconds is an unsigned 64-bit integer 487 containing the number of milliseconds since the UNIX epoch, 1 January 488 1970 at 00:00 UTC, as defined in [POSIX.1]. 490 3.1.17. dateTimeMicroseconds 492 The type "dateTimeMicroseconds" represents a time value with 493 microsecond precision according to the NTP Timestamp format as 494 defined in section 6 of [RFC5905]. 496 3.1.18. dateTimeNanoseconds 498 The type "dateTimeNanoseconds" represents a time value with 499 nanosecond precision according to the NTP Timestamp format as defined 500 in section 6 of [RFC5905]. 502 3.1.19. ipv4Address 504 The type "ipv4Address" represents a value of an IPv4 address. 506 3.1.20. ipv6Address 508 The type "ipv6Address" represents a value of an IPv6 address. 510 3.2. Data Type Semantics 512 This section describes the set of valid data type semantics of the 513 IPFIX information model. A registry of data type semantics is 514 established in [RFC5610]; the restrictions specified in section 3.10 515 of that document are followed here. Note that further data type 516 semantics may be specified by future extensions of the IPFIX 517 information model. These semantics apply only to numeric types, as 518 noted in the description of each semantic below. 520 3.2.1. quantity 522 A numeric (integral or floating point) value representing a measured 523 value pertaining to the record. This is distinguished from counters 524 that represent an ongoing measured value whose "odometer" reading is 525 captured as part of a given record. This is the default semantic type 526 of all numeric data types. 528 3.2.2. totalCounter 530 An numeric value reporting the value of a counter. Counters are 531 unsigned and wrap back to zero after reaching the limit of the type. 532 For example, an unsigned64 with counter semantics will continue to 533 increment until reaching the value of 2**64 - 1. At this point, the 534 next increment will wrap its value to zero and continue counting from 535 zero. The semantics of a total counter is similar to the semantics of 536 counters used in SNMP, such as Counter32 defined in [RFC2578]. The 537 only difference between total counters and counters used in SNMP is 538 that the total counters have an initial value of 0. A total counter 539 counts independently of the export of its value. 541 3.2.3. deltaCounter 543 An numeric value reporting the value of a counter. Counters are 544 unsigned and wrap back to zero after reaching the limit of the type. 545 For example, an unsigned64 with counter semantics will continue to 546 increment until reaching the value of 2**64 - 1. At this point, the 547 next increment will wrap its value to zero and continue counting from 548 zero. The semantics of a delta counter is similar to the semantics of 549 counters used in SNMP, such as Counter32 defined in RFC 2578 550 [RFC2578]. The only difference between delta counters and counters 551 used in SNMP is that the delta counters have an initial value of 0. A 552 delta counter is reset to 0 each time its value is exported. 554 3.2.4. identifier 556 An integral value that serves as an identifier. Specifically, 557 mathematical operations on two identifiers (aside from the equality 558 operation) are meaningless. For example, Autonomous System ID 1 * 559 Autonomous System ID 2 is meaningless. Identifiers MUST be one of the 560 signed or unsigned data types. 562 3.2.5. flags 564 An integral value that represents a set of bit fields. Logical 565 operations are appropriate on such values, but not other mathematical 566 operations. Flags MUST always be of an unsigned data type. 568 4. Information Element Identifiers 570 All Information Elements defined in the IANA IPFIX Information 571 Element registry [IPFIX-IANA] have their identifiers assigned by 572 IANA. 574 The value of these identifiers is in the range of 1-32767. Within 575 this range, Information Element identifier values in the sub-range of 576 1-127 are compatible with field types used by NetFlow version 9 577 [RFC3954]; Information Element identifiers in this range MUST NOT be 578 assigned unless the Information Element is compatible with the 579 NetFlow version 9 protocol. Such Information Elements may ONLY be 580 requested by a NetFlow v9 expert, to be designated by the IESG. 582 In general, IANA will add newly registered Information Elements to 583 the registry, assigning the lowest available Information Element 584 identifier in the range 128-32767. 586 Enterprise-specific Information Element identifiers have the same 587 range of 1-32767, but they are coupled with an additional enterprise 588 identifier. For enterprise-specific Information Elements, Information 589 Element identifier 0 is also reserved. Enterprise-specific 590 Information Element identifiers can be chosen by an enterprise 591 arbitrarily within the range of 1-32767. The same identifier may be 592 assigned by other enterprises for different purposes; these 593 Information Elements are distinct because the Information Element 594 identifier is coupled with an enterprise identifier. 596 Enterprise identifiers MUST be registered as SMI network management 597 private enterprise code numbers with IANA. The registry can be found 598 at http://www.iana.org/assignments/enterprise-numbers. 600 4.1. NetFlow version 9 compatible Information Element Identifiers 602 The following list gives an overview of the Information Element 603 identifiers that are compatible with field types used by NetFlow 604 version 9 [RFC3954]. 606 +----+----------------------------+-------+-------------------------+ 607 | ID | Name | ID | Name | 608 +----+----------------------------+-------+-------------------------+ 609 | 1 | octetDeltaCount | 43 | RESERVED | 610 | 2 | packetDeltaCount | 44 | sourceIPv4Prefix | 611 | 3 | RESERVED | 45 | destinationIPv4Prefix | 612 | 4 | protocolIdentifier | 46 | mplsTopLabelType | 613 | 5 | ipClassOfService | 47 | mplsTopLabelIPv4Address | 614 | 6 | tcpControlBits | 48-51 | RESERVED | 615 | 7 | sourceTransportPort | 52 | minimumTTL | 616 | 8 | sourceIPv4Address | 53 | maximumTTL | 617 | 9 | sourceIPv4PrefixLength | 54 | fragmentIdentification | 618 | 10 | ingressInterface | 55 | postIpClassOfService | 619 | 11 | destinationTransportPort | 56 | sourceMacAddress | 620 | 12 | destinationIPv4Address | 57 |postDestinationMacAddress| 621 | 13 | destinationIPv4PrefixLength| 58 | vlanId | 622 | 14 | egressInterface | 59 | postVlanId | 623 | 15 | ipNextHopIPv4Address | 60 | ipVersion | 624 | 16 | bgpSourceAsNumber | 61 | flowDirection | 625 | 17 | bgpDestinationAsNumber | 62 | ipNextHopIPv6Address | 626 | 18 | bgpNexthopIPv4Address | 63 | bgpNexthopIPv6Address | 627 | 19 | postMCastPacketDeltaCount | 64 | ipv6ExtensionHeaders | 628 | 20 | postMCastOctetDeltaCount | 65-69 | RESERVED | 629 | 21 | flowEndSysUpTime | 70 | mplsTopLabelStackSection| 630 | 22 | flowStartSysUpTime | 71 | mplsLabelStackSection2 | 631 | 23 | postOctetDeltaCount | 72 | mplsLabelStackSection3 | 632 | 24 | postPacketDeltaCount | 73 | mplsLabelStackSection4 | 633 | 25 | minimumIpTotalLength | 74 | mplsLabelStackSection5 | 634 | 26 | maximumIpTotalLength | 75 | mplsLabelStackSection6 | 635 | 27 | sourceIPv6Address | 76 | mplsLabelStackSection7 | 636 | 28 | destinationIPv6Address | 77 | mplsLabelStackSection8 | 637 | 29 | sourceIPv6PrefixLength | 78 | mplsLabelStackSection9 | 638 | 30 | destinationIPv6PrefixLength| 79 | mplsLabelStackSection10 | 639 | 31 | flowLabelIPv6 | 80 | destinationMacAddress | 640 | 32 | icmpTypeCodeIPv4 | 81 | postSourceMacAddress | 641 | 33 | igmpType | 82-84 | RESERVED | 642 | 34 | RESERVED | 85 | octetTotalCount | 643 | 35 | RESERVED | 86 | packetTotalCount | 644 | 36 | flowActiveTimeout | 87 | RESERVED | 645 | 37 | flowIdleTimeout | 88 | fragmentOffset | 646 | 38 | RESERVED | 89 | RESERVED | 647 | 39 | RESERVED | 90 |mplsVpnRouteDistinguisher| 648 | 40 | exportedOctetTotalCount |91-127 | RESERVED | 649 | 41 | exportedMessageTotalCount | | | 650 | 42 |exportedFlowRecordTotalCount| | | 651 +----+----------------------------+-------+-------------------------+ 653 5. Information Element Categories 655 This section describes the Information Element category for the IPFIX 656 information model at the time that [RFC5102] was published. Since 657 this category field is not part of the IANA process for assigning new 658 Information Element (even though it has been reused, for example, in 659 [RFC5103]), the newest Information Elements in IANA [IPFIX-IANA] 660 don't have this classification. The elements are grouped into 12 661 groups according to their semantics and their applicability: 663 1. Identifiers 664 2. Metering and Exporting Process Configuration 665 3. Metering and Exporting Process Statistics 666 4. IP Header Fields 667 5. Transport Header Fields 668 6. Sub-IP Header Fields 669 7. Derived Packet Properties 670 8. Min/Max Flow Properties 671 9. Flow Timestamps 672 10. Per-Flow Counters 673 11. Miscellaneous Flow Properties 674 12. Padding 676 The Information Elements that are derived from fields of packets or 677 from packet treatment, such as the Information Elements in groups 678 4-7, can typically serve as Flow Keys used for mapping packets to 679 Flows. 681 If they do not serve as Flow Keys, their value may change from packet 682 to packet within a single Flow. For Information Elements with values 683 that are derived from fields of packets or from packet treatment and 684 for which the value may change from packet to packet within a single 685 Flow, the IPFIX information model defines that their value is 686 determined by the first packet observed for the corresponding Flow, 687 unless the description of the Information Element explicitly 688 specifies a different semantics. This simple rule allows writing all 689 Information Elements related to header fields once when the first 690 packet of the Flow is observed. For further observed packets of the 691 same Flow, only Flow properties that depend on more than one packet, 692 such as the Information Elements in groups 8-11, need to be updated. 694 Information Elements with a name having the "post" prefix, for 695 example, "postIpClassOfService", do not report properties that were 696 actually observed at the Observation Point, but retrieved by other 697 means within the Observation Domain. These Information Elements can 698 be used if there are middlebox functions within the Observation 699 Domain changing Flow properties after packets passed the Observation 700 Point. 702 5.1. Identifiers 704 Information Elements grouped in the table below are identifying 705 components of the IPFIX architecture, of an IPFIX Device, or of the 706 IPFIX protocol. All of them have an integral abstract data type and 707 data type semantics "identifier" as described in Section 3.2.4. 709 Typically, some of them are used for limiting scopes of other 710 Information Elements. However, other Information Elements MAY be 711 used for limiting scopes. Note also that all Information Elements 712 listed below MAY be used for other purposes than limiting scopes. 714 +-----+---------------------------+-----+---------------------------+ 715 | ID | Name | ID | Name | 716 +-----+---------------------------+-----+---------------------------+ 717 | 141 | lineCardId | 148 | flowId | 718 | 142 | portId | 145 | templateId | 719 | 10 | ingressInterface | 149 | observationDomainId | 720 | 14 | egressInterface | 138 | observationPointId | 721 | 143 | meteringProcessId | 137 | commonPropertiesId | 722 | 144 | exportingProcessId | | | 723 +-----+---------------------------+-----+---------------------------+ 725 See [IPFIX-IANA] for the definitions of these Information Elements. 727 5.2. Metering and Exporting Process Configuration 729 Information Elements in this section describe the configuration of 730 the Metering Process or the Exporting Process. The set of these 731 Information Elements is listed in the table below. 733 +-----+--------------------------+-----+----------------------------+ 734 | ID | Name | ID | Name | 735 +-----+--------------------------+-----+----------------------------+ 736 | 130 | exporterIPv4Address | 213 | exportInterface | 737 | 131 | exporterIPv6Address | 214 | exportProtocolVersion | 738 | 217 | exporterTransportPort | 215 | exportTransportProtocol | 739 | 211 | collectorIPv4Address | 216 | collectorTransportPort | 740 | 212 | collectorIPv6Address | 173 | flowKeyIndicator | 741 +-----+--------------------------+-----+----------------------------+ 743 See [IPFIX-IANA] for the definitions of these Information Elements. 745 5.3. Metering and Exporting Process Statistics 747 Information Elements in this section describe statistics of the 748 Metering Process and/or the Exporting Process. The set of these 749 Information Elements is listed in the table below. 751 +-----+-----------------------------+-----+-------------------------+ 752 | ID | Name | ID | Name | 753 +-----+-----------------------------+-----+-------------------------+ 754 | 41 | exportedMessageTotalCount | 165 | ignoredOctetTotalCount | 755 | 40 | exportedOctetTotalCount | 166 | notSentFlowTotalCount | 756 | 42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount | 757 | 163 | observedFlowTotalCount | 168 | notSentOctetTotalCount | 758 | 164 | ignoredPacketTotalCount | | | 759 +-----+-----------------------------+-----+-------------------------+ 761 See [IPFIX-IANA] for the definitions of these Information Elements. 763 5.4. IP Header Fields 765 Information Elements in this section indicate values of IP header 766 fields or are derived from IP header field values in combination with 767 further information. 769 +-----+----------------------------+-----+--------------------------+ 770 | ID | Name | ID | Name | 771 +-----+----------------------------+-----+--------------------------+ 772 | 60 | ipVersion | 193 | nextHeaderIPv6 | 773 | 8 | sourceIPv4Address | 195 | ipDiffServCodePoint | 774 | 27 | sourceIPv6Address | 196 | ipPrecedence | 775 | 9 | sourceIPv4PrefixLength | 5 | ipClassOfService | 776 | 29 | sourceIPv6PrefixLength | 55 | postIpClassOfService | 777 | 44 | sourceIPv4Prefix | 31 | flowLabelIPv6 | 778 | 170 | sourceIPv6Prefix | 206 | isMulticast | 779 | 12 | destinationIPv4Address | 54 | fragmentIdentification | 780 | 28 | destinationIPv6Address | 88 | fragmentOffset | 781 | 13 | destinationIPv4PrefixLength| 197 | fragmentFlags | 782 | 30 | destinationIPv6PrefixLength| 189 | ipHeaderLength | 783 | 45 | destinationIPv4Prefix | 207 | ipv4IHL | 784 | 169 | destinationIPv6Prefix | 190 | totalLengthIPv4 | 785 | 192 | ipTTL | 224 | ipTotalLength | 786 | 4 | protocolIdentifier | 191 | payloadLengthIPv6 | 787 +-----+----------------------------+-----+--------------------------+ 789 See [IPFIX-IANA] for the definitions of these Information Elements. 791 5.5. Transport Header Fields 793 The set of Information Elements related to transport header fields 794 and length includes the Information Elements listed in the table 795 below. 797 +-----+---------------------------+-----+---------------------------+ 798 | ID | Name | ID | Name | 799 +-----+---------------------------+-----+---------------------------+ 800 | 7 | sourceTransportPort | 238 | tcpWindowScale | 801 | 11 | destinationTransportPort | 187 | tcpUrgentPointer | 802 | 180 | udpSourcePort | 188 | tcpHeaderLength | 803 | 181 | udpDestinationPort | 32 | icmpTypeCodeIPv4 | 804 | 205 | udpMessageLength | 176 | icmpTypeIPv4 | 805 | 182 | tcpSourcePort | 177 | icmpCodeIPv4 | 806 | 183 | tcpDestinationPort | 139 | icmpTypeCodeIPv6 | 807 | 184 | tcpSequenceNumber | 178 | icmpTypeIPv6 | 808 | 185 | tcpAcknowledgementNumber | 179 | icmpCodeIPv6 | 809 | 186 | tcpWindowSize | 33 | igmpType | 810 +-----+---------------------------+-----+---------------------------+ 812 See [IPFIX-IANA] for the definitions of these Information Elements. 814 5.6. Sub-IP Header Fields 816 The set of Information Elements related to Sub-IP header fields 817 includes the Information Elements listed in the table below. 819 +-----+---------------------------+-----+---------------------------+ 820 | ID | Name | ID | Name | 821 +-----+---------------------------+-----+---------------------------+ 822 | 56 | sourceMacAddress | 201 | mplsLabelStackLength | 823 | 81 | postSourceMacAddress | 194 | mplsPayloadLength | 824 | 58 | vlanId | 70 | mplsTopLabelStackSection | 825 | 59 | postVlanId | 71 | mplsLabelStackSection2 | 826 | 80 | destinationMacAddress | 72 | mplsLabelStackSection3 | 827 | 57 | postDestinationMacAddress | 73 | mplsLabelStackSection4 | 828 | 146 | wlanChannelId | 74 | mplsLabelStackSection5 | 829 | 147 | wlanSSID | 75 | mplsLabelStackSection6 | 830 | 200 | mplsTopLabelTTL | 76 | mplsLabelStackSection7 | 831 | 203 | mplsTopLabelExp | 77 | mplsLabelStackSection8 | 832 | 237 | postMplsTopLabelExp | 78 | mplsLabelStackSection9 | 833 | 202 | mplsLabelStackDepth | 79 | mplsLabelStackSection10 | 834 +-----+---------------------------+-----+---------------------------+ 836 See [IPFIX-IANA] for the definitions of these Information Elements. 838 5.7. Derived Packet Properties 840 The set of Information Elements derived from packet properties (for 841 example, values of header fields) includes the Information Elements 842 listed in the table below. 844 +-----+---------------------------+-----+---------------------------+ 845 | ID | Name | ID | Name | 846 +-----+---------------------------+-----+---------------------------+ 847 | 204 | ipPayloadLength | 18 | bgpNextHopIPv4Address | 848 | 15 | ipNextHopIPv4Address | 63 | bgpNextHopIPv6Address | 849 | 62 | ipNextHopIPv6Address | 46 | mplsTopLabelType | 850 | 16 | bgpSourceAsNumber | 47 | mplsTopLabelIPv4Address | 851 | 17 | bgpDestinationAsNumber | 140 | mplsTopLabelIPv6Address | 852 | 128 | bgpNextAdjacentAsNumber | 90 | mplsVpnRouteDistinguisher | 853 | 129 | bgpPrevAdjacentAsNumber | | | 854 +-----+---------------------------+-----+---------------------------+ 856 See [IPFIX-IANA] for the definitions of these Information Elements. 858 5.9. Flow Timestamps 860 Information Elements in this section are timestamps of events. 862 Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds, 863 flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds, 864 flowStartNanoseconds, flowEndNanoseconds, and 865 systemInitTimeMilliseconds are absolute and have a well-defined fixed 866 time base, such as, for example, the number of seconds since 0000 UTC 867 Jan 1st 1970. 869 Timestamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds 870 are relative timestamps only valid within the scope of a single 871 IPFIX Message. They contain the negative time offsets relative to 872 the export time specified in the IPFIX Message Header. The maximum 873 time offset that can be encoded by these delta counters is 1 hour, 11 874 minutes, and 34.967295 seconds. 876 Timestamps flowStartSysUpTime and flowEndSysUpTime are relative 877 timestamps indicating the time relative to the last 878 (re-)initialization of the IPFIX Device. For reporting the time 879 of the last (re-)initialization, systemInitTimeMilliseconds can 880 be reported, for example, in Data Records defined by Option 881 Templates. 883 +-----+---------------------------+-----+---------------------------+ 884 | ID | Name | ID | Name | 885 +-----+---------------------------+-----+---------------------------+ 886 | 150 | flowStartSeconds | 156 | flowStartNanoseconds | 887 | 151 | flowEndSeconds | 157 | flowEndNanoseconds | 888 | 152 | flowStartMilliseconds | 158 | flowStartDeltaMicroseconds| 889 | 153 | flowEndMilliseconds | 159 | flowEndDeltaMicroseconds | 890 | 154 | flowStartMicroseconds | 160 | systemInitTimeMilliseconds| 891 | 155 | flowEndMicroseconds | 22 | flowStartSysUpTime | 892 | | | 21 | flowEndSysUpTime | 893 +-----+---------------------------+-----+---------------------------+ 895 See [IPFIX-IANA] for the definitions of these Information Elements. 897 5.10. Per-Flow Counters 899 Information Elements in this section are counters all having integer 900 values. Their values may change for every report they are used in. 901 They cannot serve as part of a Flow Key used for mapping packets to 902 Flows. However, potentially they can be used for selecting exported 903 Flows, for example, by only exporting Flows with more than a 904 threshold number of observed octets. 906 There are running counters and delta counters. Delta counters are 907 reset to zero each time their values are exported. Running counters 908 continue counting independently of the Exporting Process. 910 There are per-Flow counters and counters related to the Metering 911 Process and/or the Exporting Process. Per-Flow counters are Flow 912 properties that potentially change each time a packet belonging to 913 the Flow is observed. The set of per-Flow counters includes the 914 Information Elements listed in the table below. Counters related to 915 the Metering Process and/or the Exporting Process are described in 916 Section 5.3. 918 +-----+---------------------------+-----+---------------------------+ 919 | ID | Name | ID | Name | 920 +-----+---------------------------+-----+---------------------------+ 921 | 1 | octetDeltaCount | 134 | droppedOctetTotalCount | 922 | 23 | postOctetDeltaCount | 135 | droppedPacketTotalCount | 923 | 198 | octetDeltaSumOfSquares | 19 | postMCastPacketDeltaCount | 924 | 85 | octetTotalCount | 20 | postMCastOctetDeltaCount | 925 | 171 | postOctetTotalCount | 174 | postMCastPacketTotalCount | 926 | 199 | octetTotalSumOfSquares | 175 | postMCastOctetTotalCount | 927 | 2 | packetDeltaCount | 218 | tcpSynTotalCount | 928 | 24 | postPacketDeltaCount | 219 | tcpFinTotalCount | 929 | 86 | packetTotalCount | 220 | tcpRstTotalCount | 930 | 172 | postPacketTotalCount | 221 | tcpPshTotalCount | 931 | 132 | droppedOctetDeltaCount | 222 | tcpAckTotalCount | 932 | 133 | droppedPacketDeltaCount | 223 | tcpUrgTotalCount | 933 +-----+---------------------------+-----+---------------------------+ 935 See [IPFIX-IANA] for the definitions of these Information Elements. 937 5.11. Miscellaneous Flow Properties 939 Information Elements in this section describe properties of Flows 940 that are related to Flow start, Flow duration, and Flow termination, 941 but they are not timestamps as the Information Elements in Section 942 5.9 are. 944 +-----+---------------------------+-----+---------------------------+ 945 | ID | Name | ID | Name | 946 +-----+---------------------------+-----+---------------------------+ 947 | 36 | flowActiveTimeout | 161 | flowDurationMilliseconds | 948 | 37 | flowIdleTimeout | 162 | flowDurationMicroseconds | 949 | 136 | flowEndReason | 61 | flowDirection | 950 +-----+---------------------------+-----+---------------------------+ 952 See [IPFIX-IANA] for the definitions of these Information Elements. 954 5.12. Padding 956 This section contains a single Information Element that can be used 957 for padding of Flow Records. 959 IPFIX implementations may wish to align Information Elements within 960 Data Records or to align entire Data Records to 4-octet or 8-octet 961 boundaries. This can be achieved by including one or more 962 paddingOctets Information Elements in a Data Record. 964 +-----+---------------------------+-----+---------------------------+ 965 | ID | Name | ID | Name | 966 +-----+---------------------------+-----+---------------------------+ 967 | 210 | paddingOctets | | | 968 +-----+---------------------------+-----+---------------------------+ 970 See [IPFIX-IANA] for the definitions of these Information Elements. 972 6. Extending the Information Model 974 A key requirement for IPFIX is to allow for extension of the 975 Information Model maintained by IANA. The process for extending the 976 Information Model is defined in [IPFIX-IE-DOCTORS], which also 977 provides guidelines for authors and reviewers of new Information 978 Element definitions. 980 For new Information Elements, the type space defined in Section 3 can 981 be used. If required, new abstract data types can be added to the 982 subregistry defined in [RFC5610]. New abstract data types MUST be 983 defined in IETF Standards Track documents. 985 Enterprises may wish to define Information Elements without 986 registering them with IANA. IPFIX explicitly supports 987 enterprise-specific Information Elements. Enterprise-specific 988 Information Elements are described in Sections 2.1 and 4; guidelines 989 for using them appear in [IPFIX-IE-DOCTORS]. 991 7. IANA Considerations 993 7.1. IPFIX Information Elements 995 This document refers to Information Elements, for which the Internet 996 Assigned Numbers Authority (IANA) has created the IPFIX Information 997 Element Registry [IPFIX-IANA]. The columns of this registry must at 998 minimum be able to store the information defined in the template in 999 Section 2.1., additional columns defined in [IPFIX-IE-DOCTORS]; it may 1000 contain other information as necessary for the management of the 1001 registry. 1003 New assignments for IPFIX Information Elements will be administered by 1004 IANA through Expert Review [RFC5226], i.e., review by one of a group of 1005 experts designated by an IETF Area Director. Further considerations for 1006 this review are specified in [IPFIX-IE-DOCTORS]. 1008 [NOTE to IANA: please update the Reference for the IPFIX Information 1009 Element Registry to refer to this document, as well as to [IPFIX-IE- 1010 DOCTORS].] 1012 7.2. MPLS Label Type Identifier 1014 Information Element #46, named mplsTopLabelType, carries MPLS label 1015 types. Values for 5 different types have initially been defined. For 1016 ensuring extensibility of this information, IANA has created a new 1017 subregistry for MPLS label types and filled it with the initial list 1018 from the description Information Element #46, mplsTopLabelType. 1020 New assignments for MPLS label types will be administered by IANA 1021 through Expert Review [RFC5226], i.e., review by one of a group of 1022 experts designated by an IETF Area Director. The group of experts must 1023 double check the label type definitions with already defined label types 1024 for completeness, accuracy, and redundancy. The specification of new 1025 MPLS label types MUST be published using a well-established and 1026 persistent publication medium. 1028 [NOTE to IANA: please update the Reference for the IPFIX MPLS Label Type 1029 subregistry to refer to this document.] 1031 7.3. XML Namespace and Schema 1033 [IPFIX-XML-SCHEMA] defines an XML schema for IPFIX Information Element 1034 definitions. All Information Elements specified in [IPFIX-IANA] are 1035 defined by this schema. This schema may also be used for specifying 1036 further Information Elements in future extensions of the IPFIX 1037 information model in a machine-readable way. 1039 [IPFIX-XML-SCHEMA] uses URNs to describe an XML namespace and an XML 1040 schema for IPFIX Information Elements conforming to a registry mechanism 1041 described in [RFC3688]. Two URI assignments have been made. 1043 1. Registration for the IPFIX information model namespace 1044 * URI: urn:ietf:params:xml:ns:ipfix-info 1045 * Registrant Contact: IETF IPFIX Working Group , 1046 as designated by the IESG . 1047 * XML: None. Namespace URIs do not represent an XML. 1049 2. Registration for the IPFIX information model schema 1050 * URI: urn:ietf:params:xml:schema:ipfix-info 1051 * Registrant Contact: IETF IPFIX Working Group , 1052 as designated by the IESG . 1054 Using a machine-readable syntax for the information model enables the 1055 creation of IPFIX-aware tools that can automatically adapt to 1056 extensions to the information model, by simply reading updated 1057 information model specifications. 1059 The wide availability of XML-aware tools and libraries for client 1060 devices is a primary consideration for this choice. In particular, 1061 libraries for parsing XML documents are readily available. Also, 1062 mechanisms such as the Extensible Stylesheet Language (XSL) allow for 1063 transforming a source XML document into other documents. This 1064 document was authored in XML and transformed according to [RFC2629]. 1066 It should be noted that the use of XML in Exporters, Collectors, or 1067 other tools is not mandatory for the deployment of IPFIX. In 1068 particular, Exporting Processes do not produce or consume XML as part 1069 of their operation. It is expected that IPFIX Collectors MAY take 1070 advantage of the machine readability of the information model vs. 1071 hard coding their behavior or inventing proprietary means for 1072 accommodating extensions. 1074 8. Security Considerations 1076 The IPFIX information model itself does not directly introduce security 1077 issues. Rather, it defines a set of attributes that may for privacy or 1078 business issues be considered sensitive information. 1080 For example, exporting values of header fields may make attacks possible 1081 for the receiver of this information, which would otherwise only be 1082 possible for direct observers of the reported Flows along the data path. 1084 The underlying protocol used to exchange the information described here 1085 must therefore apply appropriate procedures to guarantee the integrity 1086 and confidentiality of the exported information. Such protocols are 1087 defined in separate documents, specifically the IPFIX protocol document 1088 [RFC5101bis]. 1090 This document does not specify any Information Element carrying keying 1091 material. If future extensions will do so, then appropriate precautions 1092 need to be taken for properly protecting such sensitive information. 1094 9. Acknowledgements 1096 The editors would like to thanks the authors of the RFC5102 [RFC5102], 1097 as this document is directly based upon this original RFC: Juergen 1098 Quittek, Stewart Bryant, Paul Aitken, and Jeff Meyer. 1100 10. References 1102 10.1. Normative References 1104 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1105 Requirement Levels", BCP 14, RFC 2119, March 1997. 1107 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and W. 1108 Kasch, "Network Time Protocol Version 4: Protocol and 1109 Algorithms Specification", RFC 5905, June 2010 1111 [RFC5101bis] 1112 Claise, B., and B. Trammell, Editors, "Specification of 1113 the IP Flow Information eXport (IPFIX) Protocol for the 1114 Exchange of IP Traffic Flow Information", draft-ietf- 1115 ipfix-protocol-rfc5101bis-00, Work in Progress, November 1116 2011. 1118 [IPFIX-IE-DOCTORS] 1119 Trammell, B., and B. Claise, "Guidelines for Authors and 1120 Reviewers of IPFIX Information Elements", draft-ietf- 1121 ipfix-ie-doctors-00, Work in Progress, November 2011. 1123 10.2. Informative References 1125 [IEEE.754.1985] 1126 Institute of Electrical and Electronics Engineers, 1127 "Standard for Binary Floating-Point Arithmetic", IEEE 1128 Standard 754, August 1985. 1130 [ISO.10646-1.1993] 1131 International Organization for Standardization, 1132 "Information Technology - Universal Multiple-octet coded 1133 Character Set (UCS) - Part 1: Architecture and Basic 1134 Multilingual Plane", ISO Standard 10646-1, May 1993. 1136 [ISO.646.1991] 1137 International Organization for Standardization, 1138 "Information technology - ISO 7-bit coded character set 1139 for information interchange", ISO Standard 646, 1991. 1141 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 1142 Technology - Portable Operating System Interface, IEEE, 1143 2008. 1145 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1146 "Structure of Management Information Version 2 (SMIv2)", 1147 STD 58, RFC 2578, April 1999. 1149 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1150 June 1999. 1152 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1153 Issues", RFC 3234, February 2002. 1155 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1156 Information Models and Data Models", RFC 3444, January 1157 2003. 1159 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1160 January 2004. 1162 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1163 "Requirements for IP Flow Information Export (IPFIX)", RFC 1164 3917, October 2004. 1166 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 1167 Version 9", RFC 3954, October 2004. 1169 [RFC5102] Trammell, B., and E. Boschi, "Bidirectional Flow Export 1170 Using IP Flow Information Export (IPFIX)", RFC 5103, 1171 January 2008. 1173 [RFC5103] Quittek, J., Bryant, S. Claise, B., Aitken, P., and J. 1174 Meyer, "Information Model for IP Flow Information Export", 1175 RFC 5102, January 2008. 1177 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow 1178 Information Export (IPFIX) Implementation Guidelines", 1179 RFC5153, April 2008. 1181 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1182 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1183 May 2008. 1185 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1186 "Architecture for IP Flow Information Export", RFC5470, 1187 March 2009. 1189 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP 1190 Flow Information Export (IPFIX) Testing", RFC5471, March 1191 2009. 1193 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 1194 Flow Information Export (IPFIX) Applicability", RFC5472, 1195 March 2009. 1197 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy 1198 in IP Flow Information Export (IPFIX) and Packet Sampling 1199 (PSAMP) Reports", RFC5473, March 2009. 1201 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 1202 "Exporting Type Information for IP Flow Information Export 1203 (IPFIX) Information Elements", July 2009. 1205 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 1206 "Export of Structured Data in IP Flow Information Export 1207 (IPFIX)", RFC6313, July 2011. 1209 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP 1210 Flow Information Export (IPFIX) Mediation: Framework", 1211 RFC6183, April 2011. 1213 [IPFIX-CONF] 1214 Muenz, G., Claise, B., and P. Aitken, "Configuration Data 1215 Model for IPFIX and PSAMP", draft-ietf-ipfix- 1216 configuration-model-10, Work in Progress, July 2011. 1218 [IPFIX-MED-PROTO] 1219 Claise, B., Kobayashi, A., and B. Trammell, "Specification 1220 of the Protocol for IPFIX Mediations", draft-ietf-ipfix- 1221 mediation-protocol-00, Work in Progress, December 2011. 1223 [RFC5815bis] 1224 Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 1225 "Definitions of Managed Objects for IP Flow Information 1226 Export", draft-ietf-ipfix-rfc5815bis-01.txt, Work in 1227 Progress, January 2012. 1229 [IPFIX-IANA] 1230 http://www.iana.org/assignments/ipfix/ipfix.xml 1232 [IPFIX-XML-SCHEMA] 1233 http://www.iana.org/assignments/xml- 1234 registry/schema/ipfix.xsd 1236 Authors' Addresses 1238 Benoit Claise 1239 Cisco Systems, Inc. 1240 De Kleetlaan 6a b1 1241 Diegem 1831 1242 Belgium 1244 Phone: +32 2 704 5622 1245 EMail: bclaise@cisco.com 1247 Brian Trammell 1248 Swiss Federal Institute of Technology Zurich 1249 Gloriastrasse 35 1250 8092 Zurich 1251 Switzerland 1253 Phone: +41 44 632 70 13 1254 EMail: trammell@tik.ee.ethz.ch