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 actua
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
> 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'
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 t
0 16:02
To: Greg Skinner; [EMAIL PROTECTED]
Subject: Re:
draft-ietf-nat-protocol-complications-02.txt
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.
>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
==
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 a
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
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 mo
Keith;
> > 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.
AOL will be motivated but, considering other factors, may not
change the current practice.
> From: Keith Moore <[EMAIL PROTECTED]>
> ...
> > Other than latency, message size, message rate, and the number of
> > participants, what is the difference between an AOL chat room and this
> > mailing list as exemplified by this thread?
>
> why, the participants, of course.
>
> once people move
> -Original Message-
> From: Masataka Ohta [mailto:[EMAIL PROTECTED]]
>
>
> If IETF makes it clear that AOL is not an ISP, it will commercially
> motivate AOL to be an ISP.
Oh really - it is that simple!
Guess who is better known in masses - IETF or AOL :-).
Cheers,
--brijesh
Ennov
> Other than latency, message size, message rate, and the number of
> participants, what is the difference between an AOL chat room and this
> mailing list as exemplified by this thread?
why, the participants, of course.
once people move into chat rooms and make acquaintances there, they
become
> 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 rat
> 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 susceptibi
Aboba;
> >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 th
Greg;
> I could make the argument that they provide Internet access, in the
> sense that one can use these providers to gain access to a subset of
> content and services that is "traditionally" called Internet service.
> I would support them being classified as Internet Access Providers
> (IAPs).
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
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
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 issu
> 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
motiviat
*>
*> 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
*>
*>
Resist entropy.
Bob Braden
>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
ers.
From: Randy Bush <[EMAIL PROTECTED]>
To: Masataka Ohta <[EMAIL PROTECTED]>
Cc: Jon Crowcroft <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: draft-ietf-nat-protocol-complications-02.txt
Date: Mon, 10 Jul 2000 06:35:47 -0700
>> I would go fur
> 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'v
e 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
&g
>> 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
At 21.43 -0400 00-07-10, Keith Moore wrote:
>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 inexcusable
>is not a justification for doing that thing.
I do
> 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 inexcu
>> 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 p
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
RF
>>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 l
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
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 agr
Masataka Ohta wrote:
> > i-mode uses native
> > http servers with some relatively transparent html
> > extensions for handsets (such as http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=|
|eCal Corp. |"If nobody believes what I say,
Robert;
> WAP and i-mode are *very* different.
FTP and SMTP are *very* different, because SMTP is a lot easier to
pass application/transport gateways.
However, the question of whether it is IP or not is enough to dismiss
iMODE and WAP.
The battle has been and still is fought between the end to
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 S
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 th
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 M
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
> >addres
>
> >> 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
> > get this to work we
> 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 difficul
> 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
To: [EMAIL 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, th
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
> 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
"Prefe
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 oth
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 t
> 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
> So one of IPv6's multihoming approaches is no worse than IPv4,
> while another appears to be significantly better.
...in terms of its impact on the routing system. it's not clear
that having multiple addresses per host is significantly better
for applications in general.
my guess is that so
> > 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 re
Steve,
> I interpreted Bill's question as how would this be different
> than limiting IPv4 prefix advertisements to only /8s *today*, i.e., without
> renumbering the IPv4 Internet, so I answered accordingly. I didn't think
> to interpret the question the way you did, because the answer is so obv
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 o
> Date: Wed, 26 Apr 2000 14:31:23 -0400
> From: "J. Noel Chiappa" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: draft-ietf-nat-protocol-complications-02.txt
>
> Noel is happy to wait, and see who's right. (I've been through this exa
> 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
> architecture. That accusation is false, and nothing in IPv6 prevents
> the use of the same, lousy multihoming solution we have today for IPv4.
Just for the record, I was *not* suggesting that IPv4 solves the
multihoming problem (I said nothing about it one way or the other).
I understand th
Thomas,
I think you're actually both right.
Noel's comment was meant as a general case for even a very large
enterprise. You provided a counterexample of some number of providers that
will need huge amounts of address space. Much as I dislike NAT I believe
it's an unproven assertion that those
>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 be asto
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
Thomas Narten writes:
| The point of the IPv6 addressing architecture is to make that
| sort of multihoming a _possibility_ and an _optimization_ rather
| than a _requirement_.
In a purely technical sense, redundancy of any sort is
an _optimization_ rather than a _requirement_. There
is absolu
> | 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.
> It scares me how much people buy into hype.
If only 10% of the hype is true, I'm still scared. Will it be celluar
phones? Maybe, maybe not
In message <[EMAIL PROTECTED]>, Thomas Narten typed:
>>> 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.
>>Not surprisingly, I disagree.
right, noels wrong.
the amount of
Thomas Narten writes:
| 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.
It scares me how much people buy into hype.
I seem to recall reading forecasts about many bright shiny trendy
things would
> Sean said that traditional multihoming would be "very difficult".
Actually, Sean's statement was that "IPv6's current addressing
architecture" makes multihoming very difficult, and that is the point
that is untrue.
> You replied that "This is not true" (which I take to mean
> that multihoming
> 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.
Not surprisingly, I disagree.
> Here's why:
> >> if you have a site which has more hosts than it can get external IPv4
> >>
Steve Deering writes:
| Sheesh -- we get flamed for trying to impose a limit on the number of TLAs
| and we get flamed for the possibility that the number TLAs might not be
| limited...
The salient point here is that the current inter-domain routing
architecture is not robust to growth in the n
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 poor
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:
>
At 11:00 AM -0700 4/25/00, David R. Conrad wrote:
> > 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 a
>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 ma
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.
But
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,
> mak
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
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
p
> > 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
> the
> 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 - wh
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
> 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
>
> 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 boun
> 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 big
> 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 e
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. Ve
> 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
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
> I've not backed your assertion. I've provided some data
> on the relative stability of the in-addr space. You've provided
> zero data on the efficacy of the forward delegations.
>
> Can you, with a straight face, claim the servers for the
> forwar
It is a problem of lack well designed user-interface in DNS packet.
DNS from the beginning presents a tool more than a product.
Most of my friends who handles DNS create some PERL scripts or so.
Or try to use something from public domain but it is not adequate sometime.
Also a miscommunication
%
% 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
%
% 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 mi
> 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
> si
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 regi
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 might be tolerable if
>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
%
% 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
> 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 som
> % > >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.
> %
> % actu
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:
>
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), an
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
> reac
%
% 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
% > >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 s
1 - 100 of 166 matches
Mail list logo
