[arin-ppml] Policy Proposal 119: Globally Coordinated Transfer Policy

Wed Oct 13 10:45:31 EDT 2010

On Wed, Oct 13, 2010 at 07:42, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Mon, Oct 11, 2010 at 01:20:51PM -0400, ARIN wrote:
>> Policy statement: Any RIR's member may transfer IPv4 addresses to the
>> member of another RIR as long as the two RIRs agree and exercise
>> Internet stewardship and the values expressed in RFC2050.
>
> I applaud the attempt at super-simple policy.  It is refreshing.
>
> That said, I wish to play a sort of devils advocate for a moment.
>
> There are activities one RIR's community thinks are "bad", but that
> other RIR's communities seem to think are "good".  To some extent
> that is why we have separate RIR's, but there is also a desire to
> limit the badness globally.  I believe the references to RFC2050
> are an attempt to restate such a global limit.
>
> Unfortunately RFC2050 is already long in the tooth, and with the
> impending IPv4 exhaustion will become less relevant very quickly.
> In particular, I think if you look at a post run-out world, it is
> likely different people will come to the same conclusion about the
> text in various areas.

Thanks for the excellent feedback Leo. I do want to point out that
when crafting this ultra-simple policy statement, we chose our words
very carefully: Internet stewardship *and* the _values_ expressed in
RFC2050 is meant to convey the spirit by which the RIRs should
interact ("do the right thing") without binding them explicitly to any
particular (possibly outdated) text.

~Chris

> To that end, I'm actually not sure what the effect of this policy
> would be down the road, and being unable to evaluate that effect I
> find I cannot support it.
>
> If you don't care about the details, stop reading now, if you do,
> continue.
>
> Let's fast forward 2-3 years from now to a world where IANA and all 5
> RIR's are "out" for all practical purposes, and look at some of the
> statements in RFC 2050 from that context.
>
> Right from the start, there is something quite interesting:
>
>   By approving this document as a Best Current Practice,the IESG
>   asserts its belief that this policy described herein is an accurate
>   representation of the current practice of the IP address registries
>   with respect to address assignment.  This does not constitute
>   endorsement or recommendation of this policy by the IESG. The IESG
>   will reevaluate its approval of this document in December 1997 taking
>   into consideration the results of the discussions that will be take
>   place in the IRE Working Group between now and then.
>
> The document is not a standards track RFC, it is a documentation of the
> Best Current Practice /in 1996/.  Indeed, I actually think it's well
> overdue to be updated to current practice, but that's another discussion
> for another day.
>
>  1) Conservation: Fair distribution of globally unique Internet address
>     space according to the operational needs of the end-users and Internet
>     Service Providers operating networks using this address space.
>     Prevention of stockpiling in order to maximize the lifetime of the
>     Internet address space.
>
> "Fair distribution" is a very simple thing when there are plenty of
> addresses, we can use the Chinese buffet model (take all you want, eat
> all you take).  When there is no more space, and we're looking at a
> transfer market (paid or otherwise) it takes on an entirely different
> color.  Do we have to ensure everyone gets some, regardless of ability
> to pay?  Is distribution based on who has the most money fair?  Does
> fairness require the RIR's to more aggressively revoke space from those
> who are not using it to fairly distribute to those who need it?  The
> last sentence about stockpiling would seem to indicate that is
> important.
>
>      (Under the end user "Assignment Framework" section)
>
>      c)  the organization's actual requirement for IP space is
>          very large, for example, the network prefix required to
>          cover the request is of length /18 or shorter.
>
> All of the RIR's have changed their policy to allow longer than /18
> prefixes to end users, and I think off the top of my head many now allow
> longer prefixes to end users than ISP's.  As we get closer to
> exhaustion, prefix length will get smaller.
>
>   Organizations will be assigned address space based on immediate
>   utilization plus 1 year projected utilization.  A prefix longer than
>   /24 may be issued if deemed appropriate.  Organizations with less
>   than 128 hosts will not be issued an IP address directly from the
>   IRs.  Organizations may be issued a prefix longer than /24 if the
>   organization can provide documentation from a registry recognized ISP
>   indicating the ISP will accept the long prefix for injection into the
>   global routing system.
>
> I believe there are already web-hosters who have less than "128
> hosts", but have received space because they host hundreds of web
> sites, each of which might need an IP address.
>
> I'm not pointing these out to argue about any of them individually,
> but simply to point out the document, like any, becomes less relevant
> over time.  This makes sense, as it is a best current practice, and
> not the hard and fast requirements many seem to want to make it.
>
> We're now in a post run out world, and want to assess "need".  There
> will be thousands of folks who can demonstrate technical need the
> way we have always done it, but we can't service them all.  So a
> new criteria needs to be added into the mix.  All of the RIR's seem
> to be moving to money via some mechanism for paid transfers.
> Economists and capitalists would love this, since clearly those
> with the greatest need for a resource are the ones willing to pay
> the most money.
>
> It is easy to see an argument being made as this backlog of need
> increases that much of (but not all) our current work to verify
> need is unnecessary.  Why spend hours verifying an organization
> "needs" a /16 and checking all of their engineering plans when all
> they can buy in the market place is a /24?  And if they are willing
> to pay $50,000 for that /24, isn't that a better indicator of how
> much they need it than any engineering plan?
>
> I'm not sure an RIR could argue a pure dollar based method passes
> the smell test, for instance 2050 does suggest "Prevention of
> stockpiling in order to maximize the lifetime of the Internet address
> space.", so perhaps they have to insure someone isn't just buying
> it up to stockpile.  However in such a scheme it would be easy to
> say your engineering plans do not need to be reviewed unless you
> have paid for more than a /20, because if you have very small amounts
> of space its rather hard to call it stockpiling.
>
> In short, I fear the best practice that is 2050 is far shaker ground
> going forward than many realize.  It won't ever be tested in a
> court, but it will be continuously tested in the court of public
> opinion.  It is though a snapshot in time of a continuously evolving
> process where we have already seen fit to change its guidance.  I
> can easily see a future where four of the five RIR's decide a practice
> is the best current practice in the future, but one of the four is
> a hold out for whatever reason.  To the extent this is a global policy,
> IANA would likely side with the four, noting the represent community
> consensus.
>
> While IPv4 is getting all the attention at the current time, IPv6
> is, as usual, the more interesting topic.  I urge you to consider
> a world 20 years from now, where IPv4 has been removed from all of
> the large Internet backbones and we're operating in a primarily
> IPv6 only world.  Now re-read 2050.  Does it make sense?  How much
> of it matches the best current practice in this future world?
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org