Policy Statement on Address Space Allocations
Sean Doran smd at sprint.net
Thu Jan 25 14:20:23 CET 1996
> The same ISP has said publicly that they will route /19 prefixes in our > address space: 193/8 and 194/8. The discussion is still going over > future /8s. But read the last paragraph of the policy statement! Sure, there is no filtering in 193/8 and 194/8, and as a result we have VERY poor aggregation. Consider this random cut-and-paste from 194/8. * 194.19.36.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.37.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.40.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.54.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.55.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.60.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.192.0 144.228.101.1 1 90 0 1239 701 3300 3301 5427 i * 194.20.0.0/15 144.228.101.1 1 90 0 1239 701 3302 ? * 194.20.8.0/21 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.16.0 144.228.101.1 1 90 0 1239 701 3300 ? * 194.20.19.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.20.0/22 144.228.101.1 1 90 0 1239 701 3397 ? *>i194.20.32.0/22 144.228.121.118 10 100 0 3345 i * 194.20.36.0/22 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.40.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.42.0 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.44.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.49.0 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.50.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.52.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.56.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.60.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.64.0/19 144.228.101.1 1 90 0 1239 701 3302 1267 i * 194.20.96.0/21 144.228.101.1 1 90 0 1239 701 3269 5394 i * 194.20.104.0/22 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.108.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.112.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.120.0/21 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.136.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.137.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.138.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.139.0 144.228.101.1 1 90 0 1239 701 3300 5392 i Putting in a filter on 195.0.0.0/8 that will permit ONLY /18s and shorter prefixes is the only means I can see at this time that will make this kind of b.s. impossible. Indeed, if I put inbound filters on these announcements (and many other similar examples in 194/8) today, I would bet that within two days, everything that can be aggregated above, in Europe and by AlterNet, would be aggregated. If you have some technical means by which you can guarantee that no future allocations will result in rafts of unaggregated addresses like the random chunk cut and pasted above, then I would like to know about it. > I wonder where that rumour comes from. It is certainly not the RIPE NCC > allocation policy. this is a good time to set the record straight on this > and related things. This is *not* an attack on Tony who, I am sure, was > quoting some rumour in good faith. Yah, yah, Daniel, it's a giant conspiracy against you and Tim Bass. > 1) The initial allocation for a newly established local registry (ISP) > *always* is a /19. There will be no discussion about this. > This is fixed, cast in stone, immutable, ... you get the idea. Ah, so Mr "we need to find compromises" of the last message when referring to me not being willing to abandon the goal of an absolute maximum of 1024 prefixes only (and hopefully far fewer) in every /8 remaining in the old-style class C space is not so flexible as he wants me to be? Not that I care; I'm not prone to compromise myself, frankly. I just find the change in your tone from one message to the next awfully amusing. > Note that we make /19 allocations even though one particular ISP is > telling the world that /18 is the minimum you ought to have these days. Yup. And when you make the /19 allocations, you should tell them that in 195/8, if they are announcing a /19, a /20, a /21, a /22, a /23 or a /24, that will not work if they want to talk to SprintLink via a non-customer path. If not, well, I have this neat archive of plenty of warnings I've posted on several lists, and I work with a team of good people in program management, marketing, media relations and legal who went through this in a rather more controversial atmosphere when the filters on 206/8+ went in place, cutting off people who previously had gotten accidental connectivity using long prefixes. Filters on ranges of addresses that have not yet been allocated from is much simpler to defend on all fronts. > Our experience suggests that /18 is too much to assign to any newly > established local registry. It is too wasteful. On the other hand we > cannot live without policy #1. So we decided to stick to /19s. Well, you're the registry. I can only tell you the consequences, and that I won't lift a finger to make exceptions when people start whining, "but RIPE didn't TELL me it wouldn't work!". > It should be noted that we have started allocating hierarchically from > 193/8 when the InterNIC was still using 192/8. So we feel that we have > quite a good track record concerning routing aggregation and address > space conservation too. We consider our policy a good compromise > between aggregation and conservation and our community backs this > policy. I don't disagree that historically RIPE's allocation policy has been *excellent*. However, there are two problems: firstly, it is insufficient in and of itself to prevent things like the stuff above, and secondly there is a disconnect between allocations and announcements. So, let's kill two birds at once: first, an enforcement mechanism to push people into announcing only one prefix per allocation, and second, increase the size of the initial allocation, which will tend to push people away from RIPE as the registry of first choice. I'm sorry if that hurts your income, RIPE. Sean.
[ lir-wg Archives ]