[ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal

[Ted Mittelstaedt]

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Scott Leibrand
> Sent: Tuesday, March 11, 2008 10:54 AM
> To: arin ppml
> Subject: [ppml] Restrictions on transferor deaggregation in 
> 2008-2: IPv4 Transfer Policy Proposal
> 
> 
> First of all, thanks to everyone for their feedback and discussion of 
> the 2008-2 policy proposal.
> 
> One item that I still think needs further discussion is the 
> question of 
> whether and how to restrict transferor deaggregation in an 
> IPv4 Transfer 
> Policy.  The question is, should we place restrictions on both the 
> transferee and transferor to limit deaggregation,

No.  However, the deaggregation should be performed by the "seller"
not by the "buyer"  It should also not be any longer than a /20

If a "transferor" AKA "seller" has a block longer than a /20 they
should be prohibited from participating in this policy at all - they
should return it to ARIN if they are going to give it up.

If they have a /20 they should not be allowed to deaggregate it.

If they have a /19 or shorter, they should complete the deaggregation
PRIOR to transfer.  You see, it may happen that a "transferor" may
have a large block, like a /8 for example, that they have a "buyer"
for only part of this - and their choice is either they deaggregate
the large block and sell part of it now for cash now, or they
hold off, expecting that later on someone who needs the complete
undeaggregated block will come along and want to buy it.

The liklihood is that over time
the demand will be for smaller blocks.  The reason being is that
the cost of large blocks will be so high that the networks that
can afford to buy them (and can provide justification for buying them)
will find it cheaper to go to IPv6.  It is the small fry that will
be clinging to IPv4 the longest, and will be resisting the move to
IPv6 for as long as possible - simply because putting in IPv6<->IPv4
gateways and other infrastructure to support old legacy IPv4 customers
will be a much larger percentage of cost of their infrastructure.

Of course, from a public good point of view, this is a bad thing because
it essentially means that if a transfer policy goes into place that
over time we will see more and more deaggregated IPv4 blocks as more
and more of the large block holders abandon and split apart and sell
off their large holdings.

However, it really depends on what you want.  If your goal is to prolong
IPv4 lifespan, then your going to have to accept more and more deaggregation
within the IPv4 routing table.  If your goal is to reduce the global route
table entry and your against more deaggregation, then to be consistent
you should be completely against this transfer policy from the get-go.

What you CANNOT have, is your cake and eat it to.  You CANNOT have prolonged
IPv4 lifespan without an increase in deaggregation.

In any case, I am completely against this transfer policy proposal, and
always have been.

Ted