[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