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>