idnits 2.17.1 draft-ietf-ipfix-information-model-rfc5102bis-04.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 (August 31, 2012) is 4256 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: March 4, 2013 August 31, 2012 8 Information Model for IP Flow Information eXport (IPFIX) 9 draft-ietf-ipfix-information-model-rfc5102bis-04.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 . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 10 81 3.1.16. dateTimeMilliseconds . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 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' and 'deprecated'. All newly-defined 262 Information Elements have 'current' status. The process for moving 263 Information Elements to the 'deprecated' status is defined in 264 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 The following two Information Element properties are defined to allow 305 the management of an Information Element registry with Information 306 Element definitions that may be updated over time, per the process 307 defined in Section 5.2 of [IPFIX-IE-DOCTORS]. 309 revision - The revision number of an Information Element, starting at 310 0 for Information Elements at time of definition, and incremented 311 by one for each revision. 313 date - The date of the entry of this revision of the Information 314 Element into the registry. 316 For Information Elements of the string or octetArray data types which 317 have size limits (minimum and/or maximum size, or fixed length), the 318 limits MUST be defined within the description of the Information 319 Element. 321 2.2. Scope of Information Elements 323 By default, most Information Elements have a scope specified in their 324 definitions. 326 o The Information Elements listed in Sections 5.2 and 5.3, and 327 similar Information Elements in [IPFIX-IANA], have a default of "a 328 specific Metering Process" or of "a specific Exporting Process", 329 respectively. 331 o The Information Elements listed in Sections 5.4-5.11, and similar 332 Information Elements in [IPFIX-IANA], have a scope of "a specific 333 Flow". 335 Within Data Records defined by Option Templates, the IPFIX protocol 336 allows further limiting of the Information Element scope. The new 337 scope is specified by one or more scope fields and defined as the 338 combination of all specified scope values; see Section 3.4.2.1 on 339 IPFIX scopes in [RFC5101bis]. 341 2.3. Naming Conventions for Information Elements 343 The following naming conventions were used for naming Information 344 Elements in this document. It is recommended that extensions of the 345 model use the same conventions. 347 o Names of Information Elements SHOULD be descriptive. 349 o Names of Information Elements MUST be unique within the IANA 350 registry. Enterprise-specific Information Elements SHOULD be 351 prefixed with a vendor name. 353 o Names of Information Elements MUST start with non-capitalized 354 letters. 356 o Composed names MUST use capital letters for the first letter of 357 each component (except for the first one). All other letters are 358 non-capitalized, even for acronyms. Exceptions are made for 359 acronyms containing non-capitalized letters, such as 'IPv4' and 360 'IPv6'. Examples are sourceMacAddress and destinationIPv4Address. 362 o Middleboxes [RFC3234] may change Flow properties, such as the 363 Differentiated Service Code Point (DSCP) value or the source IP 364 address. If an IPFIX Observation Point is located in the path of 365 a Flow before one or more middleboxes that potentially modify 366 packets of the Flow, then it may be desirable to also report Flow 367 properties after the modification performed by the middleboxes. 368 An example is an Observation Point before a packet marker changing 369 a packet's IPv4 Type of Service (TOS) field that is encoded in 370 Information Element ipClassOfService. Then the value observed and 371 reported by Information Element ipClassOfService is valid at the 372 Observation Point, but not after the packet passed the packet 373 marker. For reporting the change value of the TOS field, the 374 IPFIX information model uses Information Elements that have a name 375 prefix "post", for example, "postIpClassOfService". Information 376 Elements with prefix "post" report on Flow properties that are not 377 necessarily observed at the Observation Point, but which are 378 obtained within the Flow's Observation Domain by other means 379 considered to be sufficiently reliable, for example, by analyzing 380 the packet marker's marking tables. 382 3. Type Space 384 This section describes the abstract data types that can be used for 385 the specification of IPFIX Information Elements in Section 4. 386 Section 3.1 describes the set of abstract data types. 388 Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, 389 signed8, signed16, signed32, and signed64 are integral data types. 390 As described in Section 3.2, their data type semantics can be further 391 specified, for example, by 'totalCounter', 'deltaCounter', 392 'identifier', or 'flags'. 394 3.1. Abstract Data Types 396 This section describes the set of valid abstract data types of the 397 IPFIX information model. Note that further abstract data types may 398 be specified by future extensions of the IPFIX information model. 400 3.1.1. unsigned8 402 The type "unsigned8" represents a non-negative integer value in the 403 range of 0 to 255. 405 3.1.2. unsigned16 407 The type "unsigned16" represents a non-negative integer value in the 408 range of 0 to 65535. 410 3.1.3. unsigned32 412 The type "unsigned32" represents a non-negative integer value in the 413 range of 0 to 4294967295. 415 3.1.4. unsigned64 417 The type "unsigned64" represents a non-negative integer value in the 418 range of 0 to 18446744073709551615. 420 3.1.5. signed8 422 The type "signed8" represents an integer value in the range of -128 423 to 127. 425 3.1.6. signed16 427 The type "signed16" represents an integer value in the range of 428 -32768 to 32767. 430 3.1.7. signed32 432 The type "signed32" represents an integer value in the range of 433 -2147483648 to 2147483647. 435 3.1.8. signed64 437 The type "signed64" represents an integer value in the range of 438 -9223372036854775808 to 9223372036854775807. 440 3.1.9. float32 442 The type "float32" corresponds to an IEEE single-precision 32-bit 443 floating point type as defined in [IEEE.754.1985]. 445 3.1.10. float64 447 The type "float64" corresponds to an IEEE double-precision 64-bit 448 floating point type as defined in [IEEE.754.1985]. 450 3.1.11. boolean 452 The type "boolean" represents a binary value. The only allowed 453 values are "true" and "false". 455 3.1.12. macAddress 457 The type "macAddress" represents a string of 6 octets. 459 3.1.13. octetArray 461 The type "octetArray" represents a finite-length string of octets. 463 3.1.14. string 465 The type "string" represents a finite-length string of valid 466 characters from the Unicode character encoding set 467 [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many 468 other international character sets to be used. 470 3.1.15. dateTimeSeconds 472 The data type dateTimeSeconds is an unsigned 32-bit integer 473 representing the number of seconds since the UNIX epoch, 1 January 474 1970 at 00:00 UTC, as defined in [POSIX.1]. 476 3.1.16. dateTimeMilliseconds 477 The data type dateTimeMilliseconds is an unsigned 64-bit integer 478 containing the number of milliseconds since the UNIX epoch, 1 January 479 1970 at 00:00 UTC, as defined in [POSIX.1]. 481 3.1.17. dateTimeMicroseconds 483 The type "dateTimeMicroseconds" represents a time value with 484 microsecond precision according to the NTP Timestamp format as 485 defined in section 6 of [RFC5905]. 487 3.1.18. dateTimeNanoseconds 489 The type "dateTimeNanoseconds" represents a time value with 490 nanosecond precision according to the NTP Timestamp format as defined 491 in section 6 of [RFC5905]. 493 3.1.19. ipv4Address 495 The type "ipv4Address" represents a value of an IPv4 address. 497 3.1.20. ipv6Address 499 The type "ipv6Address" represents a value of an IPv6 address. 501 3.2. Data Type Semantics 503 This section describes the set of valid data type semantics of the 504 IPFIX information model. A registry of data type semantics is 505 established in [RFC5610]; the restrictions specified in section 3.10 506 of that document are followed here. Note that further data type 507 semantics may be specified by future extensions of the IPFIX 508 information model. These semantics apply only to numeric types, as 509 noted in the description of each semantic below. 511 3.2.1. quantity 513 A numeric (integral or floating point) value representing a measured 514 value pertaining to the record. This is distinguished from counters 515 that represent an ongoing measured value whose "odometer" reading is 516 captured as part of a given record. This is the default semantic type 517 of all numeric data types. 519 3.2.2. totalCounter 521 An numeric value reporting the value of a counter. Counters are 522 unsigned and wrap back to zero after reaching the limit of the type. 523 For example, an unsigned64 with counter semantics will continue to 524 increment until reaching the value of 2**64 - 1. At this point, the 525 next increment will wrap its value to zero and continue counting from 526 zero. The semantics of a total counter is similar to the semantics of 527 counters used in SNMP, such as Counter32 defined in [RFC2578]. The 528 only difference between total counters and counters used in SNMP is 529 that the total counters have an initial value of 0. A total counter 530 counts independently of the export of its value. 532 3.2.3. deltaCounter 534 An numeric value reporting the value of a counter. Counters are 535 unsigned and wrap back to zero after reaching the limit of the type. 536 For example, an unsigned64 with counter semantics will continue to 537 increment until reaching the value of 2**64 - 1. At this point, the 538 next increment will wrap its value to zero and continue counting from 539 zero. The semantics of a delta counter is similar to the semantics of 540 counters used in SNMP, such as Counter32 defined in RFC 2578 541 [RFC2578]. The only difference between delta counters and counters 542 used in SNMP is that the delta counters have an initial value of 0. A 543 delta counter is reset to 0 each time its value is exported. 545 3.2.4. identifier 547 An integral value that serves as an identifier. Specifically, 548 mathematical operations on two identifiers (aside from the equality 549 operation) are meaningless. For example, Autonomous System ID 1 * 550 Autonomous System ID 2 is meaningless. Identifiers MUST be one of the 551 signed or unsigned data types. 553 3.2.5. flags 555 An integral value that represents a set of bit fields. Logical 556 operations are appropriate on such values, but not other mathematical 557 operations. Flags MUST always be of an unsigned data type. 559 4. Information Element Identifiers 561 All Information Elements defined in the IANA IPFIX Information 562 Element registry [IPFIX-IANA] have their identifiers assigned by 563 IANA. 565 The value of these identifiers is in the range of 1-32767. Within 566 this range, Information Element identifier values in the sub-range of 567 1-127 are compatible with field types used by NetFlow version 9 568 [RFC3954]; Information Element identifiers in this range MUST NOT be 569 assigned unless the Information Element is compatible with the 570 NetFlow version 9 protocol. Such Information Elements may ONLY be 571 requested by a NetFlow v9 expert, to be designated by the IESG. 573 In general, IANA will add newly registered Information Elements to 574 the registry, assigning the lowest available Information Element 575 identifier in the range 128-32767. 577 Enterprise-specific Information Element identifiers have the same 578 range of 1-32767, but they are coupled with an additional enterprise 579 identifier. For enterprise-specific Information Elements, Information 580 Element identifier 0 is also reserved. Enterprise-specific 581 Information Element identifiers can be chosen by an enterprise 582 arbitrarily within the range of 1-32767. The same identifier may be 583 assigned by other enterprises for different purposes; these 584 Information Elements are distinct because the Information Element 585 identifier is coupled with an enterprise identifier. 587 Enterprise identifiers MUST be registered as SMI network management 588 private enterprise code numbers with IANA. The registry can be found 589 at http://www.iana.org/assignments/enterprise-numbers. 591 4.1. NetFlow version 9 compatible Information Element Identifiers 593 The following list gives an overview of the Information Element 594 identifiers that are compatible with field types used by NetFlow 595 version 9 [RFC3954]. 597 +----+----------------------------+-------+-------------------------+ 598 | ID | Name | ID | Name | 599 +----+----------------------------+-------+-------------------------+ 600 | 1 | octetDeltaCount | 43 | RESERVED | 601 | 2 | packetDeltaCount | 44 | sourceIPv4Prefix | 602 | 3 | RESERVED | 45 | destinationIPv4Prefix | 603 | 4 | protocolIdentifier | 46 | mplsTopLabelType | 604 | 5 | ipClassOfService | 47 | mplsTopLabelIPv4Address | 605 | 6 | tcpControlBits | 48-51 | RESERVED | 606 | 7 | sourceTransportPort | 52 | minimumTTL | 607 | 8 | sourceIPv4Address | 53 | maximumTTL | 608 | 9 | sourceIPv4PrefixLength | 54 | fragmentIdentification | 609 | 10 | ingressInterface | 55 | postIpClassOfService | 610 | 11 | destinationTransportPort | 56 | sourceMacAddress | 611 | 12 | destinationIPv4Address | 57 |postDestinationMacAddress| 612 | 13 | destinationIPv4PrefixLength| 58 | vlanId | 613 | 14 | egressInterface | 59 | postVlanId | 614 | 15 | ipNextHopIPv4Address | 60 | ipVersion | 615 | 16 | bgpSourceAsNumber | 61 | flowDirection | 616 | 17 | bgpDestinationAsNumber | 62 | ipNextHopIPv6Address | 617 | 18 | bgpNexthopIPv4Address | 63 | bgpNexthopIPv6Address | 618 | 19 | postMCastPacketDeltaCount | 64 | ipv6ExtensionHeaders | 619 | 20 | postMCastOctetDeltaCount | 65-69 | RESERVED | 620 | 21 | flowEndSysUpTime | 70 | mplsTopLabelStackSection| 621 | 22 | flowStartSysUpTime | 71 | mplsLabelStackSection2 | 622 | 23 | postOctetDeltaCount | 72 | mplsLabelStackSection3 | 623 | 24 | postPacketDeltaCount | 73 | mplsLabelStackSection4 | 624 | 25 | minimumIpTotalLength | 74 | mplsLabelStackSection5 | 625 | 26 | maximumIpTotalLength | 75 | mplsLabelStackSection6 | 626 | 27 | sourceIPv6Address | 76 | mplsLabelStackSection7 | 627 | 28 | destinationIPv6Address | 77 | mplsLabelStackSection8 | 628 | 29 | sourceIPv6PrefixLength | 78 | mplsLabelStackSection9 | 629 | 30 | destinationIPv6PrefixLength| 79 | mplsLabelStackSection10 | 630 | 31 | flowLabelIPv6 | 80 | destinationMacAddress | 631 | 32 | icmpTypeCodeIPv4 | 81 | postSourceMacAddress | 632 | 33 | igmpType | 82-84 | RESERVED | 633 | 34 | RESERVED | 85 | octetTotalCount | 634 | 35 | RESERVED | 86 | packetTotalCount | 635 | 36 | flowActiveTimeout | 87 | RESERVED | 636 | 37 | flowIdleTimeout | 88 | fragmentOffset | 637 | 38 | RESERVED | 89 | RESERVED | 638 | 39 | RESERVED | 90 |mplsVpnRouteDistinguisher| 639 | 40 | exportedOctetTotalCount |91-127 | RESERVED | 640 | 41 | exportedMessageTotalCount | | | 641 | 42 |exportedFlowRecordTotalCount| | | 642 +----+----------------------------+-------+-------------------------+ 644 5. Information Element Categories 646 This section describes the Information Element category for the IPFIX 647 information model at the time that [RFC5102] was published. Since 648 this category field is not part of the IANA process for assigning new 649 Information Element (even though it has been reused, for example, in 650 [RFC5103]), the newest Information Elements in IANA [IPFIX-IANA] 651 don't have this classification. The elements are grouped into 12 652 groups according to their semantics and their applicability: 654 1. Identifiers 655 2. Metering and Exporting Process Configuration 656 3. Metering and Exporting Process Statistics 657 4. IP Header Fields 658 5. Transport Header Fields 659 6. Sub-IP Header Fields 660 7. Derived Packet Properties 661 8. Min/Max Flow Properties 662 9. Flow Timestamps 663 10. Per-Flow Counters 664 11. Miscellaneous Flow Properties 665 12. Padding 667 The Information Elements that are derived from fields of packets or 668 from packet treatment, such as the Information Elements in groups 669 4-7, can typically serve as Flow Keys used for mapping packets to 670 Flows. 672 If they do not serve as Flow Keys, their value may change from packet 673 to packet within a single Flow. For Information Elements with values 674 that are derived from fields of packets or from packet treatment and 675 for which the value may change from packet to packet within a single 676 Flow, the IPFIX information model defines that their value is 677 determined by the first packet observed for the corresponding Flow, 678 unless the description of the Information Element explicitly 679 specifies a different semantics. This simple rule allows writing all 680 Information Elements related to header fields once when the first 681 packet of the Flow is observed. For further observed packets of the 682 same Flow, only Flow properties that depend on more than one packet, 683 such as the Information Elements in groups 8-11, need to be updated. 685 Information Elements with a name having the "post" prefix, for 686 example, "postIpClassOfService", do not report properties that were 687 actually observed at the Observation Point, but retrieved by other 688 means within the Observation Domain. These Information Elements can 689 be used if there are middlebox functions within the Observation 690 Domain changing Flow properties after packets passed the Observation 691 Point. 693 5.1. Identifiers 695 Information Elements grouped in the table below are identifying 696 components of the IPFIX architecture, of an IPFIX Device, or of the 697 IPFIX protocol. All of them have an integral abstract data type and 698 data type semantics "identifier" as described in Section 3.2.4. 700 Typically, some of them are used for limiting scopes of other 701 Information Elements. However, other Information Elements MAY be 702 used for limiting scopes. Note also that all Information Elements 703 listed below MAY be used for other purposes than limiting scopes. 705 +-----+---------------------------+-----+---------------------------+ 706 | ID | Name | ID | Name | 707 +-----+---------------------------+-----+---------------------------+ 708 | 141 | lineCardId | 148 | flowId | 709 | 142 | portId | 145 | templateId | 710 | 10 | ingressInterface | 149 | observationDomainId | 711 | 14 | egressInterface | 138 | observationPointId | 712 | 143 | meteringProcessId | 137 | commonPropertiesId | 713 | 144 | exportingProcessId | | | 714 +-----+---------------------------+-----+---------------------------+ 716 See [IPFIX-IANA] for the definitions of these Information Elements. 718 5.2. Metering and Exporting Process Configuration 720 Information Elements in this section describe the configuration of 721 the Metering Process or the Exporting Process. The set of these 722 Information Elements is listed in the table below. 724 +-----+--------------------------+-----+----------------------------+ 725 | ID | Name | ID | Name | 726 +-----+--------------------------+-----+----------------------------+ 727 | 130 | exporterIPv4Address | 213 | exportInterface | 728 | 131 | exporterIPv6Address | 214 | exportProtocolVersion | 729 | 217 | exporterTransportPort | 215 | exportTransportProtocol | 730 | 211 | collectorIPv4Address | 216 | collectorTransportPort | 731 | 212 | collectorIPv6Address | 173 | flowKeyIndicator | 732 +-----+--------------------------+-----+----------------------------+ 734 See [IPFIX-IANA] for the definitions of these Information Elements. 736 5.3. Metering and Exporting Process Statistics 738 Information Elements in this section describe statistics of the 739 Metering Process and/or the Exporting Process. The set of these 740 Information Elements is listed in the table below. 742 +-----+-----------------------------+-----+-------------------------+ 743 | ID | Name | ID | Name | 744 +-----+-----------------------------+-----+-------------------------+ 745 | 41 | exportedMessageTotalCount | 165 | ignoredOctetTotalCount | 746 | 40 | exportedOctetTotalCount | 166 | notSentFlowTotalCount | 747 | 42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount | 748 | 163 | observedFlowTotalCount | 168 | notSentOctetTotalCount | 749 | 164 | ignoredPacketTotalCount | | | 750 +-----+-----------------------------+-----+-------------------------+ 752 See [IPFIX-IANA] for the definitions of these Information Elements. 754 5.4. IP Header Fields 756 Information Elements in this section indicate values of IP header 757 fields or are derived from IP header field values in combination with 758 further information. 760 +-----+----------------------------+-----+--------------------------+ 761 | ID | Name | ID | Name | 762 +-----+----------------------------+-----+--------------------------+ 763 | 60 | ipVersion | 193 | nextHeaderIPv6 | 764 | 8 | sourceIPv4Address | 195 | ipDiffServCodePoint | 765 | 27 | sourceIPv6Address | 196 | ipPrecedence | 766 | 9 | sourceIPv4PrefixLength | 5 | ipClassOfService | 767 | 29 | sourceIPv6PrefixLength | 55 | postIpClassOfService | 768 | 44 | sourceIPv4Prefix | 31 | flowLabelIPv6 | 769 | 170 | sourceIPv6Prefix | 206 | isMulticast | 770 | 12 | destinationIPv4Address | 54 | fragmentIdentification | 771 | 28 | destinationIPv6Address | 88 | fragmentOffset | 772 | 13 | destinationIPv4PrefixLength| 197 | fragmentFlags | 773 | 30 | destinationIPv6PrefixLength| 189 | ipHeaderLength | 774 | 45 | destinationIPv4Prefix | 207 | ipv4IHL | 775 | 169 | destinationIPv6Prefix | 190 | totalLengthIPv4 | 776 | 192 | ipTTL | 224 | ipTotalLength | 777 | 4 | protocolIdentifier | 191 | payloadLengthIPv6 | 778 +-----+----------------------------+-----+--------------------------+ 780 See [IPFIX-IANA] for the definitions of these Information Elements. 782 5.5. Transport Header Fields 784 The set of Information Elements related to transport header fields 785 and length includes the Information Elements listed in the table 786 below. 788 +-----+---------------------------+-----+---------------------------+ 789 | ID | Name | ID | Name | 790 +-----+---------------------------+-----+---------------------------+ 791 | 7 | sourceTransportPort | 238 | tcpWindowScale | 792 | 11 | destinationTransportPort | 187 | tcpUrgentPointer | 793 | 180 | udpSourcePort | 188 | tcpHeaderLength | 794 | 181 | udpDestinationPort | 32 | icmpTypeCodeIPv4 | 795 | 205 | udpMessageLength | 176 | icmpTypeIPv4 | 796 | 182 | tcpSourcePort | 177 | icmpCodeIPv4 | 797 | 183 | tcpDestinationPort | 139 | icmpTypeCodeIPv6 | 798 | 184 | tcpSequenceNumber | 178 | icmpTypeIPv6 | 799 | 185 | tcpAcknowledgementNumber | 179 | icmpCodeIPv6 | 800 | 186 | tcpWindowSize | 33 | igmpType | 801 +-----+---------------------------+-----+---------------------------+ 803 See [IPFIX-IANA] for the definitions of these Information Elements. 805 5.6. Sub-IP Header Fields 807 The set of Information Elements related to Sub-IP header fields 808 includes the Information Elements listed in the table below. 810 +-----+---------------------------+-----+---------------------------+ 811 | ID | Name | ID | Name | 812 +-----+---------------------------+-----+---------------------------+ 813 | 56 | sourceMacAddress | 201 | mplsLabelStackLength | 814 | 81 | postSourceMacAddress | 194 | mplsPayloadLength | 815 | 58 | vlanId | 70 | mplsTopLabelStackSection | 816 | 59 | postVlanId | 71 | mplsLabelStackSection2 | 817 | 80 | destinationMacAddress | 72 | mplsLabelStackSection3 | 818 | 57 | postDestinationMacAddress | 73 | mplsLabelStackSection4 | 819 | 146 | wlanChannelId | 74 | mplsLabelStackSection5 | 820 | 147 | wlanSSID | 75 | mplsLabelStackSection6 | 821 | 200 | mplsTopLabelTTL | 76 | mplsLabelStackSection7 | 822 | 203 | mplsTopLabelExp | 77 | mplsLabelStackSection8 | 823 | 237 | postMplsTopLabelExp | 78 | mplsLabelStackSection9 | 824 | 202 | mplsLabelStackDepth | 79 | mplsLabelStackSection10 | 825 +-----+---------------------------+-----+---------------------------+ 827 See [IPFIX-IANA] for the definitions of these Information Elements. 829 5.7. Derived Packet Properties 831 The set of Information Elements derived from packet properties (for 832 example, values of header fields) includes the Information Elements 833 listed in the table below. 835 +-----+---------------------------+-----+---------------------------+ 836 | ID | Name | ID | Name | 837 +-----+---------------------------+-----+---------------------------+ 838 | 204 | ipPayloadLength | 18 | bgpNextHopIPv4Address | 839 | 15 | ipNextHopIPv4Address | 63 | bgpNextHopIPv6Address | 840 | 62 | ipNextHopIPv6Address | 46 | mplsTopLabelType | 841 | 16 | bgpSourceAsNumber | 47 | mplsTopLabelIPv4Address | 842 | 17 | bgpDestinationAsNumber | 140 | mplsTopLabelIPv6Address | 843 | 128 | bgpNextAdjacentAsNumber | 90 | mplsVpnRouteDistinguisher | 844 | 129 | bgpPrevAdjacentAsNumber | | | 845 +-----+---------------------------+-----+---------------------------+ 847 See [IPFIX-IANA] for the definitions of these Information Elements. 849 5.9. Flow Timestamps 851 Information Elements in this section are timestamps of events. 853 Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds, 854 flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds, 855 flowStartNanoseconds, flowEndNanoseconds, and 856 systemInitTimeMilliseconds are absolute and have a well-defined fixed 857 time base, such as, for example, the number of seconds since 0000 UTC 858 Jan 1st 1970. 860 Timestamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds 861 are relative timestamps only valid within the scope of a single 862 IPFIX Message. They contain the negative time offsets relative to 863 the export time specified in the IPFIX Message Header. The maximum 864 time offset that can be encoded by these delta counters is 1 hour, 11 865 minutes, and 34.967295 seconds. 867 Timestamps flowStartSysUpTime and flowEndSysUpTime are relative 868 timestamps indicating the time relative to the last 869 (re-)initialization of the IPFIX Device. For reporting the time 870 of the last (re-)initialization, systemInitTimeMilliseconds can 871 be reported, for example, in Data Records defined by Option 872 Templates. 874 +-----+---------------------------+-----+---------------------------+ 875 | ID | Name | ID | Name | 876 +-----+---------------------------+-----+---------------------------+ 877 | 150 | flowStartSeconds | 156 | flowStartNanoseconds | 878 | 151 | flowEndSeconds | 157 | flowEndNanoseconds | 879 | 152 | flowStartMilliseconds | 158 | flowStartDeltaMicroseconds| 880 | 153 | flowEndMilliseconds | 159 | flowEndDeltaMicroseconds | 881 | 154 | flowStartMicroseconds | 160 | systemInitTimeMilliseconds| 882 | 155 | flowEndMicroseconds | 22 | flowStartSysUpTime | 883 | | | 21 | flowEndSysUpTime | 884 +-----+---------------------------+-----+---------------------------+ 886 See [IPFIX-IANA] for the definitions of these Information Elements. 888 5.10. Per-Flow Counters 890 Information Elements in this section are counters all having integer 891 values. Their values may change for every report they are used in. 892 They cannot serve as part of a Flow Key used for mapping packets to 893 Flows. However, potentially they can be used for selecting exported 894 Flows, for example, by only exporting Flows with more than a 895 threshold number of observed octets. 897 There are running counters and delta counters. Delta counters are 898 reset to zero each time their values are exported. Running counters 899 continue counting independently of the Exporting Process. 901 There are per-Flow counters and counters related to the Metering 902 Process and/or the Exporting Process. Per-Flow counters are Flow 903 properties that potentially change each time a packet belonging to 904 the Flow is observed. The set of per-Flow counters includes the 905 Information Elements listed in the table below. Counters related to 906 the Metering Process and/or the Exporting Process are described in 907 Section 5.3. 909 +-----+---------------------------+-----+---------------------------+ 910 | ID | Name | ID | Name | 911 +-----+---------------------------+-----+---------------------------+ 912 | 1 | octetDeltaCount | 134 | droppedOctetTotalCount | 913 | 23 | postOctetDeltaCount | 135 | droppedPacketTotalCount | 914 | 198 | octetDeltaSumOfSquares | 19 | postMCastPacketDeltaCount | 915 | 85 | octetTotalCount | 20 | postMCastOctetDeltaCount | 916 | 171 | postOctetTotalCount | 174 | postMCastPacketTotalCount | 917 | 199 | octetTotalSumOfSquares | 175 | postMCastOctetTotalCount | 918 | 2 | packetDeltaCount | 218 | tcpSynTotalCount | 919 | 24 | postPacketDeltaCount | 219 | tcpFinTotalCount | 920 | 86 | packetTotalCount | 220 | tcpRstTotalCount | 921 | 172 | postPacketTotalCount | 221 | tcpPshTotalCount | 922 | 132 | droppedOctetDeltaCount | 222 | tcpAckTotalCount | 923 | 133 | droppedPacketDeltaCount | 223 | tcpUrgTotalCount | 924 +-----+---------------------------+-----+---------------------------+ 926 See [IPFIX-IANA] for the definitions of these Information Elements. 928 5.11. Miscellaneous Flow Properties 930 Information Elements in this section describe properties of Flows 931 that are related to Flow start, Flow duration, and Flow termination, 932 but they are not timestamps as the Information Elements in Section 933 5.9 are. 935 +-----+---------------------------+-----+---------------------------+ 936 | ID | Name | ID | Name | 937 +-----+---------------------------+-----+---------------------------+ 938 | 36 | flowActiveTimeout | 161 | flowDurationMilliseconds | 939 | 37 | flowIdleTimeout | 162 | flowDurationMicroseconds | 940 | 136 | flowEndReason | 61 | flowDirection | 941 +-----+---------------------------+-----+---------------------------+ 943 See [IPFIX-IANA] for the definitions of these Information Elements. 945 5.12. Padding 947 This section contains a single Information Element that can be used 948 for padding of Flow Records. 950 IPFIX implementations may wish to align Information Elements within 951 Data Records or to align entire Data Records to 4-octet or 8-octet 952 boundaries. This can be achieved by including one or more 953 paddingOctets Information Elements in a Data Record. 955 +-----+---------------------------+-----+---------------------------+ 956 | ID | Name | ID | Name | 957 +-----+---------------------------+-----+---------------------------+ 958 | 210 | paddingOctets | | | 959 +-----+---------------------------+-----+---------------------------+ 961 See [IPFIX-IANA] for the definitions of these Information Elements. 963 6. Extending the Information Model 965 A key requirement for IPFIX is to allow for extension of the 966 Information Model maintained by IANA. The process for extending the 967 Information Model is defined in [IPFIX-IE-DOCTORS], which also 968 provides guidelines for authors and reviewers of new Information 969 Element definitions. 971 For new Information Elements, the type space defined in Section 3 can 972 be used. If required, new abstract data types can be added to the 973 subregistry defined in [RFC5610]. New abstract data types MUST be 974 defined in IETF Standards Track documents. 976 Enterprises may wish to define Information Elements without 977 registering them with IANA. IPFIX explicitly supports 978 enterprise-specific Information Elements. Enterprise-specific 979 Information Elements are described in Sections 2.1 and 4; guidelines 980 for using them appear in [IPFIX-IE-DOCTORS]. 982 7. IANA Considerations 984 7.1. IPFIX Information Elements 986 This document refers to Information Elements, for which the Internet 987 Assigned Numbers Authority (IANA) has created the IPFIX Information 988 Element Registry [IPFIX-IANA]. The columns of this registry must at 989 minimum be able to store the information defined in the template in 990 Section 2.1., additional columns defined in [IPFIX-IE-DOCTORS]; it may 991 contain other information as necessary for the management of the 992 registry. 994 New assignments for IPFIX Information Elements will be administered by 995 IANA through Expert Review [RFC5226], i.e., review by one of a group of 996 experts designated by an IETF Area Director. Further considerations for 997 this review are specified in [IPFIX-IE-DOCTORS]. 999 [NOTE to IANA: please update the Reference for the IPFIX Information 1000 Element Registry to refer to this document, as well as to [IPFIX-IE- 1001 DOCTORS].] 1003 7.2. MPLS Label Type Identifier 1005 Information Element #46, named mplsTopLabelType, carries MPLS label 1006 types. Values for 5 different types have initially been defined. For 1007 ensuring extensibility of this information, IANA has created a new 1008 subregistry for MPLS label types and filled it with the initial list 1009 from the description Information Element #46, mplsTopLabelType. 1011 New assignments for MPLS label types will be administered by IANA 1012 through Expert Review [RFC5226], i.e., review by one of a group of 1013 experts designated by an IETF Area Director. The group of experts must 1014 double check the label type definitions with already defined label types 1015 for completeness, accuracy, and redundancy. The specification of new 1016 MPLS label types MUST be published using a well-established and 1017 persistent publication medium. 1019 [NOTE to IANA: please update the Reference for the IPFIX MPLS Label Type 1020 subregistry to refer to this document.] 1022 7.3. XML Namespace and Schema 1024 [IPFIX-XML-SCHEMA] defines an XML schema for IPFIX Information Element 1025 definitions. All Information Elements specified in [IPFIX-IANA] are 1026 defined by this schema. This schema may also be used for specifying 1027 further Information Elements in future extensions of the IPFIX 1028 information model in a machine-readable way. 1030 [IPFIX-XML-SCHEMA] uses URNs to describe an XML namespace and an XML 1031 schema for IPFIX Information Elements conforming to a registry mechanism 1032 described in [RFC3688]. Two URI assignments have been made. 1034 1. Registration for the IPFIX information model namespace 1035 * URI: urn:ietf:params:xml:ns:ipfix-info 1036 * Registrant Contact: IETF IPFIX Working Group , 1037 as designated by the IESG . 1038 * XML: None. Namespace URIs do not represent an XML. 1040 2. Registration for the IPFIX information model schema 1041 * URI: urn:ietf:params:xml:schema:ipfix-info 1042 * Registrant Contact: IETF IPFIX Working Group , 1043 as designated by the IESG . 1045 Using a machine-readable syntax for the information model enables the 1046 creation of IPFIX-aware tools that can automatically adapt to 1047 extensions to the information model, by simply reading updated 1048 information model specifications. 1050 The wide availability of XML-aware tools and libraries for client 1051 devices is a primary consideration for this choice. In particular, 1052 libraries for parsing XML documents are readily available. Also, 1053 mechanisms such as the Extensible Stylesheet Language (XSL) allow for 1054 transforming a source XML document into other documents. This 1055 document was authored in XML and transformed according to [RFC2629]. 1057 It should be noted that the use of XML in Exporters, Collectors, or 1058 other tools is not mandatory for the deployment of IPFIX. In 1059 particular, Exporting Processes do not produce or consume XML as part 1060 of their operation. It is expected that IPFIX Collectors MAY take 1061 advantage of the machine readability of the information model vs. 1062 hard coding their behavior or inventing proprietary means for 1063 accommodating extensions. 1065 8. Security Considerations 1067 The IPFIX information model itself does not directly introduce security 1068 issues. Rather, it defines a set of attributes that may for privacy or 1069 business issues be considered sensitive information. 1071 For example, exporting values of header fields may make attacks possible 1072 for the receiver of this information, which would otherwise only be 1073 possible for direct observers of the reported Flows along the data path. 1075 The underlying protocol used to exchange the information described here 1076 must therefore apply appropriate procedures to guarantee the integrity 1077 and confidentiality of the exported information. Such protocols are 1078 defined in separate documents, specifically the IPFIX protocol document 1079 [RFC5101bis]. 1081 This document does not specify any Information Element carrying keying 1082 material. If future extensions will do so, then appropriate precautions 1083 need to be taken for properly protecting such sensitive information. 1085 9. Acknowledgements 1087 The editors would like to thanks the authors of the RFC5102 [RFC5102], 1088 as this document is directly based upon this original RFC: Juergen 1089 Quittek, Stewart Bryant, Paul Aitken, and Jeff Meyer. 1091 10. References 1093 10.1. Normative References 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, March 1997. 1098 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and W. 1099 Kasch, "Network Time Protocol Version 4: Protocol and 1100 Algorithms Specification", RFC 5905, June 2010 1102 [RFC5101bis] 1103 Claise, B., and B. Trammell, Editors, "Specification of 1104 the IP Flow Information eXport (IPFIX) Protocol for the 1105 Exchange of IP Traffic Flow Information", draft-ietf- 1106 ipfix-protocol-rfc5101bis-00, Work in Progress, November 1107 2011. 1109 [IPFIX-IE-DOCTORS] 1110 Trammell, B., and B. Claise, "Guidelines for Authors and 1111 Reviewers of IPFIX Information Elements", draft-ietf- 1112 ipfix-ie-doctors-00, Work in Progress, November 2011. 1114 10.2. Informative References 1116 [IEEE.754.1985] 1117 Institute of Electrical and Electronics Engineers, 1118 "Standard for Binary Floating-Point Arithmetic", IEEE 1119 Standard 754, August 1985. 1121 [ISO.10646-1.1993] 1122 International Organization for Standardization, 1123 "Information Technology - Universal Multiple-octet coded 1124 Character Set (UCS) - Part 1: Architecture and Basic 1125 Multilingual Plane", ISO Standard 10646-1, May 1993. 1127 [ISO.646.1991] 1128 International Organization for Standardization, 1129 "Information technology - ISO 7-bit coded character set 1130 for information interchange", ISO Standard 646, 1991. 1132 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 1133 Technology - Portable Operating System Interface, IEEE, 1134 2008. 1136 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1137 "Structure of Management Information Version 2 (SMIv2)", 1138 STD 58, RFC 2578, April 1999. 1140 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1141 June 1999. 1143 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1144 Issues", RFC 3234, February 2002. 1146 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1147 Information Models and Data Models", RFC 3444, January 1148 2003. 1150 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1151 January 2004. 1153 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1154 "Requirements for IP Flow Information Export (IPFIX)", RFC 1155 3917, October 2004. 1157 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 1158 Version 9", RFC 3954, October 2004. 1160 [RFC5102] Trammell, B., and E. Boschi, "Bidirectional Flow Export 1161 Using IP Flow Information Export (IPFIX)", RFC 5103, 1162 January 2008. 1164 [RFC5103] Quittek, J., Bryant, S. Claise, B., Aitken, P., and J. 1165 Meyer, "Information Model for IP Flow Information Export", 1166 RFC 5102, January 2008. 1168 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow 1169 Information Export (IPFIX) Implementation Guidelines", 1170 RFC5153, April 2008. 1172 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1173 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1174 May 2008. 1176 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1177 "Architecture for IP Flow Information Export", RFC5470, 1178 March 2009. 1180 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP 1181 Flow Information Export (IPFIX) Testing", RFC5471, March 1182 2009. 1184 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 1185 Flow Information Export (IPFIX) Applicability", RFC5472, 1186 March 2009. 1188 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy 1189 in IP Flow Information Export (IPFIX) and Packet Sampling 1190 (PSAMP) Reports", RFC5473, March 2009. 1192 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 1193 "Exporting Type Information for IP Flow Information Export 1194 (IPFIX) Information Elements", July 2009. 1196 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 1197 "Export of Structured Data in IP Flow Information Export 1198 (IPFIX)", RFC6313, July 2011. 1200 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP 1201 Flow Information Export (IPFIX) Mediation: Framework", 1202 RFC6183, April 2011. 1204 [IPFIX-CONF] 1205 Muenz, G., Claise, B., and P. Aitken, "Configuration Data 1206 Model for IPFIX and PSAMP", draft-ietf-ipfix- 1207 configuration-model-10, Work in Progress, July 2011. 1209 [IPFIX-MED-PROTO] 1210 Claise, B., Kobayashi, A., and B. Trammell, "Specification 1211 of the Protocol for IPFIX Mediations", draft-ietf-ipfix- 1212 mediation-protocol-00, Work in Progress, December 2011. 1214 [RFC5815bis] 1215 Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 1216 "Definitions of Managed Objects for IP Flow Information 1217 Export", draft-ietf-ipfix-rfc5815bis-01.txt, Work in 1218 Progress, January 2012. 1220 [IPFIX-IANA] 1221 http://www.iana.org/assignments/ipfix/ipfix.xml 1223 [IPFIX-XML-SCHEMA] 1224 http://www.iana.org/assignments/xml- 1225 registry/schema/ipfix.xsd 1227 Authors' Addresses 1229 Benoit Claise 1230 Cisco Systems, Inc. 1231 De Kleetlaan 6a b1 1232 Diegem 1831 1233 Belgium 1235 Phone: +32 2 704 5622 1236 EMail: bclaise@cisco.com 1238 Brian Trammell 1239 Swiss Federal Institute of Technology Zurich 1240 Gloriastrasse 35 1241 8092 Zurich 1242 Switzerland 1244 Phone: +41 44 632 70 13 1245 EMail: trammell@tik.ee.ethz.ch