skip to content

An organisation enabling IPv6 is asked to put NAT at its edge so internal hosts stay hidden as they were under IPv4; how do you weigh that request?

level: principalimportance: should knowfreq 21%

answer

  1. separate the goals behind the request
  2. default-deny is a firewall rule
  3. prefix translation, not port translation
  4. unique local and temporary addresses
  5. what IPv4 NAT cost you

basics

~20 s

Unbundle it: inbound protection comes from a stateful default-deny firewall, host privacy from temporary addresses, internal-only services from unique local addresses. NPTv6 (RFC 6296) solves renumbering and multihoming but adds no security, and the IETF does not recommend NAT for IPv6.

solid answer

~50 s

"Hide our hosts" bundles several goals, and IPv6 answers each without translation. Blocking unsolicited inbound connections is what IPv4 NAT did by accident; a stateful firewall with default-deny does it as explicit, logged policy. Tracking of client hosts is handled by temporary addresses (RFC 8981, which replaced RFC 4941), and services that must never be reachable can sit on unique local addresses (`fc00::/7`, RFC 4193). If the real need is address independence across providers, NPTv6 (RFC 6296, Experimental) rewrites prefixes statelessly - but RFC 6296 itself says it carries none of NAPT44's security benefit, keeps hosts reachable and that the IETF does not recommend NAT for IPv6. Stateful port-sharing NAT for IPv6 would bring back ALGs, traversal machinery, per-flow state and asymmetric-routing fragility. My recommendation: firewall plus ULA plus temporary addresses, NPTv6 only for a documented multihoming case.

go deeper

for a junior

Recall that IPv6 has enough addresses that NAT is not needed, and that protection comes from a firewall rather than from translation.

for a middle

Explain what NPTv6 rewrites and why it preserves reachability, and what unique local and temporary addresses each provide.

for a senior

Show how you would protect an IPv6 edge in practice: default-deny stateful filtering, verified on enablement, and the IPv4 rules that NAT had made implicit.

for a principal

Lead the decision: unbundle the security team's goals, map each to a mechanism, state the cost of reintroducing stateful translation and record the reasoning.

## Unpack the request "Put NAT in front so we stay hidden" usually bundles four different goals. Separate them, because IPv6 answers each one differently: | What the team wants | What provides it in IPv6 | |---|---| | Nothing outside can open connections in | A stateful firewall with default-deny inbound | | Outsiders cannot track individual client hosts | Temporary addresses (RFC 8981) | | Internal-only services are never reachable from outside | Unique local addresses (`fc00::/7`, RFC 4193) that are not routed externally | | Internal numbering survives a provider change or multihoming | Provider-independent space, or prefix translation (NPTv6, RFC 6296) | ## Why NAT is the wrong tool for the first goal IPv4 NAT blocks unsolicited inbound traffic only because nothing matches a mapping, and its filtering behaviour decides what may come back. A stateful firewall provides the same default-deny explicitly, with reviewed exceptions, logs and outbound rules. RFC 6296 states that the IETF does not recommend Network Address Translation for IPv6, and the IETF has published no standard for stateful IPv6-to-IPv6 address and port translation. Building one anyway brings back every cost of IPv4 NAT: - application-level gateways for protocols that carry addresses in their payload; - traversal machinery for peer-to-peer and real-time media; - per-flow state, with its capacity limits, failover breakage and asymmetric-routing fragility; - broken integrity protection for the IP header, such as the IPsec Authentication Header. ## What NPTv6 does and does not give NPTv6 (RFC 6296, **Experimental**) is a stateless, one-to-one rewrite of the network prefix, designed to be checksum-neutral so transport headers are left alone. It provides **address independence**: inside the site hosts keep a stable prefix while the outside prefix can change or differ per provider. RFC 6296 is explicit about its limits: - any security benefit NAPT44 might offer is **not present**, so a firewall is still needed; - end-to-end reachability is preserved - an inside host remains reachable at its translated address; - applications that write addresses into payloads may still need ALGs; - because the mapping is algorithmic, several translators need no shared state and tolerate asymmetric routing. NPTv6 is a multihoming and renumbering tool, not a hiding tool. ## The hiding argument itself - **Topology**: interior addresses are visible in IPv6 headers, but visibility is not reachability; with IPv4 NAT the protection came from the absence of mappings, never from the hiding. - **Host tracking**: temporary addresses (RFC 8981, which replaced RFC 4941) rotate the interface identifier clients use for outgoing connections, so external observers cannot easily correlate a host over time. - **Scanning**: a /64 subnet holds 2^64 addresses, so blind sweeping is impractical, but attackers harvest addresses from DNS, logs and observed traffic instead - obscurity, not a control. ## A defensible recommendation 1. Write the inbound default-deny as **firewall policy** at every IPv6 edge, and verify it on the day IPv6 is enabled, not after. 2. Use global addresses for hosts that need the internet, unique local addresses for purely internal services, and temporary addresses on clients. 3. Consider NPTv6 only for a concrete multihoming or renumbering problem, and record that it provides no security. 4. Audit the IPv4 side for rules that were never written because NAT made them implicit - they are the same gaps. ## How to run the conversation Treat the request as a requirement to be clarified, not a proposal to be refused. Ask which incident or audit finding it is meant to prevent, then show the mapping from that concern to the IPv6 mechanism that addresses it. Security teams often accept the firewall-first design once the default-deny is demonstrated on a test edge and the evidence they need - rule review, logs, change control - is shown to be stronger than an implicit translation side effect ever was. ## The tradeoff to own Saying no has a cost: the firewall must be maintained, and the security team must accept that internal addresses are visible to the hosts they talk to. Saying yes has a larger one: years of gateways, traversal and per-flow state on a protocol designed to be free of them, plus a security posture that still depends on a side effect. Most organisations land on firewall plus unique local addresses, with NPTv6 reserved for the narrow multihoming case - but the answer should follow from which of the four goals the team actually holds.

  • If NPTv6 hides the internal prefix, why does RFC 6296 say it gives no security benefit?
    The mapping is one-to-one and algorithmic, and it works in both directions, so an outside host can reach an inside host simply by addressing its translated address. Nothing is dropped for lack of a mapping, which is the only blocking IPv4 NAPT provided by accident. RFC 6296 therefore says a firewall is still needed for any such protection.
  • What do unique local addresses give that a global address behind a firewall does not?
    Addresses from `fc00::/7` (RFC 4193) are not routed on the internet, so a service numbered only with them cannot be reached across the internet - a second layer beneath the firewall - and its address stays stable when the provider prefix changes. Hosts that also need the internet carry a global address alongside.

saying these in an interview costs you the question

  • IPv6 hosts are exposed to the internet unless NAT is added.
  • NPTv6 provides the same protection as IPv4 NAPT.
  • The IETF recommends NAT66 for enterprise IPv6 edges.
  • A /64 is too large to scan, so no IPv6 firewall is needed.
  • Temporary addresses stop inbound connections to a host.