[sig-policy] prop-046: IPv4 countdown policy proposal

  • To: <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-046: IPv4 countdown policy proposal
  • From: "Kenny Huang" <huangk at alum dot sinica dot edu>
  • Date: Tue, 30 Jan 2007 15:51:34 +0800
  • Cc:
  • List-archive: <http://www.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • Thread-index: AcdEKKt/vRhEhwUHSvaQIKaDUzp1lAAGqTXQ
    • 
      Dear SIG members
      
      Yesterday, the proposal "IPv4 countdown policy proposal" was sent to the
      Policy SIG for review. It will be presented at the Policy SIG at APNIC 23 in
      Bali, Indonesia, 26 February - 2 March 2007. You are invited to review and
      comment on the proposal on the mailing list before the meeting.
      
      The proposal's history can be found at:
      
              http://www.apnic.net/policy/proposals/prop-046-v001.html
      
      Regards,
      
      Kenny Huang
      Policy SIG
      huangk at alum dot sinica dot edu
      
      
      prop-046-v001: IPv4 countdown policy proposal
      
      ________________________________________________________________________
      
      
      
      Co-authors: Toshiyuki Hosaka (JPNIC)
      			Takashi Arano (Intec Netcore, Inc.)
                   Kuniaki Kondo (Atelier Mahoroba)
                   Tomohiro Fujisaki (NTT)
                   Akinori Maemura (JPNIC)
                   Kosuke Ito (IRI Ubitech)
                   Shuji Nakamura (IPv6 Promotion Council)
                   Tomoya Yoshida (NTT Communications)
                   Susumu Sato (JPNIC)
                   Akira Nakagawa (KDDI)
      
      Version:    1
      
      Date:       29 January 2007
      
      SIG:        Policy
      
      
      1.  Introduction
      ----------------
      
      The exhaustion of IPv4 address is approaching round the corner. Geoff
      Huston's latest projection at Potaroo (as of January 6, 2007)
      (http://www.potaroo.net/tools/ipv4/) draws the date of IANA pool exhaustion
      as 31st May 2011, and that of RIR pool as 14th July 2012.
      
      Tony Hain projects similar dates based on a different algorithm of his own.
      >From these data, we may observe that if that the current allocation trend
      continues, the exhaustion of IPv4 address space is expected to take place as
      early as within the next five years.
      
      ICANN/IANA and RIRs must co-ordinate with stakeholders to achieve smooth
      termination of IPv4 address space as the Internet bodies responsible for
      stable management and distribution of IP number resources.
      
      This proposal provides some ideas as well as concrete examples of the policy
      that helps IPv4 allocations come to an end with "the minimum confusion" and
      in "as fair manner as possible".
      
      "Five years at the earliest" is not too far in the future for the exhaustion
      of IPv4 address space. Assuming the minimum of one year is required for
      sufficient policy discussions with this proposal as a start, and two years
      for preparation and transfer by LIRs, we need to start the discussions right
      at this time.
      
      
      
      2.  Summary of current problems
      -------------------------------
      
      Despite the fact that several projections are made on IPv4 address to run
      out as early as within the next few years, no discussions are taking place
      on any of the RIR's policy fora including that of APNIC.
      This section lists possible problems if no policies are defined to prepare
      for the terminal period of allocations.
      
      
      2.1 LIR
      
      	LIRs currently do not consider IPv4 address exhaustion as an
      	imminent issue in the first place. It is possible that they will
      	finally realize the situation only when impacts of the exhaustion
      	becomes visible as a practical matter, and lead to confusions such
      	as re-addressing their network or making subsequent requests at the
      	last minute in within a	limited time frame.
      	
      	There could also be cases where allocations blocks cannot be
      	allocated 	to some of the LIRs even though requests are
      submitted
      	on the same day. Moreover, although it would be necessary for LIRs
      	to announce to their customers that IPv4 address space will not be
      	available for assignments eventually, it is difficult to plan this
      	timing without clear policy	for the last phase of allocations.
      	
      	As new IPv4 address allocations space will no longer be available,
      	LIRs have no choice but to build networks based on IPv6. However,
      	there are risks of trouble if preparations are made from that point
      	in time, as it will lead to premature actions even if some time can
      	be bought by re-addressing and subsequent allocations.
      	
      	Lastly, using up all available IPv4 address space will disable
      	assignments to services inevitable for co-existence of IPv4 and
      	IPv6 networks, such as the translator service between the two
      	networks, which it may create situation where transfer to IPv6
      	network will not even be possible.
      
      
      2.2 RIR/NIR
      
      	It is likely that smooth allocations by RIRs/NIRs will be hindered
      	by rush of inquiries during the terminal phase of allocations.
      
      
      2.3 End users
      
      	End users generally receive address assignments from ISPs
      	accompanied with Internet connection service. If an ISP no longer
      	has IPv4 address space available, nor unable to provide IPv6
      	service, end users will not be able to receive services from that
      	ISP.
      	
      	Moreover, if the terminal date of allocations remains ambiguous,
      	it may leave end users behind to prepare for IPv6 ready network.
      
      
      
      3.  Benefits
      ------------
      
      There will be the following benefits by implementing the policy for
      IPv4 address exhaustion as proposed on this paper.
      
      
      3.1 LIR
      
      	LIRs will be able to consciously plan their addressing within their
      	networks if the final date of allocations is clearly demonstrated.
      	Keeping a certain amount of unallocated address blocks enables
      	allocations/assignments for "critical infrastructure" after the
      	termination of regular allocations, which will be explained later
      	section in more details.
      
      
      3.2 RIR/NIR
      
      	Announcing the date of terminating allocations in advance and
      	ensuring that all allocations before this date will be made
      	according to the policy at the time enables RIRs/NIRs to make the
      	last allocation without confusions and avoids causing feelings of
      	unfairness among LIRs and end users. In addition, consistent policy
      	applied to all RIRs removes bias towards certain region as well as
      	inter-regional unfairness. The period which IPv6 support is
      	completed becomes clear, therefore, RIRs/NIRs can prepare for this.
      
      
      3.3 End user
      
      	As this proposal enables LIRs to prepare for the terminal period of
      	allocations in advance, it reduces the risk of delays/suspensions of
      	assignments from LIRs to enduers, and end users will be able to
      	continuously receive services from LIRs. As in the case of LIRs, end
      	users will be able to prepare for IPv6 support by the date of
      	allocation termination is clarified. In addition, IPv6 connectivity
      	as well as IPv4 address required during the allocation termination
      	period will be smoothly secured by LIRs preparing for such period.
      
      	As listed above, there will be important, notable benefits for
      	stakeholders as a result of this policy. It is therefore necessary
      	to take the following actions to achieve a smooth transfer to IPv6
      	and prevent causing instability in the Internet as well as;
      	
      	 - start discussions on allocation scheme during the exhaustion
      	   period,
      	
      	 - indicate a roadmap to exhaustion after raising awareness on the
      	   issue, and
      	
      	 - allow enough time for LIRs to plan timing of addressing of their
      	   networks, submit allocation requests, and consider how to switch
      	   to IPv6.
      
      
      
      4.  Proposal
      -----------
      
      4.1  Principles
      
      	As the first step to discuss IPv4 exhaustion planning, we would
      	like to have an agreement(consensus) on the following four
      	principles.
      
      	--------------------------------------------------------------------
      	(1) Global synchronization:
      	
      		All five RIRs will proceed at the same time for measures on
      IPv4
      		address exhaustion.
      	
      	(2) Some Blocks to be left:
      	
      		Keep a few /8 stocks instead of distributing all.
      	
      	(3) Keeping current practices until the last moment :
      	
      		Maintain the current policy until the last allocation.
      	
      	(4) Separate discussions on "Recycle" issue :
      	
      		Recovery of unused address space should be discussed
      separately
      	--------------------------------------------------------------------
      	
      
      	(1) Global synchronization:
      
      		All RIRs must proceed at the same time to take measures for
      		IPv4 address exhaustion. This is important not only for
      ensuring
      		fairness for LIRs across the regions, but alsot to prevent
      		confusions such as attempts to receive allocations from an
      RIR
      		outside their region. The five RIRs should facilitate
      bottom-up
      		discussions, which should be well coordinated under the
      		leaderships of ICANN ASO and NRO.
      
      
           (2) Some blocks to be left:
      
      		It is not practical to consider that IPv4 address blocks can
      be
      		allocated to the last piece. It is expected to cause
      confusions
      		if one	party can receive an allocation while the other has
      to
      		give up, just with a touch of a difference. The best
      solution
      		to avoid such confusion is to set in advance, a date in
      which
      		one is able to receive	an allocation if requests are
      submitted
      		before this timeline.
      		
      		Furthermore, there are few cases where allocations or
      		assignments of IPv4 address space become absolutely
      necessary
      		in the future. For	example, requirements to start a
      translator
      		service between IPv4 and IPv6 networks should be supported,
      and
      		there may be some requirements	in the future that are
      beyond
      		our imagination at this current moment.
      	
      		As such, a date to stop allocations under the current policy
      		should	be set/defined so that certain number of IPv4
      address
      		blocks will be kept as stocks instead of allocating all
      blocks
      		without remains.
      
      
      	(3) Maintaining current practices until the last moment :
      
      		Allocations should be made based on the current policy until
      the
      		time to terminate allocations. As the IPv4 Internet has now
      		developed into a social infrastructure supporting large
      number
      		of businesses, making large changes in the current policy
      		towards conservation within the next one or two years will
      lead
      		to large-scale confusions, and difficult in the reality.
      
      
      	(4) Separate discussion from "Recycle" issue
      	
      		Recovering unused allocated/assigned address blocks is an
      		important measure, and in fact, it has already be discussed
      and
      		implemented in each RIR regions. This issue, however should
      be
      		considered separately from this proposal as recovery of a
      few
      		/8 blocks extends the lifetime of IPv4 for less than one
      year
      		while efforts for the recovery is expected to require
      		substantial time.
      
      
      4.2 Details of the proposal
      
      	This section provides an example of a proposal in case consensus is
      	reached on basic principles introduced in section 4.1.
      	
      	 - Set the date for termination of allocations and the date of
      	   announcement
      	
      	   Set the date to terminate allocations as a general rule, and
      	   announce it a certain period in advance. Define the date of
      	   announcement as "A-date" and the date to terminate allocations
      	   as "T-date". The two dates will be set as follows:
      	
      	
      		   A-date (Date of Announcement):
      			
      		   - The day in which the IANA pool becomes less than 30*/8
      			
      		   - RIRs must announce "T-date" on this day, which is
      defined
      			 later
      			
      			 (*) There will be no changes in the policy on
      A-date
      
      			
      		   T-date(Date of Termination):
      			
      		   - Exactly two years after A-date
      			
      		   - 10*/8 blocks should remain at T-date, and defined as
      two
      			 years after A-date, based on the current pace of
      			 allocations
      				
      		   - It is however possible to move T-date forward at the
      point
      			 where address consumpution exceeds the projections
      during
      			 the course of two years
      			    		
      			 (*) new allocations/assignments from RIRs should
      terminate
      			     on T-date as a general rule. Allocations or
      assignments
      			     to "critical infrastructure" after T-date
      should be
      			     defined by a separate policy.
      		
      		
      		A-date is set in order to:
      		
      		- Allow some grace period and period for networks to be IPv6
      		  ready until the termination of allocations.
      		- Prevent unfairness among LIRs by clarifying the date, such
      		  as not being able to receive allocations by a small
      difference
      		  in timing.
      		
      		The rationale for setting A-date as "when IANA pool becomes
      less
      		than 30*/8" is as follows:
      		
      			The rate of allocations from IANA to RIRs after 2000
      is as
      			follows.
      			
      				2000 : 4*/8
      				2001 : 6*/8
      				2002 : 4*/8
      				2003 : 5*/8
      				2004 : 9*/8
      				2005 : 13*/8
      				2006 : 10*/8
      
      			Approximately 10*/8 has been allocated annually
      after 2003,
      			and the consumption is likely to accelerate with
      rise of the
      			last minute demands. As it is better to keep minimum
      stocks
      			of address pool at IANA, 30*/8 is set as the
      threshold
      			value, and allocations should be terminated two
      years after
      			it reaches the value, which ensures that IANA/RIRs
      secure
      			the address space for allocations/assignments to
      critical
      			infrastructure.
      
      
      4.3 Effect on APNIC members/NIRs
      
      	APNIC members are expected to concretely grasp the termination date
      	of allocations and take actions within their organization to prepare
      	for the event.
      	
      	NIRs will also terminate allocations to its LIRs in line with APNIC.
      	Therefore, NIRs will be required to sufficiently promote and keep
      	the	community informed on the date of termination of
      allocations,
      	just as it is expected of APNIC.