Original text:
The lifetime of the socket is tied to the request stream.  The proxy MUST keep the socket open while the request stream is open.  If a proxy is notified by its operating system that its socket is no <del> longer usable, it MUST close the request stream.  Proxies MAY choose to close sockets due to a period of inactivity, but they MUST close the request stream when closing the socket.  Proxies that close sockets after a period of inactivity SHOULD NOT use a period lower than two minutes, see BEHAVE. </del>  A successful response (as defined in resp1 and resp23) indicates that the proxy has opened a socket to the requested target and is willing defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on DPLPMTUD.  In this scenario, the proxy SHOULD drop the UDP payload <del> and send an ICMP "Packet Too Big" message to the target ICMP6. </del>  6.2.

Reviewer comments:
With the CONNECT UDP, a proxy will send and receive UDP datagrams on behalf of a client. However, in addition to these UDP datagrams, it could also receive ICMP messages. The current draft does not discuss how these ICMP messages should be handled by a proxy and how they would need to be conveyed to the client. It probably makes sense to at least discuss how ICMP destination/network/port unreachable should be handled by the proxy (ignore, terminate the HTTP connection, ...)
I agree. I'm not yet sure what the best solution is (closing the stream on port unreachable would improve reliability but does introduce a way for an attacker to deny service) but we should figure that out and provide guidance in the doc.
FWIW, the way TURN handles this is by having a way for the server to forward ICMP indications. URL Obviously, in order to have this in MASQUE we would need to have some sort of type indicator in the datagram.
I do want the relevant information in the ICMP to make it to the client. However, ICMP falls into the asynchronous information that is not directly associated with a forwarded packet. It can clearly be a forwarded packet per EKR's suggestion. We have other cases where we have information that is related to the associated packet, for example ECN. So I think this there is an important high level design choice here that we need to sorted out. I think for the general extensibility lets consider a content identifier so that just UDP payloads can be separated from additional types with additional fields.

Revised text:
The lifetime of the socket is tied to the request stream.  The proxy MUST keep the socket open while the request stream is open.  If a proxy is notified by its operating system that its socket is no  <ins> longer usable (for example, this can happen when an ICMP "Destination Unreachable" message is received, see ICMP6), it MUST close the request stream.  Proxies MAY choose to close sockets due to a period of inactivity, but they MUST close the request stream when closing the socket.  Proxies that close sockets after a period of inactivity SHOULD NOT use a period lower than two minutes, see BEHAVE. </ins> A successful response (as defined in resp1 and resp23) indicates that the proxy has opened a socket to the requested target and is willing defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on DPLPMTUD.  In this scenario, the proxy SHOULD drop the UDP payload  <ins> and send an ICMP "Packet Too Big" message to the target, see ICMP6. </ins> 6.2.