To: Karl Auerbach
Cc: IETF
Sent: Wednesday, April 26, 2000 16:48
Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Turn it any way you want, TCP sessions can only survive renumbering
through
end to end mechanisms...
Which raises the interesting (to me anyway) quest
It seems to me that the decision to just use NATv6 rather than
do a site-wide runumber will be a very easy decision to make.
Actually, if your assumption is that NATv6 is better than IPv6 with
renumbering, then IPv4 and NATv4 was good enough to start with and
there was need to move to IPv6 in
So what I am suggesting is that it seems that there is evidence that one
can do an "association" protocol that is relatively lightweight in terms
of machinery, packets, packet headers, and end-node state if one leaves
the heavy lifting of reliability to the underlying TCP protocol.
the
Thomas Narten writes:
| Actually, if your assumption is that NATv6 is better than IPv6 with
| renumbering, then IPv4 and NATv4 was good enough to start with and
| there was need to move to IPv6 in the first place.
^
no (right? maybe this is where the previous "not" came
I agree completely with what you say about needing to push
the multi-address complexity to the host. As you kindly
pointed out (and I self-servingly expand on here), this is
an architecture I put forth about a decade ago in a sigcomm
paper (in Zurich, I don't remember the year).
The paper
mid-connection. I would assume that what people have in
mind for this are the mobility mechanisms? (The alternative
is 8+8 or some variant, which I understand to be contentious
enough that it is a defacto non-starter.)
The rubbing point is that identifying is not quite enough
Turn it any way you want, TCP sessions can only survive renumbering through
end to end mechanisms...
Which raises the interesting (to me anyway) question: Is there value in
considering a new protocol, layered on top of TCP, but beneath new
applications, that provides an "association" the
e -
From: [EMAIL PROTECTED]
To: Karl Auerbach
Cc: IETF
Sent: Wednesday, April 26, 2000 16:48
Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
Turn it any way you want, TCP sessions can only survive renumbering
through
end to end mechanisms...
Which raises the inter
Christian;
But that architecture (hosts having multiple addresses
representing a site's multiple aggregation prefixes and
selecting among them) requires some method of identifying
hosts when they switch from one address to another
mid-connection. I would assume that what people have
Steve Bellovin;
To avoid connection hijacking, cookies, such as TCP port and sequence
numbers, is enough, if they are long enough.
That's preposterous. Long-enough numbers are good *if* and only if there are
no eavesdroppers present.
"good *if* and only if"?
With cookies, a network is
Hi all,
I guess this is somewhat unrelated to the thread's maing topic but
the paper that Christian mentioned is available to everyone (as
well as all papers from SIGCOMM since 91) through SIGCOMM's web site.
The exact pointer for the paper mentioned below is
So what I am suggesting is that it seems that there is evidence that one
can do an "association" protocol that is relatively lightweight in terms
of machinery, packets, packet headers, and end-node state if one leaves
the heavy lifting of reliability to the underlying TCP protocol.
draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of
sessions within a server pool, where uncoordinated failover of sessions from
one endpoint to another is a requirement. There is signifcant overheard and
indirection added to the session to achieve this.
We seem to be
Now consider the NATv6 alternative. The average net admin is already
comfortable with NAT at the ISP boundary (hell, some even like it).
She will already be running NAT, if for no other reason than to deal
with IPv4-IPv6 transition. NATv6 is much less onerous than NATv4,
because the
% Turn it any way you want, TCP sessions can only survive renumbering through
% end to end mechanisms...
%
% Which raises the interesting (to me anyway) question: Is there value in
% considering a new protocol, layered on top of TCP, but beneath new
% applications, that provides an
Which raises the interesting (to me anyway) question: Is there value in
considering a new protocol, layered on top of TCP, but beneath new
applications, that provides an "association" the life of which transcends
the TCP transports upon which it is constructed?
been there, done that. yes,
Which raises the interesting (to me anyway) question: Is there value in
considering a new protocol, layered on top of TCP, but beneath new
applications, that provides an "association" the life of which transcends
the TCP transports upon which it is constructed?
been there, done that.
17 matches
Mail list logo
