Tenant Networking on Deevnet IoTaaS

ADR-0029: Tenant Developer Network Keys

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0029: One Key per Tenant on the Tenant Developer Network, Issued at Admission #


Status	Accepted (2026-09-27): built and proven by CHG-0029
Date	2026-09-27
Scope	How a tenant developer’s laptop gets onto `DVNTM-TD`, how one tenant is kept from another there, and how that access ends. Not what the segment may reach (CHG-0022, CHG-0024, ADR-0028 §5).
Amends	CHG-0022’s design note “A shared key, not PPSK”; ADR-0015 §10 (what an admission hands over)
Related	ADR-0012 §3 (per-tenant PPSK keys), ADR-0028, CHG-0029

Context #

DVNTM-TD is where a tenant developer’s laptop sits to apply Terraform, reach the broker, read logs and, after ADR-0028, log in to its workloads. Today every tenant shares one WPA2-Personal key on it, with PMF off, and laptops on it can reach each other. Together that lets tenant A take tenant B’s tenant:

ADR-0019: Tenant Layer 2 at the Access Edge

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0019: Tenant Layer 2 at the Access Edge #


Status	Accepted
Accepted	2026-09-19. It decides not to build something, so there is no implementation to wait for. Its one open question was closed by reasoning rather than by experiment — see The open question, closed — and its reconsideration trigger was corrected, because the protocols it first named do not in fact require Layer 2 adjacency.
Date	2026-09-18
Scope	Whether a tenant’s EVPN/VXLAN overlay may be extended to the wireless access network as an 802.1Q VLAN, so that a physical device becomes a Layer 2 member of its tenant’s subnet
Re-opens	ADR-0011 Option B, rejected 2026-09-15, in the light of a variation it did not consider: a VLAN range reserved once, so tenant creation needs no switch change
Depends on	ADR-0001: Tenant Network Fabric, ADR-0011: Edge Devices Are Application-Owned and Platform-Attached
Related	ADR-0002: Tenant Fabric Numbering, ADR-0009: Network Device Configuration Is Inventory-Owned, ADR-0012: IoT Platform Services Through a Deevnet API, ADR-0018: Operator Access to Tenant Workloads, Network Segmentation §4

Context #

ADR-0011 settled where a physical device attaches: the access network of its trust class, not its owner’s tenant fabric. Its Option B — a per-tenant edge VLAN carried over the AP trunk and bridged into the tenant’s VRF — was rejected on 2026-09-15, and CHG-0013 then built the accepted model: one PPSK key per tenant per trust class, bound by the Deevnet API to that class’s VLAN.

ADR-0018: Operator Access to Tenant Workloads

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0018: Operator Access to Tenant Workloads #


Status	Accepted
Accepted	2026-09-19, recording what CHG-0012 applied on 2026-09-18. The route is in place and verified from both operator zones; what waits on CHG-0007 is enforcement of the surrounding policy, not this decision.
Date	2026-09-18
Scope	Whether the substrate’s operator networks may reach tenant workloads, and what that does to the “no inbound path” property other records rely on
Supersedes, in part	ADR-0001: Tenant Network Fabric and ADR-0002: Tenant Fabric Numbering, where each says the core router never learns tenant address space. It now learns one aggregate route. Everything else in both records stands, including SNAT at the exit node and per-tenant isolation inside the fabric.
Related	ADR-0003: Tenant Egress on a Single-Member Fabric, ADR-0010: Tenants Consume Platform Services, ADR-0011: Edge Devices Are Application-Owned, ADR-0012: IoT Platform Services Through a Deevnet API and Terraform Provider, ADR-0017: How Tenant Code Reaches a Tenant Workload

Context #

The property, and who relies on it #

Six records state some form of “a tenant has no inbound path”. They do not all mean the same thing, and the difference matters:

ADR-0003: Tenant Egress on a Single-Member Fabric

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0003: Tenant Egress on a Single-Member Fabric #


Status	Accepted
Date	2026-09-01
Scope	How tenant workloads reach the perimeter, and why they must reach it rather than route around it
Depends on	ADR-0001: Tenant Network Fabric

Context #

ADR-0001 chose a self-contained EVPN/VXLAN fabric per tenant hypervisor, realized today as a single-member fabric on hv02 and designed to expand by adding members. Seam 1 of that record defines north-south egress: aggregate tenant traffic leaves the fabric on a transit VLAN, and the core router is a perimeter that never learns tenant address space.

ADR-0002: Tenant Fabric Numbering

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0002: Tenant Fabric Numbering #


Status	Accepted
Date	2026-08-30
Scope	Address and identifier allocation for the tenant fabric and the tenants on it
Depends on	ADR-0001: Tenant Network Fabric

Context #

ADR-0001 made globally-unique numbering its first build requirement: allocate VNIs, VRF identifiers, and tenant subnets as if they already share one fabric, so that gaining a member is additive rather than a renumbering. It did not say what that scheme is. The Tenant Platform roadmap carried it as an open thread.

ADR-0001: Tenant Network Fabric

Mon, 01 Jan 0001 00:00:00 +0000

ADR-0001: Tenant Network Fabric #


Status	Accepted
Date	2026-08-30
Scope	Tenant networking on the tenant hypervisor; relationship to the core router and management hypervisor
Supersedes	The Option A tenant-networking model previously described in `architecture/tenant/networking.md` (core-router-owned per-tenant VLANs)

Context #

We are ready to begin hosting tenants — isolated application workloads — on the tenant hypervisor. A tenant needs a network: an address space, a gateway, routing, isolation from other tenants, and a controlled path to the outside world.