Change:
if clients send an empty Token field when the server address has changed from when the NEW_TOKEN frame was received. <del> Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN frame from one server address in an Initial packet that is sent to a different server address.  As strict equality might reduce the utility of this mechanism, clients MAY employ heuristics that result in different server addresses being treated as equivalent, such as treating addresses with a shared prefix of sufficient length as being functionally equivalent (for instance, /24 in IPv4 or /56 in IPv6). In addition, clients SHOULD treat a preferred address that is successfully validated as equivalent to the address on which the connection was made; see preferred-address. </del> <ins> Clients could avoid using NEW_TOKEN if the server address changes. However, not including a Token field could adversely affect performance.  Servers could rely on NEW_TOKEN to enable sending of data in excess of the three times limit on sending data; see validate-handshake.  In particular, this affects cases where clients use 0-RTT to request data from servers. </ins> Sending a Retry packet (packet-retry) offers a server the option to change the Token field.  After sending a Retry, the server can also

Discussion:
This is another judgment call, but as this wasn't a MUST in the first place, we weren't really preventing an attack. This just removes the recommendation to remove NEW_TOKEN tokens from Initial packets to new server addresses. It leaves the generic guidance, which is far more nuanced. I've added some commentary about the effect of withholding tokens on performance, as it seems like that is worth highlighting here. All in all, this leans more toward saying that request forgery is not the responsibility of QUIC deployments.
I'm merging this. If anyone thinks this ought to be dealt with differently, please say so on this PR or on the issue, and we can revisit.
Apologies for merging this PR. NAME NAME : we should still run through the process as a design issue.
PR adds a new normative restriction on when tokens received in NEWTOKEN can be used: "Therefore, clients SHOULD NOT send a token received in a NEWTOKEN frame from one server address in an Initial packet that is sent to a different server address. As strict equality might reduce the utility of this mechanism, clients MAY employ heuristics that result in different server addresses being treated as equivalent, such as treating addresses with a shared prefix of sufficient length as being functionally equivalent (for instance, /24 in IPv4 or /56 in IPv6). In addition, clients SHOULD treat a preferred address that is successfully validated as equivalent to the address on which the connection was made; see {{preferred-address}}." I believe this will greatly reduce the practical value of 0-RTT, since most responses cannot fit into 2 packets(assuming 1 to complete the handshake) and unless Anycast is used for load balancing, it's extremely common for the IPs not to match and quite common for them not to share a /24 or /56. From local testing, when I resolved URL twice in a row a second apart, I got 172.217.6.196 and 172.217.12.164. I can follow up with some numbers on how frequently this occurs today in existing deployments if that's useful? Also, from an editorial perspective, I also don't think this normative statement should only be in security considerations, since I believe it's more likely to be missed there.

On the email thread, I suggested changing the restriction to something like "MUST NOT use tokens from one RFC address space in a different one.", but NAME said that people setup vulnerable servers on public internet addresses. The key to SSRF is that one peer has a privilege that the other peer does not, but if it's a public address, couldn't either peer send traffic to the address without any clever use of another QUIC peer? Address spoofing isn't trivial, but it's certainly possible in some cases, so anyone only relying on peer IP address would already be vulnerable, so I'm not grasping how QUIC is making this worse for public IPs.
No guaranteed. I used to work at an office that had a firewall and a VPN. There were a bunch of unprotected server behind that firewall. Most, if not all, of those servers used addresses from public address space. This is likely not common practice any more (addresses are expensive), but it is also not completely unexpected. To give an example, one thing you might consider is that you have a subnet (x::/56 say) where servers all operate public addresses and operate services that are accessible on the public Internet. However, that network also has a bypass for authentication checks if the source address of a request is in the x::/56 subnet to enable cross-traffic between services without overheads. This might be consider acceptable if you also assume that ingress filtering is in use for the network. I need to stress again how much I think that this sort of thing is monumentally inadvisable. On the other hand, if we're looking for hypotheticals (in the absence of actual cases), then these are at least plausible cases to consider. That said, I definitely agree that this restriction is not great and it probably is too much. I don't know how to generate a heuristic that can capture a change of the magnitude you identify. Google is lucky to have addresses that are contiguous at ~/20; I imagine that other servers have to work with a larger spread. (BTW, I get 142.250.66.228) After considering this, if we are not going to implement more rigorous protections for other aspects of this (migration spoofing), then it seems reasonable to allow this reuse and accept the risk.

That means relying on the generic protections more for this case also, which already talk about moving from public space to link-local/site-local/private spaces. We might even just rely solely on those protections. (The editorial note is well-taken; we can fix that.)
Reopening so that we can get this into our processes.
Closing this now that WGLC has finished. was already merged.
One nit.Thanks NAME greatly appreciated.