I've been writing up an implementation of migration in neqo. It's non-trivial work, but I decided that I would add preferred addresses and use that to test it.
Almost every implementation I've tested had the same bug. I'm still not sure about quant, but it seems likely that it is failing in the same way, so it's almost a clean sweep. If the client chooses a zero-length connection ID, it won't/can't send NEW_CONNECTION_ID. Thus, when the server attempts to make a new "path" to respond to the PATH_CHALLENGE that it received at its preferred address, all implementations are failing because they cannot assign a connection ID to that path. This caused connection errors in one cases, but mostly it just resulted in the preferred address not responding. So it's probably worth noting: if the peer chooses a zero-length connection ID, that doesn't count as one connection ID, it's infinite. You can always get another connection ID in that case. This likely applies to migration in general. One thing that is hard to determine from my testing is that no implementations (other than my own) seems to send probes on the old path after the client migrates to the preferred address. This is probably OK, because my address isn't changing, or at least the port is the only change. However, it's not clear that we have reliable implementations of that anti-DoS measure. Other than that, migration seems to work well. Implementations respond to probes without migrating and migrate properly when the client starts actively using a new path. I'm also seeing some implementation of the new path validation requirements already, which is good.
