sig-policy January 2009

sig-policy@lists.apnic.net

6 participants
15 discussions

Monthly List Reminder
by noreply＠apnic.net 31 Jan '09

31 Jan '09

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

solicitation for second co-chair position
by Randy Bush 27 Jan '09

27 Jan '09

Policy SIG members, The Policy SIG has traditionally had a chair and two co-chairs. So we have a vacant seat at this time. Hence, Jian Zhang (Policy SIG Co-chair) and I are now seeking a volunteer to serve as second Co-chair of the Policy SIG. The Policy SIG Co-Chair term is two years. The Co-Chair is a volunteer position whose responsibilities include: - assisting with chairing the Policy SIG session - working with the Chair and other Co-chair to develop the agenda - posting proposals and information about the Policy SIG to the Policy SIG mailing list - working with the Chair and other Co-chair to encourage and facilitate discussion on the mailing list and at the APNIC meeting For more information about the role of a SIG Co-Chair, please see the SIG guidelines at: http://www.apnic.net/sigs/sig-guidelines.pdf If you are interested in becoming a Policy SIG Co-chair, please include a short biography and description of your interest in an email to <sig(a)apnic.net>, and CC <sig-policy-chair(a)apnic.net>. If you have someone to recommend, please write to us as above. The deadline for receiving nominations is 25 February 2009. If there are any volunteers, there will be elections at the Policy SIG meeting at APNIC 27 in Manila, Philippines, 23-27 February 2009 to elect the second Policy SIG Co-chair. Candidates need to be present at the meeting to be eligible. Thank you. Regards, randy & jian

1 0

prop-070-v001: Maximum IPv4 allocation size
by Randy Bush 23 Jan '09

23 Jan '09

Dear SIG members The policy proposal 'Maximum IPv4 allocation size' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 27 in Manila, Philippines, 23-27 February 2009. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-070-v001.html 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? randy and jian ________________________________________________________________________ prop-070-v001: Maximum IPv4 allocation size ________________________________________________________________________ Authors: James Spenceley james(a)vocus.com.au Jonny Martin jonny(a)jonnynet.net Version: 1 Date: 23 January 2009 1. Introduction ---------------- The policy seeks to create a maximum APNIC allocation size. The proposal then seeks to gradually decrease the maximum allocation size based on the remaining number of /8s in the IANA free pool. 2. Summary of current problem ------------------------------ Currently, any APNIC account-holder can request and receive a single allocation that could greatly reduce the IANA free pool. In a worse case, it is possible that an APNIC account holder could request and receive a large portion of the final address space allocated to APNIC by IANA. (This is excluding the final /8 to be allocated to APNIC under the "Global policy for the allocation of the remaining IPv4 address space", which is in its final stages of the global policy process [1]). This situation does not promote fair allocation of the remaining address resources either globally or within the APNIC region. 3. Situation in other RIRs --------------------------- AfriNIC, ARIN, LACNIC and RIPE currently have no maximum allocation size. If this proposal is received well in the APNIC region, the authors are happy to work with other regions to propose this policy in other RIR policy forums. 4. Details of the proposal --------------------------- This is a proposal with two parts: 4.1 On implementation of the policy, the APNIC maximum IPv4 allocation size will be a single /8. 4.2 The maximum allocation size is reduced over time based on the size of the IANA free pool. The maximum allocation size would be reduced when the IANA free pool reaches the following thresholds: IANA free pool Maximum allocation 30 x /8s /8 (current) 25 x /8s /9 20 x /8s /12 15 x /8s /14 10 x /8s /16 5 x /8s /18 5. Advantages and disadvantages of the proposal ------------------------------------------------ 5.1 Advantages - Promotes broader allocation of IP resources by ensuring no single member requests a large portion of the remaining address space. - Provides smoother distribution of the remaining space across space across all APNIC members. - More evenly reduces the allocation size down to that proposed by prop-067 use of final /8 [2]. - Creates positive feedback to deploy IPv6 by reducing the size of allocation of IPv4. 5.2 Disadvantages - If only implemented by APNIC, it disadvantages APNIC and its members as other RIR will not be artificially limiting their allocation rate and will therefore receive a larger portion of the remaining address space. - It could create more work for APNIC account holders and the APNIC Secretariat as requests may be more frequent as a result of the reduced maximum allocation. 6. Effect on APNIC members --------------------------- This proposal potentially impacts all APNIC members who will require additional IPv4 allocations, in particular larger members who are more likely to require large allocations. 7. Effect on NIRs ------------------ The proposal impacts the NIRs in the same way as APNIC members. 8. References ------------- [1] prop-055: Global policy for the allocation of the remaining IPv4 address space http://www.apnic.net/policy/proposals/prop-055-v002.html [2] prop-067: final use of /8 http://www.apnic.net/policy/proposals/prop-067-v001.html -30-

1 0

prop-069-v001: Global policy proposal for the allocation of IPv4 blocks, to Regional Internet Registries
by Randy Bush 23 Jan '09

23 Jan '09

Dear SIG members A 'Global policy proposal for the allocation of IPv4 blocks to Regional Internet Registries' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 27 in Manila, Philippines, 23-27 February 2009. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-069-v001.html 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? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? randy and jian ________________________________________________________________________ prop-069-v001: Global policy proposal for the allocation of IPv4 blocks to Regional Internet Registries ________________________________________________________________________ Authors: Adiel A. Akplogan, AfriNIC Raul Echeberria, LACNIC Maemura Akinori, APNIC Geoff Huston, APNIC Axel Pawlik, RIPE NCC Ray Plzak, ARIN Oscar A. Robles-Garay, LACNIC Nigel Titley, RIPE NCC Paul Wilson, APNIC Note: This proposal was developed by a team consisting of persons from each of the 5 RIRs Version: 1 Date: 22 January 2009 1. Introduction ---------------- This document is a global policy proposal governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by the IANA to an RIR in accordance with this proposed policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. 2. Summary of current problem ------------------------------ With the depletion of the IANA free pool of IPv4 address space, the current policy regarding the allocation of IPv4 address space to the RIRs will become moot. The RIRs may, according to their individual policies and procedures, recover IPv4 address space. This policy provides a mechanism for the RIRs to retro allocate the recovered IPv4 address space to the IANA and provides the IANA the policy by which it can allocate it back to the RIRs on a needs basis. This policy creates a new global pool of IPv4 address space that can be allocated where it is needed on a global basis without a transfer of address space between the RIRs. 3. Situation in other RIRs ---------------------------- This proposal is being submitted in all RIR regions, with a view to becoming a global policy [1]. 4. Details of the proposal ---------------------------- This policy is to be implemented in two phases: - Phase I: Recovery of IPv4 address space - Phase II: Allocation of recovered IPv4 address space by the IANA 4.1 Phase I: Recovery of IPv4 address space Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool. 4.2 Phase II: Allocation of recovered IPv4 address space by the IANA Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 addresses space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) [2] is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 4.2.1 Allocation of IPv4 address space a. For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year. b. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described section 4.2.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 4.2.2 IPv4 address space allocation criteria A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period. 4.2.3 Initial allocation of IPv4 address space Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process. 4.3 Reporting a. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR. b. All allocated space is also to be recorded in this IANA- published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR. c. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated. d. The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website [3] and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. 4.4 Timetable for implementation This policy is to be implemented immediately upon ratification by the ICANN Board of Directors according to the global policy process described in the ASO MoU [4]. 5. Advantages and disadvantages of the proposal ------------------------------------------------- 5.1 Advantages - The policy provides a mechanism for the ongoing distribution of IPv4 address space. 5.2 Disadvantages - None identified. 6. Effect on APNIC members ---------------------------- This policy governs the allocation relationship between IANA and the RIRs and does not imply any change to allocation relationships between APNIC and its members. 7. Effect on NIRs ------------------- This policy governs the allocation relationship between IANA and the RIRs and does not imply any change to allocation relationships between APNIC and NIRs. 8. References ------------- [1] Section 5, ICANN Address Supporting Organization (ASO) MoU http://aso.icann.org/docs/aso-mou2004.html [2] Global Addressing Policy ASO-001-2 http://aso.icann.org/docs/aso-001-2.pdf [3] Internet Protocol v4 Address Space http://www.iana.org/assignments/ipv4-address-space [4] Attachment A: Global Policy Development Process, ASO MoU http://aso.icann.org/docs/aso-mou2004.html -30-

1 0

co-chair
by Randy Bush 22 Jan '09

22 Jan '09

jian and sam, my impression is that it would be good if we picked up the ball we dropped in christchurch and solicited for a co-chair. does that seem reasonable to you. randy

1 1

prop-068-v001: Inter-RIR transfer policy
by Randy Bush 20 Jan '09

20 Jan '09

Dear SIG members The policy proposal 'Inter-RIR transfer policy' has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 27 in Manila, Philippines, 23-27 February 2009. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-068-v001.html 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? randy and jian _______________________________________________________________________ prop-068-v001: Inter-RIR transfer policy ________________________________________________________________________ Author: Geoff Huston gih(a)apnic.net Version: 1 Date: 16 January 2009 1. Introduction ---------------- This is a proposal to allow the recognition and recording of address transfers between APNIC and other RIRs and between APNIC and NIRs. 2. Summary of current problem ------------------------------ prop-050, "IPv4 address transfers", proposes that APNIC recognise the transfer of IPv4 address resources between APNIC members. However, it does not address the following situations: - A transfer between an APNIC member and a member of another RIR - A transfer between an APNIC member and a member of an APNIC-recognised NIR 3. Situation in other RIRs ---------------------------- No similar policy proposals have been adoped in other RIRs. 4. Details of the proposal ---------------------------- APNIC will recognise and register a transfer of IPv4 addresses in the following cases: 4.1 Transfer from APNIC member to another RIR or NIR member The following constraints apply to the disposer of the IPv4 address disposer (the "source entity"): - The source entity must be a current APNIC account holder. - The source entity must be the currently registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. - The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer. - In making any future IPv4 address resource requests to APNIC, for as long as IPv4 address resources are available from APNIC, following the expiration of this 24 month ineligibility period, the source will be required to document the reasons for the IPv4 address resource allocation. The following constraints apply to IPv4 address block being transferred: - Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. - The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder. APNIC will require the details of the receiving entity of the transfer, and will confirm that the receiving entity and the IPv4 address block meets the eligibility criteria established by the RIR or NIR nominated by the receiving entity prior to approval of registration of the transfer. The transfer process: 1. APNIC will update the registration records relating to the transferred addresses. 2. APNIC will adjust the source's address holdings as of the date of transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as a return of address holdings to APNIC as of that date. 3. The following transfer details will be published by APNIC in a public log of resource transfers: - Source - Recipient - Recipient RIR or NIR - Address resources - Date of transfer Transfer fees: APNIC may charge the source entity a service fee on the transfer transaction. The transfer service fee may vary according to the total size of the address block being transferred. The transfer fee schedule shall be set initially by the APNIC Executive Council upon adoption of this policy. The transfer fee schedule will be included as part of any future review of APNIC fees and charges. 4.2 Transfer from member of another RIR or NIR to APNIC member The following constraints apply to the recipient of the IPv4 address disposer (the "recipient entity"): - The recipient entity must be a current APNIC account holder. - The recipient entity of the transferred resources will be subject to current APNIC policies. In particular, in any subsequent APNIC IPv4 address allocation request, the recipient will be required to account for all IPv4 address space held, including all transferred resources. - APNIC fees payable by the recipient will be assessed on the basis of all resources held. The following constraints apply to IPv4 address block being transferred: - Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. APNIC will require the details of the source entity of the transfer, and will confirm that the source entity and the IPv4 address block meets the eligibility criteria established by the RIR or NIR that holds the address registration prior to approval of registration of the transfer. The transfer process: 1. APNIC will update the registration records relating to the transferred addresses. 2. APNIC will adjust the recipient's address holdings to include the transferred addresses as of the date of the transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as an allocation or assignment of address holdings to the recipient as of that date. To preserve aggregation capabilities the transfer recipient may notify APNIC that the transferred address may be returned to the unallocated APNIC address pool, and a different address of the same size may be registered to the recipient of the transfer. This option would be available to the recipient of the transferred address, at the discretion of the recipient, and subject to availablility of an alternate address block from APNIC 3. The following transfer details will be published by APNIC in a public log of resource transfers: - Source - Source RIR or NIR - Recipient - Address resources - Date of transfer Transfer fees: APNIC may charge the recipient entity a service fee on the transfer transaction. The transfer service fee may vary according to the total size of the address block being transferred. The transfer fee schedule shall be set initially by the APNIC Executive Council upon adoption of this policy. The transfer fee schedule will be included as part of any future review of APNIC fees and charges. 5. Advantages and disadvantages of the proposal ------------------------------------------------- 5.1 Advantages This proposal, by acknowledging the existence of address transfers and registering the outcomes, would ensure that the APNIC address registry continues to maintain accurate data about resources and resource holders. The proposal also ensures that those parties who currently rely on the accuracy of this registration information can continue to rely on the currency and accuracy of this information in good faith. In particular, it would: - Ensure that the APNIC registry continues to reflect the current actual status of IPv4 resource holdings by APNIC account holders. - Mitigate the risks to the integrity of the network, and its routing and addressing infrastructure in particular, associated with the unregistered transfers of IPv4 addresses. - Provide a stronger incentive for unused IPv4 address space to return to active use, helping to satisfy residual demand for IPv4 address space across the IPv6 transition. 5.2 Disadvantages (and responses) 5.2.1 Altering the traditional concepts of IP addresses This proposal has the potential to alter a number of traditional preconceptions relating to addresses and their value, including challenging the concept that addresses are not in and of themselves assets and addresses do no in and of themselves have monetary value outside of the narrow constraints of use in networks for routing and end point identification. Changing these common percpetions about addresses and their use opens up the potential for a number of responses, including: - The loss of strong aggregation capability in the address space, with the consequent load being imposed on the routing system. - The significant shift away from a universal need-based address allocation model in the underlying policy framework. - The treatment of addresses as property with the associated legal ramifications in terms of corporate and contract law. - The imposition of taxes on addresses and their movement. - The potential for unfairness and inequities to be realized in terms of access to addresses for use by network service providers. Response: A number of factors mitigate the risks above: - As the transition to IPv6 gathers pace, any residual value of IPv4 addresses would fall in line with the decreasing value proposition of IPv4-based services in an increasing IPv6 network. - If this policy were to be adopted while IPv4 addresses are still available from APNIC, APNIC's established IPv4 address allocation process would continue to provide an alternative source of supply of IPv4 addresses to the industry. 5.2.2 Proposal diverts attention from address reclamation and resuse It has been argued that the proposal diverts attention from policy development that encourages IP address reclamation and reuse. Response: To date the level of return and reclamation of addresses has been minimal. Aside from price-based mechanisms it is unclear that further policy refinement would alter this situation. Even if policy development encouraged address reclamation and reuse, there is the distinct possibility that the amount reclaimed addresses would be smaller than the amount needed for APNIC to continue to allocate addresses on a needs-basis after the unallocated address pool has been exhausted. An open and significant issue is how APNIC could fairly ration limited addresses when faced with a much larger set of demands. In other words, concentrating on relamation and reuse policies rather than transfer policies also contains significant issues that may prove challenging to resolve as a policy matter. 5.2.3 Potential for APNIC to be cast as a regulator If APNIC adopted this policy, APNIC may be cast as a regulator of a secondary market in addresses. Concerns have been expressed that APNIC has no experience, expertise nor the authority to enforce regulatory actions. Such a role may also expose APNIC to additional litigation. Response: This proposal does not advocate such a role for APNIC. The scope of this policy is explicitly limited to the conditions that would allow APNIC to recognise and record a transfer of addresses in its registry. There is a general belief that adoption of this policy would act as an incentive for a market in addresses. However, that does not imply that markets would act outside existing regulatory structures. Nor does it mean that market participants would be immune from existing regulatory measures within their respective regimes. The potential for additional liabilities associated with this policy should be the subject of legal review by an appropriately qualified party. 6. Effect on APNIC members ---------------------------- APNIC members will have the ability to register the transfer of IPv4 address resources between APNIC members. 7. Effect on NIRs ------------------- This policy would allow NIRs to determine their own transfer policies, and allow the transfer of resources between APNIC members and the members of an NIR based on meeting the respective eligibility criteria for the transfer. -30-

3 2

Timeline for policy proposals at APNIC 27
by Sam Dickinson 19 Jan '09

19 Jan '09

Dear SIG members The deadline for submitting policy proposals to the APNIC Secretariat for discussion at APNIC 27 is 19 January 2009. As first used in the policy proposal timeline for APNIC 26, there is a one-week buffer between the deadline for submitting policy proposals to the Secretariat and the deadline for Chairs to send policy proposals to the SIG mailing lists. This one-week buffer gives the Secretariat time to help proposal authors conform to the policy proposal template and to help with any language issues that may arise. All policy proposals will be sent to the appropriate SIG mailing list by the end of 26 January 2009. This is the date that the minimum four-week discussion period before APNIC 27 begins. Regards -- _____________________________________________________________________ Samantha Dickinson email: sam(a)apnic.net Policy Development Manager, APNIC sip: sam(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100

1 0

prop-050 vs prop-067 (part two)
by Andy Linton 16 Jan '09

16 Jan '09

Address transfer process ==== prop-050 states: The proposal does not: - Prescribe how such transfers may occur, nor - Impose any further constraints on the transfer or on the parties involved. There is no equivalent in prop-067. Commentary from me: This section wasn't in the two previous drafts of prop-050. I believe we should take this section at its word and drop the section describing "The address transfer process". This is an operational issue and should be left to APNIC staff to handle. Fees ==== prop-050 states: Transfer fees: APNIC may charge the recipient a service fee on the transfer transaction. The transfer service fee may vary according to the total size of the address block being transferred. The transfer fee schedule shall be set initially by the APNIC Executive Council upon adoption of this policy. The transfer fee schedule will be included as part of any future review of APNIC fees and charges. There is no equivalent in prop-067. Commentary from me: It seems to me that this is where the fundamental difference between the two proposals lies and where change/compromise is needed although it's important to note that prop-050 says that "APNIC may charge" and that this is not a requirement. Clearly APNIC will incur costs in implementing these transfers but there seems to be a conflict between the existing policy for addresses allocated from the current free pool and addresses potentially obtained under the proposed transfer policy. The current 2008 membership fees and payment information (http://www.apnic.net/member/feesinfo.html) talks about: IP resource application fee A member's first address allocation request is subject to a non-refundable IP resource application fee of AU$3,169. Subsequent allocations are free of charges. I'm struggling to see why any additional fee is warranted. The cost to a current member (which we've already required) should be the same regardless of the source of the addresses. APNIC's work in the transfer scenario is the equivalent of the accepting a return of an unused block from a member and checking out an application from another member for a block of the same size. Clearly if the recipient has never been allocated a block of addresses the initial IP resource application fee applies as part of the standard APNIC fee structure. Other thoughts ==== So what about Section 5, Advantages and disadvantages of the proposal? I think Section 5.1, Advantages in both prop-050 and prop-067 say pretty much the same thing. The Disadvantages section of prop-050 has had eighteen months to evolve and while prop-063 claims there are no disadvantages to that proposal, the points raised in prop-050 could equally be applied to prop-063. Where to from here? ==== I'd like to see four things happen: 1) I'd like the authors of prop-050 and prop-063 to look at each others proposal and discuss with each other and the rest of us on this list the things they can agree on which could be in a unified proposal. 2) If there are fundamental differences in what they want to see happen then if they can identify those then that would help this community see what needs to be worked on. 3) If we can get the above points sorted out, are there members in the community who have other views that they want considered before Manila? 4) Try to table a document that synthesizes that consensus at APNIC 27.

3 2

Upcoming APNIC policy implementations
by Sam Dickinson 15 Jan '09

15 Jan '09

________________________________________________________________________ Upcoming APNIC policy implementations ________________________________________________________________________ On 16 February 2009, APNIC will implement three policy proposals that reached consensus during APNIC 26 in Christchurch, New Zealand in August 2008. The APNIC Executive Council (EC) endorsed the proposals during their November 2008 meeting. The three policy changes are: - Defining how APNIC should distribute the final /8 worth of IPv4 addresses from its unallocated pool This change aims to ensure that during the transition to IPv6, LIRs can still participate in the IPv4 Internet while they deploy services using the IPv6 Internet. - Including the utilization rate of historical IPv4 addresses when assessing an LIR's request for more IPv4 addresses. This change brings utilization of historical IPv4 addresses into line with current best practices for address management. It will ensure that organizations are using scarce IPv4 address space resources to the fullest extent possible. - Including an additional date in the timetable for moving from two-byte only AS numbers to four-byte only AS numbers This change aims to create greater awareness within the community for the need to support 4-byte AS numbers without mandating an absolute final adoption of 4-byte AS numbers. To view the history of these policy proposals, see: prop-062: Use of final /8 http://www.apnic.net/policy/proposals/prop-062-v002.html prop-064: Change to assignment policy for AS numbers http://www.apnic.net/policy/proposals/prop-064-v002.html prop-066: Ensuring efficient use of historical IPv4 resources http://www.apnic.net/policy/proposals/prop-066-v004.html APNIC policies are developed by the membership and broader Internet community. To have your say on policy proposals to be presented at APNIC 27 in Manila, Philippines, February 2009, join the Policy SIG mailing list. Details at: http://www.apnic.net/community/lists Regards -- _____________________________________________________________________ Samantha Dickinson email: sam(a)apnic.net Policy Development Manager, APNIC sip: sam(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100

1 0

prop-050 and prop-063 (part one)
by Andy Linton 14 Jan '09

14 Jan '09

I've been thinking about two of the policy proposals which are currently before this list and which will be discussed at APNIC 27 in Manila. The proposals in question are: [prop-050] IPv4 address transfers [prop-067] A simple transfer proposal It seems to me that these proposals are responses to the more or less same problem and so it would be better if we could get to the position where we had one proposal which encapsulated the best features from each of these documents. I think that would make it much easier for the community to reach consensus in Manila or at least move closer to that. I'll only concentrate on the section 4 of the two proposals, as this is where the "meat" of the proposal lies. To me, the issues fall into the following categories: * Size of the address blocks that can be transferred * Who is allowed to transfer space * Who can receive space Size of the address blocks that can be transferred ==== prop-050 states: "Conditions on the IPv4 address block: - Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. prop-067 states: "4.1 An organisation may transfer: a. An intact allocated block - Allocated blocks smaller than the current minimum APNIC allocation size may also be transferred as an intact block. For example, a legacy /24. b. One or more subnets of an allocated block, provided no subnet is smaller than the current minimum APNIC allocation size." Commentary from me: These two proposals effectively say the same thing here. prop-050 allows blocks to be split up into their constituent /24 subnets. And, in future, when IPv4 address space is at a premium, it's possible that a lowered minimum allocation size would mean that prop-063 would allow /24 transfers as well. prop-050 states: - The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder. - The address block will be subject to all current APNIC policies from the time of transfer. This includes address blocks previously considered to be "historical"." prop-067 states: 4.3 Transfers between regions are permitted providing that: a. The organisation originating transfer of an address block must follow the policies of the originating RIR. b. The organisation receiving an address block must follow the policies of the receiving RIR. Commentary from me: So prop-050 restricts the policy to APNIC only addresses whereas prop-067 widens the scope to allow transfers between regions. At first glance this seems a major difference but prop-067 notes that originating or receiving RIR policies must be followed. In other words if APNIC adopts a policy like prop-067 then inter-region transfers will only happen if other RIRs adopt a similar policy. So perhaps we should leave aside what the other RIRs will do and agree to look at how inter-region transfers happen later. Who is allowed to transfer space ==== prop-050 states: Conditions on source of the transfer: - The source entity must be a current APNIC account holder. - The source entity must be the currently registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. - The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer. - In making any future IPv4 address resource requests to APNIC, for as long as IPv4 address resources are available from APNIC, following the expiration of this 24 month ineligibility period, the source will be required to document the reasons for the IPv4 address resource allocation. prop-067 states: 4.4 The originating address holder must be the holder of record, whether a current member, historical, or otherwise. 4.5 If either the origin or recipient of the address block is in the APNIC region, they should be the holder of a current account in APNIC or the appropriate NIR. Commentary from me: prop-067 make no explicit mention of disputes about status but it seems a very reasonable condition. Who can receive space ==== prop-050 states: Conditions on recipient of the transfer: - The recipient entity must be a current APNIC account holder. - The recipient entity of the transferred resources will be subject to current APNIC policies. In particular, in any subsequent APNIC IPv4 address allocation request, the recipient will be required to account for all IPv4 address space held, including all transferred resources. - APNIC fees payable by the recipient will be assessed on the basis of all resources held. prop-067 states: 4.4 The originating address holder must be the holder of record, whether a current member, historical, or otherwise. 4.5 If either the origin or recipient of the address block is in the APNIC region, they should be the holder of a current account in APNIC or the appropriate NIR. Commentary from me: The fees issues isn't explicitly discussed in prop-067 but the requirement for current membership in section 4.5 would appear to cover it if combined with the "APNIC member fee schedule: tiers, fees, and descriptions" document (http://www.apnic.net/docs/corpdocs/member-fee-schedule.html) I'd like to assert that there's no substantive difference to the two proposals in the points described above. I think you could take the three sections above from prop-050, add a section that said APNIC would seek to coordinate transfers between regions when other RIRs had worked out their policies on this matter and it really wouldn't change prop-063 materially. Conversely you could take section 4 from prop-067, add a paragraph that acknowledged that until other RIRs agreed similar policies then this would be an APNIC only process and you could drop it into prop-050 and it wouldn't materially change it either. Now if this was all there was in section 4 of prop-050 then we might be in good shape to combine the two proposals but we have two more paragraphs to deal with. * Address transfer process * Fees But this email is getting very long, so I'll post more about them in my next email .

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy January 2009