<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3.3) --> <?rfc compact="yes"?> <?rfc comments="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-ipfix-fixes-12" number="9710" category="std" consensus="true" submissionType="IETF" tocDepth="2" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.22.0 -->updates="" obsoletes="" version="3" xml:lang="en"> <front> <title abbrev="IPFIX IANA Fixes">Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry</title> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-ipfix-fixes-12"/>name="RFC" value="9710"/> <author fullname="MohamedBoucadair">Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="BenoitClaise">Claise" initials="B." surname="Claise"> <organization>Huawei</organization> <address> <email>benoit.claise@huawei.com</email> </address> </author> <dateyear="2024" month="July" day="22"/> <area>Operations and Management</area> <workgroup>OPSAWG</workgroup>year="2025" month="January"/> <area>OPS</area> <workgroup>opsawg</workgroup> <keyword>IPFIX</keyword> <keyword>Operations</keyword> <keyword>Network Providers</keyword> <keyword>Network Managment</keyword> <keyword>Anomaly detection</keyword> <keyword>Telemetry</keyword> <abstract><?line 68?><t>This document provides simple fixes to the IANAIP"IP Flow Information Export (IPFIX)EntitiesEntities" registry. Specifically, this document provides updates to fix shortcomings in the description of some Information Elements(IE), updates(IEs), to ensure a consistent structure when citing an existing IANA registry, andupdatesto fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry.</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of this document takes place on</front> <middle> <section anchor="introduction"> <name>Introduction</name> <t>When the Operations and Management Area Working GroupWorking Group mailing list (opsawg@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/opsawg/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/boucadair/simple-ipfix-fixes"/>.</t> </note> </front> <middle> <?line 73?> <section anchor="introduction"> <name>Introduction</name> <t>When OPSAWG(OPSAWG) was considering <xreftarget="RFC9565"/>target="RFC9565"/>, which updates <xref target="RFC7125"/>, the WG realized that some parts of the IANAIP"IP Flow Information Export (IPFIX)EntitiesEntities" registry <xref target="IANA-IPFIX"/> were notup-to-date.up to date. This document updates the IANA registry and brings some consistency among the entries of the registry.</t> <t>As discussed with IANA during thepublication processdevelopment of <xref target="RFC9487"/>, the "Additional Information" entry in <xref target="IANA-IPFIX"/> should contain a link to an existing registry, when applicable, as opposed to having:</t> <ul spacing="normal"> <li> <t>A link to an existing registry in the "Description" entry.</t> </li> <li> <t>The registry detailed values repeated in the "Description" entry. This practice has the drawback that the description must be updated each time the registry is updated.</t> </li> </ul> <t>Therefore, this document lists a set of simple fixes to the IPFIXIANAregistry <xref target="IANA-IPFIX"/>. These fixes are classified as follows:</t> <ul spacing="normal"> <li> <t>Updatesthatto fix a shortcoming in the description of an IE (<xref target="desc"/>).</t> </li> <li> <t>Updatesthat require addingto include a pointer to an existing IANA registry (<xref target="to-iana"/>).</t> </li> <li> <t>Updatesthat are meantto ensure a consistent structure when calling an existing IANA registry (<xref target="consistent"/>).</t> </li> <li> <t>Miscellaneous updatesthatto fix broken pointers, orphaned section references, etc. (<xref target="misc"/>).</t> </li> </ul> <t>These updates are also meant to facilitate the automatic extraction of the values maintained in IANA registries (e.g., with a cron job), required by Collectors to be able to support new IPFIX IEs and, more importantly, adequately interpret new values in registries specified by those IPFIX IEs.</t> <t>Note that, as per <xref section="5" sectionFormat="of" target="RFC7012"/>, <xref target="IANA-IPFIX"/> is the normative reference for the IPFIX IEs that were defined in <xref target="RFC5102"/>. Therefore, the updates in this document do not update any part of <xref target="RFC7011"/>.</t> <t>Likewise, this document is not marked as formally updating <xref target="RFC5477"/>, <xref target="RFC5610"/>, <xref target="RFC5655"/>, <xref target="RFC6235"/>, <xref target="RFC6759"/>, <xref target="RFC7014"/>, <xref target="RFC7015"/>, <xref target="RFC7133"/>, <xref target="RFC7270"/>, <xref target="RFC8038"/>, and <xref target="RFC8158"/>.</t> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>This document uses the IPFIX-specific terminology (Information Element, Template, Collector, Data Record, Flow Record, Exporting Process, Collecting Process, etc.) defined inSection 2 of<xref sectionFormat="of" section="2" target="RFC7011"/>. As in <xref target="RFC7011"/>, these IPFIX-specific terms have the first letter of a word capitalized.</t> </section> <!-- [rfced] FYI, regarding the NEW text that appears throughout this document, we have updated it to include the registry name followed by the URL to the registry group. Based on discussion with IANA, this was the preferred way to refer to these registries in the RFC. Note that the extended URLs remain in the OLD text, as it does not matter if these links cease to work in the future (they are marked OLD). For example: Section 6.2.2 Original: Additional Information: See the Classification Engine IDs registry ([https://www.iana.org/assignments/ipfix/ ipfix.xhtml#classification-engine-ids]). Current: Additional Information: See the "Classification Engine IDs (Value 101)" registry [https://www.iana.org/assignments/ipfix]. --> <section anchor="why-an-rfc-is-needed-for-these-updates"> <name>WhyAnan RFCisIs Needed for TheseUpdates?</name>Updates</name> <t>Many of the edits in this document may be handled by the IPFIX Experts (informally called the IE-DOCTORS <xref target="RFC7013"/>). However, and given that many of the impacted IEs were created via the IETF stream, the following from <xref section="5.1" sectionFormat="of" target="RFC7013"/> is followed:</t><ul empty="true"> <li><blockquote> <t>This process should not in any way be construed as allowing the IE-DOCTORS to overrule IETF consensus. Specifically, Information Elements in the IANA IE registry that were added with IETF consensus require IETF consensus for revision or deprecation.</t></li> </ul></blockquote> </section> <section anchor="desc"> <name>Update theDescription</name>Descriptions in the IANA Registry</name> <section anchor="sourcetransportport"> <name>sourceTransportPort</name> <section anchor="old"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The source port identifier in the transport header. For the transport protocols UDP, TCP, and SCTP, this is the source port number given in the respective header. This field <bcp14>MAY</bcp14> also be used for future transport protocols that have 16-bit source port identifiers.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0768"/> for the definition of the UDP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the definition of the TCP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9260"/> for the definition of SCTP.</t></dd> <dt/> <dd><t>Additional information on defined UDP and TCP port numbers can be found at[https://www.iana.org/assignments/service-names-port-numbers].</t>[<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>].</t> </dd> </dl> </section> <section anchor="new"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The source port identifier in the transport protocol header. For transport protocols such as UDP, TCP, SCTP, and DCCP, this is the source port number given in the respective header. This field <bcp14>MAY</bcp14> also be used for future transport protocols that have 16-bit source port identifiers.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0768"/> for the definition of the UDP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the definition of the TCP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9260"/> for the definition of the SCTP source port number field.</t></dd> <dt/> <dd><t>See <xref target="RFC4340"/> for the definition of the DCCP source port field.</t></dd> <dt/> <dd><t>See the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers athttps://www.iana.org/assignments/service-names-port-numbers.</t>[<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>].</t> </dd> </dl> </section> </section> <section anchor="destinationtransportport"> <name>destinationTransportPort</name> <section anchor="old-1"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The destination port identifier in the transport header. For the transport protocols UDP, TCP, and SCTP, this is the destination port number given in the respective header. This field <bcp14>MAY</bcp14> also be used for future transport protocols that have 16-bit destination port identifiers.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0768"/> for the definition of the UDP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the definition of the TCP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9260"/> for the definition of SCTP.</t></dd> <dt/> <dd><t>Additional information on defined UDP and TCP port numbers can be found at[https://www.iana.org/assignments/service-names-port-numbers].</t>https://www.iana.org/assignments/service-names-port-numbers.</t> </dd> </dl> </section> <section anchor="new-1"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The destination port identifier in the transport protocol header. For transport protocols such as UDP, TCP, SCTP, and DCCP, this is the destination port number given in the respective header. This field <bcp14>MAY</bcp14> also be used for future transport protocols that have 16-bit destination port identifiers.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0768"/> for the definition of the UDP destination port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the definition of the TCP destination port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9260"/> for the definition of the SCTP destination port number field.</t></dd> <dt/> <dd><t>See <xref target="RFC4340"/> for the definition of the DCCP destination port field.</t></dd> <dt/> <dd><t>See the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers athttps://www.iana.org/assignments/service-names-port-numbers.</t>[<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>].</t> </dd> </dl> </section> </section> <section anchor="forwardingstatus"> <name>forwardingStatus</name> <t>The current forwardingStatus entry in <xref target="IANA-IPFIX"/> deviates from what is provided in <xref target="RFC7270"/>. In particular, the registered Abstract Data Type is unsigned8, while it must be unsigned32. The following update fixes that issue. The description is also updated to clarify the use of the reduced-size encoding as per <xref section="6.2" sectionFormat="of" target="RFC7011"/>.</t> <section anchor="old-2"> <name>OLD</name><artwork><![CDATA[ - Description: This<dl> <dt>Description:</dt> <dd><t>This Information Element describes the forwarding status of the flow and any attachedreasons.reasons.</t> <t> The layout of the encoding is asfollows:follows:</t> <artwork><![CDATA[ MSB - 0 1 2 3 4 5 6 7 - LSB +---+---+---+---+---+---+---+---+ | Status| Reason code or flags | +---+---+---+---+---+---+---+---+ See the Forwarding Status sub-registries at [Forwarding-Status]. Examples: value : 0x40 = 64 binary: 01000000 decode: 01 -> Forward 000000 -> No further information value : 0x89 = 137 binary: 10001001 decode: 10 -> Drop 001001 -> Bad TTL-]]></artwork> </dd> <dt> AdditionalInformation: SeeInformation:</dt><dd> <t>See "NetFlow Version 9 Flow-Record Format"[CCO-NF9FMT]. - Abstract<xref target="CCO-NF9FMT"/>.</t></dd> <dt>Abstract DataType: unsigned8 ]]></artwork>Type:</dt><dd> unsigned8</dd> </dl> </section> <section anchor="new-2"> <name>NEW</name><artwork><![CDATA[ - Description:<dl> <dt>Description:</dt><dd> <t> This Information Element describes the forwarding status of the flow and any attached reasons. IPFIX reduced-size encoding is used asrequired. Arequired.</t> <t>A structure is currently associated with the least-significant byte. Future versions may be defined to associate meanings with the remainingbits. Thebits.</t> <t>The current version of the Information Element should be exported asunsigned8. Theunsigned8.</t> <t>The layout of the encoding is asfollows:follows:</t> <artwork><![CDATA[ MSB - 0 1 2 3 4 5 6 7 - LSB +---+---+---+---+---+---+---+---+ | Status| Reason code or flags | +---+---+---+---+---+---+---+---+ Examples: value : 0x40 = 64 binary: 01000000 decode: 01 -> Forward 000000 -> No further information value : 0x89 = 137 binary: 10001001 decode: 10 -> Drop 001001 -> Bad TTL- Additional Information:]]></artwork> </dd> <dt>Additional Information:</dt><dd> See "NetFlow Version 9 Flow-Record Format"[CCO-NF9FMT].<xref target="CCO-NF9FMT"/>. See theForwarding"Forwarding Statussub-registries(Value 89)" registry at[Forwarding-Status]. - Abstract[<eref target="https://www.iana.org/assignments/ipfix"/>].</dd> <dt>Abstract DataType: unsigned32 ]]></artwork>Type:</dt><dd> unsigned32</dd> </dl> </section> </section> <section anchor="collectortransportport"> <name>collectorTransportPort</name> <section anchor="old-3"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The destination port identifier to which the Exporting Process sends Flow information. For the transport protocols UDP, TCP, and SCTP, this is the destination port number. This field <bcp14>MAY</bcp14> also be used for future transport protocols that have 16-bit source port identifiers.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0768"/> for the definition of the UDP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the definition of the TCP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9260"/> for the definition of SCTP.</t></dd> <dt/> <dd><t>Additional information on defined UDP and TCP port numbers can be found at [https://www.iana.org/assignments/service-names-port-numbers].</t> </dd> </dl> </section> <section anchor="new-3"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The destination port identifier to which the Exporting Process sends Flow information. For transport protocols such as UDP, TCP, and SCTP, this is the destination port number. This field <bcp14>MAY</bcp14> also be used for future transport protocols that have 16-bit source port identifiers.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0768"/> for the definition of the UDP destination port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the definition of the TCP destination port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9260"/> for the definition of the SCTP destination port number field.</t></dd> <dt/> <dd><t>See the assigned transport protocol (e.g., UDP, TCP, and SCTP) port numbers athttps://www.iana.org/assignments/service-names-port-numbers.</t>[<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>].</t> </dd> </dl> </section> </section> <section anchor="exportertransportport"> <name>exporterTransportPort</name> <section anchor="old-4"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The source port identifier from which the Exporting Process sends Flow information. For the transport protocols UDP, TCP, and SCTP, this is the source port number. This field <bcp14>MAY</bcp14> also be used for future transport protocols that have 16-bit source port identifiers. This field may be useful for distinguishing multiple Exporting Processes that use the same IP address.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0768"/> for the definition of the UDP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the definition of the TCP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9260"/> for the definition of SCTP.</t></dd> <dt/> <dd><t>Additional information on defined UDP and TCP port numbers can be found at [https://www.iana.org/assignments/service-names-port-numbers].</t> </dd> </dl> </section> <section anchor="new-4"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The source port identifier from which the Exporting Process sends Flow information. For transport protocols such as UDP, TCP, and SCTP, this is the source port number. This field <bcp14>MAY</bcp14> also be used for future transport protocols that have 16-bit source port identifiers.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0768"/> for the definition of the UDP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the definition of the TCP source port field.</t></dd> <dt/> <dd><t>See <xref target="RFC9260"/> for the definition of the SCTP source port number field.</t></dd> <dt/> <dd><t>See the assigned transport protocol (e.g., UDP, TCP, and SCTP) port numbers athttps://www.iana.org/assignments/service-names-port-numbers.</t>[<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>].</t> </dd> </dl> </section> </section> </section> <section anchor="to-iana"> <name>Point toAnan Existing IANA Registry</name><t>This document requests IANA to update<t>IANA has updated the following entries by adding the indicated "Additional Information" to the <xref target="IANA-IPFIX"/>registry:</t> <table>registry. (In <xref target="table_addl_info"/>, "EltID" is short for "ElementID".)</t> <!--[rfced] FYI, similarly Table 1 has been updated to use the registry name and the URL without the URI fragment, per IANA's preference for RFCs. For example: "Additional Information" for 33 igmpType. Original I-D: https://www.iana.org/assignments/ igmp-type-numbers/igmp-type- numbers.xhtml#igmp-type-numbers-1 Current document: See "IGMP Type Numbers" at [https://www.iana.org/assignments/ igmp-type-numbers] Current IANA registry (we will send a request to update to the registry name): See the assigned IGMP type numbers at [https://www.iana.org/assignments/igmp-type-numbers/ igmp-type-numbers.xhtml#igmp-type-numbers-1] Note: Table 1 currently uses Form A, but if you prefer Form B, please let us know. Form A: See "Name" at [URL] Form B: See the "Name" registry at [URL] --> <table anchor="table_addl_info"> <name>Cite an IANA RegistryunderUnder Additional Information</name> <thead> <tr> <thalign="left">ElementID</th>align="left">EltID</th> <th align="left">Name</th> <th align="left">Additional Information</th> </tr> </thead> <tbody> <tr> <td align="left">32</td> <td align="left">icmpTypeCodeIPv4</td> <tdalign="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml</td>align="left">See "ICMP Type Numbers" at [<eref target="https://www.iana.org/assignments/icmp-parameters"/>] </td> </tr> <tr> <td align="left">33</td> <td align="left">igmpType</td> <tdalign="left">https://www.iana.org/assignments/igmp-type-numbers/igmp-type-numbers.xhtml#igmp-type-numbers-1</td>align="left">See "IGMP Type Numbers" at [<eref target="https://www.iana.org/assignments/igmp-type-numbers"/>]</td> </tr> <tr> <td align="left">139</td> <td align="left">icmpTypeCodeIPv6</td> <tdalign="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml</td>align="left">See "ICMPv6 'type' Numbers" and "ICMPv6 'Code' Fields" at [<eref target="https://www.iana.org/assignments/icmpv6-parameters"/>]</td> </tr> <tr> <td align="left">176</td> <td align="left">icmpTypeIPv4</td> <tdalign="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types</td>align="left">See "ICMP Type Numbers" at [<eref target="https://www.iana.org/assignments/icmp-parameters"/>]</td> </tr> <tr> <td align="left">177</td> <td align="left">icmpCodeIPv4</td> <tdalign="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes</td>align="left">See "ICMP Type Numbers" at [<eref target="https://www.iana.org/assignments/icmp-parameters"/>]</td> </tr> <tr> <td align="left">178</td> <td align="left">icmpTypeIPv6</td> <tdalign="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2</td>align="left">See "ICMPv6 'type' Numbers" at [<eref target="https://www.iana.org/assignments/icmpv6-parameters"/>]</td> </tr> <tr> <td align="left">179</td> <td align="left">icmpCodeIPv6</td> <tdalign="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-3</td>align="left">See "ICMPv6 'Code' Fields" at [<eref target="https://www.iana.org/assignments/icmpv6-parameters"/>]</td> </tr> <tr> <td align="left">346</td> <td align="left">privateEnterpriseNumber</td> <tdalign="left">https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers</td>align="left">See "Private Enterprise Numbers (PENs)" at <eref target="https://www.iana.org/assignments/enterprise-numbers"/>]</td> </tr> </tbody> </table> </section> <section anchor="consistent"> <name>Consistent Citation of IANA Registries</name><t>This document requests IANA to update<t>IANA has updated the "IP Flow Information Export (IPFIX) Entities" registry <xref target="IANA-IPFIX"/> for each of the IE entries listed in the following subsections.</t> <section anchor="mplstoplabeltype"> <name>mplsTopLabelType</name> <section anchor="old-5"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>This field identifies the control protocol that allocated the top-of-stack label. Values for this field are listed in the MPLS label type registry.</t></dd> <dt/> <dd><t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC3031"/> for the MPLS label structure.</t></dd> <dt/> <dd><t>See the list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/mpls-label-values].</t> </dd> </dl> </section> <section anchor="new-5"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This field identifies the control protocol that allocated the top-of-stack label. Values for this field are listed in the MPLS label type registry.</t> </dd> <dt>Additional Information:</dt> <dd> <!-- [rfced] Section 6.1.2: To which registry does "IPFIX MPLS label type registry" refer? We see the following registries at https://www.iana.org/assignments/mpls-label-values: "Base Special-Purpose MPLS Label Values" or "Extended Special-Purpose MPLS Label Values" Original: Additional Information: See the IPFIX MPLS label type registry ([https://www.iana.org/assignments/mpls-label-values]). --> <t>See the IPFIX MPLS label type registry([https://www.iana.org/assignments/mpls-label-values]).</t> </dd> <dt/> <dd>[<eref target="https://www.iana.org/assignments/mpls-label-values"/>].</t> <t>See <xref target="RFC3031"/> for the MPLS label structure.</t> </dd> </dl> </section> </section> <section anchor="classificationengineid"> <name>classificationEngineId</name> <section anchor="old-6"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>A unique identifier for the engine that determined the Selector ID. Thus, the Classification Engine ID defines the context for the Selector ID. The Classification Engine can be considered a specific registry for application assignments.</t></dd> <dt/> <dd><t>Values for this field are listed in the Classification Engine IDs registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids.</t> </dd> </dl> </section> <section anchor="new-6"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>A unique identifier for the engine that determined the Selector ID. Thus, the Classification Engine ID defines the context for the Selector ID. The Classification Engine can be considered a specific registry for application assignments.</t></dd> <dt/> <dd><t>Values for this field are listed in the Classification Engine IDs registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theClassification"Classification Engine IDs (Value 101)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="flowendreason"> <name>flowEndReason</name> <section anchor="old-7"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The reason for Flow termination. Values are listed in the flowEndReason registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason.</t> </dd> </dl> </section> <section anchor="new-7"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The reason for Flow termination. Values are listed in the flowEndReason registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theflowEndReason"flowEndReason (Value 136)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="natoriginatingaddressrealm"> <name>natOriginatingAddressRealm</name> <section anchor="old-8"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>Indicates whether the session was created because traffic originated in the private or public address realm. postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective.</t></dd> <dt/> <dd><t>Values are listed in the natOriginatingAddressRealm registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC3022"/> for the definition of NAT.</t> </dd> </dl> </section> <section anchor="new-8"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>Indicates whether the session was created because traffic originated in the private or public address realm. postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective.</t></dd> <dt/> <dd><!-- [rfced] Because it seems the pointers to the relevant registry were moved from the "Description" to "Additional Information", do you still want to keep the sentence about where the values are listed in the "Description"? It seems redundant in some cases; please review. Examples of sentences that you may want to cut from NEW Descriptions: S 6.2.2 Values for this field are listed in the Classification Engine IDs registry. S 6.3.2 Values are listed in the flowEndReason registry. S 6.4.2 Values are listed in the natOriginatingAddressRealm registry. S 6.5.2 Values for this Information Element are listed in the "NAT Event Type" registry. --> <t>Values are listed in the natOriginatingAddressRealm registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See thenatOriginatingAddressRealm"natOriginatingAddressRealm (Value 229)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm]).</t> </dd> <dt/> <dd>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> <t>See <xref target="RFC3022"/> for the definition of NAT.</t> </dd> </dl> </section> </section> <section anchor="natevent"> <name>natEvent</name> <section anchor="old-9"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies a NAT event. This IE identifies the type of a NAT event. Examples of NAT events include, but are not limited to, NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc. Values for this Information Element are listed in the "NAT Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC3022"/> for the definition of NAT.</t></dd> <dt/> <dd><t>See <xref target="RFC3234"/> for the definition of middleboxes.</t></dd> <dt/> <dd><t>See <xref target="RFC8158"/> for the definitions of values 4-16.</t> </dd> </dl> </section> <section anchor="new-9"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies a NAT event. This IE identifies the type of a NAT event. Examples of NAT events include, but are not limited to, NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc. Values for this Information Element are listed in the "NAT Event Type" registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theNAT"NAT Event Type (Value 230)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type]).</t> </dd> <dt/> <dd>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> <t>See <xref target="RFC3022"/> for the definition of NAT.</t></dd> <dt/> <dd><t>See <xref target="RFC8158"/> for the definitions of values 4-16.</t> </dd> </dl> </section> </section> <section anchor="firewallevent"> <name>firewallEvent</name> <section anchor="old-10"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>Indicates a firewall event. Allowed values are listed in the firewallEvent registry.</t></dd> <dt/> <dd><t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event.</t> </dd> </dl> </section> <section anchor="new-10"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>Indicates a firewall event. Allowed values are listed in the firewallEvent registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See thefirewallEvent"firewallEvent (Value 233)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="biflowdirection"> <name>biflowDirection</name> <section anchor="old-11"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element <bcp14>MAY</bcp14> be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option <bcp14>SHOULD</bcp14> be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element <bcp14>SHOULD</bcp14> appear in each Flow Record. Values are listed in the biflowDirection registry. See [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction].</t> </dd> </dl> </section> <section anchor="new-11"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element <bcp14>MAY</bcp14> be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option <bcp14>SHOULD</bcp14> be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element <bcp14>SHOULD</bcp14> appear in each Flow Record. Values are listed in the biflowDirection registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See thebiflowDirection"biflowDirection (Value 239)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="observationpointtype"> <name>observationPointType</name> <section anchor="old-12"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>Type of observation point. Values are listed in the observationPointType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type.</t> </dd> </dl> </section> <section anchor="new-12"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>Type of observation point. Values are listed in the observationPointType registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theobservationPointType"observationPointType (Value 277)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="anonymizationtechnique"> <name>anonymizationTechnique</name> <section anchor="old-13"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>A description of the anonymization technique applied to a referenced Information Element within a referenced Template. Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements. Values are listed in the anonymizationTechnique registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique.</t> </dd> </dl> </section> <section anchor="new-13"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>A description of the anonymization technique applied to a referenced Information Element within a referenced Template. Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements. Values are listed in the anonymizationTechnique registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theanonymizationTechnique"anonymizationTechnique (Value 286)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique]).</t>[<eref target="https://www.iana.org/assignments/ipfix/"/>].</t> </dd> </dl> </section> </section> <section anchor="nattype"> <name>natType</name> <section anchor="old-14"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>Values are listed in the natType registry.</t></dd> <dt/> <dd><t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC3022"/> for the definition of NAT.</t></dd> <dt/> <dd><t>See <xref target="RFC1631"/> for the definition of NAT44.</t></dd> <dt/> <dd><t>See <xref target="RFC6144"/> for the definition of NAT64.</t></dd> <dt/> <dd><t>See <xref target="RFC6146"/> for the definition of NAT46.</t></dd> <dt/> <dd><t>See <xref target="RFC6296"/> for the definition of NAT66.</t></dd> <dt/> <dd><t>See <xref target="RFC0791"/> for the definition of IPv4.</t></dd> <dt/> <dd><t>See <xref target="RFC8200"/> for the definition of IPv6.</t> </dd> </dl> </section> <section anchor="new-14"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies the NAT type applied to packets of the Flow.</t></dd> <dt/> <dd><t>Values are listed in the natType registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See thenatType"natType (Value 297)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type]).</t> </dd> <dt/> <dd>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> <t>See <xref target="RFC3022"/> for the definition of NAT (commonly named NAT44).</t></dd> <dt/> <dd><t>See <xref target="RFC6144"/> for the definition of NAT46.</t></dd> <dt/> <dd><t>See <xref target="RFC6146"/> for the definition of NAT64.</t></dd> <dt/> <dd><t>See <xref target="RFC6296"/> for the definition of NPTv6.</t></dd> <dt/> <dd><t>See <xref target="RFC0791"/> for the definition of IPv4.</t></dd> <dt/> <dd><t>See <xref target="RFC8200"/> for the definition of IPv6.</t> </dd> </dl><ul empty="true"> <li><!-- [rfced] The following text was included as a note for IANA. We have removed the text. Please let us know if this is incorrect. <t>Note to IANA: This change also corrects errors in the pointers provided for NAT46/NAT64.</t></li> </ul>--> </section> </section> <section anchor="selectoralgorithm"> <name>selectorAlgorithm</name> <section anchor="old-15"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies the packet selection methods (e.g., Filtering, Sampling) that are applied by the Selection Process. Most of these methods have parameters. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. The methods listed below are defined in <xref target="RFC5475"/>. For their parameters, Information Elements are defined in the information model document. The names of these Information Elements are listed for each method identifier. Further method identifiers may be added to the list below. It might be necessary to define new Information Elements to specify their parameters.</t></dd> <dt/> <dd><t>The following packet selection methods identifiers are defined here: https://www.iana.org/assignments/psamp-parameters.</t></dd> <dt/> <dd><t>There is a broad variety of possible parameters that could be used for Property match Filtering (5) but currently there are no agreed parameters specified.</t> </dd> </dl> </section> <section anchor="new-15"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies the packet selection methods (e.g., Filtering, Sampling) that are applied by the Selection Process. Most of these methods have parameters. Further Information Elements are needed to fully specify packet selection with these methods and all of their parameters. For the methods parameters, Information Elements are defined in the IPFIXIANAregistry <xref target="IANA-IPFIX"/>. The names of these Information Elements are listed for each method identifier. Further method identifiers may be added to the list. It might be necessary to define new Information Elements to specify their parameters.</t></dd> <dt/> <dd><t>There is a broad variety of possible parameters that could be used for PropertymatchMatch Filtering (5) but currently there are no agreed parameters specified.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See thePacket"Packet Sampling (PSAMP)ParametersParameters" registry([https://www.iana.org/assignments/psamp-parameters]).</t>[<eref target="https://www.iana.org/assignments/psamp-parameters"/>].</t> </dd> </dl> </section> </section> <section anchor="informationelementdatatype"> <name>informationElementDataType</name> <section anchor="old-16"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>A description of the abstract data type of an IPFIX information element. These are taken from the abstract data types defined in section3.1<xref target="RFC5102" sectionFormat="bare" section="3.1"/> of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the [informationElementDataType]subregistry.registry. These types are registered in the IANA IPFIX Information Element Data Type subregistry. This subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</t> </dd> </dl> </section> <section anchor="new-16"> <name>NEW</name> <dl> <dt>Description:</dt> <dd><t>A<!-- [rfced] Section 6.12.2: We are unable to find an informationElementDataType registry on iana.org. From discussion with IANA, it seems "[informationElementDataType] subregistry" was renamed "IPFIX Information Element Data Types" at some point. Assuming this is true, please consider the following updates. Original: 6.12.2. NEW Description: A description of the abstract data type of an IPFIX information element.These are taken from the abstract data types defined in Section 3.1 of the IPFIX Information Model<xref target="RFC5102"/>;[RFC5102]; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the IANA IPFIX Information Element Data Typesubregistry.</t> </dd> <dt/> <dd> <t>Thesubregistry. The [informationElementDataType] subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action [RFC8126] to modify. Additional Information: See the IPFIX Information Element Data Types registry ([https://www.iana.org/assignments/ipfix/ ipfix.xhtml#ipfix-information-element-data-types]). Perhaps: 6.12.2. NEW Description: A description of the abstract data type of an IPFIX information element.These are taken from the abstract data types defined in Section 3.1 of the IPFIX Information Model [RFC5102]; see that section for more information on the types described in the "IPFIX Information Element Data Types" registry (previously the "informationElementDataType" subregistry). These types are registered in the "IPFIX Information Element Data Types" registry. The "IPFIX Information Element Data Types" registry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol; as such, modifications require Standards Action [RFC8126]. Additional Information: See the "IPFIX Information Element Data Types" registry [https://www.iana.org/assignments/ipfix/]. --> <t>A description of the abstract data type of an IPFIX information element. These are taken from the abstract data types defined in Section <xreftarget="RFC8126"/>target="RFC5102" sectionFormat="bare" section="3.1"/> of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the "IPFIX Information Element Data Types" subregistry.</t> <t>The [informationElementDataType] subregistry is intended tomodify.</t>assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol; as such, modifications require Standards Action <xref target="RFC8126"/>.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theIPFIX"IPFIX Information Element DataTypesTypes" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="informationelementsemantics"> <name>informationElementSemantics</name> <section anchor="old-17"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in section3.2<xref target="RFC5102" section="3.2" sectionFormat="bare"/> of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types defined in the [IPFIX Information Element Semantics] subregistry. This field may take the values in the semantics registry; the special value 0x00 (default) is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori. These semantics are registered in the IANA IPFIX Information Element Semantics subregistry. This subregistry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</t> </dd> </dl> </section> <section anchor="new-17"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in Section3.2<xref target="RFC5102" section="3.2" sectionFormat="bare"/> of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types defined in the[IPFIX"IPFIX Information ElementSemantics] subregistry.Semantics" registry. This field may take the values in the[IPFIX"IPFIX Information ElementSemantics] subregistry.Semantics" registry. The special value 0x00 (default) is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori.</t></dd> <dt/> <dd><t>The[IPFIX"IPFIX Information ElementSemantics] subregistrySemantics" registry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIXProtocol, andProtocol; assuch requires asuch, modifications require Standards Action <xreftarget="RFC8126"/> to modify.</t>target="RFC8126"/>.</t> </dd><dt>Additional Information:</dt> <dd> <t>See<!-- [rfced] Section 6.13.2: We updated the registry title to refer to the "IPFIX Information Element Semantics" registry, instead of the name of the registry group ("IP Flow Information Export (IPFIX) Entities" registry group). Please confirm this is correct. Original: Additional Information: See the IP Flow Information Export (IPFIX) Entities registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-semantic]).</t>([https://www.iana.org/assignments/ipfix/ ipfix.xhtml#ipfix-information-element-semantic]). Current: Additional Information: See the "IPFIX Information Element Semantics" registry [https://www.iana.org/assignments/ipfix]. --> <dt>Additional Information:</dt> <dd> <t>See the "IPFIX Information Element Semantics" registry [<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="informationelementunits"> <name>informationElementUnits</name> <section anchor="old-18"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in section5<xref target="RFC5102" section="5" sectionFormat="bare"/> of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the informationElementsUnits subregistry. This field may take the values in Table 3 below; the special value 0x00 (none) is used to note that the field is unitless. These types are registered in the [IANA IPFIX Information Element Units] subregistry.</t> </dd> </dl> </section> <section anchor="new-18"> <name>NEW</name> <dl> <dt>Description:</dt> <dd><t>A<!-- [rfced] Section 6.14.1: We are unable to find an informationElementsUnits registry on iana.org. We believe the informationElementsUnits subregistry was renamed as "IPFIX Information Element Units" registry at some point. Please confirm this is correct. Assuming this is true, please consider the following updates. Original: 6.14.2. NEW Description: A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in Section 5 of the IPFIX Information Model [RFC5102]; see that section for more information on the types described in the informationElementsUnits subregistry. These types can take the values in the [IANA IPFIX Information Element Units] subregistry. The special value 0x00 (none) is used to note that the field is unitless. Additional Information: See the IPFIX Information Element Units registry ([IANA IPFIX Information Element Units]). Perhaps: 6.14.2. NEW Description: A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in Section 5 of the IPFIX Information Model [RFC5102]; see that section for more information on the types described in the "IPFIX Information Element Units" registry (previously the informationElementsUnits subregistry). These types can take the values in the "IPFIX Information Element Units" registry. The special value 0x00 (none) is used to note that the field is unitless. Additional Information: See the "IPFIX Information Element Units" registry [https://www.iana.org/assignments/ipfix]. --> <t>A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in Section <xref target="RFC5102" section="5" sectionFormat="bare"/> of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the informationElementsUnits subregistry. These types can take the values in the [IANA IPFIX Information Element Units] subregistry. The special value 0x00 (none) is used to note that the field is unitless.</t> <!-- [rfced] Section 6.14.2 (NEW for informationElementUnits): FYI, if you accept the suggested text in the previous question, we will ask IANA to remove the following sentence from the registry; it is not part of the proposed new text. Original: These types can take the values in the [IANA IPFIX Information Element Units] subregistry. --> </dd> <dt>Additional Information:</dt> <dd> <t>See theIPFIX"IPFIX Information ElementUnitsUnits" registry([IANA IPFIX Information Element Units]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="portrangestart"> <name>portRangeStart</name> <section anchor="old-19"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The port number identifying the start of a range of ports. A value of zero indicates that the range start is not specified, ie the range is defined in some other way.</t></dd> <dt/> <dd><t>Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</t> </dd> </dl> </section> <section anchor="new-19"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The port number identifying the start of a range of port numbers. A value of zero indicates that the range start is not specified, i.e., the range is defined in some other way.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers athttps://www.iana.org/assignments/service-names-port-numbers.</t>[<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>].</t> </dd> </dl> </section> </section> <section anchor="portrangeend"> <name>portRangeEnd</name> <section anchor="old-20"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The port number identifying the end of a range of ports. A value of zero indicates that the range end is not specified, ie the range is defined in some other way. Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</t> </dd> </dl> </section> <section anchor="new-20"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The port number identifying the end of a range of port numbers. A value of zero indicates that the range end is not specified, i.e., the range is defined in some other way.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers athttps://www.iana.org/assignments/service-names-port-numbers.</t>[<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>].</t> </dd> </dl> </section> </section> <section anchor="ingressinterfacetype"> <name>ingressInterfaceType</name> <section anchor="old-21"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The type of interface where packets of this Flow are being received. The value matches the value of managed object 'ifType' as defined in https://www.iana.org/assignments/ianaiftype-mib.</t> </dd> <dt>Additional Information:</dt> <dd> <t>https://www.iana.org/assignments/ianaiftype-mib</t> </dd> </dl> </section> <section anchor="new-21"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The type of interface where packets of this Flow are being received. The value matches the value of managed object 'ifType'.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theIANAifType-MIB"IANAifType-MIB" registry([https://www.iana.org/assignments/ianaiftype-mib]).</t>[<eref target="https://www.iana.org/assignments/ianaiftype-mib"/>].</t> </dd> </dl> </section> </section> <section anchor="egressinterfacetype"> <name>egressInterfaceType</name> <section anchor="old-22"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The type of interface where packets of this Flow are being sent. The value matches the value of managed object 'ifType' as defined in https://www.iana.org/assignments/ianaiftype-mib.</t> </dd> <dt>Additional Information:</dt> <dd> <t>https://www.iana.org/assignments/ianaiftype-mib</t> </dd> </dl> </section> <section anchor="new-22"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The type of interface where packets of this Flow are being sent. The value matches the value of managed object 'ifType'.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theIANAifType-MIB"IANAifType-MIB" registry([https://www.iana.org/assignments/ianaiftype-mib]).</t>[<eref target="https://www.iana.org/assignments/ianaiftype-mib"/>].</t> </dd> </dl> </section> </section> <section anchor="valuedistributionmethod"> <name>valueDistributionMethod</name> <section anchor="old-23"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>A description of the method used to distribute the counters from Contributing Flows into the Aggregated Flow records described by an associated scope, generally a Template. The method is deemed to apply to all the non-key Information Elements in the referenced scope for which value distribution is a valid operation; if the originalFlowsInitiated and/or originalFlowsCompleted Information Elements appear in the Template, they are not subject to this distribution method, as they each infer their own distribution method. The valueDistributionMethod registry is intended to list a complete set of possible value distribution methods.</t></dd> <dt/> <dd><t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method.</t> </dd> </dl> </section> <section anchor="new-23"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>A description of the method used to distribute the counters from Contributing Flows into the Aggregated Flow records described by an associated scope, generally a Template. The method is deemed to apply to all the non-key Information Elements in the referenced scope for which value distribution is a valid operation; if the originalFlowsInitiated and/or originalFlowsCompleted Information Elements appear in the Template, they are not subject to this distribution method, as they each infer their own distribution method. ThevalueDistributionMethod"valueDistributionMethod (Value 384)" registry is intended to list a complete set of possible value distribution methods.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See thevalueDistributionMethod"valueDistributionMethod (Value 384)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="flowselectoralgorithm"> <name>flowSelectorAlgorithm</name> <section anchor="old-24"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process. Most of these techniques have parameters. Its configuration parameter(s) <bcp14>MUST</bcp14> be clearly specified. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. Further method identifiers may be added to the flowSelectorAlgorithm registry. It might be necessary to define new Information Elements to specify their parameters.</t></dd> <dt/> <dd><t>Please note that the purpose of the flow selection techniques described in this document is the improvement of measurement functions as defined in the Scope (Section 1).</t></dd> <dt/> <dd><t>The Intermediate Flow Selection Process Techniques identifiers are defined at https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm.</t> </dd> </dl> </section> <section anchor="new-24"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process. Most of these techniques have parameters. Its configuration parameter(s) <bcp14>MUST</bcp14> be clearly specified.FurtherAdditional Information Elements are needed to fully specify packet selection with these methods and all of their parameters.FurtherAdditional method identifiers may be added to theflowSelectorAlgorithm"flowSelectorAlgorithm (Value 390)" registry. It might be necessary to define new Information Elements to specify their parameters.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theflowSelectorAlgorithm"flowSelectorAlgorithm (Value 390)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm]).</t>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="datalinkframetype"> <name>dataLinkFrameType</name> <section anchor="old-25"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element specifies the type of the selected data link frame. Data link types are defined in the dataLinkFrameType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type.</t></dd> <dt/> <dd><t>Further values may be assigned by IANA. Note that the assigned values are bits so that multiple observations can be OR'd together. The data link layer is defined in [ISO/IEC.7498-1:1994].</t> </dd> <dt>Additional Information:</dt> <dd> <t>(IEEE802.3)(IEEE802.11)(ISO/IEC.7498-1:1994)</t> </dd> </dl> </section> <section anchor="new-25"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element specifies the type of the selected data link frame. Data link types are defined in thedataLinkFrameType"dataLinkFrameType (Value 408)" registry.</t></dd> <dt/> <dd> <t>Further<t>Additional values may be assigned by IANA. Note that the assigned values are bits so that multiple observations can be OR'd together.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See thedataLinkFrameType"dataLinkFrameType (Value 408)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type]).</t> </dd> <dt/> <dd>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> <t>More information about the data link layer can be found in (IEEE802.3)(IEEE802.11)(ISO/IEC.7498-1:1994).</t> </dd> </dl> </section> </section> <section anchor="mibcapturetimesemantics"> <name>mibCaptureTimeSemantics</name> <section anchor="old-26"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>Indicates when in the lifetime of the Flow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer to Flow creation or Flow export time and refers to the Timestamp fields included in the same Data Record.</t></dd> <dt/> <dd><t>This field <bcp14>SHOULD</bcp14> be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e., the data is already stale) and it is important to know the exact sampling time, then an additional observationTime* element should be paired with the OID using IPFIX Structured Data <xref target="RFC6313"/>. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data.</t></dd> <dt/> <dd><t>Values are listed in the mibCaptureTimeSemantics registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics.</t> </dd> </dl> </section> <section anchor="new-26"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>Indicates when in the lifetime of the Flow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer to Flow creation or Flow export time and refers to the Timestamp fields included in the same Data Record.</t></dd> <dt/> <dd><t>This field <bcp14>SHOULD</bcp14> be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e., the data is already stale) and it is important to know the exact sampling time, then an additional observationTime* element should be paired with the OID using IPFIX Structured Data <xref target="RFC6313"/>. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data.</t></dd> <dt/> <dd><t>Values are listed in themibCaptureTimeSemantics"mibCaptureTimeSemantics (Value 448)" registry.</t> </dd> <dt>Additional Information:</dt> <dd><t>See<t>Values are listed in themibCaptureTimeSemantics registry ([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics]).</t>"mibCaptureTimeSemantics (Value 448)" registry. See [<eref target="https://www.iana.org/assignments/ipfix"/>].</t> </dd> </dl> </section> </section> <section anchor="natquotaexceededevent"> <name>natQuotaExceededEvent</name> <section anchor="old-27"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies the type of a NAT Quota Exceeded event. Values for this Information Element are listed in the "NAT Quota Exceeded Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0791"/> for the definition of the IPv4 source address field.</t></dd> <dt/> <dd><t>See <xref target="RFC3022"/> for the definition of NAT.</t></dd> <dt/> <dd><t>See <xref target="RFC3234"/> for the definition of middleboxes.</t> </dd> </dl> </section> <section anchor="new-27"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies the type of a NAT Quota Exceeded event. Values for this Information Element are listed in the "NAT Quota Exceeded EventType"Type (Value 466)" registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theNAT"NAT Quota Exceeded Event Type (Value 466)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event]).</t> </dd> <dt/> <dd>[<eref target="https://www.iana.org/assignments/ipfix"/>].</t> <t>See <xref target="RFC3022"/> for the definition of NAT.</t> </dd> </dl> </section> </section> <section anchor="natthresholdevent"> <name>natThresholdEvent</name> <section anchor="old-28"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies a type of a NAT Threshold event. Values for this Information Element are listed in the "NAT Threshold Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref target="RFC0791"/> for the definition of the IPv4 source address field.</t></dd> <dt/> <dd><t>See <xref target="RFC3022"/> for the definition of NAT.</t></dd> <dt/> <dd><t>See <xref target="RFC3234"/> for the definition of middleboxes.</t> </dd> </dl> </section> <section anchor="new-28"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element identifies a type of a NAT Threshold event. Values for this Information Element are listed in the "NAT Threshold EventType"Type (Value 467)" registry.</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theNAT"NAT Threshold Event Type (Value 467)" registry([https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event]).</t> </dd> <dt/> <dd>[<eref target="https://www.iana.org/assignments/ipfix"/>]).</t> <t>See <xref target="RFC3022"/> for the definition of NAT.</t> </dd> </dl> </section> </section> </section> <section anchor="misc"><name>Misc</name> <t>This document requests<name>Miscellaneous Updates</name> <t> IANAto updatehas updated thedescriptiondescriptions of the following entries in <xref target="IANA-IPFIX"/>.</t> <section anchor="collectiontimemilliseconds"> <name>collectionTimeMilliseconds</name> <section anchor="old-29"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element <bcp14>SHOULD</bcp14> be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element, as defined below.</t> </dd> </dl> </section> <section anchor="new-29"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element <bcp14>SHOULD</bcp14> be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element.</t> </dd> </dl> </section> </section> <section anchor="messagemd5checksum"> <name>messageMD5Checksum</name> <section anchor="old-30"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The MD5 checksum of the IPFIX Message containing this record. This Information Element <bcp14>SHOULD</bcp14> be bound to its containing IPFIX Message via an options record and the messageScope Information Element, as defined below, and <bcp14>SHOULD</bcp14> appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in <xref target="RFC1321"/>, place the resulting value in this Information Element, and export the buffered message.</t></dd> <dt/> <dd><t>This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. This Information Element has a fixed length of 16 octets.</t> </dd> </dl> </section> <section anchor="new-30"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The MD5 checksum of the IPFIX Message containing this record. This Information Element <bcp14>SHOULD</bcp14> be bound to its containing IPFIX Message via an options record and the messageScope Information Element, and <bcp14>SHOULD</bcp14> appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in <xref target="RFC1321"/>, place the resulting value in this Information Element, and export the buffered message.</t></dd> <dt/> <dd><t>This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. This Information Element has a fixed length of 16 octets.</t> </dd> </dl> </section> </section> <section anchor="anonymizationflags"> <name>anonymizationFlags</name> <section anchor="old-31"> <!-- [rfced] Section 7.3: It is unclear why there are hyphens after destination and source in the tables. We see the OLD text appears in RFC 6235, and it does not include hyphens. The hyphens also are not used in RFC 5103. For example: destination- Information (i.e., source- or destination-) Information Element destination- element Should the hyphens be removed? For example: destination Information (i.e., source or destination) Information Element destination element --> <name>OLD</name> <artwork><![CDATA[ +--------+----------+-----------------------------------------------+ | bit(s) | name | description | | (LSB = | | | | 0) | | | +--------+----------+-----------------------------------------------+ | 0-1 | SC | Stability Class: see the Stability Class | | | | table below, and section Section 5.1. | | 2 | PmA | Perimeter Anonymization: when set (1), | | | | source- Information Elements as described in | | | | [RFC5103] are interpreted as external | | | | addresses, and destination- Information | | | | Elements as described in [RFC5103] are | | | | interpreted as internal addresses, for the | | | | purposes of associating | | | | anonymizationTechnique to Information | | | | Elements only; see Section 7.2.2 for details. | | | | This bit MUST NOT be set when associated with | | | | a non-endpoint (i.e., source- or | | | | destination-) Information Element. SHOULD be | | | | consistent within a record (i.e., if a | | | | source- Information Element has this flag | | | | set, the corresponding destination- element | | | | SHOULD have this flag set, and vice-versa.) | +--------+----------+-----------------------------------------------+ ]]></artwork> </section> <section anchor="new-31"> <name>NEW</name> <artwork><![CDATA[ +--------+----------+-----------------------------------------------+ | bit(s) | name | description | | (LSB = | | | | 0) | | | +--------+----------+-----------------------------------------------+ | 0-1 | SC | Stability Class: see the Stability Class | | | | table below, and Section 5.1 of [RFC6235]. | | 2 | PmA | Perimeter Anonymization: when set (1), | | | | source- Information Elements as described in | | | | [RFC5103] are interpreted as external | | | | addresses, and destination- Information | | | | Elements as described in [RFC5103] are | | | | interpreted as internal addresses, for the | | | | purposes of associating | | | | anonymizationTechnique to Information | | | | Elements only; see Section 7.2.2 of [RFC6235] | | | | for details. | | | | This bit MUST NOT be set when associated with | | | | a non-endpoint (i.e., source- or | | | | destination-) Information Element. SHOULD be | | | | consistent within a record (i.e., if a | | | | source- Information Element has this flag | | | | set, the corresponding destination- element | | | | SHOULD have this flag set, and vice versa.) | +--------+----------+-----------------------------------------------+ ]]></artwork> </section> </section> <section anchor="informationelementdescription"> <name>informationElementDescription</name> <section anchor="old-32"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>A UTF-8 <xref target="RFC3629"/> encoded Unicode string containing a human-readable description of an Information Element. The content of the informationElementDescription <bcp14>MAY</bcp14> be annotated with one or more language tags <xref target="RFC4646"/>, encoded in-line <xref target="RFC2482"/> within the UTF-8 string, in order to specify the language in which the description is written. Description text in multiple languages <bcp14>MAY</bcp14> tag each section with its own language tag; in this case, the description information in each language <bcp14>SHOULD</bcp14> have equivalent meaning. In the absence of any language tag, the "i-default" <xref target="RFC2277"/> language <bcp14>SHOULD</bcp14> be assumed.</t></dd> <dt/> <dd><t>See the Security Considerations section for notes on string handling for Information Element type records.</t> </dd> </dl> </section> <section anchor="new-32"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>A UTF-8 <xref target="RFC3629"/> encoded Unicode string containing a human-readable description of an Information Element. The content of the informationElementDescription <bcp14>MAY</bcp14> be annotated with one or more language tags <xref target="RFC4646"/>, encoded in-line <xref target="RFC2482"/> within the UTF-8 string, in order to specify the language in which the description is written. Description text in multiple languages <bcp14>MAY</bcp14> tag each section with its own language tag; in this case, the description information in each language <bcp14>SHOULD</bcp14> have equivalent meaning. In the absence of any language tag, the "i-default" <xref target="RFC2277"/> language <bcp14>SHOULD</bcp14> be assumed.</t></dd> <dt/> <dd><t>Seethe Security ConsiderationsSection <xref target="RFC5610" section="4" sectionFormat="bare">Security Considerations</xref> of <xref target="RFC5610"/> for notes on string handling for Information Element type records.</t> </dd> </dl> </section> </section> <section anchor="distinctcountofdestinationipaddress"> <name>distinctCountOfDestinationIPAddress</name> <section anchor="old-33"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>The count of distinct destination IP address values for Original Flows contributing to this Aggregated Flow, without regard to IP version. This Information Element is preferred to the version-specific counters below, unless it is important to separate the counts by version.</t> </dd> </dl> </section> <section anchor="new-33"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>The count of distinct destination IP address values for Original Flows contributing to this Aggregated Flow, without regard to IP version. This Information Element is preferred to the version-specific counters, unless it is important to separate the counts by version.</t> </dd> </dl> </section> </section> <section anchor="externaladdressrealm"> <name>externalAddressRealm</name> <section anchor="old-34"> <name>OLD</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element represents the external address realm where the packet is originated from or destined to. The detailed definition is in the internal address realm as specified above.</t> </dd> </dl> </section> <section anchor="new-34"> <name>NEW</name> <dl> <dt>Description:</dt> <dd> <t>This Information Element represents the external address realm where the packet is originated from or destined to.</t></dd> <dt/> <dd><t>See the internalAddressRealm IE for the detailed definition.</t> </dd> </dl> </section> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This document does not add new security considerations to those already discussed for IPFIX in <xref section="8" sectionFormat="of" target="RFC7012"/>.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>Sections4<xref target="desc" format="counter"/> to7<xref target="misc" format="counter"/> include actions for IANA. These actions are not repeated here.</t><t>This document requests IANA to update<t>IANA has updated the note in the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group <xref target="IANA-IPFIX"/> as follows:</t> <dl> <dt>OLD:</dt> <dd> <t>The columns previously titled "References" and "Requester" have been renamed "Additional Information" and "Reference", respectively.</t> </dd> <dt>NEW:</dt> <dd> <t>The columns previously titled "References" and "Requester" have been renamed "Additional Information" and "Reference", respectively.</t></dd> <dt/> <dd><t>The initial values for this registry were provided in <xref target="RFC5102"/>. <xref target="RFC7012"/> has obsoleted <xref target="RFC5102"/> and specifies that the current registry is the normative reference for these Information Elements.</t> </dd> </dl><t>This document also requests IANA to add the RFC number to be assigned to<t>IANA has added this documentto theas a referenceclause offor the "IPFIX Information Elements" registryunderwithin the "IP Flow Information Export (IPFIX) Entities" registry group <xref target="IANA-IPFIX"/>.</t><t>Also, this document requests IANA<t>IANA has also updated references toconsistently referencethe "Service Name and Transport Protocol Port Number"throughconsistently throughout the registry asfollows</t>follows:</t> <dl> <dt>OLD:</dt> <dd> <t>Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers.</t> </dd> <dt>NEW:</dt> <dd> <t>See the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers athttps://www.iana.org/assignments/service-names-port-numbers.</t>[<eref target="https://www.iana.org/assignments/service-names-port-numbers"/>].</t> </dd> </dl> </section> </middle> <back> <displayreference target="RFC0768" to="RFC768"/> <displayreference target="RFC0791" to="RFC791"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <reference anchor="IANA-IPFIX"target="https://www.iana.org/assignments/ipfix/ipfix.xhtml">target="https://www.iana.org/assignments/ipfix"> <front> <title>IP Flow Information Export (IPFIX) Entities</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference><reference anchor="RFC7012"> <front> <title>Information Model for IP Flow Information Export (IPFIX)</title> <author fullname="B. Claise" initials="B." role="editor" surname="Claise"/> <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell"/> <date month="September" year="2013"/> <abstract> <t>This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.</t> </abstract> </front> <seriesInfo name="RFC" value="7012"/> <seriesInfo name="DOI" value="10.17487/RFC7012"/> </reference> <reference anchor="RFC7011"> <front> <title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title> <author fullname="B. Claise" initials="B." role="editor" surname="Claise"/> <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <date month="September" year="2013"/> <abstract> <t>This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101.</t> </abstract> </front> <seriesInfo name="STD" value="77"/> <seriesInfo name="RFC" value="7011"/> <seriesInfo name="DOI" value="10.17487/RFC7011"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC7013"> <front> <title>Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements</title> <author fullname="B. Trammell" initials="B." surname="Trammell"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <date month="September" year="2013"/> <abstract> <t>This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.</t> </abstract> </front> <seriesInfo name="BCP" value="184"/> <seriesInfo name="RFC" value="7013"/> <seriesInfo name="DOI" value="10.17487/RFC7013"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7012.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7013.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC5103"> <front> <title>Bidirectional Flow Export Using IP Flow Information Export (IPFIX)</title> <author fullname="B. Trammell" initials="B." surname="Trammell"/> <author fullname="E. Boschi" initials="E." surname="Boschi"/> <date month="January" year="2008"/> <abstract> <t>This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5103"/> <seriesInfo name="DOI" value="10.17487/RFC5103"/> </reference> <reference anchor="RFC6235"> <front> <title>IP Flow Anonymization Support</title> <author fullname="E. Boschi" initials="E." surname="Boschi"/> <author fullname="B. Trammell" initials="B." surname="Trammell"/> <date month="May" year="2011"/> <abstract> <t>This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="6235"/> <seriesInfo name="DOI" value="10.17487/RFC6235"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5103.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6235.xml"/> <!-- [CCO-NF9FMT] --> <reference anchor="CCO-NF9FMT" target="https://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html"> <front> <title>NetFlow Version 9 Flow-Record Format</title> <author> <organization>Cisco</organization> </author> <date year="2011" month="May"/> </front> </reference><reference anchor="Forwarding-Status" target="https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status"> <front> <title>Forwarding Status (Value 89)</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="RFC9565"> <front> <title>An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title> <author fullname="M. Boucadair" initials="M." surname="Boucadair"/> <date month="March" year="2024"/> <abstract> <t>RFC 7125 revised<!-- [rfced] We removed thetcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changesreference tothe TCP header control bits since RFC 793. However, that update is still problematic for interoperability[Forwarding-Status] becausesome flag values have subsequently been deprecated.</t> <t>This document removes stale information from theIANA"IPFIX Information Elements"updated their registryand avoids future conflictswith theauthoritative IANA "TCP Header Flags" registry.</t> <t>This document obsoletes RFC 7125.</t> </abstract> </front> <seriesInfo name="RFC" value="9565"/> <seriesInfo name="DOI" value="10.17487/RFC9565"/> </reference> <reference anchor="RFC7125"> <front> <title>Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title> <author fullname="B. Trammell" initials="B." surname="Trammell"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <date month="February" year="2014"/> <abstract> <t>This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.</t> </abstract> </front> <seriesInfo name="RFC" value="7125"/> <seriesInfo name="DOI" value="10.17487/RFC7125"/> </reference> <reference anchor="RFC9487"> <front> <title>Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)</title> <author fullname="T. Graf" initials="T." surname="Graf"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <author fullname="P. Francois" initials="P." surname="Francois"/> <date month="November" year="2023"/> <abstract> <t>This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being forwarded with.</t> </abstract> </front> <seriesInfo name="RFC" value="9487"/> <seriesInfo name="DOI" value="10.17487/RFC9487"/> </reference> <reference anchor="RFC5102"> <front> <title>Information Model for IP Flow Information Export</title> <author fullname="J. Quittek" initials="J." surname="Quittek"/> <author fullname="S. Bryant" initials="S." surname="Bryant"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <author fullname="J. Meyer" initials="J." surname="Meyer"/> <date month="January" year="2008"/> <abstract> <t>This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used bylink. We updated theIPFIX protocol for encoding measured traffic information and information relatedtext to include thetraffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces,registry title name andapplications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5102"/> <seriesInfo name="DOI" value="10.17487/RFC5102"/> </reference> <reference anchor="RFC5477"> <front> <title>Information Model for Packet Sampling Exports</title> <author fullname="T. Dietz" initials="T." surname="Dietz"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <author fullname="F. Dressler" initials="F." surname="Dressler"/> <author fullname="G. Carle" initials="G." surname="Carle"/> <date month="March" year="2009"/> <abstract> <t>This memo defines an information model forthePacket SAMPling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information relatedURL to theSampling process. As the PSAMP protocol isregistry group, based onthe IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5477"/> <seriesInfo name="DOI" value="10.17487/RFC5477"/> </reference> <reference anchor="RFC5610"> <front> <title>Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements</title> <author fullname="E. Boschi" initials="E." surname="Boschi"/> <author fullname="B. Trammell" initials="B." surname="Trammell"/> <author fullname="L. Mark" initials="L." surname="Mark"/> <author fullname="T. Zseby" initials="T." surname="Zseby"/> <date month="July" year="2009"/> <abstract> <t>This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5610"/> <seriesInfo name="DOI" value="10.17487/RFC5610"/> </reference> <reference anchor="RFC5655"> <front> <title>Specification of the IP Flow Information Export (IPFIX) File Format</title> <author fullname="B. Trammell" initials="B." surname="Trammell"/> <author fullname="E. Boschi" initials="E." surname="Boschi"/> <author fullname="L. Mark" initials="L." surname="Mark"/> <author fullname="T. Zseby" initials="T." surname="Zseby"/> <author fullname="A. Wagner" initials="A." surname="Wagner"/> <date month="October" year="2009"/> <abstract> <t>This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5655"/> <seriesInfo name="DOI" value="10.17487/RFC5655"/> </reference> <reference anchor="RFC6759"> <front> <title>Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)</title> <author fullname="B. Claise" initials="B." surname="Claise"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <author fullname="N. Ben-Dvora" initials="N." surname="Ben-Dvora"/> <date month="November" year="2012"/> <abstract> <t>This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6759"/> <seriesInfo name="DOI" value="10.17487/RFC6759"/> </reference> <reference anchor="RFC7014"> <front> <title>Flow Selection Techniques</title> <author fullname="S. D'Antonio" initials="S." surname="D'Antonio"/> <author fullname="T. Zseby" initials="T." surname="Zseby"/> <author fullname="C. Henke" initials="C." surname="Henke"/> <author fullname="L. Peluso" initials="L." surname="Peluso"/> <date month="September" year="2013"/> <abstract> <t>The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported.</t> </abstract> </front> <seriesInfo name="RFC" value="7014"/> <seriesInfo name="DOI" value="10.17487/RFC7014"/> </reference> <reference anchor="RFC7015"> <front> <title>Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol</title> <author fullname="B. Trammell" initials="B." surname="Trammell"/> <author fullname="A. Wagner" initials="A." surname="Wagner"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <date month="September" year="2013"/> <abstract> <t>This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.</t> </abstract> </front> <seriesInfo name="RFC" value="7015"/> <seriesInfo name="DOI" value="10.17487/RFC7015"/> </reference> <reference anchor="RFC7133"> <front> <title>Information Elements for Data Link Layer Traffic Measurement</title> <author fullname="S. Kashima" initials="S." surname="Kashima"/> <author fullname="A. Kobayashi" initials="A." role="editor" surname="Kobayashi"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <date month="May" year="2014"/> <abstract> <t>This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.</t> </abstract> </front> <seriesInfo name="RFC" value="7133"/> <seriesInfo name="DOI" value="10.17487/RFC7133"/> </reference> <reference anchor="RFC7270"> <front> <title>Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)</title> <author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <date month="June" year="2014"/> <abstract> <t>This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012.</t> </abstract> </front> <seriesInfo name="RFC" value="7270"/> <seriesInfo name="DOI" value="10.17487/RFC7270"/> </reference> <reference anchor="RFC8038"> <front> <title>Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol</title> <author fullname="P. Aitken" initials="P." role="editor" surname="Aitken"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <author fullname="S. B S" initials="S. B" surname="S"/> <author fullname="C. McDowall" initials="C." surname="McDowall"/> <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/> <date month="May" year="2017"/> <abstract> <t>This document specifies a way to complement IP Flow Information Export (IPFIX) Data Recordsdiscussion withManagement Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.</t> <t>Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.</t> </abstract> </front> <seriesInfo name="RFC" value="8038"/> <seriesInfo name="DOI" value="10.17487/RFC8038"/> </reference> <reference anchor="RFC8158"> <front> <title>IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events</title> <author fullname="S. Sivakumar" initials="S." surname="Sivakumar"/> <author fullname="R. Penno" initials="R." surname="Penno"/> <date month="December" year="2017"/> <abstract> <t>Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing. In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior. This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information. This document describes the formats for logging NAT events.</t> </abstract> </front> <seriesInfo name="RFC" value="8158"/> <seriesInfo name="DOI" value="10.17487/RFC8158"/> </reference> <reference anchor="RFC0768"> <front> <title>User Datagram Protocol</title> <author fullname="J. Postel" initials="J." surname="Postel"/> <date month="August" year="1980"/> </front> <seriesInfo name="STD" value="6"/> <seriesInfo name="RFC" value="768"/> <seriesInfo name="DOI" value="10.17487/RFC0768"/> </reference> <reference anchor="RFC9293"> <front> <title>Transmission Control Protocol (TCP)</title> <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/> <date month="August" year="2022"/> <abstract> <t>This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these haveIANA. Currently, [Forwarding-Status] onlybeen documentedappears ina piecemeal fashion. This document collects and brings those changes together withtheprotocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t> </abstract> </front> <seriesInfo name="STD" value="7"/> <seriesInfo name="RFC" value="9293"/> <seriesInfo name="DOI" value="10.17487/RFC9293"/> </reference> <reference anchor="RFC9260"> <front> <title>Stream Control Transmission Protocol</title> <author fullname="R. Stewart" initials="R." surname="Stewart"/> <author fullname="M. Tüxen" initials="M." surname="Tüxen"/> <author fullname="K. Nielsen" initials="K." surname="Nielsen"/> <date month="June" year="2022"/> <abstract> <t>This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.</t> <t>SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.</t> <t>SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users:</t> <t>The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.</t> </abstract> </front> <seriesInfo name="RFC" value="9260"/> <seriesInfo name="DOI" value="10.17487/RFC9260"/> </reference> <reference anchor="RFC4340"> <front> <title>Datagram Congestion Control Protocol (DCCP)</title> <author fullname="E. Kohler" initials="E." surname="Kohler"/> <author fullname="M. Handley" initials="M." surname="Handley"/> <author fullname="S. Floyd" initials="S." surname="Floyd"/> <date month="March" year="2006"/> <abstract> <t>The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4340"/> <seriesInfo name="DOI" value="10.17487/RFC4340"/> </reference> <reference anchor="RFC3031"> <front> <title>Multiprotocol Label Switching Architecture</title> <author fullname="E. Rosen" initials="E." surname="Rosen"/> <author fullname="A. Viswanathan" initials="A." surname="Viswanathan"/> <author fullname="R. Callon" initials="R." surname="Callon"/> <date month="January" year="2001"/> <abstract> <t>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3031"/> <seriesInfo name="DOI" value="10.17487/RFC3031"/> </reference> <reference anchor="RFC3022"> <front> <title>Traditional IP Network Address Translator (Traditional NAT)</title> <author fullname="P. Srisuresh" initials="P." surname="Srisuresh"/> <author fullname="K. Egevang" initials="K." surname="Egevang"/> <date month="January" year="2001"/> <abstract> <t>The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3022"/> <seriesInfo name="DOI" value="10.17487/RFC3022"/> </reference> <reference anchor="RFC3234"> <front> <title>Middleboxes: Taxonomy and Issues</title> <author fullname="B. Carpenter" initials="B." surname="Carpenter"/> <author fullname="S. Brim" initials="S." surname="Brim"/> <date month="February" year="2002"/> <abstract> <t>This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3234"/> <seriesInfo name="DOI" value="10.17487/RFC3234"/> </reference> <reference anchor="RFC1631"> <front> <title>The IP Network Address Translator (NAT)</title> <author fullname="K. Egevang" initials="K." surname="Egevang"/> <author fullname="P. Francis" initials="P." surname="Francis"/> <date month="May" year="1994"/> <abstract> <t>This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t> </abstract> </front> <seriesInfo name="RFC" value="1631"/> <seriesInfo name="DOI" value="10.17487/RFC1631"/> </reference> <reference anchor="RFC6144"> <front> <title>Framework for IPv4/IPv6 Translation</title> <author fullname="F. Baker" initials="F." surname="Baker"/> <author fullname="X. Li" initials="X." surname="Li"/> <author fullname="C. Bao" initials="C." surname="Bao"/> <author fullname="K. Yin" initials="K." surname="Yin"/> <date month="April" year="2011"/> <abstract> <t>This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address TranslationOLD text. Please review. [Forwarding-Status] IANA, "Forwarding Status (Value 89)", <https://www.iana.org/assignments/ipfix/ ipfix.xhtml#forwarding-status>. Section 4.3.2 original: -Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6144"/> <seriesInfo name="DOI" value="10.17487/RFC6144"/> </reference> <reference anchor="RFC6146"> <front> <title>Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers</title> <author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/> <author fullname="P. Matthews" initials="P." surname="Matthews"/> <author fullname="I. van Beijnum" initials="I." surname="van Beijnum"/> <date month="April" year="2011"/> </front> <seriesInfo name="RFC" value="6146"/> <seriesInfo name="DOI" value="10.17487/RFC6146"/> </reference> <reference anchor="RFC6296"> <front> <title>IPv6-to-IPv6 Network Prefix Translation</title> <author fullname="M. Wasserman" initials="M." surname="Wasserman"/> <author fullname="F. Baker" initials="F." surname="Baker"/> <date month="June" year="2011"/> <abstract> <t>This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses inAdditional Information: See "NetFlow Version 9 Flow-Record Format" [CCO-NF9FMT]. See the"inside" and "outside" prefixes, preserving end-to-end reachabilityForwarding Status sub-registries atthe network layer. This document defines an Experimental Protocol for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="6296"/> <seriesInfo name="DOI" value="10.17487/RFC6296"/> </reference> <reference anchor="RFC0791"> <front> <title>Internet Protocol</title> <author fullname="J. Postel" initials="J." surname="Postel"/> <date month="September" year="1981"/> </front> <seriesInfo name="STD" value="5"/> <seriesInfo name="RFC" value="791"/> <seriesInfo name="DOI" value="10.17487/RFC0791"/> </reference> <reference anchor="RFC8200"> <front> <title>Internet Protocol,[Forwarding-Status]. Current: Additional Information: See "NetFlow Version6 (IPv6) Specification</title> <author fullname="S. Deering" initials="S." surname="Deering"/> <author fullname="R. Hinden" initials="R." surname="Hinden"/> <date month="July" year="2017"/> <abstract> <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t> </abstract> </front> <seriesInfo name="STD" value="86"/> <seriesInfo name="RFC" value="8200"/> <seriesInfo name="DOI" value="10.17487/RFC8200"/> </reference> <reference anchor="RFC5475"> <front> <title>Sampling and Filtering Techniques for IP Packet Selection</title> <author fullname="T. Zseby" initials="T." surname="Zseby"/> <author fullname="M. Molina" initials="M." surname="Molina"/> <author fullname="N. Duffield" initials="N." surname="Duffield"/> <author fullname="S. Niccolini" initials="S." surname="Niccolini"/> <author fullname="F. Raspall" initials="F." surname="Raspall"/> <date month="March" year="2009"/> <abstract> <t>This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5475"/> <seriesInfo name="DOI" value="10.17487/RFC5475"/> </reference> <reference anchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="June" year="2017"/> <abstract> <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by9 Flow-Record Format" [CCO-NF9FMT]. See theInternet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given"Forwarding Status (Value 89)" registryprudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> <reference anchor="RFC6313"> <front> <title>Export of Structured Data in IP Flow Information Export (IPFIX)</title> <author fullname="B. Claise" initials="B." surname="Claise"/> <author fullname="G. Dhandapani" initials="G." surname="Dhandapani"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <author fullname="S. Yates" initials="S." surname="Yates"/> <date month="July" year="2011"/> <abstract> <t>This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6313"/> <seriesInfo name="DOI" value="10.17487/RFC6313"/> </reference> <reference anchor="RFC1321"> <front> <title>The MD5 Message-Digest Algorithm</title> <author fullname="R. Rivest" initials="R." surname="Rivest"/> <date month="April" year="1992"/> <abstract> <t>This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.</t> </abstract> </front> <seriesInfo name="RFC" value="1321"/> <seriesInfo name="DOI" value="10.17487/RFC1321"/> </reference> <reference anchor="RFC3629"> <front> <title>UTF-8, a transformation format of ISO 10646</title> <author fullname="F. Yergeau" initials="F." surname="Yergeau"/> <date month="November" year="2003"/> <abstract> <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t> </abstract> </front> <seriesInfo name="STD" value="63"/> <seriesInfo name="RFC" value="3629"/> <seriesInfo name="DOI" value="10.17487/RFC3629"/> </reference> <reference anchor="RFC4646"> <front> <title>Tags for Identifying Languages</title> <author fullname="A. Phillips" initials="A." surname="Phillips"/> <author fullname="M. Davis" initials="M." surname="Davis"/> <date month="September" year="2006"/> <abstract> <t>This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="RFC" value="4646"/> <seriesInfo name="DOI" value="10.17487/RFC4646"/> </reference> <reference anchor="RFC2482"> <front> <title>Language Tagging in Unicode Plain Text</title> <author fullname="K. Whistler" initials="K." surname="Whistler"/> <author fullname="G. Adams" initials="G." surname="Adams"/> <date month="January" year="1999"/> <abstract> <t>This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="2482"/> <seriesInfo name="DOI" value="10.17487/RFC2482"/> </reference>at [https://www.iana.org/assignments/ipfix]. --> <!-- <referenceanchor="RFC2277">anchor="Forwarding-Status" target="https://www.iana.org/assignments/ipfix"> <front><title>IETF Policy on Character Sets and Languages</title> <author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/> <date month="January" year="1998"/> <abstract> <t>This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract><title>Forwarding Status (Value 89)</title> <author> <organization>IANA</organization> </author> <date/> </front><seriesInfo name="BCP" value="18"/> <seriesInfo name="RFC" value="2277"/> <seriesInfo name="DOI" value="10.17487/RFC2277"/></reference> --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9565.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7125.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9487.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5102.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5477.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5655.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6759.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7014.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7015.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7133.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7270.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8038.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8158.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3022.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1631.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6144.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6296.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5475.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6313.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4646.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2482.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2277.xml"/> </references> </references><?line 934?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Many thanks toPaul Aitken<contact fullname="Paul Aitken"/> for the review and many suggestions that enhanced this specification. Special thanks toAndrew Feren<contact fullname="Andrew Feren"/> for sharing data about scans of IPFIX data he collected.</t><t>Thomas Graf<t><contact fullname="Thomas Graf"/> tagged an issue with the forwardingStatus Information Element and for the Shepherd review.</t> <t>Thanks toEric Vyncke<contact fullname="Éric Vyncke"/> for the review and comments.</t> <t>Thanks toQin Wu<contact fullname="Qin Wu"/> for the opsdir review,Behcet Sarikay<contact fullname="Behcet Sarikaya"/> for the genart review,Martin Duke<contact fullname="Martin Duke"/> for the tsvart review,Donald Eastlake<contact fullname="Donald Eastlake"/> for the intdir review, andHilarie Orman<contact fullname="Hilarie Orman"/> for the secdir review.</t> <t>Thanks toMahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review.</t> <t>Thanks toÉric Vyncke<contact fullname="Éric Vyncke"/> for the IESG review.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA+0923bbyJHv/IqO/BApEWiRknWbzMzKumS0x7rElGc2x2dO ThNokohBgMFFsmLPvO9f7Lfs/tjWpRtogAAvutgej3TiDAmiu6urq6qrqquq HcdppX4aqH2x0vPHk0CJE/+9SkQaiXSkxOmlOAmiG3EaDqJ4LFM/CsXx+0kU p2L19PLk9L/WxHEIHfjQ5PTg/EC8VkM/SePblZbs92N1Df3Se/wr9b3ScmWq hlF8uy+S1Gu1Jv5+S8CI7r64VQl/9NQkHe2LLnxLYLRYDRLza3I7tr+60Xgi 3dT6OlZhqn9ueZEbyjFMz4vlIHV8lQ6caJLIm6HjTwb+e2eAIDmdbivJ+mM/ SWCG6e0EGpweX520wmzcV/F+ywOI91tuFCYqTDLoPI0z1YLZbbZkrCTM8mKi YsJPImToiTMZyqFCSFZaN1H8bhhH2QRfu+wd/PTXldY7dQuPPZi4IwhB+KHo A7+dqxRbiss4uvY9FZceUv/YPT48CKOxDG6Fp1LlYnt8eKUCGB+WoiWzdBTF OBTgR4hBFgSMk7NoBP/1xMsoc6Un/Zh+j+KhDP1/EyD74iKW4VDRD2os/WBf jLlVu29a/UdE77QB9a3pQV6qMPJTcRhIP1E1A/yQyRvl2wP0qUXbpRb/MaLf ufOQifBa7dP7RFQOoU8/gD9NzktQbt40R5T+c/JPVaBXcOSVYkwZDxWQ4ChN J8n+8+c3NzdtH1aoDa2eSyCqYUhE+Zxojv+//X6UjoO8C6IwMZABIKnlG6Dz mb4+OXzR2dgsvm13N1/ob4eHF875yd7J2VUOukYCUAsh4UegHkTAHuHEea1c oD1xQmOYJktM/tBP3Ciffd3kXXwD1+y5Cp+/6T0HuhyFURANAd3P03fbW7vw /5vb3dIP/7gZ+an6x0QCG2zsdXa35cbG7saG3PT6e20bWYyrM3kruhudDj+F ydzI2PPDodNLZQo8WqWI4g3Bb4jVH2WQKbG7t/Y5SeDZoAA9IcDqiaLlOI6Q fZCuIO5arauRnwgQbxl2KyYsJBKRsBQflKQ4yt5lRHmspXhb9CbK9Qe+K4Pg dh06qx0zmyCgNByMKxLAYAprDxNKhB8SCPCaG/sTGjUagEwfqzIkAQlLWJPT 47V1u0cUuLESUqD0BahwZIAtc1N8fDNSoXABalhVGQr1Ht7AzzRlM411EskV KPtx9A7aTiI/TIE91mF5JyMZgjhMWIhC84GKVegq+FGlbltcwURMLxJhCpJI jJUEiKDTfowD08xyUN1bIccRPEYcAOQxYhfmj19zJOulHfueF8A6PwPEpHHk ZSzKWz/hFHnfEDcy4c5hP8DRPnz4HmTB3ovtF7/8Arjw3VEOIP+00+nCT+s0 ILSHvSrw/w1zTEcyZVgnMk5zmO5MKTBcIYwRFsCcCKMUwHHSyEGQEH82+eTr YcbN+8LVImwmd0PnAYwCAihLEpjpjZ+OuH8vI5zhy5OsHwBR09SAjGGJqR+N zq3dHYOzlQPP8/E1Gdj4WKHRb5G6KxMH4s8CD0FOJfwqReCH75A8bOosCJPo V04mCE0/UECpAMhkEiHk0Ggkr+H9fSAQcTCzJ8NnK0cFo2kg29D4ykIQqgmw z8IA1yj+cA0nClbCm9UHr90ERY/vKoCL1w20qpu+dN8xPVUZfZwlKezmeqU9 oSTQZ+rDitoLJnwjQbw2ijWgHMCzqkqbAF4GtgPuTEmC1Mm5QtNsoEvi4cQ0 Qx4GLQOE88AH8GBOgygAyk8I4W9y+oSpocSQtmRrEGywNqfHYvXDB3z+yy9r 7WpHsfpX5qPs8GgnkkYAVRe2PAvoELgI95O6PnEeuRhaRF6CNJ8pMHG8orke 8gxYSgUBiMgos2S+wc4d5CmMAio3o6nFC9MsXgfS9QMf9kemHtioI+RFF6ZA O6JeAPxN0zVok8SETNn2BFFsrKr2sL3O4gGQFUPzf0Z92Hv0CoEIuhWHQA8A fRQTjQEpI5PixySbkEAM1Y0hu2PS/NdBPwbYgTrhZwAdt03pQZcAeIBsCsiZ xIpbakD90AYs4S2XAQBtJFHFCICn84gwIFOSFaAqAYn3NIZfIAb+gGJ/o9NF EVYRTj5zba5GF0sClB/bPHSsV5bkuKcGBossIUEV7WpmKpi1WDxiDZt3vUjv Bfg7YOmWdh2WuBrcDvTXar3y36kb0PqrzA+fsYOxjN8ZRoUpgE7CfRZb4Yut nR2eOH3b7mzY3168KL6hAm1923mxV3wDeLZK36w3dzqbm9a37o41wu7G5i5+ ww1MP+m82KWZPQNaCq9hLrmJeIRY9dncQ+oXYBMKNAoTsXL2pne1ss7/FecX 9Pn18d/enL4+PsLPvR8OXr3KP7T0G70fLt68Oio+FS0PL87Ojs+PuDE8FaVH rZWzg7+vMNhgoV6dXpwfvFqZXkZkSmaDnIxpNVosBPtMIi8PL//3fzpbemm7 nQ4gVn/Z7exskaKiQh4tCmEJ+SsQEJiqE9iKYuwFFhfk1AQYPkiI0kH23oQC CQ6w+ae3iJmf98Vf+u6ks/WdfoATLj00OCs9JJxNP5lqzEiseVQzTI7N0vMK psvwHvy99N3g3Xr4l+9BTCvhdHa//65V1fizxOhOyLGOlhqugIWB/QlNKhDj NSr2urhSsHUCI66jnZFLuHUhjmQqBRuH66wCmi+s/iGbXbK2ZLe1H5NgX7Mk Br5nxFN3iuPFQcJSpXhGlJDUTosMI1CJeAcY+DGoF4FKcffErZeYxxANarnE dj+NbsVBiCYzSpFzpTyAC6Udbzh6I/2+1TpDuaR3EAVKX40cG4PJ2UftJ/QC I5+NyAQUKdSkV7XxjsIJN1pStuGlY+fo4vDq4nWvmO0m7nzih+hGXauYGWII Ujlk0Tu24PHJxwVdoWAmmezGrLNd+1L3f3WC+7ySYxbGrMrg2gziaGxvEu2O tU1s8rbAbysPNB/A8XdG3WPNWOu0KIGRMwGsG0YE6gjoCSORLM14lemCxIhg fnEWaChzN1pbVOzLWotQK1psmhwXOkqxP4EulSv6pQFybavyGJc/Vtc+OUXg s6dAlrE5QDTDREHDWrqw+PCMtDp44xkYJlnsqqtYhgmyxiX8w+fPxMWro1bL arXf2if1mxsI0hrAfIONAPb42MwuNR2BhAN1IW6ju6LyCyxHGrlRkIg3R5fA xoeXTDO9w6tLvWHqDd4ei12YmrD0aLFCviINwAxHCw4QwTqDZGLdC1X3RHPL ICP9sQ4aWghiy8620/fThqmi8lJvTSGKekrpLXNjZxu2zFwh8fJt0jADzL40 BEHdLvWx193bnNkHIG9+H9sbjX0gzvF1a0K+RbzwPyMCEVpcJRzRWhCw40H9 7iOfZvArYPDtXNdRouJrsL4cdKwmDnbm6M5+bjPxnR//dC/iM4tapsKaNU8y MOWkTYlMhaTYHB4+0eMnpkd8gitQh+qavrY2t2b3hWvYDBAZYESYuLtNU4+2 rZqIY63MCLhadyd9onw0w0EPodVbQiZbrT6NYJ4a8DNww4xJf1Us8RsT0UvR 4iPJ6d8TeU6Nc1caXayjRWR3E/rvLMBng/aFSXEU48VRGB/RsWPEzeIYza/q r41OeA90e/JEkelzgyTG5gyeV1l+LPbetIGSyCHlu1kg43XLO63QD3igz9zY Pr66nShyWYeMuV104vtg2wDt5g5v/dtmlw+NCltMu8C025oBSzLVNiIgtzX8 hNnI+M7BinIBOH/ANiewVnHw4WWu8pwETF7AiBuxY7nqG9xudy2zj91t+d74 66+/ot3n2ObOvmC+rjHKhHH4JNrUNOtinZbmf3ymaaAdoFsBSQjNSJmm0h3B 7MBsTcA6a7fqOkDUBPI2ytLcPDezRCzZXvua1me9lzgxsQGfO/CvC/824d8W /HsB/7bh3w698ar3sq4D/vuz4zgz/zU3/ajPmz8K8ZrmCZaop9DuHARymIiP 9xm1rq1h7ukT7yTrO5aruTj9t//eTp2l/1y/MMfvJR7CNCCenNtiX2y839oQ 34rtrbqX+iCeMBBoo7NBf3XveArxhe+YJ853Zm7NqMM/7pPeP49gF4oBK7Gt BcwBfHcPAO9s7syCHAGHf51ZkHc2LMiP4mgyD2zskF5+KUEtuXrVYu5s2Pxo wVcWCfZYKQ/8tggd0Uvs1Ei7/ULWkaAo1JgvRmzUtGevXL1wRPGdsNfKnPbU U/iBdXQGjfRGFNzivhm5Pklm8jsBjHXtAwAwdRB55OQCFPRv8ST8hBWia16q RDsW60mIdVQ8HjRj0qEYHY+bsWEaeNrVgEpQq2aIVrO7amDyUIDp9atdJvYN wqanyEfMWM0J5kmiLz3qk6RtgPyrkbQLb9DlPtAAbdqaZ8vtza4R3ECo+rzn gdwkIJc47gjnM3VMJBIVegmfJVnE8ChOlCef4e/XQXIfKlzIa/J1U+Jv1Rey tAfDLOMjeKC1+rOMXG04ldFOi08rVKfPDT4NFduD6ON16H+QBTSCx9FpmZ+M EAHjLEh9DPubwonxpqBfhKYjx5S9Ij0vhp+fxPaXdvR4PyK/h8z+XIT+FVHg woeNX4x8bj0TlxiYiorCAUaz21Gvr/NY4WcmyLYabIVeAoXxx9QgNW7ZSqCN iUjv35rwXordCT0MNQcMNAaT6/jlihfbRLqA0fdRW+CnRx/FOYq2ur+PDVYL mKMfN7sfhe+OJ2gXHIKldHp5vZU3m5+zAi2diYxhZIztrX7nPBbuDIbahKGG PNTiI0ADBxPvzKJNP9HZMlPPnY4ZubO5NzXL7eVmeb1dnWfpSTFTHG5nuxju ERD6rPKUZp3kg+/w4I+0mlODo31dDL5bmvljIPnZ1HOnqwffK838Ew2+ycS9 BWs+if1rYOhjDoL1E3XOsk/DMRcMlTfMqX36EaP6wz6nr327cuhT6HRFZMEG DgM3yJVfdNixSQM4xPB5LcPtblBmfXhmBfwvKv4qAgt3C8rxMC7E41wkYvZG kWFSiMwk6+v0AK1GjydBchVNXsm+CpC6ZmnQ+aad77O8xWPyTQzbS77PcJYE jMlymHTkaOJEA0y4c9+JAEdrix85HJ83vbxzjHoug392+arHbQSypJV6xNve HXIAORkZJ+9Qx8TrC+oMmxubHWuvtqDLndf2hoxzwRWqzCIpdmrYv2ihF9IM LZg5nWG2QvjlrdkcHBcRvk1diNW7YGmtvfwikgNPJyxxuOpxOARV/9RrZpMD kBE+sG9J+dajKGrNqMbkcYwc17juKXYTitMj1I+zhI/FD0ujCx4e3tE2R7GW 6n2aD1Ppq6kXbZWY/EY8SRB5/HeObOxUJ8xRYwvLiNFF6aFpIqXk17vxcnmF HEay43vJDMZ4WqW7rtIi/Du/m0V4eImVRu6meBbY5o5Djw+JZjuD+CyTUEJG L6+zNno1vqYRVBrg/qSra2LgaQaY3w7DxLE5zRb+g0K+yHLWN73bEtbO2Cwf TOIi9oc0mXB4wL4kGDYYN6/lqTb3EsxrolMw8jooKi3CCdw6daOvXEn+qlgO kHkiPVSBI61o4sEiZywbfxYlco/bYCUn6fnBVY/scLQCNIzr5pejwo1a8/Ol blnyWbIVbl44agispRX9VyYDTlXMD6JLAOI8JqDL6nhBi/On6aEZ1w9F1tCz ExVDOBpUh3G5qK7V7Tb6RQDfM0T8E2E8HmEsIjUW6Oc+ImQmdU1rewuQEUJ8 jCmjc2ygukgbS7uW2KFQ2JH2dIJdVtG+SZ+lHDrrXRN0oGHix5iP5QaZp9ZF P+PFxrywwB/7HKa4Tu+Ssy9gmJisp597oHDg86sRIGoUgQLwWlFcD+aOW0+P 37uUtaezxqu6Q930p6loBUcnbNLZ+IpVgyG5r1AhxCxnsc1b/tLb3c2txre5 akg/eq+ScivOPK5pReupM8+3nM72PHPtibzuQ14LiaZy4wcTRwVdLi9/7k5K mJirbsBynyO7iv1Q5k0MbRxwNqrpu0Z7tMd4OAeM6ZZRt9Bm/oDAL6L61ja9 l+pbmrLRfPs+qsRH8JuuQtS0imC5VkqgEImYhpbhJ8ag9UQen6pxOCP8Qq+/ pNEE6xy6OEKuXbSbxRAe1vVRG1IJSSWst0MmSCmT3ZiielhYKBwtKQIW6SxS hjWHkND0oo8nSzzuUYRRljADOjsip9DFhJ2X4nTQLC90+YppOHXIGEJYCSiV BimY4J240QQkmZ9yeGSSjU0JJ23ID/xhFstFV4Bcu2AAR1mK/rQ+ILwt8roi XCOmZo6EPUDkbfNES/jFeVC+eB0Oo7gZ7ezE4FGFLrnQR1WZSD7wZT+4JYTr L/bJrEa1vJZ+QD+t+m3VXrcn9ebocm29eQ56wKIUBbm0reWaYdRW2KZiudyd SblfJ1/UWT7WJ4Z8YsgnhpzHkItstk2N77PdTnHymk59i4oloVCFOYdfWqO2 WnHprRm4qBvhoXwrVt8OwWHMoUbT4sEnsMiKzuzhPstaP3+jTckwCm/HunTo FZY8RV//rDObGhFe6kSkppeSKC0Kenm1rGQkgP2eKQcEFhnV58s71uF4RXVC LteEmYgqpuqGtfVacLcA4qY6zJhtSY3QdpjVasaq1yPvoQi31LuTT37Z/fVp ceoXZxGmnNPHfdiyYXUt//5sMTvLKXn1oEf/aK8/mgeps106XJ56e2ur/P52 Z6vZ4wTvb0+/vz2z/+3K+929me9vV97f2Nlrhh/d1xV/RXejOXgRI4bu6fIy Lhtya1kcPpHuO1UU00UNZZ5ne/ktrNrovk6iu7iHxCpKEJIdIVWQJxpaW46I pohiDhFNEd1MIrq8un58IvpOK+kRxcto4nFHWA2fg4hBO0U9D0ybOMYioub4 RhdJLUoS4DCEk+d6plRjTJ/IHwTDKIbNYcap46JkyySqe8b32ALJy6Ge+EFK paXXRQ/ds/BpTeRFZg2t68J3vbwXbSe0xVmUmJzOROWdU3y0FWMnTnSCYP0e hU5frtOHdV8zrKTHEQa30/Cb8yVrNEoTDjCCSPlxaVg8rTZvaVbsK8osrq1y urXzAqtD6LSKUl8Nteoq/XD4b/HeOPJUkIfVMTwUr1ygrLFbDW8eY2dMxzxe pMDq1E9Jri54Gqt5IBjNH2w3sEX94YiqV4QK11LGpE3wbLjObR1oWAtXr80U vnV8QBHt10h9Nqg2DrHc5wI19SeJLIew8sictC2xNLFEd2zsq5RKKk4iaIw6 U9GEidw1ycx56D9QNtZ1vAUMpmh1Gv4Qqy/W6IiiyAlPaUQ+shByGAMJ2wPk dX0fYPf5fbOxyXMyb96FLResFf6Z2fNRGfPLZY/5WtAlE5AhbrF62Ts4u1yD 53mHyyhIVQFiDARLeGvEoiNzts1Qbx+a7GwPHaH5eWio6dDeJBQPZErVU9Fl iaXVyT1X31lik7ept77JhV4tardGOaOtyC7n/Q0dhPPFELoHXGEuZ15OMDNn ukle0SPnq7fNKPsZo70Ls52np0OP41LFpVLJ1ynQjUwsyjFV+vUT+wkSOapb oVdyc5swe1LwsBPi9HVyVqIuz5oZsMdYoUbnJ2MOauTEHgvzpcsHLnX4MsfK SJ2WpouMILP1UvhBYpHvA8axOWLtojILfYGOADy7tP9hefq6K3n1ftfkpXWa ReH4rRLfojHxMxF33/BaNlItTDuadvE+GcnpUM2SuqfGEjZYN1lSVCemXYmD aiY6Q0IXXFj0Viuhu5+AhUp6z9vmdcsRNsVJpQxtnCp1VdxeUUabafkNP8d9 HciIa71svN/YEKsAk8yCdC0vxJTSBRF6bqAeFJ3p861IRz8AEN/gsZsrQ+SV PjpCQ3+SBRw4eQtEPl2VHs+2TrBE32uqV8mjeJHikylKoUqQM7BjibGVYG2b xbUguYsQyXF67z2qAGQpWVE0+yL2qU/AXL2vkLnu1PFvl/fMJrvsrH/LbLTI jnuHe9keeOM1eGjedt+Efrrslpthm0UlAvlUk0kU5pYyN8cLwXzXT+ki1LKt X1uKsAhitHbkF59epZ1GYUI4XFZOXNEp4CZ79Jr33jAKVQPz52zO9W0x7zhJ FtGk387ZBWk+Zfm05L7x+Smk9+VTSLFMmKTXuJUsvVaNe8nStHQ/w4InbYm2 haZiAmxQUL7GoxmQyfMqM9kVTbSf7tbU80hSfXeZFHTvMXvMYjwmP9DYgSf/ VnGUl/5ICpxwE+5Dh0blnq914SvrJb9sM+BNmBE5EG/k7WIFgOYW/rlv1avm pMC7YNCA+RCIpBizRXG5SJDCl1Mo3abl43BG6ve8dVB4A9u96Bh7uA8V/3Zp uB53d6DgBhR+3fQLWMTkuFM8BR9IV82r9FGkEPmmCQaQxqocc+HrgmGopfQV 34/rKv9aebyH8ZLQUYU+SMsXCdRaOcSAqP4/YaMWf/QHCNMfUae3ED9fl4aH /oDKE439/syVWbKv2aT6mdCz2IYOuzS/75ydvlzONCmhwBgd6hMRT5If0j8R zgOi5jMQDVINgXVE9Y76GQ53RuewS5qqlZwJz/THULuwKdHhIzmrDrGmDQ0G GDuhEHxAM1skB0Mg4iF5Tgi1MUWy28o/OlRCOw1BJx0MVahiul5SWuGhVwVs tFeosXaBGB+OPkqHjSZ08KbZWXctWgGoNCgZLVyskRfXs9DIh8jw3IeVnijO evhG+IwvnRId0PRP0Z6iucDe8hz6LP16GGE+aFofHZtY8f/Yb36JKX67zRNF wWwhWiMs+0kZUMYP3SZLjeigHtQOZeJ78IbZmhYWoU/Tj2hyPlF4DV7DzbMy F5fnh+s1mNQBDfcOJqWuHbtrR89kSbP7idqfqP3xqX2B7WAuOPfwczZyi13F x1RHesBYTFJggHDpSg9ii6lILCvgf25kl59UA7sWGKAa6pWPVxPtdQpkWU5t y39dTdYEXcCNlaECINw81gsDej5bnNhyAVe1y2zlmTxWKNYl3hKjKr6zSRYD 7+SXfFHmYYEGa5kq3kK7bKOueOyP8XCDSRC1Mhgti/nrIAu5+GJFXcVmPZKF q8bv2VkzxzKL0O1VAWBTbOciduSsek0mOlqapXqAuMonlnxiyYVLkDUDdt9S ZFOkbXYiPPp+5YfvThDYBcqj1pG8IYJyaRY+nMdhAft0wg50/A40OxiozSE9 9KA4BqqIiynQHipDj2J9cGyHgNFZUvs5KenjDUM+lSKmdh51yQ9mVefo01lK xC/ldwxYKZ250/Hi9R+RNodUv0tf2pijJpC36CgsCdK3p72L56fHh+2drb1d p7Pf2dvb+nkmha2eHh8f725025tr+cdOBz5Pd7R2B4H36Vf/i1iqRXi6eQ73 4ec68uV8q7PqKaDs441oaQ1RlXzegPJliETXVfb7h3KCZWSv/LFaIDauVK4u v/w38Acq9cc50XDBR/iAThrW8W/oVj0s+3xtSjmYFyigAkG5ILvl1AqOv9JX NBhT0/jLjWXFfecVIqhcHgebVAdxA9Cb6EogAo7KQ5FJq8tTch+CZsHpsAMK cOcdB7GTpLCN8+llXo8qp3S6WcQqZ9EulzUuqiPQTAh3Kq+nYE2esgL10XDO k7lFjZEqWKw7wUXStSyqSE6ofhaxT+/87JKDZ8rxKWdKh+Nb0TjTRTX0apmj DR5htTiCIGqkC2kBl94tQhaoNaGjdnw6WIcuJdebeBdqklDvMYg4MSH6iHDq jypQyIIdLe5F7P/JRChbdwtOJN7RWBQTvDg9KhXE6JkayR4vjc4Q3OxsYh5H zx/7ASpA60hNnj8gez9lamGmIOisiKfipcqCKaNB6GxthKZU3CRlbvH8a9/L YHYNjFevltTPmCz3OVOemWjaBMMD7dDQvaPx6CAe8yihWQdsT/LlSb48yZff iXxZRP2a18l9lLBmCWWVgvhbFqXSVIN8gMKrtoLNlS9phLzgpKkXeI+Kk5UO H6m+6b9wFEfpUfLaiIvdZzUj6Z7lyPWWuUfKlAiuuY/qsSqm3ttj9PkXeOEK o419PVgtiTpCuXPp47xC64PUQC6vU1H99f5LZFWSfRz2S80AT5z3+ddzYW6r 6+bhiraUSeIuPCbO/MQVH56N4T9L3XdXc0w8fQUeFdEoZdPbt09rTezMDwD/ oNeE3gxHBDrZZD+JAjp2ztVnqotoro8kDdLSmPgcF284kTBz0jsbiICtCY6C asphmVHwslDH++SbQcuCffJmZKMoJ4kcKioeWa7hiFouH7XTG3zqUjPUun1E w1U7Zkf2POEs1a4vfuvs6MXhSLnvkmzG2S1hDt4Urn61HO1vQKpiKdZ1KB90 zmDFRHrC3P89aEVfrVmqpEn1m6LQVVz/dAjLGZbBgAlFYMEELuV4WcabiQqr HXvgx1hYJhvoUIPGWeLemKZls3BGzyauA+NpFeelhBXo6lYOJCX6iWEUDVL5 qFNXSNvswm65LiYBhsCVmzFg5nS1Ht2AXGP3Q1seCPrXC9Weua1ZgRQSt7YE 81SUNQ9YJ8rnidUAXcYoRH26NARg9DF7TtfozY+LhBz6gZ8WgSI6I81jSBFL aG6HSAlxBHY94k/DCqbpUCXpDFoeSa56/h4ADlQ4TOnCv862iNxUpfOCqr8G 5npipSdW+mSsVK6PeRLIoa0s/frrr60/O/ov/1D6uNDfn1sf8XANowY+Umqs vlPV1vbm/32EXlZf9V6Kb6GpdTHxcn/Yy8ZatenyvTwUXjb4iuGPoneYw9JL ZZ8Jgy6X29eJfqr6QzGj6Wl8FCnlbFo7tMkSzLMN2512CS9d0/RyfJB/VLFP sQviwCaVffYOYyTeamdt3e6lDhY2BZ2GiJBKoFFjL28593HzZ2IYn6+1pTBH iQXe4SvaTfNg0fYo5mcjVryi+HwZvtm9NEJfBnJOL5U50FecgwWjMbRm9KLj uTiHVUe5okSs/2vES32pXCxAOYWVBfDC4hAp19DbTrvb7tJ8PAUbTQB7Q1Mv JNTwxnuKMjq/uOKS8LpcfbV8fuOMKEQXRDbVxDSnAoYWo1iU/pp6sQlkrT41 2NISmnopbkC2azGTcqDh8tHhMAeWGXxE8p4vvAQxPrsXla7rHd8kM1PpH5sT zDlGcy96zhQ3VoxLfSNfUY7WtYoT2V4TDycxcU8qdMCnHaq5l9/gDmXtTCjL 3lIl3s0XP7dNL0871NMO9eg7lE15jb2UtrG5f0/73Fe9z4lH2+fqqoQWe9Ks /MI3VyfOrvHZb3f3fvlFqNCN0Hx9E/r4AW9/R3xYdr8Uo2wsQ7xY1CPhXHHI y9pLHDhYle78Dk1w+WzAzWVOVO2pIHC6p0iXMAlkOMzQ0E3BKNXz2NrGMu7r +UT8EKMfzclEd2sXTyYstzPjgKe5LugiIo/Da6wA7WIkeMFyYVvQwqLfgMUO 02sLexZ0xzm0yoNFTVcJTRAg5/iHxA5np2IzN2Fpgt/kfgtXJmp9GgAL6eaS ory9TaDoQLiWAQV/KIlr2oYV45DXfoKJaLyMt6XhecAV39EFvFYMRrs7O4DR 6kgcX4v3UrWtgykQollMO7++vl3HzNrFaTAPBQWvIb0RcBAF2OCPtb4kPtmi jL6ZCYZP5P5E7l8EuRtdAsbV1Zq2O+ayh/uSP6VpYFxd6KaHGG53MSjdta0v np593klxegie6cneELEQnDmwvy7OufXl1oHOvXXtdFyTIFrJw12n5cegc3wa k+ccOsed0p95z5+PV1dgXGNc5OroVo6ONnSLYENtPWQh1oCqC+lLFKbf2FnF CZ4rGjhmHyh8Vbi6J5Zy+8W+3vwOoTOx0lcjJjrSsmxR6EvcuVIEvqCTwvzE vqueomZJBcfloMnrlBnSyTHTpAhM8PN07Kr5ogeTVol4zJS4nnm73CefmCV1 zARKV8yfHlvhGFPTJ7nRJK6qwRl59UwAmjLcEtPOLYs5IjYw6VomsBY4xM0S U7vflAYHGWgE4i7y0R9AIO5sdLoUtAFgUQxIFSTdIhFbOMyOCWMWUj+mASip 54rruJo80/wYZaIImYjq9jLxJ5QnawJ2Gou/JUXIDlcZNe8vXEPT6mAYR9mk EtCCBMlxL8l+qwXcVcijIBuHxPTXfpQlGPCL5e88sfLaVBqAztEugQc0TxWv 8F7ZVwqPovhSpZX6QKO8qe5rZR0Prya4HtcqwAAl4IgvBhgGg8jcFA+0wrJy DN9QzRlzG1JxBQ9VUWzDt4IoybiMMLiFHB72i3yEYmW4mQtZ+RKKUvECJiWa xrVVA8JwacNdH1OUStc8TZErciYOAJCZAmLw1M55y0s2mI70zlAA4gYyKxLA l6X0hyR1jHmDaa5XIJ6adeFXADIrJkLg97gimDiXOi3iKq9DZoroikv8dk7o WoFWAMlwpJGioSt4Lme5+RXk3hxd8oiLVJKbeUtIuY6ZZrMvsMKa4ziiDzsX Su8DFxMmgOOH1LD1YZ/fU963KwOgXrXyS6t1huo3sEv4jnaNS9C4xYGfUtlt vWuhAIG9BkEe49tJNsTDbd5okNFUOJJURIWoxGg2tBpt0dPVQ4sxDkLYHW/E CRIJV2YeyTi/3YBTIRNYoYTvW0Pip19YqHFiDnFjNAaq+GssB2g2DKnaCvB3 gkksJp0Dur8BlQ1674FplzWEg4ZePtneSE1gY/L0rGkcA/hxDPraj7chKAZ1 yOG7NbWkMG3+BhLtpyx/PZoknh/rVuvipRq5dJlN7L+Tt/lbQxC9cZq/dSYx q0YcZda4aXJtv3KEbOCJY5mkgbReA43EHg/B/AEzVnwFmjCsZv4iaBLFi6UZ nEmQiSPxnwpXEGtah37e6uCorsX//XcNok6Pe3/NX/5/bx4oKn7QAAA= --></rfc>