[ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal
Howard, W. Lee
Lee.Howard at stanleyassociates.com
Wed Mar 12 10:09:43 EDT 2008
> 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?"
188.8.131.52 Downstream customer adherence
ISPs must require their downstream customers to adhere to the
Reassignment information for prior allocations must show that each
customer meets the 80% utilization criteria and must be available
via SWIP/RHWOIS prior to your issuing them additional space.
. . .
184.108.40.206 Reassignments to multihomed downstream customers
Under normal circumstances an ISP is required to determine the prefix
size of their reassignment to a downstream customer according to the
guidelines set forth in RFC 2050. Specifically, a downstream customer
justifies their reassignment by demonstrating they have an immediate
requirement for 25% of the IP addresses being assigned, and that they
have a plan to utilize 50% of their assignment within one year of its
. . .
> This is possible right now, and as far as I can tell not
> breaking any policies.
Looks like it breaks at least one of the above policies.
You can't get a /23 because you're getting rack space. You can
get a /23 because you're hosting a bunch of equipment with
several subnets (for various, inversely proportional values of
"bunch" and "several").
> 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?
Every time you need more space, either under existing policy or
under the proposed transfer policy.
> This is possible already, with no policy changes.
Not the way I read it.
> I'd actually be surprised if it's not happening already for
> networks that were denied by their RIR.
If it is, it's in small pockets around the industry. The
reputable carriers don't do this.
> -- Kevin
> 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:
> Please contact the ARIN Member Services Help Desk at
> info at arin.net if you experience any issues.
More information about the ARIN-PPML