...routed to the topologically nearest of several...
I think this is Vixie-specificism which just muddies the waters. To the best of my knowledge, nobody else tries to do this, or uses this terminology. I've never seen a reasoned argument that there was any reason to do this, nor heard that anyone else had considered doing it. I'm not sure it needs to be documented outside of ISC tech-notes, for ISC staffers who have to maintain it. Besides, any particular anycast node is, pretty much by definition, only visible to a subset of the whole routing system. So that's not a useful definition of something that's been purposely hamstrung. And you're missing "Anycast Instance." And if you're going to define "Service Address," you should probably define "Unique Address" as well, just for the sake of thoroughness.
Why do you care whether people do it at two or more discrete locations? It just needs to be two or more instances, to be anycast. Who cares where they're located?
The general rule is that protocols don't matter, but critical stateful transactions, like online banking sessions, should be handled by unique addresses when possible. And you may as well take the opportunity to debunk the fallacy about problems with TCP. I have no idea why there are still idiots, ten years later, who still think there's a problem, but the point of an RFC is to convey information to the clueless, so you might as well avail yourself of the chance.
Is this necessary? It doesn't have anything to do with anycast.
Again, this goes into excessive detail on a unique implementation, for which there's no evidence of desirability.
More specificity here wouldn't hurt. "Nodes' internal and connecting infrastructure should be scaled in accordance with the "be liberal in what you accept and conservative in what you send" principle. Specifically, the capacity of each node should be engineered with the expectation that traffic will spill over from other adjacent nodes which fail, are withdrawn, or are overrun by DDoS attacks. Likewise, nodes should be capable of absorbing potentially much larger volumes of traffic than they can actually serve, without unintentionally failing-over to adjacent nodes, and multiplying the burden which they're already carrying."
How so? In what case would the IGP override local routes within a node, and bring it down?
You might point out that many people run simple web servers on their anycast servers, which just serve a page with the name of the site on it, to facilitate the work of amateur diagnosticians.
That this isn't something to which anycast nodes are particularly vulnerable, and I'm not sure that it makes any sense to say that it's less likely to be noticed if it's done to them... It might also be worth pointing out that this is potential abuse of the technique. That is, the attack you're describing is, in fact, anycast. It's just rogue anycast, whether or not the address is otherwise anycasted. Otherwise, looks great. Nice work. -Bill |
PGP.sig
Description: This is a digitally signed message part
