We have people vigorously asserting that Linux broke IPv6 TCP over Anycast five years ago and this is serious.
And We have people vigorously asserting that TCP over Anycast works absolutely perfectly and there are no issues.
And they are the same people. It cannot work and not work at the same time.
As a user, I find that a lot of the commercial systems I end up having to use are considerably less reliable than they should be. Running a real time trading desktop over a 1Gbs pipe to a big name brokerage is not 100% reliable which is rather surprising.
What I am objecting to here is the assumption that people can make use of some undocumented feature that was never guaranteed to work and then insist that the rest of the Internet maintain that feature in perpetuity. Nope, does not work that way because however important your application is to YOU, it is almost certainly not important to ME.
The core assumption of the Internet is that the narrow waist is an unreliable transport which makes no guarantees. That is why TCP exists in the first place.
Like BitCoin, deployment of TCP turns out to be immutable. Whatever clever features people might think they can add, they cannot because TCP is a platform feature and requires deep operating system voodoo to change.
So if you want your applications to work, you need to think about moving away from TCP to a modern transport over UDP that takes account of the additional capabilities and features of the network as deployed.
I would not design a DDoS resistant transport over IPv6 the same way as over IPv4. What a waste! With 128 bits of addressing, why on earth give everyone the same target IP address at the discovery layer??? Of course I am going to be mixing it up.
What this discussion is doing that is useful is surfacing some of the operational assumptions that are not supported in the infrastructure but relied on by real installations. We will never have an exhaustive set of such assumptions.
At the end of the day, there are two operational arguments that invariably turn out to be false:
1) This change I am proposing to the infrastructure is so important it MUST be deployed.
2) This feature I rely on is so important it MUST NOT ever change.
What is really strange is that these arguments seem to be the ones most commonly made in BOFs and WG kickoffs. We have 30 years of experience telling us that both are false but they still come up, over and over again.
Making a protocol dependent on deployment of a new DNS record is a really good way to make sure it will never see deployment and I speak as the author of the only new DNS record to be successfully deployed since SRV (nope, TLSA still not in C-Panel, most people can't use it, take a look at the business model and you will see why that isn't happening). Making a protocol dependent on TCP fast start was another wrecking choice. The list goes on.
An internetwork is not the same thing as a network. tThe IETF is not the administrator of the internetwork because the distinctive feature of an Internetwork is that there is no administrator.
