One document matched: draft-boschi-ipfix-implementation-guidelines-00.txt
Internet Draft E. Boschi
draft-boschi-ipfix-implementation-guidelines-00.txt Hitachi Europe
Expires: April 2006 L. Mark
Fraunhofer FOKUS
J. Quittek
NEC Europe Ltd.
M. Stiemerling
NEC Europe Ltd.
October 2005
IPFIX Implementation Guidelines
draft-boschi-ipfix-implementation-guidelines-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 1]
IPFIX implementation guidelines October 2005
Abstract
The IP Flow Information eXport (IPFIX) protocol defines how IP
Flow information can be exported from routers, measurement
probes or other devices. This document provides guidelines for
the implementation and use of the IPFIX protocol. A set of these
guidelines refers to the implementation on middleboxes, such as
firewalls, network address translators, tunnel endpoints, packet
classifiers, etc.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 2]
IPFIX implementation guidelines October 2005
Table of Contents
1. Introduction...........................................3
2. Terminology............................................4
3. Implementation Guidelines..............................4
3.1 IPFIX Message Format...................................4
3.1.1 Set Format............................................4
3.1.2 Template Format.......................................5
3.2 Padding................................................6
3.3 IPFIX Message Header Export Time and Data Record Time..6
3.4 Template Management....................................6
3.5 The Collecting Process's side..........................6
3.6 Transport Protocol.....................................7
3.6.1 SCTP..................................................7
3.6.2 UDP...................................................7
3.7 Extensions.............................................7
4. Guidelines for implementation on Middleboxes...........8
4.1 Traffic Flow Scenarios at Middleboxes..................9
4.2 Location of the Observation Point.....................10
4.3 Reporting Flow-related Middlebox Internals............11
4.3.1 Packet Dropping Middleboxes..........................12
4.3.2 Middleboxes Changing the DSCP........................12
4.3.3 Middleboxes Changing IP Addresses and Port Numbers...13
4.3.4 Tunnel Endpoints ....................................14
5. Implementation mistakes...............................14
5.1 IPFIX and Netflow v9..................................14
5.2 Padding of the data set...............................15
5.3 Field ID Numbers......................................15
5.4 Template ID Numbers...................................15
6. Open issues...........................................15
6.1 Enterprise specific IEs types.........................15
7. Security Considerations...............................16
8. Code availability.....................................16
9. Normative References..................................17
10. Informative References................................17
11. Acknowledgements......................................17
12. Author's Addresses....................................18
13. Intellectual Property Statement.......................18
14. Copyright Statement...................................19
15. Disclaimer............................................19
1. Introduction
The IPFIX protocol defines how IP Flow information can be
exported from routers, measurement probes or other devices. In
this document, we provide guidelines for its implementation,
highlighting at the same time open issues, and unclear
definitions.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 3]
IPFIX implementation guidelines October 2005
We also provide some guidelines for the implementation on
middleboxes. Middlebox functions potentially change properties
of traffic flows passing the box, for example, NATs change
addresses in header fields and firewalls change the numbers of
packets and bytes belonging to a traffic flow. An IPFIX
implementation on a middlebox should reflect this by the way it
selects and reports the observation point and by the way it
measures and reports traffic flows.
2. Terminology
The terminology used in this document is fully aligned with the
terminology defined in [IPFIX-PROTO].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119.
3. Implementation Guidelines
3.1 IPFIX Message Format
An IPFIX message consists of a Message Header and one or more
Template, Option Template, or Data Sets.
3.1.1 Set Format
A Set is a collection of records of the same type. Template
Sets, Option Template Sets, and Data Sets contain records of the
same type, respectively template records, option template
records, and data records.
A Set is identified by a Set ID. A Set ID has an integral data
type and its value is in the range of 2 - 65535. A value of 2
identifies a Template Set. A value of 3 identifies an Option
Template Set. All other values from 4 to 255 are reserved for
future use. Values above 255 are used for Data Sets. In this
case the SetID correspond to the TemplateID of the used
template. The Set ID values of 0 and 1 are not used for
historical reasons [RFC3954].
A Set with a reserved or unknown or unused (value of 0 or 1) Set
ID SHOULD be ignored.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 4]
IPFIX implementation guidelines October 2005
3.1.2 Template Format
IPFIX is template based. Templates define the structure of data
to be exported, describing data fields together with their type
and meaning. Therefore, the exporter can export all kind of data
records composed of information elements from [IPFIX-INFO] or
vendor specific information elements. This offers a great
flexibility to the exporter.
[IPFIX-PROTO] and [IPFIX-INFO| define the IPFIX protocol and
information elements which can be exported using the protocol.
There are no hints how to compose a template or pre-defined
templates for the most common use cases. The absence of common
templates complicates the interworking of applications using
IPFIX even if the application can communicate at the protocol
level.
3.1.2.1 Multiple IE of same field type
Exporters and collectors SHOULD support the use of multiple
IEs of the same field type for scope elements.
Exporters SHOULD avoid the use of templates containing multiple
non-scope IEs of the same field type. Collectors not capable of
handling multiple non-scope IEs of the same field type should
log a warning and MAY accept the IEs using a first match
semantic.
3.1.2.2 Order of IEs within the template
Although it is not explicitly mentioned in the protocol draft
the order of IEs within the template SHOULD NOT be changed by
exporting or collecting processes.
3.1.2.3 Coding of IEs of unknown type
The exporting process SHOULD NOT export Information Elements of
unknown type.
The collecting process MAY accept templates with Information
Elements of unknown types. In this case these data should be
decoded as an octet array.
Alternatively the collecting process MAY ignore templates and
subsequent data sets that contain Information Elements of
unknown types.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 5]
IPFIX implementation guidelines October 2005
3.1.2.4 Using Scopes
The default scope for exported IPFIX data is the observation
domain. One can further limit the scope via option records.
3.2 Padding
[TODO]
3.3 IPFIX Message Header Export Time and Data Record Time
This section contains recommendations on when to use this method
and when not. Additionally, some general comments how to use
timestamps in data records are provided.
Section 5 of the [IPFIX-PROTO] defines a method for an optimized
export of time related information elements.
[IPFIX-ARCH] distinguishes the Metering Process and the
Exporting Process. The problem is that the Metering Process does
not know when the IPFIX-Message leaves the exporter. This
implies that the metering process has to store timestamp
information i.e. in a 64 bit memory cell and has to provide the
exporting process with these 64 bit data, while the exporting
process hat to convert these data e.g. to a 32 bit offset value.
3.4 Template Management
The exporter has to take care that the templates are sent prior
to the related data records. For SCTP and TCP the templates have
to be resent on a connection reestablishment. For UDP templates
have to be resent after a configured timeout. In either case
this requires the exporting process to store all active template
definitions.
3.5 The Collecting Process's side
The IPFIX collector has to maintain a list of sources and per
source a list of templates to decode incoming data templates.
Because of the template feature of IPFIX the collector does not
need any knowledge of the transferred data. All information
needed to decode all kind of data is transferred via template
records.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 6]
IPFIX implementation guidelines October 2005
3.6 Transport Protocol
IPFIX messages can be transferred using SCTP, TCP or UDP as
bearer protocol. An IPFIX implementation MUST support SCTP-PR
whereas support for TCP and UDP is optional.
3.6.1 SCTP
Preference to SCTP-PR was given because it is congestion-aware
and reduces bandwidth in case of congestion but still has a much
simpler state machine than TCP. This saves resources on
lightweight probes and router line cards.
As October 2005, there is no major operating system with full
support for SCTP-PR (at least the authors are not aware of one).
So at present an application has to use TCP to enable the export
over ipv6 networks. One option to test the SCTP code is to use
Linux with kernel 2.6 that has support for SCTP-PR over IPv4.
3.6.2 UDP
UDP is not a reliable transport protocol, and therefore IPFIX
messages sent using UDP might be lost. [IPFIX-PROTO] specifies
that templates sent from the Exporting Process to the Collecting
Process using UDP MUST be resent at regular intervals. The
frequency of template transmission MUST be configurable.
The protocol allows resending templates depending on the number
of packets sent.
The resend time shouldn't be lower than 10 seconds or bigger
than one hour.
3.7 Extensions
New Information Elements can be added to the protocol in two
different ways:
- If the IEs are considered of general interest they could
be added to the group of IETF specified IEs and extend the
current IPFIX Information Model. The list of IETF specified
IEs is going to be administered by IANA, after being
administered for an initial period by the IPFIX WG. The
introduction of new IE in the IANA registry is subjected to
expert review. Those experts will initially be drawn from
the Working Group Chairs and document editors of the IPFIX
and PSAMP Working Groups (cf. [IPFIX-INFO]).
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 7]
IPFIX implementation guidelines October 2005
[IPFIX-INFO] defines an XML schema, which may be used to
create consistent machine-readable extensions to the IPFIX
information model.
- A faster way of introducing new IEs or the way for
vendors to integrate proprietary IEs in IPFIX is by using
Enterprise IEs (cf. [IPFIX-PROTO]).
Developers having no enterprise ID, or waiting for IANA to
assign new IDs can temporary use IDs from 10000-11000. These
numbers are reserved for developers and are not assigned by
IANA. [This is just a proposal. Maybe we can discuss this on the
ipfix mailing list]
The [IPFIX-INFO] document contains an XML-based specification of
template, abstract data types and IPFIX Information Elements.
This formal description can be used for automatically checking
syntactical correctness of the specification of IPFIX IEs or for
generating code that deals with processing IPFIX IEs.
4. Guidelines for implementation on Middleboxes
The term middlebox is defined in RFC 3234 [RFC3234] by:
"A middlebox is defined as any intermediary device performing
functions other than the normal, standard functions of an IP
router on the datagram path between a source host and
destination host."
The list of middleboxes discussed in RFC 3234 contains:
1. NAT,
2. NAT-PT,
3. SOCKS gateway,
4. IP tunnel endpoints,
5. packet classifiers, markers, schedulers,
6. transport relay,
7. TCP performance enhancing proxies,
8. load balancers that divert/munge packets,
9. IP firewalls,
10. application firewalls,
11. application-level gateways,
12. gatekeepers / session control boxes,
13. transcoders,
14. proxies,
15. caches,
16. modified DNS servers,
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 8]
IPFIX implementation guidelines October 2005
17. content and applications distribution boxes,
18. load balancers that divert/munge URLs,
19. application-level interceptors,
20. application-level multicast,
21. involuntary packet redirection,
22. anonymizers.
It is likely that since the publication of RFC 3234 new kinds of
middleboxes have been added.
4.1 Traffic Flow Scenarios at Middleboxes
Middleboxes may delay, re-order, drop, or multiply packets, they
may change packet header fields and change the payload. All
these action have an impact on traffic flow properties.
In general, a middlebox transforms a uni-directional original
traffic flow T that arrives at the middlebox into a transformed
traffic flow T' that leaves the middlebox.
+-----------+
T ---->| middlebox |----> T'
+-----------+
Figure 1: Uni-directional traffic flow traversing a middlebox
Note that in an extreme case, T' may be an empty traffic flow (a
flow with no packets), for example, if the middlebox is a
firewall and blocks the flow.
In case of a middlebox performing a multicast function, a single
original traffic flow may be transformed into a more than one
transformed traffic flow.
+------> T'
|
+---------+-+
T ---->| middlebox |----> T''
+---------+-+
|
+------> T'''
Figure 2:Uni-directional traffic flow traversing a middlebox
with multicast function
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 9]
IPFIX implementation guidelines October 2005
For bi-directional traffic flows we can not identify original
and transformed traffic flow, we can just identify flows on
different sides of the middlebox, say T_l on the left side and
T_r on the right side.
+-----------+
T_l <--->| middlebox |<---> T_r
+-----------+
Figure 3: Bi-directional unicast traffic flow traversing a
middlebox
In case of a NAT T_l might be a traffic flow in a private
address realm and T_r the translated traffic flow in the public
address realm. If the middlebox is a NAT-PT, then T_l may be an
IPv4 traffic flow and T_r the translated IPv6 traffic flow.
At tunnel endpoints, flows are multiplexed or de-multiplexed. In
general, tunnel endpoints can deal with bi-directional traffic
flows.
+------> T_r1
v
+---------+-+
T_l <--->| middlebox |<---> T_r2
+---------+-+
^
+------> T_r3
Figure 4:Bi-directional traffic flow traversing a tunnel
endpoint
An example is a traffic flow T_l of a tunnel and flows T_rx that
are multipled into or de-multiplexed out of a tunnel.
According to the IPFIX definiton of traffic flows in [IPFIX-PR]
T and T' or T_l and T_ri, respectively, are different flows in
general.
However, from an application point of view, they might be
considered as closely related or even as the same flow, for
example if the payloads they carry are identical.
4.2 Location of the Observation Point
Middleboxes might be integrated with other devices. An example
is a router with a NAT or a firewall at a line card. If an IPFIX
observation point is located at the line card, then the measured
properties of measured traffic flows may depend on the side of
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 10]
IPFIX implementation guidelines October 2005
the integrated middlebox at which packets were captured for
traffic flow measurement.
Consequently, an exporting process reporting traffic flows
measured at a device that hosts one or more middleboxes MUST
clearly indicate to collecting processes the location of the
used observation point(s) with respect to the middlebox(es).
Otherwise, processing the measured flow data could lead to wrong
results.
At the first glance, choosing an observation point that covers
the entire middlebox looks like an attractive choice for the
location of the observation point. But this leads to
ambiguities for all kinds of middleboxes. Within the middlebox
properties of packets are modified and it MUST be clear at a
collecting process whether packets were observed and measured
before or after modification. For example, it must be clear
whether a reported source IP address was observed before or
after a NAT changed it or whether a reported packet count was
measured before or after a firewall dropped packets.
Only in case of composed middleboxes with well defined and well
separated internal middlebox functions, for example a combined
NAT and firewall, an observation point MAY be inside a
middlebox, but in any case it MUST be located in between the
middlebox functions.
4.3 Reporting Flow-related Middlebox Internals
While this document requests IPFIX implementations using
observations points outside of middlebox functions, there are
cases, where reporting flow-related internals of a middlebox is
of interest.
For many application that use traffic measurement results it is
desirable to get more information than can be derived from just
observing packets on one side of a middlebox. If, for example,
packets are dropped by the middlebox acting as firewall, NAT or
traffic shaper, then information about how many packets of the
observed packets are dropped may be of high interest.
This section gives recommendations on middlebox internal
information that SHOULD or MAY be reported if the IPFIX
observation point is co-located with one or more middleboxes.
Since the internal information to be reported depends on the
kind of middlebox, it is discussed per kind.
The recommendations cover middleboxes that act per packet and
that do not modify the application level payload of the packet
(except by dropping the entire packet) and that do not insert
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 11]
IPFIX implementation guidelines October 2005
additional packets into an application level or transport level
traffic stream.
Covered are the packet level middleboxes of kind 1 - 6, 8 - 10,
21, and 22 (according to the enumeration given at the beginning
of section 4). Not covered are 7 and 11 - 20. TCP performance
enhancing proxies (7) are not covered because they may add ACK
packets to a TCP connection.
Still, if possible, IPFIX implementation co-located with not
covered middleboxes MAY follow the recommendations given in this
section if they can be applied in a way that reflects the
intention of the recommendations.
4.3.1 Packet Dropping Middleboxes
If an IPFIX observation point is co-located with one or more
middleboxes that potentially drop packets, then the
corresponding IPFIX exporter SHOULD be able to report the number
of packets that were dropped per reported flow.
Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS
gateway (3), packet schedulers (5), IP firewalls (9) and
application level firewalls (10).
4.3.2 Middleboxes Changing the DSCP
If an IPFIX observation point is co-located with one or more
middleboxes that potentially modify the DiffServ Code Point
(DSCP, see [RFC2474]) in the IP header, then the corresponding
IPFIX exporter SHOULD be able to report besides the observed
value of the DSCP also the value of the DSCP on the 'other' side
of the middlebox (if this is a constant value for the particular
traffic flow).
Note that the 'other' side of the middlebox can be before or
after changing the DSCP value depending on the location of the
middlebox. Note also that a classifier may change the same DSCP
value of packets from the same flow to different values
depending on the packet or other conditions. Also it is
possible that packets of a single uni-directional arriving flow
contain packets with different DSCP values that are all set to
the same value by the middlebox. In both cases there is a
constant value for the DSCP field in the IP packets header to be
observed on one side of the middlebox, but on the other side the
value may vary. In such a case reliable reporting of the DSCP
value on the 'other' side of the middlebox is not possible by
just reporting a single value.
This recommendation concerns packet markers (5).
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 12]
IPFIX implementation guidelines October 2005
4.3.3 Middleboxes Changing IP Addresses and Port Numbers
If an IPFIX observation point is co-located with one or more
middleboxes that potentially modify the
- IP version field,
- IP source address header field,
- IP destination header field,
- TCP source port number,
- TCP destination port number,
- UDP source port number and/or
- UDP destination port number
in one of the headers, then the corresponding IPFIX exporter
SHOULD be able to report besides the observed value of the
particular header fields also the 'translated' value of these
fields, as far as they have constant values for the particular
traffic flow.
Note that the 'translated' values of the fields can be the
fields values before or after the translation depending on the
flow direction and the location of the observation point with
respect to the middlebox. We always call the value that is not
the one observed at the observation point the translated value.
This paragraph needs to be adapted from DSCP to addresses and
port numbers: Note also that a classifier may change the same
DSCP value of packets from the same flow to different values
depending on the packet or other conditions. Also it is
possible that packets of a single uni-directional arriving flow
contain packets with different DSCP values that are all set to
the same value by the middlebox. In both cases there is a
constant value for the DSCP field in the IP packets header to be
observed on one side of the middlebox, but on the other side the
value may vary. In such a case reliable reporting of the DSCP
value on the 'other' side of the middlebox is not possible by
just reporting a single value.
Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS
gateway (3) and involuntary packet redirection (21).
This recommendation MAY also be applied to anonymizers (21), but
it should be noted that this includes the risk of loosing the
effect of anonymisation.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 13]
IPFIX implementation guidelines October 2005
4.3.4 Tunnel Endpoints
If an IPFIX observation point is co-located with one or more
tunnel endpoints such that it observes packets that will be
multiplexed into a tunnel or that have been de-multiplexed out
of a tunnel, then the corresponding IPFIX exporter SHOULD be
able to report the corresponding tunnel ID.
5. Implementation mistakes
It seems useful to list a few things that were clear in the
document and not needing clarification that some implementers
didn't do correctly. All of these things caused or may cause
interoperability problems.
5.1 IPFIX and Netflow v9
A large group of mistakes stems from the fact that many
implementers started implementing IPFIX from an existing version
of Netflow v9. Despite their similarity, the two protocols
differ in many aspects. We list here some of the most important
differences.
- Transport protocol: Netflowv9 runs over UDP while IPFIX
must be reliable and has SCTP as its mandatory protocol,
while TCP and UDP are optional
- IPFIX differentiates between IETF and non-IETF defined
fields. Non-IETF Information Elements can be specified by
coupling the non IETF IE identifier with an Enterprise ID
(corresponding to the vendor that defined the IE).
- Option templates: in IPFIX an option template must have a
scope, the scope is not allowed to be of length zero. This
is not the case in Netflow v9.
Message header:
- Length field: in Netflow v9 this field (called count)
contains the number of records, in IPFIX indicates the
total length of the IPFIX message, measured in Octets
(including message header and Set(s))
- Timestamp: Netflow v9 has an additional timestamp:
Sysuptime. It indicates the time in milliseconds since the
last reboot of the exporter
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 14]
IPFIX implementation guidelines October 2005
5.2 Padding of the data set
In [IPFIX-PROTO] it is specified that he exporting process MAY
insert some padding octets to align IEs within a data record.
The padding length MUST be anyway shorter than any allowable
record in that set.
It is important to respect this limitation: if the padding
length is equal or longer that the length of the shorter record,
it will be interpreted as another record.
5.3 Field ID Numbers
If the Information Element identifier in the data record has a
value such that the first bit is "1", the collector interprets
the fields following the length fields as enterprise number.
There is no way to tell that this is wrong, if it wasn't meant
as enterprise data record.
5.4 Template ID Numbers
Template IDs are generated on demand by the exporting process.
When exporting the same template at different times or using the
same template multiple times simultaneously different template
IDs are generated. So the collecting process does not know in
advance which template id a special template will get.
6. Open issues
6.1 Enterprise specific IEs types
When receiving information elements from vendors the following
information is directly available to the collector:
- the vendor specific IE identifier
- its length
- the enterprise ID.
While enterprise IDs are publicly available and is therefore
straightforward to identify the enterprise, how to obtain the
type of the given information element requires some
clarification.
Open Issue:
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 15]
IPFIX implementation guidelines October 2005
How to provide this information to the collector? Which general
mechanism(s) should be used?
One first solution could be to make it available on the web via
some automatable external lookup (e.g. XDS).
Another solution would be to send the enterprise specific
information element description with the data stream, in an
option record.
7. Security Considerations
This document describes the implementation of IPFIX. The
security requirements for the IPFIX target applications are
addressed in the IPFIX requirements draft. These requirements
must be considered for the specification of the IPFIX protocol.
Section 4.3 recommends that IPFIX exporting processes report
internals about middleboxes. These internals may be security-
relevant and the reported information needs to be protected
appropriately for reasons given below.
Reporting the packets dropped by firewalls and other packet
dropping middleboxes imply the risk that this information is
used by attackers for analyzing the configuration of the packet
dropper and for developing attacks that pass the middlebox.
Address translation may be used for hiding the network structure
behind an address translator. If an IPFIX exporting process
reports the translations performed by an address tranlator, then
parts of the network structure may get uncovered.
If an IPFIX exporting process reports the translations performed
by an anonymizer, the main function of the anonymizer might get
lost.
Also information about which packet enters of leaves which
tunnel may need protection.
8. Code availability
This section provides links where to gather IPFIX
implementations (or code related to IPFIX) that have been made
freely available by their implementers.
Link: http://libipfix.sourceforge.net
Organisation: Fraunhofer FOKUS
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 16]
IPFIX implementation guidelines October 2005
Description: IPFIX C library, distributed under the BSD license.
Full support for SCTP, UDP, TCP, IPv4 and IPv6 over Linux,
FreeBSD, Solaris
Link: http://www.ntop.org/
Organisation: Netikos S.p.A.
Description: distributed under the GPL2 license. Runs over Linux
9. Normative References
[RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander,
Requirements for IP Flow Information Export,
October 2004
[IPFIX-PROTO] B. Claise (Editor), IPFIX Protocol Specification,
Internet Draft <draft-ietf-ipfix-protocol-19.txt>,
work in progress, September 2005
[IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, Information Model
for IP Flow Information Export, Internet Draft
<draft-ietf-ipfix-info-11>, work in progress,
September 2005
[RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", RFC
2474, December 1998.
10. Informative References
[IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek:
Architecture for IP Flow Information Export,
Internet Draft < draft-ietf-ipfix-architecture-
09.txt>, work in progress, August 2005
[RFC3415] B. Carpenter, and S. Brim, "Middleboxes: Taxonomy
and Issues", RFC 3234, February 2002.
11. Acknowledgements
We would like to thank the MoMe project for organising the IPFIX
Interoperability Event in July 2005 that provided us precious
input for this draft.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 17]
IPFIX implementation guidelines October 2005
12. Author's Addresses
Elisa Boschi
Hitachi Europe SAS
Immeuble Le Theleme,
1503 Route des Dolines
o6560 Valbonne, France
Phone: +33 4 89874180
Email: elisa.boschi@hitachi-eu.com
Lutz Mark
Fraunhofer Institute for Open Communication Systems (FOKUS)
Kaiserin-Augusta-Allee 31
10589 Berlin, Germany
Phone: +49 30 3463 7306
Email: mark@fokus.fraunhofer.de
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg, Germany
Phone: +49 6221 90511-15
EMail: quittek@netlab.nec.de
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg, Germany
Phone: +49 6221 90511-13
Email: stiemerling@netlab.nec.de
13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any
license under such rights might or might not be available; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and
BCP 79.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 18]
IPFIX implementation guidelines October 2005
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
14. Copyright Statement
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
15. Disclaimer
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:45 |