Server's Preferred Address

[Mike Bishop <[e-mail]>]

As we walk along the spectrum from fixed 4-tuple for the life of a connection to full multipath, #560 requested a solution to the problem of Anycast IP addresses.  There are some large server deployments where the front-end addresses are Anycast-based.  However, for a connection-oriented protocol, you want to be "sticky" to the server endpoint that you did the handshake with.  Currently, that's addressed with some amount of re-forwarding internally and some amount of tolerated connection breakage.  This gets more painful if we support connection migration, as the same Anycast address likely hits a different server from your new IP address.

PR#1251 builds on the path verification approach to enable servers to hand off to a unicast IP address if desired.  It adds a transport parameter in which the server supplies:

  *   IP version
  *   IP address
  *   UDP port
  *   Connection ID (possibly empty)
  *   Stateless Reset Token

At the end of the handshake, the client SHOULD perform path validation on the supplied address; if it succeeds, it transitions to the new address.  If it fails, it just stays on the original (presumably Anycast) address and takes the risk that the connection will fail when routing changes.  (The SHOULD is a matter of some contention - servers want to be able to rely on this, but can't actually tell whether the client's path validation failed or was never attempted.)

It's important to note that this isn't full server migration - it's a step in that direction, but this is scoped strictly to the server making one change attempt to an address it provides at a specified time.  However, this isn't something that has seen broad discussion, so I wanted to raise it for the WG's consideration.

(If we want to tackle server migration, I think the next piece would be a frame that carries essentially the same information, requesting the client to make a probe attempt.  This helps deal with NATs by making clients speak first, but it assumes that the server always maintains control of both addresses during a transition.  To support full P2P, where both sides could be make-after-break, you basically need something like ICE.)