Re: [quicwg/base-drafts] QUIC connection migration and IPv6 only NAT64/DNS64 Networks (#2122)

[plakhera <[e-mail]>]

> I think we can get the low-hanging fruit here by having alternate_address_v4 and alternate_address_v6 transport parameters. 

+1. Just that bit by itself (either having two new TPs alternate_address_v4 or  alternate_address_v6 or splitting preferred_address to _v4 and v6) would help in most cases.

> That said, I'm not convinced of how important this is to solve in v1. This affects only migrations, and then only those that are from networks on one address family to a different one.

It is increasingly becoming common for cellular carriers to deploy IPv6 only NAT64/DNS64 networks, even in countries where ISPs have stayed IPv4 only on the CPE, mostly because of differences in how connectivity is achieved in two scenarios and the use-cases.
It won't be far fetched to think that this disparity would be widened by end of next year.

The current limitation introduces legitimate concerns of deploying dual stack configuration for services that still desire transport protocol level connection migration support.

Also we should probably try our best to have version one be address family agnostic. The fact that there is only one preferred_address family parameter doesn't help.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2122#issuecomment-446862799