add support for configuring and communicating preferred address

[kckeiks]

Hello, I have a wip PR for review for issue #828. This change allows users to configure the server's preferred address via Config. After the handshake, the preferred addresses can be accessed via the Connection.

• [X] implement encoding and decoding of params (PreferredAddressParams)
• [X] allow users to configure preferred address params viaConfig
• [X] allow clients to access the server's preferred address after the handshake
• [X] add/update unit tests
• [x] update TransportParams.to_qlog
• [X] ~allow clients to update the Connection's peer address with the preferred address~ #1223

I will add docs once I get some feedback about these changes.

[kckeiks]

allow clients to update the Connection's peer address with the preferred address

I'm not 100% sure of all the tasks to complete this part. I believe we should update Connection.peer_addr and optionally the connection ID (maybe add methods Connect.use_preferred_address_v4/v6?). I need to look at it more closely but would be great to get some guidance.

[ghedo]

@kckeiks Thanks for the PR!

I believe we should update Connection.peer_addr

Yes, but note that before sending packets to a new address the client needs to validate the path first, by sending a PATH_CHALLENGE frame (see https://datatracker.ietf.org/doc/html/rfc9000#section-9.6.2 ) and quiche currently doesn 't currently do this on its own since we don't support migration yet (it does support creating the frame, but some code will need to be added to verify the challenge response).

[kckeiks]

Yes, but note that before sending packets to a new address the client needs to validate the path first, by sending a PATH_CHALLENGE frame (see https://datatracker.ietf.org/doc/html/rfc9000#section-9.6.2 ) and quiche currently doesn 't currently do this on its own since we don't support migration yet (it does support creating the frame, but some code will need to be added to verify the challenge response).

Thanks for the info! I see that this enhancement has an issue and adding this feature is still TBD. Maybe I can think of some ideas and offer them for consideration to try to get these features moving along.

[tbu-]

#840 was now added by #1223, does that mean that this pull request is now unblocked?

[kckeiks]

#840 was now added by #1223, does that mean that this pull request is now unblocked?

Yes, it is. I will update this PR shortly today.

[kckeiks]

@ghedo I finished the pending tasks so this is ready for review. I'm not sure what the issue is with that one failing check. Maybe it needs a rerun?

[junhochoi]

I rerun the failed test. It looks like flaky

[LPardue]

The qlog specs recently changed to extract StatelessResetToken into its own type. The changes on https://github.com/cloudflare/quiche/pull/1294 should help avoid this PR needing to make some changes of its own.

[PSUdaemon]

@kckeiks Can you rebase this on the changes from #1294 please?