[ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal
Bill Darte
BillD at cait.wustl.edu
Wed Mar 12 10:12:43 EDT 2008
- Previous message: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal
- Next message: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> > On Mar 11, 2008, at 2:26 PM, Jo Rhett wrote: > > > Ted Mittelstaedt wrote: > >> What you CANNOT have, is your cake and eat it to. You CANNOT have > >> prolonged > >> IPv4 lifespan without an increase in deaggregation. > > > > I don't often find myself 100% agreeing with Ted, but this > is one of > > those cases. I don't believe that preventing deaggregation is > > plausible. I suspect that attempts to do so with move parties > > interested in using the transfer policy (if approved) into > the black > > market to avoid dealing with the policy limitations. > > > Okay, either I'm missing something completely here or > everyone else has gotten so wrapped up in the idea of > transferring space that nobody's considering the alternative > that I think is a whole heck of a lot more likely... which is > already possible and going to cause deaggregation wether we > want it or not. > > Why sell when you can rent and keep collecting cash? Kevin, I agree. This is a fear I have of the whole loosened transfer policy. Given that the policy were put in place, this loosens not just the transfer policy, but the notion of who's in charge. I see that legacy block holders and those that can free up sizeable blocks can become local registries and who's to stop that? > > Right now I can go to any colo provider and say "I want a > half dozen racks, power, and connectivity for my 150 > servers." and pretty easily get a /23 or larger. Now what > happens if I say "You know, why don't you forget about the > racks, power, bandwidth and everything else... > How much would just the /23 be per month?" > > This is possible right now, and as far as I can tell not > breaking any policies. A big hosting or colo provider with > excess v4 space can SWIP space to the highest bidder for a > large monthly check, and have the security that if they end > up needing more v4 later they can pull it back. There's no > need for a black market, no need for complying with a > complicated transfer policy, no need to give up space > irrevocably, and it becomes a continuing revenue stream > instead of a one off payment. > As v4 space gets more and more scarce, the market price goes > up along with the asking price. > > I don't think there's any way this can be prevented under > current policies, and even though it feels wrong I don't know > how you can prevent this without preventing other more > "legitimate" business. > Require that the address space come with some kind of > service? Okay, throw in a dialup PPP line with it. Where do > you draw the line that won't take more time to verify than it's worth? > > Rather than a stock-market like service of selling IP space, > I think it's a lot more likely that we're going to see ISPs > offering IP space as a standalone monthly service. > > This will cause deaggregation. > > This is possible already, with no policy changes. > > I'd actually be surprised if it's not happening already for > networks that were denied by their RIR. > > -- Kevin > > _______________________________________________ > 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. >
- Previous message: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal
- Next message: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list