- NANOG - lists.nanog.org

Re: Internic address allocation policy
by Vince Fuller 21 Mar '95

21 Mar '95

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? The right solution is to add enhancements to the Internet protocol suite to either automate renumbering as much as possible or to decouple the routing and addressing system from endpoint identification (in general, end-systems need only the latter, and adding such indirection would allow the assignment of addresses to be fully automatic). Unfortunately, while doing this has been discussed for a long time, not a lot of progress has been made in implementing and deploying viable solutions. And to make matters worse, it would appear the next generation of the Internet protocol is likely to do this wrong as well, which means that while it may provide adequate numbering space for assign a unique identifier to every atom in the Universe, it may not solve the route scaling problem. --Vince

1 0

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

21 Mar '95

Ref: Your note of Tue, 21 Mar 1995 09:32:27 -0600 (CST) Karl, >The implementation of this kind of thing MUST -- repeat -- MUST -- be >complete, or it won't get adopted. I could sell to people *right now* >the need and want to go to, for example, an integrated bootp/DNS style >thing, IF it was integrated all the way down to the level of plug and play. As I mentioned before, the IETF (the DNSIND WG) is actively working on the last piece of technology that would make host autoconfiguration possible, both for IPv4 and for IPv6. Talk to your friendly vendor(s), get them interested, see if they'll be willing to implement these capabilities. Yakov.

1 0

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

21 Mar '95

Ref: Your note of Tue, 21 Mar 1995 11:30:42 -0500 Jeff, >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 primary >(because most users won't need its capabilities, at least initially) >so will not be fully specified and implemented until it is too late. I fully agree that host autoconfiguration seems like a reasonable technical solution to the problem of changing providers. The importance of providing autoconfig for IPv6 *on day one* must be stressed over and over again. You, as a member of the IESG, could certain help with this. Yakov.

1 0

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 21 Mar '95

21 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