Shim6, was: Re: filtering /48 is going to be necessary
mohta at necom830.hpcl.titech.ac.jp
Thu Mar 15 07:52:54 CDT 2012
William Herrin wrote:
>> I know non-IP mobile environment is heavily encumbered. So, I
>> can understand why you insist on using DNS for mobility only
>> to make IP mobility as encumbered as non-IP ones.
> I don't understand your statement. None of the technologies I work
> with use the word "encumbered" in a comparable context. Perhaps you
> could rephrase?
OK. You are bell headed.
>> However, on the Internet, 0.05 second of packet losses can
>> be significant and things work end to end.
> Get real. Even EAPS takes 0.05 seconds to recover from an unexpected
> link failure
If you keep two or more links, keep them alive, and let them
know their IP addresses each other, which can be coordinated
by mobile hosts as the ends, links can cooperate to avoid
broken links for a lot faster recovery than 0.05s.
> and that's on a trivial Ethernet ring where knowledge
> propagation is far less complex than a mobile environment.
The previous statement of mine merely assumes radio links with
sudden link failure by, say, phasing.
Its spatial diversity arranged by the mobile hosts as the ends.
If link failure is expected several seconds before, which is
usual with radio links, mobile hosts can smoothly migrate to
a new link without any packet losses, because it has much
time to resend possibly lost control packets.
>> In this case, your peer, a mobile host, is the proper
>> end, because it is sure when it has lost or are
>> losing a link.
> Correct, but...
>> Then, the end establishes a new link with a new IP and
>> initiate update messages for triangle elimination at
>> proper timing without unnecessary checking.
> This is where the strategy falls apart every time. You know when your
> address set changes but you don't know the destination endpoint's
> instant address set unless
Certainly, if two communicating mobile hosts, two ends, changes
their IP addresses simultaneously, they can not communicate
*DIRECTLY* each other, because they can not receive new IP
addresses of their peers.
The proper end for the issue is the home agent.
Just send triangle elimination messages to the home agent
without triangle eliminations.
With the new layer of indirection by the home agent, control
messages for triangle elimination are sent reliably (though
The home agent knows reachable foreign addresses of mobile hosts,
as long as the mobile hosts can tell the home agent their new
foreign addresses before the mobile hosts entirely loses their
> either (1) he tells you or (2) he tells a
> 3rd party which you know to ask.
(3) he tells his home agent, his first party, to which you,
his second party, ask packet forwarding.
Unlike DNS servers, the first party is responsible for its
> Your set and his set are both in
> motion so there _will_ be times when your address set changes before
> he can tell you the changes for his set. Hence #1 alone is an
> _incomplete_ solution.
A difficulty to understand the end to end principle is to
properly recognize ends.
Here, you failed to recognize home agents as the essential
ends to support reliable communication to mobile hosts.
> It was incomplete in SCTP, it was incomplete in Shim6 and it'll be
> incomplete in MPTCP as well.
It is complete though shim6 is utterly incomplete.
> And oh-by-the-way, if you want to avoid being chatty on every idle
> connection every time an address set changes and you want either
> endpoint to be able to reacquire the other when it next has data to
> send then the probability your destination endpoint has lost all the
> IP addresses you know about goes way up.
Idle connections may have timeouts for triangle elimination after
which they use home agents of their peers.
That's how the end to end Internet is working without any packet
losses not caused by congestion nor unexpected sudden link failures.
More information about the NANOG