[LACNIC/Politicas] IPv4 Countdown policy

Nicolás Ruiz nicolas at ula.ve
Sat May 5 23:06:12 BRT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Toshiyuki Hosaka wrote:

> Please find the policy proposal to be presented next LACNIC meeting, as
> below. Should you have any comments or questions please feel free to
> contact me.

I agree with the proposal.

> 
> regards,
> toshi
> --
> Toshiyuki Hosaka
> Japan Network Information Center (JPNIC)
> 
> 
> Summary of Proposal:
> --------------------
> 
> This policy proposal proposes four general principles, which will be
> needed to accomplish the smooth termination of IPv4 address allocation.
> 
> The four general principles are described below:
> 
>    1. Global Synchronisation:
>       All five RIRs will proceed at the same time for measures on IPv4
>       address exhaustion.
> 
>    2. To set and announce the date when the allocation is terminated:
>       To set the date when RIRs cease the allocation in accordance with
>       a precise estimation and to announce the date far before the
>       termination date
> 
>    3. Not to change the current address policy stricter for the
>       extension of IPv4 address lifetime:
>       Keeping the current allocation criteria as it is until the last
>       date to ensure the steady provision of IPv4 address space
> 
>    4. Separate discussions on "Recycle" issue:
>       Recovery of unused address space should be discussed separately
> 
> 
> Draft Policy Text
> -----------------
> 
> i. Introduction
> 
> The exhaustion of IPv4 address is approaching round the corner. Geoff
> Huston's latest projection at Potaroo (as of 6 January 2007) draws the
> date of IANA pool exhaustion as 31 May 2011, and that of RIR pool as 14
> 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.
> 
> ii.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 had taken
> place on any of the RIR's policy fora before APNIC 23 Meeting in
> February 2007. This section lists possible problems if no policies are
> defined to prepare for the terminal period of allocations.
> 
> ii-a 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
> will be forced to build networks with a big architectural change whether
> it will be with hierarchical NAT or with IPv6 or even with another solution.
> 
> 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.
> 
> ii-b RIR/NIR
> 
> It is likely that smooth allocations by RIRs/NIRs will be hindered by
> rush of inquiries during the terminal phase of allocations.
> 
> ii-c End Users
> 
> Regardless which out of hierarchical NAT and IPv6 is used for the
> Internet connection after IPv4 address is exhausted, End Users will more
> or less experience a change of specification for their Internet
> connection. End Users might be confused if such a change were not
> well-coordinated or informed.
> 
> iii Benefits
> 
> There will be the following benefits by implementing the policy for IPv4
> address exhaustion as proposed on this paper.
> 
> iii-a 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.
> 
> iii-b 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.
> 
> iii-c 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 End Users, 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
> 
>     * allow enough time for LIRs to plan timing of addressing of their
>       networks, submit allocation requests, and consider how to switch
>       to an alternative solution
> 
> iv.Proposal
> 
> iv-a 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 synchronisation
>    2. To set and announce the date when the allocation is terminated
>    3. Not to change the current address policy stricter for the
>       extension of IPv4 address lifetime
>    4. Separate discussions on "Recycle" issue
> 
> 
> 1. Global synchronisation:
> 
> 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 also 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. To set and announce the date when the allocation is terminated:
> 
> 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. Not to change the current address policy stricter for the extension
> of IPv4 address lifetime:
> 
> 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.
> 
> iv-b An Example of Detailed Policy to be Implemented
> 
> This section provides an example of a proposal in case consensus is
> reached on basic principles introduced in section iv-a.
> 
> 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 consumption 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 for networks to be ready for an
>       alternative solution 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.
> 
> iv-c Effect on RIR Members/NIRs
> 
> RIR members are expected to concretely grasp the termination date of
> allocations and take actions within their organisation to prepare for
> the event.
> 
> NIRs (if any in the region) will also terminate allocations to its LIRs
> in line with the RIR. 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 the RIRs.
> 
> v. Authors
> 
> Akinori MAEMURA (JPNIC)
> Toshiyuki HOSAKA (JPNIC)
> Takashi ARANO (Intec Netcore, Inc.)
> Kuniaki KONDO (Atelier Mahoroba)
> Tomohiro FUJISAKI (NTT)
> Kosuke ITO (IRI Ubitech)
> Shuji NAKAMURA (IPv6 Promotion Council)
> Tomoya YOSHIDA (NTT Communications)
> Susumu SATO (JPNIC)
> Akira NAKAGAWA (KDDI)
> 
> (end of text)
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> 

- --
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
- --
Juan Nicolás Ruiz    | Corporación Parque Tecnológico de Mérida
                     | Centro de Cálculo Cientifico ULA
nicolas at ula.ve       | Avenida 4, Edif. Gral Masini, Ofic. B-32
+58-(0)274-252-4192  | Mérida - Edo. Mérida. Venezuela
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPTgUmjsZS9ZBxv8RAi9DAJ4vFX4fg8vGPLz4LqQypBbjMKjVowCfbzPE
q3FlCSwzcWHFCLr1PndZM2w=
=TOvg
-----END PGP SIGNATURE-----




More information about the Politicas mailing list