Mailing List Archive

Address allocation stats
Would anyone have a pointer for recent v4 address allocation statistics?
I'm aware of the Frank's [solensky@ftp.com] presentation material
which he talked about in Los Angeles, but I was looking for something
a bit more recent, and perhaps HTML'ized. Raw figures welcome.

For what its worth, links to Frank's .ps files are located at:

http://research.ftp.com/~solensky/cidr.html

Thanks,

- paul

- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
> Would anyone have a pointer for recent v4 address allocation statistics?
> I'm aware of the Frank's [solensky@ftp.com] presentation material
> which he talked about in Los Angeles, but I was looking for something
> a bit more recent, and perhaps HTML'ized. Raw figures welcome.

The the most recent raw-data report that Frank has based his work on is
available at:
ftp://rs.internic.net/netinfo/ip_network_allocations

They are generated on a monthly basis and filenames are in the form:
ftp://rs.internic.net/netinfo/ip_network_allocations.YYMmm

Regards,
Mark

--

Mark Kosters markk@internic.net +1 703 742 4795
Principal Investigator InterNIC Registration Services
PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48
- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
Thank you, kind sir. This is exactly what I was looking for:

[may '96 figures]

Grand Total (Allocated and Assigned Combined)
Class A - 127
Class B - 10150
Class C - 764202

Percentage Allocated (Allocated and Assigned Combined)
Class A - 100.00%
Class B - 61.95%
Class C - 36.44%

No, back to your regularly scheduled programming. :-)

- paul


At 10:47 PM 6/4/96 -0400, Mark Kosters wrote:

>> Would anyone have a pointer for recent v4 address allocation statistics?
>> I'm aware of the Frank's [solensky@ftp.com] presentation material
>> which he talked about in Los Angeles, but I was looking for something
>> a bit more recent, and perhaps HTML'ized. Raw figures welcome.
>
>The the most recent raw-data report that Frank has based his work on is
>available at:
> ftp://rs.internic.net/netinfo/ip_network_allocations
>
>They are generated on a monthly basis and filenames are in the form:
> ftp://rs.internic.net/netinfo/ip_network_allocations.YYMmm
>
>Regards,
>Mark
>
>--
>
>Mark Kosters markk@internic.net +1 703 742 4795
>Principal Investigator InterNIC Registration Services
>PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48
>

- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
>
> Thank you, kind sir. This is exactly what I was looking for:
>
> [may '96 figures]
>
> Grand Total (Allocated and Assigned Combined)
> Class A - 127
128 <-- :)

> Class B - 10150
> Class C - 764202
>
> Percentage Allocated (Allocated and Assigned Combined)
> Class A - 100.00%
> Class B - 61.95%
> Class C - 36.44%
>
> No, back to your regularly scheduled programming. :-)
>
> - paul
>
>
> At 10:47 PM 6/4/96 -0400, Mark Kosters wrote:
>
> >> Would anyone have a pointer for recent v4 address allocation statistics?
> >> I'm aware of the Frank's [solensky@ftp.com] presentation material
> >> which he talked about in Los Angeles, but I was looking for something
> >> a bit more recent, and perhaps HTML'ized. Raw figures welcome.
> >
> >The the most recent raw-data report that Frank has based his work on is
> >available at:
> > ftp://rs.internic.net/netinfo/ip_network_allocations
> >
> >They are generated on a monthly basis and filenames are in the form:
> > ftp://rs.internic.net/netinfo/ip_network_allocations.YYMmm
> >
> >Regards,
> >Mark
> >
> >--
> >
> >Mark Kosters markk@internic.net +1 703 742 4795
> >Principal Investigator InterNIC Registration Services
> >PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48
> >
>
>


--
--bill
- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
>>
>> Thank you, kind sir. This is exactly what I was looking for:
>>
>> [may '96 figures]
>>
>> Grand Total (Allocated and Assigned Combined)
>> Class A - 127
> 128 <-- :)

Bit pattern 0xxxxxxx Class A (0-127)
Bit pattern 10xxxxxx Class B (128-191)
Bit pattern 110xxxxx Class C (192-223)
Bit pattern 1110xxxx Class D (224-239)

I give up. Where did I go wrong that I think net 128.x.y.z is in the
old style class B range?

Ehud


>> Class B - 10150
>> Class C - 764202
>>
>> Percentage Allocated (Allocated and Assigned Combined)
>> Class A - 100.00%
>> Class B - 61.95%
>> Class C - 36.44%
>>
>> No, back to your regularly scheduled programming. :-)
>>
>> - paul
>>
>>
>> At 10:47 PM 6/4/96 -0400, Mark Kosters wrote:
>>
>> >> Would anyone have a pointer for recent v4 address allocation statistics?
>> >> I'm aware of the Frank's [solensky@ftp.com] presentation material
>> >> which he talked about in Los Angeles, but I was looking for something
>> >> a bit more recent, and perhaps HTML'ized. Raw figures welcome.
>> >
>> >The the most recent raw-data report that Frank has based his work on is
>> >available at:
>> > ftp://rs.internic.net/netinfo/ip_network_allocations
>> >
>> >They are generated on a monthly basis and filenames are in the form:
>> > ftp://rs.internic.net/netinfo/ip_network_allocations.YYMmm
>> >
>> >Regards,
>> >Mark
>> >
>> >--
>> >
>> >Mark Kosters markk@internic.net +1 703 742 4795
>> >Principal Investigator InterNIC Registration Services
>> >PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48
>> >
>>
>>


>--
>--bill
- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
>
> >>
> >> Thank you, kind sir. This is exactly what I was looking for:
> >>
> >> [may '96 figures]
> >>
> >> Grand Total (Allocated and Assigned Combined)
> >> Class A - 127
> > 128 <-- :)
>
> Bit pattern 0xxxxxxx Class A (0-127)
> Bit pattern 10xxxxxx Class B (128-191)
> Bit pattern 110xxxxx Class C (192-223)
> Bit pattern 1110xxxx Class D (224-239)
>
> I give up. Where did I go wrong that I think net 128.x.y.z is in the
> old style class B range?
>
> >> Class B - 10150
> >> Class C - 764202
> >>
You did not go wrong, look at the way Paul did the distribution.
For that matter, look at you supplied bit patterns.
0 to 127 is how many? 128!! :)

(side note... Net zero will be harder to reclaim than net 127)
(any takers? :)
--
--bill
- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
> You did not go wrong...

D'oh. Time to have another Sammy.

> (side note... Net zero will be harder to reclaim than net 127)

Politically easy, legacy-kernel-wise nigh impossible :) That code
is _designed_ to waste net 0.

E
(sammy := Samuel Adams Lager)
- - - - - - - - - - - - - - - - -
RE: Address allocation stats [ In reply to ]
Although the 0-127 nets are allocated 100%, they are hardly
heavily used. The table I made up here is a few months old,
but I suspect there has been little change. In fact, only
about 1/3 of the available space is assigned from this range.


3 General Electric Company
4 Bolt Beranek and Newman Inc. (SATNET)
6 Army (YUMA-NET)
8 Bolt Beranek and Newman Inc. (BBNCCNET), listed as "temp" since 1992
9 IBM Corporation
11 DoD Intel Information Systems
12 AT&T Bell Laboratories
13 Xerox Palo Alto Research Center
14 Public Data Network
15 Hewlett-Packard Company
16 Digital Equipment Corporation
17 Apple Computer Incorporated
18 Massachusetts Institute of Technology
19 Ford Motor Company
20 Computer Sciences Corporation
21 DDN-RVN (Army, not US)
22 Defense Information Systems Agency
24 Being partitioned; 24.0 -> 24.3 "@Home"
25 Royal Signals and Radar Establishment
26 Defense Information Systems Agency (NET-MILNET)
28 DSI-North
29 Defense Information Systems Agency (NET-MILX25-TEMP)
30 Defense Information Systems Agency (NET-ARPAX25-TEMP)
32 Norsk Informasjonsteknologi (NET-NORGESNETT)
33 DLA Systems Automation Center
34 Halliburton Company
35 MERIT Computer Network
36 Stanford University
38 Performance Systems International
40 Eli Lilly and Company
43 Japan Inet (NET-JAPAN-A)
44 Amateur Radio Digital Communications (NET-AMPRNET)
45 Interop Show Network (NET-SHOWNETA)
46 Bolt Beranek and Newman Inc. (NET-BBNNET)
47 Bell-Northern Research (NET-BNR)
48 Prudential Securities Inc. (NET-PRUBACHE)
49 Joint Tactical Command, Control, and Communications Agency (NET-JITCNET1)
50 Joint Tactical Command, Control, and Communications Agency (NET-JITCNET2)
51 Department of Social Security of UK (NET-ITSANET)
52 E.I. duPont de Nemours and Co., Inc. (NET-DUPONT1)
53 cap debis ccs (NET-DB-NET2) (Deutches Bundespost?)
54 Merck and Co., Inc. (NET-MERCK2)
55 Boeing Computer Services, RCAS
56 U.S. Postal Service (NET-USPS1)
57 SITA-Societe Internationale de Telecommunications Aeronautiques
1 Reserved
2 Reserved
5 Reserved
7 Reserved
10 Reserved
23 Reserved
27 Reserved
31 Reserved
37 Reserved
39 Reserved
41 Reserved
42 Reserved
58 through 126 Reserved
0, 127 Reserved by RFC1812; cannot ever be used


jms

Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX)
jms@Opus1.COM http://www.opus1.com/jms Opus One
- - - - - - - - - - - - - - - - -
RE: Address allocation stats [ In reply to ]
I couldn't help but notice how much address space BBN has:

>4 Bolt Beranek and Newman Inc. (SATNET)
>8 Bolt Beranek and Newman Inc. (BBNCCNET), listed as "temp" since 1992
>46 Bolt Beranek and Newman Inc. (NET-BBNNET)

It would be nice if they (BBN-Planet) would renumber into a much smaller
block. As one of their customers who renumbered to get a larger block, I
find it hypocritical that they are asking their customers to renumber when
they have not done it themselves.

Bob


- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
>
> I couldn't help but notice how much address space BBN has:
>
> >4 Bolt Beranek and Newman Inc. (SATNET)
> >8 Bolt Beranek and Newman Inc. (BBNCCNET), listed as "temp" since 1992
> >46 Bolt Beranek and Newman Inc. (NET-BBNNET)
>
> It would be nice if they (BBN-Planet) would renumber into a much smaller
> block. As one of their customers who renumbered to get a larger block, I
> find it hypocritical that they are asking their customers to renumber when
> they have not done it themselves.
>
> Bob
>

They are much improved. When address reclaimation was started over this space,
BBN had eight (8) blocks. And there are efforts in progress to recover
more of this space. You will note that none of these blocks are for BBN-Planet
but for BBN internal and BBN contracts for US Military nets. However, this
is not the real problem.

The largest concern is the so-called toxic-waste-dump of the 192.0.0.0/8 range.
This is due to the fact that the critical path component is not address space
but routing table entries. Efforts to get people to reduce the number of
192.0.0.0/8 entries in the global routing space will provide the most "bang
for the buck" until (with a nod to Noels excellent arguments) better routers
are on the market.

So lets not pick on BBN while the real problem is chomping on our respective
hindends.

--bill
- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
Bill:
>
> So lets not pick on BBN while the real problem is chomping on our respective
> hindends.
>

I could not agree more.

Aggregation is a Tool not a Rule.

A argument can be easily constructed that points fingers at router vendors;
and another argument can be constructed that points fingers at other
organizations.

Let's not pick on BBN (didn't Bill say this first?)

Happy Trails,

Tim


- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
> @ So lets not pick on BBN while the real problem is chomping on our respective
> @ hindends.
> @
> @ --bill
> @
>
> Why should anyone even care any more...there are
> no good fixes, the people that are in a position to
> fix things will never do it...and from an IPv8 point of
> view...the entire IPv4 address space is a TWD...
>
> --
> Jim Fleming
> UNETY Systems, Inc.
> Naperville, IL
>

Just curious, How did your missive enter into our TWD of
IPv4 anyway and why do you insist on remaining here
(unety.net) just to badger us, the poor sots who lack
your forsight and vison. I am happy with my heathen
ways and don't wish this new religion thrust down my
throat.

Of course many people I know of who have left IPv4, looked
at your IPv8 and decided that it is flawed and moved on..
to IPv10. In fact there are commercial implementations of
this code base now from a large number of vendors. Yup,
IPX is the wave of the future.... :)

--
--bill
- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
> 53 cap debis ccs (NET-DB-NET2) (Deutches Bundespost?)

Njet, Debis belongs to Mercedes Benz.

Cheers,
Kai


- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
[initial stuff deleted]
>They are much improved. When address reclaimation was started over this space,
>BBN had eight (8) blocks. And there are efforts in progress to recover
>more of this space. You will note that none of these blocks are for BBN-Planet
>but for BBN internal and BBN contracts for US Military nets. However, this
>is not the real problem.
>
>The largest concern is the so-called toxic-waste-dump of the 192.0.0.0/8 range.
>This is due to the fact that the critical path component is not address space
>but routing table entries. Efforts to get people to reduce the number of
>192.0.0.0/8 entries in the global routing space will provide the most "bang
>for the buck" until (with a nod to Noels excellent arguments) better routers
>are on the market.
>
>So lets not pick on BBN while the real problem is chomping on our respective
>hindends.


Hm... perhaps I need a better chart at Nanog, anyway, here the
summary:
Todays total announce prefixes:
~36,000
Average aggregation on a prefix for currently unannounced space
(not including RFC- space reserved for private networks)
For a /20:
>650,000
For a /19:
>325,000
For a /18:
>150,000
For a /17:
>75,000
For a /16:
<50,000

Now from my other chart " Your favority router vendor BGP memory usage"
At /16 level of AVERAGE aggregation, plus legacy prefixs, we will
be eating about 18megs of memory for Cisco BGP data
with 4 full views (4 NAP/MAEs)
At /17 (4.0 views): 30M of memory
At /18 (4.0 views): 50M of memory
At /19 (4.0 views): 100M of memory
At /20, my chart won't fit on my screen.

For those companies that are creating multiple private interconnections we can
look at data for 8.0 views: (fractional View number are common in real
world data since, there are legacy private interconnects and
multi-home customers count differently, thew "view" number is the
ratio of prefixes to path, since cisco's use about 135 bytes
per prefix, plus 35 bytes per path, this is fairly constant).

/17 (8.0): ~45M
/18 (8.0): ~55M
/19 (8.0): ~125M
/20 (8.0): >225M

At 16 paths per prefix (16 major exchanges)
/17 (16.0): ~60M
/18 (16.0): ~115M
/19 (16.0): ~240M
/20 (16.0): >370M


Of course this is "end state" after all possible addresses have been
assigned.

Now if you just look at it on a total prefixes basis, you can
see with 8 peering points and 75,000 prefixes, a Cisco 7000
is just going to die.

And most of us know that route flap will kill is first, if we
don't dampen. If any has any clear ways to gather data
of route flap cpu utilization, I'd like to tal to them. Some people
have done this, it just isn't very easy to gather data and
do best fit function like the memory data was.


--
Jeremy Porter, Freeside Communications, Inc. jerry@fc.net
PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-339-6094
http://www.fc.net

- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
> Would anyone have a pointer for recent v4 address allocation statistics?
> I'm aware of the Frank's [solensky@ftp.com] presentation material
> which he talked about in Los Angeles, but I was looking for something
> a bit more recent, and perhaps HTML'ized. Raw figures welcome.
>
> For what its worth, links to Frank's .ps files are located at:
>
> http://research.ftp.com/~solensky/cidr.html

I've just updated the graphs for the data through the end of May.
These'll be the ones I'll be bringing to Montreal and are very
similar to the ones from LA -- assuming no other changes.

The postscript files can also be copied from:
ftp://research.ftp.com/pub/cidr/current

If I get a chance this week, I'll also look for a .ps->.gif converter..
-- Frank

- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
> I've just updated the graphs for the data through the end of May.
> These'll be the ones I'll be bringing to Montreal and are very
> similar to the ones from LA -- assuming no other changes.
>
> The postscript files can also be copied from:
> ftp://research.ftp.com/pub/cidr/current
>
> If I get a chance this week, I'll also look for a .ps->.gif converter..

You've just found one. Me. ;-)

Seriously, you need GhostScript 2.6.1 with the following
modification to gdevgif.c:

/* #define TABLE_SIZE 5123 /* this is max for 12-bit codes */
#define TABLE_SIZE 5119 /* this is max for 12-bit codes (and prime) */

5123 is nice, but not prime, and this will in certain
circumstances produce an infinite CPU-consuming loop.

Second, uncomment the "30000 VM?" test in the PS files.

Third you will need the ps-to-gif script (a one-liner in the
shell given the right gs) and the landscape.ps which is available
together with the already converted (gif) files in

ftp://trane.uninett.no/tmp/pier/

Note that a newer version of GhostScript won't do, since they
removed the GIF driver in subsequent versions to 2.6.1 (you
probably know why...).

Regards,

- Havard
- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
> > I've just updated the graphs for the data through the end of May.
> > These'll be the ones I'll be bringing to Montreal and are very
> > similar to the ones from LA -- assuming no other changes.
> >
> > The postscript files can also be copied from:
> > ftp://research.ftp.com/pub/cidr/current
> >
> > If I get a chance this week, I'll also look for a .ps->.gif converter..
>
> You've just found one. Me. ;-)
>
> Seriously, you need GhostScript 2.6.1 with the following
> modification to gdevgif.c:
>
> /* #define TABLE_SIZE 5123 /* this is max for 12-bit codes */
> #define TABLE_SIZE 5119 /* this is max for 12-bit codes (and prime) */
>
> 5123 is nice, but not prime, and this will in certain
> circumstances produce an infinite CPU-consuming loop.
>
> Second, uncomment the "30000 VM?" test in the PS files.
>
> Third you will need the ps-to-gif script (a one-liner in the
> shell given the right gs) and the landscape.ps which is available
> together with the already converted (gif) files in
>
> ftp://trane.uninett.no/tmp/pier/
>
> Note that a newer version of GhostScript won't do, since they
> removed the GIF driver in subsequent versions to 2.6.1 (you
> probably know why...).
>
> Regards,
>
> - Havard

However, newer versions of ghostscript have no problem creating ppm
files (if you compile w/ ppm driver), and you can use them along with
'pstogif' to generate GIF files. 'pstogif' is just a perl script that
runs gs to generate ppm, then pnmcrop, ppmquant and ppmtogif (from the
netpbm package). Also, 'convert' in the ImageMagick package will work
as well, and does something similar (i.e. I think you still need
ghostscript with ppm). I don't normally use 'convert' for PostScript to
GIF conversion though, since I've found it to be a lot slower than
'pstogif'.

I don't remember where I got 'pstogif' (maybe the CTAN archive?), so
here it is (albeit with my change to use a FIFO to speed things up a
bit).

Daniel
~~~~~~

#!/usr/local/bin/perl
#
# pstogif.pl v1.0, July 1994, by Nikos Drakos <nikos@cbl.leeds.ac.uk>
# Computer Based Learning Unit, University of Leeds.
#
# Accompanies LaTeX2HTML Version 95
#
# Script to convert an arbitrary PostScript image to a cropped GIF image
# suitable for incorporation into HTML documents as inlined images to be
# viewed with WWW browsers.
#
# This is based on the pstoepsi script
# by Doug Crabill dgc@cs.purdue.edu
#
# Please note the following:
# - The source PostScript file must end
# in a .ps extention. This is a GhostScript requirement, not mine...
# - The -density argument has no effect unless the
# color depth (set with the -depth argument) is equal to 1.
# - Valid arguments for -depth are 1,8, or 24.
#
# This software is provided as is without any guarantee.
#
# Nikos Drakos (ND), nikos@cbl.leeds.ac.uk
# Computer Based Learning Unit, University of Leeds.
#
# 20 JUL 94 ND Converted to Perl and made several changes eg it now accepts
# parameters from environment variables or from command line or will use
# default ones.
#
# 1 APR 94 ND Changed the suffixes of multi-page files from xbm to gif (oops!)
#
#

#####################################################################
$| =1;
&read_args;

### You may need to specify some pathnames here if you want to
### run the script without LaTeX2HTML

# Ghostscript
$GS= $ENV{'GS'} || 'gs';

# Comes with LaTeX2HTML (For ghostscript versions greater than 3.0
# you need the newer pstoppm.ps)
$PSTOPPM= $ENV{'PSTOPPM'} ||
'/usr/local/lib/ghostscript/pstoppm.ps';

# Available in the PBMPLUS libary
$PNMCROP=$ENV{'PNMCROP'} || '/u/dwm/bin/pnmcrop' ;

# Also in PBMPPLUS
$PPMTOGIF=$ENV{'PPMTOGIF'} || '/u/dwm/bin/ppmtogif' ;

# Also in PBMPPLUS
$REDUCE_COLOR=$ENV{'PPMQUANT'} || '/u/dwm/bin/ppmquant 256' ;

$OUTFILE = $ENV{'OUTFILE'} || $out;

# Valid choices for $COLOR_DEPTH are 1, 8 or 24.
$DEPTH = $ENV{'DEPTH'} || $depth || 24;

#Default density is 72
$DENSITY = $ENV{'DENSITY'} || $density || 72;

# Valid choices are any numbers greater than zero
# Useful choices are numbers between 0.1 - 5
# Large numbers may generate very large intermediate files
# and will take longer to process
$SCALE = $ENV{'SCALE'} || $scale; # No default value

$PAPERSIZE = $ENV{'PAPERSIZE'} || $papersize; # No default value;

$DEBUG = $ENV{'DEBUG'} || $DEBUG || 0;

######################################################################

&main;

sub read_args {
local($_);
while ($ARGV[0] =~ /^-/) {
$_ = shift @ARGV;
if (/^-h(elp)?$/) {
&usage; exit;}
elsif (/^-out$/) {
$out = shift @ARGV;
}
elsif (/^-(.*)$/) {
eval "\$$1 = shift \@ARGV;"; # Create and set a flag $<name>
}
}
}

sub main {
local($base, $outfile, $i, $j);
$base = &test_args;
$outfile = $OUTFILE || "$base.gif";
open(STDERR, ">/dev/null") unless $DEBUG;
system("/usr/bin/mkfifo $base.ppm");
&crop_scale_etc("$base.ppm", $outfile);
&convert($base);
&cleanup($base);
}

sub crop_scale_etc {
local($in, $out) = @_;
open(STDERR, ">/dev/null") unless $DEBUG;
system("$PNMCROP $in |$REDUCE_COLOR |$PPMTOGIF - > $out &");
print "Writing $out\n";
}

sub test_args {
local($file) = $ARGV[0];
if (! ($file =~ s/\.ps$//)) {
print "The name of the input file must end in '.ps'\n";
exit;}
elsif (! ( -f "$file.ps")) {
print "Cannot find file $file.ps\n.";
exit;}
elsif (! ($DEPTH =~ /^(1|8|24)$/)) {
print "The color depth must be 1 or 8 or 24. You specified $DEPTH\n";
exit;
}
if (defined $SCALE) {
if ($SCALE > 0) {
$DENSITY = int($SCALE * 72);}
else {
print "Error: The scale must be greater than 0.\n" .
"You specified $SCALE\n";
exit;}
}
$file;
}

sub convert {
local($base) = @_;
local($paperopt) = "-sPAPERSIZE=$PAPERSIZE" if $PAPERSIZE;
local($ppmtype) = join('', "ppm",$DEPTH,"run");
open (GS, "|$GS -q $paperopt -dNODISPLAY $PSTOPPM -");
print GS "$DENSITY $DENSITY ppmsetdensity\n";
print GS "ppmsetsize2$PAPERSIZE % thanks to wsineric\@win.tue.nl (Eric Verbeek)\n" if $PAPERSIZE;
print GS "($base) $ppmtype\n";
close GS;
}

sub cleanup {
local($base) = @_;
# unlink <$base[0-9.]*ppm>;
}

sub usage {
print "Usage: pstogif [-h(elp)] [-out <output file>] [-depth <color depth 1, 8 or 24>] [-density <pixel density>] <file>.ps\n\n";
}
- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
> Seriously, you need GhostScript 2.6.1 with the following
> modification to gdevgif.c:

I'm at the IPv6 UNH bake-off this week and only have direct
access to a portable with Win 95 & WfW 3.11 on it so I'll
get to this right after the IETF..

- - - - - - - - - - - - - - - - -
Re: Address allocation stats [ In reply to ]
We have made a dump of the networks contained in the InterNIC
database as ftp://rs.internic.net/netinfo/ip_network_dump.96Jun.gz to
better help aid the analysis in both IP address allocations and
routing announcements. Here is a sample of what is contained within this
file:

network:IP-Network: 192.68.148.0/24
network:Assigned-Date: 13-Mar-90
--------------------
network:IP-Network: 144.143.0.0/16
network:Assigned-Date: 12-Dec-90
--------------------
network:IP-Network: 144.144.0.0/16
network:Assigned-Date: 12-Dec-90
--------------------
network:IP-Network: 192.86.170.0/24
network:Assigned-Date: 12-Dec-90

Regards,
Mark

--

Mark Kosters markk@internic.net +1 703 742 4795
Principal Investigator InterNIC Registration Services
PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48
- - - - - - - - - - - - - - - - -