[1516] in North American Network Operators' Group
Re: Policy Statement on Address Space Allocations
daemon@ATHENA.MIT.EDU (Sean Doran)
Thu Jan 25 08:26:32 1996
In-reply-to: Daniel Karrenberg's message of Thu, 25 Jan 1996 11:47:36 +0100
From: Sean Doran <smd@sprint.net>
Reply-To: smd@sprint.net
To: Daniel Karrenberg <Daniel.Karrenberg@ripe.net>
cc: nanog@merit.edu, forrestc@imach.com, cidrd@IEPG.ORG, iab@isi.edu,
iesg@isi.edu, iana@isi.edu,
Local Internet Registries in Europe <local-ir@ripe.net>,
Tony Li <tli@cisco.com>
Date: Thu, 25 Jan 1996 08:20:23 -0500
> 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.
