- Test - lists.nanog.org

Re: Allocation of IP Addresses
by Brett D. Watson 14 Mar '96

14 Mar '96

> On Wed, 13 Mar 1996, Jim Browning wrote: > > > A. a single allocation capable of supporting planned growth, or > > B. incremental allocations of *contiguous* blocks > > > > InterNIC's current CIDR allocation practice does not support either of > > these options. > > Here's an idea. Let new ISP's reserve large blocks (say /16's) in 65/8, > 66/8, .... but don't let them actually use these addresses on the global > Internet. Then, the ISP can run a Network Address Translation gateway and > give their customers 65/8 addresses while still using a chunk from their > provider's block. And they can switch providers without forcing their > customers to renumber. Then, after they have demonstrated that they > should be given a /16, open up the block they were given in 65/8 for use > without the NAT. > > Of course, there is one little problem with this.... > > bash$ whois 65 > Air Force Logistics Command (ASN-LOGNET) LOGNET-AS 65 > IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0.0.0 > > bash$ whois 96 > Army Finance and Accounting Office (ASN-JTELS) JTELS-BEN1-AS 96 > IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0.0.0 > > How did these guys get such big chunks of address space reserved? by 'these guys' you mean the air force logistics command? the number you looked up is an aut num, not the network. iana has these reserved, not air force. or i've misinterpreted your question... carbon:~ $ whois -h rs.internic.net asn-jtels Army Finance and Accounting Office (ASN-JTELS) "Fort Ben Harrison Indianapolis, IN 46249-1136 " Autonomous System Name: JTELS-BEN1-AS Autonomous System Number: 96 Coordinator: Reilly, William (RR26) REILLY(a)INDPLS-ASAFM1.ARMY.MIL (COM) (317)543-7179 (DSN) 699-7179 Record last updated on 10-Jan-91. carbon:~ $ whois -h rs.internic.net ASN-LOGNET Air Force Logistics Command (ASN-LOGNET) Logistics Management Systems Center/SYU Wright-Patterson Air Force Base, OH 45433 Autonomous System Name: LOGNET-AS Autonomous System Number: 65 Coordinator: Anderson, Jerome (JRA18) [No mailbox] (513) 257-4499 (DSN) 787-4499 Record last updated on 10-Jan-91. -brett

1 0

Re: Those 6 more As
by Sanjay Dani 14 Mar '96

14 Mar '96

>58% whois 24.0.0.0 >@Home (NETBLK-ATHOME) ATHOME 24.0.0.0 - 24.3.255.0 >Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-24) RESERVED-24 > 24.4.0.0 - 24.255.255.0 On a related topic: I am guessing that this is the first allocation given to @Home by the InterNIC. I wonder how @home influenced the NIC's "slow start" procedure and acquired a /14 when the first allocation for every other ISP is /22 through /19. What works for a company that does not (yet) have a single customer ? Marketing hype, an ambitious business plan, impressive VC lineup, media hype or the presense of a highly respected routing expert ? I would like to know how we can "buy" addresses.

2 1

allocations/filtering, etc.
by Jeremy Porter 14 Mar '96

14 Mar '96

I had promised a number of people a paper on economics of route filtering, and I haven't quite got it finished yet. However with regard to current whining, I will post some of the numbers from my current work in progress. I would like to encorage anyone that is working with non-cisco routers, that has information on router limits with regards to memory utilization per prefix, I would like to hear from you. Right now my paper is basied with only numbers I have from various members of Nanog, and my personal numbers in my routers. ----- from "Economics of Route Filtering", Jeremy Porter, Feb 1996, unpublished. ----- Current theory is that a large number of backbone routers will overload when more than about 64,000 prefixes are announced into the global backbone. There are currently about 35,000 networks being announced. With providers filtering routes with prefixes longer than 2^18 bits, with allocations remaining between 207.0.0.0 and 223.255.255.255, we have 17 networks of size 2^8, or 17048 networks of size 2^18. This total is less than the 70,000 "doomsday" routing table. The 2^19 filter length also fulfills the recommendation some people have been making of 2048 prefixes per class A space. This gives us with maximum density 4.4 million hosts on the Internet. With 50% utilization we are still talking about 2.2 million new hosts on the Internet. Currently the reserved spaces have not been allocated except for one notable exception which is a large block anyway. Filtering on just the 2^19 limit gives us a total routing table size between 2.6 million prefixes and 5.3 million prefixes. Given current router technology one could estimate an 8 fold growth in router table size to utilize all 5.3 million prefixes. Thus future routers could need 512 megabytes of memory. This is within the realm of today's technology. Now if we decided that we need our current routers to function, filtering on 2^14 out of 64.0.0.0 - 95.255.255.255 will give an additional 16384 prefixes in a worst case allocation. This is just slightly larger than current routers will hold. With moderate levels of aggregation in 207.0.0.0 - 223.255.255.255 and 64.0.0.0 - 95.255.255.255 we should be able to keep current routers under the doomsday limit. -- Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-339-6094 http://www.fc.net

1 0

Interesting AP Article
by Steve Rubin 14 Mar '96

14 Mar '96

Spelling errors are most likely mine, I take no responsibiltiy for the rest of the errors :) --- "Sprint says its being forced to block smaller Internet users" By STEVE ORR Gannett Rochester Newspapers ROCHESTER, N.Y... In a medium where everhboy is supposed to be linked to everyone else, some Internet users are finding that you can't always get there from here. The reason is usurprising: A major Internet service provider, U.S. Sprint, is intentionally blocking users communications. Sprint says it is being forced to do so because of overcrowding on the fast-growing global computer network. Critics say it's a sign of bad things to come. "I see it as being a pissible start of the fragmentation of the Internet. The alarms are starting to be rung." said Kurt Schweitzer, a Rochester Internet consultant who has researched the problem. Sprint is applauded by some for being first to take action to address crowding. But even supporters note that company's approach contradicts one of the Internet's most hallowed premises... that participants will allow the free passage of any and all information, regardless of its origin or destination. "This is unusual. It's contrary to the cooperative approach," said David Staudt, an Internet Export at te National Science Foundation in suburban Washington. Sprint is now blocking electronic mail, file transfers, and visits to World Wide Web sites. The people who are affected are mostly new customers who have accounts with smaller Internet serivce providers. No one can say for certain how large the group of blacklisted [oh god] users is, though several knowledgeable people put the number at 10,000 or more nationally and growing daily. Sprint's policy remains little known outside expert circles. But some Internet users can point to several cases where communications are blocked. "Our company is really quite concerned about it," said David Luckett, executive director and vice president of NYSERNet, which sells Internet access to many New York companies and which use Sprint. "I don't think we should be looking at Sprint and pointing fingers, though. The problem Sprint is having today is the same problem that the other major providers will face some day." That problem stems from wild popularity of the Internet. There are so many linked networks and users that the system used to route all the Internet information to destinations has become too complex. "There's been for quite a while within the Internet community some concern about performance problems... caused by this explosive growth," said Sprint spokesman Reg Rowe in Dallas. Internet information is sent in "packets," small bursts of data that are addressed with the numerical ID number of the packets destination. Millions of these packets move through the Internet daily, shepherded by computers called routers that check the addresses and send packets toward their destination the fastest possible way. To do that, routers have complex software that lists all the known addresses and routes to reach them. But that lists of addresses, kwno as a router table, has outgrown the computer memory of many routers, experts say. One solution is to route in blocks, with routers sending all packets with similar addresses to end-user computers for final distribution [huh?] It's similar to a U.S. Postal Service worker looking at a letter whose ZIP code starts with "146" and automaticly sending it to Rochesters central office for distribution, without looking at the street name. Sprint, apparently alone among the big Internet companies, adopted this routing system several months ago. But one drawback is that the addresses must be part of a block controlled by an enduser who handles final distribution. Thats fine for Sprint, MCI and other national Internet service providers that are issued Internet addresses in large blocks. But it leaves out smaller Internet companies that tend to acquire addresses a few at a time. those are the addresses Sprint is blocking. "It's a very emotional topic. They're basically saying that they're not talking to the little guy's anymore," said Liudy Bukys, a computer system administrator at UR. Smaller companies might be able to "sublease" block addresses from larger providers, but their customers would have to change the addresses on their computers, and there would be no guarantee the larger provider wouldn't take back the addresses later. Most of those knowledgeable of the problem agree that the block routing is not a bad way to address overvrowding ... unless you're the one left out in the cold. "What they're doing is a community-spritied thing in concept," Staudt said. "Where I somebody who is unreachable... it would sure look to me like Sprint is trying to force me out of business." -- Steven Eric Rubin - the godfather Aimnet Corporation Senior Network Engineer 2350 Mission College Park (408) 567-3820 x511 Santa Clara, CA 95054 Work: ser(a)aimnet.com Play: ser(a)tch.org URL: http://anarky.tch.org/~ser

3 2

Re: Interesting AP Article
by Paul Ferguson 14 Mar '96

14 Mar '96

Perhaps it is 'interesting' because this issue has made it into the mainstream popular press? - paul At 11:24 PM 3/13/96 +0000, Larry J. Plato wrote: >Steve, > >I am not really trying to flame you but why is this article >interesting? It is really a poorly written rehash of the >filtering policy Sprint has discussed for the last 18 months. >I don't agree w/ Sprint's position but I don't see this >article as being particularly interesting. It's not even >very well written. If anything I find it annoying and >irresponsible that the author did not seem, IMHO, to >research his topic very well. As far as I can tell he neither >asked the opinion of Sprint, or any other major NSP, as to why >someone would do this. Yet he had the call to title his >article "Sprint says ..." > >I think this is sloppy, yellow, journalism. > >Larry Plato >I speak for myself only >#include <std.disclaimer> >

1 0

Re: Allocation of IP Addresses
by Paul Ferguson 14 Mar '96

14 Mar '96

At 04:43 PM 3/13/96 -0800, Michael Dillon wrote: > >Here's an idea. Let new ISP's reserve large blocks (say /16's) in 65/8, >66/8, .... but don't let them actually use these addresses on the global >Internet. Then, the ISP can run a Network Address Translation gateway and >give their customers 65/8 addresses while still using a chunk from their >provider's block. And they can switch providers without forcing their >customers to renumber. Then, after they have demonstrated that they >should be given a /16, open up the block they were given in 65/8 for use >without the NAT. > Well, I knew this topic would come up sooner or later, since it was discussed briefly in LA/IETF at the CIDRD WG meeting(s). A snippet from the LA/IETF CIDRD minutes: [snip] Yakov Class A Allocation Guidelines ============================= Motivation Observation 1: 192/3 is 1/8 of the total IPv4 unicast space Observation 2: 64/2 is 1/4 of total IPv4 unicast addrses space Hypothesis1: at some point we will exhaust 192/3 Hypothesis2: at some point we will need to allocate out of 64/2 Observation3: It appears safe to allocate out of 64/2 based on experience documented in RFC???? on Class A Experiment Recommendation allocation of /17 or larger should be done out of 64/2 allocation of /18 or smaller should be done out of 192/3 Comments? Randy: Do you mean start this now? YR: No, only when we decide it necessary. Eliot Lear: Can big ISPs get bigger blocks? YR: Yes, it should allow them to. EL: Do we need to advise Registries? EL: Should 192/3 be declared unroutable? YR: Perhaps part of it. BManning: I would like to attach a rider on this. I think before anyone gets anything out of 64/2 that they should agree to give back their old blocks. TonyLi: Is there some reason not to start alloc 64/2 immediately? YR: We don't have to yet, so perhaps we should not. TonyLi: Pressure from international carriers to get large blocks. ELear: We should wait as long as possible to age legacy systems. Tony: There weren't any big problems in the RFC. BManning: Some things were not tested. Only routing protocols were tested. We couldn't figure out a reliable way to test interior routing. We should hold off a little longer before we jump into this. NoelChiappa: We can't get rid of all the legacy systems. Is the cost of hurting the legacy equipment less than the benefit of 64/2. [general discussion of when we should implement this. Now or wait a little longer for legacy systems to expire.] [discussion of route-able v unroute-able prefixes. Will certain prefix ranges be declared unroute-able in future?] MKosters: @home has a /14 out of net 24, so we have already allocated out of Class A. BrianC: Suppose IANA decides to do this, and some joe-ISP asks for a /14. We haven't given the Registries any guidance on how to allocate. RConrad: Policy most likely to remain the "power of 2" increase. The size of the ISP is irrelevant with this scheme. Cathy of @home complained that Sean won't take 24/14 only 24/8. Sean Doran raised the issue of charging for prefixes. Tony advised we leave this for further discussion on the mailing list. [snip] - paul

1 0

Routing table jump
by Rebecca L. Nitzan 13 Mar '96

13 Mar '96

Hi: Routing tables seem to be taking a jump at an alarming rate since last weekend. Is everyone else seeing this? -- Becca Date #Prefixes ------ --------- 2/23/96 33790 2/29/96 34054 3/1/96 33917 3/1/96 34261 3/2/96 34128 3/2/96 33821 3/3/96 33391 3/3/96 34123 3/4/96 34100 3/4/96 34446 3/5 96 34275 3/6/96 34842 3/7/96 34183 3/8/96 35071 3/9/96 34623 3/10/96 34500 3/11/96 36924 3/12/96 38104

3 2

Canada's domain and IP registry
by Michael Dillon 13 Mar '96

13 Mar '96

If you look through http://www.caip.ca you will find the following: The IP registry for Canada has been run by the University of Toronto for the past few years. The .CA domain name registry for Canada has been run by John Demco of the University of British Columbia. This has been done mostly out of the goodwill of organizations such as CA*Net, UofT, UofBC, and John, who have paid for this service. With increased demand for these services, the UofT will no longer be offering the service. The CAIP will be taking over both registration services and will be responsible for the provisioning of IP address and .CA domain names within Canada. So far it seems reasonable. Then we see this: The pool and committee will also be anonymous and non-public. This is being done in order to obtain the best possible people for the positions, to ensure that the decisions are un-biased, and that the positions can not be used for personal gain. The specific membership of the committee will therefor not be published by the CAIP, nor will any member of the pool or committee ever be allowed to publisize that they were on it. This seems highly unusual and I wonder if any of you know of domain registries (and especially IP registries) in other countries that are runn by anonymous committees and most especially, on which committee members are EXPRESSLY FORBIDDEN from ever identifying themselves. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael(a)memra.com

1 0

Re: Routing table jump
by Paul Ferguson 13 Mar '96

13 Mar '96

At 09:33 PM 3/12/96 -0500, mike wrote: > >This means to all who use routers to do transport *and* routing >calculations/table management on memory bound devices: you're out of >business on 10/1/1996. This is when 'the Internet' crashes. In reality, >it is when all lemmings jump the final cliff, and only the 'bad' ones >will prevail. > >Mike > >( this is a private statement. Don't get me wrong! mypaycheck is not >involved!) > > Good thing your paycheck isn't involved; chances are you'd loose it. Death of the Net predicted, Film at Eleven. Deja Vu. - paul

2 1

Cisco 7513/HSA
by Lowell Hanson 11 Mar '96

11 Mar '96

Sorry, but as I read my message I realized that I missed a "1". The IOS levels should read l1.1(1) and 11.1(2). Lowell Lowell K. Hanson http://www2.dgsys.com/~lkh Philip Morris Network Services lkh(a)dgsys.com 804-274-5462

1 0