Shaggy IPv6

Shaggy IPv6: Why These Mask Recommendations Make Me Shiver

✍️ Written by: RJS Expert
A critical look at IPv6 subnet sizing misconceptions and why /64 is non-negotiable.

When I recently saw a design table recommending IPv6 prefixes like /119, /118, /117, /116 based on site count, I had to blink twice.

No. Just no.

That's IPv4-style thinking, and it breaks fundamental IPv6 design principles.

🛑 Don't Even Think About Using These Tiny IPv6 Masks

The intention seems harmless: right-size the subnet based on the size of the network.

✔ Perfectly valid in IPv4.
❌ Completely wrong in IPv6.

🛑 RFC 7421 + RFC 4291 Are Unambiguous

Any IPv6 L2 segment intended to use SLAAC must be a /64.

• Not "mostly."
• Not "unless it's a small branch."
• Not "unless the WAN pool is tight."

➡️ Always /64.

Why?

SLAAC, ND, ICMPv6 behavior, and interface identifiers all rely on a 64-bit host portion.

Shrink it and you're not optimizing — you're breaking protocol behavior.

🔋 "But what about address exhaustion?"

This is IPv4 scarcity thinking leaking into IPv6.

For perspective:

• MAC addresses are only 48 bits
• OUIs are allocated in 24-bit chunks
• After 40 years, roughly 0.3% of the address space is allocated

If the MAC namespace isn't anywhere close to exhaustion…
Your IPv6 WAN pool certainly isn't either.

🛑 So Why Do These Small Prefix Recommendations Exist?

Because IPv4 reflexes are hard to kill:

IPv4 Thinking	small site → small subnet big site → big subnet
IPv6 Reality	Any L2 segment → /64 No exceptions.

That makes sense in IPv4.
It has no place in IPv6.

⚠️ "But Smaller Prefixes Prevent ND Table Exhaustion!"

Wrong fix.

The correct engineering controls are:

• ND throttling
• ND cache limits
• RA-Guard / ND-Guard

You don't break the protocol to protect the equipment.
You reinforce the equipment to handle the protocol.

🛑 IPv6 Is Not IPv4 With Bigger Addresses

This is the real root cause.

IPv4 thinking is deeply ingrained.
We all have to consciously suppress it when designing IPv6.

IPv6 was built around different fundamentals:

IPv6 Design Principle	Why It Matters
✔ Stable /64 L2 subnets	SLAAC, ND, and protocol operation depend on it
✔ SLAAC + RA-driven operations	Autoconfig without DHCP, 64-bit interface IDs
✔ Clean aggregation	Predictable hierarchy, no VLSM micromanagement
✔ Hierarchical delegation	/48 → /56 → /64 structure scales globally

Trying to "right-size" IPv6 subnets the IPv4 way is not optimization —
it's protocol damage.

➡️ Conclusion: Keep IPv6 Clean — Respect the /64

When someone recommends a /119 as a subnet mask, something has gone very wrong.

If IPv6 had been designed with variable subnet sizing per site count, it would have collapsed under its own complexity years ago.

IPv6's purpose is simplicity, not address conservation.

Best practice remains extremely simple:

• 👉 Always use /64.
• 👉 Do not shrink it.
• 👉 Stop applying IPv4 conservation logic to IPv6.

Common IPv6 Subnet Sizing Myths vs Reality

Myth	Reality
"Small sites need small subnets"	❌ Breaks SLAAC. Always use /64 regardless of site size.
"We'll run out of IPv6 addresses"	❌ IPv4 scarcity thinking. IPv6 has 340 undecillion addresses.
"Smaller masks protect against ND exhaustion"	❌ Wrong approach. Use ND throttling and cache limits instead.
"Point-to-point links can use /127"	✔ Correct! RFC 6164 specifically allows /127 for P2P links.
"We need to conserve our /48 allocation"	❌ A /48 gives you 65,536 /64 subnets. Plan properly, don't shrink.

📖 Key RFCs to Understand:

• RFC 4291: IPv6 Addressing Architecture (defines /64 interface ID boundary)
• RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing
• RFC 4862: IPv6 Stateless Address Autoconfiguration (SLAAC requires /64)
• RFC 6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links (the ONLY exception)

"IPv6 is not a bigger IPv4. It's a different protocol with different rules. Respect the /64."

Final Word:

If your IPv6 design includes subnet masks like /119, /118, /117, or /116 for L2 segments, you're not optimizing — you're breaking the protocol.

The fix is simple: Use /64. Always.

IPv6 freed us from address scarcity. Don't drag IPv4's conservation neurosis into a protocol that was designed to eliminate it.