[arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size Requirements

[Scott Leibrand]

On Wed, Mar 19, 2014 at 11:34 AM, David Huberman <
David.Huberman at microsoft.com> wrote:

> > But regardless of the legal piece, I see no upside, and quite a bit of
> downside, to allowing IPv4 /32 transfers.
>
> Please articulate the "quite a bit of downside".  If we ignore the legal
> piece of your argument, as you said to, what are the problems with /32
> transfers to the technical operations of the internet? I've only seen the
> legal argument in your replies so far, hence my request.
>
> Also, I believe ARIN is the wrong place for such constraints.  I believe
> operators should make the decision on such matters - not central numbers
> registries which suffer from very very low participation.  You can choose
> to reply to that or not, of course, but I think it's very germane to the
> meat of this proposal:  why does ARIN get to set this basement???
>

Ok, setting aside the Legal thing (based on John's reply), I see this as
mostly an expectations and externalities thing.  Right now, I can make any
size BGP announcement I want to my peers (as Marty pointed out), and that
works fine. But no one is *expecting* me to accept IPv4 /32s via my peers
and transit providers from some unrelated entity across the country/world.

I think ARIN policy needs to be in line with what operators are doing (or
will soon want to do).  I think removing minimum transfer sizes entirely
would act as a forcing function that moves us too far down the "you must
route this" path.  What is actually needed in the next few years is to be
able to transfer /25s and maybe even /28s, not /32s.

Where ARIN is telling operators they can't do what they want, I would agree
with you that we should stop doing that.  But AFAICT no operators actually
want to transfer and try to get everyone to globally route IPv4 /32s, so
ARIN's policy here is just reflecting reality.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140319/48624706/attachment.htm>