- Test - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by Havard.Eidnes＠runit.sintef.no 27 Jan '96

27 Jan '96

Hi, I see Daniel hasn't answered this one (weekend for some, I guess ;-) > > The point is that we will guarantee that our allocation policy > > will create no more than 1024 allocations per /8 and therefore > > not necessitate by itself more routes than that. Currently our > > allocation sizes are /19 - /16. If you think about it a little > > you will see that it is easy to achieve. > > > > And just in case: Yes the minimum allocation is /19 irrespective > > of the number of hosts covered. Note: allocation != assignment. > > OK, so just to make it clear, if a customer would come to the RIPE > NCC and the customer has just 1 host you would still allocated him > /19 block. Correct? This may be obvious to some familiar to the european networking scene already, but anyway... The RIPE NCC itself does in general not deal directly with end customers, only with local registries. To be allocated address space directly from the RIPE NCC you have to first establish yourself as a local registry, pay the startup fee and contribute to the financing of the running costs of the RIPE NCC. Remember, there is noone else than the organizations running the local registries who are picking up the tab for running the RIPE NCC. The typical local registry is also an ISP. Also note the distinction between allocation and assignment made by Daniel which could be lost on some. In this specific case allocation means "address space allocated for a local registry for subsequent assignment to customers". I've seen people critizising the RIPE NCC for their inflexible policies and the practicing of these policies. One important aspect of the RIPE NCC policies when allocating address space to registries is simplicity and uniformity of policy, because one of the worst things that could happen for the RIPE NCC would be for them to rightfully be accused of giving unfair preferential treatment to some registries (=~ ISPs) over others. The chance of this happening (or the RIPE NCC being accused of it) increases with the fuzziness of policies and the amount of evaluation and judgement the RIPE NCC has to apply to individual cases. I think this is fairly accurate, but since this is not coming from the authoritative source I may have made minor mistakes in formulating the above. Regards, - Havard

2 1

on a lighter note...
by hwb＠upeksa.sdsc.edu 27 Jan '96

27 Jan '96

Regarding the NANOG meeting. I am not endorsing their product (or saying anything against it, for that matter, just neutral), but we do have two Xircom wireless Ethernet access points. There are for short distance (may be 30 meters or so in my experience) communication and do some 1 Mbps with a 2.4GHz spread spectrum radio as some "shared medium." The radio guts sits on a PCMCIA card. that fits nicely into a (laptop) PC, and costs a few hundred dollars (not sure about the exact amount). If there were sufficient interest, we could probably use them at the meeting place, so don't leave home without your PCMCIA card. Though I will only install the access points if people ask for it. Y'know, people who don't always want to depend on cables. By the way, I would also be interested hearing from people having experience with other wireless products.

1 0

RE: Policy Statement on Address Space Allocations
by lodge＠houston.omnes.net 27 Jan '96

27 Jan '96

I've been reading this address allocation ping-pong match for some time, and I'm a bit confused. I'd like to describe a real-world case, and gain some understanding by getting some advice. On one hand, we have registries that won't hand out /18 class C blocks for fear of depleting the remaining address space too quickly. On the other, we have "core" providers refusing to route longer prefixes because their routers are about to melt down. I'm currently trying to get a new ISP for a small country on its feet. It can't get addresses from its upstream provider, because they've not got enough and are trying to get some more themselves. They also want to be multi-homed from day one. They currently offer all sorts of fully redundant data services, and understandably they can't see why they should have a single point of failure in their global Internet access. We can spell BGP, and we'll teach them how to spell it too. How about some concrete advice on The Right Thing to do from you folks? Thanks, Mathew -- | Mathew Lodge: lodge(a)houston.omnes.net |5599 San Felipe, 4th Floor | | Internet Specialist, Omnes -- A |Houston, Texas 77056, USA | | Schlumberger/Cable & Wireless company |Phone: +1 713 513 3237 | | http://www.omnes.net/ |Fax: +1 713 513 3126 |

2 1

Re: Policy Statement on Address Space Allocations
by William Allen Simpson 27 Jan '96

27 Jan '96

I trimmed the CC list even further. And you are forwarned that this is a flame, with combined technical and political content: > From: Peter Galbavy <peter(a)demon.net> > Just to spend a few minutes thinking about it, what do the phone > companies do ? They are the nearest thing with a large installed base > that the Internet even begins to map onto. There are however some > fundemental differences - primarily the fragmentation of Europe (which > is not the case in the US). > It should not surprise you that we've heard this before, and rejected it before. > We have a 2Mb line from London to Amsterdam which costs us very much > the same as a T1 from London to Washington. As I understand it, this > "milk them for all they are worth" pricing of the telcos applies to > cross-border land lines in Europe also. > So, lay your own lines if it is cost effective. Heck, spread spectrum radio comes to mind.... if not microwave towers on the oil rigs in the north sea.... > All this impacts very severely on the commercial decisions taken as to > the routeing of traffic. I would much rather buy more lines to the US > and let the traffics flow back to Europe then to just buy lines to > Europe. > Is this why the US-UK links are soooooo overcrowded? Destroying connectivity for the rest of us? > We allocate *each* dialup customer *1* IP address from a > block and dynamically route them based on where they log in to the > service (including RSN Amsterdam). The RIPE NCC has >effectively< refused > us space because they believe that we should change the product we > sell and use dynamic IP for dialups. > Hell yes! Damn right! Three cheers for RIPE!!! Anyone who still allocates more than 1 address per actual dial-up link should be taken out and shot! We spent rather a lot of volunteer-years getting this to work (PPP). > We provide a product which > our customers understand gives them *more* for their money. We do something > different, and the customers like it. Tough fact of business life that. > Are you sure you told your customers about the alternatives? Like dynamic addressing? Like having connectivity to the entire Internet? This isn't new, this is old hat static addresses! How is it different? What gives _more_ here? I don't see anything worthwhile! > The RIPE NCC believes it can dicate the business model we use, which > has been established for > 3.5 years. This is unlikely to happen. > There is this misconception on your part that you have a _right_ to succeed in business, at the expense of the rest of us. > Please read the policies again. You policy uses words like "strongly > discouraged" for static IP allocation, not "disallowed". You have > attempted to strongly discourage us, we have not been so discouraged, > and now give up and give us the address space we are *entitled* to. > You have another misconception that there is an _entitlement_ to Internet access, at the expense of the rest of us. > > What we do *not* do is consider *individual* interests of some over > > the ones of others. If we would do that we would eliminate our > > "raison d'etre". > > Why not. We are not a communist society are we ? I dunno about _your_ society, but the Internet Community requires cooperation. Call it communistic or socialistic as you like. The net won't work without it. Your "priveleges" end when you affect someone else. And you are affecting me, buddy, and I don't like it one bit! Perhaps you should go build your own internet, like MicroSoft.... Again, I applaud RIPE!!! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Re: Creative routing (was Re: Policy Statement ...)
by Sean Doran 27 Jan '96

27 Jan '96

Well, there's an alternate tactic for a tiny tiny company. MCI Sprint | / The Site-----BBN / \ Alternet ANS 1/ Pick a provider from whom to acquire a tiny amount of aggregatable address space. 2/ Choose a community attribute which you tag on your prefixes. The easiest would probably be "no-export". The ideal would be one meaning "export only to my set of providers". 3/ router bgp X neighbor ProviderX route-map set-community out neighbor ProviderX send-community neighbor ProviderX filter-list 1 out ... ip as-path access-list 1 permit ^$ ip as-path access-list 1 deny .* route-map set-community permit 10 set community <value> 4/ each provider, at each interchange router bgp Y neighbor PeerA route-map policy out neighbor PeerA send-community neighbor PeerB route-map policy out neighbor PeerB send-community ... neighbor AnotherPeer route-map other-policy out ... route-map policy permit X match community <value> set community no-export ... route-map other-policy deny X match community <value> 5/ on ONLY the provider supplying addresses, configure at (or very near) *each* interchange point this: ip route CIDR-SUPERBLOCK MASK null0 router bgp M network CIDR-SUPERBLOCK mask MASK It's important that the route for CIDR-SUPERBLOCK never fully vanish, or you lose connectivity to your non-providers. Hence the provider you choose address-space from should have a good record of knowing what it's doing and always having at least one path by which to announce the CIDR-SUPERBLOCK to the world. That's about the only big qualification. There. Now you have fully redundant connectivity among all your providers. Your address space is aggregated everywhere except in your set of providers. Each of your providers will carry at least two prefixes: the CIDR superblock and the much longer end-site prefix. Each provider advertises reachability for your prefix to each of your other providers; however, the rest of the world sees only the CIDR-SUPERBLOCK. If a packet hits the router announcing the superblock and that router has no route to the long prefix, it probably will be hearing the more-specific announcements from at least one of your other peers, and will hand traffic to them. You can even play games with AS-path lengths on the more-specific prefix in order to select which provider will handle the bulk of traffic from the set of people at interexchange points who are not your providers and therefore not receiving the most-specific prefix. And all sorts of other nifty hacks. I bet it's even fairly easy for most providers to attach a cost on all the activities needed to support this, so you could end up proving Yakov's thoughts about the Push operation. It won't be cheap. This is very-brain-and-slightly-CPU-intensive. Dear small company needing a /28 and comparing itself to Netscape: please forward my standard consulting fee (a pound of good European chocolate) to my office address when you have a moment. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by jnc＠ginger.lcs.mit.edu 27 Jan '96

27 Jan '96

<I'm mostly sitting this one out, guys and gals... Been there, done that, have *all* the T-shirts, way too many times... I know I should really just ignore Tim, sending him replies just keeps him going, but this one was too food to pass up. For now I'll be totally civil, and let Sean handle the ridicule and abuse approach... :-> From: Tim Bass (from cais.com) <cais(a)dune.silkroad.com> There are at least five hierarchical routing architectures that are not CIDR based To start with, CIDR is not a "routing architecture", it's an addressing scheme; routing architectures are pretty much orthagonal. I.e. you could run a hierarchical link-state system sort of like OSPF in the Internet with the exact same addressing as we have today (of course, you'd have to add more levels of areas to the protocol, etc). So, assuming you meant "five hierachical addressing schemes", could you enumerate them for the rest of us? I can think of only one addressing scheme which is really significantly different from CIDR (Landmark doesn't count, it's basically CIDR with diffuse boundaries), and that's Geographic. What is hard to understand is why men and women with intelligent brains believe that there is only 'one way, one religion' to do hierarchical routing. You need to distinguish between routing, and the addresing structure it uses. There are numerous ways to do the routing (i.e. the calculation of paths and/or routing table entries, such as destination-vector, link-state, etc), but there seems to be only one way to make the addressing work for very large networks, and that is to use the approach in CIDR. I am quite sure that the most vocal advocates of CIDR have read very little historical documents outside of the IETF RFCs. Oh, really? I guess I don't count as a very vocal advocate of CIDR... and I guess the same goes for Tony and Yakov. Hi guys! :-) I highly recommend some time spent in review of the principals of hierarchical routing; graph theory; queuing systems; dynamic programming and others as well as the marginalia of journal articles on the subject. Queueing systems aren't much use for this aspect of routing. Noel

1 0

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 27 Jan '96

27 Jan '96

>Then, some of you will ask how to enforce this. Once every so often, you >dump the BGP routing tables from strategic routers. If you see any >non-matching prefixes, you send an email to the network coordinator for >the allocated block giving them a set amount of time to clean it up. Any >routes which are not cleaned up by the deadline are added to a filter >list which could be carried on routers. Sorry, *who* gets to play the net politzai? Registries have no control over service providers, and service providers have insufficient human resources to do that (and most won't do that anyway). Note that updating exterior policy filters by a large ISP involves carefully planned and timed update on some dozen-odd routers, so it is not done often, and certainly won't be done just to punish some clueless luser. We'll be back shortly after the expected RA advertisement break... --vadim Not speaking for Sprint.

5 4

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 27 Jan '96

27 Jan '96

Peter had other ideas about net politzai candidacies :) --vadim Sorry, *who* gets to play the net politzai? Well, I think someone who has considerable experience with a totalitarian regime and a secret police state would be appropriate, wouldn't you, Vadim? ;-) Tony

2 1

Re: Policy Statement on Address Space Allocations
by Sean Doran 27 Jan '96

27 Jan '96

| Now can we try to make things work rather than point fingers! Yes, indeed; that is the ultimate goal we share. We just have some differences of philosophy -- you think that RIPE really can persuade people into having only 1024 announements (preferably far fewer) in 195/8, and I don't. That's all. The compromise we could find would involve a practicable method by which we don't have to put a prefix-length-floor in place, but at the same time don't have to spend enormous amounts of (unavailable) CPU time filtering based on what's in the RIPE database. Avoiding large amounts of (largely unavailable) staff time at Sprint and RIPE to chase down offenders and try to figure out how to stop them from ignoring their contribution to melting routers is also something I'd like to avoid. I don't love my solution either, but it does have the advantages of being CPU inexpensive, does a reasonable job of guaranteeing an absolute maximum number of prefixes in 195/8 (the sum of the /18s, /17s, /16s ... /7s and the /8 itself) even in the worst case, and provides what has already proven in practice to be a tractable enforcement mechanism. I regret the renumberings which have happened as a result, but unfortunately people are still being hooked up to the network with freshly-allocated PI /23s and /21s, and only after they actually try to use them does it click that they really won't work. Moreover, when these people try to find out why things aren't working, (and sometimes after trying various so-far unsuccessful means to have an exception made), they often understand what's happening in core routers and from then on have tended to do a good job of not introducing new prefixes into the core. I am aware of various disclaimers and warnings the registries issue and I'm grateful for them, actually. They've been helpful. Some folks at a couple of our peers/competitors have also been good at protecting their customers by telling them a great deal about CIDR and PI vs PA space. The large failing of CIDRD and the CIDR effort is one of being unable to communicate things to precisely these people receiving new allocations, which in large part is due to the inability to get any documents published. So, as a consequence of some parties being religiously opposed to issuing documents emanating from a part of the IETF that describe what really is happening now -- in order to save newcomers and folks who haven't followed CIDRD a great deal of confusion and effort -- on the grounds that any such publication would look like the IETF "endorsing" some evil greedy bastards who are out to rape and screw small providers, people in small countries, small animals, or whatever the cause celebre of this type of zealot happens to be today. The people being screwed are those who have no information about how busy routers are and how untenable lots of addresses of any nature are, and how important aggregation is, and therefore how good PA addresses are to them *until* they run right smack into my filters. The campaign of "keep them ignorant to force providers to abandon this silly notion that currently available routers are too busy to deal with as many unaggregated addresses as people want to present to them" only succeeds in *hurting* small providers and startup providers. And those small providers are who pay my salary, and you better believe that my colleagues and I are very keen on keeping them in business and seeing their customer base and income grow substantially, so that they end up buying more and bigger circuits -- both Internet connections and raw private lines and international private lines -- and keep being able to pay for them for a very very very long time. Sean.

6 10

Re: Policy Statement on Address Space Allocations
by matthew＠scruz.net 27 Jan '96

27 Jan '96

Original message <96Jan27.012415-0000_est.20615+371(a)chops.icp.net> From: Sean Doran <smd(a)icp.net> Date: Jan 27, 1:24 Subject: Re: Policy Statement on Address Space Allocations ... > > The encouragement, IMHO, should be in the form of the work > PIER is addressing (sorry about the pun), some possible > future renumbering tools, NATs, or any other technology > which results in making a change of addresses painless and > quick, so that people have little or no reason to object to > using provider-supplied addresses. Right. Exactly. But UNTIL such time as easy renumbering for everyone is a reality, watching a world where the policy of one of the big service providers collides directly with the policy of the address assignment agencies makes me wonder what whose goals really are, and really REALLY glad that the company I founded is as big as it is already. And that's because if I was starting that company TODAY, and I knew that in less than two years down the road I'd be in a position where I'd be multihomed and/or at an interchange point, I'd be stuck... because there's no way I could get an initial address block for assignment to my customers that was also big enough to pass Sprint's routing filters. I don't even understand how I'd effectively use such an address... If I get an address from my provider, I'm doomed to renumbering in the event that provider can't provide me with all the service I need, and I can't subject my customers to that. But the first "portable" block of addresses I could get (speaking hypothetically as a new ISP) wouldn't work to get everywhere, because Sprint (and no doubt others in the future) would ignore the announcement. Since those addresses would be worthless, there's no way I could ever use them, and thus no way I could ever satisfy the Internic that I'd effectively used my first block of addresses and was ready for a bigger one. I forsee a large number of new /19's filled with fictitious entities, followed immediately by the application for an additional, larger, block... and if we're concerned about the efficient use of address space (and not just routing table size) that's a serious waste. Why can't we just all agree, at least for a little while, on the SAME address efficiency vs. routing table size tradeoff? RIPE, et al has decided that initial assignments of /19 are the right tradeoff. Sprint has decided that /18 (or maybe /17 now) is the right tradeoff. Similar, but not the same, choice. If it was the same, this argument would be over and new providers could continue to spring up without having to wonder how they're going to get their first addresses routed and NSP engineers would know that routing table size, while perhaps a bit larger than they'd wanted, would still be seriously limited in growth compared to the alternatives. I really don't care whether Sprint changes their filter to be at /19, or if RIPE, IANA, et al decide that Sprint really is smarter than they are and that /17 is the correct tradeoff point, but its just 2 bits! Stop claiming technical superiority and just make it work right for everyone simultaneously! We (scruz-net) advertise more addresses than I'd like, but the Internic forced us into that corner. We asked for a big block over a year ago. They gave us a /21. We used it right up and asked for a big block again. They gave us a /20. We argued with them about it, and they refused to budge, so we went ahead and used it up to. Then we asked for a big block again. THAT time they believed us. We got a /16. Had they given us the /16 the first time, we'd have 2 fewer announcements in 204.*, and still not be quite done using it up. But I'm not going to go tell a hundred or more customers (a good number of those 204.* addresses are subnetted into /29 for "small LAN" customers) that, without the benefit of any renumbering tools, they get to change everything around and sit on the phone all day with our tech support staff until it works correctly again. -mattthew kaufman matthew(a)scruz.net

2 1