D3-BDI Broadcast Domain Isolation: Limiting LAN reach and proving it holds

On a flat LAN every host can see every other host's broadcasts and talk to it directly, so one compromised laptop, printer or camera can scan, poison and attack its neighbours without crossing a firewall. MITRE D3FEND names the countermeasure Broadcast Domain Isolation (D3-BDI) and defines it as "Broadcast isolation restricts the number of computers a host can contact on their LAN." It sits under the Isolate tactic as a child of Network Isolation, beside Directional Network Link, DNS Allowlisting, DNS Denylisting, Encrypted Tunnels and Network Traffic Filtering, and D3FEND gives "Network Segmentation" as its synonym. This card explains how the technique works, why D3FEND lists no ATT&CK mapping for it, where it is implemented on switches, wireless and virtual networks, and how to prove the isolation holds. It is written for network engineers and security architects. Where vendor features are named, vendors are listed alphabetically; the order is not a ranking.

Key takeaways

• It shrinks the neighbourhood. The goal is that a host can reach only the LAN peers it needs, typically its gateway and a few services, rather than everything on the segment.
• Layer 2 only. Broadcast isolation stops direct host-to-host frames; traffic that goes up to the router and back down is a separate path that needs routing and filtering controls.
• No ATT&CK mapping in D3FEND. D3FEND lists no related ATT&CK techniques for D3-BDI. The threats it addresses are still well known: the private VLAN specification names port scans and ARP poisoning.
• Infrastructure-dependent. D3FEND's only consideration is that the technique is "highly dependent on network infrastructure and networking requirements"; every switch in the path has to support and enforce it.
• Test from the host's point of view. Verification means trying to reach a neighbour from an isolated port, not reading the switch configuration.

D3-BDI at a glance

How it works

A broadcast domain is the set of hosts that receive each other's Layer 2 broadcasts, normally one VLAN. Plain VLANs already split a network into broadcast domains; D3-BDI goes further and restricts which hosts inside one domain or subnet may exchange frames at all. Three mechanisms do most of the work.

• Private VLANs: described in RFC 5517 (Informational, February 2010, an independent submission from Cisco). A primary VLAN is paired with secondary VLANs. Isolated ports talk only to promiscuous ports; community ports talk to their own community and to promiscuous ports; promiscuous ports, where gateways and DHCP servers connect, talk to everyone. All of them share one IP subnet. The RFC states that properly deployed, this segregation can contain threats such as port scans and ARP poisoning.
• Wireless client isolation: access points and controllers can stop wireless clients on the same SSID from exchanging frames directly, forcing traffic through the gateway. Feature names differ between vendors.
• Virtual and software-defined networks: hypervisor virtual switches and SDN overlays can intercept broadcasts and forward them only to permitted destinations, which is the model D3FEND's article describes.

Vendor examples of private VLAN behaviour

• Cisco: RFC 5517 documents Cisco's private VLAN design: one isolated secondary VLAN per primary VLAN, multiple community VLANs, and isolation carried across inter-switch links so it stays consistent between switches.
• Juniper Networks: Junos documentation describes promiscuous, community, isolated access and PVLAN trunk ports, and states that "Isolated ports have Layer 2 connectivity only with promiscuous ports and PVLAN trunk ports". Each secondary VLAN is its own broadcast domain, and a primary VLAN can contain only one isolated VLAN. The documentation lists platform-specific limits, such as some features that cannot be combined with PVLAN interfaces.

ATT&CK techniques and D3-BDI

D3FEND lists no ATT&CK techniques for D3-BDI, direct or inferred, and its Local Area Network Traffic artefact has no ATT&CK relations in the D3FEND ontology. The table below is therefore an NHI Mgmt Group view, not a D3FEND mapping: it shows LAN-adjacent techniques where restricting who a host can reach on its segment is relevant. Each ID was checked against ATT&CK v20.

These attacks are covered in depth in the Layer 2 Attacks Guide, MITRE ATT&CK T1557 Adversary-in-the-Middle and MITRE ATT&CK T1040 Network Sniffing.

Where it fits best

For small organisations, client isolation on guest wireless and a separate VLAN for IoT devices deliver most of the value with no new hardware. Large estates usually combine private VLANs with network access control so that ports get the right isolation role automatically; see the Network Access Control (NAC) Guide. Where finer east-west control is needed between workloads, microsegmentation is the next step; see the Microsegmentation Buyers Guide.

Implementation steps

1. Map who needs to talk to whom. For each segment, list the peers each host type genuinely needs: gateway, DHCP, DNS, backup, cluster partners. Everything else is a candidate for isolation.
2. Check every switch and access point. Confirm all devices in the path support the feature. RFC 5517 warns that a switch without support in a mixed network may forward traffic it should block, including permanent flooding of unicast frames.
3. Design the roles. Put gateways and shared services on promiscuous ports, independent hosts on isolated ports, and hosts that must talk to each other in community VLANs.
4. Close the router path. Isolation is Layer 2 only: hosts in the same subnet can still reach each other through the router. Add ACLs or firewall rules on the gateway interface for any host-to-host traffic you do not want routed back.
5. Pilot on one segment. Start with guest wireless or an IoT VLAN, watch for broken discovery, printing or clustering, and fix with community VLANs or explicit gateway rules.
6. Roll back per port. Keep the previous port configuration so a single port or SSID can be returned to normal while a problem is investigated, rather than removing isolation from the whole segment.

How to verify it works

• Peer reachability test: from a test host on an isolated port or SSID, confirm it cannot reach a neighbour by ARP, ping or a TCP connection, and that it can still reach the gateway and permitted services.
• Router path test: repeat the test at Layer 3 to confirm gateway ACLs block routed host-to-host traffic where intended.
• Configuration audit: compare port roles on every switch and access point to the design, including newly added devices, since one unconfigured switch breaks isolation for the segment.
• Authorised testing: include Layer 2 attacks such as ARP spoofing from a test port in authorised penetration tests, and record whether neighbours were reachable.

Limits, bypasses and failure patterns

• Routing around the isolation: traffic sent to the gateway and routed back to a neighbour is not stopped by Layer 2 isolation; gateway filtering is required.
• Mixed hardware: an older or third-party switch that does not enforce private VLANs can flood frames the design meant to block.
• Exceptions that grow: moving a device to a promiscuous port to fix a problem gives it reach to every isolated host.
• Broken discovery leads to rollback: printers, casting and building systems that rely on broadcast or multicast stop working, and isolation is removed under pressure. Plan gateway-based alternatives first.
• Treating isolation as the whole segmentation strategy: D3FEND lists "Network Segmentation" as a synonym, but segmentation between zones still needs VLAN design and firewalling; see M1030 Network Segmentation and the Zero Trust Network Segmentation Playbook for Flat Networks.

Framework mapping

Related countermeasures

• Network Traffic Filtering (D3-NTF): the filtering at the gateway that closes the routed path; see D3-NTF Network Traffic Filtering.
• Directional Network Link (D3-DNL): one-way links for the strictest separation; see D3-DNL Directional Network Link.
• Network Isolation: the parent technique; the wider framework is in the MITRE D3FEND Guide.

Practitioner checklist

• Document required peer communication for each segment before isolating it.
• Confirm every switch and access point in the path supports and enforces isolation.
• Turn on client isolation for guest and IoT wireless networks.
• Use isolated ports for independent hosts and community VLANs only where peers must talk.
• Add gateway ACLs to block routed host-to-host traffic you do not want.
• Pair isolation with DHCP snooping and dynamic ARP inspection on trusted ports.
• Run a peer reachability test from an isolated port each quarter.
• Keep an owner and end date for every isolation exception.

Standards and references

• MITRE D3FEND: Broadcast Domain Isolation (D3-BDI)
• IETF RFC Editor: RFC 5517 Cisco Systems' Private VLANs
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-7, SC-32)
• Juniper Networks: Understanding private VLANs (Junos OS)

Related NHI Mgmt Group resources: Layer 2 Attacks Guide · M1030 Network Segmentation · DHCP Security Guide · Zero Trust Network Segmentation Playbook for Flat Networks · MITRE D3FEND Guide