Draft: draft-ietf-quic-transport

Commentary: Addresses . I 'm flexible on wording and where exactly it lives in the document . I put it in Security Considerations . 
 I just completely rearranged the new section based on your input . See how it reads now . Editors , I do n't seem to have permission to request review . Can someone add 
 Unfortunately , some of the reviews are hidden as obsolete . I want to respond to this by about disablemigration I tried to not recommend anything here except to send disablemigration . The client is going to decide what to do with regard to NAT rebinding . If wired , I probably send more PINGs or something . If wireless , maybe not . If I 'm quite sure I 'm not behind a NAT , I probably do nothing . There 's nothing normative here but to send the TP , so if people hate this I can just delete the explanation . 
 I moved the whole thing to Section 5 as suggested . I 've taken most of the other suggestions , but am not sure if the intro needs to change , or what exactly people do n't like about the disable_migration explanatory text . 
 I 'm actually fine with this . We were considering keep alives on the server side when we ca n't support migration ( or NAT rebinding ) based on the current infrastructure . So having the spec suggest keep alives to the client would be better . It would allow the client to choose if it would prefer keep alives or just to close the connection . 
 After taking all suggestions from I simply deleted the explanatory text about sending disablemigration . I did n't see the stuff about NAT rebinding as prescriptive or changing the semantics , but it 's non - normative , clients are gon na do what they gon na do , and it 's not worth holding up the rest of this over . If people want to add NAT rebinding considerations to disablemigration we can fight that out in another issue . 
 FWIW , we have a number of cases when the destination IP and port + CID would route correctly , but the original IP(being anycast ) would not always route correctly . It 's likely there are millions of connections to the destination IP being migrated to , but yes it 's a smaller number than the anycast IP . 
 So do you want new or revised language here , or will the other issue address the linkability stuff ? I would like to close this out if it 's good enough . 
 Given how hard this has been to get right , I want to take a look . But I 'm happy with this . 
 A reminder for to either take a look or say that this is OK to proceed without another review . 
 I could not stand leaving this unmerged any longer . Anyone with more comments can make a new PR . Thanks to everyone who helped out here . 
 The transport draft talks about QUIC being resilient to NAT rebindings . However , if a QUIC server is behind an L3 load balancer which simply routes based on 5 - tuple , then connections to this server will ( likely ) not survive rebinding . I could n't find any language which addressed whether such a deployment was " OK " or not . I think that since this load balance does not support NAT binding resilience , it is implicitly " bad " according to the draft , but others might disagree . In any case , I think there should be text to address this . Note , if the server advertised a preferredaddress which routed around the load balancer , and if clients were required to use this address , then that could obviously work . But preferredaddress support is a SHOULD , not a MUST . 
 We did discuss this issue . Use of empty connection IDs and demultiplexing based on source addresses . The conclusion there was that this was OK : people could do that , as long as it was clear that what they were getting was not different than TCP . That is , we made it clear that if you do n't use the identifiers that you control ( your addresses , the connection ID ) , then you accept that you ca n't handle migration at all and connections will drop ( well , unless you do something like trial decryption , which has some obvious scaling issues ) . The outcome of that discussion was captured in . Assuming that  finds this answer satisfactory ( and I have n't missed anything ) , then I suggest we just close this as a duplicate of . 
 I do n't think this captures Ryan 's concern : when the server is using a non - zero CID and also is behind 4 - tuple routing . I think he 's looking for a section of text to coherently describe what you have to do here : send either disablemigration or preferredaddress ; or forward packets between servers ; or either do n't use a common stateless_reset key , or put client address / port in the reset token . This is sort of ops - drafty but there real requirements on servers to behave in a secure way . I think someone with full command of the transport draft would figure this out , but it is not clearly stated anywhere . 
 I agree with   and the language he suggests makes sense to me . 
 This does feel a bit ops - drafty to me , but I 'd be happy to review a PR . 
 I 'm sure that this is now basically unrecognizable ... Some more suggestions , but overall this LG
Paragraph (version B):
If servers can use other dedicated server IP addresses or ports
than the one that the client initially connects to, they could use
the preferred_address transport parameter to request that clients
move connections to these dedicated addresses.  Note that clients
could choose not to use the preferred address.