[ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal
Bill Darte
BillD at cait.wustl.edu
Tue Mar 11 14:43:28 EDT 2008
I will piggy back upon Scott's praise of the ARIN staff.
I think it would be hard to find a more trustworthy, knowledgeable,
competent and dedicated group than ARIN staff.
Policy reliance upon them to 'do the right thing' is not an issue of
whether they have the talent and ability to do it, but rather is it
appropriate to express policy in that generalized way.
The risk of being too expressive in giving guidance on how they may do
these the task runs the risk of missing something necessary or bleeding
over into operations...whereas being to general runs the risk of lack of
transparency and perceived fairness.
Bill Darte
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
> Behalf Of Scott Leibrand
> Sent: Tuesday, March 11, 2008 1:34 PM
> To: Jim Weyand
> Cc: arin ppml
> Subject: Re: [ppml] Restrictions on transferor deaggregation
> in 2008-2: IPv4 Transfer Policy Proposal
>
> Yes, there have been some numbers produced by ARIN staff
> (http://www.arin.net/statistics/index.html), which the AC has
> been using (along with some data from whois) to judge the
> likely demand and supply of larger and smaller blocks.
>
> In addition, I would anticipate that ARIN staff will also be
> able to use the prices on the listing service to decide
> whether/when to adjust deaggregation thresholds. If the
> per-IP price for smaller blocks gets to be higher than that
> for larger blocks, for example, that may mean that more
> deaggregation needs to be permitted.
>
> Fortunately, ARIN not only has a very smart staff, but also
> has the engaged the services of an economics expert with
> experience in a wide range of Internet issues (Ben), so I
> have confidence that they will be well prepared to make the
> decisions required to ensure smooth functioning of the market.
>
> -Scott
>
> Jim Weyand wrote:
> > Scott-
> > Is there any quantitative data on the effect of deaggregation?
> >
> > The proposal relies on ARIN staff to make decisions regarding
> > deaggregation. What skills and experience will be required of staff
> > members to make reasonable decisions?
> >
> > -Jim Weyand
> >
> >> -----Original Message-----
> >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]
> On Behalf
> > Of
> >> Scott Leibrand
> >> Sent: Tuesday, March 11, 2008 12:54 PM
> >> 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, or would a more
> >> limited set of restrictions be sufficient?
> >>
> >> Some background (or skip down to the bottom if you want):
> >>
> >> In 8.3.2 Conditions on the transferee, there are two
> bullet points
> >> permitting and requiring transferees to get a larger block
> than they
> >> might otherwise, to help prevent deaggregation:
> >> * The transferee may request and receive a contiguous CIDR block
> > large
> >> enough to provide a 12 month supply of IPv4 addresses.
> >> * The transferee may only receive one IPv4 address transfer
> > through
> >> this
> >> Simple Transfer process every 6 months.
> >>
> >> In 8.3.3 Conditions on the IPv4 address block to be
> transferred, a
> >> transferor is permitted to split their block into two
> pieces, keeping
> >> one and transferring the other. This could be an even
> split into two
> >> CIDR blocks, or at the other extreme it could mean splitting a /8,
> >> keeping a /22, and transferring the remaining /9, /10,
> /11, /12, /13,
> >> /14, /15, /16, /17, /18, /19, /21, and /22. However, it also means
> > that
> >> a holder of a large IPv4 address block cannot simply
> transfer it off
> > as
> >> 16,384 /22's.
> >>
> >> In 8.3.6 Deaggregation when Permitted by ARIN, further
> deaggregation
> >> beyond 8.3.3 is allowed, at ARIN's discretion, in order to
> deal with
> > any
> >> shortage of smaller blocks resulting from the restrictions above.
> >>
> >> The conditions in 8.3.3 and 8.3.6 above represent a compromise
> >> between two views. On the one hand, there is the view that the
> >> transferee conditions in 8.3.2 are sufficient to recreate an
> >> environment very similar to the one we have today, in that
> recipients
> >> must justify
> > their
> >> need for addresses, and then they receive a block large enough to
> >> meet their needs for a certain number of months. Today that block
> >> comes
> > out
> >> of a /8 allocated from IANA to ARIN, so each such allocation
> >> generates at least one additional route in the routing
> table. There
> >> is little reason to believe that the number of prefixes
> demanded will
> >> change significantly, so there would be no incentive for
> transferors
> >> to deaggregate more than we do today, and therefore in
> this view the
> > 8.3.2
> >> conditions are adequate, and the last bullet of 8.3.3 and section
> > 8.3.6
> >> are unnecessary.
> >>
> >> The other view is that, without conditions restricting them from
> >> doing so, transferors of large netblocks will deaggregate their
> >> holdings to
> > a
> >> large degree and transfer off the resulting pieces, resulting in a
> >> shortage of larger blocks. Under this view, the transfer policy
> > should
> >> restrict the degree to which deaggregation is permitted, thereby
> >> encouraging transfer of larger blocks instead of smaller ones.
> >>
> >> In version 1.0 of the proposal, section 8.3.6 Deaggregation when
> >> Permitted by ARIN did not exist. Without it, a convincing argument
> > was
> >> made that supply of small netblocks would be restricted, thereby
> > driving
> >> up the price of small netblocks and driving down the price
> of large
> >> ones. To address this, we added section 8.3.6 in version 1.1.
> >>
> >>
> >>
> >> So, a few questions to discuss:
> >>
> >> Do you think that the IPv4 Transfer Policy should restrict
> > deaggregation
> >> of transferred netblocks? Why or why not?
> >>
> >> If so, what restrictions should be placed on
> deaggregation, and what
> >> types of deaggregation should be allowed to provide supply
> of smaller
> >> netblocks?
> >>
> >> Should any restrictions on deaggregation be written into
> the policy,
> > or
> >> should ARIN staff be given discretion to adjust the
> restrictions as
> >> needed to best serve the interests of the community
> (section 8.3.6)?
> >>
> >> Thanks,
> >> Scott
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed
> to the ARIN
> >> Public Policy Mailing List (PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/ppml
> >> Please contact the ARIN Member Services Help Desk at
> info at arin.net if
> > you
> >> experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed
> to the ARIN
> > Public Policy Mailing List (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml
> > Please contact the ARIN Member Services Help Desk at
> info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at
> info at arin.net if you experience any issues.
>
More information about the ARIN-PPML
mailing list