[jump-admins] IPv6 multihoming

[James A. T. Rice]

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."

Regards
James