Summary
- RFC 3069 let separate customer VLANs share one IPv4 subnet and gateway, reducing allocation waste without merging their Layer 2 broadcast domains.
- Because a same-prefix host still tries ARP before sending to its gateway, a super-VLAN router must mediate reachability; the mask alone proves neither adjacency nor authorization.
Fewer addresses, more mediation
The address arithmetic was compelling. In the RFC’s example, three customers expected to need sixteen hosts apiece. Conventional separate subnets consumed 28 addresses once network, directed-broadcast and gateway addresses, plus power-of-two sizing, were counted. RFC 3069’s arrangement used nineteen: all three customer sub-VLANs shared 1.1.1.0/24 and gateway 1.1.1.1, while their host ranges stayed disjoint. An idle address in one range could be assigned elsewhere without renumbering the customer.
That economy did not make the customers neighbors at Layer 2. Each sub-VLAN remained its own broadcast domain. Yet every host used the super-VLAN prefix length. Ordinary IP logic therefore treated an address inside 1.1.1.0/24 as on-link and tried address resolution instead of sending the packet to the default gateway. ARP discovers a link-layer address on the local network; it cannot make two isolated broadcast domains one network.
The super-VLAN router supplied the missing bridge. RFC 3069 says it may perform a function similar to Proxy ARP: answer a host’s request for an address in another sub-VLAN, then receive the frame and route the packet. To the host, the destination looked like a neighbor. In the forwarding system, the router was an intermediary. The prefix described an addressing relationship, not a physical or Layer 2 fact.
That distinction puts operational state behind the apparent simplicity. The router must know which addresses belong to which sub-VLAN, decide whether the requester may use the claimed source, answer ARP consistently and forward only along the intended path. A plausible mask or a successful ARP reply is not evidence that the address-to-VLAN binding is current or authorized. RFC 3069 recommends sticky address ranges: reject IP or ARP packets arriving on a sub-VLAN with a source address not assigned there, and optionally log the event. The protection is a control-plane rule whose effectiveness depends on the local allocation and binding data.
Some familiar subnet behaviors no longer map cleanly to one broadcast domain. RFC 3069 provides no directed-broadcast support because the all-ones address cannot represent a directed broadcast into several isolated Layer 2 domains at once. Multicast also needs care: a multicast router may require host-route-like state so reverse-path-forwarding checks work across the split domains. Later, RFC 4562 described how per-customer VLAN isolation complicates multicast replication and scales against the 4096-VLAN ceiling in broadband access networks.
Address savings did not remove operational costs; it moved them into router state and network operations.
The evidence boundary matters. RFC 3069 is Informational, not an Internet Standard, and deliberately leaves implementation details unspecified. It reports that Extreme Networks had a working implementation in service-provider data centers for more than a year; that is the RFC authors’ deployment report, not an independent adoption survey. Other vendors were only rumored to be developing similar functions. The document gives no broad interoperability, failure-rate or customer-outcome measurement.
Read the packet, not just the mask
When a same-subnet flow fails, the mask is only the first clue. An operator needs the request and reply on the relevant sub-VLAN, the source address, the router’s address-to-VLAN allocation, the proxy/ARP decision and the forwarding result. For multicast, the relevant RPF state and sender-specific route evidence matter too. These records can establish what the router did at an observation point; they do not automatically prove application success or that every access path was isolated.
Sources
- RFC 3069 — VLAN Aggregation for Efficient IP Address Allocation
- RFC 3069 status and metadata
- IETF Datatracker record for RFC 3069
- RFC 826 — Ethernet Address Resolution Protocol
- RFC 1027 — Using ARP to Implement Transparent Subnet Gateways
- RFC 2644 — Changing the Default for Directed Broadcasts
- RFC 1812 — Requirements for IPv4 Routers
- RFC 4562 — MAC-Forced Forwarding
- RFC 4632 — Classless Inter-domain Routing
- Running-Code Primacy
- Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
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
