Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab05812; 5 Jun 96 0:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05797; 5 Jun 96 0:01 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa00801; 5 Jun 96 0:01 EDT Received: from slam.internic.net (slam.internic.net [198.41.0.36]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id MAA09342 for ; Wed, 5 Jun 1996 12:39:33 +1000 Received: (markk@localhost) by slam.internic.net (8.7.4/SLAM-1) id WAA29836; Tue, 4 Jun 1996 22:47:08 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Kosters Message-Id: <199606050247.WAA29836@slam.internic.net> Subject: Re: Address allocation stats To: Paul Ferguson Date: Tue, 4 Jun 1996 22:47:08 -0400 (EDT) Cc: cidrd@iepg.org, nanog@merit.edu, pier@isi.edu In-Reply-To: <199605282359.QAA27104@lint.cisco.com> from "Paul Ferguson" at May 28, 96 07:58:29 pm X-Mailer: ELM [version 2.4 PL24alpha4] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07612; 5 Jun 96 1:39 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07608; 5 Jun 96 1:39 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa01872; 5 Jun 96 1:39 EDT Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id OAA11349 for ; Wed, 5 Jun 1996 14:35:45 +1000 Received: from pferguso-pc.cisco.com (c1robo5.cisco.com [171.68.13.5]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id VAA11246; Tue, 4 Jun 1996 21:44:03 -0700 Message-Id: <199606050444.VAA11246@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 05 Jun 1996 00:43:16 -0400 To: Mark Kosters Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Ferguson Subject: Re: Address allocation stats Cc: cidrd@iepg.org, nanog@merit.edu, pier@isi.edu 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 >   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07859; 5 Jun 96 1:58 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07854; 5 Jun 96 1:58 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02041; 5 Jun 96 1:58 EDT Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id OAA11635 for ; Wed, 5 Jun 1996 14:52:32 +1000 Received: by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 4 Jun 1996 22:00:00 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Manning Message-Id: <199606050500.AA21014@zephyr.isi.edu> Subject: Re: Address allocation stats To: Paul Ferguson Date: Tue, 4 Jun 1996 22:00:00 -0700 (PDT) Cc: markk@internic.net, cidrd@iepg.org, nanog@merit.edu, pier@isi.edu In-Reply-To: <199606050444.VAA11246@lint.cisco.com> from "Paul Ferguson" at Jun 5, 96 00:43:16 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1328 > > 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09863; 5 Jun 96 4:05 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab09859; 5 Jun 96 4:05 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03357; 5 Jun 96 4:05 EDT Received: from Hearts.ACES.COM (Hearts.ACES.COM [192.195.240.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id QAA14107 for ; Wed, 5 Jun 1996 16:59:13 +1000 Received: from ACES.COM by ACES.COM (PMDF V4.3-10 #4107) id <01I5J2NCK6I80001VO@ACES.COM>; Wed, 05 Jun 1996 00:06:04 -0700 (MST) Date: Wed, 05 Jun 1996 00:02:35 -0700 (MST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ehud Gavron Subject: Re: Address allocation stats In-reply-to: Your message dated "Tue, 04 Jun 1996 22:00:00 -0700 (PDT)" <199606050500.AA21014@zephyr.isi.edu> To: bmanning@isi.edu Cc: pferguso@cisco.com, markk@internic.net, cidrd@iepg.org, nanog@merit.edu, pier@isi.edu, GAVRON@aces.com Message-id: <01I5J2SUMXOK0001VO@ACES.COM> Organization: ACES Research Inc. MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit >> >> 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09983; 5 Jun 96 4:14 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09979; 5 Jun 96 4:14 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03449; 5 Jun 96 4:14 EDT Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA14173 for ; Wed, 5 Jun 1996 17:03:13 +1000 Received: by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 5 Jun 1996 00:10:49 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Manning Message-Id: <199606050710.AA22234@zephyr.isi.edu> Subject: Re: Address allocation stats To: Ehud Gavron Date: Wed, 5 Jun 1996 00:10:49 -0700 (PDT) Cc: bmanning@isi.edu, pferguso@cisco.com, markk@internic.net, cidrd@iepg.org, nanog@merit.edu, pier@isi.edu, GAVRON@aces.com In-Reply-To: <01I5J2SUMXOK0001VO@ACES.COM> from "Ehud Gavron" at Jun 5, 96 00:02:35 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 784 > > >> > >> 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11458; 5 Jun 96 5:59 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11454; 5 Jun 96 5:59 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04402; 5 Jun 96 5:59 EDT Received: from Hearts.ACES.COM (Hearts.ACES.COM [192.195.240.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id SAA15909 for ; Wed, 5 Jun 1996 18:41:23 +1000 Received: from ACES.COM by ACES.COM (PMDF V4.3-10 #4107) id <01I5J5W5CI5C0001Z0@ACES.COM>; Wed, 05 Jun 1996 01:48:54 -0700 (MST) Date: Wed, 05 Jun 1996 01:46:54 -0700 (MST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ehud Gavron Subject: Re: Address allocation stats In-reply-to: Your message dated "Wed, 05 Jun 1996 00:10:49 -0700 (PDT)" <199606050710.AA22234@zephyr.isi.edu> To: bmanning@isi.edu Cc: GAVRON@aces.com, bmanning@isi.edu, pferguso@cisco.com, markk@internic.net, cidrd@iepg.org, nanog@merit.edu, pier@isi.edu Message-id: <01I5J6BUPZRE0001Z0@ACES.COM> Organization: ACES Research Inc. MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > 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)   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07597; 7 Jun 96 2:02 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07593; 7 Jun 96 2:02 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02436; 7 Jun 96 2:02 EDT Received: from Piano.Opus1.COM (Piano.Opus1.COM [192.245.12.69]) by nico.aarnet.edu.au (8.6.10/8.6.10) with ESMTP id OAA19139 for ; Fri, 7 Jun 1996 14:14:54 +1000 Received: from Opus1.COM by Opus1.COM (PMDF V5.0-5 #9830) id <01I5LPKROYHSE46Q0H@Opus1.COM>; Thu, 06 Jun 1996 21:22:51 -0700 (MST) Date: Thu, 06 Jun 1996 21:20:35 -0700 (MST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Joel M Snyder, bucket o' bits" Subject: RE: Address allocation stats To: cidrd@iepg.org, nanog@merit.edu Message-id: <01I5LPO7TZ7GE46Q0H@Opus1.COM> Organization: Opus One - +1 520 324 0494 MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Fruit-of-the-day: muskmelon Comments: Telecommunications and Information Technology Services 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20915; 7 Jun 96 14:31 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20910; 7 Jun 96 14:31 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa04964; 7 Jun 96 14:31 EDT Received: from mailhost.Ipsilon.COM (foo-5-10.Ipsilon.COM [205.226.5.12]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id DAA00374 for ; Sat, 8 Jun 1996 03:05:49 +1000 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA19970; Fri, 7 Jun 1996 10:13:41 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Jun 1996 10:15:03 -0700 To: "Joel M Snyder, bucket o' bits" Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Hinden Subject: RE: Address allocation stats Cc: cidrd@iepg.org, nanog@merit.edu 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21661; 7 Jun 96 15:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21656; 7 Jun 96 15:01 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05470; 7 Jun 96 15:01 EDT Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id DAA00777 for ; Sat, 8 Jun 1996 03:50:35 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 7 Jun 1996 10:58:48 -0700 Posted-Date: Fri, 7 Jun 1996 10:58:20 -0700 (PDT) Message-Id: <199606071758.AA02169@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 7 Jun 1996 10:58:20 -0700 Subject: Re: Address allocation stats To: Bob Hinden Date: Fri, 7 Jun 1996 10:58:20 -0700 (PDT) Cc: Joel_M_Snyder@opus1.com, cidrd@iepg.org, nanog@merit.edu In-Reply-To: from "Bob Hinden" at Jun 7, 96 10:15:03 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1348 > > 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22192; 7 Jun 96 15:25 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22188; 7 Jun 96 15:25 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa05861; 7 Jun 96 15:25 EDT Received: from linux.silkroad.com (silkroad.com [198.133.151.18]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA00964 for ; Sat, 8 Jun 1996 04:12:52 +1000 Received: (from nanog@localhost) by linux.silkroad.com (8.7.3/8.6.9) id OAA15437; Fri, 7 Jun 1996 14:20:51 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Bass (@NANOG-LIST) Message-Id: <199606071820.OAA15437@linux.silkroad.com> Subject: Re: Address allocation stats To: bmanning@isi.edu Date: Fri, 7 Jun 1996 14:20:51 -0400 (EDT) Cc: hinden@ipsilon.com, Joel_M_Snyder@opus1.com, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199606071758.AA02169@zed.isi.edu> from "bmanning@isi.edu" at Jun 7, 96 10:58:20 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22815; 7 Jun 96 15:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22809; 7 Jun 96 15:41 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa06188; 7 Jun 96 15:41 EDT Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA01084 for ; Sat, 8 Jun 1996 04:26:12 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 7 Jun 1996 11:34:30 -0700 Posted-Date: Fri, 7 Jun 1996 11:34:02 -0700 (PDT) Message-Id: <199606071834.AA02228@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 7 Jun 1996 11:34:02 -0700 Subject: Re: Address allocation stats To: Jim Fleming Date: Fri, 7 Jun 1996 11:34:02 -0700 (PDT) Cc: nanog@merit.edu, cidrd@iepg.org In-Reply-To: <01BB5474.88D01B60@webster.unety.net> from "Jim Fleming" at Jun 7, 96 01:23:35 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 971 > @ 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09465; 9 Jun 96 17:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09456; 9 Jun 96 17:22 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12204; 9 Jun 96 17:22 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09445; 9 Jun 96 17:22 EDT Received: from newdev.harvard.edu by IETF.CNRI.Reston.VA.US id aa09406; 9 Jun 96 17:20 EDT Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id RAA02296; Sun, 9 Jun 1996 17:21:16 -0400 (EDT) Date: Sun, 9 Jun 1996 17:21:16 -0400 (EDT) X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott Bradner Message-Id: <199606092121.RAA02296@newdev.harvard.edu> To: cidrd@iepg.org, ietf@ietf.org Subject: what should follow CIDRD? Source-Info: From (or Sender) name not authenticated. The 2nd half of the CIDRD session in Monreal will be a BOF liiking into the question of what should happen to the CIDRD WG. Here is the BOF description. ----- CIDRD progeny (cidpro) -- chair Scott Bradner -- area OPS BGP begot BGPD, BGPD came together with ALE to beget CIDRD, CIDRD strayed from the true path and the question is should it beget or begone. There is a widespread feeling that the CIDRD working group should be concluded. It has met its goals and has become more of a general operations of the Internet catch-all. The working group chairs and the IESG concur in this feeling and the working group will terminate after the fates of the documents that it has in last call are determined. This BOF will explore the options for the future of the activities that the CIDRD working group has been supporting. This discussion will include an examination of the role of the IETF in the operations of the Internet. Anyone who would like to be given time to speak at the session please send a request to sob@harvard.edu.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10396; 9 Jun 96 18:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10392; 9 Jun 96 18:54 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13217; 9 Jun 96 18:54 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10379; 9 Jun 96 18:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10363; 9 Jun 96 18:54 EDT Received: from kuji.off.connect.com.au by CNRI.Reston.VA.US id aa13209; 9 Jun 96 18:54 EDT Received: (from asjl@localhost) by kuji.off.connect.com.au id KAA03292 (8.7.5/IDA-1.6); Mon, 10 Jun 1996 10:50:55 +1200 (NZST) Date: Mon, 10 Jun 1996 10:50:54 +1200 (NZST) X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Linton X-Sender: asjl@kuji.off.connect.com.au To: Barry Raveendran Greene cc: 'IESG Secretary' , "'iesg@cnri.reston.va.us'" , "'ietf@cnri.reston.va.us'" , "aim@apic.net" , apng-all , "'apng-legal@apng.org'" , "cidrd@iepg.org" , "cix-members@cix.org" , "'davidc@apnic.net'" , "'dfk@ripe.net'" , "'kimh@internic.net'" , "local-ir@teckla.apnic.net" , "'markk@internic.net'" , "'postel@isi.edu'" , "sg-nic@singnet.com.sg" , "'stix@singnet.com.sg'" Subject: RE: Last Call: INTERNET REGISTRY IP ALLOCATION GUIDELINES to BCP In-Reply-To: <01BB35DF.AD9DCE00@ts900-4508.singnet.com.sg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 29 Apr 1996, Barry Raveendran Greene wrote: > TO: IESG and AP Internet Community, > > The IESG has received a request from the CIDR Deployment Working Group > to consider "INTERNET REGISTRY IP ALLOCATION GUIDELINES" > for the status of BCP. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by > May 3, 1996. I must echo Barry Greene's comments on the draft. There is a real danger here that if this document goes forward it will continue to promote the view held by many in the US that the Internet is in fact based in the US and that the rest of the world somehow connects to it. Regional links are starting to appear in the AP region which bypass the US West Coast bottlenecks. The proposed scheme will not encourage this diversity and redunancy. Barry's comments about AP having its act together are worth repeating. The provisions of this draft fail to take note of that. Please don't support this draft as it stands! andy -- Mail : Andy Linton Tel : +64 4 384 1784 URL : http://www.connect.com.au/people/asjl/ Fax : +64 4 499 1130 Post : connect.com.au pty ltd, PO Box 11-992, Wellington, New Zealand --   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11638; 9 Jun 96 20:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11634; 9 Jun 96 20:54 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14574; 9 Jun 96 20:54 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11625; 9 Jun 96 20:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11605; 9 Jun 96 20:53 EDT Received: from kuji.off.connect.com.au by CNRI.Reston.VA.US id aa14564; 9 Jun 96 20:53 EDT Received: (from asjl@localhost) by kuji.off.connect.com.au id MAA03390 (8.7.5/IDA-1.6); Mon, 10 Jun 1996 12:50:18 +1200 (NZST) Date: Mon, 10 Jun 1996 12:50:17 +1200 (NZST) X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Linton X-Sender: asjl@kuji.off.connect.com.au To: Barry Raveendran Greene , 'IESG Secretary' , "'iesg@cnri.reston.va.us'" , "'ietf@cnri.reston.va.us'" , "aim@apic.net" , apng-all , "'apng-legal@apng.org'" , "cidrd@iepg.org" , "cix-members@cix.org" , "'davidc@apnic.net'" , "'dfk@ripe.net'" , "'kimh@internic.net'" , "local-ir@teckla.apnic.net" , "'markk@internic.net'" , "'postel@isi.edu'" , "sg-nic@singnet.com.sg" , "'stix@singnet.com.sg'" Subject: RE: Last Call: INTERNET REGISTRY IP ALLOCATION GUIDELINES to BCP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I must apologise to all recipients of this message for my recent posting. I'd mailed in support of Barry's call for support on the issue and hadn't noticed that I was replying to a piece of old mail and that the deadline had gone for objections. Also apologies if you get multiples of this - I'm using the original list that I stuffed up with. andy -- Mail : Andy Linton Tel : +64 4 384 1784 URL : http://www.connect.com.au/people/asjl/ Fax : +64 4 499 1130 Post : connect.com.au pty ltd, PO Box 11-992, Wellington, New Zealand --   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06860; 11 Jun 96 1:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06856; 11 Jun 96 1:23 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02199; 11 Jun 96 1:23 EDT Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id NAA08312 for ; Tue, 11 Jun 1996 13:40:29 +1000 Received: from localhost by ptavv.es.net; (5.65/1.1.8.2/08Feb94-0649PM) id AA10519; Mon, 10 Jun 1996 20:49:25 -0700 Message-Id: <9606110349.AA10519@ptavv.es.net> X-Mailer: exmh version 1.6.7 5/3/96 To: cidrd@nico.aarnet.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jun 96 20:49:25 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kevin Oberman X-Mts: smtp help list end   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13257; 11 Jun 96 9:41 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13251; 11 Jun 96 9:41 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa09011; 11 Jun 96 9:41 EDT Received: from mail.Germany.EU.net (mail.germany.eu.net [192.76.144.65]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id WAA12568 for ; Tue, 11 Jun 1996 22:24:46 +1000 Received: by mail.Germany.EU.net with ESMTP (5.59:21/EUnetD-2.5.4.c) via EUnet id OAA20723; Tue, 11 Jun 1996 14:33:39 +0200 Message-Id: <199606111233.OAA17989@meepmeep.Germany.EU.net> Received: from meepmeep by meepmeep.Germany.EU.net with ESMTP (5.59:8/EUnetDlan-1.24-1.2.10) via EUnet for [mail.germany.eu.net] id OAA17989; Tue, 11 Jun 1996 14:33:38 +0200 To: "Joel M Snyder, bucket o' bits" cc: cidrd@iepg.org, nanog@merit.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kai Alexander Scharwacht Subject: Re: Address allocation stats In-reply-to: (Your message of Thu, 06 Jun 1996 21:20:35 PDT.) <01I5LPO7TZ7GE46Q0H@Opus1.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jun 1996 14:33:37 +0200 X-Orig-Sender: Kai.Alexander.Scharwacht@germany.eu.net > 53 cap debis ccs (NET-DB-NET2) (Deutches Bundespost?) Njet, Debis belongs to Mercedes Benz. Cheers, Kai   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25713; 11 Jun 96 15:47 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18326; 11 Jun 96 15:47 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25676; 11 Jun 96 15:47 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25476; 11 Jun 96 15:43 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18197; 11 Jun 96 15:43 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa25468; 11 Jun 96 15:42 EDT To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: cidrd@iepg.org Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: The IESG Subject: Protocol Action: Implications of Various Address Allocation Policies for Internet Routing to BCP Date: Tue, 11 Jun 96 15:42:53 -0400 X-Orig-Sender: scoya@CNRI.Reston.VA.US Message-ID: <9606111542.aa25468@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Draft "Implications of Various Address Allocation Policies for Internet Routing" for publication as a Best Current Practices RFC. This document is the product of the CIDR Deployment Working Group. The IESG contact persons are Scott Bradner and Michael O'Dell. Technical Summary The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. The major focus of this document is on two possible policies, "address ownership" and "address lending," and the technical implications of these policies for the Public Internet. For the organizations that could provide reachability to a sufficiently large fraction of the total destinations in the Internet, and could express such reachability through a single IP address prefix the document suggests to use the "address ownership" policy. However, applying the "address ownership" policy to every individual site or organization that connects to the Internet results in a non-scalable routing. Consequently, this document also recomments that the "address lending" policy should be formally added to the set of address allocation policies in the Public Internet. The document also recommends that organizations that do not provide a sufficient degree of routing information aggregation, but wish to obtain access to the Internet routing services should be strongly encouraged to use this policy to gain access to the services. Working Group Summary There was a clear consensus in the working group in support of this document. There was a spirited discussion in response to the IETF Last-Call but a consensus developed that, given the currently deployed routing technology, this document describes those practices which would best conserve the IPv4 address space and thus the document should be advanced as a BCP. Protocol Quality The document was reviewed for the IESG by Scott Bradner and Mike O'Dell. Note to RFC Editor: Please include the following text as part of the boilerplate: The addressing constraints described in this document are largely the result of the interaction of existing router technology, address assignment, and architectural history. After extensive review and discussion, the authors of this document, the IETF working group that reviewed it and the IESG have concluded that there are no other currently deployable technologies available to overcome these limitations. In the event that routing or router technology develops to the point that adequate routing aggregation can be achieved by other means or that routers can deal with larger routing and more dynamic tables, it may be appropriate to review these constraints.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04253; 11 Jun 96 21:59 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04249; 11 Jun 96 21:59 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa25047; 11 Jun 96 21:59 EDT Received: from nic.hq.cic.net (nic.hq.cic.net [198.108.58.2]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id KAA00755 for ; Wed, 12 Jun 1996 10:49:14 +1000 Received: from nic.hq.cic.net (dorian@nic.hq.cic.net [198.108.58.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id TAA03335 for ; Tue, 11 Jun 1996 19:57:21 -0400 (EDT) Date: Tue, 11 Jun 1996 19:57:21 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dorian Kim X-Orig-Sender: dorian@cic.net To: cidrd@iepg.org Subject: Protocol Action: Implications of Various Address Allocation Policies for Internet Routing to BCP (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Finally. -dorian ---------- Forwarded message ---------- Date: Tue, 11 Jun 96 15:42:53 -0400 From: The IESG To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , cidrd@iepg.org Subject: Protocol Action: Implications of Various Address Allocation Policies for Internet Routing to BCP The IESG has approved the Internet-Draft "Implications of Various Address Allocation Policies for Internet Routing" for publication as a Best Current Practices RFC. This document is the product of the CIDR Deployment Working Group. The IESG contact persons are Scott Bradner and Michael O'Dell. Technical Summary The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. The major focus of this document is on two possible policies, "address ownership" and "address lending," and the technical implications of these policies for the Public Internet. For the organizations that could provide reachability to a sufficiently large fraction of the total destinations in the Internet, and could express such reachability through a single IP address prefix the document suggests to use the "address ownership" policy. However, applying the "address ownership" policy to every individual site or organization that connects to the Internet results in a non-scalable routing. Consequently, this document also recomments that the "address lending" policy should be formally added to the set of address allocation policies in the Public Internet. The document also recommends that organizations that do not provide a sufficient degree of routing information aggregation, but wish to obtain access to the Internet routing services should be strongly encouraged to use this policy to gain access to the services. Working Group Summary There was a clear consensus in the working group in support of this document. There was a spirited discussion in response to the IETF Last-Call but a consensus developed that, given the currently deployed routing technology, this document describes those practices which would best conserve the IPv4 address space and thus the document should be advanced as a BCP. Protocol Quality The document was reviewed for the IESG by Scott Bradner and Mike O'Dell. Note to RFC Editor: Please include the following text as part of the boilerplate: The addressing constraints described in this document are largely the result of the interaction of existing router technology, address assignment, and architectural history. After extensive review and discussion, the authors of this document, the IETF working group that reviewed it and the IESG have concluded that there are no other currently deployable technologies available to overcome these limitations. In the event that routing or router technology develops to the point that adequate routing aggregation can be achieved by other means or that routers can deal with larger routing and more dynamic tables, it may be appropriate to review these constraints.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15217; 12 Jun 96 8:45 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15213; 12 Jun 96 8:45 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa07252; 12 Jun 96 8:45 EDT Received: from dns.sprintcorp.com (dns.sprintcorp.com [144.230.1.35]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id VAA06236 for ; Wed, 12 Jun 1996 21:19:32 +1000 Received: from qm by dns.sprintcorp.com (5.4R3.10/200.2.1.5) id AA26040; Wed, 12 Jun 1996 06:30:03 -0500 Message-Id: Date: 12 Jun 1996 07:34:02 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Pat Craig Subject: None To: "cidrd @iepg.org" X-Mailer: Mail*Link SMTP-QM 3.0.2 subscribe   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08345; 12 Jun 96 19:58 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08341; 12 Jun 96 19:58 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa19411; 12 Jun 96 19:58 EDT Received: from mailhub.cts.com (mailhub.cts.com [192.188.72.25]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA11938 for ; Thu, 13 Jun 1996 08:39:27 +1000 Received: from netguru.cts.com(really [206.170.122.137]) by mailhub.cts.com via smail with smtp id for ; Wed, 12 Jun 96 15:48:33 -0700 (PDT) (Smail-3.1.92 1996-Mar-19 #3 built 1996-Apr-21) Message-Id: <2.2.32.19960612225331.006ca0b0@mail.cts.com> X-Sender: kwe@mail.cts.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Jun 1996 15:53:31 -0700 To: Bob Hinden Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Kent W. England" Subject: BBN's class As [was RE: Address allocation stats] Cc: cidrd@iepg.org, nanog@merit.edu At 10:15 AM 6/7/96 -0700, Bob Hinden wrote: >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 > Perhaps BBN is waiting for the Internet Draft to become an RFC. [Come to PIARA BOF at IETF to discuss.] If so, these As could be worth millions of $. Best to let them alone for now. --Kent   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11005; 12 Jun 96 22:13 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11001; 12 Jun 96 22:13 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa21201; 12 Jun 96 22:13 EDT Received: from IMgate.iMach.com (IMgate.iMach.com [206.127.73.225]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA14850 for ; Thu, 13 Jun 1996 11:14:54 +1000 Received: (from forrestc@localhost) by IMgate.iMach.com (8.6.12/8.6.12) id TAA20031; Wed, 12 Jun 1996 19:24:13 -0600 Date: Wed, 12 Jun 1996 19:24:12 -0600 (MDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Forrest W. Christian" To: cidrd@iepg.org Subject: Need Global Routing Table (BGP) dump or summary. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm thinking about some interesting aggregation techniques using NAT (or more specifically address rewriting) techniques. I don't want to go into the gruesome details right now, but I need some information to play with. Generally, I'd like either a BGP dump of the full routing table (preferred, probably too big) or some sort of summary information which I can get the quantity of each length prefix that each origin-AS is announcing. I'd do it myself, but unfortunately, I don't have access a router will full routing tables. I envision coming up with a table like: AS Routes /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 /12 /13 ..... 1 0 0 0 0 0 0 0 1 0 0 2 2 3 4 ..... The results aren't going to come back to haunt anyone :) I need this to determine the quantity of the existing space which is being routed on the net, and how much of it is being announced by each AS. I only need a single copy of the data. Please drop me a note before you send (or make) a big BGP dump, in case someone else already has :) thanks, forrestc@imach.com   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00564; 12 Jun 96 23:10 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00558; 12 Jun 96 23:10 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa00254; 12 Jun 96 23:10 EDT Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id LAA15090 for ; Thu, 13 Jun 1996 11:36:13 +1000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmanning@isi.edu Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 12 Jun 1996 18:45:29 -0700 Posted-Date: Wed, 12 Jun 1996 18:44:56 -0700 (PDT) Message-Id: <199606130144.AA07919@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Wed, 12 Jun 1996 18:44:57 -0700 Subject: pedultimate aggregreation To: "Forrest W. Christian" Date: Wed, 12 Jun 1996 18:44:56 -0700 (PDT) Cc: cidrd@iepg.org In-Reply-To: from "Forrest W. Christian" at Jun 12, 96 07:24:12 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 349 is default... but I digress. There are some interesting, very prelim. numbers that indicate that full and agressive use of the CIDRassistant tool could reduce the number of prefixes announced from the current 35k+ by some 10K. Thats without renumbering or violating any existant, registered policies in the IRR. Something to chew on... --bill   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08594; 13 Jun 96 1:56 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08590; 13 Jun 96 1:56 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02529; 13 Jun 96 1:56 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08582; 13 Jun 96 1:56 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab08578; 13 Jun 96 1:56 EDT Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa02524; 13 Jun 96 1:56 EDT Received: by ginger.lcs.mit.edu id AA22664; Thu, 13 Jun 96 01:55:54 -0400 Date: Thu, 13 Jun 96 01:55:54 -0400 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9606130555.AA22664@ginger.lcs.mit.edu> To: cidrd@iepg.org, iesg@CNRI.Reston.VA.US Subject: Re: Protocol Action: Implications of Various Address Allocation Policies for Internet Routing to BCP (fwd) Cc: iab@isi.edu, jnc@ginger.lcs.mit.edu From: The IESG Please include the following text as part of the boilerplate: The addressing constraints described in this document are largely the result of the interaction of existing router technology, address assignment, and architectural history. After extensive review and discussion, the authors of this document, the IETF working group that reviewed it and the IESG have concluded that there are no other currently deployable technologies available to overcome these limitations. In the event that routing or router technology develops to the point that adequate routing aggregation can be achieved by other means or that routers can deal with larger routing and more dynamic tables, it may be appropriate to review these constraints. Sigh. OK, I will be polite, and not beat you violently and abusively about the ears with a sharp stick for what I consider to be saying something I consider ... hmmmm ... inoperable, to use a nice old Zieglerism. To say that "In the event that routing or router technology develops ... or that routers can deal with larger routing and more dynamic tables" is potentially very misleading, and saying "addressing constraints ... largely the result of the interaction of existing router technology, address assignment, and architectural history" is only slightly better. They could easily be taken to imply that this is largely an issue of resources. It's not. Here's a good way to see why (a way of putting it I just came up with, and hopefully a concise and readily understandable one): *** *The* fundamental issue in large scale routing is *throwing away *** information*. You *have* to do this if the routing is going to scale *** in a *practical* way in a large *real* system. That discarding of *** information *inevitably* involves aggregable routing-names - and this *** is true of *no matter what* routing architecture you use. I think it's very wise to study this statement until you grok it completely. It was good to mention "architectural history", which I take to mean the fact that the identifiers we are talking about are at the same time routing-names (which have this unavoidable constraint), plus serving other functions, functions in which people find the constraints that are placed on them by their use as routing-names onerous. However, you undid the good by mentioning resources. Routing-names will forever, down to the end of time (and past it, for that matter) have to be aggregable *to a certain degree* in a very large network. We will *never* run a global network in which routes to each host are computed separately. Exactly *how much* aggregation you have to do is a function of i) what you want the routing system to do, and ii) what kind of resources (memory, computes, bandwidth) etc you have available to deploy. The latter will provide a *floor* on how much aggregation you have to have, but it doesn't get rid of the need for some aggregation. (See passage above marked with ***'s). The conclusions are manifold. For example, if the 'Net is growing faster than hardware is getting faster... Sorry, you dudes, but saying "addressing constraints ... are largely the result of the interaction of existing router technology, address assignment" is just flat wrong. There will *always* be constraints on routing names (see passage ... etc), the only question is what level those will reach. And those constraints are fundamental... I'm not expecting that the added paragraph will get changed - although it would be nice if it did. At this point, I just don't care anymore - just publish the damn thing. I just want to make sure everyone understands up front that that statement is potentially very misleading. Noel   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04795; 13 Jun 96 16:49 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04791; 13 Jun 96 16:49 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17700; 13 Jun 96 16:49 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04776; 13 Jun 96 16:49 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04768; 13 Jun 96 16:49 EDT Received: from postman.ncube.com by CNRI.Reston.VA.US id aa17695; 13 Jun 96 16:49 EDT Received: from butler.ncube.com ([134.242.4.3]) by postman.ncube.com (4.1/SMI-4.1) id AA10789; Thu, 13 Jun 96 13:50:18 PDT Received: from skynet.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA04788; Thu, 13 Jun 1996 13:48:58 +0800 Date: Thu, 13 Jun 1996 13:48:58 +0800 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vadim Antonov Message-Id: <9606132048.AA04788@butler.ncube.com> To: cidrd@iepg.org, iesg@CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu Subject: Re: Protocol Action: Implications of Various Address Allocation Policies for Internet Routing to BCP (fwd) Cc: iab@isi.edu Content-Length: 1324 Noel Chiappa wrote: >Routing-names will forever, down to the end of time (and past it, for that >matter) have to be aggregable *to a certain degree* in a very large network. >We will *never* run a global network in which routes to each host are computed >separately. Never say never. It very much depends on medium -- if you have single-hop end-to-end medium (did i hear anybody say "radio"? :) you don't need any aggregation -- just choose your way of tuning (frequency, time division, code division et al). Now, if somebody comes up with Sub-Etha something which can carry enough bits our worries about routing can go poof (and there are people playing with quantum computers which can concievably make uber-code-division practical). To be nitpickingly precise, truely global (planet-wide, that's it) comm. network which does not employ aggregation of any kind exists for some seven decades now (i may be off with my chronology), so this is old news. Rather, the statement is applicable to relay networks with number of hops exceeding some trivial constant (2?). >There will *always* be constraints on routing names (see >passage ... etc), the only question is what level those will reach. And those >constraints are fundamental... Am i right to see ellipsis as an epistolar equivalent of handwaving? :) --vadim   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10310; 13 Jun 96 19:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10306; 13 Jun 96 19:07 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20701; 13 Jun 96 19:07 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10296; 13 Jun 96 19:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10290; 13 Jun 96 19:07 EDT Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa20691; 13 Jun 96 19:07 EDT Received: by ginger.lcs.mit.edu id AA27217; Thu, 13 Jun 96 19:06:48 -0400 Date: Thu, 13 Jun 96 19:06:48 -0400 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9606132306.AA27217@ginger.lcs.mit.edu> To: avg@postman.ncube.com, cidrd@iepg.org, iesg@CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu Subject: Re: Protocol Action: Implications of Various Address Allocation Policies for Internet Routing to BCP (fwd) Cc: iab@isi.edu, jnc@ginger.lcs.mit.edu From: avg@postman.ncube.com (Vadim Antonov) Never say never. It very much depends on medium -- if you have single-hop end-to-end medium ... you don't need any aggregation ... if somebody comes up with Sub-Etha something which can carry enough bits our worries about routing can go poof ... the statement is applicable to relay networks with number of hops exceeding some trivial constant (2?). Right, I was assuming the "global communication network" was indeed a *network*. To be very precise and formal, the statement holds if the communication links form a graph, one in which the order of all the nodes is a small fraction of the total number of nodes in the graph. Formal enough for you? :-) > There will *always* be constraints on routing names (see passage ... > etc), the only question is what level those will reach. And those > constraints are fundamental... Am i right to see ellipsis as an epistolar equivalent of handwaving? :) No, it was just repetition of what I'd said in the paragraph above, didn't feel like retyping the whole thing. Noel   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20834; 16 Jun 96 21:51 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20830; 16 Jun 96 21:51 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa15707; 16 Jun 96 21:51 EDT Received: from ftp.com (ftp.com [128.127.2.122]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id KAA26467 for ; Mon, 17 Jun 1996 10:29:41 +1000 Received: from ftp.com by ftp.com ; Sun, 16 Jun 1996 20:39:03 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Sun, 16 Jun 1996 20:39:03 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id UAA00545; Sun, 16 Jun 1996 20:39:03 -0400 Message-Id: In-Reply-To: <199605282359.QAA27104@lint.cisco.com> References: Conversation <199605282359.QAA27104@lint.cisco.com> with last message <199605282359.QAA27104@lint.cisco.com> Priority: Normal To: Paul Ferguson , cidrd@iepg.org Cc: nanog@merit.edu, pier@isi.edu Mime-Version: 1.0 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank T Solensky Subject: Re: Address allocation stats Date: Sun, 16 Jun 96 20:38:27 EDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit > 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04615; 18 Jun 96 16:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04608; 18 Jun 96 16:01 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa19249; 18 Jun 96 16:01 EDT Received: from ftp.com (ftp.com [128.127.2.122]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA21607 for ; Wed, 19 Jun 1996 04:52:38 +1000 Received: from ftp.com by ftp.com ; Tue, 18 Jun 1996 15:02:20 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 18 Jun 1996 15:02:20 -0400 Received: from solensky-1 by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id PAA19405; Tue, 18 Jun 1996 15:02:18 -0400 Message-Id: In-Reply-To: <199606181846.UAA05450@vader.runit.sintef.no> References: Conversation with last message <199606181846.UAA05450@vader.runit.sintef.no> Priority: Normal To: Havard.Eidnes@runit.sintef.no Cc: cidrd@iepg.org, nanog@merit.edu, pier@isi.edu Mime-Version: 1.0 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank T Solensky Subject: Re: Address allocation stats Date: Tue, 18 Jun 96 15:01:47 EDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit > 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..   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04822; 18 Jun 96 16:08 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04816; 18 Jun 96 16:08 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa19420; 18 Jun 96 16:08 EDT Received: from vader.runit.sintef.no (vader.runit.sintef.no [129.241.100.134]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id EAA21509 for ; Wed, 19 Jun 1996 04:37:38 +1000 Received: from runit.sintef.no (localhost [127.0.0.1]) by vader.runit.sintef.no (8.6.12/8.6.12) with ESMTP id UAA05450; Tue, 18 Jun 1996 20:46:55 +0200 Message-Id: <199606181846.UAA05450@vader.runit.sintef.no> To: solensky@ftp.com Cc: pferguso@cisco.com, cidrd@iepg.org, nanog@merit.edu, pier@isi.edu Subject: Re: Address allocation stats Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Havard.Eidnes@runit.sintef.no In-Reply-To: Your message of "Sun, 16 Jun 96 20:38:27 EDT" References: X-Mailer: Mew version 1.00.4 on Emacs 19.30.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 18 Jun 1996 20:46:55 +0200 X-Orig-Sender: he@runit.sintef.no > 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09068; 18 Jun 96 17:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09064; 18 Jun 96 17:42 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa21748; 18 Jun 96 17:42 EDT Received: from bugsy.aa.ans.net (bugsy.aa.ans.net [198.83.21.9]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id GAA22093 for ; Wed, 19 Jun 1996 06:01:16 +1000 Received: from loopback (dwm@loopback [127.0.0.1]) by bugsy.aa.ans.net (8.7.5/8.7.3) with SMTP id UAA157416; Tue, 18 Jun 1996 20:10:55 GMT Message-Id: <199606182010.UAA157416@bugsy.aa.ans.net> X-Authentication-Warning: bugsy.aa.ans.net: Host dwm@loopback [127.0.0.1] didn't use HELO protocol Position: Staff Engineer Company: ANS Location: ANS Network Services, Ann Arbor, MI To: Havard.Eidnes@runit.sintef.no cc: solensky@ftp.com, pferguso@cisco.com, cidrd@iepg.org, nanog@merit.edu, pier@isi.edu Subject: Re: Address allocation stats In-reply-to: Message from of Tue Jun 18, 1996 20:46 EDT <199606181846.UAA05450@vader.runit.sintef.no> Date: Tue, 18 Jun 1996 16:10:53 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Daniel W. McRobb" > > 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 # 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 $ } } } 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 ] [-depth ] [-density ] .ps\n\n"; }   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08225; 20 Jun 96 2:31 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08221; 20 Jun 96 2:31 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02720; 20 Jun 96 2:31 EDT Received: from slam.internic.net (slam.internic.net [198.41.0.36]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id PAA16874 for ; Thu, 20 Jun 1996 15:04:32 +1000 Received: (markk@localhost) by slam.internic.net (8.7.4/SLAM-1) id BAA01595; Thu, 20 Jun 1996 01:14:36 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Kosters Message-Id: <199606200514.BAA01595@slam.internic.net> Subject: Re: Address allocation stats To: Frank T Solensky Date: Thu, 20 Jun 1996 01:14:35 -0400 (EDT) Cc: Havard.Eidnes@runit.sintef.no, cidrd@iepg.org, nanog@merit.edu, pier@isi.edu In-Reply-To: from "Frank T Solensky" at Jun 18, 96 03:01:47 pm X-Mailer: ELM [version 2.4 PL24alpha4] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26744; 25 Jun 96 19:48 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26740; 25 Jun 96 19:48 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa16876; 25 Jun 96 19:48 EDT Received: from bbnplanet.com (poblano.near.net [198.114.157.116]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id IAA00558 for ; Wed, 26 Jun 1996 08:36:53 +1000 Received: from ietf192-50.ietf.risq.qc.ca by poblano.bbnplanet.com id aa00875; 25 Jun 96 17:41 EDT X-Sender: jcurran@198.114.157.116 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Phone: (617) 873-4398 USMail: 150 CambridgePark Drive, Cambridge, MA, 02140 Date: Tue, 25 Jun 1996 17:41:50 -0400 To: cidrd@iepg.org Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Curran Subject: CIDRD WG Minutes [DRAFT] - The Final Meeting CIDRD WG Minutes - Final Meeting (6/25/96) Tony Li & Vince Fuller, Co-Chairs Note: As the work of this group is now finished, this working group will conclude per agreement of the WG chairs and the OPS Area Directors. o Agenda Bashing o Document Status Classless IN-ADDR (draft-ietf-cidrd-classless-inaddr-01.txt) Document with minor edits underwent last call process and is awaiting publication as RFC (with BCP status). Address Ownership (draft-ietf-cidrd-addr-ownership-07.txt) Scott Bradner indicated that this was passed by the IESG for a publication as a Best Current Practices RFC. Registry Guidelines (draft-hubbard-registry-guidelines-02.txt) Scott Bradner indicated IESG has placed consideration of this draft on hold till the next IETF, and encouraged the WG to email their views on this document to the IESG. o Statistics Vince Fuller presented a graph of routing prefixes in the Internet (provided by Erik-Jan Bos of SURFnet) and the growth in the routing table appears linear. Several sharp downward spikes in the routing table appeared to correspond to IETF meetings. Frank Solensky presented a graph of class B and C address space address assignment, and the extrapolated allocation curves have appeared to flattened out significantly. It was suggested that this was the result of stricter adherance to to standard address allocation policies by registries. o Other Topics Eventual depletion of AS numbers was raised as an issue; the BGP4 protocol allows 2^16 worth of AS numbers. It was suggested that IDRP was the appropriate long-term solution, as it allows much longer autonomous system numbers. Bill Manning presented a short review of some of the CIDRD working group activities, and noted that many were "policy" docs. Bill asked: "Should the IETF do policy documents?" Scott Bradner led a discussion of whether we need some group in the IETF which addresses such issues on an ongoing basis. Discussion continued to fill the available time slot, touching on topics such as the IESG's ability to set policies, other network provider forums which work on policy issues, and the possibility of creating an ongoing working group or maintaining an open meeting to handle operational policy issues. Some folks felt that it was important to have an active forum for customers, operators, and developers in one place in order to continue the interaction which has occured in CIDR. A show of hands reflected an overall weak interest in moving forward with this proposal at the current time.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07313; 27 Jun 96 2:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07309; 27 Jun 96 2:01 EDT Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02308; 27 Jun 96 2:01 EDT Received: from hq.barrnet.net (hq.barrnet.net [204.160.73.5]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id OAA10315 for ; Thu, 27 Jun 1996 14:49:18 +1000 Received: (from vaf@localhost) by hq.barrnet.net (8.7.5/HQ-Len-1.1) id VAA21299 for cidrd@iepg.org; Wed, 26 Jun 1996 21:49:18 -0700 (PDT) Date: Wed, 26 Jun 96 21:49:17 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vince Fuller To: cidrd@iepg.org Phone: (415) 528-7227 USMail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: Re: CIDRD WG Minutes [DRAFT] - The Final Meeting Message-ID: FYI- Please send any comments on these minutes by 23:59-PDT on Friday, July 12th. After that time, they will be submitted to the IETF Secretariat. --Vince