A public address and a routed subnet solve different problems

A virtualization host runs several services. One partner wants a file-transfer destination; another application expects its usual port. The gateway has one public address and a growing list of mappings.

Use one public IP when direct assignment or supported port mappings meet those requirements. Choose a routed subnet when workloads need separate public addresses or downstream prefixes, and you can operate the gateway routes, firewall and reply paths. Several services do not automatically require several addresses. A routed allocation supplies an address block; distributing it safely across your infrastructure remains part of the deployment.

When one public IP and port mappings are sufficient

A supported gateway can forward different external ports to different LAN services. Two servers listening locally on TCP 443 might use external ports 8443 and 9443 at the same public address. Clients must support that choice, and the firewall must restrict the intended traffic.

For HTTP applications, a suitable proxy can sometimes select a backend using application information such as the hostname. Plain port forwarding does not make that selection. When the protocol or client requires a particular port, a separate address can avoid that collision.

A direct Device IP assignment is another single-address arrangement. The supported host receives the address and manages its own permitted services and routes. It does not automatically allocate public addresses to every VM or container running on that host.

When workloads need a routed public subnet

A routed public block gives the customer gateway a range to distribute across assessed infrastructure. The gateway routes traffic onward to workloads; the operator defines address ownership, local forwarding and firewall policy.

Fibmesh Routed Subnets delivers an agreed public allocation over a supported WireGuard tunnel. A covering aggregate brings internet traffic to Fibmesh, and the customer allocation is routed to the assessed gateway. The model does not require a separate global announcement for each small customer block.

A routed block therefore adds useful freedom and useful responsibilities. Document which address belongs to which workload, how traffic reaches it, which sources may connect, and how replies using that address return through the agreed delivery path. Receiving a block is not the same as completing that customer-side design.

Calculate total addresses and confirm usable counts

Classless Inter-Domain Routing (CIDR) notation describes the number of fixed prefix bits. For IPv4, a /29 contains eight total addresses; a /28 contains sixteen. RFC 4632 explains classless prefix addressing and aggregation.

Total addresses are not a promise of the same number of workload assignments. A conventional LAN subnet, gateway reservation and individually routed host addresses can use a block differently. Do not apply “subtract two” indiscriminately to every prefix and delivery model. For example, RFC 3021 permits both addresses of a /31 on an appropriate point-to-point link; that is not a general LAN rule.

Ask for the usable count and its assumptions before accepting an allocation. Include infrastructure reservations and realistic growth. A block that looks sufficient on paper may be too small for the intended topology.

IPv6 planning commonly asks how many downstream /64 networks you need. A /56 contains 256 /64 networks; a /48 contains 65,536. RFC 6177 discusses end-site sizing with room for multiple networks. More address space does not eliminate the need for a clear allocation plan.

Keep public routing separate from private subnet access

A private route to 192.168.20.0/24 lets authorized participants reach approved resources in that private range through an assessed gateway. It does not make that range globally public.

Fibmesh Networks private subnet access and Public IPs Routed Subnets therefore solve different problems. Private route fields such as subnetRoutes should not be read as evidence of public-prefix provisioning. One concerns permitted access to existing private resources; the other concerns delivery and distribution of public addresses.

The two can coexist. A workload may have a public application destination and private administration, with separate policies and address roles. Document both so a change to one does not accidentally expand the other.

Agree the allocation and operations together

Fibmesh Routed Subnets is available as a separate invitation-led managed service, outside the app MVP. IPv4 and IPv6 are separate allocations; IPv6 sizes range from /48 through /64. Inventory, serving location and quoted terms are deployment-specific.

Bring the workload list, address-family requirements, gateway platform and expected traffic. Agree reverse-DNS scope if needed, ownership, abuse handling and the effect of pausing or releasing the allocation. Availability does not establish self-service provisioning or complete native-client parity.

This is managed subnet delivery. It does not introduce wholesale prefixes, Bring Your Own IP (BYOIP) or a customer Border Gateway Protocol (BGP) service. Automatic floating-subnet orchestration and failover remain separately scoped planned work.

Choose a single address when supported mappings or direct assignment meet the requirement. Choose a block when separate destinations and downstream routing are useful enough to justify operating them. In either case, verify each intended application and its response before treating the addressing plan as complete.