Re: NAT->IPv6

It is a complete fallacy that NAT provides any sort of security. It does no such thing. Security is provide by a firewall, and (more importantly) by strong security policies that are policed and enforced. - Original Message - From: Leonid Yegoshin <[EMAIL PROTECTED]> Newsgroups: cisco.e

Re: draft-ietf-nat-protocol-complications-02.txt

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: >

Re: NAT->IPv6

>From: John Stracke <[EMAIL PROTECTED]> > >"J. Noel Chiappa" wrote: > >> So, you're the CIO for Foondoggle Corp, and you're trying to figure out >> whether to spend any of your Q3 funds on IPv6 conversion. Let's see, benefits >> are not very many (autoconfig may be the best one), and the cost is >

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> > Which raises the interesting (to me anyway) question: Is there value in > > considering a new protocol, layered on top of TCP, but beneath new > > applications, that provides an "association" the life of which transcends > > the TCP transports upon which it is constructed? > > been there, do

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

Hello again, >From the note below, it's obvious that there are some misconceptions about Mobile IP that I'd like to correct. Tripp Lilley wrote: > That is, that's the way it should work... I should be able to put my > laptop to sleep, hop on the plane, land in San Francisco, pull it back > out

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> Which raises the interesting (to me anyway) question: Is there value in > considering a new protocol, layered on top of TCP, but beneath new > applications, that provides an "association" the life of which transcends > the TCP transports upon which it is constructed? been there, done that. yes

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

> I have a hard time believing that your average IP net manager > wouldn't prefer to run an IPv6-IPv6 NAT box (lets call this > NATv6) at her ISP boundary rather than do site-wide renumbering. some of the applications that will motivate the deployment of IPv6 will be those that do not work with N

Re: draft-ietf-nat-protocol-complications-02.txt

>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

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

% > Turn it any way you want, TCP sessions can only survive renumbering through % > end to end mechanisms... % % Which raises the interesting (to me anyway) question: Is there value in % considering a new protocol, layered on top of TCP, but beneath new % applications, that provides an "associati

Re: NAT->IPv6

>From: "Charles E. Perkins" <[EMAIL PROTECTED]> > >If we get to a model where large new domains use IPv6 addressing >with NAT to global IPv4 address space, that would be quite useful. >Before too long, services will appear on the IPv6 network that >can't get the IPv4 global addresses they need.

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

On Tue, 25 Apr 2000, Karl Auerbach wrote: > Which raises the interesting (to me anyway) question: Is there value in > considering a new protocol, layered on top of TCP, but beneath new > applications, that provides an "association" the life of which transcends > the TCP transports upon which it i

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

> Turn it any way you want, TCP sessions can only survive renumbering through > end to end mechanisms... Which raises the interesting (to me anyway) question: Is there value in considering a new protocol, layered on top of TCP, but beneath new applications, that provides an "association" the lif

Re: SCSI over IP

Jon, >> I learned of a forthcoming RFC covering SCSI over IP from IBM and Cisco = >> a couple of weeks ago. Has anyone heard about this? Has the RFC been = >> submitted yet? Are there any web sites with more information? Information on the proposed RFC info on SCSI over IP is htt

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

> Now consider the NATv6 alternative. The average net admin is already > comfortable with NAT at the ISP boundary (hell, some even like it). > She will already be running NAT, if for no other reason than to deal > with IPv4-IPv6 transition. NATv6 is much less onerous than NATv4, > because the ad

Re: SCSI over IP

SCSIoIP Who'd a thunk it   I believe there are a few hash renditions of it at a higher level of networking through distributed computing / storage and processing but lack the white papers to send you on it. I'd be interested if anyone else has specifics on it.   Comments?     - Or

Re: IPv6: Past mistakes repeated?

I think the only reason this hasn't happened in the phone system is due to resistance by humans to reading, writing, and entering very long strings of digits. Unfortunately, computers aren't as fussy. My experience is that as people become more (internationally) mobile their use of IDD +x

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

At 1:53 PM -0700 4/25/00, Paul Francis wrote: >It seems to me that the decision to just use NATv6 rather than >do a site-wide runumber will be a very easy decision to make. If that were the only issue, sure. But there are tradeoffs: is the ease of renumbering (which should be a relatively rare e

RE: IPv6: Past mistakes repeated?

Jim, I totally agree with you. We need to move and start deploying this now rather that later. Starting with the carriers, then the ISP's and the trend will flow down until eventually (in 10-15 years) everyone and everything will be IPv6. I have been tasked with looking into the feasability of up

Re: multihoming (was Re:draft-ietf-nat-protocol-complications-02.txt)

At 1:11 PM -0700 4/25/00, Paul Francis wrote: >For me, your statement certainly reinforces the idea that multihoming in >IPv6 is indeed very difficult. More accurately: multihoming in IP (any version) is indeed very difficult. The problems are a fundamental consequence of having to do hierarchica

Re: IPv6: Past mistakes repeated?

> address space shortage is just one of many possible problems. > as long as the network keeps growing at exponential rates we are > bound to run into some other major hurdle in a few years. it might > be address space but the chances are good that before we hit that > limitation again that we

Re: multihoming (was Re: draft-ietf-nat-protocol-complications-02.txt)

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

Re: IPv6: Past mistakes repeated?

Anthony, One interesting example: OSI NSAP addresses are variable length, with a theoretical limit of 255 bytes I believe (perhaps there's an escape mechanism to grow them longer?). There was an "implementors' agreement" to limit the maximum length in actual use to 20 bytes "for now", to make i

SCSI over IP

I learned of a forthcoming RFC covering SCSI over IP from IBM and Cisco a couple of weeks ago.  Has anyone heard about this?  Has the RFC been submitted yet?   Are there any web sites with more information?   Jon William Toigo Independent Consultant and Author [EMAIL PROTECTED]

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: NAT->IPv6

"J. Noel Chiappa" wrote: > So, you're the CIO for Foondoggle Corp, and you're trying to figure out > whether to spend any of your Q3 funds on IPv6 conversion. Let's see, benefits > are not very many (autoconfig may be the best one), and the cost is > substantial. Sure. Then you buy out Moondogg

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: IPv6: Past mistakes repeated?

Anthony Atkielski wrote: > From: "Keith Moore" <[EMAIL PROTECTED]> > > > it often seems to be the case that if you design for > > the long term, what you get back isn't deployable > > in the near term because you've made the problem > > too hard. > > I dunno. I don't think that adding two more d

Re: IPv6: Past mistakes repeated?

Anthony Atkielski wrote: > From: <[EMAIL PROTECTED]> > > > so that after seeing only the first few bytes, they could > > know what interface to enqueue the outbound packet on > > *before the entire packet had even come in*. > > But this would be even faster with a variable-length address than wit

runumbering (was: Re: IPv6: Past mistakes repeated?)

> > > Wasn't one of the design goals of IPv6 to make renumbering easier, > > so that people could move from small assignments to large ones? > > Yes. IPv6's primary tool in this regard is that it supports multiple > addresses simultaneously. To renumber, you add a new address to each > .

Re: NAT->IPv6

Hello Matt, I probably shouldn't tread into these waters, but... >> 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 s

Re: draft-ietf-nat-protocol-complications-02.txt

> > 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

Re: IPv6: Past mistakes repeated?

> I dunno. I don't think that adding two more digits in the 1960s to year > fields would have really made any problems too hard. you've obviously never tried to write business applications for a machine with only a few Kbytes of memory. memory was expensive in the 1960s, and limited in size.

Re: draft-ietf-nat-protocol-complications-02.txt

> 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

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: draft-ietf-nat-protocol-complications-02.txt

> 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

multihoming (was Re: draft-ietf-nat-protocol-complications-02.txt)

> > 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

Re: IPv6: Past mistakes repeated?

On Tue, 25 Apr 2000 20:16:28 +0200, Anthony Atkielski <[EMAIL PROTECTED]> said: > But this would be even faster with a variable-length address than with a > fixed-length address. You just read address bits until you find a match, > and ignore the rest. Umm.. No. "until you find a match" works

Re: draft-ietf-nat-protocol-complications-02.txt

> 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

Re: draft-ietf-nat-protocol-complications-02.txt

> 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

Re: IPv6: Past mistakes repeated?

On Tue, 25 Apr 2000 20:07:05 +0200, Anthony Atkielski <[EMAIL PROTECTED]> said: > I dunno. I don't think that adding two more digits in the 1960s to year > fields would have really made any problems too hard. It was more a question You never had to fit 2 more bytes onto a punch card, did you?

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: draft-ietf-nat-protocol-complications-02.txt

> 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

Re: NAT->IPv6

> From: Matt Holdrege <[EMAIL PROTECTED]> >> The basic key *architectural* problem with NAT ... is that when you >> have a small number of external addresses being shared by a larger >> number of hosts behind some sort of "address-sharing" device, there's >> no permanent assoc

Re: draft-ietf-nat-protocol-complications-02.txt

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

NAT->IPv6

At 12:55 PM 4/25/00 -0400, J. Noel Chiappa wrote: >The basic key *architectural* problem with NAT (as opposed to all the >mechanical problems like encrypted checksums, etc, some of which can be >solved with variant mechanisms like RSIP), as made clear by Keith's comments, >is that when you have a

Re: How many IP addresses?

> Doesn't this leave out a few pieces of data? Given the current IPv6 > address format, which includes a globally unique 64 bit interface ID and 64 > bits of globally unique routing goop. My calculation is that you only have > 2^64 addresses to work with which leaves roughly 12 bits, maybe 14 to

Re: draft-ietf-nat-protocol-complications-02.txt

> 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

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: draft-ietf-nat-protocol-complications-02.txt

% % 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

Re: IPv6: Past mistakes repeated?

From: <[EMAIL PROTECTED]> > The problem is that the router guys wanted to fast-path > the case of "no IP option field, routing entry in cache" > so that after seeing only the first few bytes, they could > know what interface to enqueue the outbound packet on > *before the entire packet had even c

Re: IPv6: Past mistakes repeated?

From: "Keith Moore" <[EMAIL PROTECTED]> > I wasn't there, but I expect it would have sounded > even more preposterous for someone to have said: > "I'm absolutely positive that this Internet thing > will reach to nearly everyone on the planet in a > couple of decades, and therefore we need to make

Re: draft-ietf-nat-protocol-complications-02.txt

% % 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

Re: draft-ietf-nat-protocol-complications-02.txt

> 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

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: draft-ietf-nat-protocol-complications-02.txt

>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

Re: IPv6: Past mistakes repeated?

Anthony Atkielski wrote: > > > I agree! Why create a finite anything when an infinite > > possibility exists? > > Exactly. If you designed an open-ended protocol, you're far less likely to > ever have to rewrite it. PS - that's what we have version numbers for. Open-ended can sometimes mean

Re: draft-ietf-nat-protocol-complications-02.txt

% % 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

You Gota See!

$ Hey! $ Check Out This: http://mafiouso3.tripod.com $ The Best In Everything Mp3s, Pictures, Movies What Ever Your After You Will Find It Here, $ Want a HOT Christina Aguilera Background For Your PC $ Just Goto The Link Below And Right Click, Then `SET AS WALLPAPER. http://mafiouso3.tripod

Re: IPv6: Past mistakes repeated?

Anthony Atkielski wrote: > > Exactly ... but that's the magic of the variable address scheme. You only > have to allocate disparate chunks in a fixed address scheme because the size > of each chunk is limited by the length of an address field. But if the > address field is variable, you can m

Re: IPv6: Past mistakes repeated?

Daniel Senie wrote: > > Ian King wrote: > > > >From the reports I read, this was implemented by mapping phone numbers > to some other tag (which the user doesn't see) which is used to get the > calls to the proper carrier and ultimately to the proper user. > > Sounds a whole lot like using DNS

Re: draft-ietf-nat-protocol-complications-02.txt

> 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

Re: draft-ietf-nat-protocol-complications-02.txt

> % > >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

Re: draft-ietf-nat-protocol-complications-02.txt

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: >

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: How many IP addresses?

In message , Timothy Behne writ es: >Also, I dont see how you got 25*10^9 * 1000 * 10 = 25*10^9. Should be >25*10^13. This requires log(25*10^13)/log(2), or 48 bits, to use every >address. So the original answer (80 bits left over) was correct, an

RE: How many IP addresses?

Also, I dont see how you got 25*10^9 * 1000 * 10 = 25*10^9. Should be 25*10^13. This requires log(25*10^13)/log(2), or 48 bits, to use every address. So the original answer (80 bits left over) was correct, and using 25*10^9 in the calculation must have been a typo. I just had to satisfy myself

Re: draft-ietf-nat-protocol-complications-02.txt

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

RE: How many IP addresses?

On Tue, 25 Apr 2000, Michael B. Bellopede wrote: > >wrong idea -- big iron routers don't use "code" to do forwarding, they use > >silicon, and very fast silicon at that. There are routers in production > >--Steve Bellovin > > Software, firmware, its a matter of semantics. Do yo

Re: draft-ietf-nat-protocol-complications-02.txt

% % 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

Re: How many IP addresses?

At 9:41 -0400 4/25/00, Steven M. Bellovin wrote: >In message <[EMAIL PROTECTED]>, Graham >Klyne wri >tes: >>At 11:06 PM 4/23/00 -0500, Richard Shockey wrote: >>>With "always on" IP and IP on anything this is closer to reality than we >>>might think. In order to permit a reasonable allocation of ad

Re: draft-ietf-nat-protocol-complications-02.txt

% > >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

Re: draft-ietf-nat-protocol-complications-02.txt

"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): >

Re: draft-ietf-nat-protocol-complications-02.txt

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

Re: IPv6: Past mistakes repeated?

John Stracke <[EMAIL PROTECTED]> writes: > Wasn't one of the design goals of IPv6 to make renumbering easier, > so that people could move from small assignments to large ones? Yes. IPv6's primary tool in this regard is that it supports multiple addresses simultaneously. To renumber, you add a n

Re: How many IP addresses?

In message <[EMAIL PROTECTED]>, "Mi chael B. Bellopede" writes: > > > >> But we have to engineer this in some fashion that >>permits efficient use of these addresses by hosts and (especially) routers. >>(An earlier poster wrote that you "just have to write the code". That's >the >>wrong idea --

RE: How many IP addresses?

> But we have to engineer this in some fashion that >permits efficient use of these addresses by hosts and (especially) routers. >(An earlier poster wrote that you "just have to write the code". That's the >wrong idea -- big iron routers don't use "code" to do forwarding, they use >silicon, a

Re: draft-ietf-nat-protocol-complications-02.txt

> >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

Re: How many IP addresses?

In message <[EMAIL PROTECTED]>, Graham Klyne wri tes: >At 11:06 PM 4/23/00 -0500, Richard Shockey wrote: >>With "always on" IP and IP on anything this is closer to reality than we >>might think. In order to permit a reasonable allocation of addresses with >>room for growth the idea of 25 IP addr

How many IP addresses?

At 11:06 PM 4/23/00 -0500, Richard Shockey wrote: >With "always on" IP and IP on anything this is closer to reality than we >might think. In order to permit a reasonable allocation of addresses with >room for growth the idea of 25 IP address per household and 10 person >actually seems conservat

RE: IPv6: Past mistakes repeated?

For those of you who don't know, and Jim is too modest to tell you, he was a member of the Stanford team that designed and implemented the first TCP protocol versions. Later he went on to build the first versions for the portable Digital LSI-11s used in the Packet Radio network. Vint

RE: IPv6: Past mistakes repeated?

I wonder which we will run out of first: IPv6 addresses or our energy resources? Does the earth have sufficient energy resources to support the level of human economic activity implied by the exhaustion of the IPv6 address space? Guess i am looking too far into the future? :) Maha. On Mon, 24