Servers can't migrate. Period.

[martinthomson]

This was a bit weak in the past, but it is part of our defense strategy for attacks on migration and rebinding. Not that this totally prevents attack, but it means that an attacker looking to force a migration has to observe and race packets sent by both endpoints if this is true.

[marten-seemann]

I'm not happy with the fact that servers can't migrate in general, but this change makes the current state clearer and more consistent.

[martinthomson]

Yes. I am similarly unhappy, but the task to properly define migration for both clients and servers ultimately ends up with something as complex as ICE. We don't want to repeat that mistake. ICE started small, then turned into an RFC that was so large and complex people were scared of it.

[mikkelfj]

I also dislike this asymmetry but the primary case for client server symmetry is in mostly static P2P server networks.

However, if two voice chat users connect via QUIC using NAT hole punching, this becomes difficult to manage without migration. But I see @martinthomson's point on ICE. How can QUIC realistically handle this use case, because I think it has to, in some version at least.

[MikeBishop]

I think a general P2P use of QUIC uses ICE directly to find the peer addresses, then uses a broader definition of "address" when doing migration within QUIC. A draft that described the interaction between the two of them would be welcome, but it doesn't need to be in the core transport spec.

[mikkelfj]

@MikeBishop but even if punching via ICE, both endpoints could be travelling (like moving from train wifi to station wifi). I like the idea of fixing the server from an attack perspective, but I'm afraid it is too restrictive.

[MikeBishop]

@mikkelfj, that's not a barrier. IIUC, ICE should track those changes of IP address. What I'm suggesting is that P2P would delegate all the address management to ICE, and consider the endpoints that ICE provides it as being the same "address". From P2P QUIC's standpoint, no one ever changes address.

[mikkelfj]

I'm not up to speed on all the punc techs, but my impression is that you often want to end up in a situation where there is no middle man involved after the initial connection is established. Any local NAT boxes would have been punched. I'm not sure this is possible with just QUIC, but some driver logic should be able to provide an IP/port combo to the other end. But this is for stationary NAT.

You can also imagine an intial rendezvous service that is not necessarily punching NAT but rather provides a location service. Once you connect using driver logic, the IP/port is handed to QUIC, and then migration becomes an issue because there is only the endpoints to track the migrations. This is the two traveller scenario as opposed to domestic Skype or Bittorrent.

[erickinnear]

I agree with @marten-seemann (and others above): I'd prefer if we could have more symmetry in this area and would be interested in exploring that later, but I also see why it's necessary to stick with this for v1.

[janaiyengar]

What @MikeBishop said. I would expect ICE to be used alongside QUIC for P2P signaling, and ICE implementations expose encapsulations as interfaces to stacks, so QUIC will largely be out of the loop when it comes to migration and such. I think it is a larger project to figure out if ICE and QUIC can be combined in some interesting way to make P2P better.