Greg Skinner wrote:
The IETF might perhaps take an advocacy position for traditional Internet
service. An RFC on the order of "Full Internet Access is Good" might
sway a few people who are unaware of the wealth of services a full
provider offers. On the other hand, a provider that actually
g'day,
Masataka Ohta wrote:
. . .
If IETF makes it clear that AOL is not an ISP, it will commercially
motivate AOL to be an ISP.
Not to be unkind, since the IETF has done some good work, but the above
statement is incorrect. If you'd written "If AOL perceives that the
market would punish
The bottom line is, the world isn't waiting for us to tell them the
right way to do what they want and the clever solutions we came up with
as solutions to the networking problems of 1970, or 1980, or 1990 don't
demand that they adopt our proposals for solving their problems of 2000.
We're
Keith Moore [EMAIL PROTECTED] wrote:
the reason I say that your statement is content-free is that it offers
no specific criticism of IETF that can be used in a constructive fashion.
With respect to this particular thread, the only criticism I'd make is
I don't see how the draft in question
Wrong I'm reading it :P Leave AOL alone. There are
many FREE connections to select one can have AOL and
many other "raw" connections. Maybe we like AOL, and
that is why we pick it. AOlers also know that AOL
isnt top class but we like easy listening once in a
while :P We're not all idiots and
Wrong I'm reading it :P Leave AOL alone.
AOlers also know that AOL
isnt top class but we like easy listening once in a while
Um, I guess this isn't one of those 'whiles.'
Received: from [4.33.131.234] by web4601.mail.yahoo.com
;-)
RGF
Robert G. Ferrell, CISSP
Masataka:
If IETF makes it clear that AOL is not an ISP, it will commercially
motivate AOL to be an ISP.
Keith:
probably not. folks who subscribe to AOL aren't likely to be
reading IETF documents.
face it, it's not the superior quality of AOL's service that keeps
AOLers from moving
Masataka Ohta wrote:
If IETF makes it clear that AOL is not an ISP, it will commercially
motivate AOL to be an ISP.
Why? Certainly, they are aware that they are not an ISP by your
definition. It hasn't changed their business practices. Why would
an IETF RFC change their business practices?
If IETF makes it clear that AOL is not an ISP, it will commercially
motivate AOL to be an ISP.
probably not. folks who subscribe to AOL aren't likely to be
reading IETF documents.
face it, it's not the superior quality of AOL's service that keeps
AOLers from moving - it's their
From: Keith Moore [EMAIL PROTECTED]
...
face it, it's not the superior quality of AOL's service that keeps
AOLers from moving - it's their susceptibility to marketing BS and
their addiction to chat rooms. it's hard to help those people.
Other than latency, message size, message rate, and
The views of the author may not necessarily
reflect those of the Company.
-Original Message-
From: Randy Bush [mailto:[EMAIL PROTECTED]]
Sent: 11 July 2000 03:26
To: Keith Moore
Cc: Masataka Ohta; Jon Crowcroft; [EMAIL PROTECTED]
Subject: Re:
draft-ietf-nat-protocol-complications-02.txt
What I oppose strongly, is that people sell weird stuff and call it Internet.
I've never seen a marketing person that wouldn't lie and do exactly that.
If folks want to buy wierd stuff, and they know it's wierd stuff and
are aware of its limitations, I don't have much problem with that.
But
I don't see any problems people making money
on weird NAT-munging-weirdo-webonly-wap things
which they sell to customers
"Making money" implies that for every seller
there is a willing buyer. For NAT to have
progressed from a twinkle-in-the-eye to the
near ubiquity that it will have in a few
masataka was saying that he could classify providers given a rather fixed
model. i was saying that the world changes and that providers will find
new business models and bend masataka's rigid classification.
yes, but the desire to have classification of providers is significantly
motiviated
Bob;
* but yes, likely some things in this world are not acceptable to some
* segment of the population. so don't accept them. but life goes on and
* things change.
*
* randy
Changes are already implied by RC1958, which I refer.
As things change, new RFCs can be issued.
Randy;
My intention is to provide a semi permanent definition as an Informational
RFC.
It is important to make the definition protected by bogus opinions
of various bodies including IETF.
of course you will exuse the providers if we continue to be perverse and
find new business
Jon:
personal comment
Other classes of organisation may simply be providing a subset of
internet services - I don't see a market or technical case for these
and in fact would encourage regulatory bodies to see if these types of
organisations are trying to achieve lock out or are engaged in
Any comments on the content of the draft?
I would go further - first to define by exclusion, secondly to define
a new class of providers (according tro common uisage) so that
discussion can proceed
An ISP _hosts_ its own and customer's hosts. Hosts follow the
hosts requirements RFC, at
Jon;
Any comments on the content of the draft?
I would go further - first to define by exclusion, secondly to define
a new class of providers (according tro common uisage) so that
discussion can proceed
My intention is to provide a semi permanent definition as an Informational
RFC.
It
I would go further - first to define by exclusion, secondly to define
a new class of providers (according tro common uisage) so that
discussion can proceed
My intention is to provide a semi permanent definition as an Informational
RFC.
It is important to make the definition protected
of course you will exuse the providers if we continue to be perverse and
find new business models.
not bloody likely. some things are inexcusable. munging data in
transit is one of them. the fact that you may have a business
model that says you can make money doing something that is
Dear all;
Based on the previous discussion,
Jon In message [EMAIL PROTECTED], Masataka Ohta ty
Jon ped:
Jon
Jon Is it fair if providers using iMODE or WAP are advertised
Jon to be ISPs?
Jon
Jon Is it fair if providers using NAT are advertised to be ISPs?
Jon
Jon
Steve Deering;
Unfortunately, IPv6's current addressing architecture makes it very
difficult to do this sort of traditional multihoming if one is not
IPv6's larger address space is merely a necessary piece of an
Internet which will not run out of numbers.
Wow, we actually agree on
Vint;
that's right - they use iMODE on the DOCOMO mobiles. iMODE and
WAP seem to have that in common: a non-IP radio link protocol
and an application gateway. Of course, this limits the applications
to those that can be "translated" in the gateway, while an end to
end system (such as the
In message [EMAIL PROTECTED], Masataka Ohta ty
ped:
Is it fair if providers using iMODE or WAP are advertised
to be ISPs?
Is it fair if providers using NAT are advertised to be ISPs?
My answer to both questions is
No, while they may be Internet Service Access
Matt;
I don't know about you, but it scares me to read the various forecasts
about how wireless will transform the landscape over the next few
years. E.g., more wireless phones with internet connectivity than
PCs. The numbers are just staggering and the associated demand for
addresses will
that's right - they use iMODE on the DOCOMO mobiles. iMODE and
WAP seem to have that in common: a non-IP radio link protocol
and an application gateway. Of course, this limits the applications
to those that can be "translated" in the gateway, while an end to
end system (such as the Ricochet from
In message [EMAIL PROTECTED], "J. Noel Chiappa" typed:
right, noels wrong.
Noel is happy to wait, and see who's right. (I've been through this exact
same experience before, with CLNP, so I understand the life-cycle.) So far,
I've been waiting for quite a few years with IPv6, and so
PROTECTED]
Subject:Re:
draft-ietf-nat-protocol-complications-02.txt
From: "Steven M. Bellovin" [EMAIL PROTECTED]
...
There is some data indicating that Keith is right, that
there are problems in
the
From: "BookIII, Robert" [EMAIL PROTECTED]
...
save for a couple of auto-responses from NTMail in the name of
...
but have started up again. Does anyone know how I could go about addressing
this? Thanks for your time and consideration.
You can expect at least 3 and usually several more
From: Keith Moore [EMAIL PROTECTED]
You appear to be saying that because historically people screwed up
configuring their DNS that it is impossible to rely on the DNS for
critical infrastructure.
I wouldn't say 'impossible'. My point is that it is more difficult to
From: Bill Manning [EMAIL PROTECTED]
So, of the 7763 visable servers, 45 are improperly configured in the
visable US. tree. Thats 4.53% of those servers being "not well
maintained.
Keith, These two data points seem to bear your assertion out.
It is always possible to do something poorly.
In his previous mail, Thomas Narten writes:
Now, consider someone in the process of deploying massive numbers of
devices (100's of millions) together with the infrastructure to
support them (e.g., wireless). With IPv4, they face not only the
necessity of using NAT to get to outside
right, noels wrong.
Noel is happy to wait, and see who's right. (I've been through this exact
same experience before, with CLNP, so I understand the life-cycle.) So far,
I've been waiting for quite a few years with IPv6, and so far I'm right.
Let's see, how many years have these standards
Keith,
even the DNS names for major services may not be well maintained.
at one time I did a survey of the reasons for mail bounces
for one of my larger mailing lists.
You appear to be saying that because historically people screwed up
configuring their DNS that it is impossible to rely on
even the DNS names for major services may not be well maintained.
at one time I did a survey of the reasons for mail bounces
for one of my larger mailing lists.
You appear to be saying that because historically people screwed up
configuring their DNS that it is impossible to rely on
From: Keith Moore [EMAIL PROTECTED]
...
(email errors are usually detected by the sender of a message, since
that's who gets the bounced message. but the party who has responsibility
for fixing the error is usually not on the sender's end of things)
...
It may be irrelevant, and my
At 2:42 PM -0700 4/26/00, David R. Conrad wrote:
Perhaps it is obvious to you, however it has been implied that one of the
advantages of v6 is that it has a limited number of TLAs which would be found
the the DFZ of the v6 Internet.
The truth is subtly different than what what was implied or
In message [EMAIL PROTECTED], Vernon Schryver writes
It may be irrelevant, and my personal sample size is trivially tiny. ...
In recent months very little email I've sent was bounced due to DNS errors
and only a little more has been delayed. My logs say the delivery of much
more from others to
From: "Steven M. Bellovin" [EMAIL PROTECTED]
...
There is some data indicating that Keith is right, that there are problems in
the DNS. See, for example, http://www.research.att.com/~edith/Papers/infocom2000.ps
I don't think I understand the connection between that paper about
even if you do this the end system identifier needs to be globally
scoped, and you need to be able to use the end system identifier
from anywhere in the net, as a means to reach that end system.
DNS is a bright and successfull example of such deal.
actually, DNS is slow, unreliable, and
Sean Doran [EMAIL PROTECTED] writes:
Unfortunately, IPv6's current addressing architecture makes it very
difficult to do this sort of traditional multihoming if one is not
a TLA.
This is not true. IPv6's TLA scheme has as its primary goal placing an
upper bound on the number of routing
% even if you do this the end system identifier needs to be globally
% scoped, and you need to be able to use the end system identifier
% from anywhere in the net, as a means to reach that end system.
%
%DNS is a bright and successfull example of such deal.
%
% actually, DNS is slow,
%
% Sean Doran [EMAIL PROTECTED] writes:
%
% Unfortunately, IPv6's current addressing architecture makes it very
% difficult to do this sort of traditional multihoming if one is not
% a TLA.
%
% This is not true. IPv6's TLA scheme has as its primary goal placing an
% upper bound on the
Thomas,
This is not true. IPv6's TLA scheme has as its primary goal placing an
upper bound on the number of routing prefixes that are needed in the
core.
...
Contrast that with today's IPv4 where the number of
prefixes that need to be maintained in the DFZ in order to have global
At 8:48 AM -0700 4/25/00, Bill Manning wrote:
and this is different from only carrying the 253 usable /8 prefixes in
IPv4 how?
The set of customers who have addresses under a given IPv4 /8 prefix greater
than 127 do not all aggregate into a single topological subregion (e.g., a
single ISP), and
On Tue, 25 Apr 2000 08:18:20 PDT, Bill Manning said:
The 2q2000 data for the in-addr tree shows 77402 unique
servers answering for 693,337 zones.
19515 servers blocked/refused data. Of the 57887 that
answered, these are the numbers for improper configuration:
% even if you do this the end system identifier needs to be globally
% scoped, and you need to be able to use the end system identifier
% from anywhere in the net, as a means to reach that end system.
%
%DNS is a bright and successfull example of such deal.
%
% actually, DNS is
From: Brian Lloyd [EMAIL PROTECTED]
I was thinking about your message, and something from my exchanges with Keith
Moore suddenly popped into my head with great clarity. I think it's the
answer to your question immediately below - and it has some very grave
consequences.
Although it's
From: Keith Moore [EMAIL PROTECTED]
even if you do this the end system identifier needs to be globally
scoped, and you need to be able to use the end system identifier
from anywhere in the net, as a means to reach that end system.
DNS is a bright and successfull example of such deal.
At 10:22 AM -0700 4/25/00, Bill Manning wrote:
Given the nature of trans-oceanic b/w vs. local b/w arguments I've heard
over the years, I'd say that these delegations are esentially constrained
to topological subregions and that for the most part, having the largest
incumbent ISPs in each region
%
% So, of the 57,887 visable servers, 4314 are improperly configured
% in the visable in-addr.arpa. tree. Thats 7.45% of the
% servers being "not well maintained".
%
% a 92.55% reliability rate is not exactly impressive, at least not in
% a favorable sense.
%
% it
At 11:16 AM -0700 4/25/00, Bill Manning wrote:
And why do you think that the ISP community and others will not
meet the IPv6 routing proposal with anything less than the
"hostility and derision" that came from the previous attempts
to impose "topological constraints
Now, if you have a site which has more hosts than it can get external IPv4
addresses for, then as long as there are considerable numbers of IPv4 hosts a
site needs to interoperate with, *deploying IPv6 internally to the site does
the site basically no good at all*. Why?
this sounds like a
Keith,
a 92.55% reliability rate is not exactly impressive, at least not in
a favorable sense.
it might be tolerable if a failure of the PTR lookup doesn't cause
the application to fail.
If people's livelihood depends on something, they're more likely to insure it
actually works. Very
If people's livelihood depends on something, they're more likely to insure
it actually works.
that's a good point. but it's one thing to make sure that DNS mappings
for "major" services are correct, and quite another to make sure that
the DNS mappings are correct in both directions for
From: Keith Moore [EMAIL PROTECTED]
IPv6's claimed big advantage - a bigger address space - turns out not to be an
advantage at all - at least in any stage much short of completely deployment.
IPv6 deployment is going to have to be driven by IPv6's *other* features, and
when you take
Sean Doran [EMAIL PROTECTED] writes:
Unfortunately, IPv6's current addressing architecture makes it very
difficult to do this sort of traditional multihoming if one is not
a TLA.
This is not true. IPv6's TLA scheme has as its primary goal placing an
upper bound on the
IPv6's claimed big advantage - a bigger address space - turns out not to be an
advantage at all - at least in any stage much short of completely deployment.
that's an exaggeration. if you have an app that needs IPv6, you don't
need complete deployment of IPv6 throughout the whole network to
On Tue, 25 Apr 2000, J. Noel Chiappa wrote:
From: Brian Lloyd [EMAIL PROTECTED]
I was thinking about your message, and something from my exchanges
with Keith Moore suddenly popped into my head with great clarity. I
think it's the answer to your question immediately below - and it has
From: Keith Moore [EMAIL PROTECTED]
I don't see what you're getting at. the outside sites may be running v4
with a limited number of external addresses ... if they are running v6
they will have plenty of external addresses.
Not external *IPv4* addresses, they won't - which
I don't see what you're getting at. the outside sites may be running v4
with a limited number of external addresses ... if they are running v6
they will have plenty of external addresses.
Not external *IPv4* addresses, they won't - which is what kind of addresses
they need
On Tue, 25 Apr 2000 12:19:49 PDT, "David R. Conrad" said:
If it "isn't very good", try using the Internet without it for a bit.
In your view, what is it in the DNS protocol(s) that results in a lack of
reliability?
Actually, in my experience, the protocol isn't the biggest problem. To
On Tue, 25 Apr 2000, David R. Conrad wrote:
Keith,
a 92.55% reliability rate is not exactly impressive, at least not in
a favorable sense.
it might be tolerable if a failure of the PTR lookup doesn't cause
the application to fail.
If people's livelihood depends on something,
Paul Francis wrote:
Sean said that traditional multihoming would be "very difficult".
You replied that "This is not true" (which I take to mean
that multihoming is not very difficult), and then go on to describe
something that sounds very difficult to me (maintain longer prefixes,
make
I think there are interesting things happening in DNS. I wrote a not very
good paper for AUUG a few years back noting an error rate in DNS above 10%
for the mirror site I do stats on.
Reviewing the figures for yesterday I get 9.75% unresolvable which is pretty
close to Bill Mannings figure.
From: Keith Moore [EMAIL PROTECTED]
If people's livelihood depends on something, they're more likely to insure
it actually works.
that's a good point. but it's one thing to make sure that DNS mappings
for "major" services are correct, and quite another to make sure that
the DNS mappings are
On Tue, 25 Apr 2000 08:18:20 PDT, Bill Manning said:
The 2q2000 data for the in-addr tree shows 77402 unique
servers answering for 693,337 zones.
19515 servers blocked/refused data. Of the 57887 that
answered, these are the numbers for improper configuration:
[Keith Moore on a "KMart box"]
| take it home, plug it in to your phone line or whatever, and get
| instant internet for all of the computers in your home.
| (almost just like NATs today except that you get static IP addresses).
No, not "or whatever" but "AND whatever".
Otherwise this is a
--- Henning Schulzrinne [EMAIL PROTECTED] wrote:
It might be useful to point out more clearly the common characteristics
of protocols that are broken by NATs. These include, in particular,
protocols that use one connection to establish another data flow. Such
protocols include ftp, SIP and
At 4:32 PM +0200 4/24/00, Sean Doran wrote:
Unfortunately, IPv6's current addressing architecture makes it very
difficult to do this sort of traditional multihoming if one is not
a TLA. This is a significant step backward from the current IPv4
situation, where one can persuade various operators
[Keith Moore on a "KMart box"]
| take it home, plug it in to your phone line or whatever, and get
| instant internet for all of the computers in your home.
| (almost just like NATs today except that you get static IP addresses).
No, not "or whatever" but "AND whatever".
Otherwise this
Keith Moore wrote:
it's not at all clear to me why households need traditional multihoming,
nor how to make it feasible for households to have it. so I would regard
this as overdesign of the home 'internet interface box'
Now that I've got a decent DSL provider, I've found that the least
| it's not at all clear to me why households need traditional multihoming,
| nor how to make it feasible for households to have it. so I would regard
| this as overdesign of the home 'internet interface box'
Three observations:
1.
In the past, when and if large arrogant
Date: Mon, 24 Apr 2000 15:06:21 -0400
From: John Stracke [EMAIL PROTECTED]
it's not at all clear to me why households need traditional multihoming,
nor how to make it feasible for households to have it. so I would regard
this as overdesign of the home 'internet interface box'
Sean;
[Keith Moore on a "KMart box"]
| take it home, plug it in to your phone line or whatever, and get
| instant internet for all of the computers in your home.
| (almost just like NATs today except that you get static IP addresses).
No, not "or whatever" but "AND whatever".
Do you
On Mon, Apr 24, 2000 at 04:32:38PM +0200, Sean Doran wrote:
Therefore, in order to support IPv6 house-network multihoming, so
as to preserve at least these three features of traditional
multihoming, either the current IPv6 addressing architecture's
restrictions on who can be a TLA must be
At 08:27 PM 04/24/2000 -0400, Andrew Partan wrote:
Or seperate the end system identifer from the routing goop. This
solves lots of problems (while introducing others).
Deja Vu.
- paul
asp writes:
| Or seperate the end system identifer from the routing goop. This
| solves lots of problems (while introducing others).
Right, so in the 8+8 model, some router performs a NAT function by
writing in the routing goop portion at an address abstraction boundary.
The host does not
The problem is not NAT's. The problem is why people have to use
NAT's...they can't get the numbers they need or want, in large measure, due
to the greed of ISP's.
That is a huge generalisation. The ISP I work for offers customers as
many IP numbers as they can justify and at no
they can't get the numbers they need or want, in large measure, due
to the greed of ISPs.
Rather than demonizing ISPs, it's more worthwhile to take
some time to stand in their shoes. Back in the mid '90s,
we faced these same issues in provisioning of small office/home
offices. It was generally
henning,
good stuff...
people would do well to read this -
also, all attempts to fix NATs so as to ameliorate these problems
have _exactly_ the same deployment complexity as IPv6 - there's a
quote somewhere from yakov rehkter to this effect (can't find it
exactly, but he was coming the ther
At 02:10 PM 4/22/00, Keith Moore wrote:
Look, I have on my disk a file from June, 1992 (yes, that's not a typo -
*1992*) called "Problems with NAT".
This is probably a naive viewpoint but I have always viewed NAT as a hack
that would allow us to continue to use 32bit addresses until we
Bernard Aboba writes:
Rather than demonizing ISPs, it's more worthwhile to take
some time to stand in their shoes. Back in the mid '90s,
we faced these same issues in provisioning of small office/home
offices. It was generally much easier (and less expensive from
an administrative point of
Most users are not
networking geeks. They like NAT because NAT boxes make what they want
to do so easy.
presumably they don't realize that the NATs are making it hard
to do other things that they might want to do.
I wonder...how many of these folks really want network address
translation,
Most users are not networking geeks. They like NAT because NAT boxes
make what they want to do so easy.
presumably they don't realize that the NATs are making it hard
to do other things that they might want to do.
I wonder...how many of these folks really want network address
Most users are not
networking geeks. They like NAT because NAT boxes make what they want
to do so easy.
presumably they don't realize that the NATs are making it hard
to do other things that they might want to do.
I wonder...how many of these folks really want network address
At 11:50 PM 4/22/2000 -0400, vinton g. cerf wrote:
big smile - vBNS+ is running IPv6 on a commercial basis. I'd be more than
interested in
your opinion of a sensible (acceptable) policy on the minimum size of IPv6
space one might expect
to allocate to customers.
Vint
Well that is a very
Noel;
From: Keith Moore [EMAIL PROTECTED]
there are far too many problems to NAT, affecting far too many
applications ... and the list is constantly growing larger.
Perhaps if there was a document that explained how to design an application
so that it worked through a NAT
--- Jeffrey Altman [EMAIL PROTECTED] wrote:
I have so many issues with this reply that I am only going to focus on
one.
Agreed. How do you expect the intruders will steal the tickets, without
being recipients of the ticket? Unless, you are assuming that the private
network is not
Date: Sat, 22 Apr 2000 05:48:36 -0400
From: "J. Noel Chiappa" [EMAIL PROTECTED]
there are far too many problems to NAT, affecting far too many
applications ... and the list is constantly growing larger.
Perhaps if there was a document that explained how to design an
It might be useful to point out more clearly the common characteristics
of protocols that are broken by NATs. These include, in particular,
protocols that use one connection to establish another data flow. Such
protocols include ftp, SIP and RTSP (the latter is not mentioned yet in
the draft, but
Look, I have on my disk a file from June, 1992 (yes, that's not a typo -
*1992*) called "Problems with NAT".
However, as a close personal friend of the patron saint of Lost Causes (see
all the scars on my forehead? :-), let me tell you that I have (painfully :-)
learned to recognize a lost
Date: Sat, 22 Apr 2000 05:48:36 -0400
From: "J. Noel Chiappa" [EMAIL PROTECTED]
there are far too many problems to NAT, affecting far too many
applications ... and the list is constantly growing larger.
Perhaps if there was a document that explained how to design
and just because I'm arguing against the above kinds of statements doesn't
mean that I think we can convince folks to just discard their NATs. I do
however think that folks may be willing to upgrade and/or replace their
NATs once something better exists that allows them to run applications
Richard,
I'm not entirely pleased with the current policies for address assignment,
nor with the pricing policies of certain ISPs for access for more than
one IP address. However, I'm convinced that even with improvements to
these policies, IPv4 address exhaustion would still be a major
big smile - vBNS+ is running IPv6 on a commercial basis. I'd be more than interested in
your opinion of a sensible (acceptable) policy on the minimum size of IPv6 space one
might expect
to allocate to customers.
Vint
At 09:08 PM 4/22/2000 -0500, Richard Shockey wrote:
And yes I have a credit
In Kerberos 4, when the KDC receives a ticket request, it includes the
source IP address in the returned ticket. This works fine if the KDC
is across a NAT gateway, as long as all of the Kerberos services are
also across a NAT gateway.
doesn't this require the NAT to use the same
doesn't this require the NAT to use the same inside-outside address
binding for the connection between the client and the KDC as for
the connection between the client and the application server?
e.g. it seems like the NAT could easily change address bindings
during the lifetime of a ticket.
doesn't this require the NAT to use the same inside-outside
address binding for the connection between the client and the KDC as
for the connection between the client and the application server?
e.g. it seems like the NAT could easily change address bindings
during the lifetime of a ticket.
1 - 100 of 109 matches
Mail list logo
