Stop Thinking in IPv4: Misconceptions That Sabotage Your IPv6 Deployment

Audience: isp6 members, cloud architects, network engineers, and security practitioners migrating workloads to IPv6 — especially those with years of IPv4 muscle memory.

Last updated: April 2026

Table of Contents

1. Introduction
2. Misconception 1: Microsegment Your Subnets
3. Misconception 2: Block All ICMP
4. Misconception 3: You Still Need NAT
5. Misconception 4: ULA Is the New RFC 1918
6. Misconception 5: You Need to Bolt On IPsec
7. Misconception 6: Scan the Subnet to Find Hosts
8. Bonus: Taming the Hex — Readable Firewall Rules
9. Summary Cheat Sheet
10. References & RFCs

1. Introduction

Engineers who have spent years optimising IPv4 networks bring hard-won instincts to IPv6 deployments. Many of those instincts — conserve addresses, block ICMP, hide behind NAT — were rational responses to IPv4's constraints. But applying them to IPv6 is like rationing water in a submarine: the scarcity model no longer fits.

This document identifies the most common IPv4 reflexes that actively harm an IPv6 deployment, explains why they made sense in IPv4, and shows what to do instead.

If you are an isp6 member deploying your PA allocation for the first time — whether via BYOIP to a cloud provider or on your own infrastructure — these are the mental model shifts that will determine whether your deployment succeeds cleanly or stalls on problems that were solved at the protocol level years ago.

If you are entirely new to the protocol, start with Designing the Next Internet: An Introduction to IPv6 for a ground-up tour of address anatomy, scopes, and the SLAAC bootstrap — this article then corrects the IPv4 reflexes that most commonly survive into a fresh IPv6 deployment.

flowchart LR
    subgraph ipv4["IPv4 World"]
        direction TB
        A["Conserve addresses"]
        B["Block all ICMP"]
        C["NAT everything"]
        C2["ULA = RFC 1918"]
        D["Bolt on IPsec"]
        D2["Scan the subnet"]
        E["Hex is unreadable"]
    end
    subgraph ipv6["IPv6 World"]
        direction TB
        F["Use a /64 per subnet"]
        G["ICMPv6 is load-bearing"]
        H["End-to-end is restored"]
        H2["Use Global Unicast"]
        I["It's built into the stack"]
        I2["Flow telemetry + inventory"]
        J["Plan prefixes for humans"]
    end
    A --> F
    B --> G
    C --> H
    C2 --> H2
    D --> I
    D2 --> I2
    E --> J

2. Misconception 1: Microsegment Your Subnets

The IPv4 Instinct

In IPv4, address space is scarce and expensive. A /24 gives you 254 usable hosts, and wasting addresses on a subnet with only three servers feels irresponsible. So we learned to carve /28s, /29s, and /30s — and spent years managing the resulting VLSM complexity.

Why It's Wrong in IPv6

A single /64 subnet contains 2^64 addresses — roughly 18.4 quintillion. That is more addresses in one subnet than the entire IPv4 internet has in total. Splitting a /64 into /80s or /96s to "avoid waste" is a reflex from a scarcity model that no longer applies.

More importantly, it breaks things. Core IPv6 mechanisms depend on a /64 boundary:

The Rule

Give every subnet a /64. No exceptions for end-host subnets.

The only legitimate deviations from /64 are defined by the IETF:

The /127 exception is not just about conserving nibbles — it closes a real attack surface. A p2p link numbered as a full /64 exposes roughly 18 quintillion unconfigured addresses on the router's interface. An attacker flooding that range forces the router into perpetual Layer 2 resolution, filling the neighbour cache and starving legitimate traffic — a Neighbor Cache Exhaustion attack (RFC 6583). A /127 restricts the active space to two addresses (one per end), eliminating the attack surface entirely. Reserve the full /64 in your IPAM for the link, but configure /127 on the interfaces. See Planning your isp6 allocation for the threat model and configuration pattern.

Prefix Paranoia: The Numbers

Engineers who accept the /64 rule intellectually still hesitate to allocate generously, fearing they will "run out" of prefixes. The global data says otherwise:

• Even with worldwide IPv6 adoption approaching 50%, only 0.7% of the 2000::/3 global unicast allocation is in use (APNIC IPv6 measurement).
• Within a typical enterprise /48, fewer than 0.1% of the available 65,536 /64 subnets are utilised.

Do not compromise your routing topology or avoid clean nibble boundaries to save a resource that will not run out. Assign /64s freely — one per VLAN, one per availability zone, one per service tier. The address space is not the constraint; your numbering discipline is.

What This Means in Practice

A /48 allocation — the standard enterprise assignment and the minimum for AWS BYOIP — gives you 65,536 /64 subnets. That is more subnets than most organisations will ever need.

2001:db8:acad::/48

If you hold a /44 allocation from isp6, the hierarchy gains a third tier. A /44 contains 16 /48 blocks — sized to assign one /48 per cloud region or per account. Each region's /48 is then subdivided into /64 subnets for its availability zones and service tiers, following the same model as the single-region case above, independently per region. The last nibble of the third address group selects the region; the fourth group selects the subnet within that region.

2001:db8:a100::/44 (16 × /48 available)

3. Misconception 2: Block All ICMP

The IPv4 Instinct

In IPv4, ICMP was treated as a security liability. Smurf attacks, ICMP redirect abuse, and network reconnaissance via ping sweeps led to a widespread "block all ICMP" firewall posture. For IPv4, this was aggressive but broadly survivable — TCP and UDP continued to function, and Path MTU Discovery failures could (sometimes) be masked by MSS clamping.

Why It's Catastrophic in IPv6

In IPv6, ICMPv6 is not optional — it holds the stack up. Blocking ICMPv6 indiscriminately does not just degrade performance; it breaks fundamental network operations that have no alternative mechanism.

ICMPv6 (RFC 4443) subsumes the functions of ARP, ICMP, and IGMP from the IPv4 world. The Neighbor Discovery Protocol (NDP, RFC 4861) runs entirely over ICMPv6. Block it, and your hosts cannot discover routers, resolve link-layer addresses, or detect duplicate addresses.

ICMPv6 Message Types: What They Do and What Breaks

The table below categorises the essential ICMPv6 messages. For the full filtering guidance, see RFC 4890.

Error Messages (Types 1–127) — Must Not Be Dropped

NDP Messages (Types 133–137) — Must Not Be Dropped on Local Links

Multicast Listener Discovery (Types 130–132, 143)

Informational Messages (Types 128–129)

The NDP Dependency Chain

To understand why you cannot "just block a few types," consider how NDP messages depend on each other:

flowchart TD
    Start(["Host boots up"])
    RS["1. Router Solicitation (Type 133)<br>Host: 'Are there any routers on this link?'"]
    RA["2. Router Advertisement (Type 134)<br>Router: 'Here is prefix 2001:db8:acad:1::/64,<br>default route via me, MTU 1500'"]
    DAD["3. Duplicate Address Detection — DAD (Type 135)<br>Host: 'Is anyone already using the address I generated via SLAAC?'"]
    NS["4. Neighbor Solicitation (Type 135)<br>Host: 'What is the link-layer address of the gateway?'"]
    NA["5. Neighbor Advertisement (Type 136)<br>Gateway: 'My MAC address is aa:bb:cc:dd:ee:ff'"]
    Online(["Host is online. Block ANY step above and it isn't."])

    Start --> RS --> RA --> DAD --> NS --> NA --> Online

ICMPv6 in the Cloud (AWS)

In AWS, the infrastructure handles NDP at the hypervisor level — your EC2 instances do not need to process raw Router Advertisements or Neighbor Solicitations themselves. However, ICMPv6 still matters:

• Security Groups are stateful and automatically allow return ICMPv6 traffic (including Packet Too Big) for established connections. If you configure a security group to allow outbound IPv6 traffic, the inbound PMTUD response is permitted implicitly.
• Network ACLs are stateless. You must explicitly allow ICMPv6 Type 2 (Packet Too Big) inbound if you use NACLs, or PMTUD will break for traffic traversing tunnels or VPN links with reduced MTU.
• Echo Request/Reply (Types 128/129) must be explicitly allowed in security groups if you want ping6 to work — AWS does not allow these by default.

See AWS Security Group Rules Reference for ICMPv6 configuration examples.

The Rule

Do not apply a blanket "deny all ICMPv6" policy. Follow RFC 4890 for filtering guidance. At minimum, always permit Types 1–4 (errors), 128–129 (echo), and 133–136 (NDP).

4. Misconception 3: You Still Need NAT

Why NAT Exists in IPv4

NAT was never a security feature — it was a survival mechanism. When the IETF realised in the early 1990s that the 4.3 billion IPv4 addresses would not be enough, NAT (RFC 3022) was introduced to allow multiple hosts to share a single public address. It became ubiquitous because it solved three practical problems simultaneously:

These were real benefits in IPv4. But they came at a significant cost:

mindmap
  root((The Hidden Costs of NAT))
    Breaks end-to-end connectivity
      Peer-to-peer, VoIP, gaming
    Requires ALGs for protocols embedding addresses
      SIP, FTP, H.323
    Complicates logging
      5-tuple and timestamps for attribution behind CGNAT
    Adds state to the network path
      Lost during failover, all connections reset
    Prevents inbound connections
      Without explicit port forwarding
    Makes IPsec AH mode impossible
      Requires NAT-T workaround, RFC 3947

Why IPv6 Doesn't Need It

IPv6 eliminates the root cause: there is no address scarcity. A single /48 allocation provides 65,536 /64 subnets, each with 2^64 host addresses. Every device gets a globally unique address. With scarcity gone, the three problems NAT solved in IPv4 are addressed differently:

RFC 4864 ("Local Network Protection for IPv6") formally documents how IPv6 achieves equivalent or better protection than NAT44 without address translation.

The End-to-End Principle Restored

Without NAT, IPv6 restores the original design intent of IP: any host can communicate directly with any other host, constrained only by policy (firewalls), not by architectural translation layers. This simplifies:

• Peer-to-peer protocols — WebRTC, SIP, and gaming work without STUN/TURN/ICE traversal hacks.
• Logging and forensics — source addresses are globally meaningful; no need to correlate NAT translation logs with flow records.
• IPsec — AH and ESP work end-to-end without NAT Traversal encapsulation.
• Application architecture — no ALGs, no port forwarding rules, no hairpin NAT.

When Translation Still Appears in IPv6

The IETF explicitly recommends against NAT for IPv6 (RFC 6296, Section 1). However, two translation mechanisms exist for specific transition scenarios:

Neither of these is "NAT as you know it." NAT64 is a transition crutch that should be retired as IPv4 dependencies are eliminated. NPTv6 is stateless, checksum-neutral, and does not map ports — it avoids the worst pathologies of NAT44.

The Rule

Do not deploy NAT66 (stateful IPv6-to-IPv6 NAT). Use stateful firewalls for security, Privacy Extensions for topology hiding, and BYOIP or NPTv6 for provider independence. Use NAT64 only as a transition mechanism to reach IPv4-only endpoints.

5. Misconception 4: ULA Is the New RFC 1918

The IPv4 Instinct

In IPv4, RFC 1918 private addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are the bedrock of enterprise networking. Every data centre, every corporate LAN, every home router uses them. When engineers accept that NAT is unnecessary in IPv6, their next instinct is to reach for the closest equivalent: Unique Local Addresses (ULA, RFC 4193, fc00::/7).

The reasoning seems sound: "We don't need NAT, but we still want private, non-internet-routable addresses for internal traffic." ULA appears to be exactly that.

Why It's a Trap

ULA has two structural problems that make it a poor default for enterprise IPv6 deployments:

1. Architectural Limitations

2. RFC 6724 Kills Your IPv6 Traffic

This is the subtle, devastating problem. On a dual-stack host (IPv4 + IPv6), the operating system uses RFC 6724 ("Default Address Selection for IPv6") to decide which source and destination address to prefer when multiple options exist.

RFC 6724's default policy table ranks address types by precedence:

ULA (precedence 30) ranks below IPv4-mapped addresses (precedence 35). On a dual-stack host with both an IPv4 address and a ULA IPv6 address, the operating system will always prefer IPv4. You can engineer a flawless dual-stack network, publish AAAA DNS records, and configure every router correctly — and your IPv6 traffic will remain at zero because the host's address selection algorithm deprioritises ULA in favour of IPv4.

flowchart TD
    Host["Dual-Stack Host<br>Has: IPv4 + ULA IPv6"]
    DNS["DNS returns A + AAAA"]
    RFC["RFC 6724<br>Address Selection"]
    IPv4["IPv4 path selected<br>(precedence 35)"]
    IPv6["ULA IPv6 path ignored<br>(precedence 30)"]

    Host --> DNS --> RFC
    RFC -->|"Preferred"| IPv4
    RFC -->|"Deprioritised"| IPv6

    style IPv4 fill:#d4edda,stroke:#28a745
    style IPv6 fill:#f8d7da,stroke:#dc3545

This is not a misconfiguration — it is the correct, standards-compliant behaviour. The only way to ensure IPv6 is preferred on dual-stack hosts is to use Global Unicast Addresses, which have a higher precedence than IPv4-mapped addresses.

The Rule

Use Global Unicast Addresses (GUA) as your default IPv6 addressing strategy. ULA is not the IPv6 equivalent of RFC 1918 — it is a niche tool for air-gapped networks that will never need internet connectivity. For everything else, use GUA from your isp6 allocation behind stateful firewalls. If you need multi-homing without PI space, use NPTv6 (RFC 6296) with GUA, not ULA.

6. Misconception 5: You Need to Bolt On IPsec

The IPv4 Instinct

In IPv4, IPsec was an afterthought — a separate protocol suite layered on top of a network layer that had no native security. Deploying IPsec meant additional software, configuration complexity, and often dedicated hardware accelerators. Many organisations avoided it entirely, relying instead on TLS at the application layer.

IPv6: IPsec Is Part of the Architecture

IPv6 was designed with IPsec as an integral part of the protocol stack, not an add-on. The two IPsec headers — Authentication Header (AH, RFC 4302) and Encapsulating Security Payload (ESP, RFC 4303) — are defined as IPv6 extension headers, processed natively by the IPv6 stack.

flowchart TB
    A["IPv6 Header<br>(Next Header = ESP)"] --> B["ESP Header"]
    B --> C["TCP / UDP"]
    C --> D["Payload"]
    D --> E["ESP Trailer"]

flowchart TB
    A["IPv4 Header"] --> B["IPsec Headers (AH / ESP)"]
    B --> C["TCP / UDP"]
    C --> D["Payload"]

What Changed: MUST → SHOULD

The requirement level for IPsec support in IPv6 implementations has evolved:

The downgrade from MUST to SHOULD reflects practical reality: not every constrained device (IoT sensors, embedded systems) can implement full IKEv2 + ESP. But for servers, network infrastructure, and cloud workloads, IPsec support is present in the stack by default. You do not need to install additional software or purchase dedicated appliances — the capability is there, ready to be configured.

What This Means for Your Deployment

• Host-to-host encryption is available without TLS termination proxies or VPN tunnels. ESP in transport mode encrypts the payload between two IPv6 hosts with no intermediate infrastructure.
• Network-to-network tunnels (ESP in tunnel mode) work cleanly because there is no NAT in the path to interfere with AH integrity checks or require NAT-T encapsulation.
• IPsec is not a replacement for TLS. Use IPsec for network-layer encryption (host-to-host, site-to-site); use TLS for application-layer authentication and encryption. They complement each other.
• In cloud environments (AWS, GCP, Azure), managed VPN and transit gateway services handle IPsec tunnel negotiation. The "built-in" nature of IPsec in IPv6 means the overhead of establishing these tunnels is lower, but the operational model is similar to IPv4 VPNs.

The Rule

Do not treat IPsec as something you need to "add" to IPv6. It is already part of the protocol architecture. Plan your encryption strategy knowing that every IPv6 node in your infrastructure (excluding constrained IoT devices) already has IPsec capability in its network stack.

7. Misconception 6: Scan the Subnet to Find Hosts

The IPv4 Instinct

In IPv4, vulnerability scanning and host discovery are straightforward. A /24 subnet has 254 usable addresses. A security team can enumerate every host in seconds with nmap -sn 192.168.1.0/24, run a full port scan of the entire subnet in minutes, and maintain a near-real-time inventory of every device on the network. This brute-force approach works because the search space is small enough to exhaust.

Many organisations build their entire security posture on this foundation: periodic subnet scans, vulnerability assessments against discovered hosts, and compliance reports showing "100% of assets scanned." The implicit assumption is that scanning the address range is equivalent to scanning the network.

Why It's Impossible in IPv6

A single /64 subnet contains 2^64 addresses — approximately 1.8 × 10^19 (18.4 quintillion). To put this in perspective:

Even at theoretical line rate, scanning a single /64 takes longer than recorded human history. The brute-force approach that underpins IPv4 security scanning is mathematically impossible in IPv6.

This is not a temporary tooling gap — it is a fundamental property of the address space. No amount of hardware or parallelism will make exhaustive /64 scanning viable.

What to Do Instead

IPv6 requires a shift from address-space enumeration to active host inventory and flow telemetry. You cannot find hosts by scanning for them; you must know where they are because you put them there or because they announced themselves.

In cloud environments, this shift is already the norm. AWS, GCP, and Azure maintain authoritative registries of every ENI, NIC, and VM — you query the cloud API for your inventory, not the network. IPv6 extends this principle to on-premises and hybrid networks.

The Rule

Do not attempt to scan IPv6 subnets by address range. Build your security posture on authoritative host inventories (IPAM, CMDB, cloud APIs), NDP monitoring, and flow telemetry. Redefine "complete coverage" as "all known assets scanned," not "all addresses probed."

8. Bonus: Taming the Hex — Readable Firewall Rules

The Problem

A 128-bit address written in hexadecimal is intimidating. When engineers see firewall rules referencing 2001:0db8:acad:0042:a9f3:2e1b:8c05:7d3a/128, cognitive load spikes and misconfigurations follow. This leads to a perverse outcome: teams avoid writing granular IPv6 firewall policies because the addresses are "too hard to read."

The Solution: Plan Your Prefixes for Humans

The vast address space of IPv6 is not just about scale — it is an opportunity to encode meaning into your addressing scheme. When you control your prefix allocation (as you do with BYOIP), you can design subnet IDs that are simple, sequential, and self-documenting.

Example: A Readable Allocation Scheme

Starting from a /48 allocation of 2001:db8:acad::/48, assign subnet IDs using a simple ascending pattern that encodes environment and purpose:

Allocation: 2001:db8:acad::/48

Firewall Rules That Read Like English

With this scheme, firewall and security group rules become self-documenting. Compare:

Before (unplanned addressing):

  Source: 2001:db8:acad:a3f2::/64
  Dest:   2001:db8:acad:7b01::/64
  Port:   443
  Action: ALLOW

  # What does this rule do? No one knows without a spreadsheet.

After (planned addressing):

  Source: 2001:db8:acad:1::/64     # Prod / Web Tier
  Dest:   2001:db8:acad:2::/64     # Prod / App Tier
  Port:   443
  Action: ALLOW

  # Web tier can reach App tier on HTTPS. Obvious.

Aggregation for Broad Policies

By aligning your numbering to nibble boundaries (multiples of 4 bits), you can write aggregate rules that cover entire environments with a single prefix:

Tip: Align your subnet numbering to nibble boundaries (/52, /56, /60) so that route aggregation and firewall summarisation work cleanly. A /60 gives you 16 contiguous /64 subnets — usually enough for one environment. Plan this before you assign the first address.

Avoid the Mapping Trap

A tempting shortcut is to preserve IPv4 muscle memory by embedding the old octets inside IPv6 hex strings — for example, assigning 10.0.0.1 as 2001:db8:acad::1000:0001, or folding a /24 into the final nibble group. Do not do this. The IPv4 octet boundary is 8 bits; the IPv6 addressing architecture is designed around 4-bit nibbles. Mapping 10.0.0.0/24 into an IPv6 host portion puts meaningful structure at bit offsets that do not align to hex characters, breaking reverse-DNS zone delegation, defeating route aggregation, and producing subnet IDs that read as random hex to anyone who was not present when the scheme was invented. Design the IPv6 hierarchy on its own terms — the address space is large enough that you never need to reuse IPv4 semantics to save space.

Reserve the 0th Subnet for Core Infrastructure

The first subnet block in any allocation (…:0::/64 within a /48, or the first /48 within a /44) should be reserved for shared core infrastructure: loopbacks, point-to-point links, management networks, and anything else that is not a routable customer or workload subnet. Keeping core infrastructure at a predictable, low-numbered prefix makes firewall allow-lists, monitoring scopes, and route filters easier to write, and leaves the "first interesting block" (…:1::/64 onwards) free for the hierarchical assignment scheme that readers will actually see in logs and dashboards.

The Rule

Design your prefix plan for human readability. Use simple, sequential subnet IDs (1, 2, 3...) and align to nibble boundaries for aggregation. When you control the allocation, there is no reason for firewall rules to be a wall of inscrutable hex.

9. Summary Cheat Sheet

What isp6 Handles

Several of the corrections above are already resolved for isp6 members before you touch a cloud console or a router:

For step-by-step BYOIP guides that show exactly what isp6 handles and what you configure on the cloud side, see the AWS, Azure, and Google Cloud guides.

10. References & RFCs

Core IPv6 Specifications

ICMPv6 and Neighbor Discovery

NAT and Network Protection

IPsec

ULA and Address Selection

Host Discovery and Flow Telemetry

Address Planning

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.