sig-policy August 2012

sig-policy@lists.apnic.net

19 participants
14 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

Monthly List Reminder
by noreply＠apnic.net 31 Aug '12

31 Aug '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

New Version of prop-103: A Final IP Address Policy Proposal
by Andy Linton 30 Aug '12

30 Aug '12

Dear SIG members Version 002 of the proposal "prop-103: A Final IP Address Policy Proposal" has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 34 in Phnom Penh, Cambodia on 30 August 2012. Information about this version and version 001 is available from: http://www.apnic.net/policy/**proposals/prop-103<http://www.apnic.net/policy/proposals/prop-103> 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-103-v002: A Final IP Address Policy Proposal ------------------------------**------------------------- Author: Randy Bush <randy(a)psg.com> 1. Introduction --------------- IPv4 is history, with no immediate need to add more policy. IPv6 is sufficiently plentiful that a lot of further policy making is probably not needed. So let us agree to make no more IP address policies or proposals except those which are clearly needed and for which can not be accomplished with current procedures. 2. Summary ---------- The APNIC community spends time and resources proposing, discussing, arguing, ... about IP address policies out of habit. The process is important in that it maintains an open policy process but often these proposals are not really relevant to actually coordinating the prudent and high quality operation of the internet. 3. Situation in other RIRs -------------------------- The community spends inordinate time and resources making endless policy proposals about miniscule issues and baroque corner cases. This is a waste of time and other resources. 4. Details ---------- IPv4 policy proposals should be carefully examined to ensure that they are really necessary and they address real needs that can not be accomplished with existing processes. Discussion of the problem should preceed proposals for new policy to address the problem. In general, the same should hold for IPv6, although it is realized that, as we learn more about IPv6 use and deployment, more policy development may be useful. 5. Pros/Cons ------------ Advantages: - We would not have to spend time discussing things of small consequence and which do not help the customer/user in any real way. Disadvantages: - It would impact the amateur careers of policy wannabes. This is a feature, not a bug. 6. Effect on APNIC ------------------ Saves money, time, and other resources such as administrative complexity created by more complex but useless policies. 7. Effect on NIRs ----------------- Saves money, time, and other resources such as administrative complexity created by more complex but useless policies.

5 7

IPv6 multihoming, PI address space and scaling
by Usman Latif 30 Aug '12

30 Aug '12

Hi, I have some queries around the IPv6 address assignment architecture: i. What is the currently accepted and agreed upon provider independant address assignment policy in use by RIRs to support multihoming for ISP end-customer organizations. E.g. I read that currently there is an IPv6 address pool reserved for provider-independant address assignment to ISP clients and the minimum agreed upon prefix-length is a /48 ii. If /48s are used for multihoming address assignment, are there any considerations given to how large it can scale to and how to control the expansion in internet route-table size? Are there any restrictions or alternatives enforced with regards to the resulting expansion? iii. Does it also imply that the ISPs are required to accept advertisements upto /48 from peer ISPs and to reject anything above /48 e.g. like /56 etc? Thanks, Usman

2 2

New version of prop-104: Clarifying demonstrated needs requirement in IPv4 transfer policy
by Andy Linton 29 Aug '12

29 Aug '12

Dear SIG members A new version the proposal "prop-104: Clarifying demonstrated needs requirement in IPv4 transfer policy" has been sent to the Policy SIG for review. Changes from previous version are: - Introduction was simplified to avoid misunderstanding. - Following text removed from "4. Details" due to difficulties in implementation. "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." Information about this version and earlier versions is available from: http://www.apnic.net/policy/proposals/prop-104 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-104-v002: 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. 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 2.3.2.13, "Submission of Assignment Information" and Section 2.3.2.18.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". This proposal does not intend to change the requirement for an address allocation or assignment from APNIC. 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. 7. Effect on NIRs ------------------ It is the NIR's choice as to whether to adopt this policy.

1 0

prop-104-v001: Clarifying demonstrated needs requirement in IPv4 transfer policy
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 2.3.2.13, "Submission of Assignment Information" and Section 2.3.2.18.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.

8 14

Re: [sig-policy] New Version of prop-103: A Final IP Address Policy Proposal
by Ren-Hung Hwang 29 Aug '12

29 Aug '12

I would support this proposal. Regarding Dean's thought: 4. Details ---------- IPv4 policy proposals should be carefully examined to ensure that they provide a solution to a well defined problem and they address real needs that can not be accomplished with existing processes. Discussion of the problem should precede proposals for new policy to address the problem. The following process describes how this discussion could be included within the current PDP. . A Problem Statement is posted to the Policy-SIG list outlining a problem or issue with the current APNIC policies. . The proposer leads conversation on the Policy-SIG list to develop possible solutions to this Problem Statement. >> I think the author(s) of the proposal should provide a initial/feasible solution as the start point for disussion. Ren-Hung . At this stage the APNIC Secretariat can comment if they consider that the Problem Statement can be covered within current policies. . When the proposer feels that they have a solution to their Problem Statement, they draft a policy and submit it in a similar fashion as occurs currently within the PDP. -- 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

2 1

prop-101 Returned to mailing list and Newversion posted
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." [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 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 [6], 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: ---------------- [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 _______________________________________________

8 21

Information Regarding Co-Chair Election
by Adam Gosling 26 Aug '12

26 Aug '12

Dear SIG members For the benefit of all, please read the following information regarding the Co-Chair Election at APNIC 34. Terms governing the election of Chairs and Co-Chairs are covered in the APNIC SIG Guidelines at Section 6 paragraph 3. In accordance with these procedures, the election will be the first item on the SIG agenda. That is, at 16:00 (UTC +7) on Tuesday, 28 August 2012 at APNIC 34 in Phnom Penh, Cambodia. Candidates will be invited to give a short speech prior to the voting. This is generally a short statement of a minute or two. Remember there is only 10 minutes assigned in the agenda for the election process. Voting will take place by a count of a show of hands in the room. Secretariat staff will be asked to assist in the count. Only candidates who are physically present at the SIG session will be included in the vote. A new clause was recently added to the SIG Guidelines. After the elections in Busan, Korea appointed three new Chairs who'd not had the chance to work together with the task of running the meeting. Following consultation with the community and the APNIC EC, it was agreed that newly appointed chairs should take up their role at the end of the meeting. Newly elected Chair/Co-Chairs will join the outgoing Chair(s) for the meeting, so that there is better continuity in the policy process oversight role. Outgoing Chairs are expected to follow proposals reaching consensus at the current OPM, through to the completion of the Policy Development Process. Please feel free to ask any questions should this be unclear. Regards Adam -- 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.

1 0

prop-099 IPv6 Reservation for Large Networks withdrawn
by Andy Linton 21 Aug '12

21 Aug '12

Dear colleagues, We've received confirmation from Xing Li today that he is withdrawing prop-099 IPv6 Reservation for Large Networks. He has indicated that due to changes in the IPv6 policy documents as a result of prop-102 which reached consensus at our last meeting that he feels that there is now no need for this proposal. We'd like to thank everyone for the constructive way in which this has been dealt with. It's great to see our community working well together in this way. Most of you will have seen this announcement to apnic-talk and apnic-announce which covers the changes. Regards, Andy, Masato, Skeeve ---------- Forwarded message ---------- From: APNIC Secretariat <secretariat(a)apnic.net> Date: Mon, Aug 20, 2012 at 11:00 AM Subject: [apnic-talk] [Apnic-announce] Policy proposal implemented To: apnic-announce(a)lists.apnic.net _______________________________________________________________________ Implementation of prop-102 _______________________________________________________________________ APNIC today published amendments to two documents related to the implementation of the following policy proposal, which reached consensus in February 2012 during APNIC 33 in New Delhi, India. The proposal implemented is: prop-102: Sparse allocation guidelines for IPv6 resource allocations This proposal requires the details of any sparse allocation algorithm used by APNIC to allocate IPv6 resources be published on the website, and any revisions should be handled in line with the procedures contained within APNIC-112. Updated documents ----------------- The policy change required edits to two documents. The comment period for the draft documents incorporating these policies ended on 19 August 2012. The following updated documents are now officially active: - IPv6 address allocation and assignment policy http://www.apnic.net/policy/ipv6-address-policy - APNIC guidelines for IPv6 allocation and assignment requests http://www.apnic.net/criteria/ipv6-guidelines For more information on the history of this policy proposal, see: http://www.apnic.net/policy/proposals/prop-102 Regards ________________________________________________________________________ Adam Gosling Senior Policy Specialist email: adam(a)apnic.net APNIC sip:adam@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary. _______________________________________________ Apnic-announce mailing list Apnic-announce(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce _______________________________________________ apnic-talk mailing list apnic-talk(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy August 2012