Summary
- RFC 8799 argues that a protocol can be standardized for use inside a limited domain without promising universal Internet applicability, but local scope creates extra duties: define membership, identify boundary roles, prevent leakage and explain what happens when domains overlap or connect.
- Brian Carpenter is one of two authors, with Bing Liu, of this Independent Submission. Their document is Informational research, not IETF consensus and not a finished membership protocol; its value is the set of questions it refuses to let a
controlled environmenthide.
The line the packet could not see
Consider an operator who enables a locally meaningful packet field across a managed network. Every router on the architecture diagram sits inside a colored boundary. At one edge, however, a default route carries the packet outward. The next device sees syntactically ordinary bits but not the private agreement that gave them meaning. It may ignore them, reinterpret them or expose operational data that was never meant to leave.
The mistake occurred before the leak. The diagram was treated as proof. A line can describe administrative intent, but it does not tell a node which domain it may join, which interface faces outward, whether another node is a member or whether a credential was revoked yesterday. Those are machine decisions, and they require evidence the machine can evaluate.
RFC 8799, published in July 2020, gives this problem a name. A limited domain is a set of nodes or users within which requirements, behavior or semantics differ from the wider Internet. It may be a building, a vehicle, a campus, a virtual network spanning continents, an industrial system, a data center, a network slice or a managed provider service. Physical proximity is optional; bounded meaning is the common feature.
The document treats controlled environment as a practical synonym. It does not mean a DNS domain, and it explicitly does not address political or linguistic fragmentation of the Internet. That distinction matters. RFC 8799 is not an argument for turning every administrative preference into a private Internet. It is an attempt to make technically limited behavior compatible with an open Internet that remains the universal means of interconnection.
Local scope does not cancel interoperability
Some requirements are genuinely local. A factory may need bounded latency. A constrained sensor network must spend power and bandwidth sparingly. A provider overlay may attach meaning to an identifier that other networks do not share. A universal mechanism can be unnecessarily complex or simply fail on the paths available. Carpenter and Liu accept that such differences will produce sector-specific protocols and extensions.
They do not infer that private meaning should stay undocumented. The same feature may be implemented by many vendors in thousands of separate domains. Those implementations still need a common grammar. Even a disconnected network needs its devices to interoperate, and two well-run domains may later be connected, nested or merged. Standardization can therefore be useful precisely because applicability is limited.
That creates a harder design test. Engineers must say where the behavior is valid and what an out-of-scope device will do. Declaring local use only is not security. RFC 8799 warns that the mechanism may leak onto the open Internet through error or misuse. Local scope can add security complexity because the trust model changes at the edge and because apparently ordinary bits may carry non-ordinary semantics.
Four different journeys across an edge
Section 5 separates four cases that are often collapsed into the word private.
First, a domain-specific protocol can retain standard IP formats and travel between two parts of a virtual domain over the open Internet. The intermediate network may be transparent to the packet even though it has no reason to understand the endpoint semantics.
Second, a non-standard IP form cannot assume such carriage. If it depends on a non-standard IPv6 extension header, the open Internet may be opaque. The operator needs another containment or transport design rather than optimism about path transparency.
Third, a mechanism may be explicitly invalid outside its domain. Then a tunnel can join separated sites into one virtual domain, and boundary nodes must drop packets that would otherwise escape. The edge action is part of correctness, not optional hygiene.
Fourth, two domains may use the same syntactic field with incompatible local meanings. Differentiated Services provides the familiar example: a DSCP value is well formed everywhere, but meaningful interoperability across an edge requires an agreement or a gateway mapping. If domains merge without that translation, a valid packet can produce an invalid operational assumption.
These cases allocate different responsibilities. Can the open Internet carry the bits? May the bits leave? Will another domain understand them? The answers determine tunneling, dropping, mapping, versioning and testing. A procurement statement that merely promises limited-domain support answers none of them.
Membership makes the boundary executable
RFC 8799's sharpest move is to say that the boundary itself has no technical meaning. What matters is whether a node is a member and whether it holds a boundary role. A boundary node must distinguish inward-facing from outward-facing interfaces. A sender must know whether its destination is inside. A receiver may need to know whether traffic originated inside. The geometry becomes a set of verifiable relationships.
The document then sketches eleven functional requirements. A domain needs a unique verifiable identity, effectively a public key. Nodes need to determine their eligibility, enrol securely and obtain authorization credentials. Enrolment needs withdrawal, and membership may be dynamic. Nodes need verifiable roles, the ability to verify peers and roles, and a way to discover boundary nodes. They also need domain policy or configuration, including filters that keep inappropriate traffic from leaving.
Nesting and overlap prevent this system from being reduced to one universal inside bit. A device may belong to several domains at once, perhaps on different interfaces and with different roles. A network slice can exist within a provider domain; an observability domain can overlap a service domain. Authority must therefore be scoped to the particular domain, interface, role and time.
Revocation belongs in the same sentence as enrolment. A system that proves how a device joined but cannot prove that it left will accumulate silent exceptions. The holder of the domain's private key is a trust anchor for domain operations, not an unlimited ruler. Its custody, delegation, rotation and recovery determine whether automated membership is safer than the manual filters it replaces.
RFC 8799 does not complete this machinery. It leaves open whether packets need a domain indicator and whether individual packets require cryptographic authentication. Its requirements can guide a design or an audit, but they are not an implementation to install. That restraint is part of the evidence boundary.
IOAM turns the taxonomy into edge work
Later specifications show what the limited-domain idea looks like when a feature reaches packets. RFC 9197 defines data fields for In Situ Operations, Administration, and Maintenance. IOAM adds or updates operational information while user packets cross a network. It explicitly limits that activity to IOAM domains as understood through RFC 8799.
An IOAM domain may contain multiple overlapping namespaces. Encapsulation designers must provide mechanisms to keep IOAM data within the intended domain, while operators are expected to enforce the edge, for example with filtering. Edge devices add or remove fields. The boundary is no longer a colored shape: it is a packet transformation owned by identifiable nodes.
RFC 9378 makes the roles more concrete. An encapsulating node adds IOAM options, transit nodes update them, and a decapsulating node at the edge removes all IOAM option types and related encapsulation headers before the packet continues. A node can hold different roles in different namespaces. This is precisely the overlapping, role-scoped world that a flat perimeter fails to describe.
Containment is only one acceptance test. IOAM increases packet size, which can alter ECMP behavior, consume path-MTU headroom and affect ICMP handling. A clean egress capture does not prove that the feature was harmless inside. Operators need both boundary evidence and path evidence.
Nor does IOAM prove that every RFC 8799 requirement now has a universal solution. It demonstrates uptake of the architectural vocabulary and supplies a testable example of edge responsibility. The general problems of secure membership, domain identity and role authority remain design choices for each applicable system.
Carpenter's deliberately incomplete map
The University of Auckland describes Brian Carpenter as an honorary academic whose expertise includes Internet protocols and computer history. His record spans CERN networking, IBM standards work and past leadership of the IETF, IAB and Internet Society. The IETF Datatracker lists RFC 8799 among a much larger body of infrastructure work.
That history can tempt a reader to turn the document into institutional doctrine. The document forbids that shortcut itself. RFC 8799 is an Informational Independent Submission by Carpenter and Bing Liu. It records the authors' research, informed by IETF consultation, but it is not IETF consensus and not an Internet Standard. Later IETF documents can use its definition without retroactively changing that status.
This boundary makes the work more useful, not less. The authors separate an architectural problem from a premature universal mechanism. They give designers a vocabulary for local semantics and a checklist of missing authority surfaces. They also leave readers able to distinguish a requirement, a later implementation choice and an operator's evidence.
The durable lesson is that local is a claim about scope, not proof of safety. A trustworthy domain needs a verifiable account of who belongs, who faces the edge, which meanings stop there and what evidence shows that they actually stopped.
Sources
- RFC Editor record and status for RFC 8799
- RFC 8799 full text
- RFC 9197: IOAM data fields
- RFC 9378: IOAM deployment
- Brian Carpenter's IETF Datatracker profile
- Brian Carpenter's University of Auckland profile
- IETF Datatracker record for RFC 8799
- RFC Editor record for RFC 9197
- RFC Editor record for RFC 9378
- Brian Carpenter's follow-up on the IETF IPv6 mailing list
- Brian Carpenter's official University of Auckland homepage
- Brian Carpenter's University of Auckland short biography
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
