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".
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.
This comment recommends changes to 5204-bis 4.2.3 that the main goal
of VIA_RVS is to facilitate support for the double-jump mobility
problem and secondarily "to allow operators ...".
And to 5206-bis section 3.2.3 to use the VIA_RVS to 'know' that there
is an RVS for the host and to optionally aggressively send HIP
mobility UPDATES to the RVS.
It seems to me that we ought to state that hosts should be prepared to
handle duplicate mobility updates sent in parallel to different
locators (such as to RVS(es) and to more than one of the host's
addresses). We could also state that the aggressiveness of a host
replicating its UPDATES to multiple destinations, to try them in
parallel instead of serially, is a policy choice outside of the
specification. Any other comments on this possible change?
- Tom
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
