March 1996 - Test - lists.nanog.org

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

15 Mar '96

The growth of the railroads in the United States is also a good story to study. There are many parallels with the Internet story. Another story to study is the telephone industry... In the "old days", telephone systems were based on a model where the central core switching system was very expensive and the telephones were cheap. Centralized authorities made some sense, partly because the equipment capitalization was enormous. Common control was easier and could be performed by a few expensive systems. With the Internet, the capitalization is largely incremental. The core "switching system" is low-cost compared to telephone systems. Unlike low-cost telephones, PCs and servers are placed on the "edges" of the system and help to contribute to the common control. This incremental capitalization allows people to start small and to grow at their own pace. Also, companies can select prime urban markets and bypass rural areas. This is similar to what happened with railroads. As companies grow (like railroads) they start to encounter other growing companies and they best serve their customers by coordinating routes that allow packets (passengers) to transfer from one place to another with ease. It does not do a customer any good to be stranded in Peoria with no route to Des Moines. The Internet is only one component of the rapidly evolving story of a decentralized telecommunications system. The Internet would not be here if UNIX had not been set free, if AT&T had not been split, and if PC technology had not been allowed to evolve without centralized controls. Unfortunately, the lack of centralized control allows the Internet to evolve but also discourages coordination. Eventually, customers (passengers) will be the ones that get to decide which ISPs (trains) they ride. ISPs that work together to provide customers with the best service will survive. Those that do not will end up as carnival rides without connections to anything. Jim Fleming Naperville, IL ---------- From: Kevin Oberman[SMTP:oberman@nersc.gov] Sent: Friday, March 15, 1996 10:08 AM To: perry(a)piermont.com Cc: Barry Shein; 'NANOG List' Subject: Re: Allocation of IP Addresses > Date: Fri, 15 Mar 1996 00:40:24 -0500 > From: "Perry E. Metzger" <perry(a)piermont.com> > > I'm arguing that they haven't ever really existed, except with > government intervention to create them. Guess this you could claim "government intervention" for most anything, but I suggest you read up on Carnagie Steel, Standard Oil, and a few others at the turn of the century. 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. Yes, monopolies have and continue to exist. (A monopoly on IPv4 address space is very improbable and would certainly be short-lived, though!) R. Kevin Oberman Energy Sciences Network (ESnet) National Energy Research Supercomputer Center (NERSC) EMAIL: oberman(a)es.net Phone: +1 510 422-6955

2 1

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

15 Mar '96

>From: Perry E. Metzger[SMTP:perry@piermont.com] > >Jim Browning writes: >> 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... > >So in what way is this a demonstration of a monopoly able to >arbitrarily raise prices? What you've shown is that someone might be >able to arbitrarily drop prices... The price has been artificially raised through the years by controlling supply, and it is only a government (the former USSR) which has (to the best of my knowledge) threatened DeBeers control. -- Jim Browning

1 0

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 14 Mar '96

14 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 14 Mar '96

14 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 14 Mar '96

14 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 14 Mar '96

14 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