5. <del> IP packets are encoded using HTTP Datagrams HTTP-DGRAM with the IP_PACKET HTTP Datagram Format Type (see value in iana-format-type). When using the IP_PACKET HTTP Datagram Format Type, full IP packets (from the IP Version field until the last byte of the IP Payload) are sent unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram. In order to use HTTP Datagrams, the client will first decide whether or not it will attempt to use HTTP Datagram Contexts and then register its context ID (or lack thereof) using the corresponding registration capsule, see HTTP-DGRAM. When sending a registration capsule using the "Datagram Format Type" set to IP_PACKET, the "Datagram Format Additional Data" field SHALL be empty.  Servers MUST NOT register contexts using the IP_PACKET HTTP Datagram Format Type.  Clients MUST NOT register more than one context using the IP_PACKET HTTP Datagram Format Type.  Endpoints MUST NOT close contexts using the IP_PACKET HTTP Datagram Format Type.  If an endpoint detects a violation of any of these requirements, it MUST abort the stream. </del> <ins> This protocol allows future extensions to exchange HTTP Datagrams which carry different semantics from IP packets.  For example, an extension could define a way to send compressed IP header fields.  In order to allow for this extensibility, all HTTP Datagrams associated with IP proxying request streams start with a context ID, see payload-format. Context IDs are 62-bit integers (0 to 2 -1).  Context IDs are encoded as variable-length integers, see Section 16 of QUIC.  The context ID value of 0 is reserved for IP packets, while non-zero values are dynamically allocated: non-zero even-numbered context IDs are client-allocated, and odd-numbered context IDs are server-allocated.  The context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be simultaneously assigned different semantics in distinct requests, potentially with different semantics.  Context IDs MUST NOT be re-allocated within a given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. Registration is the action by which an endpoint informs its peer of the semantics and format of a given context ID.  This document does not define how registration occurs.  Depending on the method being used, it is possible for datagrams to be received with Context IDs which have not yet been registered, for instance due to reordering of the datagram and the registration packets during transmission. 6. When associated with IP proxying request streams, the HTTP Datagram Payload field of HTTP Datagrams (see HTTP-DGRAM) has the format defined in dgram-format.  Note that when HTTP Datagrams are encoded using QUIC DATAGRAM frames, the Context ID field defined below directly follows the Quarter Stream ID field which is at the start of the QUIC DATAGRAM frame payload: A variable-length integer that contains the value of the Context ID.  If an HTTP/3 datagram which carries an unknown Context ID is received, the receiver SHALL either drop that datagram silently or buffer it temporarily (on the order of a round trip) while awaiting the registration of the corresponding Context ID. The payload of the datagram, whose semantics depend on value of the previous field.  Note that this field can be empty. IP packets are encoded using HTTP Datagrams with the Context ID set to zero.  When the Context ID is set to zero, the Payload field contains a full IP packet (from the IP Version field until the last byte of the IP Payload). </ins> Clients MAY optimistically start sending proxied IP packets before receiving the response to its IP proxying request, noting however