james_r-ipv6ops at jump
Feb 8, 2011, 7:34 AM
Post #2 of 3
On Tue, 8 Feb 2011, Gert Doering wrote:
> Besides that, it's not the address policy community's *job* to decide
> about *routing table slots*. That's the routing operator community's
> job, to agree upon "who can get what number of slots, for which price".
The two are intrinsically linked. The vast majority of operators are not
going to update their prefix filters continuously (other than for their
customers of course), thus if we end up in a situation where people are
forced to deaggregate their /32, we'll then end up in a situation where
people have to relax their prefix length filters across the whole board.
Being in a situation where the best way to avoid more specific hijacks of
your prefixes (eg recent China hijacks) is to announce the most specific
generally accepted prefixes yourself, stinks, we end up not only allowing
pointless deaggregation across the board, we almost require it so as to
make hijacks less painful. Lets not go there, just let operators filter on
/32 or /48 as appropriate, and allow people to get another /32 or /48 as
necessary when they can't aggregate.
> We (the address policy group) make sure they can get enough addresses
> to number their customers and/or sites and/or networks. A small ISP
> that has a /32 has all the addresses they ever need - but they might
> need multiple routing table slots.
Again, address policy and routing is intrincially linked, there's no point
playing politics of which working group should deal with this because in
the long run the suboptimal outcome is operators with orders of magnitude
more prefixes in the global tables because they either can't be bothered
to configure aggregation, or they want to go some way to protect
themselves from more specific hijackings. Once we end up in this
situation, just like the mess we have with v4 today, there is no going
back - we need to stop it from happening to begin with.
> I welcome a specific proposal that enables the RIR hostmasters to make
> the decision, under which specific circumstances extra address blocks
> should be handed out, and when not. What's been on the table so far
> completely failed to be a) specific enough to be implementable, and
> b) get consensus.
Fine, I propose that address policy should be such that if a party needs
an additional block for routing purposes, they should be given one.
> The easiest proposal would be "who asks for a second address block gets
> another one", but for some funny reason, not many people seem to think
> that this is a good idea.
I guess the tricky bit is about defining when they "need" one.
Typically this "need" is consistent with having an additional network,
autonomous (possibly not connected to) from the first, which they need to
announce some IP space from, generally they will then also have a seperate
autonomous system number for the additional site. In which case how about:
"Who asks for an additional block gets one, provided that they also meet
the requirements for additional autonomous system number under which
they will announce this additional prefix."