[address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

Hi Remco,

> Yes, this is another policy proposal about IPv4. It's even about the
> current allocation policy (confusingly known as 'last /8').

The proposal claim to «explicitly state that the current IPv4
allocation policy applies to all available IPv4 address space held by
the RIPE NCC that has not been reserved or marked to be returned to
IANA». But is current policy really ambigous in this regard? IIRC this
was already fixed in 2011-03.

> The last scrap of IPv4 space that any LIR can get is meant for a
> specific purpose - to facilitate migration to IPv6.

Actually, that particular clause was removed by 2014-04.

> - All allocations handed out under the 'last /8 policy' will be
> (re-)registered as 'ALLOCATED FINAL';

Okay, whatever, although I am far from certain that this cosmetic change
is worth the risk/trouble (breaking tools etc).

> - Allocations marked as 'ALLOCATED FINAL' can not be transferred or
> sub-allocated;

With regards to transfers, do we have data that show that this is still
a problem that needs fixing after 2015-01 was passed?

With regards to sub-allocations, I fail to understand what problem are
you trying to solve? Isn't delegating resources downstream towards
end-users (i.e., making assignments or sub-allocations) essentially the
whole point of operating an LIR? Stopping LIRs from doing "LIR stuff"
seems ill advised to me - or what am I missing here?

> - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space,
> regardless of how they got it;
> - Any excess space will have to be returned to the RIEP NCC within
> 180 days (however I don't intend that this is applied retroactively);

The proposal needs guidance to the NCC as to which specific /22 the NCC
should de-register. The oldest? The least-assigned?

> - DNS reverse delegation will be limited to the LIR itself, and is
> limited to a total of a /22 in space.

Uhm. Why? And how exactly would this be enforced?

> And, outside of policy but enforceable as business rules following
> from this policy proposal:
> - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22
> - No routing registry entries for any 'ALLOCATED FINAL' blocks over a
> single /22

Okay, so it's good this is not mentioned in the actual proposed new
policy text (even though it says otherwise in the summary), because
these suggestions makes absolutely zero sense to me. Why would we try to
prevent operators from accurately describing their routing policies in
the RIPE database and publish corresponding ROAs?

> Basically, every LIR gets 1 allocation, and if you no longer need it
> or you end up having more, you have to return the excess. All the
> extra limitations should be workable if you're using the space the
> way it was intended, but make it unattractive to collect allocations
> for other purposes.

I'm quite willing to discuss a policy proposal that focuses on the first
part of this. That is, ensure that a single LIR can only hold a single
"final" /22 and stopping creative hoarding. However, such a proposal
would also need to provide some discussion and preferably hard data
that shows that 2015-01 isn't working.

The extra limitations, however, make this propsal a non-starter for me.
You claim that they're workable "if you're using the space the way it
was intended", but I highly doubt that it was ever the intention of the
RIPE community that an LIR shouldn't be allowed to perform standard LIR
tasks with its final /22 like delegating reverse DNS, creating
sub-allocations, ROAs, route objects, etc.

If on the other hand those restrictions were only meant to impact
"hoader LIRs" with >1 final /22, then it seems to me that the mandatory
de-registration is sufficient as it will automatically implement all of
the proposed restrictions (and more) for the excessive /22s, while
leaving "legitimate" final /22s alone.

(I don't see any text in the actual proposal that implements the «if
you no longer need it [..], you have to return the excess» requirement
you described above, by the way.)

Tore