One document matched: draft-ietf-ipfix-mediation-protocol-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="std" docName="draft-ietf-ipfix-mediation-protocol-01.txt">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="IPFIX MED-PROTO">
Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators
</title>
<author initials="B." surname="Claise" fullname="Benoit Claise">
<organization abbrev="Cisco Systems, Inc.">
Cisco Systems, Inc.
</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>1831 Diagem</city>
<country>Belgium</country>
</postal>
<phone>+32 2 704 5622</phone>
<email>bclaise@cisco.com</email>
</address>
</author>
<author initials="A." surname="Kobayashi" fullname="Atsushi Kobayashi">
<organization abbrev="NTT">
NTT Information Sharing Platform Laboratories
</organization>
<address>
<postal>
<street>3-9-11 Midori-cho</street>
<city>Musashino-shi, Tokyo 180-8585</city>
<country>Japan</country>
</postal>
<phone>+81 422 59 3978</phone>
<email>akoba@nttv6.net</email>
</address>
</author>
<author initials="B." surname="Trammell" fullname="Brian Trammell">
<organization abbrev="ETH Zurich">
Swiss Federal Institute of Technology Zurich
</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<city>8092 Zurich</city>
<country>Switzerland</country>
</postal>
<phone>+41 44 632 70 13</phone>
<email>trammell@tik.ee.ethz.ch</email>
</address>
</author>
<date month="June" day="5" year="2012"/>
<area>Operations</area>
<workgroup>IPFIX Working Group</workgroup>
<abstract>
<t>This document specifies the the operation of the IP Flow Information
Export (IPFIX) protocol specific to IPFIX Mediators, including Template
and Observation Point management, timing considerations, and other
Mediator-specific concerns.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The IPFIX architectural components in <xref target="RFC5470"/> consist of
IPFIX Devices and IPFIX Collectors communicating using the IPFIX protocol
<xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, which specifies how to
export IP Flow information. This protocol is designed to export information
about IP traffic Flows and related measurement data, where a Flow is defined
by a set of key attributes (e.g. source and destination IP address, source
and destination port, etc.).</t>
<t>However, thanks to its Template mechanism, the IPFIX protocol can export
any type of information, as long as the relevant Information Element is
specified in the IPFIX Information Model <xref
target="I-D.ietf-ipfix-information-model-rfc5102bis"/>, registered with
IANA, or specified as an enterprise-specific Information Element. The
specifications in the IPFIX protocol <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/> have not been defined in the
context of an IPFIX Mediator receiving, aggregating, correlating,
anonymizing, etc... Flow Records from the one or multiple Exporters. Indeed,
the IPFIX protocol must be adapted for Intermediate Processes, as defined in
the IPFIX Mediation Reference Model as specified in Figure A of <xref
target="RFC6183"/>, which is based on the IPFIX Mediation Problem Statement
<xref target="RFC5982"/>.</t>
<t>This document specifies the IP Flow Information Export (IPFIX) protocol
in the context of the implementation and deployment of IPFIX Mediators. The
use of the IPFIX protocol within a Mediator -- a device which contains both
as a Collecting Process and an Exporting Process -- has an impact on the
technical details of the usage of the protocol. An overview of the technical
problem is covered in section 6 of <xref target="RFC5982"/>: loss of
original exporter information, loss of base time information, transport
sessions management, loss of Options Template Information, Template Id
management, considerations for network considerations for aggregation.</t>
<t>The specifications in this document are based on the IPFIX protocol
specifications <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/> but
adapted according to the IPFIX Mediation Framework <xref
target="RFC6183"/>.</t>
<section title="IPFIX Documents Overview">
<!-- copy over from aggregation? -->
<t>The IPFIX Protocol <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/> provides network administrators with
access to IP Flow information.</t>
<t>The architecture for the export of measured IP Flow information out of
an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX
Architecture <xref target="RFC5470"/>, per the requirements defined in the IPFIX
Requirement doc, <xref target="RFC3917"/>.</t>
<t>The IPFIX Architecture <xref target="RFC5470"/> specifies how IPFIX Data Records and
Templates are carried via a congestion-aware transport protocol from IPFIX
Exporting Processes to IPFIX Collecting Processes.</t>
<t>IPFIX has a formal description of IPFIX Information Elements, their
name, type and additional semantic information, as specified in the IPFIX
Information Model <xref target="I-D.ietf-ipfix-information-model-rfc5102bis"/>.</t>
<t>The IPFIX Applicability Statement <xref target="RFC5472"/> describes
what type of applications can use the IPFIX protocol and how they can use
the information provided. It furthermore shows how the IPFIX framework
relates to other architectures and frameworks.</t>
<t>"IPFIX Mediation: Problem Statement" <xref target="RFC5982"/>,
describing the IPFIX Mediation applicability examples, along with some
problems that network administrators have been facing, is the basis for
the "IPFIX Mediation: Framework" <xref target="RFC6183"/>. This framework
details the IPFIX Mediation reference model and the components of an IPFIX
Mediator.</t>
</section>
<section title="IPFIX Mediator Documents Overview">
<t>The "IPFIX Mediation: Problem Statement" <xref target="RFC5982"/>
provides an overview of the applicability of Mediators, and defines
requirements for Mediators in general terms. This document is of use
largely to define the problems to be solved through the deployment of
IPFIX Mediators, and to provide scope to the role of Mediators within an
IPFIX collection infrastructure.</t>
<t>The "IPFIX Mediation: Framework" <xref target="RFC6183"/> provides more
architectural details of the arrangement of Intermediate Processes within
a Mediator.</t>
<t>The details of specific Intermediate Processes, when these have
additional export specifications (e.g., metadata about the intermediate
processing conveyed through IPFIX Options Templates), are each treated in
their own document (e.g., the "IP Flow Anonymization Support" <xref target="RFC6235"/>).
Documents specifying the operations of specific Intermediate Processes
cover the operation of these Processes within the Mediator framework, and
comply with the specifications given in this document; they may
additionally specify the operation of the process independently, outside
the context of a Mediator, when this is appropriate. As of today, these
documents are:</t>
<list style="numbers">
<t>"IP Flow Anonymization Support", <xref target="RFC6235"/>, which describes
Anonymization techniques for IP flow data and the export of Anonymized
data using the IPFIX protocol.</t>
<t>"Flow Selection Techniques" <xref target="I-D.ietf-ipfix-flow-selection-tech"/>, which describes the
process of selecting a subset of flows from all flows observed at an
observation point, the flow selection motivations, and some specific
flow selection techniques.</t>
<t>"Exporting Aggregated Flow Data using IP Flow Information Export"
<xref target="I-D.ietf-ipfix-a9n"/> which describes Aggregated Flow export within the
framework of IPFIX Mediators and defines an interoperable,
implementation-independent method for Aggregated Flow export.</t>
</list>
<t>This document specifies the IP Flow Information Export (IPFIX) protocol
specific to Mediation, i.e. the specifications that all Intermediate
Processes type must comply to. Some extra specifications might be required
per Intermediate Process type (In which case, the Intermediate Process
specific document would cover those).</t>
</section>
<section title="Relationship with IPFIX and PSAMP">
<t>The specification in this document applies to the IPFIX protocol
specifications <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>. All specifications from <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/> apply
unless specified otherwise in this document.</t>
<t>As the Packet Sampling (PSAMP) protocol specifications <xref target="RFC5476"/> are
based on the IPFIX protocol specifications, the specifications in this
document are also valid for the PSAMP protocol. Therefore, the method
specified by this document also applies to PSAMP.</t>
</section>
</section>
<section title="Terminology">
<t>[EDITOR'S NOTE: change to only define terms in this section that are
actually used in the document.]</t>
<t>[EDITOR'S NOTE: Definition change proposal for the Intermediate Process,
Intermediate Conversion Process, Intermediate Selection Process,
Intermediate Anonymization Process, and IPFIX Mediator. See
http://www.ietf.org/mail-archive/web/ipfix/current/msg05969.html. However,
the definitions are copied over verbatim from RFC6183. Also note that
Intermediate Anonymization Process in this document is not in line with the
RFC6235.]</t>
<t>IPFIX-specific terms, such as Observation Domain, Flow, Flow Key,
Metering Process, Exporting Process, Exporter, IPFIX Device, Collecting
Process, Collector, Template, IPFIX Message, Message Header, Template
Record, Data Record, Options Template Record, Set, Data Set, Information
Element, and Transport Session, used in this document are defined in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>. The PSAMP-specific terms used
in this document, such as Filtering and Sampling, are defined in <xref
target="RFC5476"/>.</t>
<t>IPFIX Mediation terms related to aggregation, such as the Interval,
Aggregated Flow, and Aggregated Function are defined in <xref
target="I-D.ietf-ipfix-a9n"/>.</t>
<t>The IPFIX Mediation-specific terminology used in this document is defined
in "IPFIX Mediation: Problem Statement" <xref target="RFC5982"/>, and reused
in "IPFIX Mediation: Framework" <xref target="RFC6183"/>. However, since
both of those documents are an informational RFCs, the definitions have been
reproduced here along with additional definitions.</t>
<t>Similarly, since <xref target="RFC6235"/> is an experimental RFC, the
Anonymization Record, Anonymized Data Record, and Intermediate Anonymization
Process terms, specified in <xref target="RFC6235"/>, are also reproduced
here.</t>
<t>In this document, as in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, <xref target="RFC5476"/>,
<xref target="I-D.ietf-ipfix-a9n"/>, and <xref target="RFC6235"/>, the first
letter of each IPFIX-specific and PSAMP-specific term is capitalized along
with the IPFIX Mediation-specific term defined here. In this document, we
call a stream of records carrying flow- or packet-based information a
"record stream". The records may be encoded as IPFIX Data Records of any
other format.</t>
<list style="hanging">
<t hangText="Transport Session Information: ">The Transport Session is
specified in <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>. In SCTP,
the Transport Session Information is the SCTP association. In TCP and UDP,
the Transport Session Information corresponds to a 5-tuple {Exporter IP
address, Collector IP address, Exporter transport port, Collector
transport port, transport protocol}.</t>
<t hangText="Original Exporter: ">An Original Exporter is an IPFIX Device
that hosts the Observation Points where the metered IP packets are
observed.</t>
<t hangText="Original Observation Point: ">An Observation Point of the
Original Exporter. In the case of the Intermediate Aggregation Process on
an IPFIX Mediator, the Original Observation Point can be composed of, but
not limited to, a (set of) specific exporter(s), a (set of) specific
interface(s) on an Exporter, a (set of) line card(s) on an Exporter, or
any combinations of these.</t>
<t hangText="IPFIX Mediation: ">IPFIX Mediation is the manipulation and
conversion of a record stream for subsequent export using the IPFIX
protocol.</t>
<t hangText="Template Mapping: ">A mapping from Template Records and/or
Options Template Records received by a Mediator to Template Records and/or
Options Template Records sent by that IPFIX Mediator. Each entry in a
Template Mapping is scoped by incoming or outgoing Transport Session and
Observation Domain, as with Templates and Options Templates in the IPFIX
Protocol.</t>
<t hangText="Anonymization Record: ">A record that defines the properties
of the anonymization applied to a single Information Element within a
single Template or Options Template, as in <xref target="RFC6235"/>.</t>
<t hangText="Anonymized Data Record: ">A Data Record within a Data Set
containing at least one Information Element with Anonymized values. The
Information Element(s) within the Template or Options Template describing
this Data Record SHOULD have a corresponding Anonymization Record, as in
<xref target="RFC6235"/>.</t>
</list>
<t>The following terms are used in this document to describe the
architectural entities used by IPFIX Mediation.</t>
<list style="hanging">
<t hangText="Intermediate Process: ">An Intermediate Process takes a
record stream as its input from Collecting Processes, Metering Processes,
IPFIX File Readers, other Intermediate Processes, or other record sources;
performs some transformations on this stream, based upon the content of
each record, states maintained across multiple records, or other data
sources; and passes the transformed record stream as its output to
Exporting Processes, IPFIX File Writers, or other Intermediate Processes,
in order to perform IPFIX Mediation. Typically, an Intermediate Process is
hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be
hosted by an Original Exporter.</t>
<t hangText="IPFIX Mediator: ">An IPFIX Mediator is an IPFIX Device that
provides IPFIX Mediation by receiving a record stream from some data
sources, hosting one or more Intermediate Processes to transform that
stream, and exporting the transformed record stream into IPFIX Messages
via an Exporting Process. In the common case, an IPFIX Mediator receives a
record stream from a Collecting Process, but it could also receive a
record stream from data sources not encoded using IPFIX, e.g., in the case
of conversion from the NetFlow V9 protocol <xref target="RFC3954"/> to
IPFIX protocol.</t>
</list>
<t>Specific Intermediate Processes are described below. However, this is not an exhaustive list.</t>
<list style="hanging">
<t hangText="Intermediate Conversion Process: ">An Intermediate Conversion
Process is an Intermediate Process that transforms non-IPFIX into IPFIX,
or manages the relation among Templates and states of incoming/outgoing
Transport Sessions (or equivalent for non IPFIX protocols) in the case of
transport protocol conversion (e.g., from UDP to SCTP).</t>
<t hangText="Intermediate Aggregation Process: ">An Intermediate
Aggregation Process is an Intermediate Process that aggregates records
based upon a set of Flow Keys or functions applied to fields from the
record (e.g., binning and subnet aggregation).</t>
<t hangText="Intermediate Correlation Process: ">An Intermediate
Correlation Process is an Intermediate Process that adds information to
records, noting correlations among them, or generates new records with
correlated data from multiple records (e.g., the production of
bidirectional flow records from unidirectional flow records).</t>
<t hangText="Intermediate Selection Process: ">An Intermediate Selection
Process is an Intermediate Process that selects records from a sequence
based upon criteria-evaluated record values and passes only those records
that match the criteria (e.g., Filtering only records from a given network
to a given Collector).</t>
<t hangText="Intermediate Anonymization Process: ">An Intermediate
Anonymization Process is an Intermediate Process that transforms records
in order to anonymize them, to protect the identity of the entities
described by the records (e.g., by applying prefix-preserving
pseudonymization of IP addresses).</t>
</list>
</section>
<section title="Handling IPFIX Message Headers" anchor="sec-header">
<t>The format of the IPFIX Message Header as exported by an IPFIX Mediator
is shown in <xref target="fig-header"/>. Note that the format is compatible
with the IPFIX Message Header defined in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, with some field definitions
(for the example, the Export Time) updated in the context of the IPFIX
Mediator.</t>
<figure title="IP Message Header format" anchor="fig-header">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The header fields as exported by an IPFIX Mediator are describe below.</t>
<list style="hanging">
<t hangText="Version: ">Version of Flow Record format exported in this
message. The value of this field is 0x000a for the current version,
incrementing by one the version used in the NetFlow services export
version 9 <xref target="RFC3954"/>.</t>
<t hangText="Length: ">Total length of the IPFIX Message, measured in
octets, including Message Header and Set(s).</t>
<t hangText="Export Time: ">Time at which the IPFIX Message Header leaves
the Mediator, expressed in seconds since the UNIX epoch of 1 January 1970
at 00:00 UTC, encoded as an unsigned 32-bit integer. [EDITOR'S NOTE:
change to be consistent with Timing Considerations below]</t>
<t hangText="Sequence Number: ">Incremental sequence counter modulo 2^32
of all IPFIX Data Records sent on this PR-SCTP stream from the current
Observation Domain by the Exporting Process. Check the specific meaning of
this field in the sub-sections of section 10 when UDP or TCP is selected
as the transport protocol. This value SHOULD be used by the Collecting
Process to identify whether any IPFIX Data Records have been missed.
Template and Options Template Records do not increase the Sequence Number.
[EDITOR'S NOTE: change here and in 5101bis to handle multiple transports
natively.] </t>
<t hangText="Observation Domain ID: ">A 32-bit identifier of the
Observation Domain that is locally unique to the Exporting Process. The
Exporting Process uses the Observation Domain ID to uniquely identify to
the Collecting Process the Observation Domain that metered the Flows. It
is RECOMMENDED that this identifier is also unique per IPFIX Device.
Collecting Processes SHOULD use the Transport Session and the Observation
Domain ID field to separate different export streams originating from the
same Exporting Process. The Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX Message.
For example, when exporting the Exporting Process Statistics, or in case
of hierarchy of Collector when aggregated Data Records are exported.
[EDITOR'S NOTE: make consistent with Observation Domain Management as
discussed below]</t>
</list>
</section>
<section title="Template Management">
<t>[EDITOR'S NOTE: verify this section is consistent with 5101bis, after
simplified template management converges.]</t>
<t>How a Mediator handles the Templates it receives from the Original
Exporter depends entirely on the nature of the Intermediate Process running
on that Mediator. For Mediators which pass substantially the same Data
Records from the Original Exporter downstream, (e.g., an Intermediate
Selection Process), the templates can be passed unmodified as described in
<xref target="sec-tmpl-passthrough"/>; this section describes a Template
Mapping required to make this work in the general case. Mediators which
export Data Records which are substantially changed from the Data Records
received from the Original Exporter follow the guidelines in <xref
target="sec-tmpl-passthrough"/> instead.</t>
<t>Subsequent subsections deal with specific issues in Template management
that may occur at Mediators.</t>
<section title="Passing Unmodified Templates through a Mediator" anchor="sec-tmpl-passthrough">
<t>[EDITOR'S NOTE: the definition of template mappings seems really
implementation specific -- why not notionally just map IDs on each socket
to a base template? on the other hand, if we're providing a real example,
it should have concrete content in each field. reformatting is held off
until this issue is resolved.]</t>
<t>The first case is a situation where the IPFIX Mediator doesn't modify
the (Options) Template Record(s) content. A typical example is an
Intermediate Selection Process acting as distributor, which collects Flow
Records from one or more Exporters, and based on the Information Elements
content, redirects the Flow Records to the appropriate Collector. This
example is a typical case of a single network operation center managing
multiple universities: an unique IPFIX Collector collects all Flow Records
for the common infrastructure, but might be re-exporting specific
university Flow Records to the responsible system administrator.</t>
<t>As specified in <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, the Template IDs are unique per Exporter,
per Transport Session, and per Observation Domain. As there is no
guarantee that, for similar Template Records, the Template IDs received on
the incoming Transport Session and exported to the outgoing Transport
Session would be same, the IPFIX Mediator MUST maintain a Template Mapping
composed of related received and exported (Options) Template Records:</t>
<list style="symbols">
<t>for each received (Options) Template Record: Template Record Flow
Keys and non Flow Keys, Template ID, Observation Domain Id, and
Transport Session Information</t>
<t>for each exported (Options) Template Record: Template Record Flow
Keys and non Flow Keys, Template ID, Collector, Observation Domain Id,
and Transport Session Information</t>
</list>
<t>If an IPFIX Mediator receives an IPFIX Withdrawal Message for a
(Options) Template Record that is not used anymore in any other Template
Mappings, the IPFIX Mediator SHOULD export the appropriate IPFIX
Withdrawal Message(s) on the outgoing Transport Session, and remove the
corresponding entry in the Template Mapping.</t>
<t>If a (Options) Template Record is not used anymore in an outgoing
Transport Session, it MUST be withdrawn with an IPFIX Template Withdrawal
Message on that specific outgoing Transport Session, and its entry MUST be
removed from the Template Mapping.</t>
<t>If an incoming or outgoing Transport Session is gracefully shutdown or
reset, the (Options) Template Records corresponding to that Transport
Session MUST be removed from the Template Mapping.</t>
<t>For example, <xref target="fig-selection-example"/> displays an example
of an Intermediate Selection Process, re-distributing Data Records to
Collectors on the basis of customer networks, i.e. the Route Distinguisher
(RD). In this example, the Template Record received from the Exporter #1
is reused towards Collector #1, Collector #2, and Collector #3. </t>
<figure title="Intermediate Selection Process example" anchor="fig-selection-example">
<artwork><![CDATA[
Tmpl. .---------.
ID 256 | |
.---->|Collector|<==>Customer
| |#1 | A
| | |
RD=100:1 '---------'
.---------.Templ. .---------. |
| |Id | |----' .---------.
| |258 | | RD=100:2 | |
|IPFIX |------->|IPFIX |--------->|Collector|<==>Customer
|Exporter | |Mediator | Tmpl. |#2 | B
|#1 | | | ID 257 | |
| | | |----. '---------'
'---------' '---------' |
RD=100:3
Tmpl. | .---------.
ID | | |
257 '---->|Collector|<==>Customer
|#3 | C
| |
'---------'
]]></artwork>
</figure>
<t><xref target="fig-template-mapping-example"/> shows the Template Mapping for the system shown in <xref target="fig-selection-example"/>.</t>
<figure title="Template Mapping example: templates" anchor="fig-template-mapping-example">
<artwork><![CDATA[
Template Entry A:
Incoming Transport Session Information (from Exporter#1):
Source IP: <Exporter#1 export IP address>
Destination IP: <IPFIX Mediator IP address>
Protocol: SCTP
Source Port: <source port>
Destination Port: 4739 (IPFIX)
Observation Domain Id: <Observation Domain ID>
Template Id: 258
Flow Keys: <series of Flow Keys>
Non Flow Keys: <series of non Flow Keys>
Template Entry B:
Outgoing Transport Session Information (to Collector#1):
Source IP: <IPFIX Mediator IP address>
Destination IP: <IPFIX Collector#1 IP address>
Protocol: SCTP
Source Port: <source port>
Destination Port: 4739 (IPFIX)
Observation Domain Id: <Observation Domain ID>
Template Id: 256
Flow Keys: <series of Flow Keys>
Non Flow Keys: <series of non Flow Keys>
Template Entry C:
Outgoing Transport Session Information (to Collector#2):
Source IP: <IPFIX Mediator IP address>
Destination IP: <IPFIX Collector#2 IP address>
Protocol: SCTP
Source Port: <source port>
Destination Port: 4739 (IPFIX)
Observation Domain Id: <Observation Domain ID>
Template Id: 257
Flow Keys: <series of Flow Keys>
Non Flow Keys: <series of non Flow Keys>
Template Entry D:
Outgoing Transport Session Information (to Collector#3):
Source IP: <IPFIX Mediator IP address>
Destination IP: <IPFIX Collector#3 IP address>
Protocol: SCTP
Source Port: <source port>
Destination Port: 4739 (IPFIX)
Observation Domain Id: <Observation Domain ID>
Template Id: 257
Flow Keys: <series of Flow Keys>
Non Flow Keys: <series of non Flow Keys>
]]></artwork>
</figure>
<t>The Template Mapping corresponding to figure B can be displayed as:</t>
<figure title="Template Mapping example: mappings">
<artwork><![CDATA[
Template Entry A <----> Template Entry B
Template Entry A <----> Template Entry C
Template Entry A <----> Template Entry D
]]></artwork>
</figure>
<t>Alternatively, the Template Mapping may be optimized as:</t>
<figure title="Template Mapping example: mappings">
<artwork><![CDATA[
+--> Template Entry B
|
Template Entry A <--+--> Template Entry C
|
+--> Template Entry D
]]></artwork>
</figure>
<t>Note that all examples use Transport Sessions based on the SCTP
protocol, as simplified use cases. However, the protocol would be
important in situations such as an Intermediate Conversion Process doing
transport protocol conversion.</t>
</section>
<section title="Creating New Templates at a Mediator" anchor="sec-tmpl-new">
<t>The second case is a situation where the IPFIX Mediator generates new
(Options) Template Records as a result of the Intermediate Process.</t>
<t>In this situation, the IPFIX Mediator doesn't need to maintain a
Template Mapping, as it generates its own series of (Options) Template
Records. However, the following special case might still require a
Template Mapping, i.e. a situation where the IPFIX Mediator, typically
containing an Intermediate Conversion Process, Intermediate Aggregation
Process <xref target="I-D.ietf-ipfix-a9n"/>, or Intermediate Anonymization
Process in case of black-marker Anonymization <xref target="RFC6235"/>,
generates new (Options) Template Records based on what it receives from
the Exporter(s), and based on the Intermediate Process function. In such a
case, it's important to keep the correlation between the received
(Options) Template Records and exported Derived (Options) Template Records
in the Template Mapping. These template mappings would be kept as in <xref
target="sec-tmpl-passthrough"/>, except that the export template would not
be identical to the collection template.</t>
</section>
<section title="Information Element Ordering within Templates">
<t>[EDITOR'S NOTE: address the following: What Paul Aikten would like to
see in section 3.5 (See
http://www.ietf.org/mail-archive/web/ipfix/current/msg05969.html): What
about IE ordering? May an exporter re-order received fields? eg, two
devices sending the same information, though with the fields in a
different order. Or the mediator is extracting the same information from
two sources. That seems to be a valid scenario. eg, this reduces the
number of templates received at the collector.]</t>
</section>
<section title="Handling Unknown Information Elements">
<t>[EDITOR'S NOTE: also from Paul Aitken: What should a mediator do with a
field which it doesn't know/understand? Inevitably, exporters will be
updated without mediators keeping in step. It's also very likely that
mediators will see Enterprise-specific IEs. May a mediator re-export
unknown IEs unchanged, or should it drop them? Presumably a mediator may
report received Enterprise-specific IEs even from multiple different
Enterprises. What if an unknown field depends on the field ordering? eg,
it's a bitfield like flowKeyIndicator. Re-ordering, adding or removing
fields breaks the meaning of this field, so it can't be passed on. It can
only be used if the received fields are reported unchanged.]</t>
</section>
</section>
<section title="Preserving Original Observation Point Information" anchor="sec-oop">
<t>[EDITOR'S NOTE: Decide whether we want to address export of observation
point information without 6313. Review this section to make sure it
adequately explains how original Observation Point information can get so
complicated.]</t>
<t>Depending on the use case, the Collector in an Exporter - Mediator -
Collector structure may need to receive information about the Original
Observation Point(s), otherwise it may wrongly conclude that the IPFIX
Device exporting the Flow Records, i.e. the IPFIX Mediator, directly
observed the packets that generated the Flow Records. Two new Information
Elements are introduced in the subsections below to address this use case:
originalExporterIPv4Address and originalExporterIPv6Address. Practically,
the Original Exporters will not exporting these Information Elements.
Therefore, the Intermediate Process SHOULD report the Original Observation
Point(s) to the best of its knowledge. Note that the Configuration Data
Model for IPFIX and PSAMP <xref
target="I-D.ietf-ipfix-configuration-model"/> may help.</t>
<t>In the IPFIX Mediator, the Observation Point(s) may be represented
by:</t>
<list style="symbols">
<t>A single Original Exporter (represented by the
originalExporterIPv4Address or originalExporterIPv6Address Information
Elements)</t>
<t>A list of Original Exporters (represented by the
originalExporterIPv4Address or originalExporterIPv6Address Information
Elements).</t>
<t>Any combination or list of Information Elements representing
Observation Points. For example:</t>
<list style="symbols">
<t>A list of Original Exporter interface(s) (represented by the
originalExporterIPv4Address or originalExporterIPv6Address, the
ingressInterface and/or egressInterface Information Elements,
respectively)</t>
<t>A list of Original Exporter line card (represented by the
originalExporterIPv4Address or originalExporterIPv6Address, the
lineCardId Information Elements, respectively)</t>
</list>
</list>
<t>Some Information Elements characterizing the Observation Point may be
added. For example, the flowDirection Information Element specifies the
direction of the observation, and, as such, characterizes the Observation
Point.</t>
<t>Any combination of the above representations is possible. For example, in
case of an Intermediate Aggregation Process, an Original Observation Point
could be composed of:</t>
<figure title="Complex Observation Point Definition Example" anchor="fig-oop-example">
<artwork><![CDATA[
exporterIPv4Address 192.0.2.1
exporterIPv4Address 192.0.2.2,
interface ethernet 0, direction ingress
interface ethernet 1, direction ingress
interface serial 1, direction egress
interface serial 2, direction egress
exporterIPv4Address 192.0.2.3,
lineCardId 1, direction ingress
]]></artwork>
</figure>
<t>If the Original Observation Point is composed of a list, then the IPFIX
Structured Data <xref target="RFC6313"/> MUST be used to export it from the
IPFIX Mediator.</t>
<t>The most generic way to export the Original Observation Point is to use a
subTemplateMultiList, with the semantic "exactlyOneOf". Taking the previous
example, the following encoding can be used:</t>
<figure title="Complex Observation Point Definition Example: Templates" anchor="fig-oop-templates-example">
<artwork><![CDATA[
Template Record 257: exporterIPv4Address
Template Record 258: exporterIPv4Address,
basicList of ingressInterface, flowDirection
Template Record 259: exporterIPv4Address, lineCardId, flowDirection
]]></artwork>
</figure>
<t>The Original Observation Point is modeled with the Data Records
corresponding to either Template Record 1, Template Record 2, or Template
Record 3 but not more than one of these ("exactlyOneOf" semantic). This
implies that the Flow was observed at exactly one of the Observation Points
reported.</t>
<t>When an IPFIX Mediator receives Flow Records containing the Original
Observation Point Information Element, i.e. originalExporterIPv6Address or
originalExporterIPv4Address, the IPFIX Mediator SHOULD NOT modify its
value(s) when composing new Flow Records in the general case. Known
exceptions include anonymization per <xref target="RFC6235"/> section 7.2.4
and an Intermediate Correlation Process rewriting addresses across NAT. In
other words, the Original Observation Point should not be replaced with the
IPFIX Mediator Observation Point. The daisy chain of (Exporter, Observation
Point) representing the path the Flow Records took from the Exporter to the
top Collector in the Exporter - Mediator(s) - Collector structure model is
out of the scope of this specification.</t>
<section title="originalExporterIPv4Address Information Element" anchor="ie-oe4">
<t><list style="hanging">
<t hangText="Description: ">The IPv4 address used by the Exporting
Process on an Original Exporter, as seen by the Collecting Process on
an IPFIX Mediator. Used to provide information about the Original
Observation Points to a downstream Collector.</t>
<t hangText="Data Type: ">ipv4Address</t>
<t hangText="ElementId: ">TBD1</t>
</list></t>
</section>
<section title="originalExporterIPv6Address Information Element" anchor="ie-oe6">
<t><list style="hanging">
<t hangText="Description: ">The IPv6 address used by the Exporting
Process on an Original Exporter, as seen by the Collecting Process on
an IPFIX Mediator. Used to provide information about the Original
Observation Points to a downstream Collector.</t>
<t hangText="Data Type: ">ipv6Address</t>
<t hangText="ElementId: ">TBD2</t>
</list></t>
</section>
</section>
<section title="Managing Observation Domain IDs">
<t>In any case, the Observation Domain ID of any IPFIX Message containing
Flow Records relevant to no particular Observation Domain, or to multiple
Observation Domains, MUST have an Observation Domain ID of 0, as in
<xref target="sec-header"/> above, and section 3.1 of <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>.</t>
<t>IPFIX Mediators that do not change (Options) Template Records MUST
maintain a Template Mapping, as detailed in <xref
target="sec-tmpl-passthrough"/>, to ensure that the combination of
Observation Domain IDs and Template IDs do not collide on export.</t>
<t>For IPFIX Mediators that export New (Options) Template Records, as in
<xref target="sec-tmpl-new"/>, there are two options for Observation
Domain ID management. The first and simplest of these is to completely
decouple exported Observation Domain IDs from received Observation Domain
IDs; the IPFIX Mediator, in this case, comprises its own set of
Observation Domain(s) independent of the Observation Domain(s) of the
Original Exporters.</t>
<t>The second option is to provide or maintain a Template Mapping for
received (Options) Template Records and exported inferred (Options)
Template Records, along with the appropriate Observation Domain IDs per
Transport Session, which ensures that the combination of Observation
Domain IDs and Template IDs do not collide on export.</t>
<t>In some cases where the IPFIX Message Header can't contain a consistent
Observation Domain for the entire IPFIX Message, but the Flow Records
exported from the IPFIX Mediator should anyway contain the Observation
Domain of the Original Exporter, the (Options) Template Record must
contain the originalObservationDomainId Information Element. When an IPFIX
Mediator receives Flow Records containing the originalObservationDomainId
Information Element, the IPFIX Mediator MUST NOT modify its value(s) when
composing new Flow Records with the originalObservationDomainId
Information Element.</t>
<section title="originalObservationDomainId Information Element" anchor="ie-ood">
<t><list style="hanging">
<t hangText="Description: ">The Observation Domain ID reported by the
Exporting Process on an Original Exporter, as seen by the Collecting
Process on an IPFIX Mediator. Used to provide information about the
Original Observation Domain to a downstream Collector.</t>
<t hangText="Data Type: ">unsigned32</t>
<t hangText="Data Type Semantics: ">identifier</t>
<t hangText="ElementId: ">TBD3</t>
</list></t>
</section>
</section>
<section title="Timing Considerations">
<t>The IPFIX Message Header "Export Time" field is the time in seconds since
0000 UTC Jan 1, 1970, at which the IPFIX Message leaves the IPFIX Mediator.
However, in the specific case of an IPFIX Mediator containing an
Intermediate Conversion Process, the IPFIX Mediator MAY keep the export time
received from the incoming Transport Session.</t>
<t>It is RECOMMENDED that Mediators handle time using absolute timestamps
(e.g. flowStartSeconds, flowStartMilliseconds, flowStartNanoseconds), which
are specified relative to the UNIX epoch (00:00 UTC 1 Jan 1970), where
possible, rather than relative timestamps (e.g. flowStartSysUpTime,
flowStartDeltaMicroseconds), which are specified relative to protocol
structures such as system initialization or message export time.</t>
<t>The latter are difficult to manage for two reasons. First, they require
constant translation, as the system initialization time of an intermediate
system and the export time of an intermediate message will change across
mediation operations. Further, relative timestamps introduce range problems.
For example, when using the flowStartDeltaMicroseconds and
flowEndDeltaMicroseconds Information Elements [IANA-IPFIX], the Data Record
must be exported within a maximum of 71 minutes after its creation.
Otherwise, the 32-bit counter would not be sufficient to contain the flow
start time offset. Those time constraints might be incompatible with some of
the Intermediate Processes: Intermediate Aggregation Process (temporal) and
Intermediate Correlation Process, for example.</t>
<t>When an Intermediate Aggregation Process aggregates information from
different Flow Records, the typical reporting times SHOULD be the minimum of
the start times and the maximum of the end times. However, if the Flow
Records do not overlap, i.e. if there is a time gap between the times in the
Flow Records, then the report may be inaccurate. The IPFIX Mediator is only
reporting what it knows, on the basis of the information made available to
it - and there may not have been any data to observe during the gap. Then
again, if there is an overlap in timestamps, there's the potential of
double-accounting: different Observation Points may have observed the same
traffic simultaneously. Therefore, as there is not a single rule that fits
all different situations, a complete specification of the precise rules of
applying Flow Record timestamps at IPFIX Mediators is out of the scope of
this document.</t>
<t>Note that <xref target="I-D.ietf-ipfix-a9n"/> provides additional
specifications for handling of timestamps at an Intermediate Aggregation
Process.</t>
<t>[EDITOR'S NOTE: What about temporal re-ordering? How should a mediator
deal with out-of-order data coming from multiple devices? It can't expect
all received data to be in time order.]</t>
</section>
<section title="Transport Considerations">
<t>SCTP <xref target="RFC4960"/> using the PR-SCTP extension specified in
<xref target="RFC3758"/> MUST be implemented by all compliant IPFIX Mediator
implementations. TCP <xref target="RFC0793"/> MAY also be implemented by
IPFIX Mediator compliant implementations. UDP <xref target="RFC0768"/> MAY
also be implemented by compliant IPFIX Mediator implementations.
Transport-specific considerations for IPFIX Exporters as specified in
sections 8.3, 8.4, 9.1, 9.2, and 10 of <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/> apply to IPFIX Mediators as
well.</t>
<t>PR-SCTP SHOULD be used in deployments where IPFIX Mediators and
Collectors are communicating over links that are susceptible to congestion.
PR-SCTP is capable of providing any required degree of reliability. TCP MAY
be used in deployments where IPFIX Mediators and Collectors communicate over
links that are susceptible to congestion, but PR-SCTP is preferred due to
its ability to limit back pressure on Exporters and its message versus
stream orientation. UDP MAY be used, although it is not a congestion-aware
protocol. However, in this case, the IPFIX traffic between IPFIX Mediator
and Collector MUST run in an environment where IPFIX traffic has been
provisioned for, or is contained through some other means.</t>
</section>
<section title="Collecting Process Considerations">
<t>Any Collecting Process compliant with <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/> can receive IPFIX Messages from
an IPFIX Mediator. If the IPFIX Mediator uses <xref target="RFC6313">IPFIX
Structured Data</xref> to export Original Exporter Information as in <xref
target="sec-oop"/>, the Collecting Process MUST support <xref
target="RFC6313"/>.</t>
</section>
<section title="Specific Reporting Requirements">
<t>[EDITOR'S NOTE: edit this section for self-consistency.]</t>
<t>There is no need for a specific Options Template for the IPFIX Mediator;
instead, each Intermediate Process type requires some particular metadata.
For example, a specification of IPFIX flow Anonymization including an
Options Template for the export of metadata about Anonymized flows is
described in <xref target="RFC6235"/>; when Anonymizing Flows Records, IPFIX
Mediators SHOULD add the Options Template specified therein to annotate the
exported data.</t>
<t>Some specific Options Templates and Options Template Records are provided
by the IPFIX Protocol <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/> to
report extra information about the Flow Records and about the Metering
Process; these should be used by Exporting Processes at Mediators as well,
as described in the subsectiond below.</t>
<section title="Protocol Statistics Options Templates">
<t>The "Metering Process Statistics Options Template", "The Metering
Process Reliability Statistics Options Template", and "The Exporting
Process Reliability Statistics Options Template", as specified in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, SHOULD be implemented on
the IPFIX Mediator.</t>
<t>Refer to the document specifying a particular Intermediate Process type
for specific values for these Options Template Records. For example, in
case of an Intermediate Aggregation Process, <xref
target="I-D.ietf-ipfix-a9n"/> specifies which values to insert into the
fields of "Metering Process Statistics Options Template", "The Metering
Process Reliability Statistics Options Template", and "The Exporting
Process Reliability Statistics Options Template" [EDITOR'S NOTE: no it
doesn't, should it? consider removing this paragraph]</t>
<t>[EDITOR'S NOTE: Comment to solve Rahul Patel's issue: That makes sense in the MEDPROTO
(http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-00) We
would need to take as a basis the "The Metering Process Reliability
Statistics Options Template" from
http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-00#page-26,
which solves already one issue compared to RC5101, by inserting the
"meteringProcessId". See Benoit's comments in UPPER CASE: ]</t>
<list style='hanging'>
<t hangText="(scope) observationDomainId "> An identifier of an
Observation Domain that is locally unique to the Exporting Process.
This Information Element MUST be defined as a Scope Field.</t>
<t hangText="(scope) meteringProcessId "> The identifier of the
Metering Process for which lack of reliability is reported. This
Information Element MUST be defined as a Scope Field. => NEED
IAPPROCESSID</t>
<t hangText="ignoredPacketTotalCount "> The total number of IP packets
that the Metering Process did not process. => NEED SOMETHING SUCH AS
IGNOREDFLOW..</t>
<t hangText="ignoredOctetTotalCount "> The total number of octets in
observed IP packets that the Metering Process did not process. => DON'T
NEED THIS ONE</t>
<t hangText="time first packet ignored "> The timestamp of the first IP
packet that was ignored by the Metering Process. For this timestamp,
any of the following timestamp can be used: observationTimeSeconds,
observationTimeMilliseconds, observationTimeMicroseconds, or
observationTimeNanoseconds. => THIS RELATES TO THE FLOW, BUT THE IE
MIGHT BE THE SAME</t>
<t hangText="time last packet ignored "> The timestamp of the last IP
packet that was ignored by the Metering Process. For this timestamp,
any of the following timestamp can be used: observationTimeSeconds,
observationTimeMilliseconds, observationTimeMicroseconds, or
observationTimeNanoseconds. => THIS RELATES TO THE FLOW, BUT THE IE
MIGHT BE THE SAME</t>
</list>
</section>
<section title="Flow Key Options Template">
<t>The Flow Keys Option Template specifies the structure of a Data Record
for reporting the Flow Keys of reported Flows. A Flow Keys Data Record
extends a particular Template Record that is referenced by its templateId
identifier. The Template Record is extended by specifying which of the
Information Elements contained in the corresponding Data Records describe
Flow properties that serve as Flow Keys of the reported Flow. This Options
Template is defined in section 4.4 of <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, and SHOULD be used by
Mediators for export as defined there.</t>
<t>When an Intermediate Process exports Data Records containing different
Flow Keys from those received from the Original Exporter, and the Original
Exporter sent a Flow Keys Options record to the Mediator, the Mediator
MUST export a Flow Keys Options record defining the the new set of Flow
Keys.</t>
</section>
</section>
<section title="Configuration Management">
<t>In general, using Mediators to combine information from multiple Original
Exporters requires a consistent configuration of the Metering Processes
behind these Original Exporters. The details of this consistency are
specific to each Intermediate Process. Consistency of configuration should
be verified out of band, with the MIB modules (<xref
target="I-D.ietf-ipfix-rfc5815bis"/> and <xref
target="I-D.ietf-ipfix-psamp-mib"/>) or with the Configuration Data Model
for IPFIX and PSAMP <xref target="I-D.ietf-ipfix-configuration-model"/></t>
</section>
<section title="Security Considerations">
<t>As they act as both IPFIX Collecting Processes and Exporting Processes,
the Security Considerations for IPFIX Protocol <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/> also apply to Mediators. The
Security Considerations for IPFIX Files <xref target="RFC5655"/> also apply
to IPFIX Mediators that write IPFIX Files or use them for internal storage.
However, there are a few specific considerations that IPFIX Mediator
implementations must also take into account.</t>
<t>By design, IPFIX Mediators are "men-in-the-middle": they intercede in the
communication between an Original Exporter (or another upstream Mediator)
and a downstream Collecting Process. This has two important implications for
the level of confidentiality provided across an IPFIX Mediator, and the
ability to protect data integrity and Original Exporter authenticity across
a Mediator. These are addressed in more detail in the Security
Considerations for Mediators in <xref target="RFC6183"/>.</t>
<t>Note that, while Mediators can use the exporterCertificate and
collectorCertificate Information Elements defined in <xref
target="RFC5655"/> as described in section 9.3 of <xref target="RFC6183"/>
to export information about X.509 identities in upstream TLS-protected
Transport Sessions, this mechanism cannot be used to provide true end-to-end
assertions about a chain of IPFIX Mediators: any Mediator in the chain can
simply falsify the information about upstream Transport Sessions In
situations where information about the chain of mediation is important, it
must be determined out of band.</t>
</section>
<section title="IANA Considerations">
<t>This document specifies three new IPFIX Information Elements,
originalExporterIPv4Address in <xref target="ie-oe4"/>,
originalExporterIPv6Address in <xref target="ie-oe6"/>, and
originalObservationDomainId in <xref target="ie-ood"/>, to be added to the
<xref target="iana-ipfix-assignments">IPFIX Information Element
registry</xref>. [IANA NOTE: please add the three Information Elements as
specified in the references subsections, and change TBD1, TBD2, and TBD3 in
this document to reflect the assigned identifiers.]</t>
</section>
<section title="Acknowledgments">
<t>We would like to thank the IPFIX contributors, and specifically Paul
Aitken for his thorough review. This work is materially supported by the
European Union Seventh Framework Programme under grant agreement 257315
(DEMONS).</t>
</section>
<!-- <section title="Word content">
3. Specifications
This section describes the IPFIX specifications for Mediation: more specifically, specifications for generic Intermediate Processes. Possible specific Intermediate Processes are: Intermediate Conversion Process, Intermediate Aggregation Process, Intermediate Correlation Process, Intermediate Selection Process, Intermediate Anonymization Process.
For a specific Intermediate Process, the specifications in the following references MUST be followed, on top of the specifications in this document:
- For the Intermediate Aggregation Process, the specifications in <xref target="I-D.ietf-ipfix-a9n"/> MUST be followed.
- For the Intermediate Selection Process, the specifications in <xref target="I-D.ietf-ipfix-flow-selection-tech"/> MUST be followed.
- For the Intermediate Anonymization Process, the specifications in <xref target="RFC6235"/> should be considered as guidelines as <xref target="RFC6235"/> is an experimental RFC.
Note that no specific document deals with the Intermediate Conversion Process at the time of this publication.
These new specifications, which are more specific compared than <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, are described with the key words described in <xref target="RFC2119"/>.
</section> -->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-ipfix-protocol-rfc5101bis" ?>
<?rfc include="reference.I-D.ietf-ipfix-information-model-rfc5102bis" ?>
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3758" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5655" ?>
<?rfc include="reference.RFC.6313" ?>
<?rfc include="reference.I-D.ietf-ipfix-flow-selection-tech" ?>
<?rfc include="reference.I-D.ietf-ipfix-a9n" ?>
<?rfc include="reference.I-D.ietf-ipfix-psamp-mib" ?>
<?rfc include="reference.I-D.ietf-ipfix-configuration-model" ?>
<?rfc include="reference.I-D.ietf-ipfix-rfc5815bis" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3917" ?>
<?rfc include="reference.RFC.3954" ?>
<?rfc include="reference.RFC.5470" ?>
<?rfc include="reference.RFC.5472" ?>
<?rfc include="reference.RFC.5476" ?>
<?rfc include="reference.RFC.5982" ?>
<?rfc include="reference.RFC.6183" ?>
<?rfc include="reference.RFC.6235" ?>
<reference anchor='iana-ipfix-assignments'>
<front>
<title>IP Flow Information Export Information Elements (http://www.iana.org/assignments/ipfix/ipfix.xml)</title>
<author surname="Internet Assigned Numbers Authority"/>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:19:17 |