Netflow is a network traffic flow reporting mechanism, originally introduced by Cisco, and adopted across the networking industry. A "flow" is typically defined as a stream of packets either entering or exiting an interface where Netflow collection is configured. A flow starts when a connection is built, and ends when a connection is torn down, or when a pre-configured length of time has passed. An important thing to note is that flow data does not include the payloads of the packets, but instead just data and metrics about the flow - source, destination, size, duration, ports, etc.
Typically flows are only tracked on the input side of an interface - ingress traffic. Some router manufacturers support egress flow monitoring, though not all, and typically it has to be turned on explicitly. A common pitfall with flow monitoring is to monitor flows ingressing on one interface, then egressing on another, so the same traffic gets counted twice. To prevent double-counting of flows it is often recommended that only ingress or egress flow monitoring be used at once. Regardless of ingress or egress, Netflow flows are uni-directional. Some proprietary standards by organizations like Cisco account for flows in a bi-directional manner, but this is not in keeping with published Netflow standards and is specific to those proprietary platforms.
Some versions of Netflow are "sampled", meaning that only one out of every n packets passing in / out of an interface is sampled. This provides a good cross-section of traffic, without imposing a large processing burden on a router that is handling a lot of flows. Netflow v5 and v9 are examples of "sampled" Netflow. In contrast Netflow v1 is non-sampled, meaning every flow is exported. Those flows are sent to a collector for storage, analysis, and display to network operators.
There are a number of supported versions and features across the Netflow ecosystem, though a few versions have become the most prominent over time and are detailed below.
Netflow v5
Netflow v5 is now considered a legacy version, originally published by Cisco, but is still very widely supported across the industry. It is only capable of handling IPv4 flows, and is not template-based, meaning that the fields v5 can report on are limited and static. Due to the static nature of flow data, however, it is very simple to parse and store. Where Netflow v9 can report ~127 individual fields and metrics using templates, v5 has only 18 possible fields and metrics. The possible fields in Netflow v5 can be found here.
Netflow v9
Netflow v9 is considered a modern version of Netflow, and is very widely supported, despite still being a Cisco standard. This version is template-based, meaning that the fields it can export are not static like in v5, and it supports IPv6. An exporter will first send a Template to the collector, showing what fields and metrics it will be reporting and how many bytes each of those is. The collector will cache the template and use it to decipher the flow data that arrives after the Template is received. Any flow data received before a template arrives is discarded, per the Netflow v9 standard, because there is no way to decipher it. The approximately 127 possible fields and metrics in Netflow v9 can be found here, in Section 8 of the IETF text document.
IPFIX (aka Netflow v10)
IPFIX is often referred to as "Netflow v10", but is actually a separate IETF standard, as defined in RFC 5101. Some router manufacturers specify the Netflow version number 10 in their CLI, others refer to it as "ipfix" at the CLI. This is another template-based standard, which adds additional fields, metrics, and flexibility on top of what Netflow v9 offers. The number of possible fields is increased significantly with IPFIX, offering 458 possible fields and metrics to report on. This standard adds additional capabilities for reporting on MPLS labels, BGP performance, mobile routing, and many other advanced configurations.