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.
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-13
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
