topic Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP in Broadband & Landline

IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Sun, 08 Feb 2026 12:10:34 GMT

I'd love to hear if anyone can validate this -- I've been fighting with an iOS power drain issue, but in fact it's actually a IPv6 issue which occurs both with the EE Homehub AND with a opnsense router. Basically it seems as if the EE network is breaking path mtu discovery both by dropping fragments, and in not returning the correct ICMP responses.

This is quite technical but it's quite a fundamental issue (it feels to me as it's a 'broken network'). Of course I may have made an error:

More complete AI-summarised version below.

Observation: The upstream network (EE/Openreach backhaul) appears to silently discard outbound IPv6 packets that require fragmentation. This breaks Path MTU Discovery (PMTUD), causing connectivity stalls and high battery drain on devices attempting to negotiate packet sizes (e.g., Apple devices using iCloud Private Relay).

Context: ISP/Plan: EE Full Fibre 900/110. Hardware: Tested on EE Smart Hub Plus and confirmed consistent on OPNsense (Intel N100). MTU: Link negotiates at 1492 bytes (PPPoE standard).

The Limitation: The network accepts unfragmented packets up to the link limit (1492 bytes) but drops any packet that is fragmented, regardless of total size. Crucially, it fails to send back ICMPv6 Type 2 (Packet Too Big) or Type 3 (Time Exceeded), creating a silent "black hole."

Test Methodology (Reproducible)

You can replicate this on any Linux/macOS device (Pi, Mac, etc.) connected to the router. You need two terminal windows open.

Step 1: The Monitor (Terminal A) Run this to listen for "Packet Too Big" or error messages from the ISP.

sudo tcpdump -n -i any "icmp6 && (icmp6[0] == 1 || icmp6[0] == 2 || icmp6[0] == 3)"

Step 2: The Trigger (Terminal B) Run these pings to test the boundary.

Test A (Standard Packet - 1492 bytes): Payload 1444 + 48 bytes headers = 1492 bytes (Fits in one frame)

ping6 -c 3 -s 1444 ipv6.google.com

Result: Success.

Test B (Fragmented Packet - 1493 bytes): Payload 1445 + 48 bytes headers = 1493 bytes (Forces fragmentation)

ping6 -c 3 -s 1445 ipv6.google.com

Result: 100% Packet Loss.

Step 3: Verification Look at Terminal A. Expected Behavior (RFC Compliant): You should see an ICMPv6 error message. Actual Behavior (Black Hole): The terminal remains completely blank. The packets are dropped silently.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

bobpullen — Mon, 09 Feb 2026 17:10:54 GMT

@planetf1b wrote:
I'd love to hear if anyone can validate this...

Using your commands, can confirm the same outcome.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Mon, 09 Feb 2026 21:13:29 GMT

Thanks. Glad to know it’s not just me, but I’m surprised and disappointed. Despite cs variability I really thought be/ee core network would be solid.

I’m going to try to report bot from reading around I think this has been an issue for ages

Definitely now thinking I may move to another network once contract is up in a few months.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Mon, 09 Feb 2026 22:08:21 GMT

Here's a clearer write-up after some more experiments tonight. Next the challenge is to get a ticket opened

EE Broadband – IPv6 PMTUD Failure (ICMPv6 Type‑2 Filtering) – Fault Report

Summary: IPv6 Path MTU Discovery (PMTUD) is failing on this EE broadband connection due to ICMPv6 Type‑2 (Packet Too Big) messages being filtered somewhere between EE’s access network and the customer premises. This breaks standards‑compliant IPv6 behaviour and causes real‑world service failures, including iCloud Private Relay.

1. Local MTU Verified Correct (1500 bytes)

The customer LAN and CPE are operating with a standard 1500‑byte Ethernet MTU.

Validation:

ping6 -s 1452 <host> → succeeds (1452 + 8 + 40 = 1500 bytes total)
ping6 -s 1453 <host> → fragments locally (expected)

This confirms the issue is not caused by the local network.

2. Public IPv6 Path with PMTU 1280 Identified

Testing against www.reuters.com (CloudFront) reveals a real PMTU of 1280 bytes:

ping6 -s 1232 (1280 total) → success
ping6 -s 1233 (1281 total) → consistent failure

This is a valid, standards‑compliant test case where routers must generate ICMPv6 Type‑2 messages.

3. ICMPv6 Type‑2 Messages Not Received

While sending packets larger than 1280 bytes, a packet capture was run:

Code

sudo tcpdump -i <interface> -n 'icmp6 && ip6[40] == 2'

Result:

No ICMPv6 Type‑2 messages observed
Pings above 1280 bytes hang with 100% loss

This is the exact condition where RFC 8201 requires routers to send Packet‑Too‑Big messages. Their absence indicates filtering of ICMPv6 Type‑2 on the EE path.

4. Other ICMPv6 Types Are Received Normally

Earlier tests produced:

ICMPv6 Type 3 Code 1 (fragment reassembly failures) from Akamai

This confirms:

ICMPv6 is not globally blocked
The filtering is selective, affecting Type‑2 specifically

5. Customer‑Visible Impact: iCloud Private Relay Fails

iCloud Private Relay relies on:

IPv6
QUIC/HTTP‑3
Encapsulation (additional headers)
PMTUD to discover the true MTU

With a real PMTU of 1280 and no Packet‑Too‑Big messages, Relay traffic cannot adjust packet size and stalls. The same Apple ID works correctly on other networks, confirming the issue is specific to this EE connection.

This is a direct customer‑visible service failure.

Conclusion

EE Broadband is filtering ICMPv6 Type‑2 (Packet Too Big) messages on this line or its associated BNG. This breaks IPv6 PMTUD and causes failures for:

iCloud Private Relay
QUIC/HTTP‑3
CDN‑backed services
VPNs and tunnels
Any IPv6 path with MTU <1500

The issue is fully reproducible using www.reuters.com, which exposes a real PMTU of 1280.

Requested Action

Please escalate to EE’s core network engineering team to:

Review ICMPv6 filtering policy on the affected BNG/BRAS.
Ensure ICMPv6 Type‑2 (Packet Too Big) messages are permitted end‑to‑end.
Validate PMTUD behaviour on IPv6 paths with MTU <1500.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

XRaySpeX — Mon, 09 Feb 2026 23:55:23 GMT

@planetf1b wrote:
Please escalate to EE’s core network engineering team to:

This user discussion group is not the correct platform for formally escalating issues & requiring their fix in EE systems. You previously requested we validate your findings which @bobpullen did. That was fine but this is a step too far. You need to report your issues to CS (& God help you they understand this). Failing any progress that way you could raise a complaint.

You can make a formal complaint to EE & if you don't get satisfaction after 8 weeks or come to a deadlock you can take it to EE's ADR provider. See Complaints code of practice and here is the Complaints Form . What the Ombudsman will make of this I dread to think.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

XRaySpeX — Mon, 09 Feb 2026 23:56:32 GMT

@bobpullen : Would this apply to all EE FTTP?

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

bobpullen — Tue, 10 Feb 2026 11:20:53 GMT

@XRaySpeX - I strongly suspect the outcome of the OP's tests will be the same on any BT/EE connection. I can confirm the same outcome on an IPv6-enabled Plusnet line I have access to.

@planetf1b wrote:
Customer‑Visible Impact: iCloud Private Relay Fails

How is Private Relay visibly failing? What are the symptoms? If I enable Private Relay on one of my iPads, I don't seem to notice any ill effects? 🤔

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Tue, 10 Feb 2026 12:00:18 GMT

Oh wow, I had hoped it was just a one-off on a badly configured bit of kit. To intentionally block packet too big is a MASSIVE issue.

I tried to go through the call centre today, but after 3 hours I gave up. I've instead emailed the ceo office - I completely couldn't figure out how to move forward as it's a very precise technical issue.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

bobpullen — Tue, 10 Feb 2026 13:02:25 GMT

@planetf1b wrote:
Oh wow, I had hoped it was just a one-off on a badly configured bit of kit. To intentionally block packet too big is a MASSIVE issue.

What massive issues are you experiencing though? Whilst I understand to a degree what your tests are doing, I'm also not confident enough to say that they're a conclusive indicator of ICMP too big responses being dropped out in the network. Have you repeated the tests on a non-BT connection with differing results?

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

Ewan15 — Wed, 11 Feb 2026 07:56:40 GMT

I tested this just using ping on a Windows device on PowerShell using

ping -6 2001:4860:4860::8888 -l 1400
ping -6 2001:4860:4860::8888 -l 1440
ping -6 2001:4860:4860::8888 -l 1472
ping -6 www.reuters.com -l 1440
ping -6 www.reuters.com -l 1280

I then asked CoPilot to interpret the results as below

The behaviour you’re seeing is not caused by “fragmentation”
Routers on IPv6 never fragment, so nothing is being “discarded because it requires fragmentation.”
Instead, what’s happening is:
• You send a packet larger than the path MTU
• A router along the path drops it
• That router is supposed to send back ICMPv6 Type‑2 (Packet Too Big)
• If that Type‑2 message never reaches you, PMTUD breaks
So the real question is:
Are Type‑2 messages being lost on the path?
Your tests give a mixed answer.

What your results actually show
To Google IPv6
• 1440 works
• 1452 fails
• Clean, repeatable boundary
This is exactly what working PMTUD looks like.
It means:
• EE/Openreach is not filtering Type‑2 on that path
• Your host is learning the MTU correctly
• The path MTU is ~1492 (classic PPPoE)
To Reuters IPv6
• 1400 fails
• 1280 works
• No clean boundary above 1280
• Behaviour is consistent with a remote MTU bottleneck, not EE
This is what happens when the far end (or its CDN) sits behind tunnels with a very small MTU.
Akamai, Cloudflare, Fastly, and similar CDNs often have edges behind:
• GRE
• IPsec
• DDoS scrubbers
• Multi‑layer encapsulation
Those can reduce MTU to 1280–1400.
Your results match that perfectly.

So is EE/Openreach “silently discarding outbound IPv6 packets that require fragmentation”?
No — that’s not what your data shows.
If EE were dropping Type‑2 messages, you would see:
• Google IPv6 failing at all large sizes
• No clean cutoff
• Random timeouts
• Broken PMTUD across all destinations
• TCP stalls everywhere
• iCloud Private Relay failing consistently
But instead:
• Google path shows perfect PMTUD
• Reuters path shows remote MTU constraints, not EE filtering
• Your EE line behaves exactly like a normal PPPoE IPv6 connection
So the upstream is not “silently discarding packets that require fragmentation.”
It’s simply enforcing its MTU, and PMTUD is working.

Why Apple devices sometimes struggle
This part of your observation is real, but the cause is different.
Apple’s iCloud Private Relay is extremely sensitive to:
• PMTUD failures
• Small MTUs
• CDNs with 1280‑byte edges
• Networks that block any ICMPv6 (not just Type‑2)
So if a remote service (like Reuters’ CDN) has a tiny MTU, Apple devices may:
• retry aggressively
• drain battery
• stall connections
• switch between IPv4/IPv6 repeatedly
This is a known behaviour of Private Relay, but it doesn’t mean EE is filtering Type‑2.

The accurate interpretation
A more precise version of your observation would be:
“Some IPv6 destinations (e.g., Reuters via Akamai) appear to sit behind very small MTUs. PMTUD works correctly on EE/Openreach, but the remote path MTU is low enough that certain services—especially Apple Private Relay—may experience stalls or retries.”
This matches your measurements exactly.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

JimM11 — Wed, 11 Feb 2026 10:51:42 GMT

@Ewan15 You will also find on the Ispreview Forum topic discussion with the OP!

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Wed, 11 Feb 2026 11:48:45 GMT

@Ewan15 Thanks *so* much for trying that out!

Router's can't fragment on IPv6 - however clients can, so they send the base packet, then a packet with an extension header (44). These are discarded on some networks, but I don't think this is EE -- it's variable depending the routing - it's also, annoyingly, quite common as there's a concern of DoS and other attacks from fragmented packets. So if say a tunneled route (vpn) uses a mtu such that it's tunneled packets won't fit in the actual connection, then the fragments will be created there. But that's all local. It cannot send anything > mtu (hence fragments)

Anyway lots of places do that, so my main focus was on the icmpv2 responses.

Google is failing at 1452 because we have payload (1452) + icmp v6 header (8) + ipv6 header (40) = 1500

Whilst this is the physical interface mtu, the actual advertized mtu for the ipv6 route is 1492. You can see this in an RA from the EE hub:

On *nix this can be seen with: sudo tcpdump-ni <interface> -vv ip6 and icmp6 and 'icmp6[0] == 134'

Within that there'll be a line

mtu option (5), length 8 (1): 1492

So in this case it is your local device that knows the packet is too large, and therefore sending a *LOCAL* response. It's not validating the network.

Google will actually go up to 1452 if you use 'baby jumbo' frames (I've tested) -- and this is fine with EE.

As was pointed earlier one 'flaw' in my original post is I picked specifically on reuters as causing a problem, but that doesn't prove or disprove it's EE. I've also had issues with *some* amazon endpoints (from both mac and linux) (for example with a packet size of less than 1300).

WHat's odd is I've *never* seen an ICMP type 2 packet arrive

A specific example. This is one resolved amazon address (I've seen it with other providers too)

sudo ping6 -c 5 -s 1444 -D 2a00:23c7:60de:c700:8872:afc7:95e6:2265
->
ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4085ms

even whilst:

sudo tcpdump -ni any -vv ip6 and icmp6 and 'icmp6[0] == 2' &

is running

So it's possible amazon (or any intermediate transit) is blocking them. Or reuters.. Or ....

I can believe there is some varied configuration in the links - which may be why they have varying mtus.. but I'd be surprised if they'd all also block the responses?

Really need to test on another isp ...

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

mayo123 — Thu, 12 Feb 2026 10:45:36 GMT

I have configured my Ethernet MTU to 1508 to allow an MTU of 1500 on my EE FTTP connection. When I run one of the examples above I do not experience packet loss:

pi@raspberrypi:~ $ ping6 -c 3 -s 1445 ipv6.google.com
PING ipv6.google.com(uv-in-f101.1e100.net (2a00:1450:4009:c15::65)) 1445 data bytes
1453 bytes from uv-in-f101.1e100.net (2a00:1450:4009:c15::65): icmp_seq=1 ttl=113 time=6.05 ms
1453 bytes from uv-in-f101.1e100.net (2a00:1450:4009:c15::65): icmp_seq=2 ttl=113 time=5.93 ms
1453 bytes from uv-in-f101.1e100.net (2a00:1450:4009:c15::65): icmp_seq=3 ttl=113 time=6.73 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 5.931/6.237/6.734/0.354 ms

Does this help at all? With your connection are you experiencing 100% packet loss when running the above command?

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Tue, 03 Mar 2026 22:59:34 GMT

I've done a more in-depth analysis

The scripts I used, and results are at : planetf1/bt-ee-ipv6-blackhole · Discussions · GitHub

In summary
* Some sites work fine with a 1500 mtu including apple, cloudflare
* others fail - aws, gcp
* this in itself is normal/not an issue. However the network not responding with 'packet too big' is a serious issue and protocol breakage

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

Mustrum — Tue, 03 Mar 2026 23:44:07 GMT

@planetf1b Could this be another limitation within the network related to the UDP issue mentioned https://community.ee.co.uk/t5/Broadband-Landline/UDP-Packet-drop/td-p/1571725 ?

Getting to the right level of technical support is going to be you biggest challenge I suspect.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

bobpullen — Thu, 05 Mar 2026 17:05:59 GMT

@Mustrum - I doubt there's any correlation; the two problems are very different in nature.

That said, I'm still at a bit of a loss to understand what @planetf1b's 'real world' problem actually is?

eg. there's mention of problems using Apple Private Relay and docker pull commands but I have zero issues with either of these 🤔

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Tue, 10 Mar 2026 07:34:11 GMT

I have taken some time to put together a more technically detailed *and reproducible* analysis -- the previous discussion was a little ad-hoc (my fault).

This new writeup is technical and precise, and should be reproducible (or at least be able to rerun) by others. I hope it's also suitable for quick review by a network engineer. I've seperately shared an earlier version in a community forum and at least one person has reproduced similar issues with the script.

https://github.com/planetf1/bt-ee-ipv6-blackhole

In summary the current EE IPv6 support seems to breach standards which causes application failures

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Tue, 10 Mar 2026 07:42:31 GMT

@bobpullen you asked about real-world impact - and I agree it may not be obviously apparent.

Applications will use a mix of different network protocols to communicate.

Firstly there's IPv4 and IPv6. Which is chosen is affected by the ways names resolve to addresses (depending on DNS server for example) as well as their own logic. Some will prioritize IPv6, others may do not.

Then there's different protocols like TCP (making a connection), UDP (connectionless). And even within either there may be further layers like VPN tunnels.

Most of these apps will have some 'fall-back' to work around broken infrastructure. Sometimes the protocols themselves have tweaks built in to detect these 'black holes'

Typically the impact can be one of several things
- No impact
- a delay on first connection (quite typical)
- higher power drain (this is where I started... on a mobile device the 'radio' is kept active whilst waiting for a reply to a request that never arrives. With many apps and overnight this adds up)
- connection stalls - starts working (when packet size is smaller) then pauses (for a bigger picked when it gets no response)
- connection failures - Anything using a tunnel may fail to establish the connection in the first place.

So what we have is a whole bunch of 'odd' behaviour where many may struggle to specifically associate the issue above with the problem (usually delays or unreliability).

The above is an attempt (as an engineer) to tease out & discover the root cause (at least as far as the end user on a connection is concerned) to get answers/fixes from the network provider.

Hope that helps a little -- but I do empathize with the view 'it's working for me'. the truth is there are multiple layers trying to work around the problem, and causing side effects.

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

bobpullen — Tue, 10 Mar 2026 11:03:20 GMT

@planetf1b - thanks, I broadly understand the underlying network principles.

I'll not press the matter but have to admit, I still remain confused as to what noticeable application use-case is falling foul of this outside of your analysis/what AI thinks. From your listed impacts, it sounds to me that the 'only' thing you've personally encountered is smartphone battery drain? It would be interesting to see some evidence that correlates the two things e.g. a packet capture showing a native smartphone application sending large IPv6 payloads, failing to get a response, re-transmitting, stalling, falling back to IPv4 etc.

@bobpullen wrote:
Have you repeated the tests on a non-BT connection with differing results?

I also think this ^ might help validate/further your case i.e. an example of your tests doing what you're expecting them to do whilst connected to a non BT/EE Internet connection.

Another thought is that you could try removing your router/hub from the equation by hooking a PC up to the ONT directly and having it use a PPPoE dial-up connection; if only to remove a point of obfuscation.

What's piqued my curiosity is the fact that there a a few online tests out there that purport to check for this sort of thing; and when I try running them, they all pass 🤔

From the 'Tests Run' tab > Technical info here: -

From here: -

Re: IPv6 Fragmentation "Black Hole" on EE/BT 900Mb FTTP

planetf1b — Tue, 10 Mar 2026 16:19:10 GMT

Thanks for the reply
- the summary is AI-assembled (hopefully for clarity!) but I'm a software engineer and was adding IPv6 support to apps in he late 1990s... 😉
- some sites work perfectly at 'large' mtus (right up to 1500 mtu - 1440 mss - if using RFC 4638 - though the EE router is only configured for 1492/1432 due to the 8 byte overhead for ppp). The issue is that some sites/routes cannot take the full size, which in itself is fine, except that the sender never gets notified.. (except through timeout etc)
- I mostly use opnsense (open source router based on Free BSD), but have also used a EE hub for comparison
- I work in sw dev, so will look at apps misbehaving (is it a broken app, the os etc) this is clearly a network issue. cumulative effect of timeout on battery can be huge, and delays can = bad user experience
- Agree ref: other iSP. I did actually run some tests on a hosted service.. I should include those results as a comparison

I'm back in touch with the exec office. Not much more I can do beyond that except switch ISP.