When a service that sat behind an IPv4 NAT gains IPv6 addresses, what becomes reachable, and what must the design review add?
answer
- globally routable host addresses
- every listener, both families
- prefix translation keeps reachability
- obscurity of a /64 is not policy
basics
~20 sIPv6 gives each host globally routable addresses with no translation, so every socket listening on all addresses becomes reachable from the internet. The review must add an explicit default-deny stateful policy for IPv6 and matching host rules for both families.
solid answer
~50 sBehind the IPv4 NAT, inside hosts had no public address, so unsolicited inbound traffic had nowhere to go. With IPv6 each host gets one or more global unicast addresses and the edge simply routes, so everything bound to all addresses, including admin, metrics and database ports, is now addressable. The review should list listening ports per family, put a default-deny stateful policy for IPv6 at the edge that matches the IPv4 intent, mirror host firewall rules for IPv6, and publish AAAA records only for services meant to be public. Two shortcuts do not count: NPTv6 (RFC 6296, Experimental) is stateless prefix translation that keeps every host reachable, and the size of a /64 does not hide hosts whose addresses leak through DNS, logs and predictable identifiers. The policy must also leave room for the ICMPv6 error messages IPv6 depends on.
go deeper
Remember that IPv6 hosts have globally routable addresses with no translation, so blocking inbound traffic needs an explicit firewall rule.
Explain why exposure grows: services bound to all addresses, per-family rule sets, and IPv6 enabled by default on most platforms.
Run the review: per-family listener inventory, default-deny stateful policy, host rule parity, deliberate AAAA publication, and why NPTv6 or /64 size are not controls.
Argue for one security intent expressed for both families from a single source, owned explicitly, instead of inheriting protection from address scarcity.
## The scenario A service runs on hosts with private IPv4 addresses behind a translator at the edge. Nobody ever wrote an inbound policy for most of those hosts, because nothing outside could address them. Now the network is being given **IPv6**, and the design review has to decide what changes. ## What IPv6 changes about reachability IPv4 address exhaustion is why the NAT existed. IPv6 removes the shortage, and its architecture assumes **end-to-end addressing**: - each interface receives one or more **global unicast** addresses (currently allocated from `2000::/3`), alongside its link-local address; - the edge router **routes** those addresses; the base protocol defines no translation for traffic that stays within IPv6; - so every inside host is now addressable from anywhere, and the only thing deciding whether a packet reaches it is **filtering policy**. The protection the NAT gave was a side effect: an unsolicited inbound packet had no mapping and therefore no inside destination. IPv6 does not carry that side effect over, so the intent must be written down. ## What becomes reachable | Exposure | Why it appears with IPv6 | |---|---| | Services bound to all addresses | They now listen on the host's global IPv6 addresses too | | Admin, metrics, debug and database ports | They were "internal" only because nothing could address them | | Hosts with IPv4-only firewall rules | Rule sets are per family; IPv6 traffic matches none of them | | Networks believed to be IPv4-only | RFC 8504 notes most platforms enable IPv6 by default | ## What the review must add 1. **Inventory listeners per family.** For every host, list which ports answer on IPv6 and decide which should. 2. **A default-deny stateful policy for IPv6 at the edge.** Allow return traffic for connections initiated from inside, deny unsolicited inbound, and explicitly allow published services. Express the same intent for both families from one source of truth. 3. **Host-level rule parity.** Every host rule that exists for IPv4 needs its IPv6 counterpart. 4. **Deliberate publication.** Add AAAA records (RFC 3596) only for services meant to be public; internal names should not leak global addresses. 5. **Room for ICMPv6.** IPv6 relies on ICMPv6 error messages, above all Packet Too Big, because routers never fragment, so the policy cannot simply drop ICMPv6 the way some IPv4 edges dropped ICMP. 6. **Test from outside over IPv6**, not only over IPv4. ## Two shortcuts that do not count as controls - **NPTv6** (RFC 6296, Experimental) translates one prefix to another, statelessly and one-to-one, with no port mapping. It preserves end-to-end reachability: every inside host still has an outside address. RFC 6296 says plainly that any security benefit NAPT44 might offer "is not present in NPTv6, necessitating the use of a firewall". - **The size of a /64.** Brute-forcing 2^64 interface identifiers is impractical, but addresses leak through AAAA records, logs, outbound connections and reverse lookups, and many hosts use predictable identifiers such as `2001:db8::1` or MAC-derived ones. Stable-privacy identifiers (RFC 7217) make guessing harder; they do not enforce policy. ## What is not new - The stateful policy itself is ordinary firewalling; nothing about it is IPv6-specific except that it can no longer be skipped. - Link-local traffic, including Neighbor Discovery, never crosses the edge router; its protection is a local-network concern. - Outbound connections work the same way: the inside host opens the flow and the stateful filter admits its replies. ## The judgement to show A weak answer says "IPv6 is less secure because it has no NAT". A strong answer says that reachability is now decided by policy rather than by address scarcity, so the review must make that policy explicit, cover both families from one intent, and reject NPTv6 and address-space size as substitutes.
- Does NPTv6 give an IPv6 site the protection that NAPT gave in IPv4?No. RFC 6296 defines NPTv6 as stateless, one-to-one prefix translation with no port mapping, and it preserves end-to-end reachability: every inside host still has an outside address. The RFC states that any security benefit of NAPT44 is not present and a firewall is needed. NPTv6 is also only Experimental.
- Why does a network that believes it is IPv4-only still need IPv6 rules?Because its hosts very likely run IPv6 anyway: RFC 8504 notes most platforms enable it by default, so every interface has a link-local address and can configure global ones as soon as a router advertises a prefix. Traffic over that family matches no IPv4 rule, so explicit IPv6 policy, or IPv6 deliberately disabled, is the only safe state.
An IPv4 NAT is like an apartment block with one street door and a concierge who only admits replies to calls residents placed; nobody designed it as security, the building just had one door. IPv6 gives every flat its own street door, so each one needs a lock and a written rule about who may enter.
saying these in an interview costs you the question
- IPv4 firewall rules automatically cover the same hosts over IPv6.
- NPTv6 protects an IPv6 site the same way NAPT protected IPv4.
- A /64 is too large to scan, so IPv6 hosts need no filtering.
- IPv6 is inherently less secure because it has no NAT.
- An IPv4-only network needs no IPv6 rules at all.