Re: Issue 59: Editorial comments from Tero (was: Comments of draft-ietf-mobike-protocol-04.txt)
Jari Arkko <[email protected]> Mon, 24 Oct 2005 16:21:55 +0300
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
Yes. Thanks. --Jari [email protected] wrote: >Jari Arkko wrote: > > > >>It was indeed intention that the return packet in step 3 >>would be lost. We forgot to draw this in the flow, however. >>I have used something like >> >> REQ >> ------------------------------------------------> >> RESP >> /---------------------------------- >> >>elsewhere. But the real question is I guess step 4 >>correctness. Yes, I actually thought that we could >>switch to another request, but as you point out, >>this is incorrect. Hmm... this means that we can't >>piggyback the RR test/cookie2 all of a sudden. Oh >>well, that means another roundtrip in this case. >>Retransmit the step 3 packet to a different address, >>then do an RR test separately. >> >> > >I edited it like this: > > (The initiator suspects a problem in the currently used address pair, > and probes its liveness.) > > 3) (IP_I1:500 -> IP_R1:500) > HDR, SK { N(NAT_DETECTION_*_IP) } --> > > (IP_I1:500 -> IP_R1:500) > HDR, SK { N(NAT_DETECTION_*_IP) } --> > > ... > > (Eventually, the initiator gives up on the current address pair, and > tests the other available address pair.) > > 4) (IP_I1:500 -> IP_R2:500) > HDR, SK { N(NAT_DETECTION_*_IP) } > > <-- (IP_R2:500 -> IP_I1:500) > HDR, SK { N(NAT_DETECTION_*_IP) } > > (This worked, and the initiator requests the peer to switch to new > addresses.) > > 5) (IP_I1:500 -> IP_R2:500) > HDR, SK { N(UPDATE_SA_ADDRESSES), > N(NAT_DETECTION_*_IP), > N(COOKIE2) } --> > > <-- (IP_R2:500 -> IP_I1:500) > HDR, SK { N(NAT_DETECTION_*_IP), > N(COOKIE2) } > >Does this look right? > >Best regards, >Pasi > > > >