sig-policy March 2011

sig-policy@lists.apnic.net

14 participants
11 discussions

prop-095: Inter RIR IPv4 address transfer proposal - Final call for comments
by Gaurab Raj Upadhaya 20 Apr '11

20 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the final call for comments on policy proposal "prop-095: Inter RIR IPv4 address transfer proposal". This proposal was presented at APNIC 31 and was accepted by consensus. The proposal is now being submitted to the Policy SIG mailing list for an eight-week discussion period. At the end of that period, if consensus appears to have been achieved, the Policy SIG Chair will ask the Executive Council to endorse the proposal for implementation. * Send all comments and questions to: <sig-policy at apnic dot net> * Deadline for comments: 26 April 2011 Proposal summary - ---------------- This is a proposal to allow and define a mechanism for the transfer of IPv4 address space between APNIC account holders and organizations in other RIR region(s), providing that the counterpart RIR has a policy that allows transfers of address space with APNIC account holders. Proposal details including the full text of the proposal, presentations, links to relevant meeting archives and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-095 Regards Guarab, Terence, and Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tEq0ACgkQSo7fU26F3X2xhQCbBnKp3CzuRyrGUuqeM01o7G4I +qEAnj5sTLQ09EGIq1helx/O2yh/oFXN =wxoW -----END PGP SIGNATURE-----

8 7

Monthly List Reminder
by noreply＠apnic.net 31 Mar '11

31 Mar '11

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-097: Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA - Final call for comments
by Gaurab Raj Upadhaya 04 Mar '11

04 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the final call for comments on policy proposal "prop-097: Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA". This proposal was presented at APNIC 31 and was accepted by consensus. The proposal is now being submitted to the Policy SIG mailing list for an eight-week discussion period. At the end of that period, if consensus appears to have been achieved, the Policy SIG Chair will ask the Executive Council to endorse the proposal for implementation. * Send all comments and questions to: <sig-policy at apnic dot net> * Deadline for comments: 26 April 2011 Proposal summary - ---------------- This proposal describes the process that IANA will follow to allocate IPv4 resources to Regional Internet Registries (RIRs) after the central pool of addresses is exhausted. The processes for how IPv4 space may be placed in the IANA Recovered IPv4 Pool is out of the scope of this proposal. Proposal details including the full text of the proposal, presentations, links to relevant meeting archives and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-097 Regards Guarab, Terence, and Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tEskACgkQSo7fU26F3X075gCeL3lETRgi4kfYqll8py18skl0 32UAnRJINvyVvXWUjG89nuiu2DeN75LS =b+bM -----END PGP SIGNATURE-----

9 8

prop-096: Maintaining demonstrated needs requirement in transfer, policy after the final /8 phase
by Andy Linton 04 Mar '11

04 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "prop-096: Maintaining demonstrated needs requirement in transfer policy after the final /8 phase", did not reach consensus at the APNIC 31 Policy SIG. Therefore, this proposal is being returned to the author and the Policy SIG mailing list for further discussion. Proposal summary - ---------------- This is a proposal to maintain the requirement for recipients of IPv4 transfers to justify their need for address space beyond the current allocation phase and into the final /8 phase. Proposal details including the full text of the proposal, presentations, links to relevant meeting archives and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-096 Regards Gaurab, Terence, and Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNcE5BkNpmQ2ketuURAkIbAJ9NXHLiSalsfmW3+wT/rbHgv4/i2ACeI7D5 /3oDvh4VYFeiC3Pz60sDxAE= =Vh3O -----END PGP SIGNATURE-----

3 3

prop-088: Distribution of IPv4 addresses once the final /8 period starts - Final call for comments
by Gaurab Raj Upadhaya 03 Mar '11

03 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello All, This is the final call for comments on policy proposal "prop-088: Distribution of IPv4 addresses once the final /8 period starts". This proposal was presented at APNIC 31 and was accepted by consensus. The proposal is now being submitted to the Policy SIG mailing list for an eight-week discussion period. At the end of that period, if consensus appears to have been achieved, the Policy SIG Chair will ask the Executive Council to endorse the proposal for implementation. * Send all comments and questions to: <sig-policy at apnic dot net> * Deadline for comments: 26 April 2011 Proposal summary - ---------------- This is a proposal to handle any IPv4 address space received by APNIC after the final /8 policy is implemented as being part of the final /8 pool and to redistribute these resources according to the final /8 policies. Proposal details including the full text of the proposal, presentations, links to relevant meeting archives and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-088 Regards Guarab, Terence, and Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tEkcACgkQSo7fU26F3X35awCgkimQ2j2YgE+Rl7OJyzYxAz2Q 0t8AoM2F89I38Dvb8A8SRAwN5FeBtofN =1dZ8 -----END PGP SIGNATURE-----

2 1

prop-094: Removing renumbering requirement from final /8 policy - Final call for comments
by Gaurab Raj Upadhaya 01 Mar '11

01 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, This is the final call for comments on policy proposal "prop-094: Removing renumbering requirement from final /8 policy". Version 1 of this proposal was named "Adding alternative criteria to renumbering requirement in final /8 policy". This proposal was presented at APNIC 31 and was accepted by consensus. The proposal is now being submitted to the Policy SIG mailing list for an eight-week discussion period. At the end of that period, if consensus appears to have been achieved, the Policy SIG Chair will ask the Executive Council to endorse the proposal for implementation. * Send all comments and questions to: <sig-policy at apnic dot net> * Deadline for comments: 26 April 2011 Proposal summary - ---------------- This is a proposal to remove the requirement for organizations receiving their initial allocation from APNIC to renumber out of their previously deployed space when they are allocated addresses under the final /8 policy. Proposal details including the full text of the proposal, presentations, links to relevant meeting archives and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-094 Regards Guarab, Terence, and Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tEosACgkQSo7fU26F3X0J0ACg2XfyMDX28PTwsHTi6PDjV5jv poAAni/IISxxvEPx8Fg9UgxNo/T0LjcF =oqSl -----END PGP SIGNATURE-----

1 0

prop-093: Reducing the minimum delegation size for the final /8 policy - Final call for comments
by Gaurab Raj Upadhaya 01 Mar '11

01 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the final call for comments on policy proposal "prop-093: Reducing the minimum delegation size for the final /8 policy". This proposal was presented at APNIC 31 and was accepted by consensus. The proposal is now being submitted to the Policy SIG mailing list for an eight-week discussion period. At the end of that period, if consensus appears to have been achieved, the Policy SIG Chair will ask the Executive Council to endorse the proposal for implementation. * Send all comments and questions to: <sig-policy at apnic dot net> * Deadline for comments: 26 April 2011 Proposal summary - ---------------- This is a proposal to change the minimum size of IPv4 delegations to a /24 when the final /8 policy is activated. Proposal details including the full text of the proposal, presentations, links to relevant meeting archives and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-093 Regards Guarab, Terence, and Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tEl4ACgkQSo7fU26F3X0ovwCgynLE818XkW468kCzYAGst6mk pEYAoMqJrT18VgROd55Ys4lKxoUmN1jB =cD9U -----END PGP SIGNATURE-----

1 0

prop-083: Alternative criteria for subsequent IPv6 allocations - Final call for comments
by Gaurab Raj Upadhaya 01 Mar '11

01 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the final call for comments on policy proposal "prop-083: Alternative criteria for subsequent IPv6 allocations". This proposal was presented at APNIC 31 and was accepted by consensus. The proposal is now being submitted to the Policy SIG mailing list for an eight-week discussion period. At the end of that period, if consensus appears to have been achieved, the Policy SIG Chair will ask the Executive Council to endorse the proposal for implementation. * Send all comments and questions to: <sig-policy at apnic dot net> * Deadline for comments: 26 April 2011 Proposal summary - ---------------- This is a proposal to enable current APNIC account holders with existing IPv6 allocations to receive subsequent IPv6 allocations from APNIC for use in networks that are not connected to the initial IPv6 allocation. Proposal details including the full text of the proposal, presentations, links to relevant meeting archives and links to mailing list discussions are available at: http://www.apnic.net/policy/proposals/prop-083 Regards Guarab, Terence, and Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tEhkACgkQSo7fU26F3X0tYQCfbKdbBbpE4t5zfBZp+4aFMy9L VwMAn0xsBpuQ3Oe/g9e9ISiA1mTP0SBJ =cXmu -----END PGP SIGNATURE-----

1 0

prop-083-v003: Alternative criteria for subsequent IPv6 allocations
by Gaurab Raj Upadhaya 01 Mar '11

01 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear SIG members Below is an updated version of the proposal that includes elements changed during the APNIC 31 Policy SIG meeting. The following changes were made: - The specific examples in section 4.2 were removed from the text. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-083 This proposal reached consensus at the Policy SIG meeting during the Policy SIG at APNIC 31 in Hong Kong SAR, China, 21-25 February 2011. It will be presented to the Policy SIG mailing list soon for a formal eight-week final call for comments. Gaurab, Terence, and Andy ___________________________________________________________________ prop-083-v003: Alternative criteria for subsequent IPv6 allocations ___________________________________________________________________ Author: Skeeve Stevens <skeeve(a)eintellego.net> Version: 3 Date: 24 February 2011 1. Introduction - ---------------- This is a proposal to enable current APNIC account holders with existing IPv6 allocations to receive subsequent IPv6 allocations from APNIC to facilitate network deployments. Examples: - For use in networks that are not connected to the initial IPv6 allocation - Transitional technologies such as 6RD - Other reasons accepted by APNIC as valid circumstance, or as decided by the community in policy amendments. 2. Summary of current problem - ------------------------------ An APNIC account holder with an existing /32 IPv6 allocation (or larger) is unable to deaggregate that allocation into routes smaller than a /32 due to the community practice of 'filter blocking' or 'bogon lists' associated with RIR blocks which are known to have a minimum allocation size of /32 [1]. As an example, a LIR may want to build a network in a separate location and provide IPv6 connectivity; however, because the LIR risks routability problems if they deaggregate, they cannot use a subset of their initial allocation in the new location. For example: An ISP has a /32 allocation which they announce via an upstream in Australia.Ê The ISP wants to build a new network in Cambodia. The ISP's new network in Cambodia is not connected to the existing Australian network and the ISP is using a local transit provider to obtain dual stacked connectivity. If the network was using IPv4 addresses, the ISP would usually be able to deaggregate their allocation and announce one part of the deaggregated range to the local transit provider. In IPv6, however, this is not possible due to 'community filtering' on ranges smaller than a /32. Such a filter may look like the following: ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32 This above statement in the IPv6 BGP filter recommendations would cause any announcements by an ISP which had an allocation, such as 2400:0000::/32, to announce smaller routes from that block, such as multiple /35s for example, to be filtered.Ê In a default free situation, connectivity to the ISP would be problematic. Instead, the ISP needs to obtain a new /32 allocation to be able to have IPv6 connectivity in the new location with an independent (from their primary network) transit provider. Other valid examples of subsequent allocation may be to facilitate transitional technologies such as 6RD. 3. Situation in other RIRs - --------------------------- AfriNIC and LACNIC currently have no similar policies or proposals. ARIN: A similar policy, 2009-5 has been adopted [3] and integrated into the ARIN Number Resource Policy Manual RIPE: A similar policy, 2009-5 [4] was rejected in favor of 2009-6 [5] RIPE's 2009-6 recommended that routing announcements requirements be relaxed so that LIRÕs can announce smaller (i.e. if they have a /32, they can announce a /35) prefixes. APNIC Policy 082 at this meeting (APNIC 29) is basically the same, but does not address this issue covered by this policy proposal. 4. Details of the proposal - --------------------------- 4.1 It is proposed that alternative criteria be added to the subsequent IPv6 allocation policy [2] to allow current APNIC account holders to obtain additional IPv6 resources. 4.2 To qualify for subsequent IPv6 allocations under the proposed alternative criteria, account holders must: - Be a current APNIC account holder with an existing IPv6 allocation - Be announcing its existing IPv6 allocation - Have a compelling reason for requiring the subsequent allocation 4.3 As part of this process, if the LIR should indicate whether it will be using an existing ASN for the additional announcement which cannot be the same as the ASN of the initial assignment. 5. Advantages and disadvantages of the proposal - ------------------------------------------------ 5.1 Advantages - This proposal enables current APNIC account holders to avoid problematic network design issues and policy issues related to deaggregation. - Current APNIC account holders will be able to acquire resources and announce them separately to transit providers in disparate locations. 5.2 Disadvantages - This proposal could cause faster consumption of IPv6 address space. However, given the size of the total IPv6 pool, the author of this proposal does not see this as a significant issue. 6. Effect on APNIC members - --------------------------- APNIC members would be able to build networks in separate locations and obtain local IPv6 connectivity and announce their own resources. 7. Effect on NIRs - ------------------ The proposal allows for NIRs to have the choice as to when to adopt this policy for their members. 8. References - --------------- [1] For example, see "IPv6 BGP filter recommendations" http://www.space.net/~gert/RIPE/ipv6-filters.html [2] See section 5.2, "Subsequent Allocation Section" in "IPv6 Address Allocation and Assignment Policy" http://www.apnic.net/policy/ipv6-address-policy#5.2 [3] https://www.arin.net/policy/proposals/2009_5.html [4] http://www.ripe.net/ripe/policies/proposals/2009-05.html [5] http://www.ripe.net/ripe/policies/proposals/2009-06.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1scSkACgkQSo7fU26F3X00kgCg9ONbsCtvi+I6nKrAF/l/hFC5 OjEAoPJYqDgnfWkSY9CuPvZP+s0wU/R+ =ZhcR -----END PGP SIGNATURE-----

1 0

prop-094-v002: Removing renumbering requirement from final /8 policy
by Gaurab Raj Upadhaya 01 Mar '11

01 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear SIG members Below is an updated version of the proposal that includes elements changed during the APNIC 31 Policy SIG meeting. The following changes were made: - The name of the proposal was updated to more accurately reflect the changed details - Section 4 was changed to propose that criteria 'd' of section 9.3 be removed once we move into the final /9 phase of allocation. The proposal's history can be found at: http://www.apnic.net/policy/proposals/prop-094 This proposal reached consensus at the Policy SIG meeting during the Policy SIG at APNIC 31 in Hong Kong SAR, China, 21-25 February 2011. It will be presented to the Policy SIG mailing list soon for a formal eight-week final call for comments. Gaurab, Terence, and Andy ________________________________________________________________________ prop-094-v002: Removing renumbering requirement from final /8 policy ________________________________________________________________________ Authors: Izumi Okutani Terence Zhang Yinghao Version: 2 Date: 24 February 2011 1. Introduction - - - ---------------- This is a proposal to remove the requirement for organizations receiving their initial allocation from APNIC to renumber out of their previously deployed space when they are allocated addresses under the final /8 policy [1]. 2. Summary of the current problem - - - ---------------------------------- Under the current final /8 policy, allocations made to LIRs must meet the criteria specified under one of the two following sections of the "Policies for IPv4 address space management in the Asia Pacific region": - Section 9.3, Criteria for initial allocation - Section 9.4, Criteria for subsequent allocations One of the criteria for initial allocations is that the LIR: "commit to renumber from previously deployed space into the new address space within one year." Under current IPv4 allocation policy, that is, before the final /8 policy is activated, LIRs can receive any sized allocation they are able to justify. In the case of initial allocations, for the sake of conservation and aggregation, policy requires that any LIR that has previously used non-portable IPv4 addresses from their upstream provider must agree to renumber out of those addresses and into their new portable APNIC allocation within one year. This allowed the LIR to maintain the size of its previous non-portable address block plus add its next 12 months worth of addressing needs to its new portable allocation from APNIC. However, when we have reached the final /8, the size of allocation will be restricted to a single /22. As a result, APNIC will no longer be able to consider the loss of address space caused by renumbering, when determining the size of an LIR's initial allocation. As a result, the renumbering requirement for initial allocations will in practice result in reclamation of a new LIR's address holding, without the ability to sufficiently compensate the LIR with a corresponding allocation size. In such cases, it would be unreasonable to expect these organizations to number out of a upstream block into a single /22 from APNIC. 3. Situation in other RIRs - - - --------------------------- RIPE: The "Allocations for the last /8" policy does not define additional requirements for the renumbering of address space. See Section 5.6, "Use of last /8 for PA Allocations," in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region": http://www.ripe.net/ripe/docs/ripe-509.html There is no similar policy or proposal in the AfriNIC, ARIN or LACNIC regions. 4. Details - - - ----------- It is proposed that once APNIC starts allocations under the final /8 policy(*1), initial allocation criteria be changed to remove the requirement to renumber from previously deployed space. Specifically, section 9.3(*2) should be adjusted with a clause that criteria (d) "Commit to renumber from previously deployed space into the new address space within one year" be removed once we apply the final /8 policy(*1). (*1) section "9.10 Distribution of the final /8 worth of space in the unallocated APNIC IPv4 address pool" under the current document http://www.apnic.net/policy/add-manage-policy#9.10 (*2) defined in section "9.3 Criteria for initial allocation" of the current policy document http://www.apnic.net/policy/add-manage-policy#9.3 5. Pros/Cons - - - ------------- Advantages: - It will allow new LIRs to receive a /22 under the final /8 policy without restricting its total current address holdings. Disadvantages: - Some people might suggest that increased fraudulent applications might result from this proposed policy. However, adding or removing the renumbering requirement does NOT increase or decrease the possibility of fraud. Fraud is already a potential risk in address requests, and it is assumed that APNIC would detect and respond to any fraud related to this proposed policy in a proper manner. 6. Effect on APNIC - - - ------------------- It will allow APNIC members to receive a /22 allocation under the final /8 policy from APNIC without renumbering its current address holdings. 8. Effect on NIRs - - - ------------------ Just as the final /8 policy applies to NIRs, this amendment to the final /8 policy would apply to NIRs. 9. References - - - ------------- [1] Section 9.10.1, "Allocations to LIRs," in "Policies for IPv4 address space management in the Asia Pacific region" http://www.apnic.net/policy/add-manage-policy - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1scOgACgkQSo7fU26F3X1P5ACgxhH7kzaJo7zNOdWOQq7Sleqt TUYAmwTYA5+EbA8YEzKFoy0VStxvazZP =28Lz -----END PGP SIGNATURE-----

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy March 2011