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

[David Farmer]

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. 

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.

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.

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.

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.

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
=======================================================