[address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)

Would this proposal allow end users to request the transfer of a single
IPv4 /32?  Or is that prevented by RIPE requiring parties to a transfer to
be LIRs?  I am less worried about LIRs doing something stupid, but if it
were allowed, I would guess that some end users would attempt to use /32
transfers the same way they use phone number portability.

IMO it might be better to preserve some sort of minimum transfer size.
 Dropping it to a /24 (or farther) would make sense to me.  Going all the
way to /32 seems unnecessary and a bit risky, unless there are other good
safeguards in place to ensure that any entities transferring a /32 are
really in a position to route it themselves, and aren't just trying to
impose the routing externality on the rest of the global table (and blaming
someone else when their IPv4 /32 announcement isn't accepted everywhere).

-Scott


On Mon, Mar 24, 2014 at 7:12 AM, Elvis Velea <elvis at velea.eu> wrote:

> Hi Rob,
>
> I was just about to make the same comments :)
>
> I support the proposal although I would have proposed a minimum /24 (as it
> is in the other regions).
>
> However, leaving the decision in the hands of the operators sounds good as
> well.
>
> cheers,
> elvis
>
>
> On 24/03/14 16:05, Rob Evans wrote:
>
>>      http://www.ripe.net/ripe/policies/proposals/2014-01
>>>
>> Overall I think this is a good thing, but I wonder if there is a reason
>> for leaving 5.4 (minimum sub-allocation size) as-is?
>>
>> If we open the door to transfer prefixes smaller than a /24, should
>> sub-allocation of them be prevented?
>>
>> The routing side of me, of course, might consider the alternative of
>> clamping the transfers at /24 too, but perhaps that should just be left
>> for consenting adults to negotiate between themselves.
>>
>> Cheers,
>> Rob
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20140324/aaf03aff/attachment.html>