Summary

  • RFC 9778 moves IGMP Type and Code allocation to Standards Action and creates Standards Action registries for extension flags, increasing review and visibility without certifying deployed parser support.
  • The RFC names a two-sided security failure: an analyzer may decline an unknown value and interrupt connectivity, or forward it without effective inspection and expose a security gap.
  • Safe adoption therefore needs separate, time-stamped evidence for authority, publication, implementation, observed analyzer decisions, staged interoperability, traffic effects and rollback.

A registry entry is an unusually compact form of authority. It says that a value has an agreed name, a documented purpose and a legitimate place in a shared namespace. For operators under pressure, that clean row can look like the end of a decision. RFC 9778 makes it the beginning.

The document, published in March 2025 as BCP 57 and replacing RFC 3228, revises the allocation rules for Internet Group Management Protocol and Multicast Listener Discovery message fields. Its most consequential sentence is operational rather than bureaucratic: firewalls and network intrusion detection systems rely on unambiguous protocol fields. When a new value appears, an analyzer that does not understand it may decline the traffic, causing loss of connectivity, or may forward it as part of an attack, causing loss of security.

That is why allocation policy belongs on the protocol security surface. A code point determines not only how authors coordinate. It introduces a new branch into every deployed decision tree that reads the field.

What RFC 9778 actually authorizes

For the IGMP Type registry, RFC 9778 changes the registration procedure to Standards Action. IGMP Code fields follow the same high-review route, while the document defining a new IGMP Type must define the policy for that Type's Code field. The RFC also creates two registries for the extension mechanism used by later IGMP work: Query flags, with bit 0 assigned as E and bits 1 through 3 unassigned; and Report flags, with bit 0 assigned as E and bits 1 through 15 unassigned. Both use Standards Action.

The MLD boundary is deliberately different. MLD message Types and Codes remain within the ICMPv6 Parameters registry, whose applicable policy is IETF Review. RFC 9778 does not flatten these namespaces into a single rule. It records which authority governs which field.

RFC 8126 explains why this distinction matters. Standards Action requires publication through the Standards Track or a BCP approved by the IESG. It is designed for situations where broad review and a durable standards record matter. That process can expose proposed semantics to implementers and security reviewers before an assignment becomes normal traffic.

Yet the procedure answers a bounded question: was this value allocated through the required authority? It does not answer whether a specific packet decoder recognizes it, whether a firewall policy has a matching branch, whether a monitoring dashboard labels it correctly, or whether an emergency rollback will restore the previous path.

The unknown-value fork

Consider a hypothetical extension rollout. A standards document defines a new flag, IANA publishes the assignment, and an endpoint emits it correctly. On the wire, the packet is legitimate. At an older inspection point, the decision can still fork.

One device may apply a fail-closed posture and decline a field it cannot classify. The result is visible breakage: group membership reports disappear, multicast reachability degrades, and an operator may blame the new endpoint. Another device may treat the packet as ordinary traffic and forward it, even though the security engine did not evaluate the new semantics. Connectivity appears healthy while inspection coverage has become uncertain. A third may parse the base message but ignore an extension whose effect changes later processing.

The standard does not predict which branch a named product will take. Neither does the IANA row. RFC 6709's design guidance for protocol extensions explains the general hazard: unknown extensions, fields formerly required to be zero, partial implementations and silent discard can all create interoperability or security regressions. The evidence needed is installed behavior, not the elegance of the specification.

RFC 9279 offers a useful adjacent example. It defines an E-bit extension mechanism and requires unsupported extension TLVs to be ignored, while malformed constructions must be handled according to explicit validation rules. That separation—unknown but well-formed versus malformed—has to survive real parsers and policy engines. Support for the base message alone is not proof that the extension path is safe.

Seven receipts, not one green badge

A defensible readiness record keeps at least seven claims apart.

The authority receipt identifies the standards document and the procedure that approved the value. The publication receipt captures the IANA registry state and retrieval time. The implementation receipt identifies the exact software, firmware, ruleset or decoder version that claims support. The analyzer receipt records the observed verdict for known, unknown, malformed and mixed-version vectors. The interoperability receipt shows behavior across old and new senders, receivers and transit controls in a staged environment. The impact receipt measures multicast joins, leaves, loss, latency, CPU, alerts and false positives. The rollback receipt proves that operators can remove the new emission or policy branch without damaging unrelated traffic.

These are not seven names for the same success. A value may have authority and publication while implementation remains absent. A decoder may implement syntax while a firewall ruleset still chooses its legacy default. A lab pair may interoperate while a transit appliance declines the message. Traffic may pass while the detector records no semantic verdict. A rollback procedure may exist on paper but exceed the time available during an incident.

Heng Lu's distinction between symbolic records and running reality is useful here. The registry is real, but real at the coordination layer. Packet behavior is real at the execution layer. Confusing them does not make the registry false; it assigns the registry power it was never meant to hold.

A staged test that can fail safely

The following is a hypothetical evidence design, not a report about a live deployment.

Start with captured baseline traffic and an inventory of every control that parses IGMP or MLD: host stack, switch silicon, router process, firewall, intrusion sensor, packet broker, collector and troubleshooting decoder. For each one, record the running version and relevant configuration checksum. Replay valid legacy messages first, then introduce the proposed Type, Code or flag. Add an unassigned value, a well-formed unsupported extension, malformed length and checksum cases, and mixed old/new peers.

At each hop, collect more than a packet capture. Record whether the control parsed the field, named it, ignored it by an explicit rule, declined it, alerted on it, or forwarded it without a semantic verdict. Observe the resulting membership state and data-plane effect. A packet visible after a firewall is not automatically evidence of inspection; it may be evidence of pass-through.

Canary the change on a bounded segment with a known traffic budget. Define stop conditions before enabling emission: unexpected decline rate, missing reports, analyzer fallback, CPU pressure, state divergence or unexplained multicast loss. Keep the previous sender behavior and control policy ready as independent rollback levers. A useful recovery test demonstrates both the time to reverse and the absence of collateral changes.

Sources

  1. RFC 9778 — IANA Considerations for Internet Group Management Protocols
  2. RFC 3228 — IANA Considerations for IPv4 Internet Group Management Protocol
  3. RFC 8126 — Guidelines for Writing an IANA Considerations Section in RFCs
  4. RFC 6709 — Design Considerations for Protocol Extensions
  5. RFC 9279 — Internet Group Management Protocol Version 3 and Multicast Listener Discovery Version 2 Extensions
  6. RFC 9776 — Internet Group Management Protocol Version 3
  7. RFC 9777 — Multicast Listener Discovery Version 2
  8. RFC 4443 — ICMPv6
  9. IANA — Internet Group Management Protocol Type Numbers
  10. IANA — Internet Control Message Protocol version 6 Parameters
  11. Heng Lu — Running-code primacy
  12. Heng Lu — Minimum initial specification and localized future decision
  13. Heng Lu — Reality layers and symbolic power