Policy Statement on Address Space Allocations
Daniel Karrenberg Daniel.Karrenberg at ripe.net
Fri Jan 26 11:58:22 CET 1996
Sean,
If you insist on prefix-length filtering I have proposed a soloution
for future address space allocated via the RIPE NCC several times:
- set your inbound prefix length filter to /19.
- The RIPE NCC will *guarantee* that we will not make more than
1024 non-aggregateable allocations from each /8.
- The RIPE NCC will continue to work with the providers to
maximise aggregation. Our goal is a maximum of 1024 routes
per /8 visible at major exchange points. Incidentally this
is the same goal that you seem to have.
- Should we fall to short of the goal in your opinion, you can
start to filter on the list of allocations which is available
from our whois database (whois -h whois.ripe.net -m 19x/8).
Note that we guarantee that these will be no more than 1024.
Now given the current performance of everyone I personally believe
that we deserve a little relief from the 1024 goal but I am willing
to discuss on the basis above.
Can we please enter into a discussion why this is a bad idea and/or
why it is not acceptable to you personally or your employer.
Daniel
Detailed comments follow (can be skipped by people intersted in the
real issues).
> Sean Doran <smd at sprint.net> writes:
>
> > 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. ...
You conveniently ignored the stats in my message. I repeat them here
sorted by "hosts addressed/route". You will note that 193/8 and 194/8
have anything but "VERY poor" aggregation. They are both within a factor
2 of your goal of 1024 routes.
Routing Table
router: amsterdam.ripe.net
time: Mon Jan 22 11:06:13 1996
Destinations: 32934 Routes: 32934
/8 block hosts routes hosts
addres- /
sed route
207.0.0.0 1019136 37 27544
203.0.0.0 5831424 780 7476
200.0.0.0 4660736 697 6686
206.0.0.0 10967808 1649 6651
193.0.0.0 9264640 2019 4588
194.0.0.0 7665920 1849 4145
205.0.0.0 6019584 1793 3357
202.0.0.0 4258496 1460 2916
204.0.0.0 10499072 3660 2868
199.0.0.0 8838144 3338 2647
196.0.0.0 731648 329 2223
198.0.0.0 7488000 3705 2021
192.0.0.0 4981504 6551 760
201.0.0.0 256 1 256
197.0.0.0 256 1 256
195.0.0.0 256 1 256
C Space 82226880 27870 2950
> 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.
You should be careful calling things b.s. before checking why they
are done.
> 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.
Here we disagree about how to achieve goals. I tend to favour
compromise/consensus achieved by discussion to unilateral
action.
> 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 have told you before that as regional registry I have
absolutely no control about routing policies of any provider
whatsoever. I can only try to have influence and, again,
I think we are doing quite well compared to others.
> > 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.
I guess we have a language communications problem here.
What is wrong with someone authoritative about something to
say what it is.
> > 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?
You should have read further:
(NB: The value of /19 might change at some point, but the fact that
every newly established registry gets *the same size* initial allocation
will not.)
I am getting the impression that you are not really listening. What I
was saying is that "everyone gets the *same* *initial* allocation" was
something I am not willing to compromise on. If you had to sift through
all the bullsit (marketing predictions, solicitor's letters, hurt egos,
diplomatic notes(!) ...) which any other policy generates or
(beware) to pay someone to handle those, I am sure you would agree.
> Not that I care; I'm not prone to compromise myself,
> frankly.
Good that you say so, I didn't notice ;-).
> 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 you care to read ripe-127 and the policy statement which caused this
whole discussion you will notice that this is being done in no uncertain
but less Sprint centric terms.
This does not prevent me from arguing with you about better soloutions.
> 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.
Fine and I have this neat archive of warnings I put out too
including the documents cited above.
Now can we try to make things work rather than point fingers!
> 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!".
They would be dead wrong.
> 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.
About which I have no *control* but some influence.
See the proposal above.
> 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.
We have no problem with that. Any way to reduce the work we have
to spend on registration services is welcome. ;-).
However what you are asking is for us to make and enforce policies
that favour a certain type of provider more than technically necessary.
This we will not do. If one of these providers chooses to cut itself
and its customers off from some parts of the Internet that is fine.
Daniel
[ lir-wg Archives ]