Know which identity you need
One resource can have several addresses, with different jobs.
A Fibmesh device ID identifies an enrollment in a workspace. Private addressing supports permitted internal connectivity. A public allocation supports separately configured internet reachability or an outgoing source identity. A DNS name helps clients find an address or published application; it does not itself create the route.
Inside the private network
Private addressing does not publish the device.
Private addresses serve permitted internal connectivity. Private IPv6 is in the agreed product scope; automatic assignment still needs verification in the deployed implementation.
Private allocation and current IPv6 implementation
The checked IPv4 allocator uses 100.96.0.0/16, within the shared address space reserved by RFC 6598. These are not globally reachable public addresses. Using an address from this range does not, by itself, mean the Fibmesh connection performs NAT.
Private IPv6 is within the agreed Networks product scope. Automatic assignment is not yet verified in the checked implementation; confirm address assignment and forwarding across the endpoints and gateways in the deployed release. Do not treat a schema field as evidence of a working allocator.
An enrolled device joining another access group does not receive a fresh identity or address for that group. A resource reached through a site gateway keeps its local addressing unless the deployment explicitly changes it. Overlapping local ranges still require a routing plan.
Private workspace DNS belongs within Networks. Name resolution, route permission and application authentication are separate checks. A private name does not publish the service, issue its certificate or carry local broadcast discovery across sites.
Internet identity
Allocate the address separately from the device’s location.
Public IPs can deliver a public identity directly to a supported device without NAT, or through an assessed gateway/NAT configuration. The public allocation is distinct from the private overlay address. Incoming rules and the chosen outgoing routing mode determine how it is used.
A mobile or relocated host may use a retained allocation through its supported tunnel setup, but the public address is tied to its serving region and point of presence. Moving the device does not move that serving location or guarantee uninterrupted sessions. Pausing and resuming preserve the reservation; release can mean a different address on a later request.
For source allowlisting, check the address an external service actually sees. A private device address is not that public source. Public IPs or an agreed Outbound allocation may satisfy the requirement, depending on the delivery model.
IPv4, IPv6 or both
Match the allocation to the clients that must reach it.
Scroll sideways to compare address-family choices.
| Choice | Suitable requirement | What to check |
|---|---|---|
| IPv4 | Clients or external allowlists that require IPv4 | Allocation, delivery and any compatibility cost |
| IPv6 only | Services whose required clients have IPv6 connectivity | Target, gateway and client IPv6 support |
| Dual stack | Clients need IPv4 and IPv6 access | Both allocations, both routes and both firewall policies |
| Publish web URL | A browser or API client needs an application hostname | Planned gateway support; a URL does not imply a dedicated IP |
Provisioning separate families and handling IPv4 in an IPv6-only tunnel
IPv4 and IPv6 allocations are separate; the current single-address API represents one family per request. A dual-stack service does not imply one atomic provisioning operation or a shared firewall rule for both families.
An IPv6-only full-tunnel design must explicitly decide what happens to IPv4: block it, use a separately supported translation service, or deliberately leave it outside the tunnel. Do not describe silent ISP fallback as protected full-tunnel traffic. IPv6 does not automatically provide NAT64 or DNS64 translation.
Routed Subnets
A block of addresses for the networks behind your gateway.
Routed Subnets is a separate invitation-led Public IPs service, outside the app MVP. IPv4 and IPv6 blocks are separate allocations. IPv6 sizes range from /48 through /64: the longer prefix has fewer addresses. A /48 contains 65,536 /64 subnets; a /64 provides one such subnet. Actual usable topology and capacity depend on the service and your equipment.
Delivery, route changes and prefix boundaries
The prefix is delivered to an agreed gateway or router over the supported tunnel. Plan downstream addressing, route advertisement, filtering and the return path. Moving delivery between clouds or gateways needs a coordinated route change; allocation ownership alone does not provide simultaneous active delivery, automatic failover or a floating-subnet orchestration service.
Public prefixes do not imply BYOIP, BGP sessions, dedicated cloud circuits or a shared Ethernet segment. Those require separate capabilities and evidence.
Addressing questions
Avoid the common assumptions.
Does an IPv6 address make a device public?
No. Reachability depends on the address scope, routing and firewall policy. A private address and a globally routed public allocation serve different purposes.
Will IPv4-only clients reach an IPv6-only service?
Not directly without a suitable intermediary or translation arrangement. Verify the actual client path; do not infer translation from tunnel support.
Can one public address stay with me across ISPs?
That is possible with a retained allocation delivered through a supported tunnel. Verify reconnection and routing on the relevant platform. Retention, serving location and session continuity are separate questions.
Does Fibmesh offer a public DNS resolver?
No public DNS or consumer DNS filtering product is part of this portfolio. Private workspace naming belongs within Networks; Publish provides public hostnames for selected web applications.