In reading https://datatracker.ietf.org/doc/draft-li-quic-nat-optimization I had many questions. A few of the questions are below.
Is the packet layout described in https://www.ietf.org/archive/id/draft-li-quic-nat-optimization-00.html#section-3.1 intended as a new IPv4 option number (to register in https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml)? The problem statement in the abstract and the introduction mentions which may cause NAT entries for long-lived QUIC connections to be prematurely aged and re-bound, resulting in changes to source ports. but such action is not a problem for QUIC because of QUIC's connection ID; QUIC was designed to be resilient in exactly that scenario where a NAT destroys a mapping and the client sends a packet (and earns itself a newly-mapped UDP port on the NAT). Rather, the problem for QUIC is that if the NAT times out a mapping, and then the *server* wants to send a packet to the client, that packet will (a) get dropped by the NAT because there is no active mapping or (b) get routed by the NAT to the incorrect client which will discard that errant packet. Further in that same section, Aging Time, The Aging Time field represents the aging time of each session. It is dynamically maintained by the service side, Does 'service side' mean the server (on the Internet) would send the (first? all?) QUIC packets with a new IP Option, which means it is honored by the ISP's CGN and/or the consumer's NAT? The document would benefit from a discussion of the DoS potential allowing clients and/or business relationship necessary for servers to choose their own NAT mapping timeout ("aging time") on a consumer's NAT and on an ISP's carrier grade NAT. -d
