Your server has an IPv6 public address. A test from one mobile connection succeeds. A partner’s office cannot connect. Both observations can be correct.
An IPv6-only public service is directly reachable only by clients with a working IPv6 path. IPv4-only clients need a separately supported intermediary or an IPv4-facing service; a hostname alone cannot bridge the address families. Before choosing IPv6-only delivery, list the people and systems that must connect and test their actual applications and networks.
IPv6-capable client
- Working IPv6 clientActual application and network support IPv6.
- IPv6-only serviceUse the permitted IPv6 application path.
IPv4-only client · direct attempt
- IPv4-only clientA DNS name alone cannot add IPv6 connectivity.
- No direct IPv4 pathThe target has no IPv4-facing service.
Separately supported alternative
- IPv4-only clientConnect to the supported IPv4 front end.
- Assessed intermediaryProtocol-aware forwarding or an appropriate translation design.
- IPv6 targetIts own permitted path and return routing.
Conceptual reachability. A working IPv6 path also needs listeners, firewall permission and compatible replies. An IPv4-facing intermediary is a separately assessed service, not a benefit included with an IPv6 allocation.
The client needs a usable IPv6 path
Check the application as well as the connection. A network can provide IPv6 while an old client accepts only IPv4 literals, stores addresses in an undersized field, or follows a redirect to an IPv4-only dependency. Test the full workflow with the software people actually use.
Build a simple audience list: partner office, remote laptop, mobile application, scheduled integration. For each, record whether IPv6 access has been observed and who owns that evidence. Do not infer all customer reachability from one successful browser test.
Configure DNS records for the working address families
In the Domain Name System (DNS), an AAAA record supplies an IPv6 address. An A record supplies an IPv4 address. RFC 3596 defines the IPv6 DNS record extensions. If the service is IPv6-only, publishing an A record for an unrelated or unavailable IPv4 destination can create a separate failure path.
Check the record from the clients’ resolvers and confirm that it reaches the intended service. For HTTPS, retain the intended hostname so certificate validation and application routing remain part of the test. When an address changes, account for DNS caching before interpreting mixed results.
Address families can fail independently. A hostname with both records is not enough to call a service dual-stack: both published paths need a listener, working delivery, permitted traffic and a tested response.
Assess an IPv4-facing intermediary separately
An appropriately supported proxy or translation service can sometimes bridge a client requirement. It needs its own reachable front end, protocol support, routing and operating owner. An HTTP reverse proxy might fit a web application; it is not a general replacement for every equipment protocol.
NAT64, a form of IPv6/IPv4 network address translation, is often mentioned too broadly in these discussions. The common stateful NAT64 model lets IPv6 clients initiate connections to IPv4 servers. It does not automatically make an arbitrary IPv6-only server available to every IPv4 caller. RFC 6146 describes the translation state and the additional arrangements needed for IPv4-initiated communication.
Do not assume such a service is included with a public IPv6 allocation. Confirm the separately supported mechanism, who operates it, which protocols it handles and what address the destination observes. Fibmesh IPv6-only delivery does not, by itself, promise NAT64 or an IPv4-facing intermediary.
Reachability still needs a firewall
IPv6 changes the address model, not the need for access policy. Permit the intended application and keep administration private when that is the requirement. A globally routable address does not mean every listener should accept internet traffic.
Treat the Internet Control Message Protocol for IPv6 (ICMPv6) carefully. Some messages support essential network behavior, including discovery of the maximum packet size that the path can carry. A blanket block can produce a service that connects for a small request but stalls on a larger exchange. RFC 4890 provides guidance for filtering ICMPv6 while preserving required functions.
Use application encryption and authentication. The address carries neither. If a tunnel delivers the address, protection between tunnel peers remains separate from protection between the visitor and the application.
Keep the server’s outgoing needs separate
A server accepting IPv6 requests may still need to fetch updates or call an IPv4-only API. That is an outgoing-routing requirement. Specify whether IPv4 is blocked, uses a separately supported translation arrangement, or deliberately bypasses the tunnel through the ISP. Label bypass clearly in the deployment plan.
For Fibmesh Public IPs, single-device delivery can be dual-stack or IPv6-only on supported deployments. Confirm the native platform, gateway behavior and address inventory during assisted setup. Direct endpoint delivery and gateway forwarding do not establish the same address-family support on every device.
Choose IPv6-only when the assessed audience and dependencies support it. If required callers cannot reach IPv6, arrange a supported front end or evaluate dual-stack delivery. The useful acceptance test is a completed transaction from every required class of client, not an address successfully appearing on the server.
Check address families before deployment →
