Paul Wouters writes: > On Tue, 22 Mar 2022, Tero Kivinen wrote: > > > So having few words here for mobike case would be useful too. > > Especially pointing out that this is not specific to the TCP > > encapsulation, this is generic thing that is done when using mobike > > regardless whether you use TCP or not.. > > There was some talk from I think Antony and Valery that we should have > a clarification document on some MSGID issues that is a superset of the > TCP problems.
The mobike is written in such way that it uses the latest IKEv2 message as a probe and uses that latest message to find the working connection between devices. This just so that we can use the normal message id properties, i.e., every single request has unique message id (along with initiator flag) and has singe response and if there are retransmissions those requests and responses are all bitwise identical. So mebike will retransmit its latest IKEv2 request over different paths, even when it knows the information there might already be stale, as the for example the IP adress might have changed in address update. When it finds a working path, it will immediately restart address update to make update the other end with proper latest information. I have no idea what message id issues you are referencing to... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
