Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?

[Phillip Hallam-Baker <[e-mail]>]

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.