| (I'm not pushing this idea to the max, I mean, now IPv6 is here so we'll just go with it, but this is for the mental and engineering exercise). To answer your question, in my model, the legacy IPv4 field contains the IP addresses of "IPv4 to IPv4 Extended bridges". Let's imagine you want to connect to [example.com]: Clients who speak IPv4 Extended and their ISP is compatible, get the IPv4 Extended answer: 425.223.231.123 A+ example.com and directly to it Clients who speak IPv4 Extended but don't have an IPv4 Extended compatible ISP, add that extra IPv4 Extended header and speak to the bridges. 425.223.231.123 A+ example.com 34.23.12.2 BR example.com (the bridge) Clients who speak IPv4 only but don't speak IPv4 Extended don't have to think about IPv4 Extended at all, since they will go through the usual layer-7 (typically HTTP) reverse-proxy, or a routing based on rules (ip/port pair). Cloudflare does search large scale reverse proxies, it works fine in practice. If someone has an incentive to run such bridges or reverse proxies solution, first it's yourself, to save your preciouses IPv4. To the end user the promise is "you will connect faster to the internet if you are in native IPv4 Extended (because you skip these intermediate bridges)" We actually have a nice mechanism that we could reuse for knowing which bridges to use, it's reverse DNS lookup. https://www.cloudflare.com/learning/dns/glossary/reverse-dns... In reality this intermediate state with the bridge, is not even necessary, so the migration could be even easier. |