| Internet-Draft | MUX Status Frame | June 2026 |
| van de Meent & AI | Expires 19 December 2026 | [Page] |
This document defines the MUX Status Frame, a two-octet, relationship-scoped signal that lets a multiplexing routing layer tell a proven, related peer that a destination is unavailable - offline, not in session, superseded, or permanently revoked (tombstoned) - while disclosing nothing to the open network. It resolves the tension between two failure modes of a null-routing mux: silently dropping traffic to a dead peer (a false positive - the sender believes it landed) and answering honestly to everyone (an enumeration oracle mapping who is alive, dead, or revoked). Honest status travels only on a relationship-scoped trusted path; to the world, and to any merely authenticated but unrelated peer, the entire frame is zero. Status is derived from the canonical naming record and session liveness, not from a separate blocklist. The encoding is deterministic so independent implementations agree byte-for-byte. This protocol is transport-agnostic and complements JIS [JIS], AINS [AINS], TIBET [TIBET], and RVP [RVP].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
A multiplexing routing layer ("mux") that protects a host commonly absorbs abnormal traffic into silence (a null route). Silence is the correct posture toward an unknown scanner. It is the wrong posture toward a legitimate sender whose destination is genuinely gone: the sender (a human or an autonomous agent) believes its message landed when in fact it fell into a black hole.¶
The naive fix - reply "dead" - is worse. Any response that varies with the state of a name turns the mux into an enumeration oracle: an attacker can map which identities exist, which are alive, and which have been revoked. The honest signal and the leak are the same signal.¶
This document resolves the tension by scoping honesty to a prior relationship. The mux emits a real status only to a peer that is both cryptographically proven and already had a binding with the destination; to everyone else the frame is indistinguishable from the silent default. The distinction is the entire mechanism.¶
Two failure modes must be eliminated simultaneously:¶
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
The frame is two octets carried in a reserved field of the mux envelope. Octet 0 is the status; octet 1 is a hint.¶
bits 7-6 disclosure 00 silent / no disclosure (the world) 01 trusted 10 policy / security 11 reserved bits 5-4 state class 00 accepted / alive 01 transient / degraded 10 unavailable / dead 11 policy / quarantine bits 3-0 reason 0000 none 0001 heartbeat-dead 0010 not-in-session 0011 not-registered 0100 consent-missing 0101 tombstone-confirmed 0110 successor-available 0111 assurance-expired 1000-1111 reserved¶
bits 7-6 retry 00 no-hint 01 retry-soon 10 retry-later 11 do-not-retry-auto bits 5-4 detail source 00 none 01 local-mux 10 local-cache/last-known 11 signed-external / canonical-ref bits 3-0 detail code 0000 none 0001 route-missing 0010 endpoint-inactive 0011 runtime-wrapper-missing 0100 session-expired 0101 local-tombstone 0110 canonical-tombstone 0111 successor/ref-available 1000-1111 reserved¶
octet0 = (disclosure << 6) | (state_class << 4) | reason octet1 = (retry << 6) | (detail_source << 4) | detail_code¶
The two octets are the contract. Implementations MUST sign, verify, and compare over exactly these octets.¶
If disclosure is 00 (the world), or the caller has no relationship with the target (Section 5), the entire frame MUST be 0x0000. An implementation MUST NOT leak state class or reason through the lower bits when disclosure is 00; doing so reconstitutes the enumeration oracle through the nibbles. Honest status travels only at disclosure 01 (trusted) or 10 (policy/security).¶
Alive is implicit by routing. A reachable endpoint simply forwards traffic; an implementation MUST NOT broadcast an unsolicited "alive" frame, which is itself enumerable. An explicit alive acknowledgement (0x40nn) is OPTIONAL and is only a response to an explicit status query on the trusted path.¶
The security of the frame depends on the relationship predicate, so independent implementations MUST decide it identically. A relationship exists when the target can verify a prior bilateral binding with the caller. At least one of the following MUST hold:¶
Authentication alone - a valid signature from an otherwise unknown peer - is NOT a relationship. Treating it as one would make every trusted peer an enumeration oracle for every name. When the predicate cannot be established, the implementation MUST treat it as absent and emit 0x0000.¶
The status fields are derived from the canonical naming record (AINS) and session liveness, in this order:¶
An implementation MUST NOT assert not-in-session without positive evidence that the lane is quiet; absent such evidence a registered name resolves as alive.¶
A receiving sender keys on the state class: alive means proceed; transient means retry per the retry bits; dead means stop or follow the hint; quarantine means stop. On successor-available the sender SHOULD re-resolve the target to its successor and retry there. The detail-source field is a confidence gradient on the evidence (local-mux < local-cache < signed-canonical-ref); a sender MAY weight automated action by it. A canonical tombstone with detail-source signed-canonical-ref is self-verifiable offline.¶
The frame is a reachability/liveness posture, not a delivery or read receipt. A live actor that refuses an action is a consent decision (for example an authorization failure), and MUST NOT be encoded as a mux status. Whether a recipient read or acted on a message is a separate, higher-layer signed receipt [TIBET], never these octets.¶
Informatively, the frame maps onto familiar messaging semantics: a single check (queued, lane not live) corresponds to transient; a double check (delivered to a live lane) to alive; "blocked" to dead or quarantine. A read/acted indication is not derivable from the mux and belongs to the receipt layer.¶
Silence is the absolute floor. If status cannot be computed - the naming record is unreachable, a lookup times out, or any error occurs - the implementation MUST emit 0x0000 and MUST NOT fail open to a permissive state. Status resolution SHOULD be performed against a local replica of the canonical record to avoid network-dependent stalls; where a remote lookup is unavoidable it MUST be bounded by a timeout whose expiry yields 0x0000. The encoding is deterministic: identical inputs yield identical octets.¶
The central property is non-enumerability: the frame MUST reveal nothing to a caller that is not a proven, related peer. The relationship predicate (Section 5) is the load-bearing control; weakening it to authentication alone reintroduces the oracle. Context extraction at the mux MUST be bounded and MUST NOT parse unbounded request bodies, so the resolution step cannot itself become a denial-of-service surface; a length-capped, shape-checked target identifier from a header or path is the intended input. A bad or missing identity proof MUST NOT earn status. Because status derives from the canonical record, revocation propagates without a distributable blocklist; an attacker cannot enumerate the blocklist because there is none.¶
This document requests, on adoption, three registries with reserved ranges for future allocation: "MUX Status Reason Codes" (octet 0, bits 3-0), "MUX Hint Retry/Source" (octet 1, bits 7-4), and "MUX Detail Codes" (octet 1, bits 3-0). Code points 1000-1111 in each nibble are Reserved. The allocation policy is Specification Required.¶
caller = world / unproven, ANY target -> 0x0000 caller = trusted, NO relationship, ANY target -> 0x0000 trusted + relationship, alive (explicit ack) -> 0x4000 trusted + relationship, heartbeat-dead -> 0x5152 trusted + relationship, not-in-session -> 0x5293 trusted + relationship, not-registered -> 0x5351 trusted + relationship, canonical tombstone -> 0x65F6 trusted + relationship, successor available -> 0x66F7¶
The two negatives - world and trusted-without-relationship over a tombstoned target both yielding 0x0000 - are the conformance guarantee: an implementation that "honestly" returns the dead nibble to the world fails them. A runnable interoperability vector set and reference verifier exist as "mux_status_v10" in the TIBET communications conformance kit; implementations SHOULD verify against the published vectors, including the anti-enumeration negatives, rather than against any single reference implementation.¶