[LACNIC/Politicas] FW: [ppml] Policy Proposal: IPv4 countdown policy proposal
Raul Echeberria
raul at lacnic.net
Mon Feb 26 13:19:37 BRT 2007
Estimado Christian:
Este es un tema de mucho interés para nosotros.
LACNIC ya ha estado trabajando en el marco del
NRO - Number Resource Organization, (www.nro.net)
en la búsqueda de algunas medidas que permitan
mitigar los efectos que pudieran ser negativos
para nuestra región en la transición de IPv4 a
IPv6, lo cual incluye por supuesto la natural
caída constante del pool central de direcciones IPv4.
Coincido en que sería muy bueno incluir en el
foro público una mesa redonda con debate.
Creo que este es un tema muy importante para los
operadores y proveedores de Internet de la región.
Dime por favor si necesitas o si quieres alguna
información adicional en este momento sobre este tema.
Saludos
Raúl
At 01:33 p.m. 22/02/2007, ARG-O'FLAHERTY, CHRISTIAN wrote:
>Estimados,
>
>En otros registros se están presentando
>propuestas para contemplar una etapa de "cuenta regresiva" para IPv4.
>
>El impacto de esta política será dificil de
>analizar y requiere un estudio y un debate que deberiamos empezar ya mismo.
>
>Creo que nuestro próximo Foro Público será una
>buena oportunidad para empezar a entender el
>impacto de una política asi y formar una posición en nuestra región.
>
>Quisiera saber si hay interés y si podemos
>contar con el apoyo de Lacnic para plantear
>durante la reunión de Mayo un espacio para el
>análisis (tal vez con un panel o invitando a los originadores de la propuesta).
>
>Encontrarán abajo la política presentada en APNIC y ARIN.
>
>Saludos,
>
>Christian
>
>Policy Proposal Name: IPv4 countdown policy proposal
>
>- Set the date for termination of (IPv4) 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.
>
>
>Rationale:
>
> 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.
> (we have submitted the same proposal to APNIC on January 2007)
>
> 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 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.
>
>
> 5. Rationale for "A-date" & "T-date"
>
> 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.
>
>
> 6. Effect on RIR members
>
> RIR members are expected to concretely grasp the termination date
> of allocations and take actions within their organization to
> prepare for the event.
>
>
>Timetable for implementation: Immediate after all 5 RIRs ratified this policy.
>
>
>Esta comunicación es confidencial y puede
>contener información cuya divulgación esté
>restringida por la ley o en virtud de
>obligaciones de confidencialidad asumidas por
>acuerdos escritos. Si usted no es su
>destinatario, por favor advierta que cualquier
>divulgación, distribución o copia de esta
>comunicación le está estrictamente prohibida. Si
>usted recibió este mail por error, agradeceremos
>tenga a bien informar esa circunstancia al
>remitente mediante comunicación a la dirección
>de e-mail o al número telefónico : (5411)
>5170-0000, y le solicitamos asimismo que por
>favor proceda a borrarlo de su computadora. Por
>favor no copie ni use la información contenida
>en este mail para ningún propósito y no divulgue
>su contenido a ninguna otra persona.
>
>
>This communication is confidential and may
>contain information that is exempt from
>disclosure by law or pursuant to confidentiality
>obligations assumed by written agreement. If you
>are not the intended recipient, please note that
>any dissemination, distribution, or copying of
>this communication is strictly prohibited. If
>you receive this e-mail in error, please notify
>the sender immediately at the electronic mail
>address or phone number : (5411) 5170-0000 and
>delete the information from your computer.
>Please do not copy or use it for any purpose nor
>disclose its contents to any other person.
>
>
>
>_______________________________________________
>Politicas mailing list
>Politicas at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/politicas
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.412 / Virus Database: 268.18.3/696 - Release Date: 21/02/2007
More information about the Politicas
mailing list