> Well, NAPSTER comes pretty close. Two peers can exchange files if at
> least one of them can act as a server, i.e. is not blocked by a NAT. If
> both are behind NAT, they can't. The point being, NAT are only
> transparent if the host behind a NAT acts as a "client", and initiates
> the TCP conne
> If a compelling application comes along that is NAT-hostile, that
> will be interesting, but I can't imagine it's in anyone's interest
> to provoke such a conflict when there are well-known NAT-friendly
> ways of replacing embedded IP addresses in most higher-level protocols
> that use them...
At 11:52 AM 1/23/2001 +, Jon Crowcroft wrote:
>o'dell's GSE draft addressed renumbering perfectly.
And look how far it got.
Rgds,
-drc
> - I did not say the DNS is not useful. I said it has design flaws, and
> I named some of them. These flaws are examples of what NOT to do
> with IP.
DNS does have design flaws, but I don't think you've identified any of them.
> - A service that maps names of local resources to distant addres
Keith Moore wrote:
> Ed,
>
> without getting too long-winded
me too :-)
- I did not say the DNS is not useful. I said it has design flaws, and
I named some of them. These flaws are examples of what NOT to do
with IP.
- A service that maps names of local resources to distant addresses
is
Ed,
>
>
>Perhaps we agree that DNS names depend on IP numbers as part of their trusted
>context, but IP numbers do not depend on DNS names.
>
>However, certain design choices in the evolution of the DNS,
>since long ago, have made users fully dependent on the DNS for
>certain critical Internet se
Ed,
without getting too long-winded
- I think you're overstating the degree to which the Internet
protocols depend on DNS (with the notable exception of NATs
that use DNS ALG to fake things out). Users who aren't
behind NATs can still use IP addresses directly if they want to,
and mor
Keith Moore wrote:
> > > But you missed the point I was trying to make. in those days, the inability
> > > of the mail network (or at least parts of it) to support a single global
> > > address space was correctly recognized as a deficiency in the network -
> > > and people took action to solve
> > There was even an analogy to NAT's "addresses embedded in the application data
> > stream" problem: if you had an address in your .signature, the gateway couldn't
> > translate it, so the person receiving your message saw an address they couldn't
> > use.
> I liked even better the horror stor
o'dell's GSE draft addressed renumbering perfectly.
In message <5.0.2.1.2.20010123015631.02bbba30@localhost>, "David R. Conrad" typ
ed:
>>Kyle,
>>
>>At 03:53 AM 1/23/2001 -0500, Kyle Lussier wrote:
>>>It is a horried idea to start setting up NATs on cell phones,
>>
>>Hmm. We should proba
Kyle,
At 03:53 AM 1/23/2001 -0500, Kyle Lussier wrote:
>It is a horried idea to start setting up NATs on cell phones,
Hmm. We should probably tell that to the existing 17+ million users of
i-Mode in Japan. Better hurry as i-Mode is moving into Europe.
>(I liked the ip addressible coffee mach
> It is time IMO for some at the IETF to stop pretending that the
> Internet can made into a
> homogeneous network. It wasn't and it won't.
Ip address space will continues to tighten, exponentially increasing
the pain of dealing with such a small number of IPs. Then throw 200
million cell
> > But you missed the point I was trying to make. in those days, the inability
> > of the mail network (or at least parts of it) to support a single global
> > address space was correctly recognized as a deficiency in the network -
> > and people took action to solve the problem (notably deployng
Keith Moore wrote:
> > | at least in those days, gateway proponents didn't insist that people
> > | shouldn't include email addresses in the bodies of their messages.
> >
> > You miss the point that including "GRECO::MARYK" as an email address
> > in a USENET message is about as useful as inclu
> | Nowadays people often act as if NATs were the way the Internet was supposed
> | to work, and that it's the applications and the users of those applications
> | who are broken if they want a network that supports a global address space.
>
> Well, the genie is out of the bottle, and if NAT is w
On Tue, 23 Jan 2001 01:11:12 +0100, Harald Alvestrand <[EMAIL PROTECTED]> said:
> I liked even better the horror story of the gateway that tried.
> until someone wrote "this gateway translates [EMAIL PROTECTED] into
> [EMAIL PROTECTED]", and it came out to the recipient as
> "this gateway tr
At 12:42 22/01/2001 -0500, John Stracke wrote:
>There was even an analogy to NAT's "addresses embedded in the application data
>stream" problem: if you had an address in your .signature, the gateway
>couldn't
>translate it, so the person receiving your message saw an address they
>couldn't
>use.
| Nowadays people often act as if NATs were the way the Internet was supposed
| to work, and that it's the applications and the users of those applications
| who are broken if they want a network that supports a global address space.
Well, the genie is out of the bottle, and if NAT is winning
Valdis Kletnieks writes:
| On Mon, 22 Jan 2001 23:53:30 +0100, Sean Doran said:
| > Nobody really constrains protocols from carrying a local IP address
| > around any more than anyone constrains from putting local addresses
| > into a text message. It's just that communicating by naively replyin
On Mon, 22 Jan 2001 23:53:30 +0100, Sean Doran said:
> Nobody really constrains protocols from carrying a local IP address
> around any more than anyone constrains from putting local addresses
> into a text message. It's just that communicating by naively replying
> to such an embedded address i
> | at least in those days, gateway proponents didn't insist that people
> | shouldn't include email addresses in the bodies of their messages.
>
> You miss the point that including "GRECO::MARYK" as an email address
> in a USENET message is about as useful as including 10.0.0.26 in an
> IP heade
Keith Moore writes:
| at least in those days, gateway proponents didn't insist that people
| shouldn't include email addresses in the bodies of their messages.
You miss the point that including "GRECO::MARYK" as an email address
in a USENET message is about as useful as including 10.0.0.26 in an
> > I remember when the email
> > network was a heterogeneous network consisting of UUCP, BITNET, DECnet,
> > SMTP, X.400, and a few other things thrown in. It "worked", sort of,
> > but we had all kinds of problems with the translations at the boundaries,
> > with addresses from one network leak
At 08:53 AM 1/22/2001, Henning G. Schulzrinne wrote:
>Brian E Carpenter wrote:
> > The ISOC isn't a trade association, which is where such seals
> > of approval (and the associated b*ke-offs) tend to come from.
>
>Maybe the IPv6 consortium or whatever they call themselves could do
>this, since IPv
Keith Moore wrote:
> I remember when the email
> network was a heterogeneous network consisting of UUCP, BITNET, DECnet,
> SMTP, X.400, and a few other things thrown in. It "worked", sort of,
> but we had all kinds of problems with the translations at the boundaries,
> with addresses from one ne
Brian E Carpenter wrote:
>
> > - without "transparent" caches
>
> Do you mean interception proxies, in WREC terminology?
Yes.
>
> > - no port restrictions
>
> And no protocol type restrictions
>
> > - no NATs
>
> How about adding IPv6 support?
Good idea.
> >
> > (and whatever other abom
Henning Schulzrinne wrote:
...
> However, I think it's high time to establish a "Good Housekeeping" seal
> for "real" (pure, unadultared, GM-free, ...) Internet service, i.e.,
>
> - without "transparent" caches
Do you mean interception proxies, in WREC terminology?
> - no port restrictions
An
Keith Moore wrote:
>
> > The IETF has done it's job with 6to4, but like you said we can't force
> > people to deploy it. But let's stop and think about 6to4. Aren't some of
> > the same "tricks" or ALG's that are planned to make applications work
> > with IPv4 NAT, applicable to 6to4? If so, then
Joel Jaeggli wrote:
>
> you might check out the rather sprited discussion during the plenary at
> ietf49...
>
> the official proceeding will be up shortly on the ietf website, video of
> the event is at:
>
> http://videolab.uoregon.edu/events/ietf/ietf49.html
What can be heard on the audio (so
In message <[EMAIL PROTECTED]>, Keith Moore typed:
>>> The IETF has done it's job with 6to4, but like you said we can't force
>>> people to deploy it. But let's stop and think about 6to4. Aren't some of
>>> the same "tricks" or ALG's that are planned to make applications work
>>> with IPv4
> The IETF has done it's job with 6to4, but like you said we can't force
> people to deploy it. But let's stop and think about 6to4. Aren't some of
> the same "tricks" or ALG's that are planned to make applications work
> with IPv4 NAT, applicable to 6to4? If so, then we must find solutions
> no
Perhaps there is a difference with the Nynex/BA side of Verizon and the GTE
part. The GTE part uses 4.x.x.x which it got from a previous acquisition.
At 07:05 PM 1/21/2001, Henning Schulzrinne wrote:
>Before handing out awards: one of my colleagues here, living in
>Westchester County, got a nice
Before handing out awards: one of my colleagues here, living in
Westchester County, got a nice 10.x.x.x address (net A alright...) and
couldn't figure out why Exceed wasn't working.
However, I think it's high time to establish a "Good Housekeeping" seal
for "real" (pure, unadultared, GM-free, ...
At 11:47 AM 1/21/2001, Daniel Senie wrote:
>[EMAIL PROTECTED] wrote:
>
> > Let's stamp out NAT, *now* - before it becomes too entrenched and we can
> > never get rid of it. We don't need that sort of "worked" again.
>
>Ummm, it's FAR too late for that. As for numbers of users, it's my guess
>a la
At 05:39 PM 1/21/2001, Keith Moore wrote:
> > >NAT is an architecturally bankrupt strategy - the more you try to fix
> > >it, the more complex the architecture becomes, the harder it becomes to
> > >write and configure applications, and the the more brittle the network
> > >becomes. There is no w
> >By all means, let's deal with NAT. Let's find better solutions to the
> >problems that NAT purports to solve - solutions that don't create the
> >plethora of additional problems that inherently come with NATs.
>
> The only true solution is to not use NAT. Yet it is still being heavily
> deplo
[EMAIL PROTECTED] wrote:
> Let's stamp out NAT, *now* - before it becomes too entrenched and we can
> never get rid of it. We don't need that sort of "worked" again.
Ummm, it's FAR too late for that. As for numbers of users, it's my guess
a large percentage of the cable modem users and DSL user
At 11:53 PM 1/20/2001, Keith Moore wrote:
> > But complaining about NAT is not a new fad and usage of NAT hasn't been
> > stemmed the tiniest bit. We can't keep burying our heads in the sand and
> > trying to deny new work on dealing with NAT. It's here, it isn't going away
> > and we have to find
you might check out the rather sprited discussion during the plenary at
ietf49...
the official proceeding will be up shortly on the ietf website, video of
the event is at:
http://videolab.uoregon.edu/events/ietf/ietf49.html
joelja
On Sat, 20 Jan 2001, Jiri Kuthan wrote:
> Hello,
>
> is anyone
On Sun, 21 Jan 2001 02:22:43 EST, Keith Moore said:
> it is desirable that it be such a network. I remember when the email
> network was a heterogeneous network consisting of UUCP, BITNET, DECnet,
> SMTP, X.400, and a few other things thrown in. It "worked", sort of,
> but we had all kinds of
> But complaining about NAT is not a new fad and usage of NAT hasn't been
> stemmed the tiniest bit. We can't keep burying our heads in the sand and
> trying to deny new work on dealing with NAT. It's here, it isn't going away
> and we have to find solutions for applications that need to deal with
> simply put and well stated..but I do suspect that the current NAT problem
> can be solved by the proper deployment of applications that MUST have
> routeable addresses.
no, it's the other way around. the existence of NATs is keeping those
applications from being widely deployed.
Keith
Not the best estimate but looking at the number of unique
addresses that hit&fail the public nameservers for RFC 1918
space does show some interesting trends. A snapshot was presented
at NANOG some few meetings back. I've got the data for the last few
years.
--bill
> Technically, a NAT box is used to interconnect two (or more) independent
> networks so that hosts in the networks can communicate with one another
> *without any change* to the respective networks,
except that in reality this is completely false.
- the two networks can only "communicate" in
There are two somewhat separable issues:
- Unless you only want to make outbound calls, SIP user agents have to
be "servers" as well as "clients". Without per-application hacks, NATs
don't work with inbound connections, so SIP gets bitten by that. (There
are kludges around that, such as a permane
On Sat, 20 Jan 2001 21:32:35 EST, Richard Shockey said:
> The Net as we know is has always been application driven. SMTP, HTTP, FTP
> etc. These applications can transverse NAT's but real forms of streaming
> media cannot.
OK.. I'll admit that streaming stuff isn't my strong point, and I'm down
At 05:16 PM 1/20/2001 -0500, vint cerf wrote:
>a nightmare it seems to me
simply put and well stated..but I do suspect that the current NAT problem
can be solved by the proper deployment of applications that MUST have
routeable addresses. SIP being a case in point. The promise of SIP is a
glob
At 02:38 PM 1/20/2001, Jim McMurry wrote:
>Then it seems we will have to create an ever expanding bandwidth to support
>all the overhead associated with NAT and these multiple layers.
The overhead comes in the form of complexity rather than bandwidth.
But complaining about NAT is not a new fad a
> Then it seems we will have to create an ever expanding bandwidth to support
> all the overhead associated with NAT and these multiple layers.
bandwidth consumption is the least of the problems.
actually NATs probably conserve bandwidth because they prevent many kinds
of new applications from
"Bernard D. Aboba" wrote:
> And of course, as the address space continues to run out it is likely
> that enterprise and perhaps even ISP NAT deployment will increase
> substantially over the next few years.
>
> What is worth thinking about is what this will imply for the future
> internet archi
> From: "Jim McMurry" <[EMAIL PROTECTED]>
> Then it seems we will have to create an ever expanding bandwidth to
> support all the overhead associated with NAT and these multiple layers.
> If not we could wind up with OC-192's that feel like 56k modems :(
I'm kind of confused. Per
AIL PROTECTED]>
To: "Bernard D. Aboba" <[EMAIL PROTECTED]>
Cc: "Jiri Kuthan" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, January 20, 2001 2:16 PM
Subject: RE: Number of Firewall/NAT Users
> a nightmare it seems to me
>
> v
>
> At 0
a nightmare it seems to me
v
At 02:39 PM 1/20/2001 -0800, Bernard D. Aboba wrote:
>What is worth thinking about is what this will imply for the future
>internet architecture. It is one thing to address issues brought up by a
>single well functioning NAT within the same administrative domain. I
> what about business users, bernard?
>
> vint
>
My understanding is that the fraction of enterprises deploying NAT is
much larger than in consumer households. Almost all commercial firewall
products now support NAT. In comparison, fewer firewall products support
competing approaches (such
what about business users, bernard?
vint
At 06:47 AM 1/20/2001 -0800, Bernard Aboba wrote:
>The fraction of consumer users behind NATs is largely
>limited by the number of multiple PC households. As
>of 2000, my understanding is that 27 percent of
>households have multiple PCs. Of those househol
The fraction of consumer users behind NATs is largely
limited by the number of multiple PC households. As
of 2000, my understanding is that 27 percent of
households have multiple PCs. Of those households
with multiple PCs, only a fraction are networked.
This would indicate that perhaps less than
56 matches
Mail list logo
