Draft: draft-ietf-quic-applicability

Commentary: hopefully addresses issue 
 I do n't think " the same port number as would be used for the same application over TCP " is necessary general - purpose guidance . I would argue for something more like : 
 Copying from There 's no requirement that servers use a particular UDP port for HTTP / QUIC or any other QUIC traffic . Using    , the server is able to pick and advertise any port number and a compliant client will handle it just fine . That 's already the case , and is n't part of this issue . updates the HTTP draft to highlight this , increasing the odds that implementations will test and support that case . This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically ( though that requires coordination with their    advertisements and lifetimes , which could be challenging ) in order to make it more difficult for a network observer to classify traffic ( and therefore more difficult to ossify ) . On the other hand , as we 're wrestling with in each of these privacy / manageability debates , removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly , which could result in even worse ossification . ( E.g. indexing into the TLS ClientHello to find the ALPN list , then panicking on a different handshake protocol . ) There 's further discussion on the original issue , but this belongs in the ops drafts , not the protocol drafts . 
 this kind - of - but - not - really - duplicates , which I 'll go ahead and close . 
 Actually , it 's an exact duplicate , given that it points to the same issue . ;-) My bad . 
 can you check if PR addresses this issue sufficiently ? At least for the applicability doc ... 
 Now also PR for the manageability statement . 
 and are a ( ready for -03 ) treatment of this ; however , we should consider if we want to say more , e.g. such as general guidance / recommendations for using ALPN in QUIC mappings , for instance ? Keeping this open to track . 
 created new issue for ALPN
Paragraph (version B):
As QUIC is a general purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC in
general.  Instead, the same port number is used as would be used for
the same application over TCP.  In the case of HTTP the expectation
is that port 443 is used, which has already been registered for "http
protocol over TLS/SSL".  However, QUIC-HTTP also specifies the use of
Alt-Svc for HTTP/QUIC discovery which allows the server to use and
announce a different port number.
Paragraph (version B):
In general, port numbers serves two purposes: "first, they provide a
demultiplexing identifier to differentiate transport sessions between
the same pair of endpoints, and second, they may also identify the
application protocol and associated service to which processes
connect" RFC6335.  Note that the assumption that an application can
be identified in the network based on the port number is less true
today, due to encapsulation, mechanisms for dynamic port assignments
as well as NATs.
Paragraph (version B):
However, whenever a non-standard port is used which does not enable
easy mapping to a registered service name, this can lead to blocking
by network elements such as firewalls that rely on the port number as
a first order of filtering.