Why Censorship Testing Should Cover IPv4 And IPv6

A website can appear reachable through one address family and blocked through another. That difference matters because modern internet connections may use IPv4, IPv6, or both, while DNS resolvers and filtering systems can treat each path differently. Testing only a domain name, or only the first address returned by a lookup, can therefore produce an incomplete picture of censorship.

Net Neutrality Monitor tracks blocked websites, IP addresses, DNS responses, probes, and country-level patterns for research and comparison. Its results are indicative rather than a final legal ruling, but checking both IPv4 and IPv6 gives users a stronger basis for understanding whether a filtering event is broad, address-specific, resolver-related, or limited to one network path.

How Address Families Change The Result

IPv4 and IPv6 are separate protocols with different address spaces and routing arrangements. A domain might resolve to an IPv4 address such as 203.0.113.10 and an IPv6 address such as 2001:db8::10. Both can lead to the same service, yet they may travel through different infrastructure and encounter different filtering rules.

Some internet providers deploy mature blocking systems for IPv4 while their IPv6 controls are less complete. Others apply policy at the domain name, transport, or content-delivery layer in a way that affects both families. Testing both reveals which situation is more likely instead of assuming that one successful connection proves the whole service is available.

The reverse can happen as well. An IPv6 address may be blocked or misrouted while IPv4 works normally, perhaps because of a faulty rule, an incomplete route, or a security product that treats IPv6 traffic differently. This is why a failed connection should be recorded as evidence about a particular path, not automatically labelled as nationwide censorship.

DNS Answers Are Part Of The Evidence

DNS filtering can change what a user receives before a browser ever connects to an IP address. A resolver may return an altered answer, redirect a request to a warning page, refuse the lookup, or provide an address that does not host the requested service. If the resolver gives different A and AAAA records, the apparent result may vary according to the device’s connection preference.

A blocked URL report can also contain intermediate states. Understanding resolved status helps distinguish a name that has been translated into addresses from one that has actually been reached and tested. Resolution confirms a DNS step; it does not by itself confirm that an HTTP request succeeded or that the content was accessible.

For reliable analysis, compare DNS answers from the ISP resolver, a public resolver, and, where appropriate, an independent monitoring probe. Note whether the response includes A records, AAAA records, both, or neither. A missing AAAA answer might reflect ordinary service configuration, deliberate filtering, or a temporary DNS problem, so it needs to be compared with results from other networks.

What Australian Users May Encounter

Australia has a mixed access market involving the NBN, mobile networks, independent retailers, and large carriers such as Telstra, Optus, and TPG. A household in suburban Melbourne may receive a different DNS response from a customer on a regional wireless service in Western Australia, even when both enter the same domain in a browser. Carrier-grade systems, business firewalls, and local resolver choices can all affect the observation.

IPv6 availability also varies by provider, plan, modem, and configuration. A user in Sydney might have IPv6 enabled on a newer NBN connection, while a household in regional Queensland or the Northern Territory may rely on an arrangement where IPv4 is still the practical route. A test that checks only the working path can miss the fact that the unused address family has a separate filtering or routing condition.

Australian users also encounter filtering in settings beyond the home connection. School networks, university systems, public Wi-Fi in Brisbane or Perth, workplace gateways, and mobile networks may apply different policies. Even casual “no worries” browsing can produce misleading results if a laptop silently prefers IPv6 while a phone falls back to IPv4. Recording the provider, access type, suburb or region, and device settings makes comparisons far more useful.

A Practical Testing Routine

A sound test separates domain resolution from direct address access. Start with the hostname, record its A and AAAA responses, then test each returned address using the correct protocol. When testing HTTPS by address, preserve the original hostname through the request’s host or server-name setting; otherwise, a functioning server may reject the request because the certificate and virtual host do not match.

Keep the testing environment stable. Use the same device, browser or command-line tool, resolver, and network while comparing IPv4 with IPv6. Repeat at different times if the result is important, because temporary outages, overloaded resolvers, and route changes can resemble censorship. A second connection, such as a mobile hotspot, helps identify whether the behaviour belongs to an ISP rather than the destination.

Details Worth Recording

• Date, time, country, state or territory, and access provider
• Domain, A record, AAAA record, and tested destination address
• DNS response, connection result, HTTP status, and visible error page
• Whether IPv6 was native, tunnelled, disabled, or unavailable

Signals That Need Comparison

• Both protocols fail with the same block page or reset
• IPv4 works while IPv6 times out or returns a different response
• DNS answers differ between the ISP and an independent resolver
• A domain resolves correctly but the direct connection fails

Evidence becomes stronger when the same pattern appears across several probes or networks. A single timeout is a useful observation, but it is not enough to establish intentional blocking. Capturing timestamps and raw responses also prevents memory or browser caching from shaping the report.

Reading Results Without Overclaiming

The purpose of dual-stack testing is to narrow down explanations. If both address families resolve to expected destinations and both fail with a consistent block response, domain-level or destination-level filtering becomes more plausible. If DNS is altered for both records, resolver interference deserves attention. If only one address family fails, routing, firewall rules, or uneven policy deployment may be responsible.

Results should also be interpreted alongside the wider social and technical context. Clear records require practical communication and numeracy, much like the capabilities described in business communication skills. The point is not to turn every user into a network engineer, but to make reports precise enough that another person can reproduce the observation.

Network identity can be complicated when households use shared addresses, mobile gateways, enterprise egress points, or privacy services. This matters in Australia, where mobile and fixed-line paths can expose different public addresses and where regional access conditions may differ from those in Sydney or Melbourne. Broader digital-access research, including discussion of national ID systems, shows why technical availability and a person’s practical ability to reach an online service are related but distinct questions.

Net Neutrality Monitor’s volunteer-supported model benefits from careful, reproducible submissions. Readers can learn more about its community reporting while keeping in mind that the project is presented as a beta service and its data is intended for indicative research. A report is most valuable when it says exactly what was tested, from where, through which resolver and provider, and how IPv4 compared with IPv6.

Observation	Likely area to investigate	What it does not prove
IPv4 and IPv6 both show the same block response	Broad policy, domain filtering, or destination control	That every Australian provider applies the same rule
IPv4 works and IPv6 times out	IPv6 routing, firewall configuration, or incomplete deployment	Deliberate censorship
IPv6 works and IPv4 is blocked	IPv4-specific address or filtering rule	That the site is generally available to all users
DNS returns different answers by resolver	DNS manipulation, resolver policy, or stale data	That the destination server itself is blocking access
Domain resolves, but both direct connections fail	Routing, hosting, TLS, or destination-side controls	That the failure is government-directed
Only one ISP or network shows the issue	Provider-specific filtering or local infrastructure	That the address is blocked nationwide

The practical takeaway is simple: test the hostname, inspect both A and AAAA records, connect over IPv4 and IPv6 separately, and preserve the network and timing details. Comparing the two address families turns a vague “site is blocked” report into a clearer account of where the failure occurs and how confidently it can be attributed.