RE: [sig-policy] prop-046: IPv4 countdown policy proposal
At 09:21 07/02/12, Hannaford, Nick B wrote:
>I can see a couple of issues with this proposal
Thank you for kicking off the discussion!
>1) It brings forward the effective IPv4 runout date by up to 2 years.
>
>This has the risk of bringing forward a "last minute rush" on the
>remaining IPv4 addresses. While there are many ways that we could signal
>to industry players that the time to invest in IPv6 infrastructure is
>now, amplifying the levels of uncertainty in IPv4 and inciting a level
>of industry panic appears to be counter-productive.
OK, then I have two questions to you.
Do you think that the current policy and practices should be remaining
until the last allocation?
Our answer is NO. Please imagine a situation where the last piece of cakes
would be allocated and from the next day on any address requster
would be rejected. This might be very uncertain situation to ISPs.
One of our points is to announce the date to avoid this kind of confusion.
Then, the next question is what is your alternative proposal if you agree
with our point above. We absolutely welcome your counter proposal.
>2) It fails to address the issue of requirements for IPv4 addressing
>post registry run-out.
>
>Many players have long term requirements for IPv4 and are not in a
>position to suddenly switch to IPv6 any time soon.
I agree. This is why we are making the proposal. Since transition needs time,
the registries must let ISPs recognize well in advance of runout.
Note that IPv6 is very practical solution, but not only one to solve the runout
problem. Some ISPs could make plans to accomodate their address, ex.,
take out dialup pools and give them broadband service, etc.
Other ISPs might provide private address services to their customers.
These are totally up to ISPs. But in any cases, ISPs must be annouce in advance.
>The issue of APNIC's potential role in an IPv4 trading environment needs
>to be considered. Whilst there is some work being done on Certificates
>in APNIC, there appears to be no current or proposed mechanism to allow
>the trading of IPv4 addresses.
Trading would be possible. But IMHO, this is not a good idea.
I don't think there is a good reason for Internet-developed countries to
sell their addresses, their vested rights, to Internet-developing ones.
Regards,
Takashi Arano
>Trading will happen! Whilst APNIC is probably not the venue for such
>trading, it is well placed to certify the validate trades similar to the
>"Titles Office". The alternatives of an 'unofficial' black market
>registries appearing is simply untenable.
>
>I do not believe APNIC has really looked in terms of its operational
>profile, necessary tools, costs, etc to undertake such a role. I'm of
>the view that this is a pretty large agenda of new work for APNIC, and
>that time is running out especially if prop-046 becomes policy. We
>really should get APNIC to start looking at this role now.
>
>I would like to propose that APNIC conduct a formal study in the
>potential characteristics of trading and the role(s) that APNIC could
>play in an address trading environment. It would be good if this could
>be undertaken this year (2007). Does this proposal for APNIC to
>undertake a study require a policy proposal, or is there some other
>mechanism to allow this proposal to be adopted?
>
>
>Kind regards
>Nick Hannaford
>Telstra Corporation
>Nick.hannaford at telstra dot net
>
>-----Original Message-----
>From: sig-policy-bounces at lists dot apnic dot net
>[mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Kenny Huang
>Sent: Tuesday, 30 January 2007 6:52 PM
>To: sig-policy at apnic dot net
>Subject: [sig-policy] prop-046: IPv4 countdown policy proposal
>
>
>
>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 at alum dot sinica dot 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 at lists dot apnic dot net
>http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>* sig-policy: APNIC SIG on resource management policy *
>_______________________________________________
>sig-policy mailing list
>sig-policy at lists dot apnic dot net
>http://mailman.apnic.net/mailman/listinfo/sig-policy