Addressing & IPv6
Give identity, addresses and names distinct jobs.
A device ID identifies an enrollment. An address routes traffic. A name helps clients find it. Choose the address families your clients and services need.
Explore Public IPs ↗01 / Three distinct jobs
Start with the resource. Then choose how to reach it.
One resource can have an enrollment identity, private addressing and a separately allocated public address. Naming helps clients find the destination; the route and permission still need to exist.
- IdentifyDevice ID
- Identifies the device’s enrollment in a workspace.
- RouteIP address
- Provides an address for traffic within its configured scope.
- FindDNS name
- Resolves a destination for a person or application.
One enrolled device. Different ways to identify it.
One workspace enrollment · three distinct jobs
- Device IDWorkspace enrollment record
- Private IPIllustration: 100.96.0.42
- Private nameWorkspace DNS, where configured
The device ID identifies the enrollment. The address routes traffic. A name helps a person or application find that address.
These are identity relationships, not packet hops. An access group does not create another device address. Private addressing and name resolution do not grant permission or public access.
A public address is a separate resource.
- Public allocationIPv4 or IPv6→Allocation
- Fibmesh deliveryServing location + tunnel→Delivery
- Device or gatewayAssigned address / downstream route
An address can receive permitted incoming traffic and, under the selected routing mode, supply the source for outgoing traffic.
A device’s physical location and its public address’s serving location are different. Address retention depends on the allocation lifecycle; releasing it can mean losing that address.
Deliver a range to the router that owns the downstream network.
- IPv6 allocationIllustrative /48→Routed delivery
- Your gatewayDivide into permitted subnets→Subnet planning
- Downstream networksUp to 65,536 distinct /64s
A /48 contains 65,536 /64 prefixes. This is address arithmetic, not a capacity, hardware or performance promise.
Available service sizes are /48 through /64, assessed per allocation. IPv4 subnets are separate. A routed prefix is not an Ethernet extension, a BYOIP service or automatic failover.
A device ID, an address and a name do not grant application access, issue a certificate or sign a user in. Check network permission and application authentication separately.
02 / Inside the workspace
Private addressing connects permitted resources.
Private addresses support internal connectivity. Joining another access group changes permission; the enrolled device does not receive a new identity or private address for each group.
A resource behind a site gateway keeps its local addressing unless the deployment explicitly changes it. The gateway does not automatically enroll each LAN resource. Overlapping local ranges still need a routing plan.
A private name stays private.
Private workspace DNS belongs within Networks. It does not publish a service, bridge local broadcast discovery, issue a certificate or replace application login.
03 / A separate public allocation
Public reachability needs its own delivery.
Public IPs can deliver a public address directly to a supported device without NAT, or through an assessed gateway/NAT configuration. The allocation is distinct from the private overlay address.
Incoming rules and the selected outgoing routing mode determine how the allocation is used. For source allowlisting, check the public address an external service actually sees. Public IPs or an agreed Outbound allocation may fit, depending on the delivery model.
Keep location and lifecycle separate.
A retained allocation may follow a mobile or relocated host through a supported tunnel. The actual serving region and point of presence do not move with the device. Reconnection and session continuity need separate verification. Pause and resume preserve the reservation; release can lose the address.
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 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 assignment and forwarding across the endpoints and gateways in the deployed release; a nullable IPv6 schema field is not evidence of a working allocator.
04 / Choose the address family
Start with the clients that need to connect.
IPv4, IPv6 and dual stack need different checks. Confirm the allocation, client path, target and gateway support for each family you intend to use.
Scroll sideways to compare address-family choices. Focus the table and use the arrow keys on a keyboard.
| Choice | Suitable requirement | What to check |
|---|---|---|
| IPv4 | Clients or external allowlists require IPv4. | Allocation, delivery and any compatibility cost. |
| IPv6 only | All required clients can reach the service over IPv6. | Client, target and gateway IPv6 support; explicit IPv4 handling for a full tunnel. |
| Dual stack | Clients need both IPv4 and IPv6 access. | Both allocations, both routes and both firewall policies. |
| Publish web URL | A browser or API client needs an application hostname. | Supported gateway and deployed client path; 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 atomic provisioning of both families or a shared firewall rule across them.
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 as labelled ISP bypass. Traffic left on the ISP path is outside the protected tunnel. IPv6 does not automatically provide NAT64 or DNS64 translation.
05 / Routed Subnets
A prefix serves the networks behind your router.
Routed Subnets is a separate invitation-led Public IPs managed service with assisted setup, rather than self-service prefix provisioning in the app. IPv4 and IPv6 blocks are separate allocations, with delivery assessed for the deployment.
Available IPv6 prefix sizes
A longer prefix contains fewer addresses. A /48 contains 65,536 /64 subnets; a /64 provides one such subnet.
This is address arithmetic. Usable topology, capacity and performance depend on the service and your equipment.
Plan the whole delivery path.
The allocation is delivered to an agreed gateway or router over the supported tunnel. Your downstream networks need addressing, route advertisement, filtering and a valid return path.
Moving delivery between clouds or gateways requires a coordinated route change. Allocation ownership does not provide simultaneous active delivery, automatic failover or a floating-subnet orchestration service.
Explore Routed Subnets →Delivery, route changes and prefix boundaries
The supported IPv6 service sizes range from /48 through /64, assessed per allocation. This is a separately managed service; the range does not establish a self-service prefix API or automated route-change capability.
Public prefixes do not imply BYOIP, BGP sessions, dedicated cloud circuits or a shared Ethernet segment. Those require separate capabilities and evidence. Agree downstream routing and filtering, operational ownership and the route-change procedure before delivery.
Addressing questions
Check the scope behind the address.
An address is one part of a working connection. Reachability also depends on routing, permission, the application and the client path.
Does an IPv6 address make a device public?
No. Reachability depends on 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, the actual serving location, physical mobility and session continuity are separate questions. Releasing the allocation can lose that address.
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.
Choose the connection your clients and services need.
Compare the products for your requirement →