[ppml] Policy Proposal: IPv4 Transfer Policy Proposal

[Scott Leibrand]

Randy Bush wrote:
> [ scott told me off list that he will not be at nanog.  shame, as this
>   would make a good ad hoc bof ]

And as I mentioned, I'd be happy to participate by telephone in any such 
ad hoc discussion that does develop, so don't let my physical absence 
dissuade you.

> i think the restriction on inter-region is un-needed and not useful.  
> if it won't work operationally for the rirs, then they will handle 
> that at the admin/ops level; it is not a matter of *policy*.  and 
> putting it in now will just mean we will have to go through policy 
> process hoops later to take it back out.

I'll address this one first.  I have no strong opinions on the 
inter-region restriction.  On the one hand, I don't want to encourage 
"RIR shopping".  On the other hand, I can see some justifications, such 
as yours, for not addressing this in policy.  Perhaps others could 
comment on this and inform the discussion a bit.

> i think the six month thing is five levels indirect from the goal, 
> route conservation, you say you want to achieve.  hence it will have 
> far less effect on the goal and many undesirable side effects and 
> cause much faking to get around it.  complexity is rarely actually 
> except as a barrier to competition (which is why the telephants got 
> into the sick mind-set that it is a good thing).

So I guess we might as well get into the full discussion of how to go 
about balancing routing table efficiency with ensuring a fully liquid 
market that gets space to those who need it effectively.

There are a number of aspects of policy that bear on this:

   1. Justification of efficient use
   2. Minimum allocation size
   3. Preventing transferees from collecting multiple small blocks
   4. Preventing transferors from splitting their existing block into
      too many smaller ones


Theoretically, #1 and #2 might be enough to get us a decent level of 
routing table efficiency.  However, since acquisition of IPv4 resources 
by transfer will incur significant costs, there will be significant 
incentive to acquire smaller blocks than is typical today, and that will 
likely accelerate the rate of routing table growth.  Therefore, #3 is a 
possible counterweight: if a transferee can get one year's worth of 
addresses by transfer (rounding up to CIDR boundaries), and can't come 
back for more for 6 months, they will be less inclined to get new space 
every month or every quarter based on budget targets, and will instead 
need to get a large enough block to meet all their needs for at least 6 
months.  This will directly reduce the number of routing slots used by 
that transferee.

#4 I'm not so sure about.  I originally put such a restriction in the 
policy proposal based on the intuition that it would be an additional 
check on deaggregation.  However, in discussions since then, I've 
realized that doing so may significantly reduce the supply of IPv4 
address blocks of the sizes in demand by potential transferees.  This 
runs counter to one of my goals, maximizing supply and making addresses 
available at the lowest possible cost.  It also tends to be somewhat  
inefficient (in any market) to try to regulate both suppliers and 
consumers.  Therefore, I am now leaning towards relaxing the conditions 
on transferors from what is proposed in version 1.0.  That might even 
mean removing all restriction on deaggregation by transferors, down to 
the minimum allocation size, or there might be some middle ground.  If 
anyone has any good ideas along those lines, please share.

-Scott