Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
by Mark Tinka 21 Sep '12
by Mark Tinka 21 Sep '12
21 Sep '12
On Sunday, September 18, 2011 01:43:13 AM Owen DeLong wrote: > Multiple prefix sizes, address fragmentation, etc. > Admittedly, it's a small complication, but, it is a > complication. > Further, it violates the principle of least surprise as > your organization scales and brings in new engineers. A good v6 address assignment policy for one's infrastructure is neither difficult to create nor maintain. No issues here since we started running v6 over 6 years ago. We know how v6 can make address management within an ISP's network brain-dead to maintain, but it's not reason enough to use /64's where we can comfortably use /112's and still not overly complicate our lives. > So did I. I was being a little tongue in cheek/snarky > with just presenting the math on the number of > addresses,... I know what you were getting at, with multiple v6 addresses on a single interface, e.t.c. > but the reality is that there may be some > cases where having multiple addresses for one end of a > point to point or the other (or both) may prove useful. > These are admittedly rare. Agree, but having run multiple networks with v6 over the last several years, we're yet to find with a reason that has required us to have multiple addresses on point-to-point links either between infrastructure, or between AS domains. Some things really are that simple :-). Obviously, I can't speak for anyone else's network, just ours. Mark.
prop-104-v001: Clarifying demonstrated needs requirement in IPv4 transfer policy
by Andy Linton 29 Aug '12
by Andy Linton 29 Aug '12
29 Aug '12
Dear SIG members The proposal "prop-104-v001: Clarifying demonstrated needs requirement in IPv4 transfer policy' has been sent to the Policy SIG for review. It will be discussed at the Policy SIG at APNIC 34 in Phnom Penh, Cambodia, Thursday, 30 August 2012. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is available from: https://www.apnic.net/policy/proposals/prop-104 Andy, Skeeve, Masato ---------------------------------------------------------------------- prop-104-v001: Clarifying demonstrated needs requirement in IPv4 transfer policy ---------------------------------------------------------------------- Authors: Shin SHIRAHATA <shin(a)clara.ad.jp> Norisuke HIRAI Akira NAKAGAWA 1. Introduction ---------------- This proposal defines the period to be approved of IPv4 transfers for recipients under demonstrated needs, in addition to current IPv4 address policy for allocation/assignment from APNIC. 2. Summary of the current problem ---------------------------------- The current APNIC transfer policy has a requirement for demonstrate a need for transferred IPv4 addresses. The period of demonstrated needs under the current operational practice is 12 months based on the definition in Section 3.2, "Criteria for subsequent LIR delegations" in the "Policies for IPv4 address space management in the Asia Pacific region", "Based on these factors, APNIC and NIRs will delegate address space to meet the LIR's estimated needs for a period up to one year up to the maximum allowed delegation under Section 3." and this period was defined before the exhaustion. On the other hand, ARIN allows transfers based on demonstrated needs up to 24 months. This leads to difference in conditions of the transfer between LIRs in the APNIC region and the ARIN region. Furthermore, 12 months is also too short for transfers within the APNIC region considering many xSPs plan their service and their addressing requirements beyond one year. 3. Situation in other RIRs --------------------------- ARIN has a requirement for the period to be approved of IPv4 transfers for recipients under demonstrated needs, up to 24 months. LACNIC has a policy that defines to evaluate for 12 months needs. RIPE NCC has 3 months requirement at this time, and the policy proposal that extend to 24 months, is under discussion. AfriNIC: AfriNIC currently does not have an IPv4 address transfers policy. ARIN: ARIN policy has a clear period for justification for IPv4 address transfers, and the period is 24 months. "Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources in the amount which they can justify under current ARIN policies showing how the addresses will be utilized within 24 months." See Section 8.3, "Transfers to Specified Recipients" in the "ARIN Number Resource Policy Manual": https://www.arin.net/policy/nrpm.html#eight3 This change was proposed by "DRAFT POLICY ARIN-2012-1: CLARIFYING REQUIREMENTS FOR IPV4 TRANSFERS". https://www.arin.net/policy/proposals/2012_1.html LACNIC: LACNIC policy defines to evaluate for 12 months needs for the recipient of the IPv4 address transfer. However, the transfer will only be activate once LACNIC's address pool runs out. (expect for the reserved space) See Section 18.104.22.168, "Submission of Assignment Information" and Section 22.214.171.124.2, "Transfer of IPv4 Blocks within the LACNIC Region" in the LACNIC Policy Manual (v1.9): http://lacnic.net/en/politicas/manual3.html RIPE: In the RIPE region, the period of needs approved for IPv4 address transfers will be based on the definition of the current allocation policy, which is 3 months. Currently, there is no policy which defines the period of needs based justification, specifically for IPv4 transfers, separate from allocation criteria. See Section 5.0, "Policies and Guidelines for Allocations" in the RIPE-553, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region:" http://www.ripe.net/ripe/docs/ripe-553/ However, there is a policy proposal under discussions which proposes to extend the period of the demonstrated needs in case of IPv4 transfers, up to 24 months. See 2012-03, "Intra-RIR Transfer Policy Proposal". http://www.ripe.net/ripe/policies/proposals/2012-03 4. Details ----------- This proposal clarifies the requirement on a period approved for the transferred resource to recipients of IPv4 transfers based on the demonstrated needs, and defines its period as "24 months". In case of Inter-RIR transfer, when there is a RIR which defines a period longer than 24 months in the future, the longer period adopted by the other RIR will be adopted. This proposal does not intend to change the requirement for an address allocation or assignment. 5. Pros/Cons ------------- Advantages: - Extended period will allow the larger block size to match a longer term needs of the requester. It will help to reduce an IPv4 address block fragmentation caused by transfer. - APNIC member can apply for IPv4 address transfer as a receiver on the same condition of demonstrate a need in other RIR in case of Inter-RIR transfer. At this time, ARIN is the only RIR that adopts Inter-RIR policy in place other than APNIC. Thus, it places APNIC policy in line with ARIN on the transfer conditions. - It will allow the block size to more closely match the block size available for transfer from source - It will reduce the risk of underground IPv4 address transfers, which do not get registered in APNIC database. There is a possibility that the recipients could not obtain justification for enough IPv4 address by the current period of demonstrated needs. Disadvantages: - None There may be people who feel 24 months does not lead to efficient utilization compared to 12 months. However, the objective of needs based justification is not to "cut the size of address space to be transfered"; it is to ensure that the transfered space will be utilized in realities. 24 months is a realistic period to estimate required address space for xSPs. 6. Effect on APNIC Members --------------------------- It will requires a recipients within the APNIC region must demonstrate the need for up to a 24 months use of IPv4 address block. If there is a RIR which defines a period longer than 24 months, the recipients may use the longer period to demonstrate its demand for an Inter-RIR transfer from that RIR. 7. Effect on NIRs ------------------ It is the NIR's choice as to whether to adopt this policy.
prop-101 Returned to mailing list and Newversion posted
by Andy Linton 29 Aug '12
by Andy Linton 29 Aug '12
29 Aug '12
Can we remind you all that a revised version of this proposal, available at http://www.apnic.net/policy/proposals/prop-101, is up for consideration at our next meeting. Of course, you should consider the whole proposal before deciding to support or oppose this proposal. The change from the previous version is the *removal* of the following clause: (e) The first Policy SIG meeting of 2014 (expected to be APNIC Meeting 35) will as an agenda item consider the observed rate of IPv6 portable assignments and potential 10-year forecasts of growth of portable assignments prepared by the APNIC Secretariat extrapolated on the observed data, and by consensus consider the question "Should the IPv6 portable assignment criteria revert to requiring multihoming?" -- This clause was a major point of debate in the debate at the last policy SIG meeting and while some people now are happy to support the proposal there has been no other discussion. We encourage you express your views on the list so that those who won't be able to attend the meeting in person have a chance to take part in the discussions. Andy, Masato, Skeeve ------------------------------------------------------------------------ prop-101-v004: Removing multihoming requirement for IPv6 portable assignments ------------------------------------------------------------------------ 1. Introduction ------------------- This a proposal to change the "IPv6 address allocation and assignment policy" to allow portable (that is, provider independent or PI) assignments of IPv6 address blocks to be made by APNIC to any organization with due justification and payment of standard fees, removing the current requirement that the requestor is or plans to be multihomed. 2. Summary of the current problem ----------------------------------------------- Current APNIC policy only permits portable assignments of IPv6 addresses to be made to an organization "if it is currently multihomed or plans to be multihomed within three months."  This requirement may unnecessarily complicate the implementation of IPv6 in some networks that are large or complex and use static assignment of addresses. It is therefore proposed to remove this requirement. IPv6 models tend to assume widespread assignment of registered IPv6 addresses to equipment throughout a network; so if provider assigned IPv6 addresses have been used in an organization's network, then any change of ISP would require a renumbering of the entire network. Such renumbering may be feasible if the network is small or dynamically assigned (for example, through use of prefix-delegation), but renumbering a large, statically-assigned network would be a significant operational challenge, and may not be practically possible. Although it is likely that many large networks would be multihomed, there will be technical or commercial reasons why some will not be; currently those networks cannot obtain portable IPv6 assignments from APNIC, and would need to use assignments from their ISPs, and accept the associated difficulties of future renumbering if they do so. This consideration and complexity could significantly delay IPv6 use by the affected organisations, which is not desirable. There is a risk that removing the multihoming requirement could cause a significant increase in demand for portable assignments, which in turn could cause the Internet routing tables to grow beyond manageable levels. It is not feasible to quickly generate any realistic model of likely demand increase which would arise from the proposed policy change, but it is argued that any such increase would only be of a scale to produce a manageable impact on global routing, for reasons including: - Organizations would only be likely to seek portable addressing if they believed it were essential for their operations, as provider assigned IPv6 addressing would be likely to be offered automatically and at no additional cost with their Internet services from their ISP; - APNIC membership fees would be expected to naturally discourage unnecessary requests, as these would be a far greater cost than that for provider assigned addressing; - Many or most organizations that require portable addressing will be multihomed, so the demand increase caused by removing the multihomed requirement should be small; - Only a limited set of an ISP's products is likely to allow customers to use portable assignments if they are singly-homed. 3.Situation in other RIRs --------------------------------- APNIC is now the only RIR remaining with an absolute requirement for multihoming for portable address assignments. AfriNIC: The "Policy for IPv6 ProviderIndependent (PI) Assignment for End-Sites"  does not mention any requirement for multihoming; ARIN: Section 6.5.8 of the "ARIN Number Resource Policy Manual"  only identifies multihoming as one of several alternative criteria for direct IPv6 assignment to end-user organizations; LACNIC: There is no mention of multihoming anywhere in the IPv6 section (Section 4) of the current LACNIC Policy Manual (v1.8 - 07/12/2011) . RIPE: The latest version (RIPE-545 ) published in January 2012 of the "IPv6 Address Allocation and Assignment Policy" does not mention multihoming, removing the requirement that existed in previous versions of the document. 4.Details ------------ It is proposed that section 5.9.1 of APNIC's "IPv6 address allocation and assignment policy" (apnic-089-v010) is rewritten to remove the absolute multihoming requirement for portable assignments, and to incorporate the following conditions: A. Portable IPv6 assignments are to be made only to organizations that have either joined APNIC as members or have signed the non-member agreement, under the standard terms & conditions and paying the standard fees applicable for their respective category. B. An organization will be automatically eligible for a minimum IPv6 portable assignment if they have previously justified an IPv4 portable assignment from APNIC. C. Requests by organizations that have not previously received an IPv4 portable assignment will need to be accompanied by: (a) a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable - examples of suitable technical justifications may include (but are not limited to): (i) Demonstration that the relevant network is statically addressed and of a size or complexity that would make IPv6 renumbering operationally impractical within an acceptable business period, together with evidence that dynamic or multiple addressing options are either not available from the relevant ISP or are unsuitable for use by the organization; (ii) Demonstration that any future renumbering of the relevant network could potentially interfere with services of a critical medical or civic nature; (b) A detailed plan of intended usage of the proposed address block over at least the 12 months following allocation. D. The minimum IPv6 portable assignment to any organization is to be an address block of /48. A portable assignment of a larger block (that is, a block with a prefix mask less than /48) may be made: (a) If it is needed to ensure that the HD-ratio for the planned network assignments from the block remains below the applied HD-ratio threshold specified in Section 5.3.1 of the APNIC IPv6 policy , or; (b) If addressing is required for 2 or more of the organization's sites operating distinct and unconnected networks. Any requests for address blocks larger than the minimum size will need to be accompanied by a detailed plan of the intended usage of the proposed assignment over at least the following 12 months. E. In order to minimise routing table impacts: (a) Only one IPv6 address block is to be given to an organization upon an initial request for a portable assignment; subnets of this block may be assigned by the organization to its different sites if needed; (b) It is recommended that the APNIC Secretariat applies sparse allocation methodologies so that any subsequent requests from an organization for additional portable addressing would be accommodated where possible through a change of prefix mask of a previous assignment (for example, 2001:db8:1000::/48 -> ] 2001:db8:1000::/44), rather than through allocation of a new prefix. An additional prefix should only be allocated where it is not possible to simply change the prefix mask. (c) Any subsequent request for an additional portable assignment to an organization must be accompanied by information demonstrating: (i) Why an additional portable assignment is required, and why an assignment from from an ISP or other LIR cannot be used for this purpose instead; (ii) That the use of previous portable IPv6 allocations generated the minimum possible number of global routing announcements and the maximum aggregation of that block; (iii) How the additional assignment would be managed to minimise the growth of the global IPv6 routing table. (d) The APNIC Secretariat will produce reports of the number of portable IPv6 assignments requested, preferably as an automatically-generated daily graph of the number of cumulative IPv6 portable assignments published publically on the APNIC website, or else as regular (at a minimum, quarterly) reports sent to the sig-policy mailing list detailing the incremental assignments of new IPv6 portable assignments made since the last report, plus the cumulative total of IPv6 portable assignments. 5.Pros/Cons ----------------- Advantages: - This proposal would provide access to portable IPv6 addresses for all organizations with valid needs, removing a potential impediment to industry standard IPv6 addressing for large singly-homed networks - This change would align APNIC with the policies of all other RIRs on portable assignments Disadvantages: - There would be a risk of an unmanageably large increase in global IPv6 routing table size and APNIC workload if there were to be a substantial and widespread increase in demand for portable assignments arising from the removal of the multihoming requirement - But demand is expected to be limited by the requirements specified in section 4 for justifications and APNIC standard fees, as well as other industry factors such as the capability of Internet services to support portable addressing. 6.Effect on APNIC ------------------------ The impact of this proposal on the APNIC Secretariat would depend on the increase of demand for portable assignments. Even if demand is eventually large, it is unlikely that there will be an significant change in hostmaster workloads for a long time because of the slow rate of take up of IPv6, and so there should be sufficient time to identify and take steps to modify policies and processes if necessary to manage the increase. 7.Effect on NIRs ---------------------- This proposal specifically applies to portable assignments made by APNIC. It would be the choice of each NIR as to whether they would adopt a similar policy. References: ----------------  Section 5.9.1, IPv6 address allocation and assignment policy, http://www.apnic.net/policy/ipv6-address-policy#5.9  http://www.afrinic.net/docs/policies/AFPUB-2007-v6-001.htm  https://www.arin.net/policy/nrpm.html#six58  http://www.lacnic.net/en/politicas/manual5.html  http://www.ripe.net/ripe/docs/ripe-545 Section 5.3.1, IPv6 address allocation and assignment policy, http://www.apnic.net/policy/ipv6-address-policy#5.3 _______________________________________________
Monthly List Reminder
by noreply＠apnic.net 31 Jul '12
by noreply＠apnic.net 31 Jul '12
31 Jul '12
Dear Subscriber, This is the monthly reminder of subscription information for the sig-policy list, hosted at APNIC. For subscription information including how to un-subscribe go to http://mailman.apnic.net/mailman/listinfo/sig-policy Thank you for participating in this discussion. Kind Regards, List administrator
Re: [sig-policy] prop-103-v001: A Final IP Address Policy Proposal
by Andy Linton 23 Jul '12
by Andy Linton 23 Jul '12
23 Jul '12
I want to comment on the process of posting of Prop-103. There was debate between the Chair and Co-chairs about whether this proposal should proceed. I have decided to post the proposal based on the following. The key criteria from the APNIC SIG guidelines are: The Chair may decide that a proposal is not suitable for discussion at the forthcoming SIG session if: 1) The proposal is out of scope for the SIG 2) The proposal is insufficiently developed to be the basis for a useful discussion 3) The agenda has already been filled by topics of greater priority Item 1 +++++ The guidelines say: Dissolving a SIG It is not assumed that a SIG will continue to exist indefinitely. Each SIG should periodically review its charter to assess the SIG’s usefulness and relevance. Signs that a SIG may have outlived its purpose include: - Lack of discussion on the mailing lists for more than one year - Lack of response to calls for presentations at SIG sessions - Low attendance at SIG sessions A SIG may be dissolved if the members of the SIG decide that this is an appropriate course of action and this recommendation is approved by the AMM. Members of the SIG may make the decision to dissolve the SIG via the SIG mailing list or at SIG sessions. If a SIG is dissolved, all associated mailing lists will be closed for subscription, but the public archives will remain on the APNIC website. --- It's clear to me that this is a decision that only the SIG can take (with agreement from the AMM). This proposal effectively asks for that to happen. Note that the criteria are signs and not requirements and it's not the role of the Policy SIG chairs to decide what the membership of the SIG might think here. Item 2 +++++ There was debate among the chairs whether the met this criteria. I believe it asks us to look at the Policy SIG's processes and rationale for existence as the guidelines suggest. It seems to me that such a discussion may go two ways: a) the proposal gets rejected out of hand because everything is just fine the way it is b) the proposal provokes discussion and leads to an improvement in the way the Policy SIG operates Item 3 +++++ At this stage our agenda isn't so full that we need to reject this proposal.
Re: [sig-policy] Proposal 99
by Ren-Hung Hwang 23 Jul '12
by Ren-Hung Hwang 23 Jul '12
23 Jul '12
>Message: 7 >Date: Fri, 20 Jul 2012 10:51:31 +1200 >From: Dean Pemberton <dean(a)deanpemberton.com> >Subject: Re: [sig-policy] Proposal 99 >To: Xing Li xing(a)cernet.edu.cn >Cc: "sig-policy(a)apnic.net SIG List" <sig-policy(a)apnic.net> >Message-ID: > <CACfPNNSQ-8oS3K0GmdR3EDLYrF18Cf=9LThcsvJCTLvUvUqPkg(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >Thank you for that reference. > >The example in your slides shows a situation where a /27 is required >over a multi year period but that under the current system this is >allocated as two /29s and a /28. Your presentation claims that this >causes problems with non-optimal network design. I am also interested to know why this example cannot be resolved by APNIC's current sparse allocation policy. Regards, Ren-Hung > >I am interested to hear from Sanjaya or the hostmasters if this would >actually be a problem in reality. > >If I were a member who came to APNIC with comprehensive documentation >showing a network rollout over 5 years which needed a /27, would this >be allocated under provisions in the following section of >apnic-089-v010 > >------ >5.2.3 Larger initial allocations >Initial allocations larger than /32 may be justified if: > >a) The organization provides comprehensive documentation of planned >IPv6 infrastructure which would require a larger allocation; >------ > >In other words, if I can show that I have a need for larger network, >can this be currently addressed without the need to change policy. > >Regards, >Dean -- Ren-Hung Hwang Research Distinguished Professor Dept. of Computer Science & Information Engineering National Chung Cheng Univ. Chia-Yi, Taiwan, 621 http://exodus.cs.ccu.edu.tw/~rhhwang WebOffice: http://mmc.elearning.ccu.edu.tw/home/rhhwang
Re: [sig-policy] Proposal 99
by ajwaninaresh＠gmail.com 21 Jul '12
by ajwaninaresh＠gmail.com 21 Jul '12
21 Jul '12
Thanks dear Rgds Sent from my BlackBerry® smartphone from Tata Indicom -----Original Message----- From: Aftab Siddiqui <aftab.siddiqui(a)gmail.com> Date: Sat, 21 Jul 2012 10:24:27 To: Naresh Ajwani<ajwaninaresh(a)gmail.com> Cc: Terence Zhang YH<zhangyinghao(a)cnnic.cn>; Ren-Hung Hwang<rhhwang(a)gmail.com>; SIG policy<sig-policy(a)apnic.net> Subject: Re: [sig-policy] Proposal 99 Naresh Sb, Actually Sanjaya mentioned the following. " can we use section 5.3.3's "except where separate disaggregated ranges are requested for multiple discreet networks" to allow APNIC hostmasters to hand out multiple prefixes to these very large networks?" IMHO prop-099 is just a Hostmaster's operational function and can be addressed without a policy on case to case basis. Kindly correct me if I'm wrong. Regards, Aftab A. Siddiqui > > Sorry Aftab, I have missed out this suggestion, wud u mind sharing the same please? > > Regards & best wishes, > Naresh Ajwani > On 20-Jul-2012, at 3:52 PM, Aftab Siddiqui <aftab.siddiqui(a)gmail.com> wrote: > > Hi Terence, > >> >> >> In the above example, sparse allocation tries to ensure the 2*/32 are contiguous, >> but prop-099 tries to ensure the 2*/34 are contiguous. >> > > > I believe thats not the case because lets say if initially they got 2001:db8::/32 and they allocated /34 each for 4 pops > e.g. > 2001:db8::/34 > 2001:db8:4000::/34 > 2001:db8:8000::/34 > 2001:db8:c000::/34 > > right? > > Now for the subsequent allocation the prefix they will get can't make 2*/34 contiguous. So any POP is growing than they either have to renumber or use 2 discontiguous /34. Correct me if I misinterpret. > > Nevertheless, I don't support this proposal. And for the corner cases Sanjaya's suggestion is fine. > > Regards, > > Aftab A. Siddiqui > > > * sig-policy: APNIC SIG on resource management policy * > _______________________________________________ > sig-policy mailing list > sig-policy(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy > -- Regards, Aftab A. Siddiqui
Nominations for Policy SIG Co-Chair
by Adam Gosling 20 Jul '12
by Adam Gosling 20 Jul '12
20 Jul '12
APNIC is seeking volunteers to serve as Co-Chair of the APNIC Policy SIG. The Co-Chair responsibilities are outlined here: http://conference.apnic.net/34/policy/#election For more detailed information about SIG operations and the role of Co-Chair, please see the SIG guidelines at: http://www.apnic.net/sigs/sig-guidelines.pdf If you are interested in this position, please nominate using the following form: http://conference.apnic.net/34/policy/nominate The nomination deadline is Monday, 20 August 2012. Nominees should include a short biography and description of their interest. The election will be held during the Policy SIG meeting at APNIC 34 Phnom Penh, Cambodia, on Tuesday, 28 August 2012. All SIG Chairs undertake this work on a voluntary basis. The APNIC Secretariat speaks on behalf of the community in saying we are very appreciative of the work done by the Chairs and Co-Chairs. Regards Adam Gosling -- Adam Gosling Senior Policy Specialist email: adam(a)apnic.net APNIC sip: adam(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary.
by Andy Linton 19 Jul '12
by Andy Linton 19 Jul '12
19 Jul '12
Dear SIG members Following considerable discussion at the APNIC 33 Policy SIG meeting, Version 2 of prop-099: IPv6 Reservation for Large Networks, did not reach consensus and was returned to the mailing list for further discussion. Since then there has been no further discussion of the proposal. The author has confirmed his intention to bring this proposal before the SIG at APNIC 34 and we would encourage those for, or against, the proposal to indicate their position so the SIG Chairs can take these views into consideration when gauging community consensus. Now is also a good time to raise any concerns or seek clarification on any matters prior to the meeting, so that our time there is well spent. Proposal details --------------------- This proposal extends the IPv6 request process to allow large ISPs to request multiple prefixes within a single, contiguous, reserved space. Proposal details including the full text of the proposal, history, and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-099 Regards Andy, Skeeve, and Masato ------------------------------------------------------------------------ prop-099-v002: IPv6 Reservation for Large Networks ------------------------------------------------------------------------ Authors: Xing Li <xing(a)cernet.edu.cn> Song Jiang, Xiaomin Zhou, Haijin Li 1. Introduction --------------- This proposal extends the IPv6 request process to allow large ISPs to request multiple prefixes within a single, contiguous, reserved space. Such a request must justify each prefix allocation in terms of specific demonstrated needs (in the same manner as a normal IPv6 allocation request); and must justify the total requested reservation in terms of documented architectural plans and projected space requirements for a period of up to 5 years. 2. Summary of the current problem --------------------------------- The current IPv6 address allocation and assignment policy (apnic-089-v010) states that 5.2.3 Larger initial allocations Initial allocations larger than /32 may be justified if: a. The organization provides comprehensive documentation of planned IPv6 infrastructure which would require a larger allocation; or b. The organization provides comprehensive documentation of all of the following: o its existing IPv4 infrastructure and customer base, o its intention to provide its existing IPv4 services via IPv6, and o its intention to move some of its existing IPv4 customers to IPv6 within two years. In either case, an allocation will be made which fulfills the calculated address requirement, in accordance with the HD-Ratio based utilization policy. Large networks are facing challenges deploying IPv6 networks. The current slow start policy is to allocate a /32 and then reduce the bit mask one bit at a time on subsequent allocations (i.e. /31, /30, /29 etc.). This approach is designed to maximise global routing aggregation, however, it causes fragmentation and complexity in the internal routing configuration of very large networks. This is particularly a problem in large networks with many POPs growing at different rates. Also, the IPv6 Address Allocation and Assignment Policy (Section 5.2.3 Larger initial allocations) does not take into account long-term future growth. A partial solution is available after prop-083 (Alternative criteria for subsequent IPv6 allocations)  where additional prefixes can be delegated to an organization??s disparate networks. However, this does not address the specific needs of organizations with very large non-disparate networks. These require a large address space over which they can design their network on a longer planning window (up to 5 years). 3. Situation in other RIRs -------------------------- No similar policy or policy proposal is available in the other RIRs. 4. Details of the proposal --------------------------- 4.1 Multiple prefix request Each IPv6 request will be able to specify any number of prefixes, although each must be separately justified according to specific demonstrated needs. Conventional allocation policies will be applied in assessment of each prefix requested. In particular, existing IPv4 infrastructure can be considered, and the current minimum allocation size will apply to each prefix. Each request may specify a proposed map of requested prefixes within the reserved space, based on expected growth forecasts for each prefix. As the allocated prefixes grow and become aggregatable, external routing should be aggregated whenever possible. 4.2 Subsequent allocations Subsequent allocations within the reserved space can be requested and made according to Section 5.3 of the IPv6 address allocation and assignment policy. Subsequent allocation requests can include extensions to previously allocated prefixes and/or new prefixes as needed. 4.3 Reservation request Each IPv6 request will be able to specify a proposed reservation for the entire network, to contain all allocated prefixes, and room for their future growth. The requested reservation may accommodate projected network growth for up to 5 years, based on supporting information, which may include long-term network plans such as: - Network architecture o Number of POPs and the growth rate of each based on past records and future projection o IPv6 address assignment plan that covers the initial and the end deployment within the planning window o List of equipment and devices to be deployed in the network and, - Environmental factors such as: o Market size and market share o Population and economic growth of service region 4.4 Reservation term Each reservation will be subject to expiry after 2 years, unless renewed by a request, which provides an update of network deployment and projections. No reservation will be expired or cancelled by APNIC without prior contact with the holder. 4.5 Registration In case of a multiple-prefix allocation, only the individual allocated prefixes will be registered in whois, or included in resource certificates; the reservation itself will not be registered, however it may be separately documented. 4.6 Suggested modifications of the current policy Suggest to add bullet 'c' in the current policy 5.2.3 Larger initial allocations Initial allocations larger than /32 may be justified if: a. The organization provides comprehensive documentation of planned IPv6 infrastructure which would require a larger allocation; or b. The organization provides comprehensive documentation of all of the following: o its existing IPv4 infrastructure and customer base, o its intention to provide its existing IPv4 services via IPv6, and o its intention to move some of its existing IPv4 customers to IPv6 within two years; or c. The organization provides comprehensive documentation of long term (up to 5 years) IPv6 infrastructure which would require a larger allocation: o Larger initial allocation will be via a multiple-prefix request, conventional allocation policies will be applied in assessment of each prefix requested, subsequent allocation requests can include extensions to previously allocated prefixes and/or new prefixes as needed; o Each IPv6 request will be able to specify a proposed reservation for the entire network, to contain all allocated prefixes, and room for their future growth; o In case of a multiple-prefix allocation, only the individual allocated prefixes will be registered in whois, or included in resource certificates; the reservation itself will not be registered, however it may be separately documented. In either case, an allocation will be made which fulfills the calculated address requirement, in accordance with the HD-Ratio based utilization policy. 5. Advantages and disadvantages of the proposal ------------------------------------------------ Advantages: - This proposal enables large networks to make long-term network plans and reduce internal routing complexities. - The reserved space is aggregated, and can be globally routed as a single prefix once the space is fully allocated. - The proposal allows long-term growth forecasts to be taken into account in the allocation process, without making allocation commitments based on those forecasts Disadvantages: - Initial allocation from the reserved space could be made in multiple disaggregated prefixes that have to be announced separately on the global routing table. However, as more allocations are made, the announcement could eventually converge to a smaller number of prefixes, or even to a single prefix. - Additional work for APNIC Secretariat to manage the request process, and regular renewals of reservations. The APNIC EC may want to look at the cost implication, which is out of scope of this policy proposal. 6. Effect on APNIC Members --------------------------- APNIC account holders with large networks will be able to submit their long-term network plan and receive IPv6 allocations in stages according to that plan. 7. Effect on NIRs ----------------- The proposal allows NIRs to choose when to adopt this policy for their Members.
Final editorial comments on draft documents
by Adam Gosling 19 Jul '12
by Adam Gosling 19 Jul '12
19 Jul '12
_______________________________________________________________________ Final editorial comments on draft documents _______________________________________________________________________ APNIC seeks final editorial comments on the following draft documents: - IPv6 address allocation and assignment policy - APNIC guidelines for IPv6 allocation and assignment requests These documents are updated to reflect the upcoming implementation of prop-102: Sparse allocation guidelines for IPv6 resource allocations. This proposal completed the Policy Development Process on 24 May 2012. Details and history of prop-102 are available at the following URL: http://www.apnic.net/policy/proposals/prop-102 Nature of the document review ----------------------------- This is an editorial review only. Consensus has already been reached on the policy issue which is to be implemented. Therefore, during the comment period, interested parties may: * Object to the draft document on the grounds that it does not properly reflect the consensus decision reached in the Policy Review Process * Suggest improvements to any aspect of the document * Request that an additional call for comment be made to allow more consideration of substantial revisions To view the document drafts, please see: http://www.apnic.net/community/policy/draft Deadline for comments --------------------- Your comments are requested by 19 August 2012 prior to immediate implementation. Please send your comments to: policy(a)apnic.net -- Adam Gosling Senior Policy Specialist email: adam(a)apnic.net APNIC sip: adam(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary.