[LACNIC/Politicas] FW: [ppml] Policy Proposal: IPv4 countdownpolicy proposal
rgaglian at antel.net.uy
Mon Feb 26 14:00:55 BRT 2007
Este tipo de propuestas no debería venir desde el ASO quien coordina las
Más allá de eso, se ve que en estos movimientos se habla de reservar
bloques para "recursos estratégicos", pero en varias partes en donde al
adopción de tecnologías es más lenta (como varias partes de nuestra
región), deberíamos asegurarnos que cuando estas regiones vayan a buscar
recursos, los mismos existan.
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.
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
(*) 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
- 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.
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
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
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.
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
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
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
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.
It is likely that smooth allocations by RIRs/NIRs will be
hindered by rush of inquiries during the terminal phase of
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
Moreover, if the terminal date of allocations remains ambiguous,
it may leave end users behind to prepare for IPv6 ready network.
There will be the following benefits by implementing the policy
for IPv4 address exhaustion as proposed on this paper.
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.
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
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
- 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
(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
(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
(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
(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
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
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
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
More information about the Politicas