Hi, On 09/27/2016 03:56 AM, Robert Moskowitz wrote:
On 09/26/2016 09:08 AM, Miika Komu wrote:Hi, On 09/16/2016 02:45 PM, Robert Moskowitz wrote:On 09/16/2016 06:57 AM, Tom Henderson wrote:On Thu, 15 Sep 2016, Robert Moskowitz wrote:5206-bis specifies how to user RVS for the 'double-jump' mobility problem. 3.2.3 1) says: 1. The mobile host sending an UPDATE to the peer, and not receiving an ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the peer, if such a server is known. But it DOES know there is an RVS IF the I1 had FROM and RVS_HMAC parameters and it had created a VIA_RVS parameter to send in the R1.Yes, but the responder may not know the initiator's RVS even if the the responder's RVS was used, and it also may be the case that neither host's RVS was involved in the session setup.I see now. As currently speced, R has no way of learning I's RVS. The 'easy' way to fix this is for I to include a VIA_RVS in the I2 packet for mobility support. "If you every want to get back to me, I can always be reached at this number".do you actually need the initiator's RVS for double jump? I think the responder's RVS is enough.Then the Initiator's UPDATE must be successful before the Responder can perform its UPDATE successfully. This way they can operate in parallel.
I see, you really want to avoid packets being dropped.
This VIA_RVS provides the knowledge and locator of the peer's RVS. In fact an aggressive mobility UPDATE would be sent simultaneously to the host and its RVS. If the host had not moved itself, it gets both and drops the one from the RVS.I believe that Baris Boyvat on the InfraHIP project was looking a while back at such an approach to fast mobility; it was called 'shotgun' approach to mobility and multihoming (try all candidates simultaneously), if I remember correctly.Yes, the idea was to send I1 (or UPDATE) through all the available address pairs, but I think the idea is now achieved in a more controlled way in draft-ietf-hip-native-nat-traversal-13I will look at that. But what if there is no NATs to traverse? That there are 2+ interfaces, all native IPv6? But I will review nat-traversal.
Basically the nat-traversal draft is about connectivity checks (that traverse NATs), nothing much IPv4 specific there. Feedback is still welcome.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
