expected to be relevant for a closed connection.  Retransmitting the final packet requires less state. <del> New packets from unverified addresses could be used to create an amplification attack; see address-validation.  To avoid this, endpoints MUST either limit transmission of CONNECTION_CLOSE frames to validated addresses or drop packets without response if the response would be more than three times larger than the received packet. After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state.  An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets, which could result in a constant exchange of CONNECTION_CLOSE frames until the closing period on either peer ended. </del> <ins> While in the closing state, an endpoint could receive packets from a new source address, possibly indicating a connection migration; see migration.  An endpoint in the closing state MUST either discard packets received from an unvalidated address or limit the cumulative size of packets it sends to an unvalidated address to three times the size of packets it receives from that address. </ins> <del> An immediate close can be used after an application protocol has arranged to close a connection.  This might be after the application protocols negotiates a graceful shutdown.  The application protocol exchanges whatever messages that are needed to cause both endpoints to agree to close the connection, after which the application requests that the connection be closed.  When the application closes the connection, a CONNECTION_CLOSE frame with an appropriate error code will be used to signal closure. 10.2.1. </del> <ins> An endpoint is not expected to handle key updates when it is closing (Section 6 of QUIC-TLS).  A key update might prevent the endpoint from moving from the closing state to the draining state, as the endpoint will not be able to process subsequently received packets, but it otherwise has no impact. 10.2.2. The draining state is entered once an endpoint receives a CONNECTION_CLOSE frame, which indicates that its peer is closing or draining.  While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets.  Retaining packet protection keys is unnecessary once a connection is in the draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets.  Doing so could result in a constant exchange of CONNECTION_CLOSE frames until one of the endpoints exits the closing state. An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is also closing or draining.  In this case, the draining state SHOULD end when the closing state would have ended.  In other words, the endpoint uses the same end time, but ceases transmission of any packets on this connection. 10.2.3. </ins> When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame.  Generally, this means sending the frame in a