Enterprise Networking Guide
Office Broadband Lacks Usable Global Public IPv6: How to Build a Dual-Stack Test Network?
Explains the difference between globally routable public IPv6 addresses and internal LAN addresses, brings multi-country public IPv6 address blocks and local network egress into domestic labs with DNS resolution and firewall access controls, and clarifies the service scope of test address delivery.
When enterprises develop export-oriented in-vehicle systems (such as Android Automotive OS), mobile applications, or smart hardware, Google Compatibility Test Suite (CTS) certification and overseas customer acceptance often require devices to pass validation in a network environment with both IPv4 and global public IPv6. However, the office broadband used by many R&D labs in China either lacks IPv6 altogether or can only reach domestic websites, throwing errors as soon as devices attempt to connect to overseas test servers.
When existing office broadband cannot meet overseas dual-stack (IPv4 + IPv6) testing requirements, you do not need to apply for an expensive new cross-border physical dedicated line. Building directly on your existing lab broadband, we bring global unicast IPv6 address blocks (GUA) and local network egress from target overseas countries or regions into your domestic lab, allowing devices under test to obtain genuinely usable overseas public IPv6 addresses right inside your office.
Why devices showing an IPv6 address still fail overseas compliance tests
Many testing teams have encountered this puzzling situation: after connecting a device under test to the lab router, the network settings clearly show a colon-separated IPv6 address, yet running formal certification scripts (such as Android CTS tests) still produces widespread failures. This usually happens because different types of addresses are being conflated:
| Address shown on the device | What it actually represents | Passes overseas public IPv6 testing? |
|---|---|---|
| Global unicast address (GUA, starting with 2000::/3) with cross-border routability | A standard public IPv6 address routable across the global public internet | Yes — the device under test can communicate bidirectionally with overseas IPv6 test servers |
| Unique local address (ULA, starting with fc00::/7) | A private IPv6 address reserved under international standard (RFC 4193) for internal LAN use only; not routable on the public internet | No — can only communicate within the lab and cannot reach the public internet |
| Link-local address only (starting with fe80::) | The network interface has IPv6 enabled, but the router has not assigned a public address or outbound route | No — external networks cannot be reached at all |
| Carrier-grade NAT shared IPv4 address (CGNAT) | A shared address translation mechanism used by broadband carriers on the IPv4 side | Unrelated — this is an IPv4 mechanism and cannot substitute for any IPv6 testing requirement |
Simply put, compliance testing requires the device under test to obtain both a usable IPv4 address and a global unicast IPv6 address (GUA) that can genuinely reach standard overseas services (our access appliances support automatically assigning IPv4 addresses and configuring stateless IPv6 SLAAC addresses for test endpoints); merely configuring an internal network address on the network interface will not pass inspection.
Why DNS resolution (AAAA) and firewall security rules must be configured together
Once real public IPv6 addresses are brought into the lab, our deployment assistance also covers two essential details that directly affect test results and lab security:
- Matching IPv6 DNS resolution (AAAA records) for the target region: When an in-vehicle system or phone under test accesses an overseas service, it must first obtain the target server's IPv6 address record (an AAAA record) through DNS resolution. If the lab continues using a legacy internal network DNS server that only returns IPv4 addresses or resolves to nodes in the wrong country, the device will silently fall back to connecting over IPv4—leaving testers thinking they tested IPv6 when traffic actually ran over IPv4. We coordinate DNS resolution to match your target test country.
- Enabling dual-stack firewall protection to keep test benches from being exposed on the public internet: In a standard IPv4 LAN, router address translation prevents external networks from initiating direct connections into the lab; however, once a device under test receives a real global public IPv6 address, leaving it unprotected exposes it directly on the public internet. We therefore use dual-stack firewall and access control rules on the access appliance to block unauthorised unsolicited inbound connections by default, permit only normal communications required for testing, and log DNS resolution records and 5-tuple connection logs for review.
Basic information to prepare for your initial consultation
- The city where your domestic R&D or test lab is located, and the types of devices being tested (such as export in-vehicle infotainment systems, mobile apps, or IoT devices).
- The target countries or regions required for testing (such as Hong Kong, Singapore, the United States, Germany, or India) and whether there are specific compliance test suites (such as Google CTS).
- An overview of your lab’s current broadband and LAN setup; there is no need to prepare complex packet capture logs in advance, as specific dual-stack configurations can be confirmed step by step with us during our consultation.