Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transport: Client IP change reason #606

Closed
gloinul opened this issue Jun 7, 2017 · 2 comments
Closed

Transport: Client IP change reason #606

gloinul opened this issue Jun 7, 2017 · 2 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@gloinul
Copy link
Contributor

gloinul commented Jun 7, 2017

draft-ietf-transport-quic-03, section 7.6:

QUIC's consistent connection ID allows connections to survive changes
to the client's IP and/or port, such as those caused by client or
server migrating to a new network.

I don't understand how a sever network migration changes the client's IP address. Or is it intended to discuss forced changes to the IP/UDP 5-tuple to reach the server in general?

@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Jun 7, 2017
@martinthomson
Copy link
Member

We already have an open issue that is aimed at documenting the situations in which the connection ID helps, the limitations on that, and so forth (see #115).

As I understand it, the limitation of the proposal is that an endpoint can change its source address (IP or port) and then send and still have the packet arrive at the right destination. However, after moving, an endpoint won't be able to receive anything until it sends something. This is what makes simultaneous migration hard/impossible (see #490).

@gloinul, do you think that those two issues cover your concerns?

@gloinul
Copy link
Contributor Author

gloinul commented Jun 7, 2017

Yes, I think the clarification of those two issues, will results in the text being addressed. So, yes we can close this one.

@gloinul gloinul closed this as completed Jun 7, 2017
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Development

No branches or pull requests

3 participants