[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fragmenting the solution space
On 14-mrt-05, at 21:02, Dave Crocker wrote:
It strikes me that mobility vs. multihoming is not benefiting from
similar abstraction efforts,
Mobility and multihoming require very different tradeoffs. Mobility
needs to be able to add new addresses to existing communication
sessions/associations, but it can suffer having a home agent.
Multihoming absolutely can't depend on a home agent, but it doesn't
really need to add new addresses to existing sessions/associations.
Now if you are about to suggest a mechanism that can add new addresses
but doesn't need a home agent, and is sufficiently light-weight that it
won't overload the support lines, batteries in mobile devices or the
user's willingness to wait for something to happen after clicking,
we'll be happy to listen.
nevermind the likely artificial distinction between IPv4 and IPv6 on
this topic
We don't even have enough IPv4 addresses to give everyone _one_
address, let alone two or more... IPv4 is is dead. If it turns out we
can dress up the corpse with a shim4 layer, fine. If not, no big loss.
and nevermind the real-world transition difficulties created by any
suggestion that NATs much change.
Did I mention that IPv4 was dead?
Does it bother anyone that we are marching down a path that our next
decade or longer will require support for at least:
1. IPv4 mobile
Huh?
2. IPv6 mobile
Ok, I'll buy this one but it would be nice if someone bothered to
implement it first.
3. IPv6 multihoming
People are actually waiting for this one.
4. TCP multihoming
What are you talking about?
5. SCTP multihoming
Nice try, but it comes up short in many respects.
I notice that my windows desktop has pretty awful performance with
anything less than 512MB of memory.
It would be nice not to march the Internet stack down the path of
requiring that much for my mobile phone.
Exactly. So we have to be careful about requiring strong crypto for
basic functionality such as multihoming.