[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal
All,
Hello.
I will forward our proposal to this mailing list just FYI.
It is not an IPv6 policy, though.
Regards,
Takashi Arano
>X-Original-To: arano@inetcore.com
>Delivered-To: arano@inetcore.com
>From: "Kenny Huang" <huangk@alum.sinica.edu>
>To: <sig-policy@apnic.net>
>Date: Tue, 30 Jan 2007 15:51:34 +0800
>X-Mailer: Microsoft Office Outlook, Build 11.0.6353
>Thread-Index: AcdEKKt/vRhEhwUHSvaQIKaDUzp1lAAGqTXQ
>X-AP-Spam-Status: No, hits=0 required=6
>X-AP-Spam-Status: No, hits=0 required=6
>X-AP-Spam-Score: 0 (notspam)
>X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
>Cc:
>Subject: [sig-policy] prop-046: IPv4 countdown policy proposal
>X-BeenThere: sig-policy@lists.apnic.net
>X-Mailman-Version: 2.1.4
>List-Id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
>X-AP-Lists: APNIC SIG on resource management policy<sig-policy.lists.apnic.net>
>List-Unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
>List-Archive: <http://www.apnic.net/mailing-lists/sig-policy>
>List-Post: <mailto:sig-policy@lists.apnic.net>
>List-Help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
>List-Subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
>Sender: sig-policy-bounces@lists.apnic.net
>
>
>
>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@alum.sinica.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.
>
>
>* sig-policy: APNIC SIG on resource management policy *
>_______________________________________________
>sig-policy mailing list
>sig-policy@lists.apnic.net
>http://mailman.apnic.net/mailman/listinfo/sig-policy
