sig-policy February 2012

sig-policy@lists.apnic.net

22 participants
15 discussions

Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
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.

8 17

Re: [sig-policy] prop-102-v002: Sparse allocation guidelines for IPv6 resource allocations
by Aftab Siddiqui 01 Mar '12

01 Mar '12

Hi Izumi, > Our understanding of sparse allocation is it's an operational decision > APNIC/RIR makes to help in aggregation and it shouldn't be forced. > > > So, it means operational guidlines can not be ameded by policy? [Just for my understanding] or is it just JPNIC stance. Regards, Aftab A. Siddiqui

4 4

prop-102-v002: Sparse allocation guidelines for IPv6 resource allocations
by Andy Linton 01 Mar '12

01 Mar '12

Dear SIG members Version 002 of the proposal "prop-101: Sparse allocation guidelines for IPv6 resource allocations" has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 33 in New Delhi, India, on 1 March 2012. Information about this and other policy proposals is available from: http://www.apnic.net/policy/proposals This new version of the proposal reflects feedback from the community received on the Policy SIG mailing list: - Ren-Hung Hwang added as a co-author - Requires APNIC to publish the Sparse allocation algorithm as a numbered document - Removes the objective to ensure requesters can access space sufficient for a 5 year growth program You are encouraged you to express your views on the proposal: - Do you support or oppose 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? Regards, Andy, Skeeve, and Masato ---------------------------------------------------------------------- prop-102-v002: Sparse allocation guidelines for IPv6 resource allocations ---------------------------------------------------------------------- Author: Dean Pemberton <dean(a)deanpemberton.com> Co-authors: Ren-Hung Hwang <rhhwang(a)gmail.com> 1. Introduction ---------------- This proposal formalises the current use of a sparse allocation strategy when allocating IPv6 resources from the APNIC free pool. The proposal also requires that the allocation algorithm must be published on the website, and any revisions should go through a discussion period to receive feedback. 2. Summary of the current problem ---------------------------------- Large networks and economies are requesting blocks of IPv6 space larger than the current allocation models allow. At present the allocation strategies look at a timeline on the order of 1-2 years. Organisations are now having to look to a 5-10 year time-frame when deploying large IPv6 networks. They are understandably concerned about their ability to secure access to 5-10 years of aggregatable address space if they are only allocated on 1-2 year needs basis. We have seen requests in proposals such as prop-98, prop-99 and prop-100, which seek to find ways to allow for larger allocations or reserve an amount of space for future organisational use. All of these proposals seek to make large changes to the way that IPv6 addresses are allocated by APNIC in order to address these legitimate concerns. It would seem however that there is an alternative solution which would only require a small change to current operating procedure. At present the APNIC operating procedure is for hostmasters to use a method of sparse-allocation when allocating IPv6 addresses out of the APNIC free pool. The sparse-allocation allows for allocations to be given from a larger pool in such a way that members can request neighbouring allocations at a later date and aggregate these together in to a larger routable allocation. While this has been APNIC operating procedure for some time, it is not subject to oversight by any particular APNIC policy. As such the exact algorithm used as well as the parameters around this sparse-allocation algorithm are not open to member input or adjustment through the policy development process. While members may surmise that a neighbouring allocation may be waiting for them should they need it, this is not guarenteed and therefore can not be used as part of the members future planning process. 3. Situation in other RIRs --------------------------- Unknown at this point. 4. Details ----------- This proposal seeks to make the following additions/changes to APNIC policy 1. APNIC should the use sparse allocation when allocating IPv6 resources from APNIC address pools 2. APNIC must publish the details of the sparse allocation framework on the APNIC website as a numbered document. Changes to this document should be handled as per APNIC-112 "APNIC document editorial policy". 5. Pros/Cons ------------- Advantages: - APNIC Members will have surety that the current sparse allocation mechanism will continue to be used. - Through the use of sparse allocation, APNIC Members are able to ensure that they will receive aggregatable blocks within a longer planning window. They can use this surety in their internal network planning processes. Disadvantages: - The hostmasters would be required to document and publish the sparse allocation mechanism. This may have an increased workload requirement. It is not anticipated that this increase would be significant as changes to the algorithm are not expected to occur frequently. 6. Effect on APNIC Members -------------------------- APNIC members would be able to see the published details of the sparse allocation policy used by APNIC to allocate IPv6 resources from its address pool. APNIC members would apply for address space much like they do today and an allocation would be made under the same rules as apnic-089-v010. The only different would be that if the member can show a growth estimate for up to 5 years, APNIC will allocate their resources from a sparse allocation to accommodate this growth and future resource requests. 7. Effect on NIRs ------------------ The policy would apply when NIRs request address space from APNIC The proposal allows NIRs to choose when to adopt this policy for their Members.

6 7

Re: [sig-policy] prop-101-v001: Removing multihoming requirement for IPv6 portable assignments
by David Woodgate 01 Mar '12

01 Mar '12

Stephan, Thanks again for your comments. The only reason I included this clause was to attempt to prevent portable assignments made by APNIC being unofficially redelegated (and in an unregistered way) by the receiving organizations, making them unintended LIRs. If this is considered by the SIG community to be an unlikely risk, or is already prevented by other existing policies, then I would be very happy to drop that clause. (Again, other opinions from the list would be welcomed.) With best regards, David Sent from my iPhone On 07/02/2012, at 10:16 AM, Stephan Millet <stephan.millet(a)gmail.com> wrote: > > I could see your point; what would you (or anyone else on the list) > think about the following wording? > > 4 F. An organization must only use portable assignments made under > this policy to address its own networks and potentially the > networks of affiliates > such as majority-owned subsidiaries, joint-ventures, > or, where the organization is a > government agency, associated government departments. > An organization must > not use portable assignments to address the networks or sites of > customers or other non-affiliated organizations. > > [SM] The more I think about specific clause, this the more I > question why it should matter and if it is even necessary as part of > this policy. Would there not be existing policy that would support > this particular principal ? I would personally like to see the > clause removed and allow existing policy (if any exists) to take > precedence. >

3 4

Monthly List Reminder
by noreply＠apnic.net 29 Feb '12

29 Feb '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

1 0

prop-101-v002: Removing multihoming , requirement for IPv6 portable assignments
by Andy Linton 28 Feb '12

28 Feb '12

Dear SIG members Version 002 of the proposal "prop-101: Removing multihoming requirement for IPv6 portable assignments" has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 33 in New Delhi, India, on 1 March 2012. Information about this and other policy proposals is available from: http://www.apnic.net/policy/proposals This new version of the proposal reflects feedback from the community received on the Policy SIG mailing list: - Section 4D has been altered to reference the Applied HD-Ratio Threshold specified in section 5.3.1 of the APNIC IPv6 policy as the basis for the allocation of portable assignments larger than /48. - Section 4F has been deleted, it having been suggested that this clause was unnecessary. You are encouraged you to express your views on the proposal: - Do you support or oppose 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? Regards, Andy, Skeeve, and Masato ------------------------------------------------------------------------ prop-101-v001: Removing multihoming requirement for IPv6 portable assignments ------------------------------------------------------------------------ Author: David Woodgate <dwoodgate5(a)gmail.com> 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." [1] 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" [2] does not mention any requirement for multihoming; ARIN: Section 6.5.8 of the "ARIN Number Resource Policy Manual" [3] 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) [4]. RIPE: The latest version (RIPE-545 [5]) 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 eligible for a portable assignment if they have previously justified an IPv4 portable assignment from APNIC. C. A request for an IPv6 portable assignment will need to be accompanied by a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. 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: (i) 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 [6], or; (ii) If addressing is required for 2 or more of the organization's sites operating distinct and unconnected networks. 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. 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. 8. References: --------------- [1] Section 5.9.1, IPv6 address allocation and assignment policy, http://www.apnic.net/policy/ipv6-address-policy#5.9 [2] http://www.afrinic.net/docs/policies/AFPUB-2007-v6-001.htm [3] https://www.arin.net/policy/nrpm.html#six58 [4] http://www.lacnic.net/en/politicas/manual5.html [5] http://www.ripe.net/ripe/docs/ripe-545 [6] Section 5.3.1, IPv6 address allocation and assignment policy, http://www.apnic.net/policy/ipv6-address-policy#5.3

7 8

Prop-098 Revision 2 (redlined version showing changes from version 1)
by Owen DeLong 28 Feb '12

28 Feb '12

The text below uses the following typographical conventions: Text in black is unchanged from the previous version. Text in blue is new text added in this version. Text in red strikeout is text removed from the previous version. Text in green is modified from the previous version. ________________________________________________________________________ prop-098-v002: Optimizing IPv6 allocation strategies (simplified) ________________________________________________________________________ Author: Owen DeLong <owen(a)delong.com> Version: 2 Date: 1 February 2012 1. Introduction --------------- This is a proposal to allow for more generous IPv6 allocations to service providers in order to promote better aggregation and easier optimization across their networks as they grow. 2. Summary of current problem ----------------------------- 2.1. Many LIRs are of the errant belief that they must fit their entire subscriber base within a single /32 and that they cannot easily obtain larger allocations from their RIR or NIR. 2.2. Many network outages have been caused by on-the-fly bit math errors and by aligning addressing blocks on nibble boundaries, at least where it makes sense, these errors can be reduced or eliminated. 2.3. Continued proliferation of the /32 mindset described in (1) above will eventually lead to significant unnecessary disaggregation and larger IPv6 routing tables. 2.4. The HD ratio, while a good mathematical model leaves much to be desired as an address administration tool. Using nibble-boundaries and rounding up actually yields similar results with simpler math. 3. Situation in other RIRs: --------------------------- ARIN: - Adopted, awaiting implementation by staff. RIPE: - As RIPE NCC seems to be currently issuing generous allocations, the author does not currently intend to submit a proposal to RIPE. However, the author may subsequently submit a policy to align RIPE allocations on nibble boundaries. LACNIC and AfriNIC: - Author is working on proposals for these regions. 4. Details of the proposal --------------------------- Amend IPv6 allocation policy as follows: 1. Add the following definitions: Nibble boundary: The point in a binary string where one hex digit ends and another begins. Provider Allocation Unit: The unit by which an LIRs utilization is measured. It is defined as the smallest reassignment unit used by the provider. 2. Redefine the following terms: End site: A single structure or service delivery address, or a single tenant within a multi-tenant structure. - The intent of this definition is to provide greater clarity and flexibility in allowing ISPs to meet the needs of their customers. Utilized: (i) A provider allocation unit shall be considered fully utilized when it is assigned to an end site or allocated to a customer LIR. (ii) The utilization percentage of a block at the LIR level is calculated as the fraction of total provider assignment units which have been assigned to end sites or allocated to customer LIRs. 3. Make all allocations and assignments on nibble boundaries. 3. Allow all requesters to round their requests up to the next nibble boundary. 4. Allow LIRs to request nibble-aligned blocks of any size greater than or equal to /36. 4.1 The default minimum is /32 unless the provider specifically asks for a /36. 4.2 The maximum allocation shall be the smallest nibble aligned block which allows the provider to accommodate 5 years of projected customer utilization based on assigning each customer end-site one provider allocation unit without exceeding a 75% utilization. If the provider has no allocation or assignment history, the provider may specify their provider allocation unit at the time of application. 4.3 An LIR which has subordinate LIRs may count the required allocation for each subordinate LIR as fully utilized blocks of PAUs in the calculation for 4.2. 5. Modify the subsequent allocation process. 5.1 To qualify for a subsequent allocation, an LIR must meet one of the following two criteria: - 75% or more utilization of their total address space, OR - One or more facilities which have reached a 90% utilization of the blocks allocated to those facilities and there are no available blocks of sufficient size in the providers current allocation(s) to expand those facilities and/or add new facilities. 5.2 When making a subsequent allocation, APNIC will use the following procedure: Whenever possible, expand one or more existing allocations to the next nibble as needed. When the above expansion cannot meet the need, make a new allocation large enough to encompass all existing allocations plus the need justified in this request. Such allocation shall not exceed a /16, but, a provider may receive as many /16s as are required to meet their justified needs. When this occurs, an LIR is encouraged to vacate their old allocations through attrition and return vacated space when feasible. The LIR is not required to vacate the space, but, it is encouraged. Once vacated, the space should be returned. Nothing in this section shall preclude a requestor's right to expand on nibble-boundary alignments if that is desired. 6. Allow LIRs with existing allocations to expand their allocation size if they are eligible for a larger block under the criteria in this proposal. Any LIR which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy based on the procedure and criteria in 5.2. 5. Advantages and disadvantages of the proposal ------------------------------------------------ Advantages: - Provides nibble-boundaries for direct allocations and for at least one level of network hierarchy within the LIR, reducing the potential for human factors errors. - Increases the potential for network aggregation by issuing very large blocks to ISPs. - Reduces the potential for harmful under-sized assignments to end users by removing any incentive to do so. - Simplifies the IPv6 allocation policy by removing logarithmic computations in favor of simple ratios. - Reduces the number of times any given LIR will need to return to APNIC for additional allocations. - Allows for better network planning and growth. Disadvantages: - May increase IPv6 address allocation. Probable impact over 50 years would reduce IPv6 free pool from 99.9995% to 99.62%. 6. Effect on APNIC Members --------------------------- APNIC LIR members will be able to obtain significantly larger blocks of IPv6 addresses and both receive and make their initial allocations and assignments on nibble boundaries to simplify human factors and network management while improving aggregation. 7. Effect on NIRs ----------------- This policy should not significantly impact NIRs. 8. References ------------- [1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy' http://www.apnic.net/policy/ipv6-address-policy#5.5

3 3

prop-099-v002: IPv6 Reservation for Large Networks
by Andy Linton 25 Feb '12

25 Feb '12

Dear SIG members, Version 2 of the proposal, 'IPv6 Reservation for Large Networks', has been sent to the Policy SIG for review.It will be presented at the Policy SIG at APNIC 33 in New Delhi, India, Thursday, 1 March 2012. Changes in version 2: - Summary of the current problem expanded - Specific recommendations for policy text added 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 and other policy proposals is available from: http://www.apnic.net/policy/proposals Andy, Skeeve, 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) [1] 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.

7 8

prop-101-v001: Removing multihoming requirement for IPv6 portable assignments
by Andy Linton 25 Feb '12

25 Feb '12

Dear SIG members The proposal "prop-101-v001: Removing multihoming requirement for IPv6 portable assignments" has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 33 in New Delhi, India, Thursday, 1 March 2012. The comment period on the mailing list is an important part of the policy development process. We encourage you to express your views on the proposal. Does this proposal solve a problem you are experiencing? David Woodgate is looking for a co-author to present this proposal to the APNIIC 33 Policy SIG as he is unable to attend. If you are interested please contact him directly. Information about this and other policy proposals is available from: http://www.apnic.net/policy/proposals Andy, Skeeve, Masato ------------------------------------------------------------------------ prop-101-v001: Removing multihoming requirement for IPv6 portable assignments ------------------------------------------------------------------------ Author: David Woodgate <dwoodgate5(a)gmail.com> 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." [1] 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" [2] does not mention any requirement for multihoming; ARIN: Section 6.5.8 of the "ARIN Number Resource Policy Manual" [3] 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) [4]. RIPE: The latest version (RIPE-545 [5]) 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 eligible for a portable assignment if they have previously justified an IPv4 portable assignment from APNIC. C. A request for an IPv6 portable assignment will need to be accompanied by a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. D. The minimum IPv6 portable assignment to any organization is to be an address block of /48. A portable assignment of a block larger than a /48 can be made if it can be demonstrated that more than 32,768 /64 subnets (or equivalent) are required within its network or if numbering is required for 2 or more of the organization's sites operating distinct and unconnected networks. 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. F. An organization must only use portable assignments made under this policy to address its own networks. An organization must not use portable assignments to address the networks or sites of other organizations. 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. 8. References: --------------- [1] Section 5.9.1, IPv6 address allocation and assignment policy, http://www.apnic.net/policy/ipv6-address-policy#5.9 [2] http://www.afrinic.net/docs/policies/AFPUB-2007-v6-001.htm [3] https://www.arin.net/policy/nrpm.html#six58 [4] http://www.lacnic.net/en/politicas/manual5.html [5] http://www.ripe.net/ripe/docs/ripe-545

3 2

prop-102-v001: Sparse allocation guidelines for IPv6 resource allocations
by Andy Linton 24 Feb '12

24 Feb '12

Dear SIG members The proposal "prop-102-v001: Sparse allocation guidelines for IPv6 resource allocations" has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 33 in New Delhi, India, Thursday, 1 March 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 and other policy proposals is available from: http://www.apnic.net/policy/proposals Andy, Skeeve, Masato ------------------------------------------------------------------------ prop-102-v001: Sparse allocation guidelines for IPv6 resource allocations ------------------------------------------------------------------------ Author: Dean Pemberton <dean(a)deanpemberton.com> Co-authors: None at present Co-authors welcome 1. Introduction ---------------- This proposal formalises the current use of a sparse allocation strategy when allocating IPv6 resources from the APNIC free pool. This also has the effect of bringing the algorithm and its parameters under the oversight of the APNIC policy development process. The proposal also seeks to give members some assurance that if they are able to show a growth plan for 5 years upon applying for an initial 2 year assignment, that subsequent assignments will be allocated from a sufficiently sized, sparsely allocated block. 2. Summary of the current problem ---------------------------------- Large networks and economies are requesting blocks of IPv6 space larger than the current allocation models allow. At present the allocation strategies look at a timeline on the order of 1-2 years. Organisations are now having to look to a 5-10 year time-frame when deploying large IPv6 networks. They are understandably concerned about their ability to secure access to 5-10 years of aggregatable address space if they are only allocated on 1-2 year needs basis. We have seen requests in proposals such as prop-98, prop-99 and prop-100, which seek to find ways to allow for larger allocations or reserve an amount of space for future organisational use. All of these proposals seek to make large changes to the way that IPv6 addresses are allocated by APNIC in order to address these legitimate concerns. It would seem however that there is an alternative solution which would only require a small change to current operating procedure. At present the APNIC operating procedure is for hostmasters to use a method of sparse-allocation when allocating IPv6 addresses out of the APNIC free pool. An in depth discussion of sparse-allocation, and indeed the implementation used by APNIC is beyond the scope of this proposal. Suffice to say however, that sparse-allocation allows for allocations to be given from a larger pool in such a way that members can request neighbouring allocations at a later date and aggregate these together in to a larger routable allocation. While this has been APNIC operating procedure for some time, it is not subject to oversight by any particular APNIC policy. As such the exact algorithm used as well as the parameters around this sparse-allocation algorithm are not open to member input or adjustment through the policy development process. While members may surmise that a neighbouring allocation may be waiting for them should they need it, this is not guarenteed and therefore can not be used as part of the members future planning process. 3. Situation in other RIRs --------------------------- Unknown at this point - Investigation under way 4. Details ----------- This proposal seeks to make the following additions/changes to APNIC policy 1. Mandate the use of sparse allocation when allocating IPv6 resources from APNIC address pools 2. Publish the details of the sparse allocation algorithm and ensure that it is able to be debated through the existing policy development framework. 3. Ensure that if a member can show a growth plan for the next 5 years that this amount is sparsely allocated when an allocation is made under existing apnic-089-v010 guidelines. 5. Pros/Cons ------------- Advantages: - APNIC Members are able to ensure that they will receive aggregatable blocks within a 5 year growth projection. They can use this surety in their internal network planning processes. - APNIC Members will have the surety that the current sparse allocation mechanism will continue to be used. - Rather than simply providing a member with an allocation of 5 years worth of space which may go unused due to imprecise planning. Under this proposal, the majority of the space remains in the APNIC free pool and can be reallocated after the 5 year sparse allocation window expires. Disadvantages: - It is possible that this proposal may require APNIC to keep a larger pool in reserve that previously. This could be modelled using information from the secretariat. 6. Effect on APNIC Members ------------------- APNIC members would be able to see the published details of the sparse allocation policy used by APNIC to allocate IPv6 resources from its address pool. APNIC members would apply for address space much like they do today and an allocation would be made under the same rules as apnic-089-v010. The only different would be that if the member can show a growth estimate for up to 5 years, APNIC will allocate their resources from a sparse allocation to accommodate this growth and future resource requests. 7. Effect on NIRs ------------------ The policy would apply when NIRs request address space from APNIC The proposal allows NIRs to choose when to adopt this policy for their Members.

5 5

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy February 2012