Send a Retry packet if the ClientHello spans more than one packet.

[camshaft]

From https://tools.ietf.org/html/draft-ietf-quic-tls-32#section-4.3:

The first Initial packet from a client contains the start or all of its first cryptographic handshake message, which for TLS is the ClientHello. Servers might need to parse the entire ClientHello (e.g., to access extensions such as Server Name Identification (SNI) or Application Layer Protocol Negotiation (ALPN)) in order to decide whether to accept the new incoming QUIC connection. If the ClientHello spans multiple Initial packets, such servers would need to buffer the first received fragments, which could consume excessive resources if the client's address has not yet been validated. To avoid this, servers MAY use the Retry feature (see Section 8.1 of [QUIC-TRANSPORT]) to only buffer partial ClientHello messages from clients with a validated address.

[rday]

Would the subsequent ClientHello be required to span multiple packets as well? There is a use of MAY in the spec, but I wanted to call this out since it is a totally different section of the RFC:

From https://tools.ietf.org/html/draft-ietf-quic-transport-32#section-17.2.5.3:

A client MUST use the same cryptographic handshake message it included in this packet. A server MAY treat a packet that contains a different cryptographic handshake message as a connection error or discard it. [...] A client MUST NOT change the cryptographic handshake message it sends in response to receiving a Retry.