Code change:
an HTTP Datagram.  This prevents infinite loops in the presence of routing loops, and matches the choices in IPsec IPSEC. <ins> IPv6 requires that every link have an MTU of at least 1280 bytes IPv6.  Since CONNECT-IP conveys IP packets in HTTP Datagrams and those can in turn be sent in QUIC DATAGRAM frames which cannot be fragmented DGRAM, the MTU of a CONNECT-IP link can be limited by the MTU of the QUIC connection that CONNECT-IP is operating over.  This can lead to situations where the IPv6 minimum link MTU is violated. CONNECT-IP endpoints that support IPv6 MUST ensure that the CONNECT- IP tunnel link MTU is at least 1280 (i.e., that they can send HTTP Datagrams with payloads of at least 1280 bytes).  This can be accomplished using various techniques: if HTTP intermediaries are not in use, both CONNECT-IP endpoints can pad the QUIC INITIAL packets of the underlying QUIC connection that CONNECT-IP is running over. if HTTP intermediaries are in use, CONNECT-IP endpoints can enter in an out of band agreement with the intermediaries to ensure that endpoints and intermediaries pad QUIC INITIAL packets. CONNECT-IP endpoints can also send ICMPv6 echo requests with 1232 bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out of band means of guaranteeing that one of the two previous techniques is sufficient, they MUST use this method. </ins> Endpoints MAY implement additional filtering policies on the IP packets they forward.

Related discussion:
text: Per IPv6 RFC that requires us to support 1280 at least. What have been the rough consensus so far is that we are not defining an fragmentation and reassembly mechanism, or rather how to ensure that one uses QUIC streams when the transport is HTTP/3 for below 1280 IPv6 packets and instead reject the service. Thus we are in the position of having to answer how does one know when to reject the service. The alternatives I see are: 1) Force the Connect-IP endpoints to ICMP ping each other to verify that the path supports 1280 IPv6 packets 2) Have the HTTP intermediaries be Connect-IP aware to the level that they can reject the HTTP request if the path does not support 1280 packets. Where 2) have the downside that we still likely have some black holes in cases where the HTTP intermediaries are not connect-IP aware and ignores the requirements. Where 1) have the downside that the endpoints request can't be rejected during the request response sequence and instead have to be closed with an error message indicating the paths failure to support the packet.
I'm opposed to requiring ICMP pings because the majority of use-cases will not have this problem. How about we add text like this: CONNECT-IP endpoints that enable IPv6 connectivity in the tunnel MUST ensure that the tunnel MTU is at least 1280 bytes to meet the IPv6 minimum required MTU. This can be accomplished multiple different ways, including: Endpoints padding QUIC initial packets when it is known that there are no intermediaries present Endpoints sending ICMPv6 echo requests with 1232 bytes of data an out of band agreement between one of the endpoints and any involved intermediaries to have them pad QUIC initial packets
So I understand your desire to not add complexity anywhere for a likely seldom arising case. However, I do fear that not addressing this with a clear assignment on whose responsibility it is to avoid the issue will result in that none does anything of it. Because an endpoint that uses HTTP/3 can verify its first hop. However, the complexities arise when you have HTTP intermediaries in the mix.