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

[Bill Darte]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
> Sent: Tuesday, April 14, 2009 8:49 AM
> To: ARIN PPML
> Subject: [arin-ppml] Did 2008-6 provide what Board needed?
> 
> 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.

What predictability?  The point of the later...near IANA
runout...implementation expectation and the sunset clause within 2008-6
WAS supposed to provide predictability....

The predictability was that IPv4 was NOT the future of Internet
addressing, but rather a sureness that IPv6 was.  People could predict
with reasonable degree of certainty that in a few years, there would be
less risk in pursuing a v6 as a company strategy than might be found in
v4.  The signal that was sent, and explained at the meeting, was that
ARIN would not support a continuance of v4 over v6.  The transient
nature of 2008-6 was supposed to be an emergency, stop-gap measure to
provide continuity of services to v4 users that hadn't weaned themselves
of v4 or for which the 'complete v6 answers' were not yet available.

2008-6 was never about demonstrating the ever more efficient use of v4
addresses.....it was designed counter to that notion.

So, 2009-1 and 2008-6 have virtually nothing to do with one another
other than they funadmentally create a marketplace for existing v4
addresses...everything else about them is opposed to one another.

bd


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