Subject: Re: [Hipsec] [Hipsec-rg] About simultaneous mobility to HIP

From: Robert Moskowitz <[email-masked]>
Date: Thu, 31 Jul 2008 11:07:29 +0100

Andrew McGregor wrote:
> This is what the concept of a Rendezvous Server is intended to solve.  
> The (perhaps undocumented) idea is that a host should maintain 
> connectivity to one such that is unlikely to move, and to advertise 
> its locator as a potential rendezvous point.
At the very first BOF on HIP, Steve Derring (sp!), pointed out that if I 
could not solve the 2-party move, then HIP was not deployable (or some 
such wording).  At that time the state machines (there were 2 at that 
time, one for the Initiator, and one for the Responder) could handle one 
move or the other, but not both.

That night, some people talking with me (mostly Hugh Daniels) pushed me 
to invent the Rendezvous Server.  Later Hugh and Andrew and Pekka 
greatly improved on it.

In actual usage, the Initiator MAY assume that the address it has for 
the Responder is a Rendezvous Server address, not the actual address of 
the Responder.  The Responder SHOULD always tell the Intiator its 
current RVS and the Initiator SHOULD always provide its RVS.  If you 
look at the state machine, given this, the hosts can rediscover 
themselves quickly.  A host that moves can inform all of its SAs of any 
readdressing.

Magic happens  :)

Just sitting here in the Internetworking meeting listing to IPv4/IPv6 
funness.

Alway, go look at the RVS.
>
> Andrew
>
> On 31/07/2008, at 9:32 PM, John.zhao wrote:
>
>> Hi,folks
>>
>>     After take a look about current docs located in hip wg and hip 
>> rg. I didn't find the document to describe how to resolve the 
>> simultaneous mobility problem aimed to hip. If anyone have some clues 
>> , hope can be shared.
>>     If not,is it ok to start it?
>>     
>>
>>     Best Rgds,
>> Thanks,
>>                
>>
>>     　　　　　　　　 John.zhao
>> 　　    　    　　　　　[email-masked]
>> 　　　    　    　　　　　　2008-07-31
>> _______________________________________________
>> Hipsec-rg mailing list
>> [email-masked]
>> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>
_______________________________________________
Hipsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hipsec

---

From: Varjonen Samu <[email-masked]>
Date: Thu, 31 Jul 2008 12:56:55 +0300

Hi,

If both peers move at the same time, the update mechanism does not work
because both peers changed addresses at the same time and there is no
address that has been successfully connectivity tested. One way to solve
this is to use rendezvous server as a "home server".

http://infrahip.hiit.fi/hipl/manual/ch14s03.html

When both peers are mobile and the connectivity tests fail, peers should
try to find other peers RVS server and contact it through it. You could
also look RFC 5204 .

Cut-and-paste from RFC 5206 mobility and multihoming where this is
mentioned also

   There are a number of situations where the simple end-to-end
   readdressing functionality is not sufficient.  These include the
   initial reachability of a mobile host, location privacy, simultaneous
   mobility of both hosts, and some modes of NAT traversal.  In these
   situations, there is a need for some helper functionality in the
   network, such as a HIP rendezvous server [RFC5204].

BR
Samu Varjonen

John.zhao wrote:
> Hi,folks
> 
> 	After take a look about current docs located in hip wg and hip rg. I didn't find the document to describe how to resolve the simultaneous mobility problem aimed to hip. If anyone have some clues , hope can be shared.