RFC 1918 vs RFC 6598: When to Use 100.64.0.0/10

For 25 years, "private IP" meant one of three RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. In 2012, the IETF published RFC 6598, which reserved a fourth large block — 100.64.0.0/10 — specifically for ISP carrier-grade NAT. That range is neither public nor RFC 1918 private; it sits in a third category that is now heavily used in cloud and overlay networking.

This article explains exactly what 100.64.0.0/10 is, when to use it, and the operational implications versus pure RFC 1918 space.

The original problem: ISP NAT

By 2010, IPv4 exhaustion was forcing ISPs to NAT their own customers. A mobile carrier serving 50 million subscribers might only have 1 million public IPv4 addresses — so they NAT subscribers behind a smaller pool of public IPs. This is CGNAT (Carrier-Grade NAT), also called LSN (Large-Scale NAT).

The problem: which IP range do ISPs use for the subscriber side of the NAT? The obvious answer is RFC 1918, but that breaks for any subscriber who is also running RFC 1918 internally. A home customer with 192.168.1.0/24 behind their router cannot have their ISP's CGNAT also assign them 192.168.x.x — routing collapses.

RFC 6598 solved this by reserving a new range that ISPs could use for CGNAT without colliding with customer-internal networks:

100.64.0.0/10  =  100.64.0.0 - 100.127.255.255  (4,194,304 addresses)

Properties of RFC 6598 space

For the network operator's purposes, RFC 6598 space behaves almost identically to RFC 1918: filtered at the internet edge, routable within your private network, never assignable to public destinations. The only meaningful difference is the convention — RFC 6598 was meant for ISPs, but the IETF did not prohibit other uses.

Modern uses beyond ISPs

Over the past decade, RFC 6598 space has been adopted for several use cases that ISPs did not anticipate:

Cloud secondary CIDRs

AWS VPCs allow up to 4 secondary CIDR blocks beyond the primary. These secondary blocks must not overlap with the primary, which is challenging if the primary is already RFC 1918. Adding 100.64.0.0/16 as a secondary gives you 65,536 additional addresses without burning more RFC 1918 space.

This is especially common for EKS clusters. The primary VPC stays under 10/8, but pod IPs come from a CGNAT secondary CIDR. See our Kubernetes CIDR sizing article for the full pattern.

Overlay networking (Tailscale, WireGuard meshes)

Tailscale assigns each node an address in 100.64.0.0/10 by default. This works because the user's home network is almost certainly RFC 1918, and using CGNAT space eliminates a routing collision.

Container networking

Some Kubernetes CNI plugins (especially Cilium) use CGNAT space for cluster-wide IPs to avoid colliding with user VPC CIDRs.

VPN concentrators

Corporate VPN servers commonly assign clients from RFC 6598 to avoid collisions with the user's home network.

When to use RFC 6598 vs RFC 1918

Use RFC 1918 (10/8 or 172.16/12 or 192.168/16) when

• You are designing a greenfield network with no external integration constraints.
• Your network is small (under 1,000 hosts), and RFC 1918 has plenty of room.
• You are not worried about future peering with other networks that might use the same range.

Use RFC 6598 (100.64/10) when

• Your primary VPC CIDR is already RFC 1918 and you need a secondary range.
• You are deploying EKS with VPC CNI and want pods isolated from VM/RDS address space.
• You are building an overlay network (Tailscale, mesh VPN) that needs to coexist with user-internal RFC 1918 networks.
• You are migrating from one RFC 1918 network to another and need a temporary "bridge" range that does not collide with either source or destination.

Pitfalls to be aware of

Some ISPs filter incoming 100.64

Because 100.64/10 is reserved for ISP-internal CGNAT, some ISPs filter inbound traffic from that range — they assume any 100.64 traffic crossing their boundary must be misconfigured. If you use 100.64 in a way that traverses third-party networks, this can silently break connectivity.

Some firewalls treat it as untrusted

Older firewall vendors did not update their default trust zones when RFC 6598 came out. You may need to manually add 100.64/10 to "trusted internal" zones, or it will be treated like public internet space.

Mobile devices use it

If your network has Wi-Fi users on mobile carriers, those devices may be NAT'd at the carrier in 100.64 space. Connecting them to a corporate Wi-Fi network that also uses 100.64 internally creates the classic NAT collision. Choose your CGNAT subnet carefully if you have mobile-heavy user bases.

Smaller pool than RFC 1918

100.64/10 has 4 million addresses. RFC 1918 has 17.9 million. For very large organizations, CGNAT is not a complete replacement for RFC 1918; it is a supplement.

Allocation patterns

Within an organization using both RFC 1918 and RFC 6598, a useful pattern is:

10.0.0.0/8       Primary corporate network (VMs, databases, users)
100.64.0.0/10    Container, overlay, and serverless workloads
172.16.0.0/12    Lab, isolated test environments
192.168.0.0/16   Office Wi-Fi (where small subnets are convenient)

This separates address space by workload type, which makes routing tables, firewall rules, and operational debugging easier.

Detecting CGNAT space in traffic

If you see 100.64.x.x as a source on your internet uplink, that is almost always a leaked CGNAT from a customer's ISP. ISPs are supposed to filter it at their edge, but mistakes happen. Modern bogon-filtering BGP feeds (Team Cymru, SpamHaus DROP) include 100.64/10 in the standard bogon list.

Inside your own networks, 100.64 traffic should be normal if you have adopted it for any of the use cases above. Audit your firewall logs periodically to make sure 100.64 traffic is going where you expect.

Key takeaways

• RFC 6598 reserves 100.64.0.0/10 (4M addresses) for ISP carrier-grade NAT.
• It behaves like RFC 1918 in most respects: filtered at internet edges, routable internally.
• Modern use cases include cloud VPC secondary CIDRs, Kubernetes pod IPs, overlay networks (Tailscale), and VPN client pools.
• Most common pattern: use RFC 6598 as a secondary VPC CIDR for EKS pods to keep your primary RFC 1918 space free.
• Pitfalls: some ISPs filter inbound 100.64 traffic, mobile carriers may already NAT users from it, and older firewalls may treat it as untrusted.