[ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal
sleibrand at internap.com
Tue Mar 4 11:49:29 EST 2008
Jim Weyand wrote (in a message not posted to PPML):
> My real concern is that the community has not considered the costs
> associated with the proposed constraints. I can dream up a number of
> scenarios that may occur.
> Scenario 1
> An ISP has a /16 but determines they really only need a much smaller
> block - maybe a /20. They look at the market price for a /16 and
> determine that it is a high enough price to put up with the pain of
> moving all of their addresses to new space. In an unrestricted market a
> /16 is probably worth more than an equivalent number of /20s so the ISP
> would be motivated to transfer out the whole /16 and transfer in a /20.
> The problem is, under “Policy Proposal 2008-2: IPv4 Transfer Policy
> Proposal”, our ISP cannot acquire new addresses. So, to make the sale,
> the /16 gets broken up into pieces and all parties are net losers. The
> seller was unable to maximize their profit, the original buyer was
> unable to participate in this transaction (because they are prequalified
> for a /16) and the routing table is increased.
> Scenario 2
> Our ISP with the /16 thinks they only need a /17. They look at the
> market rate for the remaining /17 and think, “hmmm… that’s pretty
> good”. The ISP reasons that they can get cash now and, if they really
> need it, they can go buy more addresses later.
> The ISP is pretty excited about this idea and investigates what is
> involved with transferring out IP Address space under ARIN’s new rules.
> They read the rules and realize, down in the fine print, that they can’t
> get any more IP Address space for another two years. The risk is too
> great and the ISP decides not to transfer out any addresses and the
> market price of a /17 is artificially inflated.
> The constraints will have real costs – probably not the kind of costs
> that will make the front page of the Wall Street Journal but nonetheless
> real costs that will affect ISPs.
I agree completely. Perhaps one way to address your concerns would be
to look to NRPM section 4.6 Amnesty Requests
(http://www.arin.net/policy/nrpm.html#four6), and include text in the
transfer policy to accomplish similar objectives.
But the more I look at it, the more I wonder if the same objective could
be accomplished more simply by striking the words ", or through this
Simple Transfer policy" from the condition that "The transferor may not
request any IPv4 allocations or assignments from ARIN (through ordinary
allocations or assignments, or through this Simple Transfer policy)
within the subsequent 24 months." Under the standard transferee
conditions, any subsequent requests to receive IPv4 addresses through
this Simple Transfer policy would have to be justified and
pre-qualified, just as with any other potential transferee.
The only thing this doesn't address is the desire to allow someone to
get and renumber into a smaller block (say /20) and then transfer their
larger block (say /16). Under the current proposed policy, such an
organization would be able to keep the first or last /20 out of their
/16, and transfer the remaining /17, /18, /19, and /20. While I could
see a renumbering being slightly better, I think the existing policy is
adequate, so I'm not sure if we need to allow people to renumber into a
completely different block, and deal with all the complexities of timing
> I have struggled to fully understand the latter part of Scott’s second
> > but that further restricting transferors from
> > deaggregating to meet legitimate demand from pre-qualified transferees
> > will have a negative effect of increasing the price of small blocks
> > while decreasing the price (and supply) of larger blocks.
> As I understand this if we make it too difficult to split a block we could:
> 1) Artificially raise the price of smaller blocks since there may be
> demand for smaller blocks that cannot be met while there are larger
> blocks that sit unused.
Yes, that is my main concern.
> 2) Unintentionally decrease the supply of larger blocks because a
> buyer will look at the lower price of the larger blocks and lobby for an
> exemption to the pre-qualification requirement.
I hadn't thought of that aspect of it, but yes, that would be another
negative consequence of not allowing enough deaggregation.
> Do I understand this correctly?
> Assuming I do, isn’t this another argument for not introducing any
> market constraints other than minimum block size?
Or at least for reducing the number of market constraints. As I
outlined above, and in a separate proposed modification under discussion
(to allow ARIN discretion to allow enough deaggregation to ensure
adequate supply of smaller blocks), I'm open to reconsidering any
aspects of the policy that might do more harm than good, and either
eliminating or changing those aspects, or introducing compensatory
language to deal with the negative side effects.
Do you have any feedback on any of the proposals above, or any other
suggested improvements? The 30-day cutoff for submissions of revised
proposals for Denver is fast approaching.
> *From: *"Jim Weyand" <jweyand at computerdata.com
> <mailto:jweyand at computerdata.com>>
> *Date: *February 29, 2008 9:14:04 AM PST (CA)
> *To: *"arin ppml" <ppml at arin.net <mailto:ppml at arin.net>>
> *Subject: **Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
> Does our economist monitor this list? There is a lot of language in the
> rationale section that says that many of the restrictions on trade are
> designed to limit speculation. Is speculation worse than living with
> the restrictions imposed by this proposal?
> For example one restriction is that if you transfer address space to
> another party you may not receive address space for another 24 months.
> This means that if you have a nice large block you are prevented from
> transferring the entire block to another party and getting a more
> suitable block in return.
> This restriction will also artificially increase the "market price" of a
> block of addresses since I will only take the risk of running out of
> addresses in next 24 months if it is very rewarding.
> I'd like to hear our economist's (Ben?) comments on the cost to the
> community of the restrictions v. speculation.
> Even with these restrictions I can support this policy, however I think
> it is worthwhile to consider the "hidden" costs associated with these
> -Jim Weyand
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Leo Bicknell
> Sent: Friday, February 29, 2008 10:50 AM
> To: arin ppml
> Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
> In a message written on Fri, Feb 29, 2008 at 10:27:02AM -0500, Cliff
> Bedore wrote:
> I think we need to make sure the ARIN attorneys look at this from the
>> standpoint of "How can I beat the system". I expect they are
> honorable and
> above board and that's probably a disadvantage when trying to ensure
> all the
> i's are dotted and the t's are crossed and the vultures are kept at
> The ARIN AC has worked closely with both Steve Ryan, ARIN Council
> and Ben Edelman, who many saw at the last meeting for his Economics
> background, but in addition to his PhD in economics also has a J.D.
> from Harvard Law and is admitted to the Massachusetts Bar. They
> both provided significant input that the AC used to better craft
> the policy language to strengthen ARIN's legal position were this
> policy to be adopted.
> That's not to say they don't have some concerns. Nothing is 100%
> in law, particularly when there is limited case law on the subject.
> I believe both will be at the Denver meeting able to answer questions
> about legal risk. As with all policies, ARIN Council will generate
> a legal review of the policy prior to the meeting which should both
> be posted to PPML and reviewed at the meeting.
> I strongly urge anyone with legal concerns to either come to Denver,
> or participate remotely.
> Leo Bicknell - bicknell at ufp.org <mailto:bicknell at ufp.org> -
> CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
> You are receiving this message because you are subscribed to the
> ARIN Public Policy
> Mailing List (PPML at arin.net <mailto:PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> Please contact the ARIN Member Services Help Desk at info at arin.net
> if you experience any issues.
More information about the ARIN-PPML