Change:
6.2. <del> When a client receives a Version Negotiation packet, it MUST abandon the current connection attempt.  Version Negotiation packets are designed to allow future versions of QUIC to negotiate the version in use between endpoints.  Future versions of QUIC might change how implementations that support multiple versions of QUIC react to Version Negotiation packets when attempting to establish a connection using this version.  How to perform version negotiation is left as future work defined by future versions of QUIC.  In particular, that future work will need to ensure robustness against version downgrade attacks; see version-downgrade. </del> <ins> Version Negotiation packets are designed to allow future versions of QUIC to negotiate the version in use between endpoints.  Future versions of QUIC might change how implementations that support multiple versions of QUIC react to Version Negotiation packets when attempting to establish a connection using this version. A client that supports only this version of QUIC MUST abandon the current connection attempt if it receives a Version Negotiation packet, with the following two exceptions.  A client MUST discard any Version Negotiation packet if it has received and successfully processed any other packet, including an earlier Version Negotiation packet.  A client MUST discard a Version Negotiation packet that lists the QUIC version selected by the client. How to perform version negotiation is left as future work defined by future versions of QUIC.  In particular, that future work will ensure robustness against version downgrade attacks; see version-downgrade. </ins> 6.2.1.

Discussion:
The text was a little too broad. This breaks up the text and adds two caveats to handling rules: If you have handled another packet, then assume that everything is good. If you the VN includes QUIC v1, then assume that something got corrupted. The issue addresses the second, but I think we were implying the first for some time.
The "packet corruption" test that NAME added to the interop-runner has surfaced an issue about version number corruption. Suppose that a long header packet is corrupted in transit, and that the corruption changes the value of the version number. Per spec, the server will respond with a version number negotiation packet. In the test, we observe that when clients receive such packets, they abandon the connection attempt. Obviously, this is a rare event. We don't know how frequent packet corruption is today. The measured "1 packet in 5000". In theory, only one in 2^16 of these corruptions would not be detected by the UDP checksum, leading to undetected corruption in 1 in 300 million packets. That's a very small number, but I don't know whether the 1997 measurements are still valid. They could be higher. I also don't know whether the loss patterns would be detected by the UDP checksum, since some middleboxes appear to rewrite these checksums. Faced with exactly the same issue, we decided recently to add a checksum to the Retry packets. Clients can protect against such corruptions by checking the incoming VN packets for sanity. If the server issues a VN in response to a corrupted packet, the list of supported versions will include the version proposed by the client. That should normally never happen. Ignoring such bogus VN does protect against most version number correction issues. Should we point that out in the spec?
We used to require that a client ignore Version Negotiation packets that include the version the client attempted. NAME edited that out. Maybe we should restore it. That pushes the odds of failure to 1 in 90 quadrillion. Would that help? I want to say that this is a design issue.
The problem with the "one in 300 million" figure is that it relies on the UDP checksum. If you cannot trust the UDP checksum, the figure is "1 in 5000", which is more concerning.

And there are scenarios in which uncontrolled middle-boxes do rewrite that checksum.
I'd support restoring that check that NAME edited out. Anecdotally, we've found packet corruption to be very rare and basically a non-issue. Or maybe something in the network or the host is just dropping them, but we don't receive them in userspace.
I'm fine with adding this check back in. It's not onerous to implementers. This is a design issue.
Now if we were really paranoid, we would consider the possibility that the VN packet itself is corrupted.
I did. If we don't trust the UDP checksum on either, the error rates are still pretty high, but either checksum bumps it up to 1.5 trillion and both is 90 quadrillion.
I was thinking about that -- it doesn't need paranoia, it's just a question of how often -- and in this case the chances are vanishingly small.
To clarify the statement, that happened when we decided to move version negotiation to an extension. The states that - I'd be supportive of adding a sentence such as
I support the change. Does the general concern about security proofs that is driving us to authenticate the CIDs also apply to the version field?
NAME The security concerns do apply to the version field, our current plan to address that is .
NAME Thanks, but is it sufficient for this to be an extension? What if the base spec isn't provably secure?
NAME there's still time for us to make the use of that extension mandatory before we ship, but I'd suggest having that discussion on a separate issue.
Works for me.