roy@phri.UUCP (Roy Smith) (11/25/88)
Has anybody made any serious estimates of how long it will be
before we run out of 32-bit IP addresses? (Silly question; I'm sure a very
great amount of thought has been given to it by many people.) With the
proliferation of such things as diskless workstations, each of which has
its own IP address (not to mention terminal multiplexors which eat up one
IP address per tty line!), it seems like it won't be too long before we
just plain run out of addresses.
Yes, I know that 2^32 is a hell of a big number, but it seems like
we won't get anywhere near that number of assigned addresses before we
effectively run out because most nets are sparsely populated. My little
bit of wire, for example, has 256 allocated addresses yet I'm only actually
using 30 or so.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"CERF@A.ISI.EDU (11/27/88)
Roy, As you noted, the allocations are often larger than the actual host count because of the way net numbers must be bound to a chunk of address space in the 32 bit formats available. We should be worried about this and should be thinking about how to expand the available address space. Possibilities include adopting ISO IP numbering (variable length - non-trivial), introducing a 64 bit format (a new IP version number would probably be needed), adding an extended address option (awkward, I suspect), others? Vint Cerf
lear@NET.BIO.NET (Eliot Lear) (11/28/88)
Anybody for Class E addresses? -- Eliot Lear [lear@net.bio.net]
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (11/28/88)
I think Paul Tsuchiya was proposing stuffing Landmark Addresses into class E addresses to support Landmark routing on the Internet. How about class F?
KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) (11/28/88)
A quick perusal of my copy of Internet Numbers indicates that there are a fair number of assigned addresses that are not connected to the Internet - perhaps these addresses could be reclaimed - there is one class A, about 40 class B and I have not counted how many class C addresses that are not connected. This is not a long term solution, but if a crunch comes quickly then it may be a temporary solution that would last long enough to get a proper solution done. Frank Kastenholz Eastman Kodak
postel@VENERA.ISI.EDU (11/29/88)
Roy Smith: Check page 37 of RFC-1062. There are over 21 million possible network numbers. --jon.
stev@VAX.FTP.COM (11/29/88)
*We should be worried about this and should be thinking about how to expand *the available address space. Possibilities include adopting ISO IP *numbering (variable length - non-trivial), introducing a 64 bit *format (a new IP version number would probably be needed), adding *an extended address option (awkward, I suspect), others? *Vint Cerf if we are talking about this (and it seems we are), we also wanna think about issuing newtalk-IP addresses based on location instead of political boundries like they are now. i am not sure that this is the correct way to go, but routing becomes alot easier. i do think that variable length addresses are a *bad* idea. they make life *so* much more compilicated. like, where does the addressing stop? does it include the port number? coul dit include other, higher level information (processid? userid?). this is general to IP addresses, variable or fixed length. *do* we want routing information in the address? how much? explicit routes, or general "this is where one might find me" information? IP version 5 is something we could thrash about for months . . . . . .
CERF@A.ISI.EDU (11/29/88)
I would try very hard to avoid your proposed solution - we've been badly hurt by groups who've thought they'd never be linked to the Internet, have re-used some numbers, only to discover they need to be linked and have gone through much pain to deal with the problems. CERN is one such place and I gather there are others. Vint
CERF@A.ISI.EDU (11/29/88)
New versions of anything are always tricky. I'd like to hear from some LAN analyzer vendors how they feel about variable versus fixed length addressing; ditto the IP and TCP level programmers. This was a point of very active debate in 1979 when we froze on the 32 bit choice instead of variable length. I have the awful feeling I am about to ignite a new blizzard of mail, worse than the worm, but the subject is important and we need to start working through the problems and choices, in my view. Vint
CERF@A.ISI.EDU (11/29/88)
Jon, The way I read it, there are 127 possible class A nets, 16,383 class B nets, roughly 2M+ class C nets, and a bunch (2**28 - 1) of broadcast addresses. The large number of class C nets available should have been sufficient, but we are experiencing some difficulty dealing with large numbers of nets at the IP gateway level (table and routing update sizes). Subnetting works better with class B network format, because there is some room for subnet and host address space. Reparsing the class C address space might be a helpful step towards making more nets effectively available. Vint
bzs@pinocchio.UUCP (Barry Shein) (11/30/88)
>A quick perusal of my copy of Internet Numbers indicates that there are a >fair number of assigned addresses that are not connected to the Internet - >perhaps these addresses could be reclaimed - there is one class A, about 40 >class B and I have not counted how many class C addresses that are not >connected. > >This is not a long term solution, but if a crunch comes quickly then it may >be a temporary solution that would last long enough to get a proper solution >done. > >Frank Kastenholz I always thought sites were encouraged to get registered network numbers even if not currently connected? Um, aren't we panicking here a little, wasn't the question sorta hypothetical, aren't there like a few zillion network numbers left to give out before this "crisis" is worth taking this seriously? If reclaiming 40 Class B addresses will help then the game's over anyhow, that should last a couple of weeks (no?) I agree that it's a good time to start discussing future plans, but a little early to start taking away network numbers due to the "crunch". Some people form bread lines, others bake bread. -Barry Shein, ||Encore||
postel@VENERA.ISI.EDU (11/30/88)
Vint: You are correct about the number of network numbers, 126 class A, 16K class B, and 2M class C. This small address space may be come a problem in a few years, in the mean time is there going to be a solution to the routing problem so that we can have gateways that will route to more than 500 networks? --jon.
CERF@A.ISI.EDU (11/30/88)
Jon, I sure hope so - several IETF working groups are addressing aspects of this problem. It is conceivable that a restructuring of the Class C address space, combined with an area routing strategy might relieve some of the scaling problems. I don't want to second guess the IETF teams, though. Vint
Makey@LOGICON.ARPA (Jeff Makey) (11/30/88)
In <8811281821.AA00300@bel.isi.edu> postel@VENERA.ISI.EDU writes: >Check page 37 of RFC-1062. There are over 21 million possible network >numbers. My calculations give 128 class A networks, 16384 class B networks, and 4194304 class C networks, for a total of about 4.2 million network numbers. Some of these are reserved and some (about 1200) are already registered (okay, listed in the host table). With 4.2 million network numbers, 115 new network numbers could be registered every DAY, and it would still take 100 years to exhaust them all. It seems that there really isn't a problem in the foreseeable future. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
gnb@melba.bby.oz (Gregory N. Bond) (12/01/88)
In article <207@logicon.arpa> Makey@LOGICON.ARPA (Jeff Makey) writes: >My calculations give 128 class A networks, 16384 class B networks, and >4194304 class C networks, for a total of about 4.2 million network >numbers. Some of these are reserved and some (about 1200) are already >registered (okay, listed in the host table). Just last week we registered 2 class C addresses in the setup stages of what may become interneted sites. The net numbers were 192.43.blah. Now, assuming net numbers are allocated sequentially, there are approx (44*256) allocated, which is about 11000. So only 1 in 10 assigned numbers is currently interneted. And virtually none (well, 0.25%) of the class C address space has been used. Plenty of room! But class A/B nets may be at a premium. Perhaps the focus should be in combining class C nets (the reciprocal of subnetting?) Greg (who is not an IP guru but owns 2 net numbers). -- Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net Uucp: {uunet,mnetor,pyramid,ubc-vision,ukc,mcvax,...}!munnari!melba.bby.oz!gnb
das@eplunix.UUCP (David Steffens) (12/02/88)
In article <8811291051.AA06074@ucbvax.Berkeley.EDU>, KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) says: > A quick perusal of my copy of Internet Numbers indicates that there are a > fair number of assigned addresses that are not connected to the Internet - > perhaps these addresses could be reclaimed... Ummm, the problem with this solution is that many vendors are encouraging _all_ customers to apply for a net number even tho they aren't yet connected to the Internet. The idea is that it will simplify things in the event that the organization _does_ wish to connect. Maybe I'm going to be _very_ glad that I haven't gotten around to ordering ours yet :-) -- {harvard,mit-eddie,think}!eplunix!das David Allan Steffens 243 Charles St., Boston, MA 02114 Eaton-Peabody Laboratory (617) 573-3748 Mass. Eye & Ear Infirmary
mrp@sirius.ua.oz (Mark Prior) (12/02/88)
From article <8811291051.AA06074@ucbvax.Berkeley.EDU>, by KASTEN@MITVMA.MIT.EDU (Frank Kastenholz): > A quick perusal of my copy of Internet Numbers indicates that there are a > fair number of assigned addresses that are not connected to the Internet - > perhaps these addresses could be reclaimed - there is one class A, about 40 > class B and I have not counted how many class C addresses that are not > connected. > Adelaide Uni has a Class B number, we are not connected to the Internet, but you can't have our number back! :-) :-) I would suggest that quite a number of the `unused' numbers are sites that want to have a unique number so they can connect to other sites without worrying about number clashes. Also they could be foreign (ie non North American) sites, we fit into this category. One day `real soon now' the satellite link between Australia and the USA will go in and you will find out about all our networks. I will then be able to give my address as mrp@sirius.ua.oz.au ([129.127.4.20]). Mark. -- Mark Prior Phone : +61 8 228 5680 University Computing Services Telex : UNIVAD AA89141 University of Adelaide Fax : +61 8 224 0464 GPO Box 498 Adelaide S.AUSTRALIA 5001 ACSnet: mrp@sirius.ua.oz
stev@VAX.FTP.COM (12/02/88)
*I would try very hard to avoid your proposed solution - we've *been badly hurt by groups who've thought they'd never be linked *to the Internet, have re-used some numbers, only to discover they *need to be linked and have gone through much pain to deal with the *problems. CERN is one such place and I gather there are others. *Vint we found a large number of people were using IP addresses based on the ones they found in the documentation examples or what their other machines came configured with by default. we ship our code with the address 0.0.0.0, which the code realizes isnt useful, and complains at you about it and exits. *so*, we went through our docs and gave all examples with addresses on *our* network in a non-existant subnet. (hopefully, we will be the only people screwed by this if one of them connects). how about either assigning a class C network for documentation and default addresses, or someone who got one for this use letting us all know what it is and that we can use it? if everyone would band together and use it, we might be better off . . . . . . stev knowles stev@ftp.com
jqj@HOGG.CC.UOREGON.EDU (12/03/88)
Before we put much effort into a version 5 of Internet IP we should ask ourselves whether it is worth it. From my perspective, GOSIP IP and CLNS are coming along fast, and mostly solve the addressing problem. Meanwhile, the major advantage (for me!) of TCP/IP is the large installed base of systems and linked networks. A major revision of IP would almost certainly be incompatible with every existing implementation, and hence could not be widely adopted in time to solve our interim problems. Some alternatives to a major revision of IP at this time: 1/ revisit running TCP over OSI IP. OSI IP routers already exist, sort of. Could we live with OSI IP addresses? If not, what are we gonna do when we're not allowed to buy TCP/IP any more? 2/ make more effective use of the existing IP number-space. The current problem is not that we are running out of host addresses (we only have some 60K to 100K hosts on the Internet). The problem is that in a couple of years we'll run out of some kinds of network number. So maybe we should consider assigning a single class A network to each of the regional NSF networks. They could subnet their networks, issue a few hundred 10-bit subnets to each campus they are connected to, and reclaim a couple of dozen class B and C networks each. Push the problem out of the domain of IP routing into that of subnet routing and take advantage of the internal connectivity that the NSF regionals have given us! 3/ seriously consider disjoint Internets with overlapping IP address spaces, connected by application-specific bridges. The routing technology for mail is already deployed, and the technology for telnet is pretty simple (just change the documentation; you wanna get to foo.bar.PROPRIETARY? Telnet to proprietary-gateway.nsf.net, get the HOST: prompt, and telnet from there to foo.bar.proprietary). Granted you can't do much else, but 70% of our community doesn't care about NTP or NFS -- they just want to send mail or open a remote terminal session.
henry@utzoo.uucp (Henry Spencer) (12/06/88)
In article <8811282038.AA15464@vax.ftp.com> stev@VAX.FTP.COM writes: >if we are talking about this (and it seems we are), we also wanna think >about issuing newtalk-IP addresses based on location instead of political >boundries like they are now. i am not sure that this is the correct >way to go, but routing becomes alot easier. Maybe I'm being naive, but I don't grasp this -- can you explain? The current scheme, which breaks them by network, is in effect pretty much a geographic breakdown. In the cases where it's not, e.g. organizations with their own long-haul networks, it is not obvious that a geographic breakdown is in fact desired: the right way to get from one AT&T site to another, for example, is almost always through AT&T's internal nets, and never mind the geography. There is no general correlation between geographic proximity and network-routing proximity. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
Mills@UDEL.EDU (12/07/88)
Vint, You may have heard me honk this subject before, but my feeling is to byte the bullet and adopt variable-length type-E addresses and encode them as per ISO NSAP. From my implementation esperience variable-length addresses are maybe a little awkward, but not really hard when compared to variable-length options, etc. The ISO NSAP addressing format includes a length/format identifier, so it is in principle possible to adopt this format, even if the format is not completely decoded by all gateways, by teaching the header-parser code how to leapfrog the address field in order to parse the options. The big win in my view is the possibility of carrying additional baggage, such as authority, policy and so forth encoded in the address field (perhaps in the IDP field). In my opinion we should face this issue squarely and right now. A statement like: in the future the Internet may be forced to adopt variable-length addressing. If so, it will be expressed in an ISO encoding as a type E format (at least the high-order three bits). Host and gateway implementors should bear this in mind as they implement header-parsing algorithms and data structures. Or something like that. Dave
mckee@MITRE.ARPA (H. Craig McKee) (12/08/88)
>In my opinion we should face this issue squarely and right now. A statement >like: in the future the Internet may be forced to adopt variable-length ^^^^^^ ^^^ Dave/Vint/et al - We should be more definite than that, I suggest: During the next five years, the Internet IAB will require a transition to the use of variable-length addressing as described in RFC 1008. Host and gateway implementors should begin development of appropriate header-parsing algorithms and data structures. Regards - Craig (standard disclaimer)
nick@spider.co.UK (Nick Felisiak) (12/09/88)
In message [A.ISI.EDU]28-Nov-88 18:47:32.CERF, Vint Cerf writes: > > New versions of anything are always tricky. I'd like to hear from > some LAN analyzer vendors how they feel about variable versus > fixed length addressing; ditto the IP and TCP level programmers. > > [...] > > Vint > We decode TCP-IP headers in the Spidermonitor. Handling variable length decodes is not in itself a problem. The hard part is setting up filtering criteria based on variable length stuff. It is difficult to present the user with an easy to use template which will cope with a variable length field, and to have the time critical code which accepts or rejects packets do enough decode to find the right field before comparing it. Consequently, using the Decnet template, the user gets less help in setting up a trace, although the packets are correctly decoded when displayed. Nick Felisiak nick@spider.co.uk Spider Systems Ltd