IPv4 taught me to count addresses carefully.
An AWS IPv4 /28 contains sixteen positions.
AWS reserves five.
Eleven remain.
A load balancer, several interfaces and one enthusiastic deployment later, the subnet begins making worried noises.
IPv4 /28
16 total positions
- 5 AWS reservations
= 11 assignable
IPv6 presents a different starting point.
A normal /64 subnet contains:
2^(128 - 64)
= 2^64
= 18,446,744,073,709,551,616 addresses
That is more addresses in one subnet than the entire IPv4 address space repeated more than four billion times.
The immediate reaction is often:
Excellent.
I no longer need to think
about addressing.
The correct reaction is:
Excellent.
I need to think about
addressing differently.
IPv6 removes the need to squeeze ordinary networks into tiny host pools.
It does not remove the need to design:
- routing hierarchy
- network boundaries
- prefix ownership
- DNS
- security policy
- address assignment
- internet reachability
- cloud-provider implementation
- transition from IPv4
- operational evidence
The scarce object changes.
In IPv4, it is often the individual address.
In IPv6, it is more likely to be:
- well-structured prefixes
- manageable routes
- understandable policy
- supported services
- engineering attention
IPv6 did not abolish network planning. It stopped making host-address conservation the most interesting part of it.
IPv6 contains 128 bits
An IPv4 address contains 32 bits.
An IPv6 address contains 128.
IPv6 defines unicast, anycast and multicast address types. It does not define broadcast.
Writing 128 binary digits would be unpleasant, so IPv6 is written in hexadecimal.
One hexadecimal digit represents four bits.
0000 = 0
1001 = 9
1010 = a
1111 = f
An IPv6 address contains eight groups of four hexadecimal digits. Each group represents sixteen bits.
2001:0db8:1234:5678:9abc:def0:1234:5678
8 groups × 16 bits = 128 bits
Hexadecimal does not change the address.
It makes the binary value compact enough for people to read without requiring a scroll bar and a packed lunch.
Example-address note: The
2001:db8::/32range used throughout this article is reserved for documentation by RFC 3849. It is suitable for examples and must not be used as live production address space.
IPv6 text can be compressed
Leading zeros inside a group may be removed.
0db8 → db8
0004 → 4
0000 → 0
Therefore:
2001:0db8:0000:0000:0000:0000:0000:0042
can become:
2001:db8:0:0:0:0:0:42
One consecutive run of all-zero groups may then be replaced by :::
2001:db8::42
The double colon may appear only once because the reader must be able to determine how many groups were omitted.
These strings describe the same address:
2001:db8::42
2001:0db8:0:0:0:0:0:42
2001:DB8:0000:0000:0000:0000:0000:0042
RFC 4291 permits several textual forms. RFC 5952 recommends a canonical representation for logs, configuration and user interfaces. Its recommendations include lowercase hexadecimal, removal of leading zeros and consistent zero compression.
Systems should store addresses as addresses where possible, not as arbitrary case-sensitive strings.
Canonical text makes the human-facing form predictable.
The prefix still draws the boundary
IPv6 uses CIDR notation in the same general way as IPv4.
address/prefix
The prefix states how many leading bits belong to the routed network.
For example:
2001:db8:1234:5600::/56
has:
56 prefix bits
72 remaining bits
A /64 has:
64 prefix bits
64 interface-identifier bits
The arithmetic is unchanged:
addresses = 2^(address width - prefix)
The address width changed from 32 to 128.
The planning consequences are larger than the arithmetic change.
IPv4 subnetting often asks:
Can I fit 220 resources
inside this /24?
IPv6 planning should more often ask:
Which /64 belongs to this link?
Which larger prefix owns that /64?
Can related prefixes be aggregated?
Which routing and security policy
should apply to the link?
The prefix remains a boundary.
Individual address positions beyond it stop being the main capacity concern.
A /64 is the ordinary subnet unit
IPv6 unicast addressing commonly uses a 64-bit subnet prefix and a 64-bit interface identifier.
|---------- 64 ----------|---------- 64 ----------|
2001:db8:1234:0056 0000:0000:0000:0042
This produces:
2001:db8:1234:56::42
Many IPv6 mechanisms and operational recommendations assume a 64-bit interface identifier for ordinary links. Stateless Address Autoconfiguration, for example, combines a router-advertised prefix with an interface identifier.
The practical lesson is not:
Every conceivable IPv6 route
must always be /64.
Host routes, point-to-point designs and delegated prefixes can use other lengths.
The practical lesson is:
Do not size ordinary IPv6 subnets
according to expected host count.
The /64 boundary is intentional. It supports standard host configuration, stable subnet design and predictable delegation. RFC 7421 explains why the 64-bit boundary is deeply embedded in IPv6 architecture.
The subnet prefix describes a link and its policy treatment.
It is not a tightly packed container purchased one address at a time.
One /56 contains 256 /64 subnets
A /56 allocation contains:
64 - 56 = 8 subnet bits
Eight bits create:
2^8 = 256 /64 subnets
Suppose an organisation receives this example allocation:
2001:db8:1234:5600::/56
Its /64 subnet boundaries include:
2001:db8:1234:5600::/64
2001:db8:1234:5601::/64
2001:db8:1234:5602::/64
...
2001:db8:1234:56ff::/64
The useful capacity statement is:
one /56
256 ordinary /64
subnet boundaries
not:
one /56
an incomprehensibly large pile
of host addresses
Those subnet identifiers can express architecture.
For example:
00-1f development
20-3f staging
40-7f production
80-9f shared services
a0-bf observability and security
c0-ff reserved
This is only an illustrative plan.
The important shift is that the subnet field can encode controlled hierarchy without squeezing the interface space beneath it.
Cloud providers apply their own prefix rules
The /64 is the normal host-subnet model, but cloud platforms differ in how they allocate the parent space and expose addresses to resources.
| Platform | Typical or required model | Important provider detail |
|---|---|---|
| AWS | Amazon-provided VPC space commonly begins as /56; ordinary subnets commonly use /64 |
Supported allocation sources can provide VPC CIDRs from /44 to /60 and subnet CIDRs from /44 to /64, in four-bit increments |
| Azure | A virtual network may hold a larger customer-defined IPv6 range; every IPv6 subnet must be exactly /64 |
Microsoft planning guidance suggests hierarchical allocations such as /56 per virtual network and /64 per subnet |
| Google Cloud | Internal IPv6 begins with a /48 ULA range on the VPC network; each internal subnet receives a /64 |
VM interfaces and several regional resources receive /96 ranges from the subnet |
The exact platform limits can change, and individual services add further constraints. The architectural default remains simple:
larger governed allocation
│
▼
ordinary subnet /64
│
▼
provider-specific assignment
The hierarchy is portable.
The implementation is not identical.
Stop counting hosts and start allocating structure
In IPv4, I may choose among:
/24
/25
/26
according to expected resource count.
In IPv6, I can give each ordinary subnet a /64 and use higher-level allocations to express architecture.
organisation prefix
│
▼
cloud or regional prefix
│
▼
environment or network prefix
│
▼
subnet /64
│
▼
provider or host assignment
An example hierarchy can divide an organisation prefix by cloud, region, environment and network.
Within one network:
production network
│
├── public-entry-a /64
├── public-entry-b /64
├── public-entry-c /64
├── application-a /64
├── application-b /64
├── application-c /64
├── data-a /64
├── data-b /64
├── data-c /64
└── reserved /64s
The addresses remain abundant.
The subnet identifiers remain finite enough to govern.
An unstructured ocean is still difficult to navigate.
IPv6 has several important address types
Not every IPv6 address means the same thing.
Global unicast
Global unicast addresses are globally unique and routable according to network policy.
A globally unique address is not automatically reachable from the internet. Reachability still depends on routes, gateways, firewalls, security groups, network security groups and application listeners.
Link-local
Link-local addresses use fe80::/10.
They support communication on the local link and participate in router and neighbour discovery.
fe80::1234:5678:9abc:def0
They are not routed as ordinary global traffic.
Unique local
Unique Local Addresses occupy fc00::/7.
For locally assigned ULAs under RFC 4193, the L bit is set to one, which places the usable locally generated space under fd00::/8. A ULA /48 should include a pseudo-random 40-bit global identifier so that independently created networks are unlikely to collide when later connected.
fd9a:91b2:7c30::/48
Do not choose an attractive sequence as another version of 10.0.0.0/8.
fd00:1234::/48
may be valid syntax, but memorability is not a uniqueness strategy.
Cloud providers impose additional rules.
| Platform | Private or internal IPv6 convention |
|---|---|
| AWS | Private IPv6 is allocated through VPC IPAM. AWS supports private ULA VPC ranges under fd80::/9, with VPC allocations from /9 to /60, and can also use customer-owned GUA space privately |
| Azure | Customer-defined IPv6 virtual-network space can use ULA ranges under fc00::/7; IPv6 subnets must be /64 |
| Google Cloud | Google-provided internal IPv6 uses a VPC-level /48 selected from fd20::/20; each internal subnet receives a /64 from that range |
The example fd9a:91b2:7c30::/48 is a valid locally assigned ULA and also falls inside AWS’s supported private ULA space. It is not valid as a manually selected Google Cloud internal range because Google Cloud requires that /48 to come from fd20::/20.
The lesson is:
RFC-valid address
does not automatically mean
provider-valid allocation
Multicast
IPv6 multicast addresses begin with ff.
Multicast delivers a packet to a group of interfaces.
Anycast
An anycast address is assigned to more than one interface. Routing delivers traffic to one of them, commonly the nearest according to the routing system.
Anycast uses unicast address formats. Its behaviour comes from assignment and routing rather than a visibly separate prefix.
Special individual addresses
:: unspecified
::1 loopback
IPv6 has no broadcast
IPv6 defines unicast, anycast and multicast.
It does not define broadcast.
Functions that IPv4 often handled through broadcast are implemented through multicast or more specific discovery mechanisms.
Broadcast says:
Everyone on this segment,
please inspect this.
Multicast says:
Members of this group,
this packet is for you.
The final address in an IPv6 subnet is therefore not a broadcast address.
A provider may still reserve particular positions for platform use. AWS, for example, reserves the first four and final IPv6 addresses in a VPC subnet. Azure reserves its first four IPv6 subnet addresses for management.
Those reservations matter when assigning explicit addresses, but they do not create an IPv4-style capacity concern inside a /64.
Neighbor Discovery replaces more than ARP
IPv4 commonly uses ARP to discover the link-layer address associated with a local IPv4 address.
IPv6 uses Neighbor Discovery, carried through ICMPv6.
Neighbor Discovery supports:
- discovering neighbouring nodes
- resolving link-layer addresses
- locating routers
- learning prefixes and link parameters
- maintaining reachability information
- redirecting nodes towards better first hops
RFC 4861 defines these behaviours.
IPv6 destination
│
▼
Is it on-link?
│
▼
Discover neighbour or router
│
▼
Resolve link-layer destination
│
▼
Transmit frame
This is why indiscriminately blocking ICMPv6 is not a sensible hardening strategy.
ICMPv6 is not merely optional ping traffic. It carries control-plane functions required for normal IPv6 operation.
Security policy should allow the ICMPv6 types required by the design rather than treating every ICMP packet as decorative noise.
Hosts can configure addresses, but the platform still owns the subnet
IPv6 supports Stateless Address Autoconfiguration.
A router advertises information about the link, including usable prefixes.
A host combines the advertised prefix with an interface identifier and performs Duplicate Address Detection.
RFC 4862 defines the process.
ROUTER
advertises prefix
│
▼
HOST
creates interface identifier
│
▼
COMBINED ADDRESS
│
▼
DUPLICATE ADDRESS DETECTION
IPv6 environments may also use DHCPv6, explicit assignment or provider-controlled delegation.
The protocol model does not mean a cloud instance can invent any address from its subnet and expect the fabric to route it.
Cloud control planes normally govern address ownership:
- AWS associates IPv6 addresses or delegated prefixes with an ENI.
- Azure assigns static or dynamic private IPv6 configurations to network interfaces.
- Google Cloud assigns
/96address ranges to VM interfaces and supported forwarding resources.
The operating system participates in IPv6 configuration.
The platform still decides which addresses or prefixes belong to the resource.
A globally unique address is not an open door
IPv4 has trained many people to associate private addresses and NAT with security.
IPv6 separates addressing from reachability more clearly.
A workload can have a globally unique address while remaining unavailable to unsolicited internet traffic.
GLOBALLY UNIQUE ADDRESS
│
▼
PUBLIC INGRESS PATH?
│
▼
ROUTING POLICY PERMITS IT?
│
▼
SECURITY POLICY PERMITS IT?
│
▼
APPLICATION LISTENING?
A private operating model can therefore be expressed as:
NO PUBLIC INGRESS PATH
+
STATEFUL SECURITY POLICY
+
NARROW LISTENERS
=
PRIVATE OPERATION
The exact control differs by provider.
AWS offers an egress-only internet gateway for outbound IPv6 connections without allowing internet hosts to initiate connections through that gateway.
Azure and Google Cloud use their own combinations of public address assignment, routes, firewalls and service-specific egress products.
The general rule is stable:
Address scope, routing and security are separate decisions.
Public and private IPv6 are deployment choices
The phrase “global unicast” describes address architecture, not cloud exposure.
Clouds support three broad models:
public GUA with restricted reachability
ULA for internal routing
customer-owned GUA used privately
The final model preserves global uniqueness while keeping internet advertisement disabled.
The term private IPv6 is therefore provider-specific.
In AWS it can mean ULA or customer-owned GUA allocated through a private IPAM scope and not advertised by AWS.
In Google Cloud, an internal subnet can use Google-provided ULA or a BYOIP GUA prefix used privately.
In Azure, customer-defined ULA or unadvertised customer-owned GUA space can be used in the virtual network, while public exposure is configured separately.
The useful question is not merely:
Is this address global or local?
It is:
Who allocated the prefix?
Who advertises it?
Which route permits the path?
Which policy permits the flow?
NAT is no longer required for address conservation
IPv4 NAT became common partly because globally unique IPv4 addresses were scarce.
many private IPv4 addresses
│
▼
NAT
│
▼
one or several public IPv4 addresses
IPv6 does not need this model for ordinary address conservation.
Removing address-conservation NAT can improve architectural clarity:
- source addresses remain visible
- overlapping private ranges become less likely
- cross-network routing is easier to reason about
- fewer translation tables sit in the path
- applications can communicate end to end where policy allows
This does not mean every IPv6 workload must be publicly reachable.
It means routing and security policy can create the boundary without rewriting every address.
NAT and firewalling are different controls.
IPv4 made them frequent roommates.
IPv6 gives us permission to stop introducing them as twins.
Provider-specific public-IP products also differ. AWS, for example, does not provide IPv6 Elastic IP addresses. An IPv6 address assigned to an ENI remains associated until it is explicitly changed or the interface lifecycle ends, so the IPv4 private-to-public remapping model is unnecessary.
IPv6 still needs to reach IPv4
The internet and cloud-service estate are not uniformly IPv6-only.
An IPv6 workload may still need to reach an IPv4-only endpoint.
DNS64 can synthesise an IPv6 response for a destination that has only an IPv4 record.
NAT64 can translate between the IPv6 client and the IPv4 service.
IPv6-only workload
│
▼
DNS64 synthesised address
│
▼
NAT64
│
▼
IPv4-only destination
This is translation for protocol compatibility.
It is not address-conservation NAT pretending that private IPv6 space is scarce.
Support differs by provider and service. AWS NAT gateways support NAT64 with DNS64. Google Cloud supports DNS64 and NAT64 designs for IPv6-only subnets. Azure’s native service support and transition path must be checked for the workload and region rather than assumed from the IPv4 design.
A transition plan should record which endpoints remain IPv4-only, where DNS64 and NAT64 or a proxy are required, which clients prefer IPv6, and how monitoring distinguishes failures between the two families.
IPv6 adoption changes the shape of translation. It does not cause the IPv4 internet to vanish in a puff of hexadecimal smoke.
Dual-stack means two independent network paths
A dual-stack resource has IPv4 and IPv6 connectivity.
Operationally, this is closer to two parallel routing systems than one network with two address formats.
APPLICATION
│
├── IPv4 address
│ ├── IPv4 route
│ ├── IPv4 security rule
│ └── IPv4 DNS record
│
└── IPv6 address
├── IPv6 route
├── IPv6 security rule
└── IPv6 DNS record
Common failure patterns include:
AAAA record exists, but the IPv6 route is missing
IPv6 route exists, but the firewall allows only IPv4
service listens on 0.0.0.0, but not on ::
monitoring checks IPv4 while clients prefer IPv6
A successful IPv4 health check does not prove the IPv6 path.
A successful IPv6 connection does not prove IPv4 fallback.
Dual-stack is a migration and compatibility strategy.
It also doubles several categories of configuration that must remain correct.
IPv6-only changes the dependency audit
An IPv6-only subnet removes ordinary IPv4 addressing from its workloads.
Before choosing it, verify operating-system support, package repositories, container registries, cloud and identity endpoints, monitoring destinations, external APIs, DNS, load balancers, databases, CI/CD runners and incident tooling.
One forgotten IPv4-only dependency can turn an elegant design into:
IPv6-only workload
cannot download
the package required
to start
The remedy may be:
- a dual-stack endpoint
- DNS64 and NAT64
- a proxy
- a private service endpoint
- retaining dual-stack for that workload
IPv6-only is not the absence of IPv4 planning.
It is a stronger requirement to identify every place IPv4 still survives.
Provider migration rules also differ. Some platforms let an IPv4-only subnet become dual-stack but not IPv6-only. Some require a new subnet for a single-stack transition. That decision belongs in the migration plan, not in an assumption.
Kubernetes changes the practical capacity story
IPv6 removes much of the individual-address pressure common in IPv4 Kubernetes designs, but the service allocator still matters.
The questions remain:
Which range supplies node addresses?
Which range supplies Pod addresses?
Does the platform allocate individual addresses
or delegated prefixes?
What quota or interface limit becomes
the real capacity constraint?
Amazon EKS provides one concrete example.
For EC2-backed IPv6 clusters, the Amazon VPC CNI uses prefix delegation. It assigns a /80 IPv6 prefix to an ENI slot and allocates Pod addresses from that prefix.
subnet /64
│
▼
delegated /80
│
▼
Pod IPv6 addresses
The raw address count inside the /80 is enormous.
Practical limits move towards:
- node and Pod density
- ENI limits
- compute capacity
- Kubernetes configuration
- contiguous
/80availability in the subnet - service compatibility
Fargate follows a different model. Each Fargate Pod receives an IPv6 address from its subnet, while the underlying Fargate infrastructure retains IPv4 compatibility.
Other managed Kubernetes services use different node, Pod and service-range models.
IPv6 does not make service allocation irrelevant.
It changes which allocation unit deserves attention.
DNS becomes more important, not less
Long IPv6 addresses strengthen the case for using names.
orders.prod.internal
is easier to maintain than:
2001:db8:1234:5642:39ab:701c:88e2:1049
DNS may provide:
A IPv4 address
AAAA IPv6 address
A dual-stack client may receive both. The selected path depends on client behaviour, reachability and timing.
DNS testing should include A and AAAA records, private and split-horizon zones, stale and negative caching, DNS64 synthesis, service discovery and certificate names.
Hard-coded addresses make renumbering difficult in IPv4.
They become even less attractive when the literal is forty characters long and somebody has compressed the zeros differently in three configuration files.
Security and observability need both families
An IPv4 rule for:
0.0.0.0/0
does not mean:
::/0
Likewise:
10.64.0.0/16
contains no IPv6 addresses.
Enabling IPv6 requires a review of:
- firewall and security-group rules
- network ACLs
- route-table destinations
- load-balancer listeners
- web-application firewall policy
- allow lists
- rate-limiting keys
- logging and alerting queries
A common migration defect is:
IPv4 policy:
narrow and reviewed
IPv6 policy:
allow ::/0
because the service would not work
IPv6 should receive the same policy discipline as IPv4.
Observability systems also expose hidden assumptions:
- database columns too short for IPv6 text
- regular expressions that match only dotted decimal
- dashboards that split fields on colons
- parsers that confuse an address with a port
- allow lists stored as unnormalised strings
- temporary addresses increasing metric cardinality
- redaction rules that miss IPv6
An IPv6 address with a port should be bracketed:
[2001:db8::42]:443
Without brackets:
2001:db8::42:443
the address and port boundary is unclear.
Operational testing should verify:
ingest
parse
normalise
store
search
aggregate
alert
display
An application can support IPv6 perfectly while its incident dashboard files every client under unknown.
That is not complete support.
A staged multi-cloud adoption path
I would not begin by declaring every workload IPv6-only.
The implementation path should produce evidence.
1. Plan the hierarchy
Define the source of public or private IPv6 space, IPAM hierarchy, cloud and regional allocations, /64 subnet assignments, route summaries, naming and ownership.
organisation
│
▼
cloud and region
│
▼
account, subscription or project
│
▼
VPC or virtual network
│
▼
subnet /64
2. Introduce dual-stack in non-production
Keep the working IPv4 path while testing address assignment, routing, AAAA records, firewall policy, public and private egress, flow logs and telemetry.
3. Audit dependencies
| Dependency | IPv4 | IPv6 | Dual-stack | Transition required |
|---|---|---|---|---|
| Container registry | Test | Test | Test | Record |
| Package repository | Test | Test | Test | Record |
| Cloud APIs | Test | Test | Test | Record |
| Observability ingest | Test | Test | Test | Record |
| External partner API | Test | Test | Test | Record |
4. Test managed platforms
For Kubernetes and other managed services, verify workload traffic, service discovery, ingress, databases, telemetry, deployment tooling and IPv4-only dependencies.
5. Choose the production model
The result may be dual-stack networks with IPv6-first workloads, or selected IPv6-only services with translation at explicit boundaries.
The exercise should produce evidence rather than a fashion verdict.
The repeatable IPv6 planning model
For each allocation, ask:
| Area | Question |
|---|---|
| Prefix | Which organisation, cloud, region and network owns it? |
| Subnet | Which /64 belongs to this link or policy boundary? |
| Provider | Which prefix lengths and assignment units does the platform support? |
| Address type | Is the range GUA, ULA, link-local or provider-private GUA? |
| Routing | Who advertises it, and where does ::/0 lead? |
| Security | Which IPv6-specific rules permit the flow? |
| Assignment | Does the host receive an address, a range or a delegated prefix? |
| DNS | Are AAAA, reverse and DNS64 behaviour correct? |
| Transition | Which IPv4-only dependencies remain? |
| Operations | Can logs, metrics and incident tools explain the path? |
IPv6 did not make CIDR knowledge obsolete.
It moved CIDR from host-capacity arithmetic towards hierarchy, route control and governance.
The mental model I am keeping
My earlier model was:
IPv6
IPv4 with more digits
something to enable later
The stronger model is:
IPv6 prefix
│
├── routing hierarchy
├── address type
├── cloud allocation model
└── ownership
│
▼
subnet or link /64
│
├── host address
├── delegated prefix
└── service allocation
│
▼
routes + security + DNS
│
▼
application connectivity
The address width answers how large the space is.
The prefix answers which routing boundary owns it.
The /64 identifies the ordinary link or subnet.
The provider model decides which address or delegated prefix a resource may use.
Routes determine where traffic goes.
Security policy determines whether it is permitted.
Transition design determines how the IPv6 network continues reaching an IPv4 world.
IPv4 taught generations of engineers to treat addresses as scarce inventory.
IPv6 keeps CIDR but changes the centre of gravity.
A subnet is no longer valuable because it contains exactly enough addresses. It is valuable because it occupies the correct place in a clear routing and governance hierarchy.
Raw address count is unlikely to be the constraint inside a /64.
Service quotas, delegated-prefix availability, routing design and implementation support can still be.
IPv6 addresses are abundant.
Coherent architecture remains gloriously finite.
References and further reading
Protocol and addressing
- RFC 8200: Internet Protocol, Version 6 Specification
- RFC 4291: IPv6 Addressing Architecture
- RFC 3849: IPv6 Address Prefix Reserved for Documentation
- RFC 5952: A Recommendation for IPv6 Address Text Representation
- RFC 4193: Unique Local IPv6 Unicast Addresses
- RFC 4861: Neighbor Discovery for IPv6
- RFC 4862: IPv6 Stateless Address Autoconfiguration
- RFC 7421: Analysis of the 64-bit Boundary in IPv6 Addressing
AWS
- Amazon VPC IP addressing
- Amazon VPC CIDR blocks
- Amazon VPC subnet sizing
- Egress-only internet gateways
- DNS64 and NAT64
- Amazon EKS IPv6 addressing
- Amazon EKS prefix mode