[arin-ppml] Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements

[Jimmy Hess]

On Mon, Feb 10, 2014 at 3:50 PM, David Huberman <
David.Huberman at microsoft.com> wrote:

> I am the author and I support this policy.  Jimmy, I'd like to respond to
> your points:
>


> Obviously, I disagree :)  I think it is a forward looking policy, asking
> the PPML to remove an arbitrary minimum barrier which is the purview of
> network operators, not


Hi.   The choice of announced prefix size is not entirely within the
purview of network operators.     IN FACT;   whatever address size of an
 allocation  ARIN chooses to allow to be created,  may tend to be highly
"coercive",    network operators may have little ability to refuse the
prefix,  once ARIN deems it legitimate.

The minimum size of a block allocated or transferred is well within the
purview of ARIN address policy,  and a major factor causing the minimum to
be  /24  instead of /32   IS hierarchical addressing,   aggregation,  AND
 also  routable prefix size.

Routing considerations DO have a legitimate affect on RIR addressing
policy.  Which is not entirely within the purview of network operators.

However, the ARIN RIR community itself  INCLUDES network operators.
 The establishment of a minimum allocation and transfer unit, is well
within ARIN's stewardship responsibilities.


> what size prefixes I will, and will not, export to my peers.  The IETF and
> the engineering community have never given that authority to ARIN
>

ARIN policy has the authoritiy to determine what address block sizes that
ARIN issues.
Restricting allocations smaller than a /24 services legitimate stewardship
requirements.

I characterize it as "forward looking" because it is removing an arbitrary
> barrier to success for later in the 8.3 and 8.4 transfer market lifetimes.
>

Requirement that blocks contain a reasonable minimum number of addresses,
so that routes can be aggregated, is not an arbitrary barrier --- it is a
reasonable barrier, that any responsible internet registry,  fulfilling its
 address stewardship requirements,  would have a minimum size for
allocations, transfers, etc.


> You're wrong here, sorry.  This policy only affects text in 8.2, 8.3, and
> 8.4, which are transfer sections.   Transfers are going to be the only
> significant work that the Registry does in the foreseeable future, so it's
> very relevant to tomorrow's ARIN.
>

IPv6 related transfers and allocations yes.   IPv4 is not particularly
relevant to tomorrow's ARIN.


> In the world today, 8.3 transfers are very active.  Hundreds of blocks are
> changing hands every year.  That's almost as many allocations and
> assignments as ARIN gives


Yes....  mere  _hundreds_  every year,   compared to _tens of thousands_
 of  new delegations.     The fact is;  the true lack of  interest in
transfers,  Versus IPv6 allocation, will have unknowns until  20000+
delegations CAN'T happen every year, anymore.


> (4) IPv6 is likely to be adopted more heavily,  obviating the usefulness
> of any attempts to increase the number of  resource transfers occuring.
>
> Strongly disagree.  Despite the best efforts of fine engineers like Owen
> DeLong and his excellent employer Hurricane Electric, IPv6 is already a
> legacy protocol, and

adoption is very very slow.  Moreover, the number of IPv4-only networks
> dwarfs the


All signs point to  the claim of V6 adoption being slow, as completely,
utterly incorrect.

"IPv6 is a legacy protocol"  is certainly a new one.


> (6) Disagree with   "allowing networks to move blocks around as they see
> fit".    The manner "in which some networks see fit"  is not necessarily a
> good thing  for the level of global routing
>
> This isn't 1995 or even 2005 anymore. We have over 400,000 routes in the
> DFZ and large network routing tables are in the millions.  10,000 or even
> 100,000 sub-/24 route announcements isn't going to stop BGP from converging.
>

"100,000" extra sub  /24 announcements, is a dramatic underestimate of what
is likely to happen,   if  there are  a large number of sub-/24  transfers.

Not that 10 to 100K extra routes is anything to sneeze at either.



> > (7) A problem is:  as long as routes for these prefixes would
> hypothetically be accepted, the networks who "see fit to move smaller
> blocks around and fragment /24s into
> > small chunks  to sell off IP by IP"  are not bearing the cost of their
> actions ---  other ARIN members would be  essentially  forced  to bear
> costs.
>
> That's not the purview of ARIN.  It is up to each individual network
> operator to decide what routes she will, or will not, accept.
>

No, the effect of any policy changes on routing considerations' and
potential network stability are definitely within the full purview of ARIN.



> > (8) And I would say that at this point, the /24  minimum is not an
> arbitrary minimum. By de-facto standard,  no longer prefix is permissible
>  to be announced.
>
> Strongly disagree.  As Bill Manning always said, an operator will route
> whatever I pay them to route.
>



-- 
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140210/4890dea8/attachment.htm>