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

Dears,

I oppose to the current policy proposal as written. It does not mean 
that a second version would not be acceptable but this one has a few 
major problems:

On 5/17/16 3:08 PM, Remco van Mook wrote:
>
> Thank you Marco.
>
> Dear colleagues,
>
> Yes, this is another policy proposal about IPv4. It's even about the 
> current allocation policy (confusingly known as 'last /8'). I'm sorry 
> it's come to this.
>
> The proposal doesn't aim to change a lot about the *intended* goals of 
> the last /8 policy - instead, it tries to clarify the current policy 
> and lock it down against creative interpretations.
This is true. However, it creates several problems and fixes only one. 
The fix - allocations from 'last /8' can not be transferred any longer 
(once this proposal is accepted and becomes policy).
>
> We're in the IPv4 afterlife, and have been for about 3.5 years. The 
> last scrap of IPv4 space that any LIR can get is meant for a specific 
> purpose - to facilitate migration to IPv6. The age of the 32 bit 
> integers is over. The other purpose of the 'last /8' policy is to be 
> able to hand out IPv4 space to new entrants for as long as feasible. 
> These specific purposes are currently not reflected anywhere once a 
> block has been allocated, and this proposal means to change that. To 
> summarise the proposed changes:
>
> - All allocations handed out under the 'last /8 policy' will be 
> (re-)registered as 'ALLOCATED FINAL';
All allocations (as in all those that were allocated since 2012?) or 
only the ones that are going to be allocated once this proposal becomes 
policy?
> - Allocations marked as 'ALLOCATED FINAL' can not be transferred or 
> sub-allocated;
I would agree with the 'no transfer' ban but do not agree with the no 
sub-allocation. If someone wants to 'sub-allocate', they can easily 
create assignments. This can not be enforced except if we forbid the 
creation of sub-allocated PA objects using business rules. But even if 
we use business rules, that will only block the creation of 
sub-allocation blocks to the LIRs that really want to follow every word 
of the policy, the abusers will continue to abuse.
> - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, 
> regardless of how they got it;
What if an LIR has already received a transfer of a 'last-/8' block. 
They have paid for it and the RIPE NCC has approved the transfer. 
Requesting those back would lead to the NCC being sued over and over again.

As we have discussed privately, you do not intend for this policy 
proposal to apply retroactively. If that is the case, then you need to 
figure out a solution for those that will have 2 or more 'last-/8' 
blocks before this proposal becomes policy. That is why I believe a 
second version is needed as this one is not clear.
> - 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);
If you want this not to be applied retroactively, it must be very clear 
in the policy proposal. It looks like it would not apply retroactively 
the way this proposal is worded but it's not very clear.
> - DNS reverse delegation will be limited to the LIR itself, and is 
> limited to a total of a /22 in space.
How can the NCC enforce this? Why should 'ALLOCATED FINAL' IPv4 blocks 
have specific rules regarding reverse delegation but not the rest? Will 
this not be confusing?
>
> 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
Just like with reverse delegation, I oppose to having 'special' rules 
for the routing of 'ALLOCATED FINAL' blocks.

Additionally, and this is the reason I mainly oppose, if this proposal 
would become policy it would force every single small company that needs 
IPv4 addresses for its operations to hire someone to handle the 
communication with the RIPE NCC, the routing and the reverse delegation 
for their 'last-/8 allocation'.

Currently most customers of LIRs are redirected to the RIPE NCC (to 
become LIRs and get a /22) if they need (a few) IP addresses. This 
policy proposal forbids the LIR to manage the address space of the small 
- newly created - LIR (their customer).

We currently manage and maintain the address space of several customers 
of ours (LIRs). This policy proposal aims to request each of our 
customers to hire their own IT team because an other entity can not 
manage their 'last-/8' allocation (but it's ok for the other allocations 
they hold).
Forbidding routing/reverse dns to be managed by the large ISP or a 
consultant is one of the big problems of this proposal. Also, this can 
be easily worked around and I doubt the NCC can even enforce this rule.
>
> 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.
>
> Let's hear your thoughts. I'll be at the RIPE meeting next week where 
> I'll be talking about this proposal during the first APWG session.

NEWTEXT: 5.1.5: An allocation marked "ALLOCATED FINAL" is valid as long 
as it remains with the LIR it was allocated to. If an LIR, due to 
mergers, acquisitions or other means gains additional allocations marked 
"ALLOCATED FINAL", all but the equivalent of a single /22 will be 
de-registered by the RIPE NCC within 180 days.

Let's take the following example:

LIR A receives their 'last-/8' allocation in 2014.
In 2015 it transfers (transfer or merger) an other 'last-/8' allocation.
In 2016Q2 this policy proposal is approved and the RIPE NCC updates the 
RIPE Database objects. Now they have two 'ALLOCATED FINAL' blocks.
In 2016Q4 they want to transfer a non-last-/8 allocation, will they be 
forced to return one of the two ALLOCATED FINAL blocks?

If not, why?
If yes, how long do you think it will take until the NCC is taken to court?


NEWTEXT: 5.4: [...] Sub-allocations cannot be made from allocations with 
a status of "ALLOCATED FINAL". The meanings of the various "status:" 
attribute values are described in Section 7.0.

Why? What would be the difference between a Sub-allocation and an 
Assignment in this case?
Are we really adding stuff in the policy that works against the 
registration goal?


NEWTEXT 3.0: [...] For "ALLOCATED FINAL" IPv4 address space, authority 
may not be delegated to another party, and the reverse delegation will 
be limited to a total of a /22 of IPv4 address space.

How can this be enforced? Since when is the community or the NCC getting 
involved in how someone manages their network and/or reverse delegation?
Again, how long do you think it will take before the RIPE NCC is taken 
to court for implementing a policy proposal that forces new (small) LIRs 
(or even older, bigger ones) to cancel their contracts with their ISP or 
consultants for the management of their resources/LIR?
>
> Kind regards,
>
> Remco van Mook
> (no hats)
>
Regards,
Elvis
(wearing a fedora while writing this reply)
>
>> On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt at ripe.net 
>> <mailto:mschmidt at ripe.net>> wrote:
>>
>> Dear colleagues,
>>
>> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
>> is now available for discussion.
>>
>> The goal of this proposal is to limit IPv4 from the remaining address 
>> pool
>> to one /22 per LIR (regardless of how it was received).
>> These “final /22” allocations will receive a separate status with 
>> several restrictions:
>>
>> -    These allocation are not transferrable
>> -    LIRs may only retain one final /22 following a merger or acquisition
>> -    Sub-allocations are not possible
>> -    Reverse delegation authority can not delegated to another party
>>
>> You can find the full proposal at:
>>
>> https://www.ripe.net/participate/policies/proposals/2016-03
>>
>> We encourage you to review this proposal and send your comments to
>> <address-policy-wg at ripe.net <mailto:address-policy-wg at ripe.net>> 
>> before 15 June 2016.
>>
>> Regards
>>
>> Marco Schmidt
>> Policy Development Officer
>> RIPE NCC
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/623eb48b/attachment.html>