Summary

  • RFC 9899 defines a bounded comparison: choose an offset origin, skip length bytes, apply an operator and compare a binary pattern. A schema-valid configuration says nothing by itself about which bytes a device inspected.
  • A counter delta is evidence of local ACE attribution within a known scope and epoch. It is not independent proof of packet identity, action execution or application outcome.

Imagine a change ticket with four green observations: the payload feature appears in the YANG library; the configuration commit succeeds; the ACE is visible in a readback; and its packet counter advances during a test. The tempting sentence is “the payload rule works.” Every observation may be true while that sentence remains unproved.

The reason is not a defect in RFC 9899. It is a boundary the RFC makes possible to describe. Published in December 2025 as a Proposed Standard, RFC 9899 extends the ACL model of RFC 8519. Its Datatracker record identifies it as the result of draft-ietf-netmod-acl-extensions. A later Datatracker update changes the record's metadata, not the December 2025 specification. The RFC information page, the Datatracker record and the current errata search should be preserved together when the precise publication state matters.

The four-part comparison

Support begins with the match-on-payload feature. That is a capability advertisement under YANG 1.1, not a report from the forwarding plane. Within the payload-match grouping, offset selects a semantic origin, length says how many bytes to ignore from that origin, operator defaults to match, and pattern carries the binary value. The comparison starts at offset + length.

That last point is easy to misread. length is not the number of bytes to compare. It is the skip distance. The size and content of the binary pattern determine the comparison window. A review that records only “offset 42, length 4” but omits the offset identity, operator and exact pattern has not preserved the rule.

The defined origins also carry more meaning than a numeric address. layer2 begins at the data-link header. layer3 begins at the IP header. layer4 begins after the IP header, including IP options and IP-layer headers such as IPv6 extension headers and AH. payload begins after the transport header, which means after TCP options when they exist. The IANA YANG Parameters registry records the module revision and the three RFC 9899 IANA-maintained type modules; that registry evidence is useful for schema identity, not for forwarding behaviour.

The origin can move while the number stays still

Consider two TCP packets whose application bytes are identical. One has the minimum TCP header; the other carries options. RFC 9293 defines the Data Offset that locates the beginning of TCP data. A device that truly implements the payload origin should account for that variable header. A test that substitutes a fixed absolute skip may accidentally match the first packet and miss the second.

IPv6 makes the inspection point still more consequential. RFC 8200 places extension headers between the IPv6 header and upper-layer material, and treats fragments as separate packets before destination reassembly. RFC 9899 says where its layer4 origin begins, but it does not tell every appliance whether matching occurs before or after reassembly, decapsulation or a vendor normalization stage. Those are implementation and placement facts. They have to be discovered and tested.

Encryption draws a harder boundary. RFC 9000 protects QUIC packet payloads and header-protects fields including the packet number. Some header material can remain visible, but “part of a QUIC packet” is not the same as application plaintext. RFC 9899's security considerations are carefully bounded: matching is deterministic for unencrypted data, while effectiveness on encrypted packets depends on an unvarying pattern. It supplies no decryption capability. RFC 8329 provides wider context for packet-content matching in security functions, but cannot prove that a particular box implements this feature.

Nine claims that must not be merged

Operational evidence should be kept as a chain, not flattened into one status:

  1. Schema capability: the correct module revision, feature set and deviations expose the nodes.
  2. Authorization and transaction: an identified principal was permitted to write, and the protocol operation completed against a named datastore.
  3. Intended and operational state: the configuration is present in the relevant NMDA views. RFC 8342 makes this distinction explicit.
  4. Programmed state: the platform compiled and attached the ACE at the expected interface, direction, stage and hardware/software path.
  5. Exact bytes: an independently captured fixture shows the packet bytes, parsed header lengths and computed comparison window at that stage.
  6. Visibility: encryption, encapsulation, fragmentation, reassembly and normalization do not hide or move the intended invariant.
  7. ACE hit evidence: the correct counter, with known scope and epoch, changes around a controlled stimulus.
  8. Action execution: separate telemetry establishes that accept, drop, log, mark or another requested action actually occurred.
  9. Service result: the application or user-visible consequence is verified independently.

RFC 8341 is a useful reminder that schema conformance and access authorization are different systems. Likewise, RFC 8519's matched-packets and matched-octets are read-only counters for the current ACL entry. They may be per-interface or aggregated depending on implementation. A delta therefore says “this counter attributed traffic during this epoch.” Without a frozen scope, reset history, controlled stimulus and packet observation, it cannot say which packet caused the change. RFC 9899 also models complementary logging and named-counter actions; configuring an action is not proof that it ran.

A packet-window receipt

The smallest useful test artifact is a packet-window receipt. It should bind a configuration to observable input without pretending to prove the whole service:

  • module and revision, enabled feature and deviations;
  • device software and forwarding component build;
  • authenticated principal, authorization result, transaction ID and datastore;
  • ACE identifier, rule order, attachment, interface and direction;
  • inspection stage relative to decapsulation, normalization and reassembly;
  • offset identity, skip length, operator, binary pattern and computed byte range;
  • packet fixture and independent capture hashes, with decoded IP and transport header lengths;
  • encryption boundary and the exact invariant claimed to remain visible;
  • counter name, width, scope, aggregation rule, reset time, before/after values and stimulus interval;
  • separate action telemetry and separate application-result evidence.

This receipt makes negative tests as important as the positive one. Vary TCP options while holding application bytes constant. Insert an IPv6 extension header. Send first and non-first fragments where the platform supports a documented test. Change one pattern byte. Exercise encrypted and unencrypted variants. Move the same rule between ingress and egress. A comparison that survives only the easiest packet is a fixture success, not a dependable policy.

Publication is not implementation power

This separation also benefits from an explicitly external analytical lens. In Lu Heng's account of reality layers, documentary or symbolic authority is distinct from executable power. Applied here by the author—not attributed to the RFC—the YANG model belongs to a specification layer, while the programmed datapath, observed packet and enforced outcome occupy progressively more executable layers.

The same mapping gives practical meaning to Minimum Initial Specification and Localized Future Decision. Preserve a minimal deterministic core: schema identity, exact comparison window, stimulus, counter epoch and independent observation. Leave vendor choices about hooks, normalization and reassembly visible as local implementation decisions rather than smuggling them into an assumed universal meaning. The argument in On Authority, Belief, and the Internet’s Addressing System sharpens the final boundary: a published coordination artifact has influence, but the operator and implementation controlling the forwarding path possess the execution power. These are Daniel Kade's analytical applications; they are not IETF claims or evidence of RFC 9899's authors' intent.

RFC 9899 is valuable precisely because its model can make a comparison portable. Portability is not omniscience. The honest operational claim is narrower: under this schema and authorization context, at this programmed hook, these observable bytes were compared using this origin, skip, operator and pattern; this ACE counter moved within this epoch; separate evidence shows the action and service result. Anything stronger requires another receipt.

Sources