[追記] yuyarin さんが詳しい考察を書いて頂きました！
とても詳しく書かれているので参考になります！ありがとうございます
yuyarin.hatenablog.com
IETFにおいて、QUICやHTTP/3の実装が利用を避けるべき送信元ポートについて議論になりました (URL)
具体的には、下記の送信元ポートは利用を避けるべきと述べられている。
これらのポートはUDPのリフレクション攻撃 (アンプ攻撃) に利用されるポートです。リフレクション攻撃のターゲットとなるサーバ側としては、これらのポートが送信元ポートに設定されたトラフィックを大量に受け付けることになります。
そのため、一部のインフラ環境ではこれらの送信元ポートをブロックするように設定されているかもしれません。
QUICやHTTP/3もUDPを使用します。運悪く送信元ポートとしてこれらのポートを使ってしまうと、通信がブロックされてしまうかもしれません。その結果としてタイムアウトまで待ちを発生させたり、HTTP/2へのフォールバックを引き起こしたりします。
利用されうる送信元ポート (エフェメラルポート)
正規利用のユーザは送信元ポートとしてこれらの値を使いうるのでしょうか。
一般的にアプリケーションは送信元ポートとして、エフェメラルポートを使用します。どうやら、IANAで"DYNAMIC AND/OR PRIVATE PORTS"として定義される49152～65535がエフェメラルポートとして使用されるようです。（Linuxでは32768～60999らしい）
エフェメラルポートとしてもっと小さい番号を設定している環境もあるにはあるようです。しかし、先に上げた避けるべきポートが使われる可能性は低いでしょう。
ただ、NATやCGNATでは1024~65535範囲が使われる可能性が示唆されています (RFC4787)
IETFの動向
QUICやHTTP/3では、これらの送信元ポートの利用を避けるようにという文言が加えられそうです。
github.com
また、避けるべきポート番号をRFCに直書きするのではなく、IANAで管理できないか意見が募られています。
mailarchive.ietf.org
まだ議論が行われている最中であり、今後何かしら進展があるものと思われる。
感想
（実際これらのポートが使われるケースどれくらいあるんだろう）
