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