2.4.6 IP Flow Information Export (ipfix)

Last Modified: 2003-07-08

Nevil Brownlee <nevil@ccul.aukuni.ac.nz>
Dave Plonka <plonka@doit.wisc.edu>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Mailing Lists:
General Discussion: ipfix@net.doit.wisc.edu
To Subscribe: majordomo@net.doit.wisc.edu
In Body: subscribe ipfix
Archive: http://ipfx.doit.wisc.edu/list/ipfix/archive/
Description of Working Group:
There are a number of IP flow information export systems in common
use.  These systems differ significantly, even though some have
adopted a common transport mechanism; such differences make it
difficult to develop generalised flow analysis tools.  As such, there
is a need in industry and the Internet research community for IP
devices such as routers to export flow information in a standard way
to external systems such as mediation systems, accounting/billing
systems, and network management systems to facilitate services such as
Internet research, measurement, accounting, and billing.

An IP flow information export system includes a data model, which
represents the flow information, and a transport protocol.  An
"exporter," which is typically an IP router or IP traffic measurement
device, will employ the IP flow information export system to report
information about "IP flows," these being series of related IP packets
that have been either forwarded or dropped.  The reported flow
information will include both (1) those attributes derived from the IP
packet headers such as source and destination address, protocol, and
port number and (2) those attributes often known only to the exporter
such as ingress and egress ports, IP (sub)net mask, autonomous system
numbers and perhaps sub-IP-layer information.

This group will select a protocol by which IP flow information can be
transferred in a timely fashion from an "exporter" to a collection
station or stations and define an architecture which employs it.  The
protocol must run over an IETF approved congestion-aware transport
protocol such as TCP or SCTP.

Specific Goals

o Define the notion of a "standard IP flow."  The flow definition
  will be a practical one, similar to those currently in use by
  existing non-standard flow information export protocols which
  have attempted to achieve similar goals but have not documented
  their flow defintion.

o Devise data encodings that support analysis of IPv4 and IPv6
  unicast and multicast flows traversing a network element at
  packet header level and other levels of aggregation as requested
  by the network operator according to the capabilities of the
  given router implementation.

o Consider the notion of IP flow information export based upon
  packet sampling.

o Identify and address any security privacy concerns affecting
  flow data.  Determine technology for securing the flow information
  export data, e.g. TLS.

o Specify the transport mapping for carrying IP flow information,
  one which is amenable to router and instrumentation implementors,
  and to deployment.

o Ensure that the flow export system is reliable in that it will
  minimize the likelihood of flow data being lost due to resource
  constraints in the exporter or receiver and to accurately report
  such loss if it occurs.
Goals and Milestones:
Done  Submit Revised Internet-Draft on IP Flow Export Requirements
Done  Submit Internet-Draft on IP Flow Export Architecture
Done  Submit Internet-Draft on IP Flow Export Data Model
Done  Submit Internet-Draft on IPFIX Protocol Evaluation Report
Done  Submit Internet-Draft on IP Flow Export Applicability Statement
Done  Select IPFIX protocol, revise Architecture and Data Model drafts
Apr 03  Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC
Done  Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC
Aug 03  Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC
Aug 03  Submit IPFX-DATAMODEL to IESG for publication as Informational RFC
Aug 03  Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC
  • - draft-ietf-ipfix-reqs-10.txt
  • - draft-ietf-ipfix-info-01.txt
  • - draft-ietf-ipfix-arch-01.txt
  • - draft-ietf-ipfix-protocol-00.txt
  • - draft-ietf-ipfix-as-00.txt
  • No Request For Comments

    Current Meeting Report

    jfm@cablelabs.comMinutes of the IP Flow Information eXport (IPFIX) WG
    IETF 57, Vienna, Wednesday July 16, 2003
    58 people in attendance
    Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from 
    Greg Ruth.
    The meeting agenda and slides are available here:
    [please see the agenda slides there for the sequence of topics: 
    Juergen Quittek presented the requirements draft 
    "draft-ietf-ipfix-reqs-10.txt" and differences from -09 to -10.
    [see slides for details: 
    The draft says that confidentiality SHOULD be implemented and that 
    anonymization MAY be.  Current practice by the flow-export user 
    community does not depend upon these features, hence the meeting's 
    consensus was that the IPFIX requirements draft does not require them to be 
    We discussed Allison Mankin's (Transport Area Director) suggestion that 
    IPFIX make confidentiality and anonymization to both be REQUIRED (MUST).  
    One participant noted that export restrictions (of encryption 
    technology) might restrict the distribution of such an 
    The few issues remaining will be discussed on the mailing list to 
    produce the next revision in August.  [If the changes continue to be minor 
    edits, it will not require another WG last call.]
    Simon Leinen presented the changes to the individual draft 
    "draft-leinen-ipfix-eval-contrib-01.txt" and differences from -00 to -01.
    [see slides for details: 
    His suggestion was that we accept this a Working Group document, go to WG 
    last call soon, and submit it with a request to publish it as an 
    Information RFC.
    This proposal met with agreement amongst those in attendence.
    [This would not be submitted until the requirements draft is 
    resubmitted to IESG]
    Status of the four new WG drafts was reported by their respective 
     * Tanja Zseby presented the Applicability Statement draft.
       This is now a working group draft, based on her previous 
    individual draft.
       [see slides for details: 
       Reinaldo Penno presented the sub-topic of middleboxes.
       [see slides for details: 
       We discussed where this middlebox-related content should reside. It was 
    suggested that perhaps it should be in a seperate draft. The chairs 
    suggested that a "few [middlebox-related] paragraphs" should then be added to 
    the architecture draft and that the seperate draft be initiated as the 
    effort of an individual (to limit the amount of new work by the WG).  A hum 
    showed support for this.
       Juergen Quittek offered to write an individual draft.
     * Ganesh Sadasivan presented the Architecture draft:
       [see slides for details: 
       Ganesh noted that the flow definition was modified to include 
    encapsulated IP packets.  It was undecided as to whether this was an 
    improvement; discussion should continue in the mailing list.
       It was mentioned that the Denial-of-Service section regarding 
    "network under attack" is unclear.  It is perhaps just one case which 
    might invoke overload behavior.  This section needs to be clarified or 
       The editors asked for more review and input on this draft via the 
    mailing list.
     * Juergen Quittek presented the Information Model draft.
       [see slides for details: 
       Juergen mentioned that the the definitions named with the "ipdr" 
    prefix should change.
       XML is being used to define the information elements, which are then 
    parsed and rendered in an ASCII representation for the draft. The 
    editors have some potential improvements to this process, and the 
    audience didn't raise any objections to its use.
       The draft proposes to provide extensibility by using separate 
    namespaces for sets of vendor-specific extensions.  Such extensions would be 
    identified using IANA-defined Enterprise numbers, as was proposed in early 
    drafts of DIAMETER.  It was noted that such an approach will require a good 
    way of encoding the Enterprise numbers in IPFIX templates.
       Regarding the type space, the issue was raised about whether it should be 
    defined/duplicated within the info model draft or be defined in the Info 
    Model draft, with encodings specified in the Protocol draft.  Nevil 
    believes the latter is preferable.
     Discussion should continue.
     * Benoit Claise presented the IPFIX protocol specification draft.
       [see slides for details: 
       It is currently just the initial version; Benoit  asked that the 
    participants please review it and provide input [via the mailing list].
       Mentioned that terminology should be consistent throughout the 
       We discussed the use of "sync" packets.  Jurgen suggested that sync 
    information  should be exported in options data records. This 
    suggestion was well received.
    Three short slide-shows by folks interested in IPFIX were presented.
     * On behalf of Luca Deri (who could not attend), Nevil Brownlee 
    presenting slides on "nFlow".
       [see slides for details: 
     * Chang Kim presented a slide show about "Per-packet Recond Export 
    Proposal (pktId)".
       [see slides for details: 
     * Maurizio Molina presented a proposal to add Flow Sampling to IPFIX.
       [see slides for details: 
    The chairs reviewed the proposed various updates to WG Milestones. No 
    changes were suggested so these will be submitted as listed. [see slides for 
    $Id: minutes.txt,v 1.8 2003/08/11 14:41:54 dplonka Exp $


    IPFIX Requirements: Document Changes and New Issues Raised
    IPFIX Applicability Statement - Update -
    IPFix and Middleboxes
    IPFIX Architecture
    IPFIX Information Model
    IPFIX Protocol Draft
    Network Flow Monitoring
    Per-Packet Record Export Proposal
    Flow sampling in IPFIX: Status and suggestion for its support