Sean Doran wrote:
>
> 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
> > > the on-the-wire protocol overhead is not that great. the computational
> > > overhead to the host and application, and the resulting loss in maximum
> > > bandwidth, are fairly expensive.
> >
> > I tend to disagree. An association protocol only really does its work on
> > connect/reconne
> From: Masataka Ohta [SMTP:[EMAIL PROTECTED]]
> "good *if* and only if"?
>
> With cookies, a network is as secure as a telephone or fax network, which
> is *GOOD* enough for credit card companies.
Not exactly. It's pretty easy to intercept any packet on the Internet,
that's not
the case for reg
:|||: :|||: 14875 Landmark Blvd #400; Dallas, TX
> .:|||:..:|||||||:. Email: [EMAIL PROTECTED]
>
> - Original Message -
> From: [EMAIL PROTECTED]
> To: Karl Auerbach
> Cc: IETF
> Sent: Wednesday, April 26, 2000 16:48
> Subject: RE: runumbering (was: R
> 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
> > > 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 p
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
http://www.acm.org/pubs/articles/pr
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 netwo
In message <[EMAIL PROTECTED]>, Masataka Ohta wr
ites:
>
>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. We learned in 19
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 peop
[EMAIL PROTECTED]
- Original Message -
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
> > 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
> > 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
> 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 pa
>
> I think your description is somewhat biased, Paul. Suppose that you execute
Sure...I was making a point, not publishing a full analysis. But
my position did take into consideration everything you mention.
> the strategy you describe, and that the address 10.3.2.1, that was mapped to
>
> Actually, if your assumption is that NATv6 is better than IPv6 with
> renumbering, then IPv4 and NATv4 was good enough to start with and
I'm not prepared to say that NATv6 is better than IPv6+renumber,
simply because what is better depends on what is important to
the user. By some general a
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 fr
> > 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
> 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 on
> 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
> > 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, do
Hello again,
>From the note below, it's obvious that there are some misconceptions
about Mobile IP that I'd like to correct.
Tripp Lilley wrote:
> That is, that's the way it should work... I should be able to put my
> laptop to sleep, hop on the plane, land in San Francisco, pull it back
> out
> 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
> I have a hard time believing that your average IP net manager
> wouldn't prefer to run an IPv6-IPv6 NAT box (lets call this
> NATv6) at her ISP boundary rather than do site-wide renumbering.
some of the applications that will motivate the deployment of
IPv6 will be those that do not work with N
% > 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 "associati
On Tue, 25 Apr 2000, Karl Auerbach wrote:
> 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 i
> 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 lif
> 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 ad
At 1:53 PM -0700 4/25/00, Paul Francis wrote:
>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.
If that were the only issue, sure. But there are tradeoffs: is the ease
of renumbering (which should be a relatively rare e
29 matches
Mail list logo
