[address-policy-wg] The final /8 policy proposals, part 3

Hello everyone,

It has been quiet for some time now, so I think we should start to  
discuss the final /8 proposals again. In part 2 of the discussion, we  
discussed how many addresses an LIR should be able to get from the  
final /8. I'll try to summarize that part of the discussion. Please  
correct me if I am wrong or if I missed something:

Most people preferred option b: All requests are downscaled by a  
certain factor
Some people preferred option a: Everyone gets one (and only one) fixed  
size block
There were comments that IPv4 would never run out, but let's assume  
that it will run out. In the worst (best?) case we won't need this  
final /8 policy, so it doesn't hurt to be prepared when we do need it.

Because most people preferred option b, let's discuss some of the  
details to see if we can make that work. If we are going to downscale  
address space requests, how should we do that? Some issues:

- If a company demonstrates the need for a /20, we could give them  
(for example) a /26. Smaller organisations would end up with even  
smaller amounts of address space. Currently prefixes longer than a /24  
can not really be routed on 'the Internet' (for some definition of  
'Internet'). Do we expect this to change, or do we have to make the  
minimum allocation size a /24 so that LIRs receiving address space can  
use it?

- Do we want a maximum allocation size? This might be useful to  
prevent a few large companies to grab most of the address space, but  
it might also be unnecessary.

- Do we want to make exceptions for certain situations where  
downscaling is not possible? For example a server farm with many HTTPS  
sites can't use less IP addresses than the number of websites (with  
the current protocols).

I would like to leave PI assignments out od the discussion for now. I  
think we have enough PA related questions to discuss, but don't worry:  
we will get to the PI discussion later.

As before: please stay on topic. This discussion is hard enough as it  
is :)

Thanks,
Sander Steffann
APWG co-chair