Before IPFIX was a protocol, it was a problem statement. RFC 3917 is the requirements document the IETF wrote to answer a very practical question: Cisco's NetFlow is everywhere, but it's proprietary and version-locked; what would a real standard for flow export need to do? The answer became the IPFIX protocol (RFC 7011, based heavily on NetFlow v9), which today ships in virtually every serious router, switch, firewall, and flow collector — including the ntopng deployment on your network.

A flow, in the RFC's definition, is a set of IP packets passing an observation point during a time interval that share common properties — typically the 5-tuple (src IP, dst IP, src port, dst port, protocol), but the definition is deliberately flexible. Instead of shipping every packet header to a collector (expensive, invasive), an exporter aggregates packets into flow records and sends summaries. This is the trick that makes multi-gigabit visibility affordable.

The requirements themselves are worth reading because they anticipate the ways naïve implementations fail:

• Flow definition must be configurable. The 5-tuple is a default, not a mandate. The RFC insists on selecting flows by any combination of packet header fields, meta-information (interface index), and properties derived from packet treatment (MPLS label, BGP AS).
• Metering must handle high speeds via sampling. At line-rate 10G+, per-packet accounting is a fantasy. The RFC mandates both packet sampling and filtering, and — critically — requires the exporter to report the sampling parameters so collectors can extrapolate correctly. Sampled data without metadata is worse than no data.
• Congestion-aware transport. This is the requirement that killed the "just use UDP like NetFlow" answer. IPFIX is required to detect congestion and back off, which is why the protocol runs over SCTP by default (with TCP and UDP as options). NetFlow's habit of blindly UDP-flooding a collector during traffic spikes — precisely when you most need the data — was a known operational wound.
• Reliability tiers. Different flow records have different value. Billing data needs guaranteed delivery; a security investigation might tolerate loss. The requirements demand the protocol signal what was lost.
• Extensibility without renegotiation. New fields must be addable without breaking old collectors. This drove the template-based encoding: the exporter sends a template describing record structure, then sends records referencing that template. Add a field, ship a new template, done.
• Push, not pull. Explicitly a one-way exporter-to-collector protocol. No polling. This matches how routers actually operate — they can't afford to be interrogated.

Why the requirements document matters historically: RFC 3917 was the IETF's way of settling a de facto standard war. NetFlow v5 (fixed-format, UDP-only) dominated but was inflexible. NetFlow v9 introduced templates. Juniper had J-Flow, sFlow existed as a competitor from Foundry/InMon. Rather than pick a winner, the WG wrote requirements that any candidate had to meet, then IPFIX (essentially productized NetFlow v9) was chosen as the base. This is why IPFIX and NetFlow v9 records are wire-compatible in most practical respects — the standard swallowed the dominant proprietary format.

Where you meet it daily: Every DDoS mitigation service, every enterprise network monitoring tool (ntopng, Elastiflow, Kentik, Arbor), every cloud VPC flow log format traces its DNA to these requirements. When you look at a "Top Talkers" chart, you're consuming the output of a pipeline this RFC defined the shape of.