[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how mobile do we want to be
We are spending a lot of energy on this discussion. I don't
sense the two sides of the debate moving much closer to
each other. However,while the gap seems large in the discussion
and theory, I'm actually not convinced that its that large
First of all, I think most people in this thread agreed that
shim6 should not break existing mobility mechanisms, i.e.,
Mobile IPv6. So far so good, though this may mean some
work in shim6 to ensure that its really the case.
Secondly, most people would probably find it desirable to
work (in some other bof) on more advanced combinations
of what you can achieve with shim6 and mipv6.
Thirdly, I sensed that some of you wanted to ensure
that shim6 is designed both as a multihoming solution
and as a next-generation mobility solution. This raised
a lot of technical and administrative discussion. But putting
the discussion aside for the moment, I would
like to note that there are actually some components
of a such as solution already in the current working
assumptions of our group. Namely, the possibility of
"dynamic multihoming", at least as an option, and the
use of SEND address format which might be used to
build a mobility solution, even if originally intended just
for SEND and shim6 compatibility. These building blocks are close to
what I'd choose if I had to design a zero-config ipv6-only
multihoming and mobility solution from scratch.
In conclusion, while people are saying "we are not
going to do it", there are some underlying technical
choices that have not closed the door, IF we decide
to that. This is good.
I tried to incorporate these aspects also to the charter
text proposal that I sent to the list some time ago.
P.S. I can't resist saying that people who think its impossible
to build a solution that does both mobility and multihoming
should visit a couple of other IETF WGs and prototype labs
that appear to be doing just that, as well as handling IPv4-IPv6
and NAT traversal too :-)