[address-policy-wg] [arano at inetcore.com: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal]
- Next message (by thread): [address-policy-wg] [arano at inetcore.com: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gert Doering
gert at space.net
Mon Feb 5 09:05:19 CET 2007
Hi, this is a policy currently discussed in the APNIC region. I haven't formed an opinion of my own on this yet, but I think it might be useful to be aware of it. Gert Doering, APWG Chair ----- Forwarded message from Takashi Arano <arano at inetcore.com> ----- X-IronPort-SBRS: 3.5 X-Greylist: delayed 1099 seconds by postgrey-1.21 at kombu.apnic.net; Tue, 30 Jan 2007 20:45:27 EST X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2 Date: Tue, 30 Jan 2007 19:26:35 +0900 To: global-v6 at lists.apnic.net From: Takashi Arano <arano at inetcore.com> X-AP-Spam-Status: No, hits=0 required=6 X-AP-Spam-Status: No, hits=0 required=6 X-AP-Spam-Score: 0 (notspam) X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) X-Mailman-Approved-At: Wed, 31 Jan 2007 08:40:22 +1000 Subject: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal X-BeenThere: global-v6 at lists.apnic.net X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussion of new global IPv6 policy development <global-v6.lists.apnic.net> X-AP-Lists: Discussion of new global IPv6 policy development <global-v6.lists.apnic.net> List-Unsubscribe: <http://mailman.apnic.net/mailman/listinfo/global-v6>, <mailto:global-v6-request at lists.apnic.net?subject=unsubscribe> List-Archive: <http://www.apnic.net/mailing-lists/global-v6> List-Post: <mailto:global-v6 at lists.apnic.net> List-Help: <mailto:global-v6-request at lists.apnic.net?subject=help> List-Subscribe: <http://mailman.apnic.net/mailman/listinfo/global-v6>, <mailto:global-v6-request at lists.apnic.net?subject=subscribe> Errors-To: global-v6-bounces at lists.apnic.net All, Hello. I will forward our proposal to this mailing list just FYI. It is not an IPv6 policy, though. Regards, Takashi Arano >X-Original-To: arano at inetcore.com >Delivered-To: arano at inetcore.com >From: "Kenny Huang" <huangk at alum.sinica.edu> >To: <sig-policy at apnic.net> >Date: Tue, 30 Jan 2007 15:51:34 +0800 >X-Mailer: Microsoft Office Outlook, Build 11.0.6353 >Thread-Index: AcdEKKt/vRhEhwUHSvaQIKaDUzp1lAAGqTXQ >X-AP-Spam-Status: No, hits=0 required=6 >X-AP-Spam-Status: No, hits=0 required=6 >X-AP-Spam-Score: 0 (notspam) >X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) >Cc: >Subject: [sig-policy] prop-046: IPv4 countdown policy proposal >X-BeenThere: sig-policy at lists.apnic.net >X-Mailman-Version: 2.1.4 >List-Id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net> >X-AP-Lists: APNIC SIG on resource management policy<sig-policy.lists.apnic.net> >List-Unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request at lists.apnic.net?subject=unsubscribe> >List-Archive: <http://www.apnic.net/mailing-lists/sig-policy> >List-Post: <mailto:sig-policy at lists.apnic.net> >List-Help: <mailto:sig-policy-request at lists.apnic.net?subject=help> >List-Subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request at lists.apnic.net?subject=subscribe> >Sender: sig-policy-bounces at lists.apnic.net > > > >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.sinica.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.apnic.net >http://mailman.apnic.net/mailman/listinfo/sig-policy _______________________________________________ global-v6 mailing list global-v6 at lists.apnic.net http://mailman.apnic.net/mailman/listinfo/global-v6 ----- End forwarded message ----- Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
- Next message (by thread): [address-policy-wg] [arano at inetcore.com: [GLOBAL-V6] Fwd: [sig-policy] prop-046: IPv4 countdown policy proposal]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]