Summary

  • A guide republished under APNIC's banner says a private IPv4 address on a WAN port always means carrier-grade NAT. That conclusion is stronger than the observation supports.
  • RFC 1918 space, the RFC 6598 shared range, a second household router and DS-Lite describe different boundaries. A useful diagnosis records the address class, the observed public egress and the access mode before naming the mechanism.

One reading became a verdict

On 24 August, an archived copy of a guest guide carried by APNIC told home users how to interpret a MikroTik router's WAN status. Most of the practical advice is ordinary and useful: inspect the assigned address, compare it with what an external service sees, and understand why unsolicited inbound connections may fail. The problem is the sentence that closes the diagnostic loop too early: a private IPv4 address on the WAN port, it says, always means CGNAT.

That is not what the reading proves. It proves that the address visible at that interface is not globally unique when it falls inside a private block. Translation or tunnelling must occur somewhere before a packet reaches the public IPv4 Internet, but the router display alone does not identify who controls that boundary, how many translation stages exist, or whether the access service is IPv4-over-IPv6.

This distinction matters because “I cannot accept an inbound IPv4 connection” is a symptom shared by several architectures. Treating the symptom as the name of one architecture can send a user toward the wrong support request, the wrong purchase or the wrong fault domain.

Three ranges, several mechanisms

RFC 1918 reserves 10/8, 172.16/12 and 192.168/16 for private internets. Those addresses can appear behind an operator's translation equipment, but they can also appear on the link between two routers in the same home, at a managed-business edge, or inside another private network. The allocation says that the address is not globally routable; it does not name the organisation performing translation.

RFC 6598 created 100.64/10 as Shared Address Space for service-provider use at carrier-grade NAT interfaces. Even that more specific observation is evidence of a shared-address design, not a full operational receipt. It does not show the subscriber-to-public mapping, port behaviour, logging period or whether the displayed interface is the actual provider demarcation.

Double NAT is the simplest counterexample to the word “always”. Put an operator-supplied gateway in router mode in front of a customer router. The customer router may receive 192.168.1.2 on its WAN interface while the upstream gateway itself holds a globally routable address. The private WAN reading is genuine; carrier-grade NAT is not established.

DS-Lite supplies a different counterexample. RFC 6333 describes an IPv4-over-IPv6 design in which the customer-side element tunnels IPv4 traffic to an Address Family Transition Router. The decisive facts are the IPv6 tunnel and AFTR arrangement, not merely the shape of one IPv4 field. A guide that groups DS-Lite with ordinary private-address translation may correctly warn that inbound IPv4 is constrained while still misidentifying the mechanism.

The minimum diagnostic receipt

A support-grade conclusion needs a short, reproducible record:

  1. the exact WAN IPv4 address class — RFC 1918, RFC 6598, a documentation range, or globally routable space;
  2. the public IPv4 address observed by an external endpoint at the same time;
  3. whether another gateway sits between the inspected router and the access line;
  4. the presence of native IPv6, an IPv4-over-IPv6 tunnel or an AFTR configuration;
  5. the result of a controlled inbound-mapping test, including protocol, port and timestamp; and
  6. the operator's description of the subscriber product, preferably tied to a ticket or service identifier.

Those observations still may not reveal the complete topology. They do separate what the customer can see from what only the provider can confirm. RFC 6888 sets behavioural requirements for carrier-grade NAT devices, including mapping and filtering properties. A label based on a single screen offers none of that behavioural evidence.

The correction is small but important: “A private WAN address means your router is behind another addressing boundary; CGNAT is one possibility.” Then tell the reader how to distinguish the possibilities.

Why APNIC's banner changes the stakes

The independent archive copy identifies the piece as a guest post and notes that the views are the author's. That disclaimer helps with attribution, but it does not neutralise the editorial effect of republication. Readers arrive because the page sits in the information environment of a regional Internet registry. A categorical diagnostic claim there inherits more authority than the same sentence on a personal blog.

Heng Lu's argument for a minimum initial specification offers the right editorial discipline: publish the smallest claim that the evidence can support, preserve room for local variation, and make the next decision explicit. His emphasis on running code and observable behaviour points the same way. The screen value should open a test, not close one.

The guide's practical warning remains valid: many subscribers behind upstream address sharing cannot expose an IPv4 service in the usual way. The unresolved point is causation. Without the additional receipt, neither the reader nor the publisher can tell whether the fix is bridge mode, a router reconfiguration, native IPv6, a provider feature, a public-address product or no available change at all.

Sources