[EMAIL PROTECTED] (Keith Moore) wrote on 19.12.00 in
<[EMAIL PROTECTED]>:
> agreed, *provided* there is a fast and reliable service for mapping
> between one kind of identity and another. arguments of the form
> "separate identities are better" tend to gloss over the difficulty
> of providing
> thank you, I think you've advertised this draft quite adequately for the
> time being. I'm quite willing to look at it, but there are numerous
Thanks! now I will relax and go home :)
> every possible alternative architecture to conclude that (a) most or all
> of these identifiers are necess
> > IMHO what we need to change is the *implicit* association between
> > "host" related identifiers and "network topology" related identifiers -
> > so that coders treat them as separate entities, and provide a way
> > for the two to be different at the IP layer - while still allowing
> > the opt
> IMHO what we need to change is the *implicit* association between
> "host" related identifiers and "network topology" related identifiers -
> so that coders treat them as separate entities, and provide a way
> for the two to be different at the IP layer - while still allowing
> the optimization
> | yeah, I really wish those who are trying to improve network routing
> | (an endeavor which I respect in principle) would consider that
> | applications really do need stable endpoint identifiers which
> | are globally scoped, exchangable with other applications, and
> | reliably usable from an
Keith Moore writes:
| yeah, I really wish those who are trying to improve network routing
| (an endeavor which I respect in principle) would consider that
| applications really do need stable endpoint identifiers which
| are globally scoped, exchangable with other applications, and
| reliably u
{I had written:}
> | from label switching, so what I'm suggesting is that we take the bull by
> | the horns once and for all and run MPLS over IP instead of under it...
>
> an mplsd-like tag fits neatly in the first half of an ipvsux destination
> address, although there are other places in t
yeah, I really wish those who are trying to improve network routing
(an endeavor which I respect in principle) would consider that
applications really do need stable endpoint identifiers which
are globally scoped, exchangable with other applications, and
reliably usable from anywhere to reach th
At 02:11 AM 12/22/00 +0100, Sean Doran wrote:
>an mplsd-like tag fits neatly in the first half of an ipvsux destination
>address, although there are other places in the vsux header you can put
>tag bits if you're inclined to do so for stacking reasons or whatnot.
actually, I should think the flow
| from label switching, so what I'm suggesting is that we take the bull by
| the horns once and for all and run MPLS over IP instead of under it...
an mplsd-like tag fits neatly in the first half of an ipvsux destination
address, although there are other places in the vsux header you can put
t
At 04:41 PM 12/21/00 -0800, Fred Baker wrote:
>Unfortunately, the world is not internet-attached. Western Europe is, the
>US and Canada are, Australia is, Taiwan has Internet in every public
>library (I'm told). It comprises populations in the 1 billion person
>ballpark. There are some pretty l
At 02:54 PM 12/14/00 -0500, Tony Dal Santo wrote:
>What exactly is the state of the IPv4 "address pool"? I realize there is
>a PERCEIVED shortage, and this is usually the main motivation for NAT.
>But is there a real shortage? Are "reasonable" requests for addresses
>being denied?
The way I und
At 02:19 PM 12/14/00 -0500, [EMAIL PROTECTED] wrote:
>I haven't decided which of the four NAT should be blamed on.
let's be fair. There was an excellent reason for NAT at the time. Postel
suggested that private address spaces could be used rather than assigning
precious IP Address space to netw
>
>
> On Thu, 21 Dec 2000, Mike Fisk wrote:
>
> > Yes, I was being slightly more general to include other gateways that
> > don't necessarily operate at the application layer:
> > TCP-splicing/spoofing, NAT, SOCKS, etc.
> >
> > The problem is that the protocol mechanisms to discover and use
On Thu, 21 Dec 2000, Mike Fisk wrote:
> Yes, I was being slightly more general to include other gateways that
> don't necessarily operate at the application layer:
> TCP-splicing/spoofing, NAT, SOCKS, etc.
>
> The problem is that the protocol mechanisms to discover and use these
> gateways ar
>> Excellent. We've agreed that IPv6's problems are a subset of IPv4's.
From: Randy Bush <[EMAIL PROTECTED]>
>unfortunately, we have not shown it is a proper subset. e.g. the larger
>address space may exacerbate issues already causing problems in v4, such as
>the increasing number of routes
On Wed, 20 Dec 2000 13:39:11 -0500, you wrote:
>V Guruprasad posted, in reply to private mail:
>
>> Obscurity would mean that a unique server host address exists but
>> is not advertised.
>No. Security through obscurity means any approach that attempts to protect
>network resources (in this cas
On Thu, 21 Dec 2000, Harald Alvestrand wrote:
> At 09:47 19/12/2000 -0800, Mike Fisk wrote:
> >It's an argument of semantics, but I prefer to say that we're separating
> >transport-layer end-to-end from application-layer end-to-end. Make
> >applications explicitly terminate transport connections
At 09:47 19/12/2000 -0800, Mike Fisk wrote:
>It's an argument of semantics, but I prefer to say that we're separating
>transport-layer end-to-end from application-layer end-to-end. Make
>applications explicitly terminate transport connections at gateways. So
>what is now a connection from me to
one of nature's great dualities: statedulness will take root in the
most barren soil, even though datagrams will try to route around it
j
though if nat speak unto nat, then ipv6 be born
On Wed, 20 Dec 2000, John Stracke wrote:
> I say it's a weak form because I believe you are wrong in stating that "a
> unique server host address does not exist". The URL (ick) is an address
> for the server; it's just a higher-level address than an IP address.
The "URLs" in my approach do not
V Guruprasad posted, in reply to private mail:
> Obscurity would mean that a unique server host address exists but
> is not advertised.
>
> Invisibility means that a unique server host address does not exist
> at all. This is a harder condition.
No. Security through obscurity means any approach
On Wed, 20 Dec 2000, John Stracke wrote:
> > Why don't you read the I-D
>
> I did.
Then you'd see that the invisibility refers to that of the server
host, as follows: The client sees only the service name binding
in the form of the URL, but what it gets as the data path is
a virtual path (or L
V Guruprasad wrote:
> > of virtual memory is that it makes it easier for the user (well,
> > programmer) by hiding the nasty details of which physical address your
>
> IMHO, hiding is not the primary function of virtual memory addressing,
On the contrary. Hiding the details from the programmer
On Tue, 19 Dec 2000, Mike Fisk wrote:
> It's one thing to hand out addresses or names. It's another thing to run
> a top-level routing server that all of your children customers have to
> route through to get to other top-level providers. Your mapping between
> the two would imply that, for i
On Tue, 19 Dec 2000, Mike Fisk wrote:
> explosion. So over time there becomes an established club of roots and
> everybody else has to be a child. That creates a monopolistic situation
> where you have to pay a root node for transit. It could work, but it
> sounds worse than the existing DNS
On Tue, 19 Dec 2000, Jon Knight wrote:
> are on and what the address of their gateway router is. Not exactly what
> I'd call omniscience.
All right, I confess, I'm not perfect in summarising the existing art and
relating to it (yet). I promise to gratefully acknowledge comments such as
these t
> Steve Bellovin, on IPSEC, not-AH:
>
> | [A] host's identity is represented by its certificate (I'm speaking a bit
> | loosely here); its IP address is merely the way that packets reach it.
>
> This is an example of two separate namespaces that allow one
> to distinguish between "who" and "w
Date: Tue, 19 Dec 2000 11:20:23 -0500
From: V Guruprasad <[EMAIL PROTECTED]>
On Tue, 19 Dec 2000, Keith Moore wrote:
> mumble. as far as I can tell, both DNS names and IP addresses
> are hopelessly overloaded and are likely to stay that way until
> we figure out how to make a
On Tue, 19 Dec 2000, V Guruprasad wrote:
> Could you please take a look at
> draft-guruprasad-addressless-internet-00.txt
> ?
I've just started to read it and in 1.1 it says:
"- requiring e2e network knowledge (omniscience) at each node in the
form of e2e routing tables (Section 1
In message <[EMAIL PROTECTED]>, Mike Fi
sk writes:
>
>The marginal value I see in IPsec is that it is useful for protocols other
>than TCP. For TCP applications, I confess that I don't see much value in
>IPsec (not that TLS has any particular merits, it just became more common
>first).
>
Why do
On Tue, 19 Dec 2000, Theodore Y. Ts'o wrote:
>Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)
>From: Mike Fisk <[EMAIL PROTECTED]>
>
>Gateways that surreptitiously modify packets can break ANY end-to-end
>protocol no matter what layer it's at. Assume that we sacrifice IP
>addres
From: Ken Raeburn <[EMAIL PROTECTED]>
Date: 19 Dec 2000 09:02:52 -0500
"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:
> Kerberos tried to deal with this problem by talking about "canonical
> domain name", which it tried to define as being the name that you got
> when you took a
Hi Keith!
On Tue, 19 Dec 2000, Keith Moore wrote:
> mumble. as far as I can tell, both DNS names and IP addresses
> are hopelessly overloaded and are likely to stay that way until
> we figure out how to make a major architectural change.
Could you please take a look at
draft-guruprasad
ght AH was useless
=> you can argue this for IPv4, not for IPv6 where extension headers
are really used. Many times some of us tried to remove AH, many times
we vote to keep it: this topics should be in the "oh not this again" list
of IETF and IPsec mailing lists.
Regards
[EMAIL
Steve Bellovin, on IPSEC, not-AH:
| [A] host's identity is represented by its certificate (I'm speaking a bit
| loosely here); its IP address is merely the way that packets reach it.
This is an example of two separate namespaces that allow one
to distinguish between "who" and "where". That
>If DNSSEC were deployed, I see no reason why SAs could not be
>bound to domain names.
>
> I disagree. IPSEC is about Security at the IP layer, and that means we
> need a security association which is tied to an object which is
> addressable at the IP layer --- an IP address.
except tha
> there is no such thing as a "canonical domain name" for a host.
> Kerberos tried to invent such a concept, but it didn't work all that
> well. I would much rather have some real IP-level endpoint identifier.
> If that's what we're securing, that's what we should be using.
mumble. as far as I
> If DNSSEC were deployed, I see no reason why SAs could not be
> bound to domain names.
Well, there are all those load-distributing hacks -- Akamai and
others. But I bet they could come up with a huge flesh-tone bandaid
so you would continue not to notice. On a good day.
"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:
> Kerberos tried to deal with this problem by talking about "canonical
> domain name", which it tried to define as being the name that you got
> when you took a DNS name, forward resolved it to get an A address, and
> then reverse-resolved it to get a
In message <[EMAIL PROTECTED]>, "Theodore Y. Ts'o" writes
:
> Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)
> From: Mike Fisk <[EMAIL PROTECTED]>
>
> Gateways that surreptitiously modify packets can break ANY end-to-end
> protocol no matter what layer it's at. Assume that we sacrifice IP
>
Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)
From: Mike Fisk <[EMAIL PROTECTED]>
Gateways that surreptitiously modify packets can break ANY end-to-end
protocol no matter what layer it's at. Assume that we sacrifice IP
addresses as not necessarily end-to-end. Fine, there are gatewa
Date: Mon, 18 Dec 2000 22:54:47 -0500
From: "Donald E. Eastlake 3rd" <[EMAIL PROTECTED]>
If DNSSEC were deployed, I see no reason why SAs could not be
bound to domain names.
I disagree. IPSEC is about Security at the IP layer, and that means we
need a security association which is t
> From: Geoff Huston <[EMAIL PROTECTED]>
> part of the characteristics of today's Internet is that its is
> flattening out. The concept of hierarchical connectivity with
> 'upstreams' and 'downstreams' ... as I understand the current
> deployment plan there are TLAs and sub TL
DNSSEC is still evolving, it isn't deployed yet, and the right mailing
lists to discuss it are the DNSEXT and DNSOP working groups. However,
to give a really brief answer, if your local revolver is unwilling to
do the full blown DNSSEC cryptography and just wants to trust that the
local nameserv
On Mon, 18 Dec 2000 22:54:47 EST, "Donald E. Eastlake 3rd" <[EMAIL PROTECTED]>
said:
> If DNSSEC were deployed, I see no reason why SAs could not be
> bound to domain names.
I admit to not having read the DNSSEC RFCs. I however do hope that they
are immune to the same sort of attacks against S
If DNSSEC were deployed, I see no reason why SAs could not be
bound to domain names.
Donald
From: RJ Atkinson <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
Date: Mon, 18 Dec 2000 20:45:43 -0500
To: [EMAIL PROTECTED] (Sean Doran)
Cc: [EMAIL PROTECTED]
In-Reply-To: <[EMAIL PROTECTED]>
At 17:39 18/12/00, John Collis wrote:
>This is true. To do this though really requires some re-architecting
>of the current Internet model, based on "first principles".
Yes.
>In particular, there is not a sufficient "name space" for what we are
>often currently trying to do - hence the
At 13:44 15/12/00, Sean Doran wrote:
>Surely the "much pain" is because, as Melinda Shore indicates,
>some "anti-NAT fanatics" cannot understand the distinction
>between "who" and "where"?
I fancy that I know one or two things about ESP
and AH. Your analysis is Wrong. The pain has
> Excellent. We've agreed that IPv6's problems are a subset of IPv4's.
unfortunately, we have not shown it is a proper subset. e.g. the larger
address space may exacerbate issues already causing problems in v4, such as
the increasing number of routes.
and i am not 'taunting' but trying to see
On Mon, 18 Dec 2000, Theodore Y. Ts'o wrote:
> My concern is that it may turn out that some transport/routing people
> may conclude that we may also need to do NAT to solve the routing
> problem. In which case, we're back to where we started.
>
> I'd feel a lot better if we could get key routing
"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:
> It would be *awfully* convenient if we declare up front that something
> is the "end point identifier" (i.e., "who"), and is forever exempt from
> being changed by intermediate routing entities, and if necessary,
> something is else the routing comp
> > What is technically wrong with v6 that isn't already technically wrong
> > with v4?
>
> Thank you, Perry, you've put it in a nutshell.
> Noel
Excellent. We've agreed that IPv6's problems are a subset of IPv4's.
Now until we have a concrete design proposal for a perfect world
At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote:
>The flaw in your argument is that you're assuming that the only reason
>to do NAT is because of the address space problem. My concern is that
>it may turn out that some transport/routing people may conclude that we
>may also need to do NAT to
At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote:
>The flaw in your argument is that you're assuming that the only reason
>to do NAT is because of the address space problem. My concern is that
>it may turn out that some transport/routing people may conclude that we
>may also need to do NAT to
Date: Fri, 15 Dec 2000 19:44:18 +0100 (CET)
From: [EMAIL PROTECTED] (Sean Doran)
| It's already happening. Try running IPSec from one 10 network to
| another 10 network. Much pain.
Surely the "much pain" is because, as Melinda Shore indicates,
some "anti-NAT fanatics" cannot
From: "Perry E. Metzger" <[EMAIL PROTECTED]>
Date: 17 Dec 2000 13:32:03 -0500
It certainly takes more. The amount of NAT equipment out there is
astonishing, and as I said at the plenary, people are starting to pay
Real Money (as in millions a year) in large organizations to keep th
>
> You know, concerns over global name spaces and architectural purity are
> valid to the engineer/operator. But to Joe User who just got his first
> cable modem and got rid of AOL, he just wants to connect his computer
> to the Internet. Then he wants to share that connection with his kids'
> c
Perry E. Metzger wrote:
> They can't avoid it. They need to get their work done. They have no
> way of getting registered addresses. They're told to use NAT by
> organizations like ARIN, and so they do the only thing they can.
I have a hard time believing ARIN is telling people to use NAT, when
--- Sean Doran <[EMAIL PROTECTED]> wrote:
> Keith Moore writes:
>
> | but I'm fairly convinced that we are *far* better off with a global
> | name space for network attachment points, which are exposed and
> | visible to hosts and applications, than we are with only locally
> | scoped addresses
Keith Moore writes:
| but I'm fairly convinced that we are *far* better off with a global
| name space for network attachment points, which are exposed and
| visible to hosts and applications, than we are with only locally
| scoped addresses visible to hosts and applications
Out of curiosity, do
> If you find a way to select paths in real networks using only virtual data,
> we'd all be interested to hear it.
Try draft-guruprasad-addressless-internet-00.txt, and
the ECUMN'2000 paper on which it was based, at
http://affine.watson.ibm.com/tmp/vinet.pdf
The draft doesn't yet mentio
In message <[EMAIL PROTECTED]>, RJ Atkinson type
d:
>>At 13:32 17/12/00, Perry E. Metzger wrote:
>>From an operator perspective, supporting *2* IP protocols
>>is much harder than supporting just one. If one looks around,
>>very few NOCs on the planet today could reasonably be calle
Daniel Senie <[EMAIL PROTECTED]> writes:
> I'd read that RIPE is at least making micro-allocations available. The
> ability to get a few /27 allocations can REALLY help in cross-connecting
> corporations which find themselves needing private interconnects.
It can help, but it is hardly sufficien
"Steven M. Bellovin" wrote:
>
> In message <[EMAIL PROTECTED]>, "J. Noel Chiappa" writes
> :
>
> >I mean, I can understand it is a temporary thing, e.g. if one company buys
> >another, and in gluing the networks together they temporarily leave the
> >bought company behind a NAT, but interface it
> > if you try to build a global network out of limited-scope addresses you
> > eventually end up reinventing IP at a higher layer.
>
> Err, did you perhaps mean "end up reinventing globally unique addresses
> somewhere else in the system"? :-)
No. I considered whether reinventing somet
In message <[EMAIL PROTECTED]>, "J. Noel Chiappa" writes
:
>I mean, I can understand it is a temporary thing, e.g. if one company buys
>another, and in gluing the networks together they temporarily leave the
>bought company behind a NAT, but interface it to the world via the main
>corporation's g
"J. Noel Chiappa" <[EMAIL PROTECTED]> writes:
> > From: "Perry E. Metzger" <[EMAIL PROTECTED]>
>
> > Several layers of NAT has become common
>
> This is have a hard time fathoming - not that I'm doubting that people do it,
> mind.
Imagine a large number of companies talking to each oth
In message <[EMAIL PROTECTED]>, "J. Noel Chiappa" writes
:
>
>I mean, once you're behind a NAT box, you've got a *lot* of addresses to play
>with (how many, exactly, depends on how you're doing it). This is puzzling to
>me - what configurations are there out there that demand more address space,
> From: "Perry E. Metzger" <[EMAIL PROTECTED]>
> Several layers of NAT has become common
This is have a hard time fathoming - not that I'm doubting that people do it,
mind.
I mean, I can understand it is a temporary thing, e.g. if one company buys
another, and in gluing the networks tog
At 12:37 PM 12/17/2000 -0500, J. Noel Chiappa wrote:
>It's hard to put numbers on it without knowing what %-age of sites which are
>already globally advertised has more that one prefix, and how fast that
>number is growing. However, looking at the routing table growth (it has
>doubled in about 3 y
Keith Moore writes:
| if you try to build a global network out of limited-scope addresses
| you eventually end up reinventing IP at a higher layer.
Correct, that's (some of) the point of CATNIP (RFC 1707): you construct
a network layer out of a virtual superset of the component internets'
addres
> From: Keith Moore <[EMAIL PROTECTED]>
> if you try to build a global network out of limited-scope addresses you
> eventually end up reinventing IP at a higher layer.
Err, did you perhaps mean "end up reinventing globally unique addresses
somewhere else in the system"? :-)
> The vitriol that will be poured on this is from reactionaries
> who seek to preserve the indistinction between who and where,
I don't know anyone who seeks to preserve this indistinction;
however, I know several folks who are realistic about the
difficulties of separating the two.
> and who s
At 13:32 17/12/00, Perry E. Metzger wrote:
>It is true that v6 qua v6 does not solve the route explosion
>problem. It is also true that the route explosion problem is
>a real problem. However, it doesn't make it worse, either.
From an operator perspective, supporting *2* IP protocols
is
Jon Crowcroft writes:
| anyhow, i think the old 8+8 v6 scheme would have sorted this out just
| dandilyand i dont understand the vitriol people our on it -
I don't understand alot of the vitriol, but I personally am concerned
that 8 bytes is insufficient. If there was ever a time-space trad
Keith Moore <[EMAIL PROTECTED]> writes:
> > to make v6 work tarks end users more work than v4
>
> if "v4" includes dealing with an increasingly severe shortage of
> address space (which sooner or later implies forced renumbering)
> and/or tying together multiple NATted networks, it's not at all
> From: Bradley Dunn <[EMAIL PROTECTED]>
> I do think that there is a definite causal relationship between the
> address space shortage and the number of prefixes in the routing tables.
> People who allocate addresses .. use slow-start algorithms in their
> allocation policies
> to make v6 work tarks end users more work than v4
if "v4" includes dealing with an increasingly severe shortage of
address space (which sooner or later implies forced renumbering)
and/or tying together multiple NATted networks, it's not at all
clear that this takes less work than v6.
Keith
> From: "Perry E. Metzger" <[EMAIL PROTECTED]>
> What is technically wrong with v6 that isn't already technically wrong
> with v4?
Thank you, Perry, you've put it in a nutshell.
Noel
>>I understand that there are pressures to do multihoming, but I just don't see
>>how NAT (i.e. address sharing) is having much effect one way or the other on
>>the intensity of the pressure to do multi-homing.
NATs allow users to be irresponsible about the addressing since they
dont require
In message <[EMAIL PROTECTED]>, Sean Doran typed:
>>Wait, it's because of *me* that IPv6 isn't a stunning success compared to NAT?
>
>>I didn't realize that, when I asked the IAB to use their technical insights
>>as a market predictor, that behind the invisible hand of the marketplace
>>lu
At 02:28 AM 12/17/2000 -0500, J. Noel Chiappa wrote:
>To put it another way, let's imagine an alternate reality in which IPv4 had
>48-bit addresses - enough so pretty much everyone could get as many as they
>wanted, and nobody used NAT boxes because they couldn't get enough addresses.
>Now, think
"J. Noel Chiappa" <[EMAIL PROTECTED]> writes:
> > From: "Perry E. Metzger" <[EMAIL PROTECTED]>
>
> > you're ideologically opposed to deploying v6 instead of against it for
> > technical reasons?
>
> Ah, *that's* what's wrong with IPv6 - it doesn't pay enough attention to
> control o
[EMAIL PROTECTED] (Sean Doran) writes:
> Perry Metzger writes:
>
> | Maybe because I hear from folks like you and others that you're
> | ideologically opposed to deploying v6 instead of against it for
> | technical reasons?
>
> You have never heard this from me.
>
> I have no doubt whatsoever
> From: Geoff Huston <[EMAIL PROTECTED]>
>> [NAT's] shouldn't have any effect on the *number* of [address]
>> blocks (i.e. things which can potentially produce global routing table
>> entries).
>> ... So the number of distinct "local areas" is still the same, yes?
>> And
At 12/16/00 10:02 PM -0500, J. Noel Chiappa wrote:
> > From: Geoff Huston <[EMAIL PROTECTED]>
>
> > There are strong indications that NAT is one factor behind this part of
> > the BGP table.
>
>I'm afraid I'm missing the logic here. As you point out below, NAT's may have
>caused people
the fact that IPv* doesn't distinguish between who and where does
cause some problems, but does not significantly impact the ability
to route IPv* packets. even if you free IP addresses from any kind
of role as host identity (which IMHO would be a good thing except that
nobody has produced a sa
> From: Geoff Huston <[EMAIL PROTECTED]>
> There are strong indications that NAT is one factor behind this part of
> the BGP table.
I'm afraid I'm missing the logic here. As you point out below, NAT's may have
caused people to use *smaller* blocks of the global address space:
>
I looked again. Perry Metzger still writes:
| > So, I have to wonder, why is it that they have no option?
|
| Maybe because I hear from folks like you and others that you're
| ideologically opposed to deploying v6 instead of against it for
| technical reasons?
Wait, it's because of *me* that IP
Perry Metzger writes:
| Maybe because I hear from folks like you and others that you're
| ideologically opposed to deploying v6 instead of against it for
| technical reasons?
You have never heard this from me.
I have no doubt whatsoever that you have heard this from others
speaking about me. T
> From: "Perry E. Metzger" <[EMAIL PROTECTED]>
> you're ideologically opposed to deploying v6 instead of against it for
> technical reasons?
Ah, *that's* what's wrong with IPv6 - it doesn't pay enough attention to
control of the means of production by the workers.
And here I was, al
[EMAIL PROTECTED] (Sean Doran) writes:
> I should have waited until Perry had spoken, because now that he has
> pointed out the extreme cost of NAT, I have seen the light!
>
> NATs are expensive. They have gross side-effects. Even Noel Chiappa,
> my guru, says that they are an architectural ha
> It looks like NAT's are a fact of life, and we
> just need to figure out how to deal with them.
well, that's the question after all - how best to deal with them?
I claim that NATs are architecturally bankrupt and we should therefore
devote as little energy as possible toward legitimizing NATs
> this focus on NATs seems to be an incomplete statement of the problem
a complete statement of the problem is quite difficult, especially given
that the problem can be viewed in many different ways (without any of
them being contradictory with the others), each of these views being
illuminating
> Surely the "much pain" is because, as Melinda Shore indicates,
> some "anti-NAT fanatics" cannot understand the distinction
> between "who" and "where"?
sounds like a Peter Pan theory
okay, everbody, close your eyes and try *real hard* to make believe
that you can route between networks u
> "Sean" == Sean Doran <[EMAIL PROTECTED]> writes:
Sean> I should have waited until Perry had spoken, because now that he
Sean> has pointed out the extreme cost of NAT, I have seen the light!
Sean> NATs are expensive. They have gross side-effects. Even Noel
Sean> Chiappa, m
> "Jon" == Jon Crowcroft <[EMAIL PROTECTED]> writes:
Jon> note that a major problem with the little wortk that is done is that
Jon> its not often done in realistic topologies - this is a problem with
Jon> ISPs who wont let people get at the data (or the traffic traces) so
Jon>
[mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 10:48 AM
To: 'Dave Robinson'; Keith Moore
Cc: M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: NATs *ARE* evil!
Yes! TCP breaks due to the fact that "true" source/destination sockets
cannot be defined. T
> "Scott" == Scott Bradner <[EMAIL PROTECTED]> writes:
Scott> the use of private addresses - something that a whole lot of
Scott> firewalls also do - howcum the subject line is not "NATs &
Scott> Firewalls are evil!" or "use of private addresses is evil!"?
Not all firewalls do
1 - 100 of 154 matches
Mail list logo
