Send Abandon frame after NAT rebinding #198
Conversation
This is the proposed text more the other PR to start working this. The proposed solution in further discussion was to also extend the path abandon path with a specific reason code of this case.
|
See issue #188 |
| and did not receive a RETIRED_CONNECTION_ID frame for the old CID yet, | ||
| it can send an PATH_ABANDON frame for that CID in order to indicate | ||
| that the "old" path is not usable anymore. | ||
|
|
There was a problem hiding this comment.
I am really not sure there. First, I think having side effects for PATH_CHALLENGE is a bad idea, as PATH_CHALLENGE is just a connectivity test. Second, I do not understand the mechanism. We understand that if a node only use heuristics, it will sometime fail to identify the old path. If it does identify it, it will send two path challenges per normal NAT rebinding guidance, only the one on the new path will succeeds, and everything will be fixed. But if it does not, it will only send a path challenge on the new path, to confirm continuity. Due to asymmetric knowledge, the peer sees only one path, so the challenge arrives on the existing path. There should be no other action than sending a path response.
|
Yes, this is not ready to merge and discuss should take place in the issue (#188). I just wanted to capture this text as a starting point before we lose it. |
|
I think we need clarity on PR #292 before we progress this draft. We have an issue there, because the "Natted" path and the "before-NAT" path use the same number space. With PR #292, that gives us a strong constraint. I think I explained a plausible solution in #292 (comment), but with that solution if rebinding is accepted the new (natted) path will have the same path_id as before NAT rebinding. |
|
OBE after merge of #292 |
This is the proposed text more the other PR to start working this. The proposed solution in further discussion was to also extend the path abandon path with a specific reason code of this case.