IP Addressing and Subnetting Questions

Direct answer

Use global unicast addresses (GUA, the normal publicly routable IPv6 addresses) for internal servers and services by default, and protect internal-only services with firewall policy rather than by address choice. Use Unique Local Addresses (ULA, the fc00::/7 block, in practice fd00::/8) in addition to GUA where you want a stable, never-Internet-routable internal identity: isolated networks, management and infrastructure addressing, labs, and any case where the ISP-assigned prefix may change. ULA is not a substitute for GUA when anything must be reached from the Internet or when the cloud or SaaS provider will not accept it.

What each one is

Implications

• Routing: inside the organisation a ULA prefix is routed like any other, and one /48 (65,536 /64 subnets) can cover the whole enterprise, which also gives a single summary route. Keep it out of external BGP: an outbound prefix filter for fc00::/7 is a must, since leaking it only causes confusion because other networks drop it.
• Inter-site connectivity: over your own WAN, VPN or private links ULA works as well as GUA, and addresses stay unchanged when a site moves provider. Across the Internet it works only inside tunnels, because it cannot be routed publicly.
• Address collisions: the Global ID gives 2^40 values. For two sites that exchange traffic the chance of a clash is 1 in 2^40 (1 in 1,099,511,627,776), about 9.1 x 10^-13. RFC 4193 gives about 4.5 x 10^-9 for 100 interconnected prefixes and 4.5 x 10^-7 for 1,000. Those come from counting pairs: n prefixes form n(n-1)/2 pairs (100 prefixes: 4,950 pairs), and each pair clashes with probability 1/2^40, so 4,950 / 2^40 is about 4.5 x 10^-9. The risk is human, not statistical: people who choose "pretty" values such as fd00::/48 or fd12:3456:789a::/48 collide on merger or partner links, so generate the ID with the RFC 4193 method (a SHA-1 hash, a fixed scrambling function, of a timestamp and a device identifier, keeping the low 40 bits so the result looks random).
• Source selection on dual-addressed hosts: a host with both kinds of address follows the RFC 6724 default policy table, in which every address range carries a precedence (a number; when DNS returns several destinations, the one with the higher number is tried first) and a label (a tag that makes the host pair a source address with a destination of the same kind). GUA matches ::/0 with precedence 40 and label 1; ULA matches fc00::/7 with precedence 3 and label 13. If DNS returns both for one name the host will prefer GUA (40 beats 3), and a ULA destination is reached from a ULA source because both carry label 13. So give a name a ULA record in the internal DNS view (a copy of the zone served only to internal clients) and a GUA record only in the external view if you want internal clients to stay internal.

When ULA is the better choice

• Internal-only systems that must work even when the Internet or the ISP link is down (management plane, storage, cluster interconnects).
• A site whose GUA comes from a single ISP and may change: the ULA stays fixed, so internal DNS, certificates and ACLs do not need updating.
• Lab, test or isolated networks, where never being routable outside is itself the requirement.

When it is insufficient

• Anything reachable from the Internet: public servers need GUA.
• Hosts that must reach IPv6 Internet destinations: a ULA-only host needs GUA as well (the normal pattern), or a translation. Prefix translation exists (NPTv6, RFC 6296, stateless one-to-one rewriting of the prefix), but it breaks the end-to-end addressing that was the reason to adopt IPv6, so use it only when you cannot hold stable GUA.
• Cloud, SaaS or partner platforms that only accept their own or public ranges: check support before designing around ULA.
• Environments where nobody can enforce a rule keeping ULAs inside: the same discipline as private IPv4 applies, plus dual addressing means twice the places to get firewall policy wrong.

Worked example: a random ULA /48 and a site plan

The code follows the RFC 4193 method with pinned inputs so the result reproduces; in production use a fresh timestamp and your own identifier. One /48 for the whole enterprise has 65,536 /64s, and splitting into /52s gives 16 sites with 4,096 /64s each:

import hashlib, ipaddress as ip, math

# RFC 4193 section 3.2.2 method, with pinned inputs so the output is reproducible
ntp_time = (3_900_000_000).to_bytes(8, "big")          # pinned stand-in for a 64-bit NTP timestamp
eui64 = bytes.fromhex("0211223344556677")               # pinned stand-in for an EUI-64
global_id = hashlib.sha1(ntp_time + eui64).digest()[-5:]  # least significant 40 bits
prefix = ip.IPv6Network(((0xFD << 120) | (int.from_bytes(global_id, "big") << 80), 48))
print("site ULA /48:", prefix)
print("/64 subnets in a /48:", 2 ** (64 - 48))
sites = list(prefix.subnets(new_prefix=52))
print("per-site /52 count:", len(sites), "each holds", 2 ** (64 - 52), "x /64")
print("site 0:", sites[0], " site 1:", sites[1])
print("fd00::/8 in fc00::/7:", ip.ip_network("fd00::/8").subnet_of(ip.ip_network("fc00::/7")))

space = 2 ** 40
for n in (2, 100, 1000):
    p = n * (n - 1) / 2 / space
    print(f"{n} interconnected /48s -> collision probability {p:.2e}")

site ULA /48: fd84:f26f:eab1::/48
/64 subnets in a /48: 65536
per-site /52 count: 16 each holds 4096 x /64
site 0: fd84:f26f:eab1::/52  site 1: fd84:f26f:eab1:1000::/52
fd00::/8 in fc00::/7: True
2 interconnected /48s -> collision probability 9.09e-13
100 interconnected /48s -> collision probability 4.50e-09
1000 interconnected /48s -> collision probability 4.54e-07

Reading the output: the script prints one random-looking /48, shows it splits into 16 /52 site blocks of 4,096 /64s each, and shows the clash probability growing with the number of interconnected prefixes but staying tiny. Internal servers get both: a ULA /64 per site tier for the internal identity and a GUA /64 where Internet access is needed, with DNS views deciding which a client sees.

Trade-offs

GUA only is the simplest: one address per host, one set of firewall rules, nothing to translate, and nothing to explain to a partner. ULA plus GUA adds a second address to manage but buys stability. Choose ULA-plus-GUA if the ISP prefix changes (no provider-independent space), choose GUA-only if you own provider-independent space or your provider gives stable prefixes. Whichever you choose, restrict internal services with firewall policy, since an address range alone does not keep traffic out.

Direct answer

Take all of 10.0.0.0/8 as the corporate plan and divide it top-down on bit boundaries (each split fixes a few more leading bits, so every block is a power-of-two size that starts on its own boundary): first into purpose blocks (one block for each region's sites, one for data centres and cloud, one for infrastructure), then by site size class inside each region, then by function inside each site. Each level is one prefix, so a region advertises a single route to the rest of the network, and a new site is only a new block carved from space that was already reserved for its region. Nothing existing changes, so nothing is renumbered.

Level 1: the whole /8 by purpose

Going from /8 to /11 fixes 3 more bits, which cuts the /8 into 8 equal blocks. Each /11 covers 2^(32-11) = 2,097,152 addresses, which is 32 values of the second octet (256 / 8), so the first /11 is 10.0 to 10.31, the next 10.32 to 10.63, and so on.

Giving the data centre and cloud space its own block keeps it separable from branch space. Cloud networks (a VPC in AWS or a VNet in Azure is a customer's private network inside the cloud provider) must not overlap anything reachable over a VPN (an encrypted tunnel across the internet) or a private link (a dedicated provider connection). Corporate use stays out of 172.16.0.0/12 and 192.168.0.0/16 on purpose: home routers and remote users' networks very often use 192.168.x.x, and an acquired company or partner may already use any RFC 1918 range, so keeping two of the three ranges free leaves somewhere to renumber into or translate when an overlap shows up.

Level 2: site size classes inside each region

Inside one region (APAC, 10.64.0.0/11, as the example), split the first three /16s by site size class instead of mixing sizes:

Pools by size class keep every block naturally aligned and make the free space easy to see in IPAM (IP address management, the database of who owns which prefix).

Reading an address back through the plan: take 10.65.12.5. The second octet 65 lies in 64 to 95, so it is inside 10.64.0.0/11, APAC. The block 10.65.0.0/16 is the medium-site pool. Third octet 12 falls in the /22 starting at 10.65.12.0 (slot 3 counting from 0, so the fourth medium site), and the host part .5 sits in the first /27 of the site, which the fixed-offset template below uses for management. The plan is deliberately generous: a rollout of 4 large, 16 medium and 30 small sites uses 4 x 4,096 + 16 x 1,024 + 30 x 256 = 40,448 addresses, about 0.24% of the /8.

Level 3: what to reserve, and what each site gets

• Infrastructure block: 10.192.0.0/16, for example a /24 of router loopbacks (one /32 per device, 256 devices) and a /24 of point-to-point links (/31 each, 128 links). Never allocate these from user ranges, so they stay stable when sites change.
• Fixed offsets inside every site block (a fixed offset means a function always starts the same distance into the site's block): the same function at the same offset in every site (for example the first /27 of any site block is management, then users, voice, printers, guest). Staff can read an address and know what it is, and firewall rules can be written as patterns.
• Rules reserved by policy: the unallocated 10.96.0.0/11 and 10.192.0.0/10 remainder are marked reserved in IPAM; nobody takes a "temporary" block from them without a ticket.
• Gateway convention: .1 of every subnet is the gateway.

Summarisation by region

Each regional hub advertises its /11 (10.0.0.0/11, 10.32.0.0/11, 10.64.0.0/11) into the backbone, so a router in EMEA holds two routes for the other two regions (the Americas /11 and the APAC /11) plus the detail for its own region, instead of one route per site across the company (50 and growing). Two conditions make it hold: every site in a region must come from that region's /11, and the summarising router should carry a discard route for the /11 so traffic to an unallocated address inside the region is dropped rather than looped back toward the default route. A discard route is a route for the whole /11 that points at nowhere: with it, an address inside the /11 that has no more specific route is dropped here, instead of matching the default route (the catch-all route that sends everything unknown toward the backbone), going back out, and being sent in again by the other regions' summaries. The summary also hides site flaps (a link going down and up repeatedly): a site going down changes no route outside its region.

Adding a site without renumbering

New medium site in APAC, with three medium sites already allocated (10.65.0.0/22, 10.65.4.0/22, 10.65.8.0/22): record the next free slot, 10.65.12.0/22, in IPAM, build the site from the fixed-offset template, and advertise it inside the region. The /11 summary is untouched, and no other site is touched. A site that outgrows its block gets a second block from the same pool in the same region, which is still inside the /11 summary (the site then appears as two prefixes locally, a small cost); it does not trigger renumbering.

Pitfalls

• Allocating by "next free /24" with no regional structure: after a few years the summaries are gone and every router carries 50 or more site routes.
• A size class that is too small. Pick the site block for the biggest realistic need of the class, because a changed mask means renumbering; this plan allows a second block as the release valve.
• Overlap with cloud and acquired companies: reserve cloud space now and check for overlap before any VPN or peering is set up.
• Using the whole /8 as a flat pool, with no rule for who allocates, and nothing recorded: IPAM is what stops two engineers taking the same block.

Direct answer

In a spine-leaf fabric, leaf switches are the access switches that servers plug into, and spine switches sit above them; every leaf connects to every spine, so any server is two switch hops from any other. The underlay is the plain routed IP network between those switches, and the overlay is the layer of VXLAN tunnels running on top of it that carries tenant traffic. Separate the fabric's own addresses (what the switches use to talk to each other) from tenant addresses (what workloads use), and give each category its own aligned block. The fabric needs three kinds of address: point-to-point links between leaf and spine switches (the underlay), one loopback per switch (a virtual interface that is always up) for routing identity (the router ID, the number a routing protocol uses to name the device), and one loopback per leaf for the VXLAN tunnel endpoint (VTEP, the address where a leaf starts and ends tunnels). EVPN (Ethernet VPN, the BGP-based control plane that distributes MAC and IP reachability) with VXLAN (Virtual Extensible LAN, which carries Layer 2 segments over a routed IP network) only needs the loopbacks to be reachable across the underlay, because every tunnel runs from one leaf's VTEP loopback to another's and the link addresses are only used between two directly connected neighbours, so links are numbered from a small private block that is never advertised and loopbacks come from small blocks that are. Tenants get a large, separate block sliced per tenant VRF (virtual routing and forwarding instance, a separate routing table per tenant).

Sizing method

Size from the design maximum, not today's build, and round to a power of two:

• Links: spines x leaves, each link a /31 (two addresses; RFC 3021 allows /31 on point-to-point links, and both ends must support it). A 4-spine, 32-leaf fabric has 128 links, so 256 addresses today. The design maximum of 8 spines and 64 leaves is 512 links, so 1,024 addresses, which is exactly a /22.
• Loopbacks: 8 + 64 = 72 devices at maximum, so a /24 (256 /32 addresses) holds the routing loopbacks with room to spare. VTEP loopbacks are a separate /24 for the 64 leaves; if leaf pairs also share a virtual VTEP address, that adds one /32 per pair, and 64 + 32 is still well inside 256.
• Tenants: one /16 per tenant VRF, each holding 256 /24 subnets (one per VLAN/VNI, the virtual network identifier, a number that names one Layer 2 segment across the fabric). A /12 holds 16 such tenants.

Allocation

The fabric infrastructure (10.0.0.0/16) and tenant space (10.16.0.0/12) do not overlap; the checks below confirm it.

Keep it readable and summarizable

• Deterministic link addresses. The link between leaf L (1 to 64) and spine S (1 to 8) uses the /31 at index (L - 1) x 8 + (S - 1) inside 10.0.0.0/22, spine side the lower address, leaf side the upper. Anyone can compute the address of any link and spot a mistake by eye. Worked example: leaf 2 to spine 1 has index (2 - 1) x 8 + (1 - 1) = 8; each /31 is 2 addresses, so the link starts 8 x 2 = 16 addresses into 10.0.0.0/22, which is 10.0.0.16/31, with the spine on 10.0.0.16 and the leaf on 10.0.0.17. The script output below prints exactly that line, leaf2-spine1: 10.0.0.16/31.
• One summary per category. The two loopback /24s sit side by side and form one /23 (10.0.4.0/23), and tenants are one /16 each, so outside the fabric each tenant can be a single route and the fabric's own advertised space is a single /23. Keep tenant /16s contiguous so a group of tenants can still summarise.
• Do not advertise the link block. Only loopbacks must be reachable in the underlay; leaving the /31 links out of the routing protocol shrinks the routing table and the attack surface (an alternative is unnumbered interfaces, where a link borrows the loopback address instead of having its own, which removes the link block entirely).
• Anycast gateway. The same .1 gateway address (anycast: one address held by many devices at once) is configured on every leaf for each tenant subnet, so reserve .1 in every tenant /24 and document it.
• If underlay multicast carries broadcast, unknown-unicast and multicast (BUM) traffic (instead of ingress replication, where the sending leaf makes one unicast copy per remote leaf), reserve a range of group addresses from the administratively scoped 239.0.0.0/8 block and document it with the rest.

Computed checks of the arithmetic above (the link function and every block):

import ipaddress as ip

infra = ip.ip_network("10.0.0.0/16")
p2p = ip.ip_network("10.0.0.0/22")
lo0 = ip.ip_network("10.0.4.0/24")
vtep = ip.ip_network("10.0.5.0/24")
tenants = ip.ip_network("10.16.0.0/12")
SPINES_MAX, LEAVES_MAX = 8, 64

def link(leaf, spine):
    """Link /31 for leaf (1..64) to spine (1..8): spine side even address, leaf side odd."""
    idx = (leaf - 1) * SPINES_MAX + (spine - 1)
    net = ip.ip_network((int(p2p.network_address) + 2 * idx, 31))
    return net, net[0], net[1]

print("max links:", SPINES_MAX * LEAVES_MAX, " /31 space needed:", SPINES_MAX * LEAVES_MAX * 2, "p2p block size:", p2p.num_addresses)
print("today 4 spines x 32 leaves =", 4 * 32, "links =", 4 * 32 * 2, "addresses")
for leaf, spine in [(1, 1), (1, 2), (2, 1), (64, 8)]:
    n, s, l = link(leaf, spine)
    print(f"leaf{leaf}-spine{spine}: {n} spine={s} leaf={l}")
last = link(64, 8)[0]
print("last link inside p2p block:", last.subnet_of(p2p))
print("devices max:", SPINES_MAX + LEAVES_MAX, "loopback0 /24 holds", lo0.num_addresses, "/32s")
print("VTEP loopbacks max 64 leaves in", vtep, "(", vtep.num_addresses, ")")
print("tenant block", tenants, "holds", len(list(tenants.subnets(new_prefix=16))), "tenant /16s;", "each /16 holds", len(list(ip.ip_network('10.16.0.0/16').subnets(new_prefix=24))), "x /24 subnets")
print("10.16.0.0/16 last /24:", list(ip.ip_network('10.16.0.0/16').subnets(new_prefix=24))[-1])
print("infra block", infra, "overlaps tenants?", infra.overlaps(tenants))
print("tenant /12 range", tenants[0], "-", tenants[-1])

max links: 512  /31 space needed: 1024 p2p block size: 1024
today 4 spines x 32 leaves = 128 links = 256 addresses
leaf1-spine1: 10.0.0.0/31 spine=10.0.0.0 leaf=10.0.0.1
leaf1-spine2: 10.0.0.2/31 spine=10.0.0.2 leaf=10.0.0.3
leaf2-spine1: 10.0.0.16/31 spine=10.0.0.16 leaf=10.0.0.17
leaf64-spine8: 10.0.3.254/31 spine=10.0.3.254 leaf=10.0.3.255
last link inside p2p block: True
devices max: 72 loopback0 /24 holds 256 /32s
VTEP loopbacks max 64 leaves in 10.0.5.0/24 ( 256 )
tenant block 10.16.0.0/12 holds 16 tenant /16s; each /16 holds 256 x /24 subnets
10.16.0.0/16 last /24: 10.16.255.0/24
infra block 10.0.0.0/16 overlaps tenants? False
tenant /12 range 10.16.0.0 - 10.31.255.255

Trade-offs and what would flip the choices

Numbering links with /31 costs a little tooling support (both ends must accept it) and saves half the space of /30; unnumbered links remove the block altogether at the cost of less obvious troubleshooting. Because VRFs keep tenants apart, tenants could reuse overlapping ranges, but a single enterprise should not: unique ranges keep shared services, the border and any later merger simple. If you expect more than 16 tenants, shrink each to a /18 (64 per /12) or take a larger tenant block. Out-of-band management stays outside the plan so a fabric fault cannot take away the path used to repair it.

Direct answer

Put the devices on IPv6 where they support it, keep an IPv4 path through private addresses plus NAT (network address translation) for the devices that do not, and make every device dial OUT to a broker or cloud endpoint instead of expecting inbound connections. Carrier-grade NAT (CGN, a large shared NAT run by an ISP or cellular carrier) is a fallback you tolerate at a site, not a design you choose, because it removes inbound reachability and makes per-device logging weak.

The options and what each does

1. Private IPv4 (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) with NAT44 at each site. NAT44 is ordinary IPv4-to-IPv4 address translation. Devices get unique-per-site private addresses; the site router or firewall translates to one or a few public addresses.

• Security: outbound-only by default. Inbound is blocked because no translation entry exists, but that is a side effect of NAT, not a policy; keep an explicit default-deny firewall rule anyway.
• Logging: the public side sees one source address for the whole site. To trace a flow back to a device you need translation logs (private IP, private port, public IP, public port, timestamps) exported from the NAT device.
• Troubleshooting: a packet capture outside the site shows the NAT address, so you must correlate with the translation table. Duplicate private ranges across sites make central troubleshooting ambiguous unless every site has a unique block.
• Reachability: devices cannot be reached from outside without port forwards, and one public IPv4 address has only 64,512 usable source ports (1024 to 65535). A site with 2,000 devices sharing one address averages 32 ports per device if you carve it statically, so chatty devices exhaust it.
  2. Shared address space 100.64.0.0/10 (RFC 6598, 4,194,304 addresses) behind CGN. Cellular and some ISP links hand devices a 100.64/10 address and translate it at the carrier.
• Security: you do not control the translator, and other subscribers share the same public address, so IP reputation and rate limits can hit your fleet because of a neighbour.
• Logging: you only see your 100.64.x.x address on the device; the carrier holds the mapping. Your own logs on the far end show the shared public address.
• Troubleshooting: you cannot see or change the NAT, and idle-timeout values are the carrier's.
• Reachability: effectively none inbound. Use it only if the device initiates and holds the session open (keepalives, tiny periodic messages that stop the carrier forgetting the session, sent more often than the carrier's idle timeout).
  3. Globally unique IPv6. Each site gets a prefix (a /48 gives 65,536 /64 subnets, one per VLAN) and each device its own routable address, usually through SLAAC (stateless address autoconfiguration, the device builds its own address from the router's advertised prefix).
• Security: no NAT, so the site firewall must be explicit: deny inbound by default, allow only the broker or management addresses, and do not block ICMPv6 wholesale (neighbour discovery and path MTU discovery need it).
• Logging: the simplest of all options. The source address in any log IS the device, so no translation table is needed. Record SLAAC addresses and neighbour tables, because a device may hold several addresses.
• Troubleshooting: end-to-end, ping6 and traceroute6 reach the device itself.
• Reachability: reachable whenever the firewall allows it, which is the point of the design, but only if the carrier or ISP at the site provides native IPv6.
  4. IPv6-only devices with NAT64/DNS64 for IPv4-only cloud services. Devices use IPv6 inside; a NAT64 gateway translates to IPv4 for services that have no IPv6 endpoint, and DNS64 (a resolver feature) hands the device an IPv6 address that stands for the IPv4 server.
• Security: the devices are individually addressable on IPv6, so the same explicit default-deny firewall applies; the gateway is a shared choke point you can filter at.
• Logging: flows to IPv6 services are attributable directly; flows to IPv4-only services show only the gateway's IPv4 address on the far end, so you need NAT64 session logs to name the device.
• Troubleshooting: a capture before the gateway shows the device's own address, after it shows the gateway pool address, so correlate on timestamps and ports.
• Reachability: inbound from IPv4 does not work by default, because a stateful NAT64 (RFC 6146) normally creates a mapping only when an IPv6 device opens the session; an administrator can configure static mappings when a device must be reachable from IPv4. Inbound over IPv6 works if the firewall allows it, and outbound sessions to IPv4 services work as long as the gateway still has IPv4 pool addresses and ports free.
  5. Private overlay: VPN (an encrypted tunnel), SD-WAN (software-defined WAN, a managed set of tunnels across several links) or a carrier private APN (access point name, the cellular network's private attachment point). Devices keep private addresses that are unique across the whole fleet and reach a hub that holds the only public edge.
• Security: traffic never crosses the open Internet in the clear and the hub is the one place to enforce policy; the cost is that a hub compromise exposes the whole fleet.
• Logging: the hub or APN gateway sees every device by its own fleet-unique private address, so no translation table is needed when addresses are unique.
• Troubleshooting: tunnel state and the hub's routing table show which site is up; a capture inside the tunnel shows real device addresses.
• Reachability: inbound management works over the tunnel from the hub, subject to hub capacity.
  6. Application-layer reachability. The device opens an outbound TLS session (encrypted connection) to an MQTT broker (a publish/subscribe message server) or an HTTPS endpoint and receives commands over that session. "Can we reach it" becomes "can we publish to its topic", which survives any NAT in the path.
• Security: no inbound port is open on the device; each device authenticates to the broker with its own credential or certificate, so revoking one device is a broker setting.
• Logging: the broker logs each device's identity and every message, which is better evidence than an IP address behind a NAT.
• Troubleshooting: check the broker's connection list first (is the device connected, when did it last send), then the path.
• Reachability: reachable exactly while its session is up, so set keepalives under the NAT or carrier idle timeout.

Worked example

A fleet of 12,000 sensors across 40 edge sites (illustrative numbers). Size per site first: 12,000 / 40 = 300 devices per site. A /24 has 254 usable addresses, too few; a /23 has 2^9 = 512 addresses, 510 usable, so each site gets a /23 (300 / 510 = 59% full, 210 addresses of growth). Then size the whole plan: 40 sites x 512 = 20,480 addresses, which does not fit in a /18 (16,384 addresses) but does fit in a /17 (32,768 addresses, room for 64 /23s). Reserve one /17, for example 10.40.0.0/17 (10.40.0.0 to 10.40.127.255), and hand out one /23 per site: site 1 gets 10.40.0.0/23, site 2 gets 10.40.2.0/23, and so on up to site 40 at 10.40.78.0/23, leaving 24 /23s (10.40.80.0/23 to 10.40.126.0/23) free for new sites. This is better than reusing 192.168.1.0/24 everywhere. For NAT44 at one site, 64,512 usable source ports shared by 300 devices is about 215 ports each, which is comfortable. For IPv6, 40 sites need 40 of the 256 /48s in a /40, and each site uses one /64 per device class. Devices that speak IPv6 use it natively; legacy devices use NAT44 at the site; all of them connect outbound to a broker on a fixed IPv6 and IPv4 name.

Trade-offs and pitfalls

• Recommend IPv6 plus outbound-only connections (options 3 and 6, the two that matter most). It is the only combination where logging, troubleshooting and reachability are all straightforward. NAT44 is the practical fallback; CGN is the one to avoid designing around.
• What flips this: if the carrier gives no IPv6 and the devices cannot run it, use option 5 (private overlay) so you control the address plan and the NAT.
• Common wrong turns: treating NAT as a firewall, reusing the same RFC 1918 range at every site (overlap breaks central monitoring and any later VPN), and forgetting that sharing a public address shares its reputation.

Direct answer

Size each VLAN (virtual LAN, one broadcast domain per subnet) for its hosts plus a stated growth factor plus a fixed infrastructure reserve, round each up to the next power-of-two block, and allocate the blocks largest first so every block lands on its natural boundary with no gaps. With 25% growth and 5 reserved addresses per subnet, the six VLANs fit exactly inside 10.10.0.0/21 (2,048 addresses), which leaves 10.10.8.0 onward free for everything else. VLSM (variable-length subnet masking) just means each subnet gets the mask it needs instead of one mask for all.

Sizing rule (state it first, then apply it)

• Reserve 5 addresses per subnet: .1 is the default gateway (a virtual IP shared by two routers using a first-hop redundancy protocol such as HSRP or VRRP), .2 and .3 are the two routers' own interface addresses, .4 and .5 are held for infrastructure (for example a wireless controller or a local DHCP server; when DHCP is central, the routers' own .2 and .3 interfaces act as the DHCP relay agent, the feature that forwards clients' address requests to the central DHCP server). Dynamic DHCP (automatic address assignment) pools start at .6.
• Growth factor: 25% on top of today's host count. Rounding up is done with the rule hosts needed = ceil(hosts x 1.25) + 5, and the block must satisfy 2^h - 2 >= hosts needed (the 2 removed are the network and broadcast addresses).
• Allocation order: sort by size, largest first. A block of size 2^h must start at a multiple of 2^h, so placing the biggest first means every smaller block starts where the previous one ended and is automatically aligned.

One row traced step by step. Guest Wi-Fi: 250 x 1.25 = 312.5, rounded up to 313; add the 5 reserved addresses to get 318. A /24 offers only 254 usable, a /23 offers 2^9 - 2 = 510, and 510 >= 318, so Guest gets a /23 and the spare is 510 - 318 = 192. Engineering: 600 x 1.25 = 750, plus 5 is 755; a /23 (510) is too small, a /22 gives 2^10 - 2 = 1022, so /22 with 1022 - 755 = 267 spare.

The allocation

The six blocks are contiguous and collapse to a single summary route, 10.10.0.0/21 (10.10.0.0 to 10.10.7.255), so the rest of the network needs one route for all of them. The remaining 10.10.8.0/21 and higher stays unallocated. Reserve a separate small block out of it (for example 10.10.8.0/24) for router loopbacks (/32 each) and point-to-point links (/31 each, which RFC 3021 allows on point-to-point links), so infrastructure never eats user space.

Engineering has the most headroom (267 spare) and Finance the least (7 spare): a /26 has 62 usable addresses, 5 are reserved, so it holds at most 57 hosts against today's 40. If Finance is expected to pass about 57 hosts, give it a /25 now; moving a subnet later means renumbering hosts, DHCP scopes, ACLs (access control lists) and firewall rules.

Why minimising waste is not the same as sizing to today's count

Without growth, the same reserve rule gives: Engineering 605 needed (/22), Guest 255 needed (/23, because a /24 has only 254 usable and 250 + 5 = 255 does not fit), Sales 125 (/25 with 1 address left), Lab 75 (/25), Finance 45 (/26), HR 35 (/26). That packs tighter, but Sales is one device from full and Guest Wi-Fi already needed a /23 anyway. The honest trade-off: the zero-growth plan saves address space that costs nothing (the /16 has 65,536 addresses and the plan above uses 2,048, about 3%), while the growth blocks save renumbering outages. In a /16 with this much free room, spend addresses to save operational pain.

Gateway convention and scaling to five sites

Pick one gateway rule and never deviate: the first usable address (.1 of the subnet) is the gateway on every subnet in every site. Automation, DHCP templates and troubleshooting ("ping .1") all depend on it. The same method also sizes whole site blocks in a multi-site network. Sites of 120, 30, 500, 8 and 2,000 hosts with the same rule need 155, 43, 630, 15 and 2,505 addresses, which round to /24, /26, /22, /27 and /20. Largest first from 10.20.0.0/16:

All five sit inside 10.20.0.0/19 (10.20.0.0 to 10.20.31.255), so the WAN advertises one /19 summary while each site advertises its own block. The blocks end at 10.20.21.95; 10.20.21.96 to 10.20.31.255 is held for new sites or growth of the neighbours, and because it is inside the /19, using it never changes the summary. Inside each site block the same per-VLAN sizing rule above carves the VLAN subnets.

Pitfalls

• Allocating smallest first leaves holes that cannot be reused because the next larger block would be misaligned.
• Forgetting that 250 hosts plus the 5 reserved addresses is 255, one more than the 254 usable in a /24, and with 25% growth it is 318, so Guest needs a /23. (The gateway and two router addresses alone, 250 + 3 = 253, would still have fit.)
• Carving subnets with no summary boundary: scattered blocks cannot be advertised as one route.
• Assigning from the reserve block to users; infrastructure space should be separate so a rogue DHCP pool never overlaps a router address.