Jeroen Massar wrote:
My current idea puts it at the resolver level. The
application gets the 128bits identifier, which
actuall is a IPv6 address, either given out from a
special registry or simply from an /48 that is
already assigned to you. This address can be used
for both routing and
-BEGIN PGP SIGNED MESSAGE-
Tony Hain wrote:
Mobile IP, and the multi6 DHT work are attempts to mitigate it through
slight of hand at the IP layer, while SCTP attempts to mask the topology
reality in the transport layer. (These are probably not the only examples,
but they are the ones
-BEGIN PGP SIGNED MESSAGE-
Tony Hain [mailto:[EMAIL PROTECTED] wrote:
[?Does this need to keep going to both [EMAIL PROTECTED] [EMAIL PROTECTED]
Jeroen Massar wrote:
... As far as it stands I think that HIP
is going the best way there is. LIN6 is flawed as it won't
scale and
Jeroen Massar [EMAIL PROTECTED] wrote:
|The stack/API then maintains a list of routing IP's that
|are associated by that IdentifierIP and then replaces it
|before it enters the network with the routing IP that is
|to be used for actually routing the packet.
I've made this proposal several times
Dan Lanciani wrote:
|So you prove my original point, 'there is a sacred invariant, and we
|must avoid messing with the app / transport interface at all costs'.
As a practical matter, this is probably true.
Are you saying that for existing apps we can't change (in which case I
agree), or
21:12
To: 'Robert Honore'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Solving the right problems ...
Robert Honore wrote:
Perhaps this proposal really requires another working group or
something.
To be clear, I was not recommending where the work get done, that is why
Iljitsch van Beijnum wrote:
The hard part is coming up with a way to do the host/location mapping
in a way that is simple, fast, cheap, secure, flexible and reliable.
Wouldn't we all start deploying, e.g., HIP tomorrow if we had a solution for
this? And, how might that solution be any
-BEGIN PGP SIGNED MESSAGE-
Mika Liljeberg wrote:
On Wed, 2003-08-27 at 20:21, Keith Moore wrote:
what has changed is that we're now expecting a layer 3 that was designed
for relatively stable networks of wired hosts to suddenly accomodate
mobile and nomadic hosts and networks,
Jeroen Massar wrote:
[?Does this need to keep going to both [EMAIL PROTECTED] [EMAIL PROTECTED]
Not as far as I am concerned. If we take the suggested path, the work is
clearly outside the IPv6 WG, and anyone on the IPv6 list that cares to
follow the discussion is now aware of it. I will be
-BEGIN PGP SIGNED MESSAGE-
Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] wrote:
On woensdag, aug 27, 2003, at 13:18 Europe/Amsterdam, Jeroen Massar
wrote:
I totally agree with your current insight that we need to seperate
the routing from the host identifier. IMHO every host
[EMAIL PROTECTED] wrote:
A very quick question about your idea. Does this layer have a
protocol / interface to other elements on the network? Or are
you proposing something more like an abstract API?
Simple question, complex answer ... It really depends on where you are
looking at it from,
Jeroen Massar wrote:
... As far as it stands I think that HIP
is going the best way there is. LIN6 is flawed as it won't
scale and can't be deployed easily. Next to those I got my
own odd idea and I will probably work it out and implement it
as a proof of concept. Though timing on when
Iljitsch van Beijnum wrote:
The multi6 wg has been working on locator/identifier separation as a
way to solve the multihoming in IPv6 problem for a while now.
The problems we're facing (apart from the fact that there are
many ways
to skin this particular cat and everyone has a different
Dear Tony Hain,
Perhaps this proposal really requires another working group or
something. I seem to remember someone making a similar proposal a
several years ago on this list and it didn't seem to get a good
reception then. For what it is worth, though, I really do think it is
an idea
In the ongoing saga about topology reality vs. application perception of
stability, it occurs to me we are not working on the right problem. In short
we have established a sacred invariant in the application / transport
interface, and the demands on either side of that interface are the root of
[trying to keep this as brief as possible]
In the ongoing saga about topology reality vs. application perception of
stability, it occurs to me we are not working on the right problem.
agree.
We all agree that applications should not be aware of topology. At the same
time, application
16 matches
Mail list logo
