Speaking in my role on the port experts review team:As QUIC is a general-purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC. For applications with a fallback to TCP that do not already have an alternate mapping to UDP, usually the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is appropriate. For example, the default port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. The above section glosses over two critical issues that should be addressed: 1. Whether QUIC should use port number assigned to an existing transport that does not currently assume QUIC 2. Whether / when QUIC designers should seek new port numbers Both issues come back to a key issue that this document does not yet address: although QUIC is a new “transport”, it does not use or have its own transport protocol code point. This is by design, i.e., QUIC could easily have been designed with as a true Internet transport layer, but instead leverages NAT traversal support and other benefits of existing transports. IMO, this section should be more clear and detailed on the consequence if this decision in the advice in this doc, e.g., IMO: - QUIC MUST use existing port assignments where they already exist - QUIC MUST differentiate between non-QUIC and QUIC use of that port, if preexisting non-QUIC assignment exists - the doc needs to address the cases where QUIC doesn’t have an assignment i.e., IMO, because QUIC isn’t a transport, it would not itself be eligible for a port assignment so again, it seems like applications for new ports need to be for “QUIC and non-QUIC use over UDP" (or TCP, or both) It wouldn’t hurt to also refer to RFC7605, notably its SHOULD for use of security and to be explicit about exceptions, if any. Joe —
Joe Touch, temporal epistemologist
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
