Bugzilla

Idea how to test this:

We somehow need to trick the client into believing that its local interface changed. I assume that we don't have any test tooling, allowing us to change client interfaces. If I am wrong, i.e. we do, let's use that, not the hack I am proposing below.

If I understand correctly we don't leverage `IPV6_V6ONLY` socket option anywhere. In other words, all our IPv6 sockets are dualstack sockets, i.e. accept both incoming v4 and v6 packets.

1. Have Firefox connect to an IPv6 HTTP3 server, e.g. `[::1]:8080`. Given the above assumption of Firefox not doing `IPV6_ONLY`, this will result in Firefox binding to a dualstack (v4 & v6) socket. See [socket instantiation in `HttpConnectionUDP.cpp`](https://searchfox.org/mozilla-central/rev/3966e5534ddf922b186af4777051d579fd052bad/netwerk/protocol/http/HttpConnectionUDP.cpp#96-105). Common behavior across OSs is to bind to the same port, e.g. Firefox will have the local address `[::1]:12345` and `127.0.0.1:12345`.
2. Wait till the connection is fully established.
3. Fake the client going from a v4&v6 network to a v4 network. This can be done on the server side, no changes to Firefox needed. On the server side, [when reading a datagram](https://github.com/mozilla/neqo/blob/a4c4ccd8aa705e3ee52410e9e0a4e072a963a739/neqo-bin/src/server/mod.rs#L291-L298), simply replace the source address (i.e. the Firefox address) from `[::1]:12345` to `127.0.0.1:12345`. The server will automatically respond to the v4 client address, i.e. `127.0.0.1:12345`. See [sample unit test](https://github.com/mozilla/neqo/blob/main/neqo-transport/src/connection/tests/migration.rs#L69-L86), using ports instead of addresses.
4. Wait till client and server finish the migration, by validating that the client can still send and receive data from the server and does not throw [`TransportError::InvalidMigration`](https://searchfox.org/mozilla-central/rev/3966e5534ddf922b186af4777051d579fd052bad/netwerk/socket/neqo_glue/src/lib.rs#1007).

Idea for an automated test:

We somehow need to trick the client into believing that its local interface changed. I assume that we don't have any test tooling, allowing us to change client interfaces. If I am wrong, i.e. we do, let's use that, not the hack I am proposing below.

If I understand correctly we don't leverage `IPV6_V6ONLY` socket option anywhere. In other words, all our IPv6 sockets are dualstack sockets, i.e. accept both incoming v4 and v6 packets.

1. Have Firefox connect to an IPv6 HTTP3 server, e.g. `[::1]:8080`. Given the above assumption of Firefox not doing `IPV6_ONLY`, this will result in Firefox binding to a dualstack (v4 & v6) socket. See [socket instantiation in `HttpConnectionUDP.cpp`](https://searchfox.org/mozilla-central/rev/3966e5534ddf922b186af4777051d579fd052bad/netwerk/protocol/http/HttpConnectionUDP.cpp#96-105). Common behavior across OSs is to bind to the same port, e.g. Firefox will have the local address `[::1]:12345` and `127.0.0.1:12345`.
2. Wait till the connection is fully established.
3. Fake the client going from a v4&v6 network to a v4 network. This can be done on the server side, no changes to Firefox needed. On the server side, [when reading a datagram](https://github.com/mozilla/neqo/blob/a4c4ccd8aa705e3ee52410e9e0a4e072a963a739/neqo-bin/src/server/mod.rs#L291-L298), simply replace the source address (i.e. the Firefox address) from `[::1]:12345` to `127.0.0.1:12345`. The server will automatically respond to the v4 client address, i.e. `127.0.0.1:12345`. See [sample unit test](https://github.com/mozilla/neqo/blob/main/neqo-transport/src/connection/tests/migration.rs#L69-L86), using ports instead of addresses.
4. Wait till client and server finish the migration, by validating that the client can still send and receive data from the server and does not throw [`TransportError::InvalidMigration`](https://searchfox.org/mozilla-central/rev/3966e5534ddf922b186af4777051d579fd052bad/netwerk/socket/neqo_glue/src/lib.rs#1007).