A new technician at a regional ISP asks why the co-op's POP router evaluates each packet against a firewall filter independently, rather than remembering that a subscriber's device already had an accepted connection a moment earlier. Which characteristic of a Junos firewall filter explains this behavior?

A Junos firewall filter is stateless, which means every packet is evaluated independently against the filter's terms based solely on that packet's own header fields, with no tracking of connections, sessions, or the history of prior packets belonging to the same flow. This differs fundamentally from a stateful firewall, which maintains a session table and can permit return traffic automatically because it recognizes an established connection. The wrong options variously describe caching a decision from the first packet of a flow, synchronizing state with a session table, or reserving statefulness for Routing Engine-bound traffic while leaving transit traffic stateless — all of them describe stateful behavior, which is precisely the concept a Junos firewall filter does not provide at this introductory level. Because there is no session awareness, an administrator who wants return traffic (such as a DNS reply) to be permitted must write an explicit term for it, rather than relying on the filter to infer that it belongs to an already-accepted request. This has real operational consequences for a cooperative's POP router: every packet direction typically needs its own explicit permit term, and forgetting one for return traffic is a common cause of connectivity that appears to work in one direction only. To confirm this stateless behavior in practice, an engineer can watch a filter's term counters increment identically for every packet in a flow rather than only for the first one, and verify that a missing return-traffic term causes one-way connectivity even though the outbound request was accepted.