Network Segmentation #

Each site’s substrate is divided into segments by purpose and trust, one VLAN each. Traffic between segments is routed through the core router and denied unless a rule allows it.

Purpose #

Network segmentation divides each substrate into isolated broadcast domains with controlled routing between them. This provides:

• Security boundaries — Limit blast radius when devices are compromised
• Traffic isolation — Separate management, storage, and workload traffic
• Operational clarity — Each segment has a defined purpose and trust level

Segment Model #

Each substrate implements ten segment types:

The hosts on each segment at the mobile site are listed in the Network Reference.

Management Segment #

The management segment carries infrastructure control traffic.

Typical inhabitants:

• The builder
• Hypervisor management interfaces
• Router, switch and access point management interfaces
• Network management and substrate observability services
• IPMI/BMC interfaces

Properties:

• Full access to all infrastructure
• Source of automation
• Never exposed to untrusted networks

Trusted Segment #

The trusted segment contains high-trust user devices that require broad network access but are not part of the infrastructure management plane.

Typical inhabitants:

• Personal workstations
• Laptops and primary user devices
• Multi-homed desktops with access to multiple segments

Properties:

• High trust level, similar to management
• Can initiate connections to most segments (except guest)
• May access management services for administration
• Users are authenticated and devices are known/managed
• Subject to endpoint security requirements

Storage Segment #

The storage segment isolates storage protocol traffic from other network activity.

Typical inhabitants:

• NAS storage interfaces
• Hypervisor storage interfaces
• Backup target interfaces

Properties:

• High-bandwidth, low-latency requirements
• May use jumbo frames
• No internet access required
• Optional in minimal sites where storage traffic is negligible

Tenant Fabric Transport #

A tenant is not a VLAN. Since ADR-0001, a tenant’s network is an EVPN/VXLAN overlay owned by the tenant hypervisor’s own fabric, with its own anycast gateway and its own VRF. The core router never sees a tenant subnet, and creating a tenant adds no segment here — which is the whole point of the model.

What the substrate carries instead is two segments for the fabric itself, and they do not grow with the number of tenants:

Typical inhabitants: the tenant hypervisor’s transit and underlay interfaces. No tenant workload sits on either — workloads live in the overlay, at 10.20.128.0/18.

Properties:

• Isolation between tenants is enforced inside the fabric, one VRF per tenant — not by a firewall rule here
• Tenant traffic arrives at the perimeter already SNATed, so the core router cannot tell one tenant from another even if it wanted to
• The core router holds one aggregate route into the overlay, so that operators on management and trusted can reach tenant workloads ( ADR-0018). Devices, other tenants and the outside world still have no path in.

Platform Segment #

The platform segment contains shared infrastructure services that multiple segments need to access.

Typical inhabitants:

• Shared services the control plane runs for tenants: the provisioning API, secrets, tenant DNS
• DNS resolvers
• NTP servers
• Artifact mirrors and package caches
• Reverse proxy / load balancer
• Certificate authority

Properties:

• Reachable from management, trusted, tenant, and IoT backend segments
• High trust — hosts are fully managed infrastructure
• Static DHCP only
• No direct user workloads
• Services are shared, not tenant-specific

IoT Vendor Segment #

The IoT vendor segment is a strict containment zone for vendor-managed devices that phone home to cloud services and cannot be fully audited.

Typical inhabitants:

• Smart home hubs with vendor cloud dependencies
• IP cameras with vendor firmware
• Consumer IoT devices (smart plugs, thermostats)
• Any device where firmware updates are vendor-controlled

Properties:

• Outbound internet access only (for vendor cloud connectivity)
• Complete isolation from all internal segments — stricter than IoT
• No inbound access from any segment
• Devices are assumed compromised by default
• Cannot reach management, storage, tenant, or platform segments

IoT Segment #

The IoT segment contains controlled devices with a known owner. Their firmware is built and released by that owner, from that owner’s repository; the substrate attaches them to the network and issues their credentials, but does not build their software. Unlike the IoT Vendor segment, where the vendor controls the firmware, an IoT device’s owner is accountable for what it runs.

Typical inhabitants:

• Pi lab hosts
• Embedded devices
• SDR receivers
• Sensors and IoT gateways

Properties:

• Medium trust — firmware is controlled by a known owner
• Outbound internet access (controlled)
• Limited or no access to management segment
• May need access to specific tenant services

IoT Backend Segment #

The IoT backend segment hosts application backends that process IoT data — MQTT brokers, home automation controllers, and data pipelines.

Typical inhabitants:

• MQTT brokers
• Home Assistant instances
• IoT data ingestion and processing services
• Time-series databases for sensor data

Properties:

• Accepts inbound connections from IoT segment (sensor data, MQTT publish)
• May access platform segment (DNS, NTP, artifact mirrors)
• Must not access management segment directly
• Medium trust — hosts are managed but handle untrusted input
• Static DHCP only

Tenant Dev Segment #

The tenant dev segment is where a tenant’s developer works from. It reaches the services a tenant consumes from its own laptop, and nothing else inside the site.

Typical inhabitants:

• A tenant developer’s laptop, running the tenant’s infrastructure-as-code and test clients

Properties:

• May reach the tenant-facing services only: the onboarding API, the tenant state store, the message broker, the tenant log store, tenant dashboards and the read-only tenant downloads, each by host and port
• No access to management, trusted, storage, IoT or any tenant’s workloads
• Internet access
• Dynamic DHCP only (no static mappings)
• A shared key, not per-tenant keys: the segment identifies no tenant. The API’s credentials do that

Without it, a tenant must work from a trusted seat, which reaches far more than the tenant needs.

Guest Segment #

The guest segment provides network access for transient devices without substrate access.

Typical inhabitants:

• Visitor laptops and phones
• Demo equipment
• Temporary test devices

Properties:

• Internet access only
• Complete isolation from all other segments
• Dynamic DHCP only (no static mappings)
• May have bandwidth or time limits

Segment Relationships #

Segments form a trust hierarchy with controlled routing between them:

graph TB
    subgraph high["High-trust segments"]
        Mgmt[Management
High Trust]
        Trusted[Trusted
High Trust]
    end

    Mgmt -->|manages| Storage[Storage
High Trust]
    Mgmt -->|manages| Platform[Platform
High Trust]
    Mgmt -->|manages| Tenant[Tenant Transit
Medium Trust]
    Mgmt -->|manages| IoTBackend[IoT Backend
Medium Trust]
    Mgmt -->|manages| IoT[IoT
Medium Trust]
    Mgmt -->|manages| IoTVendor[IoT Vendor
Very Low Trust]
    Trusted -->|user access| Storage
    Trusted -->|user access| Platform
    Trusted -->|user access| Tenant
    Trusted -->|user access| IoTBackend
    Trusted -->|user access| IoT

    IoT -->|sensor data| IoTBackend
    TenantDev[Tenant Dev
Low Trust] -->|API, state store| Platform
    TenantDev -->|broker| IoTBackend
    Mgmt -->|manages| TenantDev
    IoTBackend -->|shared services| Platform

    Tenant -.->|no access| Guest[Guest
Untrusted
Internet only]
    IoTVendor -.->|internet only| Guest

Default Routing Policy #

• Default deny — Traffic between segments is blocked unless explicitly allowed
• Management can reach all — Management segment initiates connections to all others
• Trusted has broad access — Trusted segment can reach most segments except guest; similar to management but for user devices
• Storage is isolated — Only management, trusted, and designated compute hosts access storage
• Tenants are isolated — Tenants cannot see each other; access shared services via firewall rules
• IoT is outbound-only — IoT devices can reach internet; inbound requires explicit rules
• Platform is broadly reachable — Management, trusted, tenant, and IoT backend segments can reach platform services
• IoT Vendor is fully contained — Outbound internet only; no access to any internal segment
• IoT Backend accepts IoT traffic — Inbound from IoT, outbound to platform; no direct management access
• Tenant Dev reaches tenant-facing services only — Named hosts and ports on platform and IoT backend; nothing else internal
• Guest has no substrate access — Guest segment routes only to internet gateway

Integration with Substrate Model #

Network segmentation is substrate-scoped:

• Each site implements segmentation independently
• No cross-site segment dependencies
• The same segment model applies to all sites
• Implementation details (VLAN IDs, IP ranges) vary per site

This aligns with the site independence principle — each site can be built, operated, and torn down without affecting the other.

Authority Modes and Segmentation #

Segmentation behavior differs between authority modes:

During bootstrap, the provisioner operates on a flat network to PXE boot and configure hosts. Once the core router is configured with VLAN interfaces and the switch is configured for trunking, the substrate transitions to full segmentation.

The transition is explicit — segment configuration is part of the authority handoff from builder to core router.