← Interview Prep

DC IPv6 with Host-Based Firewalling

A data-center security model where policy is enforced on every host — distributed stateful firewalling and microsegmentation instead of hair-pinning east-west traffic through a central perimeter box.

This is the companion to the plain IPv6 DC fabric page. There we build a routed leaf-spine substrate; here we answer the question that substrate forces: in a large, flat, end-to-end-routable IPv6 fabric, where does the firewall live? The modern answer is on the host — Host-Based Firewalling (HBF).

A big IPv6 DC has no meaningful "inside vs outside" for east-west traffic — every server can route to every other server. A single perimeter firewall can neither see nor scale to that server-to-server volume, and forcing traffic through it adds a latency tax and a blast-radius bottleneck. HBF pushes a stateful, identity-based policy down to every host, so the enforcement point sits right next to the workload and scales linearly with the fleet.

The fabric HBF runs on (brief recap)

HBF is a security model layered on top of the routed IPv6 fabric — it does not replace it. The substrate, covered in depth on the DC IPv6 architecture page, is a leaf-spine (Clos) L3 fabric:

• Routing to the host: L3 goes all the way down; each host/rack advertises its prefix. No large L2 broadcast domains, so no reliance on VLAN/subnet as a security boundary.
• ECMP + BGP: eBGP per-hop with equal-cost multipath spreads flows across every spine — any-to-any bandwidth, no spanning tree.
• Unnumbered / RFC 5549: BGP peers over IPv6 link-local (fe80::/10) and carries IPv4 and IPv6 NLRI without configuring per-link addresses — far less config to manage per port.
• IPv6-native: a /64 per segment, global addressing end-to-end, no NAT.

The takeaway for security: every host is directly routable from every other host. That is exactly why the enforcement problem moves onto the host.

Why host-based firewalling

The classic design puts a big stateful firewall pair at the DC edge and treats "inside" as trusted. That model breaks in a modern DC for three reasons:

HBF inverts this: instead of steering traffic to the policy, the policy travels to the traffic. Enforcement happens at the source and/or destination host, on the path the packet was already taking. Capacity scales with the number of hosts, and there is no central box to hair-pin through or overwhelm.

What HBF is

A stateful firewall enforced on each host — in the kernel, the hypervisor, or the NIC — rather than in a network appliance. The enforcement point is co-located with the workload, so the rules move with the workload (across reschedules, migrations, autoscaling).

Microsegmentation & zero-trust east-west

The point of putting a firewall on every host is not to draw the same coarse zones in more places — it is to make the segments small. The stated goal is the segment of one: every workload is its own zone and nothing may reach it unless a policy explicitly allows it.

• Default-deny: the baseline is "drop." Connectivity is an allow-list, not a subtractive block-list. In a zero-trust model there is no trusted interior.
• Identity/label-based policy, not IP/subnet: rules are expressed over workload identity — tags, labels, security-group membership, service accounts, SPIFFE IDs — e.g. allow app=web → app=db:5432. The controller resolves those labels to the current set of addresses.
• Why not IP? In an autoscaling, containerized, IPv6 fabric, addresses are ephemeral and astronomically numerous (below). An IP-based ACL is stale the moment a pod reschedules. Identity is stable across the workload's lifecycle; the address is not.
• Least privilege by construction: policy describes the small set of flows an app actually needs, so a compromised host can't laterally sweep the fabric — lateral movement is what perimeter-only designs leave wide open.

Policy model & distribution

HBF is only as good as the system that keeps millions of per-host rules correct and current. That is a control-plane problem: authors write high-level intent; a central engine compiles it into the concrete rules each host must enforce.

  Intent (identity/label policy)
        │   "web may talk to db:5432; deny all else"
        ▼
  ┌───────────────────────┐
  │   Policy controller   │   compiles intent → per-host rulesets
  │  (label → address DB) │   resolves labels to current addresses
  └───────────┬───────────┘
              │  push / pull (incremental deltas)
      ┌───────┼───────┬───────────────┐
      ▼       ▼       ▼               ▼
  ┌───────┐┌───────┐┌───────┐     ┌───────┐
  │ agent ││ agent ││ agent │ ... │ agent │   (one per host)
  │nft/eBPF││nft/eBPF││nft/eBPF│    │nft/eBPF│
  └───────┘└───────┘└───────┘     └───────┘
  each host: local ruleset + conntrack state

• Intent → compiled rules: the engine expands label selectors against a live endpoint database into the actual match rules for each host. Only the hosts a policy affects get updated.
• Distribution: a local agent on each host receives incremental deltas (push or watch/pull) and programs the kernel/eBPF maps. Sending only diffs — not the whole table — is what makes this scale.
• Consistency: policy is eventually consistent. During a rollout different hosts may briefly hold different versions, so rules must be written so partial application never opens an unintended path (add allows before removing them on the peer; version/epoch the ruleset).
• Scaling to millions of rules: identity-based policy keeps the rule count proportional to the number of policies, not the number of address pairs; eBPF map lookups and set/interval matching (nft sets) keep per-packet cost roughly O(1) instead of walking a linear chain.
• Stateful on the host: each host keeps its own conntrack table — the return traffic for an allowed flow is permitted by connection state, so you only write rules for the initiating direction. State lives with the enforcement point, which is why there's no central state to synchronize.

IPv6 specifics that matter for HBF

IPv6 is not just "IPv4 with longer addresses" for a firewall — several of its properties directly shape HBF design.

Offload & performance (the low-latency angle)

Enforcing a stateful firewall on the host is not free: every packet costs CPU cycles for classification and conntrack lookups, and each hook adds latency and jitter. In a low-latency / trading context that tax is the whole ballgame, so where enforcement runs matters.

• Host CPU cost: a long iptables chain walked per packet steals cycles from the workload and inflates tail latency. Set/map-based matching (nftables sets, eBPF hash/LPM maps) turns linear scans into near-constant-time lookups.
• eBPF / XDP: enforce at the earliest hook — XDP runs in the driver, before sk_buff allocation — so dropped/allowed decisions happen with minimal overhead and no per-packet chain traversal. See Linux basics & troubleshooting for the kernel datapath context.
• SmartNIC / DPU offload: push classification and conntrack onto the NIC's own cores. Enforcement happens before the packet ever reaches the host CPU — you keep microsegmentation and reclaim host cycles and cut latency/jitter. This is the standard way to make HBF viable on latency-sensitive fleets.
• Rule-count discipline: fewer, identity-scoped rules = fewer lookups = lower latency. The control plane's job is partly to keep each host's active ruleset small.

Tradeoffs: HBF vs centralized perimeter firewall

In practice large DCs run both: a perimeter firewall for coarse north-south and DDoS scrubbing at the edge, and HBF for the fine-grained east-west microsegmentation the perimeter can't see. HBF is "in addition to," not purely "instead of."

Observability & failure modes

Distributing the firewall distributes the debugging. A dropped connection no longer has one place to look — it could be enforced at the source host, the destination host, or dropped by a stale policy on either.

• Distributed flow logging: each host emits allow/deny flow records (and eBPF can export per-policy verdicts). These must be aggregated centrally so you can answer "which rule on which host dropped this flow" without SSH-ing into thousands of machines.
• Fail-open vs fail-closed: the critical design choice for when the policy agent dies.
  • Fail-closed (secure default): if the agent can't confirm policy, deny. Safe, but an agent crash can black-hole a healthy host's traffic — a correlated agent bug can take out a service fleet-wide.
  • Fail-open: keep forwarding on the last-known-good ruleset (or allow) if the agent is down. Preserves availability but risks enforcing stale/no policy. Common compromise: keep the last programmed rules in the kernel and enforce them even if the userspace agent restarts — the datapath survives a control-plane blip.
• "Connection silently dropped" across thousands of hosts: the signature HBF debugging problem. A default-deny with silent drops gives no ICMP back, so the client just times out. Workflow: check the destination host's deny counters/flow logs first (does a rule match this identity?), then the source host's egress policy, then whether the label→address resolution is current (did the pod reschedule to an address the policy hasn't picked up?), and confirm required ICMPv6 (Packet-Too-Big / NDP) isn't being dropped.
• Rollout safety: because policy is eventually consistent, stage changes, watch deny-log deltas, and be able to roll back a ruleset epoch fleet-wide — a bad default-deny push is an outage, not a warning.