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

[David Huberman]

I am the author and I support this policy.

Jimmy, I'd like to respond to your points:

> (1) it is unnecessary.

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 address policy.  I run AS8075 (well, Vijay does - I work for Vijay) and only I get to say 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

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.


> (2) This is yet another IPv4-focused policy.   At this point, ARIN should be essentially looking at IPv6 policies policies only,  and not make changes that could adversly further affect IPv4 runout in problematic ways.

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.


> (3) Free pools are not yet exhausted,  so interest in 8.3 transfers cannot yet be regarded or observed in any terms ---  let alone to show that  "available /24s and longer" are inadequate,

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 out annually.  While I agree that sub-/24 blocks aren't quite relevant today, I strongly disagree they won't be relevant tomorrow.  


> (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 number of IPv6-capable networks by a factor of a few million to one.    I do not believe IPv6 will ever reach even 50% deployment in this world.  That's just an opinion, but I'm trying to back up my disagreement with your assertion.


> (5) Prefixes of /24 and larger will most likely be available over specified transfer, and  (4)  Allowing attempts to fragment /24s in IPv4  do not significantly delay exhaustion of IPv4, but 
> instead is a potential source of a great deal of pain.
and
> (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 
> table bloat.

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.

> (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.

> (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.