- Test - lists.nanog.org

Re: Internic address allocation policy
by jis＠mit.edu 21 Mar '95

21 Mar '95

At 8:23 3/21/95, yakov(a)watson.ibm.com wrote: >There are certain *fundamental* issues that one may choose to ignore. >However, this still doesn't change the fundamental property of these >issues. Relation between address space allocation/management and >the ability of the Internet routing system to scale is *one of these >issues*. There are also fundamental requirements. Not all of these requirements are strictly technical (like the requirement that routing scale "nicely"). I believe that one of the non-technical requirements, but a requirement nonetheless, is for end-user organizations to be able to change providers without an exorbitant penalty. With today's technology, renumbering (of a reasonably large organization) amounts to such a penalty. I didn't say that meeting this requirement would be easy. But that doesn't mean that it can simply be ignored because it is too hard. I point out that in the U.S. the Federal Communications Commission (FCC) has mandated that 800 numbers be portable. I am sure that created a real routing headache within the telephone network. I can make all the same scaling arguments that you use about Internet routing also apply to the phone network's 800 numbers. Doesn't change the fact of the FCC action. My concern is this. If we march down the aggregation path too far we will have ISPs (both large and small) that require customers to get addresses from them where they (the ISP) maintain ownership of the address space. At some point some (perhaps large) ISP's service will degrade and customers seeking to move to another provider will suddenly realize how locked in they are. If enough customers are put into such a situation many will call for regulation of the network (if it isn't already in place by then) and demand IP address portability. We can then wind up with such portability being mandated from on high, with little thought. I would prefer to recognize this problem now and begin to see how we can address it. One solution is for IPv6 to fulfill its promise of providing autoconfiguration (complete with secure, dynamic, DNS updating). One of my fears is that autoconfiguration will not be a priority (because most users won't need its capabilities, at least immediately) so will not be fully specified and implemented until it is too late. -Jeff

1 0

Internic address allocation policy
by yakov＠watson.ibm.com 21 Mar '95

21 Mar '95

Ref: Your note of Mon, 20 Mar 1995 14:26:03 -0500 Jeff, >... I am very concerned about having the ISPs performing address >allocation, particularly addressing aggregation. There are certain *fundamental* issues that one may choose to ignore. However, this still doesn't change the fundamental property of these issues. Relation between address space allocation/management and the ability of the Internet routing system to scale is *one of these issues*. Here is a brief recap of what had been stated on MANY occasions. The need to accommodate routing in the growing Internet requires to perform routing information aggregation/abstaction. Both the current routing technology, as well as proposals for new routing technologies (e.g. Nimrod or Unified) assume that the hierarchical routing information aggregation/abstraction will be used as *the* fundamental technique to deal with the growth in overhead costs of running the routing. For the hierarchical routing to work, addresses have to reflect *where* in the network you are. Changing providers means you've changed where you are, which in turn means you may need to change your addresses. Host autoconfiguration capabilities isn't a "rocket space" science, but would certainly greatly help to accommodate the ability to change providers in presence of hierarchical routing. Granted this wouldn't address the problem of dealing with the installed based, but we are not aware of any other alternative (except for the NAT boxes and/or application layer gateway alternative) that wouldn't require *any* changes to the installed base, while at the same time would accommodate hierarchical routing and would allow to change providers. Noel Chiappa & Yakov Rekhter

2 1

Re: Internic address allocation policy
by jis＠mit.edu 20 Mar '95

20 Mar '95

At 22:05 3/19/95, Vadim Antonov wrote: >You may like it or dislike it but nation-wide backbone providers >effectively run the Internet nowadays. It is a rare case when >big businesses actually introduced some common sense in the way >things are done architecture-wise. Why not to do the same with >the address allocation? Speaking from a (large) user organization. I am very concerned about having the ISPs performing address allocation, particularly aggregating addresses. As a user, I want to be able to change my service provider if I get a better deal from a competitor or am having service difficulties with my current provider. Today's technology for managing addresses on individual computers makes it very hard for an organization to renumber. Literally every computer administrator needs to be in the loop. This can be a large loop when you have 13,000+ independently managed machines (like we do). How do we users get our say to ensure that an addressing architecture doesn't come into existence which tends to lock us into a particular provider? -Jeff

5 10

Re: Internic address allocation policy
by Vadim Antonov 20 Mar '95

20 Mar '95

> How do we users get our say to ensure that an addressing architecture > doesn't come into existence which tends to lock us into a particular > provider? Fund my TRAP research? (See pre-publication drafts in ftp.sprintlink.net:engineer/avg). I'm doing it on my own time. --vadim

1 0

Plans
by johnr＠geo.net 20 Mar '95

20 Mar '95

>If not, you don't have an idea of what your business is going to be >doing. As I said above, you may plan wrong, but you sure as HELL should >have a plan that at least goes a year into the future. > >> No damn way. No ISP in the business can possibly do that and be telling the >> truth. > >I don't appreciate being called a liar, Karl. > >They asked for a PLAN, I supplied a PLAN. > >-abc > > Alan B. Clegg > Information Systems Manager > American Research Group He who fails to plan, plans to fail! Right on Alan! John A. Russo GeoNet Communications, Inc.

2 1

Additions to the NSFNET policy-based routing database
by smm＠twain.merit.edu 20 Mar '95

20 Mar '95

------------------------------------------------------------------------------ The PRDB and this "NWG report" will be retired very soon. Details below. ------------------------------------------------------------------------------ The following changes have been made to the NSFNET policy-based routing database and will be installed on the backbone by 08:00 EST : Total = As + Bs + Cs + Aggs Registered Networks 49445 = 30 5339 40912 3164 Configured Networks 46532 = 30 5282 38120 3100 Added Networks 140 = 0 4 118 18 Deleted Networks 4 = 0 2 1 1 IP address Net name Country Priority:AS ---------- -------- ------- ----------- 135.16/16 NNTEST.ATT.COM C:US 1:2386 2:1321 141.197/16 FLUORDANIEL C:US 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) 158.51/16 ELECTRO C:CA 1:1240 2:1800 3:1239 165.103/16 NAICNET C:US 1:3561(27) 2:3561(218) 3:3561(147) 4:3561(11) 5:3561(144) 192.54.53/24 BINTEC-LAN C:DE 1:1800 2:1239(144) 3:1133 192.72.2/23 NET-HINET C:TW 1:1800 2:1239(218) 3:1239(144) 4:1321 192.86.154/23 ORACLE C:US 1:3561(11) 2:3561(144) 3:3561(218) 192.102.146/23 FHG-BLOCK-192.102.146 C:DE 1:1800 2:1239(144) 3:1133 192.102.148/22 FHG-BLOCK-192.102.148 C:DE 1:1800 2:1239(144) 3:1133 192.102.152/21 FHG-BLOCK-192.102.152 C:DE 1:1800 2:1239(144) 3:1133 192.102.160/20 FHG-BLOCK-192.102.160 C:DE 1:1800 2:1239(144) 3:1133 192.102.176/23 FHG-BLOCK-192.102.176 C:DE 1:1800 2:1239(144) 3:1133 192.198.151/24 NETBLK-CIS C:US 1:701(136) 2:701(134) 192.198.152/24 NETBLK-CIS C:US 1:701(136) 2:701(134) 192.198.153/24 NETBLK-CIS C:US 1:701(136) 2:701(134) 192.223.179/24 NETBLK-FIDELITYI C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 192.233.131/24 MGH-EXT1 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 192.233.132/24 MGH-EXT2 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 193.47.230/24 INFNET C:CH 1:1133 2:1674 3:1800 193.51.174/24 FR-ARCHITECTURE-ROUEN C:FR 1:1800 2:1240 3:1133 4:1674 193.52.202/24 FR-ARNAUD-VILLENEUVE C:FR 1:1800 2:1240 3:1133 4:1674 193.52.218/24 COMINFO-ROUEN C:FR 1:1800 2:1240 3:1133 4:1674 193.52.219/24 ESC-NORMANDIE C:FR 1:1800 2:1240 3:1133 4:1674 193.54.73/24 FR-PALAIS-DECOUVERTE C:FR 1:1800 2:1240 3:1133 4:1674 193.54.74/24 UNISYS-EEMO C:FR 1:1800 2:1240 3:1133 4:1674 193.54.255/24 FR-ENVA C:FR 1:1800 2:1240 3:1133 4:1674 193.55.145/24 FR-ENITIAA C:FR 1:1800 2:1240 3:1133 4:1674 194.8.1/24 LVNET-TEST-C-8-1 C:LV 1:1800 2:1133 3:1240 194.8.2/24 LVNET-TEST-C-8-2 C:LV 1:1800 2:1133 3:1240 194.8.3/24 LVNET-TEST-C-8-3 C:LV 1:1800 2:1133 3:1240 194.8.4/24 LVNET-TEST-C-8-4 C:LV 1:1800 2:1133 3:1240 194.8.16/24 LATTELEKOM-C-8-16 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.17/24 LATTELEKOM-C-8-17 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.18/24 LATTELEKOM-C-8-18 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.19/24 LATTELEKOM-C-8-19 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.20/24 LATTELEKOM-C-8-20 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.21/24 LATTELEKOM-C-8-21 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.22/24 LATTELEKOM-C-8-22 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.23/24 LATTELEKOM-C-8-23 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.24/24 LATTELEKOM-C-8-24 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.25/24 LATTELEKOM-C-8-25 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.26/24 LATTELEKOM-C-8-26 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.27/24 LATTELEKOM-C-8-27 C:LV 1:1800 2:1879 3:1133 4:1240 194.57.125/24 FR-DRCNRS C:FR 1:1800 2:1240 3:1133 4:1674 198.160.164/22 TMCMB C:US 1:701(136) 2:701(134) 198.160.168/23 TMCMB C:US 1:701(136) 2:701(134) 198.168.253/24 FORTRESS-ORG C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 198.176.64/18 TMCMB2 C:US 1:701(136) 2:701(134) 198.180.131/24 BIOGEN C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 199.43.115/24 UNIVERSAL C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 199.60.222/24 FN-VICTORIA C:CA 1:1331 199.81.21/24 NETBLK-FEDEX101 C:US 1:1330 199.81.23/24 NETBLK-FEDEX101 C:US 1:1330 199.92.18/24 CAMDEN-LIB-ME C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 199.92.201/24 CALLNET-201 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 199.166.222/24 TERRAPORT-NET C:CA 1:2493(35) 2:2493(91) 199.166.223/24 TERRAPORT-NET C:CA 1:2493(35) 2:2493(91) 199.181.186/24 JJNET C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 199.221.224/24 RRNET C:US 1:1323 199.222.29/24 ABQ-NET C:US 1:1334 200.10.212/24 COMCRED-1 C:MX 1:114 2:3561(11) 3:3561(218) 4:278 5:1328 202.6.100/23 ABAC C:TH 1:701(136) 2:701(134) 202.44.144/24 KSCNET-TH C:TH 1:701(136) 2:701(134) 203.250.114/23 APNIC-CIDR-BLK C:KR 1:1800 2:1239(144) 203.250.116/23 APNIC-CIDR-BLK C:KR 1:1800 2:1239(144) 203.250.184/21 APNIC-CIDR-BLK C:KR 1:1800 2:1239(144) 204.19.166/24 VARNET C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 204.19.167/24 VARNET C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 204.86.235/24 LIIK.NET C:US 1:1240 2:1800 3:1239 204.150.132/24 ANS-C-BLOCK3 C:US 1:1325 204.168.158/24 NET-JERICHO C:US 1:1239(218) 2:1800 3:1239(144) 204.168.248/21 NET-MONROE C:US 1:1239(218) 2:1800 3:1239(144) 204.187.49/24 HWC-CA C:CA 1:577(133) 2:577(137) 3:577(143) 4:3561(218) 5:3561(11) 204.236.0/19 MEDIO-NET C:US 1:3561(11) 2:3561(218) 3:685 4:73 5:101 6:1239(144) 7:1239(147) 8:1239(218) 9:1800 204.253.128/22 CONNECT C:US 1:701(136) 2:701(134) 205.136.0/24 CWI-NET-C-136-0 C:US 1:701 2:1239 3:1800 4:1240 205.136.1/24 CWI-NET-C-136-1 C:US 1:701 2:1239 3:1800 4:1240 205.136.2/24 CWI-NET-C-136-2 C:US 1:701 2:1239 3:1800 4:1240 205.136.3/24 CWI-NET-C-136-3 C:US 1:701 2:1239 3:1800 4:1240 205.136.4/24 CWI-NET-C-136-4 C:US 1:701 2:1239 3:1800 4:1240 205.136.5/24 CWI-NET-C-136-5 C:US 1:701 2:1239 3:1800 4:1240 205.136.6/24 CWI-NET-C-136-6 C:US 1:701 2:1239 3:1800 4:1240 205.136.7/24 CWI-NET-C-136-7 C:US 1:701 2:1239 3:1800 4:1240 205.136.8/24 CWI-NET-C-136-8 C:US 1:701 2:1239 3:1800 4:1240 205.136.9/24 CWI-NET-C-136-9 C:US 1:701 2:1239 3:1800 4:1240 205.136.10/24 CWI-NET-C-136-10 C:US 1:701 2:1239 3:1800 4:1240 205.136.11/24 CWI-NET-C-136-11 C:US 1:701 2:1239 3:1800 4:1240 205.136.12/24 CWI-NET-C-136-12 C:US 1:701 2:1239 3:1800 4:1240 205.136.13/24 CWI-NET-C-136-13 C:US 1:701 2:1239 3:1800 4:1240 205.136.14/24 CWI-NET-C-136-14 C:US 1:701 2:1239 3:1800 4:1240 205.136.15/24 CWI-NET-C-136-15 C:US 1:701 2:1239 3:1800 4:1240 205.136.16/24 CWI-NET-C-136-16 C:US 1:701 2:1239 3:1800 4:1240 205.136.17/24 CWI-NET-C-136-17 C:US 1:701 2:1239 3:1800 4:1240 205.136.18/24 CWI-NET-C-136-18 C:US 1:701 2:1239 3:1800 4:1240 205.136.19/24 CWI-NET-C-136-19 C:US 1:701 2:1239 3:1800 4:1240 205.136.20/24 CWI-NET-C-136-20 C:US 1:701 2:1239 3:1800 4:1240 205.136.21/24 CWI-NET-C-136-21 C:US 1:701 2:1239 3:1800 4:1240 205.136.22/24 CWI-NET-C-136-22 C:US 1:701 2:1239 3:1800 4:1240 205.136.23/24 CWI-NET-C-136-23 C:US 1:701 2:1239 3:1800 4:1240 205.136.24/24 CWI-NET-C-136-24 C:US 1:701 2:1239 3:1800 4:1240 205.136.25/24 CWI-NET-C-136-25 C:US 1:701 2:1239 3:1800 4:1240 205.136.26/24 CWI-NET-C-136-26 C:US 1:701 2:1239 3:1800 4:1240 205.136.27/24 CWI-NET-C-136-27 C:US 1:701 2:1239 3:1800 4:1240 205.136.28/24 CWI-NET-C-136-28 C:US 1:701 2:1239 3:1800 4:1240 205.136.29/24 CWI-NET-C-136-29 C:US 1:701 2:1239 3:1800 4:1240 205.136.30/24 CWI-NET-C-136-30 C:US 1:701 2:1239 3:1800 4:1240 205.136.31/24 CWI-NET-C-136-31 C:US 1:701 2:1239 3:1800 4:1240 205.136.32/24 CWI-NET-C-136-32 C:US 1:701 2:1239 3:1800 4:1240 205.136.33/24 CWI-NET-C-136-33 C:US 1:701 2:1239 3:1800 4:1240 205.136.34/24 CWI-NET-C-136-34 C:US 1:701 2:1239 3:1800 4:1240 205.136.35/24 CWI-NET-C-136-35 C:US 1:701 2:1239 3:1800 4:1240 205.136.36/24 CWI-NET-C-136-36 C:US 1:701 2:1239 3:1800 4:1240 205.136.37/24 CWI-NET-C-136-37 C:US 1:701 2:1239 3:1800 4:1240 205.136.38/24 CWI-NET-C-136-38 C:US 1:701 2:1239 3:1800 4:1240 205.136.39/24 CWI-NET-C-136-39 C:US 1:701 2:1239 3:1800 4:1240 205.136.40/24 CWI-NET-C-136-40 C:US 1:701 2:1239 3:1800 4:1240 205.136.41/24 CWI-NET-C-136-41 C:US 1:701 2:1239 3:1800 4:1240 205.136.42/24 CWI-NET-C-136-42 C:US 1:701 2:1239 3:1800 4:1240 205.136.43/24 CWI-NET-C-136-43 C:US 1:701 2:1239 3:1800 4:1240 205.136.44/24 CWI-NET-C-136-44 C:US 1:701 2:1239 3:1800 4:1240 205.136.45/24 CWI-NET-C-136-45 C:US 1:701 2:1239 3:1800 4:1240 205.136.46/24 CWI-NET-C-136-46 C:US 1:701 2:1239 3:1800 4:1240 205.136.47/24 CWI-NET-C-136-47 C:US 1:701 2:1239 3:1800 4:1240 205.136.48/24 CWI-NET-C-136-48 C:US 1:701 2:1239 3:1800 4:1240 205.136.49/24 CWI-NET-C-136-49 C:US 1:701 2:1239 3:1800 4:1240 205.136.50/24 CWI-NET-C-136-50 C:US 1:701 2:1239 3:1800 4:1240 205.136.51/24 CWI-NET-C-136-51 C:US 1:701 2:1239 3:1800 4:1240 205.136.52/24 CWI-NET-C-136-52 C:US 1:701 2:1239 3:1800 4:1240 205.136.53/24 CWI-NET-C-136-53 C:US 1:701 2:1239 3:1800 4:1240 205.136.54/24 CWI-NET-C-136-54 C:US 1:701 2:1239 3:1800 4:1240 205.136.55/24 CWI-NET-C-136-55 C:US 1:701 2:1239 3:1800 4:1240 205.136.56/24 CWI-NET-C-136-56 C:US 1:701 2:1239 3:1800 4:1240 205.136.57/24 CWI-NET-C-136-57 C:US 1:701 2:1239 3:1800 4:1240 205.136.58/24 CWI-NET-C-136-58 C:US 1:701 2:1239 3:1800 4:1240 205.136.59/24 CWI-NET-C-136-59 C:US 1:701 2:1239 3:1800 4:1240 205.136.60/24 CWI-NET-C-136-60 C:US 1:701 2:1239 3:1800 4:1240 205.136.61/24 CWI-NET-C-136-61 C:US 1:701 2:1239 3:1800 4:1240 205.136.62/24 CWI-NET-C-136-62 C:US 1:701 2:1239 3:1800 4:1240 205.136.63/24 CWI-NET-C-136-63 C:US 1:701 2:1239 3:1800 4:1240 205.155/16 NETBLK-CSUNET-NORTH2 C:US 1:3561(11) 2:3561(218) 3:200(128) 4:200(144) 5:2150(135) Deletions: --138.187/16 INFNET-PTT1 C:CH 1:1133 2:1674 3:1800 --138.190/16 INFNET-PTT3 C:CH 1:1133 2:1674 3:1800 --192.122.236/24 CORNELL-DMZ2 C:US 1:26 --199.221.224/19 RRNET-AGG C:US 1:1323 Expanded listing, sorted by country, then by organization: ========================================================== The "Expanded Listings" section of this NWG report has been retired since it is sorted by countries and network organization addresses. The replacement configuration generation system is based on the Internet Routing Registry (briefly called the "Global Routing Registry"). See the file ftp.ra.net:pub/radb/OVERVIEW for more information. The remainder of this report will also be retired shortly. AS690 CIDR Squeezings Report: 11310 Nets, 185 ASs, 3161 Aggregates ------------------------------------------------------------------- 11310 (84%) of the ever-announced more-specific routes within aggregates have been withdrawn. 1303 of those were withdrawn within the last week. 246 the week before that. 374 the week before that. 185 ASs have registered aggregates in the PRDB. 167 of those are announcing aggregates. 91 have withdrawn at least one more specific route. 3161 Aggregates are configured. 2132 of these were Top-Level Aggregates (not nested in another aggregate). 1663 of these are being announced to AS690. 1052 of those have at least one subnet configured (the other 611 may be saving the Internet future subnet announcements). 907 have stopped announcing at least one configured more specific route. 878 have stopped announcing half of their configured more specific routes. 842 have stopped announcing most (80%) of their more specific routes. See home.merit.edu:pub/nsfnet/cidr/cidr_savings for more detail. ----------------------------------------------------------- ========================================================== The configuration reports which reflect today's update will be available for anonymous ftp on nic.merit.edu by 08:00 EST : configuration reports -- nic.merit.edu:nsfnet/announced.networks: as-as.now as-gw.now ans_core.now country.now net-comp.now nets.doc nets.non-classful nets.tag.now nets.unl.now NSS routing software configuration files -- nic.merit.edu:nsfnet/backbone.configuration: gated.nss<NSS number>.t3p Information is also avaiable through the PRDB whois server. Type "whois -h prdb.merit.edu help" for details. -------------------------------------------------------------------------- PRDB CHANGES: (Updated January 19, 1994) As of 1/19/95, ACKs and NAKs will no loger be required (or even read) in the processing of NACRs. In early 1995, as part of the transition to the new Internet Routing Registry (IRR), the Policy Routing Database (PRDB) will be retired. Many of the functions of the PRDB (including generation of router configurations for NSFNET) will be produced based on data from the Global Routing Registry. This change to the NSFNET Backbone service will involve the following changes: - The method for submitting new nets to be routed over AS690 will change. Instead of submitting a NACR to nsfnet-admin(a)merit.edu, you will need to submit a "route template" to auto-dbm(a)ra.net . - Additions and entries to the new registry will be made by the Home AS which creates the route for each net, rather than being submitted by a AS690 peer AS. - Most of the PRDB reports (listed above) will no longer be produced. Equivalent information for most of these reports is available from the global Routing Registry. These are major changes to the system. These changes are being made in order to migrate NSFNET customers and the global user community to a global Internet Routing Registry system, which will be more capable of supporting user needs after the termination of the NSFNET Backbone services in April 1995. For more information, set your web browser to http://www.ra.net/rrinfo.html , or use anonymous ftp to obtain the files "OVERVIEW" and from the directory "ftp.ra.net:pub/radb". Merit would like to minimize the number of problems that this transition may cause you. In order to help us help you through the transition, please send your concerns, your needs, and suggestions on how we can make this happen smoothly to merit-ie(a)merit.edu. The archived discussion list "db-disc(a)merit.edu" also exists for discussion of PRDB and RADB issues. Send a message to "db-disc-request(a)merit.edu" to subscribe. --Dale Johnson (dsj(a)merit.edu) -------------------------------------------------------------------------- Please send all requests for configuration changes to nsfnet-admin(a)merit.edu using the NSFNET configuration forms. The forms are available on-line from the nic.merit.edu machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfnet/announced.networks" and get the files template.net, template.net.README, template.gate, and template.as. *** Note: As of March 1, 1994, NSFNET AUP NACRs must use the template.net *** (NACR) version 7.1, or the NACR will be returned unprocessed. ******************************* --Stephen McNutt Merit/NSFNET smm(a)merit.edu --Steven J. Richardson Merit/NSFNET sjr(a)merit.edu

1 0

Re: A slight call to order (Re: Internic address allocation policy )
by johnr＠geo.net 20 Mar '95

20 Mar '95

>I know of several >providers who are chopping things up on nybble boundaries (16 hosts/net, or >actually 14 with the subnet zero and broadcast taken out). We are having do to this with our Class B.

1 0

Internet address allocation policy
by Jerry Marsh 20 Mar '95

20 Mar '95

I too am having increasing difficulty getting address from Internic without tons of justification. One small point I would like to make: There is an implicit assumption here that the addresses requested are for immediate use on the Internet. Many State agencies here are moving to TCP/IP based networks. This is as much for interconnectivity among ourselves as anything else. They may initially not even connect to other State agencies, let alone the Internet. That does not reduce their need to have coordinated addresses. The last thing they need to do is deploy a network with bogus addresses and then have to change the addresses when they interconnect with others/Internet. They could request small blocks of "C" themselves, but it makes more sense to me to use sub-block of CIDRs that I manage when they have intent of eventually attaching to the Internet thru us. Jerry Marsh | State of Washington - DIS/TSD - MS 2450 jerrym(a)dis.wa.gov | Olympia, Wa 98504-2450 voice: 360-902-3311

1 0

Re: A slight call to order (Re: Internic address allocation policy ) (fwd)
by karl＠mcs.com 20 Mar '95

20 Mar '95

> From: Brett Watson <bwatson(a)diamond.cary.mci.net> > > It just seems to me that everyone is taking all of this way out > of bounds. The internic is strict and sometimes contradicts > itself, I agree. but all they ask for is a plan, or rather and > *estimate*. Karl, you say you can't possibly guess those > numbers? How do you do business then? You've got to be able to > estimate business and market growth (not bashing you, just don't > understand). > > -brett No, what I'm saying is that it is none of the NIC's concern what my growth plan looks like, or what my business plan looks like. If someone else is willing to turn over a business plan, that's their choice, but IMHO that's really, really stupid. As in possibly suicidally stupid. I would give my left nut (pardon the vernacular) for some of these business plans. They are absolutely golden in terms of their value to a competitor in the areas of the country you do business, and anyone who doesn't understand that really ought to be working for someone else rather than running a company in this, or any other, marketplace. There are all kinds of interesting pieces of information in our business plan, and many of them would be VERY useful to a competitor. For that reason that piece of paper is to be found only in our vault at the bank, and in an encrypted (strongly!) file on a PC in my home. The NIC can have a copy of ours if and when they take out an indeminty bond of about $10M and sign the contracts required by me of anyone who wants a peek at that for any other legitimate business purpose. Until then my answer to that request is "stuff it". I know what's in there, I know how much value it has to a potential or actual competitor, and that information simply will not be allowed to pass out of my control without the strongest of guarantees that it will remain secure. Even our *bank* doesn't have a copy of this document, and that relationship is traditionally one of the strongest between two firms. -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 6 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info(a)mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net

1 0

Re: Internic address allocation policy
by Jeff.Ogden＠um.cc.umich.edu 20 Mar '95

20 Mar '95

I didn't think that the RS folks were asking for business plans. I have heard them ask for IP numbering plans or routing plans or other things that give them at least a feel that you will be putting the address to good use. Sounds like the sort of thing I'd want them to ask for. I don't want them to make too much of a judgement on what you submit, other than you seem to know enough to not waste the addresses. -Jeff Ogden Merit/MichNet

1 0