[arin-ppml] Did 2008-6 provide what Board needed?

Tue Apr 14 10:50:36 EDT 2009

On Tue, Apr 14, 2009 at 07:49, David Farmer <farmer at umn.edu> wrote:
> I had a thought, maybe we should be equally critical of our ourselves, as we
> have been of the Board and 2009-1, and ask if 2008-6 delivered what the
> board needed in order to do their job in preparing the ARIN Region for IPv4
> scarcity drawing near.
>
> In reading and thinking about the Board's statement from last week, and
> reviewing 2008-6, I think the Board is correct that 2008-6 doesn't provide the
> predictability and certainty from a network planning point of view the
> community really needs with IPv4 scarcity drawing near.  I believe this is
> caused by the timetable for implementation or more correctly the lack of any
> specific timetable for implementation in 2008-6.  And, the way the sunset
> clause is dependent on that unpredictable timetable for implementation by
> sunsetting 3 years after implementation.
>
> By having 2008-6 dependent on IANA free pool exhaustion or the ARIN
> Region reaching a threshold of scarcity, whatever any of us intended that to
> mean, does nothing to reduce the risk IPv4 scarcity represents to the
> community, does nothing to increase the predictability of the situation, and
> provides no help in network planing.

It does reduce the risk of IPv4 scarcity to the community as much as
any liberalized transfer policy would/will (the exact amount is
arguable of course).  Predictability on the other hand I will grant
you.  Not knowing when the policy will start and end ahead of time is
not helpful to network planning - agreed.

> The Board's solution is to implement immediately and eliminate the sunset
> clause.  This definitely clears up the unpredictability and uncertainty, and
> makes network planning easier.  However, this solution is inconsistent with
> the compromises within 2008-6 that allowed the community to gain the
> minimal level of consensus that it did.  Further, by eliminating any triggers or
> deadlines this solution eliminates any sense of urgency for adoption of IPv6
> within the community.  The Sunset in 2008-6 makes it clear that allowing
> IPv4 Transfers isn't going to be a long-term solution by itself.

Agreed on all points.

> I believe that we can solve the unpredictability and uncertainty while
> remaining mostly consistent with the compromise within 2008-6.  I believe
> the key to solving the unpredictability and uncertainty is to provide a specific
> start and end date for IPv4 transfers to Specified Recipients. Then provide a
> safety trigger to start early if IANA exhaustion occurs significantly faster than
> anyone expects and an automatic extension if IANA exhaustion takes
> significantly longer than anyone expects.

I think this is overly complicated and still introduces the
uncertainty and unpredictability you are trying to remove (albeit to a
lesser degree).  You are effectively saying that the transfers will
start on A and end on Z unless X changes, with no perfect way to
predict X.

> For discussion, lets say we could know for a fact that IANA will allocate the
> last /8s per NRPM 10.4.2.2 on June 30th 2011.  So lets pick one year before
> that for the start date and two years after that for the end date, giving us
> June 30th 2010 for the start and June 30th 2013 for the end, the three year
> period in 2008-6.  Currently, it looks like IANA exhaustion will occur
> sometime in mid-2011, but no one know for sure actually when, but it is a
> good bet it will occur sometime in 2011. So lets give ourselves the whole
> year of 2011 to create a good amount of certainty, lets split that equally with
> the start and end date.  So lets pick a new a start date of January 4th 2010,
> the first business day of 2010, and an end date of December 31st, 2013, the
> last business day of 2013.
>
> This really give us 4 years, but that extra year buys us something, specific
> dates, with enough cushion that we have a fairly high probability we that we
> will start with a minimum of a year before and an end a minimum of two
> years after IANA exhaustion.  These specific dates greatly reduce the
> unpredictability and uncertainty, and allow network planing to begin
> immediately based on these dates, while retaining a sense of urgency for a
> transition.  Further, we have a solution much more consistent with the
> compromises within 2008-6 that provided minimal consensus within the
> community to move forward.
>
> Now lets add that safety trigger at the to the start, in case IANA exhaustion
> accelerates and occurs significantly sooner than anyone expects.  I propose
> if we get to 13 /8s left excluding the /8s reserved in NRPM 10.4.2.1, then we
> start IPv4 transfers to Specified Recipients in 30 days.  The 30 days, is to
> allow ARIN to make an announcement.  The 13 /8s is from the fact that IANA
> is currently allocating over 12 /8s to the RIRs per year, plus an extra month
> to make an announcement, this seems like a reasonable safety trigger.  I
> believe it is highly unlikely this would happen prior to January 2010, but if it
> did, I don't think anyone would argue that it wasn't time to trigger, things
> would be going way fast than anyone expects.
>
> Now the automatic extension, if IANA exhaustion takes significantly longer
> than anyone thinks it should.  This is much more simple, we simply
> guarantee two years after IANA exhaustion.
>
> Therefore, if IANA exhaustion actually takes place in 2011, which seems
> likely, then neither the safety trigger or the automatic extension will be
> necessary, and IPv4 transfers will be allowed for 4 years.  Given that we
> cannot know for sure when IANA exhaustion with occur, in any case this
> timetable creates a high degree of predictability, while maintaining a sense of
> urgency for IPv6 adoption.
>
> Some possible policy language;
>
> IPv4 Transfers to Specified Recipients will begin on the earlier of the
> following two dates; January 4th 2010, or 30 days after the IANA free pool
> reaches 13 /8s available, exclusive of the /8s reserved in 10.4.2.1.
>
> IPv4 Transfers to Specified Recipients will end on the later of the following
> two dates; December 31st, 2013, or 2 years after ARIN receives its last /8
> per section 10.4.2.2.
>
> An expected end date of December 31st, 2013, provides sufficient time to
> implement a policy that obtains consensus at the Fall 2013 PPM in October
> 2013.  Maybe extending IPv4 transfers to Specified Recipients or possibly
> making them permanent, and maybe even adding all network resources
> including IPv6 and ASNs.  I believe that by 2013 it should be obvious one
> way or the the other.

My understanding of the lack of a specified start date in 2008-6 is
that it meant to leave the decision of when to pull the trigger up to
the Board.  Since this was part of the proposal that gained consensus
and the BoT obviously thinks that the trigger date/time is NOW, I
think the logical thing to do (if we want to make this process
predictable) is to trust the Boards judgement (as we were doing with
2008-6 already) and make the policy effective immediately.  Then we
set the sunset date at implementation plus 5 years.  This means that
if implemented following ARIN XXIII, the policy would be set to expire
in May of 2014, three years after expected IANA exhaustion.  This
solution provides a release valve now which should help stop or at
least slow the run on the bank as well as a predictable end date that
can be planned for.

> Further, delaying implementation to January 2010, would allow ARIN to get a
> good start on POC validations, assuming 2008-7 gains consensus in San
> Antonio, which could help prevent fraudulent transfers.  We would also have
> a chance to complete other IPv4 end-game policies like maybe 2009-2,
> providing a better picture of the whole solution to IPv4 scarcity not just IPv4
> Transfers to Specified Recipients.  While allowing everyone, including ARIN,
> to immediately begin their planing for IPv4 Transfers to Specified Recipients
> to begin on a well known date.

While I am obviously in favor of 2008-7 and the gains it will provide
us, as long as we maintain the "authorized resource holders served by
ARIN" language from 2008-6, I think we will be protected from
fraudulent transfers.  As I read it, that text means that ARIN will
vet the transferor before any transfer can take place.

> Personally, I would like to extend the end date to December 31st, 2014, I
> can't provide a good argument for why, but that is what my gut tells me.
> However, I believe the December 31st, 2013 date is much more consistent
> with the compromises within 2008-6, and sticking to the compromise is
> probably more important than my gut.  I could stand to loose some of my gut
> anyway. :)
>
> Does this make sense?  Is it a workable compromise?  Does it provide
> enough certainty?  Does it allow for sufficient network planning?  Does it
> provide a proper sense of urgency for IPv6 adoption?
>
>
> =======================================================
> David Farmer                                 Email:     farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota                      Phone:     612-626-0815
> 2218 University Ave SE                       Cell:              612-812-9952
> Minneapolis, MN 55414-3029                   FAX:       612-626-1818
> =======================================================
>
> _______________________________________________
> 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.
>

-- 
Chris Grundemann
weblog.chrisgrundemann.com