On 29 Jul 2009, at 16:24, Eliot Lear wrote:
It's a worthy endeavor to understand how two hosts
that both always move and have no home rendezvous.
That's the hardest case, but not impossible operationally
*in the real world with reality constraints*.
THe main trick is to use DNS (or something like it) as
a fallback rendezvous to rediscover the correspondent's
new location. (I think the idea of first using DNS for
mobility rendezvous might have been first published in
a paper in the IEEE LCS proceedings about a decade back;
it certainly is not my idea.)
One imagines that a control message ("ICMP Location Update")
can be sent by the host (about to move or just finished moving)
to its correspondents && the host also updates its A/AAAA
(or equivalent) records in the DNS using the widely available
Secure DNS Dynamic Update mechanism (available in BIND, MS Windows,
and for MacOS X [source: "DNS & BIND" book, 5th Edition])
If that ICMP message doesn't reach some correspondent (e.g.
because the correspondent moved at the same instant, unlikely
though that might be), then the correspondent can use the DNS
to find the original host's new address (and the original host
can use the DNS to find the correspondent's new address).
In the limit, if both nodes are constantly changing their
point of network attachment, then both nodes will not
be able to send or receive any packets before a new Layer-3
location change -- at which point both nodes are effectively
disconnected, at least until they stand still for a bit.
In practice, most mobility is handled by layer-2 mechanisms
(e.g. mobile phone stuff; IEEE 802.1 bridging) -- at least
part of the time. For all of the discussion above, only
changes in the layer-3 point of attachment matter.
[In a previous life, I had some small experience dealing with
IPv4 mobility issues, as my then employer had a few hundred
ships deployed around the globe and some large number of
airplanes. I find that their real-world operational issues
continue to be relevant. Solutions that will work there
likely also will work nearly everywhere else.]
Cheers,
Ran
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
