Summary

  • RFC 9899 is an IETF Proposed Standard that augments, rather than replaces, the RFC 8519 network ACL model.
  • It lets ACL entries reference named reusable sets for IPv4 and IPv6 prefixes, ports, protocols, ICMP types, and aliases; the model also expands packet matching and adds local actions.
  • The operational gain is indirection. The operational exposure is that one defined set can affect many parent rules, so ownership, authorization, dependency visibility, validation, and rollback matter.

What is being reused

A single-parameter set is appropriate when the object contains only one kind of value: for example, prefixes, ports, protocols, or ICMP types. An alias can combine parameters such as prefixes, protocols, ports, or VLANs. ACL entries can then refer to these named objects instead of repeating literals. RFC 9899 also supports reuse across network elements at an administrative-domain level. That is a model capability, not a claim that every implementation exposes every feature.

The extension remains anchored in RFC 8519. A deployment should therefore distinguish the base ACL fields from enhanced fields. For TCP flags, a client that supports both the enhanced flags-bitmask and the RFC 8519 flags field MUST NOT set both in the same request. The comparable mutual-exclusion rule applies when enhanced fragment matching and the RFC 8519 flags field overlap. A fixture that sends both combinations should be rejected or otherwise handled according to the model’s constraints; it is not a safe way to express a broader match.

A wider packet vocabulary

The augmentations add matches for IPv6 extension headers, TCP flags through flags-bitmask, IPv4 and IPv6 fragment types, payload patterns, MPLS headers, VLANs, and I-SIDs. Payload matching is feature-gated and requires an offset type, offset, length, binary pattern, and operator. It does not decrypt traffic. On encrypted packets, effectiveness depends on an unvarying observable pattern, so an operator must verify what is actually visible rather than infer application content.

Rate-limit, logging, and counter actions are also added, but the defined version supports only local actions. RFC 9899 creates initial IANA-maintained YANG modules for ICMPv4 types, ICMPv6 types, and IPv6 extension-header types. Neither those registries nor the model implies universal device support, a performance improvement, or a universal scale limit.

The control surface

Defined sets are read/write security objects. An unauthorized write can add traffic that should be denied or remove traffic that should be permitted. An unauthorized read can reveal which resources are bound to a set and weaken topology-hiding strategies. The RFC points toward YANG management protocols using secure transport and mutual authentication, with NACM available to restrict operations and content. RFC 8341 is therefore relevant to who may see or change these objects; RFC 7950 supplies the YANG 1.1 modeling language.

Theo March analysis—not an RFC mandate: treat each set as an owned dependency with a visible consumer list. Stage a proposed change, validate the affected parent ACLs and representative traffic, and retain a tested rollback path. The RFC does not prescribe one naming lifecycle, approval workflow, rollout interval, or rollback threshold. Reuse does not automatically make policy safer or more consistent: it reduces duplicated literals while concentrating change impact.

Verification fixtures

  1. Create one prefix set referenced by two ACL entries, add and remove a member, and confirm that the parent rules need not be redefined while their effective dependencies change.
  2. Submit enhanced flags together with the RFC 8519 flags field, then repeat with enhanced fragment matching and that base field; verify mutual-exclusion handling.
  3. Check advertised support before testing payload, MPLS, VLAN, I-SID, extension-header, rate-limit, logging, or counter behavior. Use a known binary fixture and an explicit offset, length, and operator; test encrypted traffic separately without claiming decryption.
  4. Attempt an unauthorized set read and write under NACM and secure, mutually authenticated transport. Confirm both access decisions and audit visibility.

Operator decision path

First inventory consumers and ownership. Next determine whether a single-parameter set or an alias expresses the intent without unnecessary coupling. Confirm feature support and the base/enhanced field constraints. Review the proposed set diff, validate all affected ACLs in a staged scope, observe local actions and relevant counters, then approve or revert using the prepared path. If dependencies cannot be made visible or authorization cannot distinguish read from write, keep the literals local until that control gap is resolved.

Sources