AT&T International Roaming: Latency Discrepancy and IPv6 NAT Investigation

# AT&T International Roaming: Latency Discrepancy and IPv6 NAT Investigation

**Date:** 2026-03-03
**Location:** Taipei, Taiwan (hotel wifi + AT&T roaming via Chunghwa Telecom hotspot)
**Status:** Observational / investigative — conclusions are qualified by evidence unless stated otherwise

---

## Background

While roaming in Taiwan on AT&T, two Taiwanese carriers (Far EasTone and Chunghwa Telecom) are available as roaming partners. A latency discrepancy of roughly 200ms RTT was observed between the two, and a separate investigation into AT&T's IPv6 addressing revealed unexpected NAT66 behavior in the mobile core. This document captures the findings from live network probing on 2026-03-03.

---

## Part 1: Latency Discrepancy Between Roaming Partners

### Observed IPs

Each Taiwanese carrier, when used as a roaming partner for AT&T, assigns the device a different IPv6 address from AT&T's mobility pool:


| Carrier               | Roaming IPv6 (from `ifconfig.me`) | Prefix             |
| --------------------- | --------------------------------- | ------------------ |
| Far EasTone (FET)     | `2600:387:15:2414::2`             | `2600:387:15::/48` |
| Chunghwa Telecom (CT) | `2600:387:a:7::6f`                | `2600:387:a::/48`  |


Both addresses fall within AT&T's `2600:300::/24` mobility allocation (`ATTMOV6-1`). [^arin]

### BGP Routing Differences (from RIPE RIS)

The two prefixes have different BGP visibility: [^ripe-ris]

- **CT prefix (`2600:387:a::/48`):** Announced as a discrete BGP route, originated by `AS20057` (AT&T Mobility). Visible to all 324 RIS full-feed peers. First seen 2013-11-22.
- **FET prefix (`2600:387:15::/48`):** No specific BGP announcement. No origin AS, no first-seen. Reachable only via the parent aggregate `2600:300::/24` originated by `AS7018` (AT&T Services backbone).

This means external BGP speakers route toward `AS20057` for CT traffic (via the more-specific announcement) and toward `AS7018` for FET traffic (via the aggregate). Whether this routing difference contributes meaningfully to the latency gap is unclear without traceroute data from the cellular connections themselves.

### AS7018 vs AS20057

Per CAIDA AS Rank [^caida] and bgp.tools: [^bgptools-7018]

- **AS7018** is AT&T's major backbone/transit ASN, ranked #27 globally, with ~57,000 prefixes and ~2,700 ASNs in its customer cone. [^caida]
- **AS20057** is AT&T Mobility/Enterprise, ranked #7,564, with ~1,400 prefixes and 3 global connections. It transits through AS7018. [^caida-20057] [^bgptools-20057]

The characterization of these ASNs comes from BGP routing table observations (CAIDA, bgp.tools), not GeoIP.

### GeoIP Data (Low Confidence)

ipinfo.io returned `Phoenix, AZ` for the FET IP and `Houston, TX` for the CT IP. [^ipinfo] GeoIP databases for mobile carrier IP ranges are generally unreliable since the addresses are assigned at the PGW, not at a physical location the GeoIP provider can independently verify. These locations should not be treated as confirmed PGW sites without corroborating traceroute data.

---

## Part 2: Hotel WiFi Baseline (Chunghwa HiNet Fixed-Line)

The hotel's wired internet connection runs on Chunghwa Telecom's HiNet network (`210.242.128.0/17`, `AS3462`). [^arin] This provided a useful baseline for Taiwan-to-US latency without GTP/IPX overhead.

### Local Taiwan Latency


| Destination              | RTT    | Notes                                 |
| ------------------------ | ------ | ------------------------------------- |
| `168.95.1.1` (HiNet DNS) | ~2ms   | Domestic, 8 hops                      |
| `8.8.8.8` (Google DNS)   | ~2.5ms | Google has a local edge in Taiwan     |
| `1.1.1.1` (Cloudflare)   | ~2ms   | Cloudflare has a local edge in Taiwan |


### Trans-Pacific Baseline

A traceroute from the hotel to Level3 DNS (`4.2.2.1`) showed the Pacific crossing:

- Hops 1-9 stayed under ~3ms (all domestic or regional).
- Hop 9→10 jumped from ~2.6ms to ~25ms, crossing to NTT's network (`129.250.x.x`). This appears to be a Taiwan-to-Japan hop.
- Hop 10→11 jumped from ~25ms to ~75ms, crossing the Pacific from Japan to Level3/Lumen (`4.69.x.x`).
- Total RTT to `4.2.2.1`: **~126ms**.

This establishes ~126ms as a rough floor for HiNet-to-US latency via the public internet.

### Traceroutes to AT&T Infrastructure (from Hotel WiFi)

Three traceroutes to AT&T IPv4 destinations from the hotel showed different transit paths and latency profiles:


| Destination              | Transit path                                                  | Final visible hop RTT |
| ------------------------ | ------------------------------------------------------------- | --------------------- |
| `104.0.0.1` (AS7018)     | HiNet → HiNet intl → Level3 (`4.7.18.145`) → AT&T             | ~131ms                |
| `107.106.0.1` (AS20057)  | HiNet → HiNet intl → Arelion (`62.115.165.50`, AS1299) → AT&T | ~142ms                |
| `12.0.0.1` (AT&T `12/8`) | HiNet → Arelion or PCCW → AT&T internal                       | ~193–219ms            |


**The** `12.0.0.1` **trace was notable: after reaching AT&T's peering point at ~133ms, an additional ~60ms was added at hop** `32.130.91.80` **within AT&T's own network.** This 60ms internal jump was stable across multiple runs (193ms observed twice). The same `32.130.91.80` router showed only ~9ms of internal forwarding delay when the destination was `107.106.0.1`, suggesting AT&T routes traffic to very different internal locations depending on the destination prefix.

The `12.0.0.1` trace also took two completely different paths on separate runs (one via Arelion at ~193ms, one via PCCW Global at ~219ms), while the AT&T internal destination latency remained consistent, which points to the variability being on the transit side, not inside AT&T.

### Google Traceroute: Local Edge (from Hotel WiFi)

Google peers directly with HiNet inside Taiwan. The traceroute to `142.250.80.46` showed traffic entering Google's network at hop 7 (`72.14.209.178`) at ~2.4ms. The traffic never left Asia. `google.com` resolved to a local IP and responded at ~3ms.

Reddit/Fastly traffic similarly stayed in Asia, routing through NTT to a Tokyo edge node at ~32ms RTT.

### Google Traceroute: US Datacenter (from Hotel WiFi)

A traceroute to a confirmed US-located Google IP (`142.250.115.138`, which responds at ~168-250ms and is not served from a local cache) showed Google carrying the traffic across the Pacific on its own private backbone:

| Hop | Address | RTT | Notes |
| --- | --- | --- | --- |
| 1–4 | `172.16.x` → `192.72.107.97` | ~5ms | Hotel LAN → HiNet → SEED Net Taiwan |
| 5–7 | `139.175.58.x` → `139.175.59.217` | ~5ms | SEED Net Taiwan (`r58-145.seed.net.tw`) |
| 8 | `142.250.172.86` | ~5ms | **Google enters at ~5ms — Taiwan edge** |
| 9–12 | `74.125.243.3` → `216.239.40.192` | ~5–10ms | Google internal, still in Asia |
| 13 | `192.178.107.202` | **~107ms** | **Pacific crossing (~97ms jump)** |
| 14 | `142.250.213.211` | ~138ms | Google, now in the US |
| 15–18 | `142.251.193.64` → `142.250.224.9` | ~166–170ms | Google US backbone |

The Pacific crossing appears at hop 12→13, with a ~97ms single-hop jump. This is consistent with a direct submarine cable path — possibly Google's own **TPU (Taiwan-Philippines-USA) cable**, which lands in Dawu, Taiwan and Eureka, California and skips Japan entirely. The ~5–10ms of Google-internal hops before the Pacific jump (hops 8–12) might indicate traffic routing through the Philippines branch before crossing.

A second traceroute to `142.250.114.27` (Gmail SMTP) showed a similar pattern with a visible ~44ms regional hop at hop 12 before the ~139ms Pacific crossing at hop 13, possibly representing a Japan or Philippines intermediate.

For comparison, the earlier Level3 traceroute crossed the Pacific via NTT's Tokyo node at ~75ms. Google's own infrastructure appears to use a different, possibly shorter physical path, with the Pacific segment itself taking ~97ms (one-way) versus the NTT path's ~50ms (Japan→US portion). The total end-to-end latency is similar (~168ms vs ~126ms) because Google's path avoids the Japan hop entirely.

---

## Part 3: AT&T IPv6 NAT66

### The Address Mismatch

When connected to AT&T's mobile network via iPhone Personal Hotspot (USB tethering over `en13`), three layers of addressing are visible:


| Layer                                                | IPv4             | IPv6                        |
| ---------------------------------------------------- | ---------------- | --------------------------- |
| Mac interface (`en13`)                               | `172.20.10.11`   | `2600:381:4404:e05:.../64`  |
| iPhone cellular interface (from net tools on device) | `10.147.239.255` | `2600:381:bd03:9b4c:.../64` |
| Internet-facing (from `curl ifconfig.me`)            | `166.205.190.20` | `2600:387:f:4411::8`        |


The IPv4 NAT is expected: `172.20.10.x` is the hotspot's local LAN, `10.x` is the cellular interface (CGNAT private), and `166.205.190.20` (`mobile-166-205-190-020.mycingular.net`) is the external CGNAT address.

The IPv6 situation is less expected. The iPhone's own cellular interface has `2600:381:bd03:9b4c::/64`, but the internet sees `2600:387:f:4411::8`. The entire address is different: different prefix (`381` vs `387`), different subnet, and different interface ID. This is full stateful NAT66 happening somewhere in AT&T's network, not prefix translation (NPTv6), since NPTv6 would preserve the interface ID modulo a checksum adjustment. This contradicts the end-to-end addressing model described in the 3GPP IPv6 specifications. [^rfc6459]

This was initially hypothesized to be the iPhone hotspot doing NAT66 (similar to a report on the Netgate forums where a user saw `2600:387` on the iPhone and `2600:380` on a tethered computer [^netgate]). However, the iPhone's own cellular interface shows `2600:381:` addresses, not `2600:387:`, which means the rewriting happens inside AT&T's network, not on the device.

This behavior reportedly occurs domestically (inside the US) as well, not only while roaming.

For comparison, Verizon was observed to provide true end-to-end IPv6: the address on the device's cellular interface matched the address seen on the internet, with no NAT. Confirmed the same on T-Mobile as well, but this is to be expected, as T-Mobile runs an IPv6-only network.

### BGP Evidence

- `2600:381:4404::/48` (the cellular interface prefix): **No BGP announcement**. Not visible in the DFZ. Only reachable via the aggregate `2600:300::/24` from AS7018. [^ripe-ris]
- `2600:387:a::/48` (one of the external prefixes): **Announced by AS20057** as a discrete route. [^ripe-ris]
- `2600:387:f::/48` (the current external prefix): **No specific announcement**, covered by the aggregate. [^ripe-ris]

The `2600:380:` and `2600:381:` ranges have many sub-prefixes announced by AS20057, while the `2600:387:` range is announced as individual `/48`s. This split is consistent with the `2600:381:` space being an internal device-facing pool and the `2600:387:` space being an externally-routable pool, though this is inference from the BGP data rather than a confirmed fact.

### 6RD Hypothesis

AT&T is documented as using 6RD (IPv6 Rapid Deployment [^rfc5969]) on their residential fiber/DSL network, where a similar pattern exists: the WAN interface gets a non-routable `2001:506:` address while the delegated prefix for LAN clients uses a different, routable range (`2600:1700:`). [^netgate]

**How AT&T residential 6RD works (confirmed):** The residential gateway derives its IPv6 `/60` prefix from its public IPv4 address using a straightforward formula. The 6RD parameters are: SP prefix `2602:300::/28`, IPv4 mask length `0` (all 32 bits used), border relay `12.83.49.81` (anycast). [^todd-6rd] [^kula-6rd] The IPv4 address is converted to hex and embedded directly after the `/28` prefix. For example, IPv4 `123.123.123.123` (hex `7b7b7b7b`) becomes `2602:307:b7b7:b7b0::/60`. This is standard RFC 5969 behavior [^rfc5969] — the prefix is stateless and deterministically derived from the IPv4 address.

Notably, the residential network uses an entirely different IPv6 allocation (`2602:300::/28`) from the mobile network (`2600:300::/24`). These are separate `/16` allocations (`2602:` vs `2600:`).

**Testing whether mobile uses a similar scheme:** A hypothesis was tested that the mobile network might use a similar derivation, with the `2600:381:` prefix being 6RD-derived from the internal IPv4 address (`10.147.239.255`). An exhaustive check across all possible SP prefix lengths (16–48 bits) and IPv4 mask lengths (0–16 bits) found **no valid 6RD derivation** that encodes a meaningful portion (>=16 bits) of the IPv4 address into the IPv6 prefix. The check was also run against the IPv4 address seen at hop 2 of the traceroute (`107.243.2.3`), in case the derivation used a different internal address; that also produced no match.

This rules out standard 6RD [^rfc5969] as the mechanism for prefix assignment on the mobile network, though it does not rule out a proprietary or modified tunneling scheme.

---

## Part 4: IPv6 Traceroute Through AT&T's Mobile Core

An IPv6 traceroute from the hotspot connection to Google (`2607:f8b0:4004:800::200e`) revealed the full path through AT&T's internal infrastructure:


| Hop | Address                                 | Owner                         | RTT    |
| --- | --------------------------------------- | ----------------------------- | ------ |
| 1   | `2600:381:4404:e05:9d39:c730:c6ce:b162` | iPhone hotspot gateway        | ~1ms   |
| 2   | `fd00:c000:100:11::3`                   | AT&T internal (ULA, RFC 4193) | ~265ms |
| 3   | `2600:300:20e2:807::3`                  | AT&T mobility aggregate space | ~266ms |
| 4   | `2001:1890:ff:ffff:12:240:192:120`      | AT&T backbone                 | ~263ms |
| 5   | `2001:1890:f6:1b2e::1`                  | AT&T backbone                 | ~264ms |
| 6   | `2001:1890:f6:5bd::1`                   | AT&T backbone                 | ~263ms |
| 7   | `2001:1890:f6:1442::2`                  | AT&T backbone                 | ~264ms |
| 8   | `2001:1890:c01:63:12:255:10:102`        | AT&T backbone (edge)          | ~263ms |
| 9   | `2607:f8b0:8562:180::1`                 | Google                        | ~264ms |


### Observations

**Hop 2 uses ULA (`fd00::`) — private, non-routable IPv6.** [^rfc4193] This is AT&T's internal mobile core infrastructure using private IPv6 addressing internally, which is consistent with the `2600:381:` device-facing addresses not being globally routable.

**AT&T backbone hops embed IPv4 addresses in the interface ID.** Two hops have what appear to be AT&T `12.0.0.0/8` IPv4 addresses encoded in the interface identifier:

- Hop 4: `2001:1890:ff:ffff:12:240:192:120` → reads as `12.240.192.120`
- Hop 8: `2001:1890:c01:63:12:255:10:102` → reads as `12.255.10.102`

Hop 3's subnet field also appears to encode an IPv4 address: `2600:300:20e2:0807::3` → `32.226.8.7` (AT&T's `32.0.0.0/8` block).

**These IPv4 addresses are encoded as decimal values placed directly into IPv6 hex groups, not as proper hex conversions.** In IPv6 notation, each colon-separated group is a hexadecimal value. The group `:192:` is hex `0x0192` (decimal 402), not the decimal value 192. If AT&T had encoded the IPv4 octet 192 as proper hex, it would appear as `:c0:` (since 192 = `0xC0`). Instead, the decimal value `192` is written directly as the hex group, making the IPv4 address immediately human-readable in traceroute output at the cost of "wasting" address space. The address `12.240.192.120` in proper hex encoding would appear as `:c:f0:c0:78` in IPv6 — much harder to visually parse as an IPv4 address.

### Decimal-in-Hex: Broader Evidence Across AT&T's Network

A deeper search confirmed this is not isolated to the two backbone hops in our traceroute. The pattern is a systematic convention across AT&T's IPv6 infrastructure, observed in at least 22 addresses spanning route servers, DNS infrastructure, and backbone transit routers.

**Route Servers (16 instances).** AT&T's public route server at `route-server.ip.att.net` publishes both IPv4 and IPv6 peering addresses in its login banner. A NANOG mailing list post from August 2025 captured the full table. [^nanog-rs] All 16 route servers use the same encoding: the IPv4 loopback address (from AT&T's `12.122.x.x` pool) is placed octet-for-octet into the interface ID of a shared `/64` prefix (`2001:1890:ff:ffff::/64`). [^he-1890]

| City | IPv4 | IPv6 IID |
| --- | --- | --- |
| Atlanta, GA | `12.122.124.12` | `:12:122:124:12` |
| Cambridge, MA | `12.122.124.67` | `:12:122:124:67` |
| Chicago, IL | `12.122.127.66` | `:12:122:127:66` |
| Dallas, TX | `12.122.124.138` | `:12:122:124:138` |
| Denver, CO | `12.122.83.238` | `:12:122:83:238` |
| Fort Lauderdale, FL | `12.122.120.7` | `:12:122:120:7` |
| Los Angeles, CA | `12.122.125.6` | `:12:122:125:6` |
| New York, NY | `12.122.125.44` | `:12:122:125:44` |
| Philadelphia, PA | `12.122.125.106` | `:12:122:125:106` |
| Phoenix, AZ | `12.122.125.132` | `:12:122:125:132` |
| San Diego, CA | `12.122.125.165` | `:12:122:125:165` |
| San Francisco, CA | `12.122.126.232` | `:12:122:126:232` |
| San Juan, PR | `12.122.159.217` | `:12:122:159:217` |
| Seattle, WA | `12.122.125.224` | `:12:122:125:224` |
| St. Louis, MO | `12.122.126.9` | `:12:122:126:9` |
| Washington, DC | `12.122.126.64` | `:12:122:126:64` |

Every single one is a 1:1 match between the IPv4 address and the IPv6 IID when read as written. None of the IPv4 addresses have reverse DNS (PTR) records, consistent with internal loopback addresses.

**DNS Infrastructure (4 instances).** AT&T's `usi.net` and `sbcidc.com` nameservers provide the strongest confirmation because both A and AAAA records are published in public DNS and can be verified independently:

| Hostname | A Record | AAAA Record |
| --- | --- | --- |
| `ns1.usi.net` | `99.99.99.136` | `2001:1890:1ff:9f1:99:99:99:136` |
| `ns2.usi.net` | `99.99.99.138` | `2001:1890:1ff:9f1:99:99:99:138` |
| `ns3.usi.net` | `68.94.156.136` | `2001:1890:1ff:9f0:68:94:156:136` |
| `ns4.usi.net` | `68.94.156.138` | `2001:1890:1ff:9f0:68:94:156:138` |

The `99.99.99.x` range is AT&T's DNS resolver pool; `68.94.x.x` is registered to SBC Internet Services (AT&T's pre-merger entity). [^arin] Both IPv4 ranges are confirmed AT&T-owned via ARIN whois. The DNS servers use different `/64` prefixes than the route servers (`2001:1890:1ff:9f0` and `9f1` vs `2001:1890:ff:ffff`), but the same decimal-in-hex IID encoding.

**Last-Octet Variant.** A few AT&T addresses use a weaker form where only the last IPv4 octet is preserved in the IID. The route server hostname itself (`route-server.cbbtier3.att.net`) resolves to `12.0.1.28` (A) and `2001:1890:111d:1::28` (AAAA) — only the `:28` carries over. [^he-rs] Similarly, `ns1.gravinoc.com` maps `12.205.28.204` to `2001:1890:1bc1:e100:aa21::204`. [^he-1890] These appear to be on customer-facing or hosting subnets rather than backbone infrastructure.

**IPv4 ranges observed in this encoding:**

| Range | Context | ARIN Registration |
| --- | --- | --- |
| `12.122.x.x` | Route server loopbacks | AT&T (ATT netblock) |
| `12.240.x.x` | Backbone router (our hop 4) | AT&T (ATT netblock) |
| `12.255.x.x` | Backbone router (our hop 8) | AT&T (ATT netblock) |
| `68.94.x.x` | DNS servers | AT&T / SBC Internet Services |
| `99.99.99.x` | DNS resolvers | AT&T / SBC Internet Services |

All confirmed examples use AT&T's own legacy IPv4 allocations from the `12/8`, `68/8`, and `99/8` blocks, which suggests the encoding is tied to AT&T's internal address management rather than a general industry convention.

This pattern suggests AT&T's backbone IPv6 infrastructure is built on top of (or mapped to) the underlying IPv4 router loopbacks from their legacy `12/8` and `32/8` allocations. AT&T owns roughly 96 million IPv4 addresses, and those appear to be structurally embedded in their IPv6 infrastructure addressing.

**The IPv4 traceroute to the same destination shows fewer visible hops but identical latency.** The IPv4 path to Google from the hotspot shows: hop 1 (hotspot LAN) → hop 2 (`107.243.2.3`, AT&T Mobility, ~264ms) → hops 3-7 filtered → hop 8 (Google, ~262ms). The ~260-265ms latency is consistent across both protocols from hop 2 onward, suggesting they traverse the same physical infrastructure.

### Comparison: IPv4 vs IPv6 Path


| Aspect                  | IPv4                          | IPv6                                    |
| ----------------------- | ----------------------------- | --------------------------------------- |
| Visible AT&T hops       | 1 (rest filtered)             | 6                                       |
| First hop after LAN     | `107.243.2.3` (AT&T Mobility) | `fd00:c000:100:11::3` (ULA)             |
| Latency from hop 2      | ~264ms                        | ~265ms                                  |
| Entry to Google         | ~262ms                        | ~264ms                                  |
| Uses private addressing | Yes (`10.x` CGNAT)            | Yes (`fd00:` ULA, `2600:381:` internal) |


---

## Part 5: Hotspot vs Cellular Prefix Allocation

The iPhone's hotspot interface and cellular interface have different `/64` prefixes within the `2600:381::/32` space:


| Interface              | Prefix                    | Likely APN                         |
| ---------------------- | ------------------------- | ---------------------------------- |
| Cellular (device data) | `2600:381:bd03:9b4c::/64` | Device data APN (e.g. `broadband`) |
| Hotspot (tethering)    | `2600:381:4404:e05::/64`  | Tethering APN (e.g. `pta`)         |


These are in completely different `/48`s (`bd03` vs `4404`), suggesting they are allocated from different pools rather than subnetted from a single delegation. In 3GPP networks, a device can maintain multiple simultaneous PDN (Packet Data Network) connections, each tied to a different APN, and each PDN connection gets its own IP allocation. [^ts23401] AT&T is known to use separate APNs for device data versus tethered/hotspot data, which enables independent metering and throttling.

The 3rd and 4th groups of these prefixes were checked for potential IPv4 encoding (`4404:0e05` → `68.4.14.5`, `bd03:9b4c` → `189.3.155.76`), but neither maps to AT&T's address space (`68.4.x.x` is Cox Communications, `189.3.x.x` is LACNIC). The prefix assignment mechanism for these allocations is not clear from the available data.

---

## Open Questions

- **What is the actual PGW location for each roaming partner?** The GeoIP data (Phoenix for FET, Houston for CT) is unverified. Traceroute data from the cellular connections (not through the GTP tunnel opacity) would be needed to confirm.
- **Why does AT&T use NAT66?** The architecture contradicts 3GPP's specification of end-to-end IPv6 addressing. [^rfc6459] One possibility is that it decouples internal address management from external routing, but the overhead and complexity seem significant. Verizon and T-Mobile both provide end-to-end IPv6 without NAT on their mobile networks.
- **Is the IPv6 transport tunneled over IPv4?** The embedded IPv4 addresses in backbone hops and identical latency on both protocols are consistent with shared infrastructure, but do not definitively prove tunneling versus native dual-stack.
- **What accounts for the full ~200ms latency delta between FET and CT roaming paths?** The hotel wifi baseline shows ~126ms to the US via HiNet's fixed-line network. The roaming path adds GTP/IPX overhead on top of the underlying physical route; whether the two carriers take different physical submarine cable paths remains unverified without traceroute data from the cellular connections themselves. [^rfc7445]
- **Why are IPv4 addresses encoded as decimal-in-hex in the backbone IPv6 addresses?** The broader evidence (16 route servers, 4 DNS servers, and backbone transit hops) confirms this is a deliberate, systematic AT&T convention rather than an ad-hoc choice. The encoding is consistent across different infrastructure types and different `/64` prefixes, and spans AT&T's legacy `12/8`, `68/8`, and `99/8` IPv4 allocations. What remains unclear is whether this convention has a name, whether it was generated by an address management tool (e.g., a Junos or IOS script that derives IPv6 interface addresses from IPv4 loopbacks), and whether any other large dual-stack operator uses the same scheme. No discussion of this specific convention was found in NANOG archives, RFCs, or vendor documentation. [^nanog-rs] [^he-1890]
- **What are the low host IDs on the external NAT66 addresses?** The internet-facing addresses end in very low host parts: `::8`, `::6f`, `::2`. These look like sequential pool allocations from a NAT66 gateway rather than SLAAC-derived or EUI-64-derived addresses. None of these addresses (`2600:387:f:4411::8`, `2600:387:a:7::6f`, `2600:387:15:2414::2`) have reverse DNS (PTR) records, and neither do nearby addresses in the same /64. It's unclear whether these are assigned from a contiguous pool, how long they persist (whether they change on reconnect or are semi-stable), or whether the /64 subnet portion (`f:4411`, `a:7`, `15:2414`) encodes any meaningful information about the PGW or session.
- **How does AT&T's mobile prefix assignment work if not 6RD?** The residential network uses standard 6RD [^rfc5969] with a clear formula (SP prefix `2602:300::/28` + full IPv4 = `/60`). [^todd-6rd] The mobile network uses a completely different allocation (`2600:300::/24`) and does not derive prefixes from the device's IPv4 address. The mechanism by which the `2600:381:` internal prefixes are assigned to devices, and the `2600:387:` external prefixes are assigned at the NAT66 boundary, is not apparent from the available data.
- **Why do Verizon and T-Mobile not provide IPv6 while roaming?** Both carriers provide end-to-end IPv6 domestically (Verizon via dual-stack, T-Mobile via IPv6-only with 464XLAT [^rfc6877] for IPv4), yet neither assigns an IPv6 address to the device when roaming internationally. AT&T, by contrast, does provide IPv6 while roaming — albeit behind NAT66. It's unclear whether the difference is a policy choice (e.g., Verizon and T-Mobile explicitly disable IPv6 PDN activation in roaming agreements), a technical limitation (e.g., their IPX providers or roaming partners don't support IPv6 GTP tunnels), or a deliberate simplification to avoid the complexity AT&T has taken on with its NAT66 architecture. The 3GPP specs [^ts23401] [^ts29272] allow the home network to reject IPv6 PDN type during roaming via the "PDN Type" IE in the Create Session Request, so this could be a home-side policy decision independent of the visited network's capabilities.

---

## References

[^ripe-ris]: RIPE RIS (Routing Information Service). BGP routing status and prefix announcement queries via `stat.ripe.net`. <https://stat.ripe.net/>
[^caida]: CAIDA AS Rank. AS7018 (AT&T Services, Inc.) ranking and customer cone data. <https://asrank.caida.org/asns?asn=7018>
[^caida-20057]: CAIDA AS Rank. AS20057 (AT&T Mobility) ranking and customer cone data. <https://asrank.caida.org/asns?asn=20057>
[^bgptools-7018]: bgp.tools. AS7018 prefix and peering data. <https://bgp.tools/as/7018>
[^bgptools-20057]: bgp.tools. AS20057 prefix and peering data. <https://bgp.tools/as/20057>
[^ipinfo]: ipinfo.io. GeoIP lookups for mobile carrier IP ranges. <https://ipinfo.io/>
[^arin]: ARIN WHOIS. IP allocation ownership queries via `whois.arin.net`. <https://www.arin.net/resources/registry/whois/>
[^he-1890]: Hurricane Electric BGP Toolkit. Prefix ownership, PTR records, and DNS records for AT&T's 2001:1890::/29. <https://bgp.he.net/net/2001:1890::/29>
[^he-rs]: Hurricane Electric BGP Toolkit. DNS resolution for `route-server.cbbtier3.att.net`. <https://bgp.he.net/dns/route-server.cbbtier3.att.net>
[^nanog-rs]: char--- via NANOG. "Re: route-server.ip.att.net — needs help?" NANOG mailing list, 18 Aug 2025. Full AT&T route server IPv4/IPv6 address table. <https://seclists.org/nanog/2025/Aug/308>
[^netgate]: Netgate Forum. "Working around AT&T's terrible native IPv6 implementation." Thread discussing `2600:387` vs `2600:380` prefix mismatch on tethered devices. <https://forum.netgate.com/topic/132024/working-around-at-t-s-terrible-native-ipv6-implementation/9>
[^todd-6rd]: Todd E Johnson. "AT&T DSL with IPv6." Blog post documenting AT&T residential 6RD parameters (SP prefix `2602:300::/28`, BR `12.83.49.81`). 29 Sep 2012. <https://www.toddejohnson.net/blog/2012/sep/29/att-dsl-ipv6-2124.html>
[^kula-6rd]: kula.tproa.net. "ATT Business Fiber and IPv6 Prefix Delegation." Dec 2020. <https://kula.tproa.net/lnt/2020/12/att-business-fiber-and-ipv6-prefix-delegation/>
[^rfc5969]: C. Townsley and O. Troan. "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification." RFC 5969, IETF, Aug 2010. <https://www.rfc-editor.org/rfc/rfc5969>
[^rfc6459]: S. Korhonen, J. Soininen, B. Patil, T. Savolainen, G. Bajko, and K. Iisakkila. "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)." RFC 6459, IETF, Jan 2012. <https://www.rfc-editor.org/rfc/rfc6459>
[^rfc7445]: S. Vinapamula and M. Boucadair. "Analysis of Failure Cases in IPv6 Roaming Scenarios." RFC 7445, IETF, Mar 2015. <https://www.rfc-editor.org/rfc/rfc7445>
[^rfc4193]: R. Hinden and B. Haberman. "Unique Local IPv6 Unicast Addresses." RFC 4193, IETF, Oct 2005. <https://www.rfc-editor.org/rfc/rfc4193>
[^rfc6877]: M. Mawatari, M. Kawashima, and C. Byrne. "464XLAT: Combination of Stateful and Stateless Translation." RFC 6877, IETF, Apr 2013. <https://www.rfc-editor.org/rfc/rfc6877>
[^ts23401]: 3GPP TS 23.401. "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access." <https://www.3gpp.org/dynareport/23401.htm>
[^ts29272]: 3GPP TS 29.272. "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol." <https://www.3gpp.org/dynareport/29272.htm>

This is a very interesting write-up. I've been testing it myself and I believe I can actually answer most of the "Open Questions" at the end. The most significant finding is that AT&T isn't implementing blanket NAT66 at all.

1. The "NAT66" is actually a transparent web proxy

I used to host my WireGuard server on port 443 (IPv6) and saw the exact same NAT-like behavior you documented. But I also noticed that WebRTC traffic wasn't getting translated, so I moved WireGuard over to port 88 (avoiding DNS/TLS filtering while also dodging the standard web ports), and suddenly I had a true end-to-end globally routable IPv6 address. No more "NAT66".

AT&T is running a Transparent Proxy / Performance Enhancing Proxy (PEP) for DPI, video throttling (Stream Saver), and TCP optimization, but it only intercepts standard web ports (80, 443). Non-standard ports bypass the proxy and route natively.

This also answers "What are the low host IDs on the external addresses?" The IPs ending in ::8, ::6f, or ::2 aren't mobile device IPs at all, they're the addresses of AT&T's proxy servers / load balancers.

2. Is the IPv6 transport tunneled over IPv4? And why the decimal-in-hex?

Yes, this is most likely 6PE (IPv6 Provider Edge over MPLS - RFC 4798).

This would explain the weird decimal-in-hex pattern too. Network management scripts automatically map the router's IPv4 loopback (12.240.192.120) directly into its IPv6 loopback (2001:1890:ff:ffff:12:240:192:120), which lets their BGP peering and MPLS Label Distribution Protocol link the IPv4 and IPv6 topologies automatically. Since both protocols are following the exact same MPLS switching path, the latency remains identical.

3. How does AT&T's mobile prefix assignment work if not 6RD?

You were right to rule out 6RD. It was a transitional band-aid for legacy copper/VDSL and is basically dead now (AT&T Fiber uses native DHCPv6-PD).

On mobile, it's just standard GTP (GPRS Tunneling Protocol). The cell tower tunnels everything back to the PGW (Packet Data Network Gateway). When your session attaches (using a specific APN for device vs. hotspot), the PGW pulls a /64 from a local regional pool and hands it to the session. No mathematical derivation needed, the GTP tunnel itself handles the transport.

4. What accounts for the ~200ms latency delta between the roaming partners?

This actually boils down to IPX (IP Exchange) providers and home routing. When you roam in Taiwan your data doesn't directly connect to the internet. Instead it's encapsulated in a GTP tunnel and sent back to an AT&T PGW in the US.

Mobile carriers use middleman IPX networks (like Syniverse or BICS) to route these tunnels. The 200ms delta means one Taiwanese carrier's IPX has a direct trans-Pacific path to an AT&T gateway (e.g., LA), while the other is taking a really suboptimal path (e.g., routing through Europe before hitting the US East Coast).

5. Why do VZW and T-Mobile not provide IPv6 while roaming?

This is exactly why Verizon and T-Mobile are more conservative. Tunnelling IPv6 inside GTP over these complex, multi-hop IPX paths is notoriously brittle. If an IPX middleman has MTU issues or doesn't properly support the IPv6 PDP type in their signalling, the connection just dies. By forcing an IPv4-only PDN while roaming, VZW/T-Mo ensures the tunnel remains stable regardless of how many transit providers it hits.

While I haven't seen AT&T's internal configuration docs, this model is the only one that consistently explains the port-dependent behavior, the BGP/traceroute patterns, and the latency profiles I observed.

#1-3 is genuinely new info to me, thank you! #4+ are already canned answers that my AI already gave me. It still doesn’t give a concrete & observable reason as to why they peer differently. I guess it make sense but it’s a bit hand wavy. 5. Same here: it doesn’t explain what I didn’t already know. I am wondering why is AT&T going through the trouble of roaming IPv6 when they have such a funky system already. T-Mobile is IPv6 only so it’s just odd they drop to v4 while roaming.

…

On Mon, Apr 27, 2026 at 13:45 delicatemythology ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ This is a very interesting write-up. I've been testing it myself and I believe I can actually answer most of the "Open Questions" at the end. The most significant finding is that *AT&T isn't implementing blanket NAT66 at all.* 1. The "NAT66" is actually a transparent web proxy I used to host my WireGuard server on port 443 (IPv6) and saw the exact same NAT-like behavior you documented. But I also noticed that WebRTC traffic wasn't getting translated, so I moved WireGuard over to port 88 (avoiding DNS/TLS filtering while also dodging the standard web ports), and suddenly I had a *true end-to-end globally routable IPv6 address*. No more "NAT66". AT&T is running a Transparent Proxy / Performance Enhancing Proxy (PEP) for DPI, video throttling (Stream Saver), and TCP optimization, but it only intercepts standard web ports (80, 443). Non-standard ports bypass the proxy and route natively. This also answers *"What are the low host IDs on the external addresses?"* The IPs ending in ::8, ::6f, or ::2 aren't mobile device IPs at all, they're the addresses of AT&T's proxy servers / load balancers. 2. Is the IPv6 transport tunneled over IPv4? And why the decimal-in-hex? Yes, this is most likely *6PE (IPv6 Provider Edge over MPLS - RFC 4798)*. This would explain the weird decimal-in-hex pattern too. Network management scripts automatically map the router's IPv4 loopback ( 12.240.192.120) directly into its IPv6 loopback ( 2001:1890:ff:ffff:12:240:192:120), which lets their BGP peering and MPLS Label Distribution Protocol link the IPv4 and IPv6 topologies automatically. Since both protocols are following the exact same MPLS switching path, the latency remains identical. 3. How does AT&T's mobile prefix assignment work if not 6RD? You were right to rule out 6RD. It was a transitional band-aid for legacy copper/VDSL and is basically dead now (AT&T Fiber uses native DHCPv6-PD). On mobile, it's just standard *GTP (GPRS Tunneling Protocol)*. The cell tower tunnels everything back to the PGW (Packet Data Network Gateway). When your session attaches (using a specific APN for device vs. hotspot), the PGW pulls a /64 from a local regional pool and hands it to the session. No mathematical derivation needed, the GTP tunnel itself handles the transport. 4. What accounts for the ~200ms latency delta between the roaming partners? This actually boils down to *IPX (IP Exchange) providers and home routing*. When you roam in Taiwan your data doesn't directly connect to the internet. Instead it's encapsulated in a GTP tunnel and sent back to an AT&T PGW in the US. Mobile carriers use middleman IPX networks (like Syniverse or BICS) to route these tunnels. The 200ms delta means one Taiwanese carrier's IPX has a direct trans-Pacific path to an AT&T gateway (e.g., LA), while the other is taking a really suboptimal path (e.g., routing through Europe before hitting the US East Coast). 5. Why do VZW and T-Mobile not provide IPv6 while roaming? This is exactly why Verizon and T-Mobile are more conservative. Tunnelling IPv6 inside GTP over these complex, multi-hop IPX paths is notoriously brittle. If an IPX middleman has MTU issues or doesn't properly support the IPv6 PDP type in their signalling, the connection just dies. By forcing an IPv4-only PDN while roaming, VZW/T-Mo ensures the tunnel remains stable regardless of how many transit providers it hits. — Reply to this email directly, view it on GitHub <https://gist.github.com/agoodkind/153a146d0d30adee4ac94890896bf8ce#gistcomment-6121735> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHYOUBR6S5UV2Z37RGM2RD4X7BGRBFHORZGSZ3HMVZKMY3SMVQXIZNMON2WE2TFMN2F65DZOBS2WR3JON2EG33NNVSW45FGORXXA2LDOOIYFJDUPFYGLJDHNFZXJJLWMFWHKZNJGE2DMMBTGE4DMNFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLKJSG44TQMRYGIYTLJDOMFWWLKDBMN2G64S7NFSIFJLWMFWHKZNEORZHKZNENZQW2ZN3ORUHEZLBMRPXAYLSORUWG2LQMFXHIX3BMN2GS5TJOR4YFJLWMFWHKZNEM5UXG5FENZQW2ZNLORUHEZLBMRPXI6LQMU> . You are receiving this email because you authored the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

That's fair enough. Honestly, #4 and #5 are just my best guesses since the whole thing is tunnelled.

Given that your data traveled through a GTP tunnel from the Taiwanese cell tower all the way to AT&T in the US, the intermediate network(s) are essentially a black box. Standard traceroutes can't penetrate the tunnel to reveal the actual physical hops so we're left guessing why one connection is 200ms slower based solely on the ping.

Regarding the T-Mobile/Verizon vs AT&T IPv6 comparison, I believe much of it stems from the fact that IPv6 is still somewhat unusual outside the US. It's not universally adopted yet some foreign carriers support it while others completely struggle with it. T-Mobile likely enforces IPv4 while roaming as a "safe mode" to ensure a successful connection on the first attempt whereas AT&T seems comfortable taking the risk with the IPv6 connection.

Also, please forgive my new account appearance. I had actually been curious about AT&T's NAT66 for a good while now but couldn't find any discussion on it, it seems like nobody really talks about this proxy/NAT66 stuff! I only stumbled onto your gist when I was googling around about AT&T fiber's 2001:506 IPv6 addresses, which made me want to share my findings too.

I wish I had concrete evidence to support my claims but the tunnel conceals all the relevant information. I'm glad the proxy details were interesting though!

Well it shouldn’t matter because the SS7 doesn’t care about what’s inside the the tunnel

…

On Wed, Apr 29, 2026 at 08:59 delicatemythology ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ That's fair enough. Honestly, #4 and #5 are just my best guesses since the whole thing is tunnelled. Given that your data traveled through a GTP tunnel from the Taiwanese cell tower all the way to AT&T in the US, the intermediate network(s) are essentially a black box. Standard traceroutes can't penetrate the tunnel to reveal the actual physical hops so we're left guessing why one connection is 200ms slower based solely on the ping. Regarding the T-Mobile/Verizon vs AT&T IPv6 comparison, I believe much of it stems from the fact that IPv6 is still somewhat unusual outside the US. It's not universally adopted yet some foreign carriers support it while others completely struggle with it. T-Mobile likely enforces IPv4 while roaming as a "safe mode" to ensure a successful connection on the first attempt whereas AT&T seems comfortable taking the risk with the IPv6 connection. Also, please forgive my new account appearance. I had actually been curious about AT&T's NAT66 for a good while now but couldn't find any discussion on it, it seems like nobody really talks about this proxy/NAT66 stuff! I only stumbled onto your gist when I was googling around about AT&T fiber's 2001:506 IPv6 addresses, which made me want to share my findings too. I wish I had concrete evidence to support my claims but the tunnel conceals all the relevant information. I'm glad the proxy details were interesting though! — Reply to this email directly, view it on GitHub <https://gist.github.com/agoodkind/153a146d0d30adee4ac94890896bf8ce#gistcomment-6125896> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHYOUDL2VGFKJVOUQH5GFT4YIRFZBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLKJSG44TQMRYGIYTLJDOMFWWLKDBMN2G64S7NFSIFJLWMFWHKZNEORZHKZNENZQW2ZN3ORUHEZLBMRPXAYLSORUWG2LQMFXHIX3BMN2GS5TJOR4YFJLWMFWHKZNEM5UXG5FENZQW2ZNLORUHEZLBMRPXI6LQMWWHG5LCNJSWG5C7OR4XAZNLI5UXG5CDN5WW2ZLOOSTHI33QNFRXHEMCUR2HS4DFURTWS43UUV3GC3DVMWUTCNBWGAZTCOBWGSTXI4TJM5TWK4VGMNZGKYLUMU> . You are receiving this email because you authored the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .