- Test - lists.nanog.org

RE: Allocation of IP Addresses
by Paul Ferguson 15 Mar '96

15 Mar '96

At 01:58 PM 3/15/96 -0600, Jim Fleming wrote: > >The growth of the railroads in the United States is also a good story >to study. There are many parallels with the Internet story. > With the number of train crashes in the past couple of months, this comparison leaves a lot to be desired, Jim. :-) - paul

1 0

RE: Allocation of IP Addresses
by Jim Browning 15 Mar '96

15 Mar '96

>From: Perry E. Metzger[SMTP:perry@piermont.com] > >"Kevin Oberman" writes: > >> And, if you want to claim that these were local, go out and buy a >> diamond. While there are a few exceptions, DuBeers controlled the >> world's diamond market totally until the past decade and still could >> easily destroy the worlds diamond market in a day. > >How could they "destroy the market"? Is there a "diamond market" sitting >in a hallway somewhere that I can shoot or something? DeBeers has controlled (or at least significantly influenced) the price of diamonds for decades, ensuring that they appreciate in value by controlling supply, and by buying diamonds on the wholesale market to keep the price up (similar to what countries do to protect their currencies). They could flood the market at any time, driving the price down dramatically. Of course this isn't in their best interest, so they won't do it. However Russia might, as they have stockpiled large quantities of diamonds, and may not have the same goal as DeBeers... -- Jim Browning

2 1

Re: Interesting AP Article
by HAKNER JEFF 15 Mar '96

15 Mar '96

As fascinating as these recent hot debates on YA Death-of-the-Internet scenarios, free markets, theoretical bounds on the food supply and an abundance of hoarded water have been......... What has been conspicuously absent is any comment from anyone at sprintlink on the original posting ("Interesting AP Article"). I tend to distrust anything I read in the popular press about tech topics. What is the truth level in that article's statement that sprint was "blocking traffic"?

2 1

Sprint's filter (fwd)
by Interpath Hostmaster 15 Mar '96

15 Mar '96

As one can see from the dates of the message, the filter has been in since September. +mike ---------- Forwarded message ---------- Date: Tue, 12 Dec 1995 18:57:07 -0500 (EST) From: Dorian Kim <dorian(a)CIC.Net> To: nanog(a)merit.edu Subject: Sprint's filter For those who didn't save this the first time. -dorian ---------- Forwarded message ---------- Date: Sat, 23 Sep 1995 18:46:01 -0400 From: Sean Doran <smd(a)sprint.net> To: nanog(a)MERIT.EDU Subject: access-list 112 This is probably ugly and difficult to read. It also can be trimmed, but has been left overly-long and overly-paranoid for readability when using "show access-list 112" and because the IOS 10.3 distribute-list caching doesn't seem to mind the extra deny clauses all that much. Sean. - -- ! list 112 - deny more specifics of some prefixes ! ! IMPORTANT-TO-REMEMBER SYNTAX FOR BGP distribute-list! ! access-list <#> <permit|deny> ip <prefix> <don't care bits> <mask> <don't care bits> ! ! clear old list ! no access-list 112 ! ! this was originally ordered A, B, C and side-effects, but ! what we really want to do is put the permit clauses up front ! starting with the swamp, as this will match the most prefixes ! !!!!! START ! !!!! PERMITs ! !!! C space !! permit /24s in 192/8-205/8. ! (192==1100 0000, 205==1100 1101) ! ! allow M =< /24 in 1100 xx0x * ! (allow mask bits in first three octets) ! 1100xx0x == {192,193,196,197,200,201,204,205} ! access-list 112 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 ! ! ! allow M =< /24 in 1100 {0010,0011,0110,0111,1010,1011} ! (which really means 1100 {001x,011x,101x}, ! which in turn is really 1110 {x01x,011x}} ! 1100x01x == {194,195,202,203} ! 1100011x == {198,199} ! access-list 112 permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 access-list 112 permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 ! ! !! hack - allow M =< /19 in 206/8 ! access-list 112 permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 ! ! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1110xxxx == {208-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 ! ! !!! B space !! permit /16s in old B-space ! 10xx xxxx * ! (we don't care what bits are in the first two octets ! of the mask; the second two octets must be 0) ! access-list 112 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 ! ! !!! A space !! permit /8s and shorter prefixes in old A-space ! 0xxx xxxx * would be simple but unsafe from 0/8 POV, so ! we make sure that there is at least one 1 bit in the first ! octet's last seven bits, and that the first bit is 0; ! we don't care what bits are set in the mask, because ! we assume IOS won't present us with a prefix with ! bits set in the prefix's first octet but not in the mask, ! unless it's a long mask... ! ! 126=01111110 (IOW, CddddddC C==CARE, d=don't care) ! 125=01111101 ! ... ! 95=01011111 ! 63=00111111 ! access-list 112 permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 ! ! !! permit 9.20.0.0/18 and 9.2/16 by exact match ! (both IBM early birds wrt subnets of As) ! access-list 112 permit ip 9.2.0.0 0.0.255.255 255.255.0.0 0.0.0.0 access-list 112 permit ip 9.20.0.0 0.0.255.255 255.255.192.0 0.0.0.0 ! !! permit exp39 /24s and shorter prefixes only ! (no ones set in the fourth octet) ! access-list 112 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 ! ! !!!! DENYs ! ! This is super paranoia. At this point we have permitted ! all valid unicast prefixes and masks. ! In theory, we could end right here with a ! ! access-list 112 deny ip any any ! ! but this section below offers some degree of clarity ! policy-wise... (at least to me, but I'm weird -- smd) ! ! we also could have done a quick deny after each permit ! to catch any prefixes which didn't pass the permit filters, ! however, as noted below, I am superparanoid about ! funny, noncontiguous masks and other weirdnesses, and ! would like to be able to see them being caught, if ! they ever get as far as the access-list. ! !!! A space !! deny 0/(9-15) - 127/(9-15) ! deny subnets in old-style class A space, first octet ! (if any bit set in bit 8-15 (second octet), deny) ! ! this is a paranoid way of writing this out; ! less paranoia would let us write: ! ! ... deny ip 0.0.0.0 127.0.0.0 0.0.0.0 255.128.0.0 ! ! because we believe in contiguous netmasks; so we would ! never have a /18 if we block /17. ! ! However, better safe than sorry... ? ! ! 0xxx xxxx * ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 ! !!! B space !! deny 0-127/16, 0-(17-23) - 191/(17-23) ! deny subnets in old-style class-B space ! and second octet of class A space. ! (first two bits will be 00 or 10; so x0xx xxxx; 191==10111111) ! (if any bit set in 16-23, deny) ! we also need to zap 0xxx xxxx * /16 ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 ! ! !!! C space !! deny 206/(19-23) - 239/(19-23) ! block prefixes longer than /18 in 207/8-239/8 ! no < /18 in 1100 1110 *, 1100 1111 *, 1110 xxxx * ! ! we block all M => /24 below and we did /17-/23 for 0/8-191/8 above, ! so we only need to worry about 19-23 for 207/8-239/8 ! ! first, in 1100 111x (206/8, 207/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 ! ! next in 1101 xxxx (208/8-239/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 ! !!! all UNICAST space !! deny ANY/24, ANY/(25-32) ! now we block the final octet for 0/8-239/8 ! (because we specifically allowed /24s in 192/8-205/8, we can ! just block everything in xxxx xxxx * that has any 1 bits in 4th octet) ! access-list 112 deny ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.0 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.128 255.255.255.127 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.64 255.255.255.191 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.32 255.255.255.223 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.16 255.255.255.239 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.8 255.255.255.247 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.4 255.255.255.251 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.2 255.255.255.253 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.1 255.255.255.252 ! !!! all IP space !! deny 240/(4-32), 0/(8-32) ! finally, we get rid of any announcements that are bogons ! 240/8-255/8 and 0/8 ! 1111 xxxx * and 0000 0000 * (any mask) ! we can leave this last as it's likely almost never to happen ! access-list 112 deny ip 255.0.0.0 15.255.255.255 0.0.0.0 255.255.255.255 access-list 112 deny ip 0.0.0.0 0.255.255.255 0.0.0.0 255.255.255.255 ! !!!!! END end

1 0

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

15 Mar '96

At 11:14 PM 3/14/96 -0500, Curtis Villamizar wrote: > >Hoarding is only effective if there is a scarce resource, even if it >is artificially scarce, as in the two "gas shortages" of the 1970s >(when there were huge gas company stockpiles and enormous gas company >profits). > Curtis, I think you helped me make my point. I think. ,-) While folks are banging their heads against the wall (and against one another) trying to keep the aggregate growth of the number of globally routeable prefixes in check, the 'Death of the Internet Predicted' rumor-mill still seems to strike enough FUD into the hearts and minds of the masses. - paul

1 0

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

15 Mar '96

At 10:51 AM 3/14/96 -0500, Perry E. Metzger wrote: > >"David R. Conrad" writes: >> Your proposal is? If you say charging for address space, please >> explain what would stop deep pocket companies from buying up all the >> address space? > >If you start charging for food, what would stop deep pocket companies >from buying up all the food? > >If you start charging rent for apartments, what would stop deep pocket >companies from renting all the apartments? > Perry, this is a ridiculous comparison. One could also argue that you can grow more food, and that you could build more apartments. Obviously, you can do neither with a finite address sapce. - paul

3 2

RE: Allocation of IP Addresses
by Jim Fleming 15 Mar '96

15 Mar '96

I think people are seeing the point... As a clarification...IANA is at least two people... Jon (not John) Postel and Joyce Reynolds $ whois 0.0.0.0 IANA (RESERVED-1) Netname: RESERVED Netnumber: 0.0.0.0 Coordinator: Reynolds, Joyce K. (JKR1) JKRey(a)ISI.EDU (310) 822-1511 Record last updated on 15-Jan-91. Jim Fleming Naperville, IL P.S. I think IANA stands for "I Am Not Alone" ---------- From: Gordon Cook[SMTP:gcook@tigger.jvnc.net] Sent: Thursday, March 14, 1996 2:20 PM To: David R. Conrad Cc: Jim Browning; 'com-priv list'; nanog(a)merit.edu Subject: Re: Allocation of IP Addresses Just a small quibble David: when you say "the IANA" decided, it gives the impression that an august group of people like the IESG took action. In reality "the IANA" is but a SINGLE person - John Postel. If some people are upset I suspect it might be because the power to make such a decision is vested in the hands of ONE person rather than in a group. ********************************************************************* Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 USA Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate Site Lic. $650 http://pobox.com/cook/ for new COOK Report Glossary of Internet terms ********************************************************************* On Fri, 15 Mar 1996, David R. Conrad wrote: > It would appear a clarification is necesssary: > > >>>The @Home allocation was done outside of normal registry procedures by > >>>the IANA directly. InterNIC should not be held responsible for that > >>>case. > >Which confirms that the rules are not well established nor consistently applied. > > Any very large or unusual request must go outside normal registry > procedures (e.g., slow start). @Home is such a case. They made their > case directly to the IANA as InterNIC is not authorized to allocate > very large or unusual requests directly. The IANA authorized the > allocation based on the merits of the request (whatever they might > be). None of the registries can allocate very large or unusual > requests directly. This rule is quite well established and > consistently applied. > > Regards, > -drc >

1 0

Re: Allocation of IP Addresses
by David R. Conrad 15 Mar '96

15 Mar '96

It would appear a clarification is necesssary: >>>The @Home allocation was done outside of normal registry procedures by >>>the IANA directly. InterNIC should not be held responsible for that >>>case. >Which confirms that the rules are not well established nor consistently applied. Any very large or unusual request must go outside normal registry procedures (e.g., slow start). @Home is such a case. They made their case directly to the IANA as InterNIC is not authorized to allocate very large or unusual requests directly. The IANA authorized the allocation based on the merits of the request (whatever they might be). None of the registries can allocate very large or unusual requests directly. This rule is quite well established and consistently applied. Regards, -drc

2 3

RE: Interesting AP Article
by Jim Fleming 15 Mar '96

15 Mar '96

This issue has been on the burner for a long time... The National Science Foundation's, "exit stage right" last year was irresponsible... As Election '96 heats up and Bill Clinton plugs more schools and parents into the net, people are going to find out that some roads lead to interstate highways and some roads end up nowhere, just like the cover of "The Road Ahead" There are no easy solutions...one thing for sure...money will be the key to survival on the Internet...the Federal Government will likely have to step in to help insure that school children get lunches and their Internet...the Election '96 candidates will have to respond to the serious problems that have been created because of the rapid commercialization of a precious resource... Next November, the candidate with the most IP addresses to "dole" out may be the winner...(no punn intended)... Jim Fleming Naperville, IL P.S. Just think, "Vote for ________ and receive a "routable" IP address"... ---------- From: Paul Ferguson[SMTP:pferguso@cisco.com] Sent: Wednesday, March 13, 1996 6:17 PM To: Larry J. Plato Cc: nanog(a)merit.edu Subject: Re: Interesting AP Article 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> >

2 1

Allocation of IP Addresses
by Jim Browning 14 Mar '96

14 Mar '96

I may be opening a can of worms, and if so, I believe it is one which needs to be opened. If this topic has been beaten to death in the past, then I apologize, however as it is a rapidly evolving topic, it warrants repeated discussion and evaluation. My fundamental questions are: 1. Is InterNIC consistently applying objective criteria in its evaluation of requests for the allocation of IP address blocks? 2. If so, what are the criteria? The INTERNIC IP ALLOCATION GUIDELINES FOR INTERNET SERVICE PROVIDERS states that "allocation is based on the ISP's 3 - 6 month requirement and other information the InterNIC deems necessary". There is no detail provided (in any document I have found) of what other information InterNIC deems to be necessary. I find an apparent conflict between established policy and its actual implementation on a day-to-day basis. CIDR dictates that addresses should be aggregated into the largest blocks possible, and that the publishing of extraneous routes be eliminated. In keeping with this, and because of often discussed operational considerations, the minimum size of blocks routed at the NAPs is growing larger and larger. To ease participation at the national level, you must ensure to the fullest extent possible that your address space is routable as a single block. In order to accomplish this, you must obtain either: 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. Due to the shortage of *available* IP addresses (there are of course millions of allocated but unused addresses floating around), InterNIC is using a "slow start" approach which provides incremental increases in total address space, with no guarantee that future increments will be contiguous. This means that the only way to maintain efficient routing is to engage in repeated renumbering of customer addresses to consolidate into increasingly larger blocks. How many times is it reasonable to ask a customer to renumber? Once is certainly reasonable. Twice is questionable. More than that and I would suspect the customer would renumber all right, but as part of shifting to a different ISP. The day to day implementation of policy by the InterNIC has increasingly critical impact on our industry, to the point of controlling who has the opportunity to succeed and who does not. IMHO, it is imperative that: 1. this function be performed in an understandable manner, 2. objective criteria be consistently applied 3. the criteria in use be publicly available, and 4. there be defined mechanisms for the 'appeal' of decisions made in the processing of allocation requests. Recent experience and observation leads me to conclude that these imperatives are perhaps not being met. Am I all wet???? -- Jim Browning <jfbb(a)ATMnet.net> 619/812-2860 Fax 619/812-2867

12 19