The QUIC and TLS drafts were written together, and are quite similar as you note. The intention is to use the TLS extension over TLS/TCP connections, and the QUIC extension for QUIC/UDP.
I agree that QUIC as a protocol benefits more from the extension than TLS does, but applications on top of both can benefit by detecting NATs, for making decisions about long-lived connections and privacy mitigations. Thanks, Tommy > On Mar 20, 2019, at 2:26 AM, Martin Thomson <[email protected]> wrote: > > I see a substantially similar draft in draft-pauly-quic-address-extension. > I'd like to understand how these might be complementary, or whether the idea > is to pursue only one. The QUIC extension seems superior, if you have QUIC. > There are a lot more plausible reasons to want this information in QUIC > though. > > Nits: > > The format of the extension is not ideal. Wouldn't you want to know which > family it came from? I think the intention was to use the length to infer the family. > > The term of art is reflexive address (or reflected address). Thanks, good to know! > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
