EE's IPv4v6 bearer APN is weird - jamesmacwhite/hh70-ee GitHub Wiki

True story. EE has a IPv4v6 bearer APN which should in theory provide dual stack connectivity, however this isn't quite true in some cases. On a modern mobile device with IPv6 support, it should work fine and you'll not notice anything major. This is likely because it is actually NAT64. If you start going outside the typical use cases you can come across some interesting finds. If any EE network engineers or the man himself Nick Heatley sees this, please get in touch and clarify this weirdness with your network, thanks!

Quick summary of the available bearer options on EE:

IPv4 - Heard you like NAT, so EE added more NAT to your NAT (CGNAT basically)
IPv4v6 - Apparently dual stack, but might not work in the way you think.
IPv6 - Go bold with IPv6 only. Good luck.

EE deploys 464XLAT and NAT64 with DNS64 resolvers in their network. EE's own 4GEE Home Router defaults to IPv4v6 APN configuration out of the box but it doesn't actually ever allocate any IPv6 address automatically, which is strange considering how EE has been quite pro IPv6 on the mobile network. You can force having an IPv6 under this configuration by doing the following process:

Disconnect from the EE network, set the APN to IPv6 only
Reconnect under the IPv6 APN and wait for an IPv6 address to be allocated, then disconnect again
Set the APN back to IPv4v6 and connect back to the network one last time

You'll then get an IPv6 address in addition to an IPv4 address which is through CGNAT. You would have been allocated an IPv6 address after step two, but subsequently allocated another different IPv6 address in a different prefix after step three. I am not sure however if this is really how the IPv4v6 APN is intended to work. You will lose IPv6 connectivity after restarting or disconnecting from the network and have to repeat the steps above to restore it. So to me, it's probably not something that's really intended but it kind of works...

This possible quirk does however allow you have IPv4 connectivity without having to use NAT64, you can directly ping and traceroute with native IPv4 literals albeit with CGNAT alongside IPv6. I tested the EE IPv4v6 APN with another LTE modem that's not provided by EE themselves and found while the IPv4v6 bearer did automatically configure an IPv6 address without any issue, it does not allow IPv4 literals to work simultaneously which to be fair is somewhat expected when it is using 464XLAT and NAT64. The main issue was any IPv4 only website needed to be resolved by the EE DNS64 resolvers to provide a "fake IPv6 address", otherwise the traffic could not be routed, IPv4 literals were broken. There have been other reports of IPv4v6 not working as expected with the dual stack APN on other modems that aren't from EE themselves. I dropped over £100 on a Netgear LB2120 to find this out. I now need to figure out what I can do with it to pretend I didn't just waste 3 figures on hardware for an experiment.

More EE IPv4v6 fun

Connecting to the 4GEE Home Router over WiFi, removing any bespoke VLAN or WAN failover configuration I use, so it's just the EE router/modem device in the path. We can see DNS64 is indeed in play. I normally do not use my 4GEE Home Router this way and instead tap into this somewhat weird IPv4v6 bearer behaviour with OpenWrt and mwan3 for failover.

Firstly someone at EE should set a proper reverse DNS record for their DNS resolvers, just seems a bit lazy.

Server:  UnKnown
Address:  2a01:4c8:f000:1::1

Non-authoritative answer:
Name:    ee.co.uk
Addresses:  64:ff9b::2d3c:4117
          64:ff9b::2d3c:4817
          45.60.72.23
          45.60.65.23

Wait, ee.co.uk doesn't have actual AAAA records?! Lol, pretty bad when you can't have your own website available over IPv6 and it has to be translated to a NAT64 address BY YOUR OWN NETWORK. Inception.

However, at least with the EE modem, I can ping the normal ee.co.uk IPv4 addresses and do a traceroute still, even if it prefers the NAT64 address by default. Ironically the traceroute binary on the 4GEE Home Router is so old it only supports IPv4, it cannot handle IPv6 (sendto: Address family not supported by protocol error). You can however do traceroute over IPv6 with the modem side, as the binary is newer.

So how are IPv4 literals working when this is meant to be 464XLAT? The answer is, it isn't using it?

Here's a traceroute using a literal IPv4 that somehow works just fine:

192.168.3.1 - EE Router (I've changed the LAN range to 192.168.3.0/24)
192.168.225.1 - EE modem part which is a Qualcomm MDM9640
Various hops within 10.0.0.0/8 - EE's NAT gateways most likely
87.237.20.150 and 87.237.20.71 - Seem to be EE still, possibly their edge network.
195.66.226.47 - LINX (London Internet Exchange)
45.60.72.23 - The cloud host for ee.co.uk

Tracing route to 45.60.72.23 over a maximum of 30 hops

  1     2 ms     2 ms     1 ms  192.168.3.1
  2     4 ms     4 ms     3 ms  MDM9640 [192.168.225.1]
  3     *        *        *     Request timed out.
  4    55 ms    36 ms    37 ms  10.248.27.165
  5    24 ms    23 ms    20 ms  10.247.85.173
  6     *        *        *     Request timed out.
  7    20 ms    19 ms    29 ms  10.247.85.113
  8    24 ms    23 ms    20 ms  10.247.85.178
  9    42 ms    58 ms    27 ms  87.237.20.150
 10    65 ms    41 ms    77 ms  87.237.20.71
 11    47 ms    27 ms    25 ms  195.66.226.47
 12    26 ms    26 ms    27 ms  45.60.72.23

The IPv4v6 bearer seems to behave differently on their own modem devices while other modems just break with IPv4 literals, which is to be expected with 464XLAT after all as it specifically can't handle this scenario, but somehow EE's modem can still route IPv4 natively, without NAT64. Very interesting.

Conclusion. Use caution when using a third party modem with EE and the mobile network. Bridge mode is essentially pointless due to CGNAT on IPv4 anyway. Likewise all IPv6 is filtered inbound. The IPv4v6 bearer may not do dual stack like you think! Even on EE's own router/modem it's really weird.