Dear Masataka Ohta,
I was a bit impetuous in saying that I would prefer not to modify
libraries or implementations etc. However, my aim so far is more to
obtain for myself a clear understanding of the problem we are trying to
solve, rather than trying to state requirements of the possible
Robert Honore;
It seems to me though, that nobody has stated clearly what those
wrong perceptions and ideas are, much less to say what is wrong with
them and thus replace them with correct perceptions and ideas.
A draft ID
Simple Internet Protocol, Again
on the real
[Please direct replies either to the IPv6 or the IETF
mailing lists, but not both. The default should be IPv6,
imho.]
Pekka Nikander wrote:
Now, even though I believe that we should solve the problems (and
apparently believe that there are sensible solutions), achieving
consensus on solutions
Dear Pekka Nikander,
Please forgive the late reply.
Where can I find out more about Dave Crocker's MAST?
See the rest of my message embedded among the qoutation of your text.
Pekka Nikander wrote:
Robert,
I like your analysis very much. Thank you for writing it up.
However, I also see a
, September 05, 2003 3:48 PM
Subject: Re: where the indirection layer belongs
Dear Pekka Nikander,
Please forgive the late reply.
Where can I find out more about Dave Crocker's MAST?
On vrijdag, sep 5, 2003, at 23:15 Europe/Amsterdam, Spencer Dawkins
wrote:
Dave's MAST proposal was announced at
http://www.ietf.org/mail-archive/ietf-announce/Current/msg25938.html.
It is not entirely clear where this draft should be discussed. I
bailed and sent my comments to Dave offlist,
Robert Honore;
(regarding the complexity of putting a general-purpose layer to survive
address changes between L4 and L7)
It is not merely complex but also useless to have such a layer.
Right now I am not fully aware of all of the specifics of the issues in
trying to implement
Dave,
Dave Crocker wrote:
DC In general I suggest we find some specific scenarios that require a new
DC construct for end-point identifiers. ...
Concrete scenarios are very good indeed.
PN On the other hand, security looks to me as a good reason for
PN having stable end-point identifiers.
DC and
Dear Keith Moore,
Maybe I read your paper on project SNIPE too quickly, but it was not
immediately clear that the problems you mentioned were a specific
result of an attempt to make the application resilient against (sudden)
changes in IP address. More specifically, it was not clear from
No matter where the stabilization layer(s) live, using DNS as a
means to map from identity to locations simply won't work. It might be
good enough for initial connection (assuming that if a service exists on
multiple hosts, any of them will do), but it's not good enough for
re-establishing an
Dear Keith Moore,
Thank you for your reply. It seems that we are without a forum though,
since what we are discussing is, according to Tony Hain, not in line
with the IPv6 working group charter. Maybe we really do need a new
working group for this issue. Should we propose the formation of
Michel Py wrote:
IMHO the only place to put the ID/LOC indirection layer (I would say
sub-layer) that does not break a million things is:
I like the third stack, added to the right, even more. A kinda
new waist for the stack. OTOH, I think that most probably
something new is also needed at
Robert,
Robert Honore wrote:
... As such, I can distinguish the following issues as aspects of
the problem given all that was mentioned in this thread, the solving
the real problem thread and the one on the IPv6 mail list about
deprecating Site Local addresses and the usage of IPv6 Link Local
Pekka,
PN that stable end-point identifiers are mainly needed to make
PN applications survive IP address changes. Dave Crocker's MAST
PN is a good example how you can do that without having stable
PN end-point identifiers.
In general I suggest we find some specific scenarios that require a new
Maybe I read your paper on project SNIPE too quickly, but it was not
immediately clear that the problems you mentioned were a specific
result of an attempt to make the application resilient against
(sudden) changes in IP address.
that wasn't quite the purpose of SNIPE. SNIPE didn't
On vrijdag, aug 29, 2003, at 23:06 Europe/Amsterdam, Keith Moore wrote:
It's not uncommon to see a FQDN point to several IP addresses so that
the service identified by the FQDN can be provided either by
(a) multiple hosts, or
(b) a host with multiple addresses.
No. A client can't tell whether
To be more precise: the idea is to have transport sessions move from
one address to another when there is a rehoming event. Obviously there
will be changes to the process of publishing additional addresses.
I'm also interested in ways of doing this. I just don't think it's
appropriate to
Keith Moore wrote:
Second, this robs apps of the best endpoint identifier they have.
Rather than being so locked into topology locators as endpoint
identifiers, we need to be specifying an infrastructure for endpoint
identifiers and any mapping protocol that might be needed.
I don't
Keith Moore wrote:
You are missing something fundamental here - if a TCP
connection breaks (isn't closed cleanly) then the two
endpoints can get out of sync regarding how much data was
delivered. You can't fix this at higher layers without an
unacceptable amount of complexity and
group.
There are few, however quite strong arguments for that. First of all why limit
ourselves with the question where the indirection layer belongs? There is no any
indication that more than one indirection layer is possible in the stack and if right
design assumed, there will be no collision
Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Friday, August 29, 2003 2:31 PM
To: Yuri Ismailov (KI/EAB)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: where the indirection layer belongs
[CC'ing multi6 as I don't think everyone there knows about this thread
(regarding the complexity of putting a general-purpose layer to survive
address changes between L4 and L7)
But why do you assert that it will take lots of complexity and
overhead? Can you point to some code where they tried this? As far
as I know, nobody has really given this an earnest
Regarding this discussion about an indirection layer, I am thinking we
really should propose the formation of some forum for discussion of
these issues. [...] Call it an indirection layer or a stabilisation
layer or whatever you want, but we need a forum where we can specify
the problem we
Keith;
(regarding the complexity of putting a general-purpose layer to survive
address changes between L4 and L7)
It is not merely complex but also useless to have such a layer.
The basic problem of the approach to have such a layer is that
only the application layer has proper knowledge on
well, the reason I named a specific time interval was to provoke
discussion, so I suppose I shouldn't be disappointed...
I am not sure that one week is the best figure. I imagine that figure
could reasonably be picked to be anywhere between several hours on the
low end to a few weeks on the high
At 20:54 29/08/03, Keith Moore wrote:
Personally I think a forum might be a bit premature, as it would
distract various peoples' energy away from efforts to draft strawman
architectures, and instead tempt them to spend time getting in sync with
the group. Maybe we could have a BOF in Minneapolis
It's not uncommon to see a FQDN point to several IP addresses so that
the service identified by the FQDN can be provided either by
(a) multiple hosts, or
(b) a host with multiple addresses.
Now if we want to support moving from one addresses to another in the
middle of an (application
27 matches
Mail list logo
