This draft is very incomplete and in my opinion not ready for prime
time. The working group has in the past requested lists of protocols
and applications which do not work with NATs. I have replied
discussing those items for which I am most familiar:
. Telnet (with AUTH, START_TLS, NEW-ENV, a
At 09:59 AM 4/20/00 -0400, Jeffrey Altman wrote:
>This draft is very incomplete and in my opinion not ready for prime
>time. The working group has in the past requested lists of protocols
>and applications which do not work with NATs. I have replied
>discussing those items for which I am most fa
> At 09:59 AM 4/20/00 -0400, Jeffrey Altman wrote:
> >This draft is very incomplete and in my opinion not ready for prime
> >time. The working group has in the past requested lists of protocols
> >and applications which do not work with NATs. I have replied
> >discussing those items for which I
At 12:39 PM 4/20/00 -0400, Jeffrey Altman wrote:
> > At 09:59 AM 4/20/00 -0400, Jeffrey Altman wrote:
> > >This draft is very incomplete and in my opinion not ready for prime
> > >time. The working group has in the past requested lists of protocols
> > >and applications which do not work with NAT
> From: Matt Holdrege <[EMAIL PROTECTED]>
> ...
> Just so there is no more confusion, in no way is the IETF endorsing the use
> or development of NAT. You've completely missed the point of the draft.
> It's purpose is to clearly point out the problems that NAT causes to a
> given set of protoc
> From: Jeffrey Altman <[EMAIL PROTECTED]>
> All of the energy and money being spent on NATs could and should be
> spent to begin the migration to IPv6 instead.
Oh, goody, another round of wasted time and energy arguing about IPv6 and NAT
boxes on the IETF list (triggered, as usual,
>By the way, just out of interest, don't the tops of your knees get kind of
>bruised every time to you see the word "NAT", or have you learned to scoot
>back from your desk in time?
Looks to me like knees are getting bruised all around.
RGF
Robert G. Ferrell, CISSP
Information Systems Security
> > From: Jeffrey Altman <[EMAIL PROTECTED]>
>
> > All of the energy and money being spent on NATs could and should be
> > spent to begin the migration to IPv6 instead.
>
> Oh, goody, another round of wasted time and energy arguing about IPv6 and NAT
> boxes on the IETF list (trigger
> Oh, goody, another round of wasted time and energy arguing about
> IPv6 and NAT boxes on the IETF list
So it seems. Too bad you couldn't just leave it at that without adding
another dose of gasoline to the mix.
Meanwhile, those of us who believe IPv6 is the best and most promising
way out of t
> From: Jeffrey Altman <[EMAIL PROTECTED]>
> I am not a IPv6 proponent other than
Well, I'm not exactly a big fan of NAT boxes either. Disgusting kludges.
However, I've generally found that it's not really very useful to go around
saying "it's not really raining, it's not really raining
> Also please do not steer this thread towards a NAT bashing-fest. We need to
> complete this document and we need constructive input to this draft.
unfortunately, the major premise of the draft is flawed. there
are far too many problems to NAT, affecting far too many applications,
to make a
> > From: Jeffrey Altman <[EMAIL PROTECTED]>
>
> > I am not a IPv6 proponent other than
>
> Well, I'm not exactly a big fan of NAT boxes either. Disgusting kludges.
>
> However, I've generally found that it's not really very useful to go around
> saying "it's not really raining, it's no
--- Keith Moore <[EMAIL PROTECTED]> wrote:
> > Also please do not steer this thread towards a NAT bashing-fest. We need to
>
> > complete this document and we need constructive input to this draft.
>
> unfortunately, the major premise of the draft is flawed. there
> are far too many problems
--- Vernon Schryver <[EMAIL PROTECTED]> wrote:
> > From: Matt Holdrege <[EMAIL PROTECTED]>
>
> > ...
> > Just so there is no more confusion, in no way is the IETF endorsing the use
>
> > or development of NAT. You've completely missed the point of the draft.
> > It's purpose is to clearly poi
--- Jeffrey Altman <[EMAIL PROTECTED]> wrote:
> This draft is very incomplete and in my opinion not ready for prime
> time. The working group has in the past requested lists of protocols
> and applications which do not work with NATs. I have replied
> discussing those items for which I am most
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 trusted and that there are intruders within the priva
I'd like to make some clarifications about Kerberos and NAT.
>> When AUTH is used with Kerberos 4 and Kerberos 5 there are issues
>> related to the IP addresses which are embedded into the Kerberos
>> tickets which specify the valid machines from which the tickets are
>> valid.
> Are you saying
> 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 inside<
> 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 t
> 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 ti
> > 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 lifeti
> > 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 lifeti
At 05:38 PM 4/21/2000 -0400, Keith Moore wrote:
>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 a
> 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 box, the
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 th
--- 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 i
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
--- "J. Noel Chiappa" <[EMAIL PROTECTED]> wrote:
> > 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 d
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
> From: Keith Moore <[EMAIL PROTECTED]>
>> I'm not exactly a big fan of NAT boxes either. Disgusting kludges.
>> However, I've generally found that it's not really very useful to go
>> around saying "it's not really raining, it's not really raining" while
>> I'm walking in a
> 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
>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
>
>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 problem
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
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 add
>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 w
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 c
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
> 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
translatio
>> 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 add
At 11:44 PM 4/23/00 -0400, Keith Moore wrote:
>I wonder...how many of these folks really want network address
>translation, versus those who just want the other things that
>NAT boxes often do? (DHCP, firewall, hub, router, all with
>really easy setup)
I'm not a valid statistical sampling, j
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 ve
ternatives. I suspect it will remain so for at least a
while -- Ian
> -Original Message-
> From: Keith Moore [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 23, 2000 8:44 PM
> To: Dick St.Peters
> Cc: [EMAIL PROTECTED]
> Subject: Re: draft-ietf-nat-protocol-complications-02.tx
> Maybe we need to help make it easy to GET assignments of blocks of addresses
> for individuals/small businesses/etc. Part of the problem is the obvious:
> IPv4 addresses are running short. Part is the "K-Mart" level of product
> understanding I've experienced with many vendors of Internet conn
[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 ni
--- 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
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 operato
Richard Shockey wrote:
> If we were looking at a typicial household and you wanted to plan for the
> future I would have to assume 1 address for every single thing plugged in
> to any thing, phone, electrical appliances, water, maybe even sewage. Yes
> an IP address on your toilet.
[...]
> Busi
> [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".
>
> Otherwi
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 r
| 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 backb
> | 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 a
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 b
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 y
Ohta-san:
| > No, not "or whatever" but "AND whatever".
|
| Do you mean "plug THEM in to your phone line and whatever"?
Yes, that is certainly one possibility. I imagine the "inside"
interface would be some easy-to-wire LAN interface, enabling THEM
to communicate using whatever protocol/addres
Sean Doran wrote:
>
> Ohta-san:
>
> | > No, not "or whatever" but "AND whatever".
> |
> | Do you mean "plug THEM in to your phone line and whatever"?
>
> Yes, that is certainly one possibility. I imagine the "inside"
> interface would be some easy-to-wire LAN interface, enabling THEM
> to com
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 need
> Or seperate the end system identifer from the routing goop. This
> solves lots of problems (while introducing others).
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 re
>From: Keith Moore <[EMAIL PROTECTED]>
>
>> Or seperate the end system identifer from the routing goop. This
>> solves lots of problems (while introducing others).
>
>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 identifi
> >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, unreliabl
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 p
"J. Noel Chiappa" <[EMAIL PROTECTED]> writes:
> For a classic example, look at the recommendations of the IAB Workshop last
> year about IPSEC (and I'll asssume for the moment that IPSec is important to
> securing the Internet, and stay away from the debates about IPSEC versus SSL,
> etc):
>
% > >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
%
% 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
> reac
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
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.
> %
> % actu
> 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
%
% 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: 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
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
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
> 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
%
% 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 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
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
> 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
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. Ve
> 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
> 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
> 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
> 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
> > 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
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
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
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
>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
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
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:
>
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
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
1 - 100 of 167 matches
Mail list logo
