Azure Front Door IPv6 TCP failure from Orange Poland AS5617

azure-ipv6-report.md

Azure Front Door IPv6 TCP Connectivity Failure from Orange Poland (AS5617)

Summary

TCP connections to Azure Front Door IPv6 endpoints in the 2620:1ec::/32 range fail completely from Orange Poland's IPv6 network (AS5617). ICMP probes successfully reach Azure's internal infrastructure, confirming the issue is not a BGP peering problem — packets enter Azure's network but TCP sessions to the Front Door anycast IPs never complete. Multiple production sites using Azure Front Door are affected.

---

Affected Endpoints

DNS name	CNAME chain	Azure Front Door IPv6
www.doz.pl	→ ecom-apps-drdncufehfg0euds.a03.azurefd.net → dual.part-0016.t-0009.fb-t-msedge.net	2620:1ec:48:1::44, 2620:1ec:29:1::44
www.bankmillennium.pl	→ Azure Front Door	2620:1ec:48:1::44

Both resolve to the same Azure Front Door IPv6 addresses. IPv4 connectivity to these sites is fully functional.

---

Source Network

• ISP: Orange Poland (TPNET)
• AS: AS5617
• IPv6 source prefix: 2a01:110f:4e0e:da00::/64 (DHCPv6-PD delegated /56: 2a01:110f:4e0e:da00::/56)
• Test machines: Two independent hosts on the same prefix (NixOS/Linux and Windows 11)

---

Evidence

1. DNS Resolution

www.doz.pl → ecom-apps-drdncufehfg0euds.a03.azurefd.net
           → mr-a03.tm-azurefd.net
           → dual.part-0016.t-0009.fb-t-msedge.net
           → 2620:1ec:29:1::44 (AAAA)
              2620:1ec:48:1::44 (AAAA)
              13.107.226.44    (A)

2. TCP Connection Test (Linux/luna, curl)

$ curl -6 -v --connect-timeout 5 https://www.doz.pl/
*   Trying [2620:1ec:48:1::44]:443...
* Connection timed out after 5001 milliseconds

Same result from Windows host on the same network. IPv4 succeeds immediately:

$ curl -4 -v https://www.doz.pl/
* Connected to www.doz.pl (13.107.226.44) port 443
< HTTP/2 200

3. MTR from Linux host (luna, 2a01:110f:4e0e:da00:e4a7:db11:70f9:623b)

HOST: luna                         Loss%   Snt   Last   Avg
  1. 2a01:110f:4e0e:da00::1          0.0%    5    0.9   0.7   <- MikroTik router
  2. 2a01:1000::6ca                   0.0%    5    5.3   4.6   <- Orange PL
  3. 2a01:1000:0:5ca::1               0.0%    5    3.9   3.6
  4. 2a01:1000::35                    0.0%    5    2.7   5.8
  5. 2a01:1100:0:100::129            80.0%    5    3.8   3.8   <- ICMP rate-limited (normal)
  6. 2a01:111:2000:2:8000::f5d        0.0%    5    3.0   3.5   <- Microsoft AS8075
  7. 2a01:111:2000:6::461e            0.0%    5   23.3  22.1
  8. 2a01:111:201:f200::1242         60.0%    5   21.2  21.9   <- ICMP rate-limited (normal)
  9. 2a01:111:201:f200::1131          0.0%    5   20.9  21.6
 10. 2a01:111:2000:6::4fcd            0.0%    5   22.2  21.6
 11. 2603:10a0:1203:1200::e           0.0%    5   19.8  19.8   <- Azure internal
 12. 2603:10a0:1203:1101::e           0.0%    5   22.4  21.9
 13. 2603:10a0:120c:390::             0.0%    5   19.8  20.3
 14. 2603:10a0:120c:390::1a           0.0%    5   19.8  20.2
 15. ???                            100.0%    5    0.0   0.0   <- ICMP blocked at endpoint (expected)

ICMP probes transit Orange PL cleanly, enter Microsoft's network at hop 6 (2a01:111:..., AS8075), traverse Azure's internal backbone (2603:10a0:...), and reach the penultimate hop at ~20ms RTT. The issue is not ICMP loss — it is that TCP connections to 2620:1ec:48:1::44:443 do not complete.

4. Windows tracert (host 2a01:110f:4e0e:da00:...)

Tracing route to 2620:1ec:48:1::44

  1    625 ms   2a01:110f:4e0e:da00::1    <- local router
  2   1117 ms   2a01:1000::6ca            <- Orange PL
  3    509 ms   2a01:1000:0:5ca::1
  4    372 ms   2a01:1000::35
  5      *        2a01:1100:0:100::129
  6    849 ms   2a01:111:2000:2:8000::f5d <- Microsoft AS8075
  7    545 ms   2a01:111:2000:6::461a
  8    235 ms   2a01:111:201:f200::1246
  9   1333 ms   2a01:111:2000:6::4ca9
 10   1303 ms   2603:10a0:1203:9100::1e
 11    107 ms   2603:10a0:1203:9301::26
 12   1311 ms   2603:10a0:120c:391::
 13    935 ms   2603:10a0:120c:391::1e    <- last visible hop
 14-30  *  *  *  Request timed out.

Note: high latency on first hops is a Windows IPv6 stack artifact — not indicative of actual path latency (Linux MTR shows ~20ms end-to-end).

---

Key Observation

ICMP probes traverse 2a01:111:... → 2603:10a0:... (Azure backbone), reaching deep into Azure's infrastructure. However, TCP connections to 2620:1ec:48:1::44 (Front Door anycast) time out. This indicates a routing inconsistency within Azure's network: ICMP is forwarded correctly while TCP packets to 2620:1ec:48::/48 are dropped or routed to a black hole after entering AS8075.

This is not an Orange Poland peering issue. IPv6 BGP peering between AS5617 and AS8075 is functional.

---

Reproduction Steps

1. From any host on Orange Poland IPv6 (AS5617):
2. curl -6 --connect-timeout 10 https://www.doz.pl/ → times out
3. curl -4 --connect-timeout 10 https://www.doz.pl/ → succeeds immediately
4. curl -6 --connect-timeout 10 https://www.bankmillennium.pl/ → times out

---

Impact

• All Orange Poland residential/business IPv6 users attempting to access Azure Front Door-hosted sites experience timeouts
• Modern browsers (RFC 6555 Happy Eyeballs) wait the full fallback timeout before switching to IPv4; some clients do not fall back at all and fail entirely
• Affected sites include at minimum: www.doz.pl, www.bankmillennium.pl; any site on Azure Front Door with AAAA records is likely affected for Orange PL users

---

Requested Action

1. Investigate routing within AS8075/Azure Front Door for destination 2620:1ec:48::/48 from source AS5617 (2a01:110f:4e0e::/48)
2. Verify TCP packets (port 443) from AS5617 are delivered to the correct Front Door PoP
3. Check for ACL or routing policy filtering traffic from AS5617 to 2620:1ec::/32

---

Report generated: 2026-05-13. Testing from Orange Poland FTTH, Warsaw area.