By their own admission CF receives a ridiculous amount of garbage traffic at this IP, it was not absurd for AT&T engineers in the past to thing "well, we need an IP that we can be reasonably sure nobody is going to use and is never going to conflict with anything on any network, 1.1.1.1 seems reasonable". Seeing everybody in this thread jumping into conspiracy theories instead of the much more likely configuration issue is a bit disappointing for a community that's supposed to understand technology.
That is an utterly unreasonable conclusion.
The same logic resulted in Y2K, which was generally a huge waste of time, money, and resources.
The same logic has resulted in the anemic adoption of IPv6, which is NOT a correct solution, because it doesn't work properly for large swaths of the public.
The correct answer always was, and will continue to be, to use internal routes for internal routing, and external routes for external. Clashes with your LAN? Too fucking bad.
This sort of pushing out of externalizes onto the customer results in the same exact outcome anyway: customer gets screwed.
The customer always gets screwed. Don't rationalize the incompetence of engineers who should know better, and corporate execs who don't give a fuck.
Do that and the FCC will come down on you like a tonne of bricks, and I feel that is absolutely justified.
That said, we agree on the probable cause of this particular issue.
Unless you're actually trying to say that AT&T has a grudge against Cloudflare and are only doing this to harm their company.
This is something more like negligence or gross negligence.
That's not wholly unthinkable as far as AT&T is concerned. They're historically a bad player.
This caused issues where my phone would try to get on wifi, but the DHCPACK would be sent along on the existing interface rather than the one coming up. So the wifi icon was continually bouncing back and forth. My only solution was to go into airplane mode and bring the cellular down before bringing the wifi up. I don't think Android ever addressed this issue, and I had to switch around the entire subnet to avoid the conflicts.
If I knew enough about how Android worked, I'd write a patch to have all android interfaces in their own linux netns, with the dhcp client exec'd in that netns, that way you'd never have to worry about this sort of conflict.
One requirement of CGNAT, for instance, requires that the carrier's router be able to handle "address crashes". [1]
> In particular, Shared Address Space can only be used in Service Provider networks OR on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.
(edit: no, very clearly, "Devices MUST be capable of performing address translation when identical Shared Address Space ranges are used on two different interfaces." )
Also, is it wrong to assume that cellular networks are able to handle "address crashes" due to the inherent centralization that comes as a result of having clients maintain the same IP (and same connections) as the device hops from tower to tower? Maybe I don't understand the topics at play here...
The 1.0.0.0/8 range was owned by IANA from _1981_ up until 2010, when it was transfered to APNIC. (The 2.0.0.0/8 range was also owned by IANA until 2010, thentransfered to RIPE NCC).
If you want to get technical, use of the space could be construed as theft.
As for the continuity issue, it was stated that it was an old device, so they have no responsibility to continue supporting it, and considering the age of the device in question, it may not be able to connect to the existing network.
Reversing that would likely require AT&T to make a firewall change to literally every piece of equipment they operate, and that's assuming that they don't use the blocks internally. That, and I can guarantee that some customer, somewhere, would be using whatever IP they chose.
I'm eagerly awaiting your evidence for this statement, which to my knowledge is entirely incorrect.
So far's I know, existing uses of 1.1.1.1 have almost universally been illegitimate (e.g. captive portals, internal-ish services, …)
Otherwise, you can purchase a different device, preferably a Nexus/Pixel, or at least one that's unlocked. If that's impossible for you then, yes, you're stuck with AT&T's "best efforts."