From info at arin.net Mon Oct 5 13:41:09 2009 From: info at arin.net (Member Services) Date: Mon, 05 Oct 2009 13:41:09 -0400 Subject: Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <4AAE4700.5050508@arin.net> References: <4AAE4700.5050508@arin.net> Message-ID: <4ACA2FB5.90602@arin.net> Draft Policy 2009-3 (Global Proposal) Allocation of IPv4 Blocks to Regional Internet Registries On 14 September 2009 a revised version of Draft Policy 2009-3 was posted to the Public Policy Mailing List (PPML). ARIN staff reviewed the text of the draft policy and produced the following revised staff and legal assessment. 2009-3 is under discussion on PPML and will be presented at the upcoming Public Policy Meeting in Dearborn. Draft Policy 2009-3 is below and can be found at: https://www.arin.net/policy/proposals/2009_3.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Staff Assessment Draft Policy 2009-3 (Global Proposal) Allocation of IPv4 Blocks to Regional Internet Registries Text assessed: 14 September 2009 I. Summary (Staff Understanding) (revised): Staff understands that this proposal would be implemented in 2 phases. Phase 1 says that the RIRs may elect to return any IPv4 addresses they recover (via policy or procedure) to the IANA but it does not require them to return recovered IPv4 address space to IANA. Phase 2 would start after the depletion of the IANA free pool and would nullify the existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The new IANA to RIR policy would allow each RIR to receive approximately 1/10th of the recovered IPv4 pool from IANA once every 6 months as long as it meets the qualification criteria written in paragraph B2. IANA will be required to keep a log of all returned IPv4 address space and all issued IPv4 address space from the recovered pool, as well as maintain a public registry of the current disposition of all IPv4 address space. II. Comments A. ARIN Staff Comments (revised) ? If an RIR is fully authoritative for a /8, and as a result of this policy, returns a portion of that /8 to IANA, it is likely that the DNS authority for the /8 could change. If the returned space is then re-issued by IANA to a different RIR, is the /8 now considered an ERX-like "fractured" /8, which the RIRs must then exchange zone fragments for to put together a complete set of zone files for the /8? Close coordination by the 5 RIRs will be required in order to successfully manage the potential reverse DNS implications. B. ARIN General Counsel Comments (revised): The current basis of allocating number resources was established in RFC's 2008 and 2050 and is defined to be according to operational need. If one region has greater needs than another, current allocation policy does not call for equal distribution of numbering resources to all RIR's. The revised portion of this policy removes objectionable requirements in the prior version that required ARIN to return all recovered IPV4 space to the IANA, when such space might be needed in this region, or other regions were not maintaining need's based distribution policies. That first problem was exacerbated by a second: the policy included a redistribution mechanism that did not follow RFC 2008 and 2050 but would provide ARIN, at best, only one fifth of such space, when it was also likely ARIN would return more than one fifth of the recovered space. The revision to voluntarily permit, but not require ARIN to return such recovered space is a substantial advance and removes strong legal and fiduciary objections to the prior draft. Accordingly, the revised policy also removes the prior version's disincentive for any RIR, including ARIN, to undertake financial expenditure of its financial resources for programs intended to obtain returned space, since it does not force 100% return to IANA. Since ARIN has expended significant resources seeking the return of unused number resources, this is again a positive change. It also appears, and it must be made so if it is not, that the revised language would not interfere with transfers made under ARIN's new policy, which is intended to encourage better use of otherwise underutilized resources. However, the revised proposal appears to retain the predecessor' drafts policy that each RIR with needs will be an equal recipient of such returned space, even if those needs are disparate. This policy could tend to reallocate returned space away from where it is recovered, in the ARIN region, to other regions. This would be objectionable from a fiduciary duty perspective if one or more of the other RIRs abandon needs-based policies, but are then permitted by this policy to obtain equal additional resources. However, since ARIN can choose not to return recovered resources if others RIRs are not maintaining needs based policies, this is no longer a fatal legal flaw, since ARIN can chose not to provide returned resources for redistribution under such circumstances. There is a concern over one particular piece of the policy. In 4 it states: "Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA." The 'new' reference appears unwise, with "recognized" RIRs being a better choice. III. Resource Impact The resource impact of implementing this policy is viewed as moderate as it represents a fundamental change to the business rules of ARIN?s inventory management of number resources. It is estimated that this policy would require a minimum of 6 person months of effort to implement following ratification by the ARIN Board of Trustees. Because this implementation is not planned, it may preempt ARIN's current project deployment schedule. It may require the following: ? Modifications to existing registration procedures to include the handling of returned/reclaimed address space and the process of requesting additional address space from the IANA. ? Modifications to the existing registration software and systems as well as the zone gen and any other processes tied to managing reverse DNS. ? Staff training ? Inter-RIR coordination End of assessment. Member Services wrote: > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > On 20 August 2009 the ARIN Advisory Council (AC) selected 2009-3 for > adoption discussion on the PPML and at the Public Policy Meeting in > Dearborn. > > 2009-3 comes from a global policy proposal. Global policies require the > agreement of all five RIRs according to their policy development > processes and ratification by ICANN. And, global policies require > specific actions by the IANA. > > After the ARIN Public Policy Meeting in April 2009 the AC returned > 2009-3 to their docket for further development and evaluation. > > The AC revised the text. The difference between the text presented at > the ARIN meeting in April and the current version is in "A. Phase I" as > follows: > > Old ARIN "A. Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. At > quarterly intervals, each RIR shall return to the IANA any legacy > address space recovered, and may return to the IANA any non-legacy > address space recovered, in aggregated blocks of /24 or larger, for > inclusion in the recovered IPv4 pool. > > New ARIN "A. Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA. Each RIR shall at > quarterly intervals return any such designated address space to the > IANA in aggregated blocks of /24 or larger, for inclusion in the > recovered IPv4 pool. > > Draft Policy 2009-3 is below and can be found at: > https://www.arin.net/policy/proposals/2009_3.html > > You are encouraged to discuss Draft Policy 2009-3 on the PPML prior to > the October Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > Note, the ARIN version of the global proposal is different from the text > at the other RIRs. The AC's version has a revised "A. Phase I" (APNIC's > equivalent is prop-069, see the second paragraph of 5.1). The ARIN > version also includes a definition of legacy space. > > The APNIC proposal can be found at: > http://www.apnic.net/policy/proposals/prop-069 > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > Version/Date: 14 September 2009 > > Policy statement: > > This document describes the policy 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 IANA to an RIR in accordance with this policy. > Such requirements should be specified by appropriate agreements among > the RIRs and ICANN. > > This policy is to be implemented in two phases. > > A. 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 and > designate any such space for return to the IANA. Each RIR shall at > quarterly intervals return any such designated 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. Return of recovered address space (as described above) will > continue throughout Phase II. > > B. 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 > address space is depleted; Global Addressing Policy ASO-001-2 (adopted > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to > allocate the IPv4 address space from the recovered IPv4 pool. > > 1. The following definitions apply to this policy: > > a. Recovered Address Space. Recovered address space is that address > space that is returned to an RIR as a result of any activity that seeks > to reclaim unused address space or is voluntarily returned to the RIR or > is reclaimed by the RIR as a result of legal action or abuse > determination. Recovered address space does not include that address > space that is reclaimed because of non-payment of contractual fees whose > reclamation date is less than 1 year at the time of the report. > > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 > address space held by an RIR to include recovered address space not yet > returned less that address space that is committed in accordance with > the RIR's reservation policy and practices. > > c. Aggregated address blocks. Aggregated address blocks are contiguous > prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 > and 10.0.1.0/24 are two contiguous prefixes that can be combined to form > an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two > contiguous prefixes that cannot be combined on a natural bit boundary to > form an aggregated block. > > d. Legacy address space. IPv4 address space allocated or assigned prior > to the creation of the RIR. > > 2. 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. > The minimum 'IPv4 allocation unit' size will be a /24. > > c. In each allocation period, each RIR may issue one IPv4 request to the > IANA. Providing that the RIR satisfies the allocation criteria described > in paragraph B.2, the IANA will allocate a single allocation unit, > composed of the smallest possible number of blocks available in its IPv4 > address pool. > > 3. 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. 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. > > 5. 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 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. > > > > > > > > > > > > > From info at arin.net Wed Oct 7 14:17:58 2009 From: info at arin.net (Member Services) Date: Wed, 07 Oct 2009 14:17:58 -0400 Subject: [arin-ppml] Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <4ACA2FB5.90602@arin.net> References: <4AAE4700.5050508@arin.net> <4ACA2FB5.90602@arin.net> Message-ID: <4ACCDB56.3070706@arin.net> A revised rationale has been added to the 2009-3 draft policy page: https://www.arin.net/policy/proposals/2009_3.html Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > On 14 September 2009 a revised version of Draft Policy 2009-3 was posted > to the Public Policy Mailing List (PPML). ARIN staff reviewed the text > of the draft policy and produced the following revised staff and legal > assessment. > > 2009-3 is under discussion on PPML and will be presented at the upcoming > Public Policy Meeting in Dearborn. > > Draft Policy 2009-3 is below and can be found at: > https://www.arin.net/policy/proposals/2009_3.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Staff Assessment > > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > Text assessed: 14 September 2009 > > I. Summary (Staff Understanding) (revised): > > Staff understands that this proposal would be implemented in 2 phases. > Phase 1 says that the RIRs may elect to return any IPv4 addresses they > recover (via policy or procedure) to the IANA but it does not require > them to return recovered IPv4 address space to IANA. > > Phase 2 would start after the depletion of the IANA free pool and would > nullify the existing IANA to RIR policy (Global Addressing Policy > ASO-001-2). The new IANA to RIR policy would allow each RIR to receive > approximately 1/10th of the recovered IPv4 pool from IANA once every 6 > months as long as it meets the qualification criteria written in > paragraph B2. IANA will be required to keep a log of all returned IPv4 > address space and all issued IPv4 address space from the recovered pool, > as well as maintain a public registry of the current disposition of all > IPv4 address space. > > II. Comments > > A. ARIN Staff Comments (revised) > ? If an RIR is fully authoritative for a /8, and as a result of this > policy, returns a portion of that /8 to IANA, it is likely that the DNS > authority for the /8 could change. If the returned space is then > re-issued by IANA to a different RIR, is the /8 now considered an > ERX-like "fractured" /8, which the RIRs must then exchange zone > fragments for to put together a complete set of zone files for the /8? > Close coordination by the 5 RIRs will be required in order to > successfully manage the potential reverse DNS implications. > > B. ARIN General Counsel Comments (revised): > > The current basis of allocating number resources was established in > RFC's 2008 and 2050 and is defined to be according to operational need. > If one region has greater needs than another, current allocation policy > does not call for equal distribution of numbering resources to all RIR's. > > The revised portion of this policy removes objectionable requirements in > the prior version that required ARIN to return all recovered IPV4 space > to the IANA, when such space might be needed in this region, or other > regions were not maintaining need's based distribution policies. That > first problem was exacerbated by a second: the policy included a > redistribution mechanism that did not follow RFC 2008 and 2050 but would > provide ARIN, at best, only one fifth of such space, when it was also > likely ARIN would return more than one fifth of the recovered space. The > revision to voluntarily permit, but not require ARIN to return such > recovered space is a substantial advance and removes strong legal and > fiduciary objections to the prior draft. > > Accordingly, the revised policy also removes the prior version's > disincentive for any RIR, including ARIN, to undertake financial > expenditure of its financial resources for programs intended to obtain > returned space, since it does not force 100% return to IANA. Since ARIN > has expended significant resources seeking the return of unused number > resources, this is again a positive change. It also appears, and it must > be made so if it is not, that the revised language would not interfere > with transfers made under ARIN's new policy, which is intended to > encourage better use of otherwise underutilized resources. > > However, the revised proposal appears to retain the predecessor' drafts > policy that each RIR with needs will be an equal recipient of such > returned space, even if those needs are disparate. This policy could > tend to reallocate returned space away from where it is recovered, in > the ARIN region, to other regions. This would be objectionable from a > fiduciary duty perspective if one or more of the other RIRs abandon > needs-based policies, but are then permitted by this policy to obtain > equal additional resources. > However, since ARIN can choose not to return recovered resources if > others RIRs are not maintaining needs based policies, this is no longer > a fatal legal flaw, since ARIN can chose not to provide returned > resources for redistribution under such circumstances. > > There is a concern over one particular piece of the policy. In 4 it > states: "Each new RIR shall, at the moment of recognition, be allocated > one (1) allocation unit by the IANA." The 'new' reference appears > unwise, with "recognized" RIRs being a better choice. > > III. Resource Impact > > The resource impact of implementing this policy is viewed as moderate as > it represents a fundamental change to the business rules of ARIN?s > inventory management of number resources. It is estimated that this > policy would require a minimum of 6 person months of effort to implement > following ratification by the ARIN Board of Trustees. Because this > implementation is not planned, it may preempt ARIN's current project > deployment schedule. > > It may require the following: > > ? Modifications to existing registration procedures to include the > handling of returned/reclaimed address space and the process of > requesting additional address space from the IANA. > > ? Modifications to the existing registration software and systems as > well as the zone gen and any other processes tied to managing reverse > DNS. > > ? Staff training > > ? Inter-RIR coordination > > End of assessment. > > Member Services wrote: >> Draft Policy 2009-3 (Global Proposal) >> Allocation of IPv4 Blocks to Regional Internet Registries >> >> On 20 August 2009 the ARIN Advisory Council (AC) selected 2009-3 for >> adoption discussion on the PPML and at the Public Policy Meeting in >> Dearborn. >> >> 2009-3 comes from a global policy proposal. Global policies require the >> agreement of all five RIRs according to their policy development >> processes and ratification by ICANN. And, global policies require >> specific actions by the IANA. >> >> After the ARIN Public Policy Meeting in April 2009 the AC returned >> 2009-3 to their docket for further development and evaluation. >> >> The AC revised the text. The difference between the text presented at >> the ARIN meeting in April and the current version is in "A. Phase I" as >> follows: >> >> Old ARIN "A. Phase I" >> >> Each RIR through their respective chosen policies and strategies may >> recover IPv4 address space which is under their administration. At >> quarterly intervals, each RIR shall return to the IANA any legacy >> address space recovered, and may return to the IANA any non-legacy >> address space recovered, in aggregated blocks of /24 or larger, for >> inclusion in the recovered IPv4 pool. >> >> New ARIN "A. Phase I" >> >> Each RIR through their respective chosen policies and strategies may >> recover IPv4 address space which is under their administration and >> designate any such space for return to the IANA. Each RIR shall at >> quarterly intervals return any such designated address space to the >> IANA in aggregated blocks of /24 or larger, for inclusion in the >> recovered IPv4 pool. >> >> Draft Policy 2009-3 is below and can be found at: >> https://www.arin.net/policy/proposals/2009_3.html >> >> You are encouraged to discuss Draft Policy 2009-3 on the PPML prior to >> the October Public Policy Meeting. Both the discussion on the list and >> at the meeting will be used by the ARIN Advisory Council to determine >> the community consensus for adopting this as policy. >> >> Note, the ARIN version of the global proposal is different from the text >> at the other RIRs. The AC's version has a revised "A. Phase I" (APNIC's >> equivalent is prop-069, see the second paragraph of 5.1). The ARIN >> version also includes a definition of legacy space. >> >> The APNIC proposal can be found at: >> http://www.apnic.net/policy/proposals/prop-069 >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy 2009-3 (Global Proposal) >> Allocation of IPv4 Blocks to Regional Internet Registries >> >> Version/Date: 14 September 2009 >> >> Policy statement: >> >> This document describes the policy 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 IANA to an RIR in accordance with this policy. >> Such requirements should be specified by appropriate agreements among >> the RIRs and ICANN. >> >> This policy is to be implemented in two phases. >> >> A. 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 and >> designate any such space for return to the IANA. Each RIR shall at >> quarterly intervals return any such designated 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. Return of recovered address space (as described above) will >> continue throughout Phase II. >> >> B. 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 >> address space is depleted; Global Addressing Policy ASO-001-2 (adopted >> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to >> allocate the IPv4 address space from the recovered IPv4 pool. >> >> 1. The following definitions apply to this policy: >> >> a. Recovered Address Space. Recovered address space is that address >> space that is returned to an RIR as a result of any activity that seeks >> to reclaim unused address space or is voluntarily returned to the RIR or >> is reclaimed by the RIR as a result of legal action or abuse >> determination. Recovered address space does not include that address >> space that is reclaimed because of non-payment of contractual fees whose >> reclamation date is less than 1 year at the time of the report. >> >> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 >> address space held by an RIR to include recovered address space not yet >> returned less that address space that is committed in accordance with >> the RIR's reservation policy and practices. >> >> c. Aggregated address blocks. Aggregated address blocks are contiguous >> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 >> and 10.0.1.0/24 are two contiguous prefixes that can be combined to form >> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two >> contiguous prefixes that cannot be combined on a natural bit boundary to >> form an aggregated block. >> >> d. Legacy address space. IPv4 address space allocated or assigned prior >> to the creation of the RIR. >> >> 2. 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. >> The minimum 'IPv4 allocation unit' size will be a /24. >> >> c. In each allocation period, each RIR may issue one IPv4 request to the >> IANA. Providing that the RIR satisfies the allocation criteria described >> in paragraph B.2, the IANA will allocate a single allocation unit, >> composed of the smallest possible number of blocks available in its IPv4 >> address pool. >> >> 3. 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. 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. >> >> 5. 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 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. >> >> >> >> >> >> >> >> >> >> >> >> >> > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From info at arin.net Wed Oct 21 09:03:56 2009 From: info at arin.net (Member Services) Date: Wed, 21 Oct 2009 09:03:56 -0400 Subject: ARIN XXIV Now Underway Message-ID: <4ADF06BC.6030404@arin.net> The ARIN XXIV Public Policy and Members Meeting begins today in Dearborn, Michigan. For those in the community who are unable to be in Dearborn, ARIN is offering a webcast and live transcript of the proceedings. The times of the broadcast are as follows: Public Policy Meeting (Policy and technical discussions) Wednesday, 21 October 9AM - 5PM Thursday, 22 October 9AM - 5PM Members Meeting (ARIN reports, Board of Trustees and Advisory Council reports) Friday, 23 October 9AM - 12PM All times are Eastern Daylight Time (EDT), (UTC/GMT -4 hours) Note that all candidate speeches will be given on Wednesday, 21 October. The NRO NC candidate speeches will begin at 11 AM and ARIN Board and AC candidate speeches will begin at 2PM. Archives of these speeches will be posted on the ARIN website by Thursday, 22 October. You may register as a remote participant at any time throughout the meeting, and registered remote participants are invited to join in the meeting chat to vote in straw polls and submit questions or comments during the times listed above. Pre-register your Jabber Identifier (JID) to have full chat room access from the start of the meeting. You can register a JID at any time, but we will only be adding new participants during scheduled breaks in the meeting. The full agenda is available at: https://www.arin.net/ARIN-XXIV/agenda.html You can also follow us on Twitter @TeamARIN for schedule updates. Be sure to use the #arin24 tag for your own tweets about the meeting. For details about how to connect to the webcast, chat, and live transcript, or to refer to the Remote Participation Acceptable Use Policy, please see: http://www.arin.net/ARIN-XXIV/remote.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Oct 28 14:39:06 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:39:06 -0400 Subject: Advisory Council Meeting Results - October 2009 Message-ID: <4AE88FCA.4090706@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 23 October 2009 and made decisions about several draft policies. The AC moved the following four draft policies to last call. Two are being sent to last call as they were presented at the ARIN XXIV Public Policy Meeting, and two were revised by the AC. Each draft policy will be posted separately to last call. 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries (revised) 2009-5: IPv6 Multiple Discrete Networks 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries 2009-7: Open Access To IPv6 (revised) The AC returned ?2009-8: Equitable IPv4 Run-Out? to the AC?s docket for further development. 2009-8 can be petitioned to last call if someone is dissatisfied with the AC?s decision to return it to their docket for more work. 2009-3 and 2009-7 may also be petitioned if someone is dissatisfied with the AC?s decision to send revised text to last call. The deadline to begin a petition is 4 November 2009. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Oct 28 14:39:36 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:39:36 -0400 Subject: Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries - Last Call Message-ID: <4AE88FE8.5080103@arin.net> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to send a revised version of the following draft policy to last call: Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. The AC revised the draft. The AC removed sections B.1.d and B.4. B.1. ?d. Legacy address space. IPv4 address space allocated or assigned prior to the creation of the RIR.? B. ?4. 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.? Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 November 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-3 (Global Proposal) Allocation of IPv4 Blocks to Regional Internet Registries Version/Date: 28 October 2009 Policy statement: This document describes the policy 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 IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases. A. 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 and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated 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. Return of recovered address space (as described above) will continue throughout Phase II. B. 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 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 1. The following definitions apply to this policy: a. Recovered Address Space. Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than 1 year at the time of the report. b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices. c. Aggregated address blocks. Aggregated address blocks are contiguous prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 and 10.0.1.0/24 are two contiguous prefixes that can be combined to form an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two contiguous prefixes that cannot be combined on a natural bit boundary to form an aggregated block. 2. 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. The minimum 'IPv4 allocation unit' size will be a /24. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph B.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 3. 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. 5. 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 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. Rationale: 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 obsolete. The RIRs may already, according to their individual policies and procedures, recover IPv4 address blocks of any size. However, current policy requires IANA to make allocations to the RIRs in blocks of /8. If any blocks smaller than /8 are returned to the IANA, current policy does not provide a way to allocate that space. This policy provides a mechanism for the RIRs to return 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. The original version of Global Policy Proposal for the Allocation of IPv4 Blocks to Regional Internet Registries (ARIN policy 2009-3) was proposed in the ARIN region, discussed on the Public Policy Mailing List (PPML), and by the Advisory Council (AC). A number of concerns were expressed, mostly related to the mandatory requirement to return reclaimed space to IANA. In an attempt to alleviate some of these concerns, the AC modified 2009-3 to make the return of non-legacy space to IANA optional. This version of the proposal was discussed at the April 2009 ARIN XXIII meeting in San Antonio. During that discussion, it became clear that there was not a consensus in the ARIN region for either the original proposal, or the modified legacy-only version. As a result of subsequent discussions of the global policy at the spring AfriNIC and LACNIC meetings, it became clear that one of the reasons 2009-3 is such a difficult policy to get consensus on is that the original policy, as proposed, is a global policy proposal that has some local policy aspects, namely that requires each RIR to return reclaimed space. Ideally, global policies are supposed to maintain a clean separation from local policies: global policy is supposed to only govern the relationship between the IANA and the RIRs, and local policy defines what the RIR can do internally. As a side effect of the blurring of global and local policy in the current revision of 2009-3, ARIN (and most of the other RIRs) have been having an interesting debate about exactly which space should be covered by the policy. To sidestep this issue, the changes made to the proposal are in the 2nd paragraph of section A: "Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool." The original version read: "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." The distinction is that under the revised version of 2009-3, recovered space is returned after it is designated for return under local policies and strategies. The original text dictated the terms of what must be returned (everything /24 or larger) as part of the global policy. Since global policy is supposed to only govern the relationship between the IANA and the RIRs, and local policy defines what the RIR can do internally. This change brings the proposal more in line with that definition of a global policy, and should address a number of other concerns as well. As this is a global policy, it will need to be reconciled with the version passed in the other RIRs. As this appears to be a substantive change, that most likely means the other RIRs will need to go back and pass the modified version as well. XXXXXXXXXXXXXXXXXXXXXXXXXXXXX Below are 3 exemplar scenarios of the execution of this policy after Phase II is in force. These are not part of the rationale but are provided for illustrative purposes. Example 1: On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 3,276 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /21 (2,048 addresses). 3. Each RIR can request and receive a single allocation unit equivalent to a /21 worth of addresses. 4. While IANA may not be able to allocate a contiguous /21 and can allocate noncontiguous smaller blocks equivalent to a /21 worth of addresses. Example 2: On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 409 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /24 (256 addresses). 3. Each RIR can request and receive a single allocation unit equivalent to a /24 worth of addresses. 4. As the minimum size of address space returned to IANA is /24, IANA can allocate a contiguous range of addresses that amount to a /24. Example 3: On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 204 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /25 (128 addresses). 3. A /25 is smaller than the minimum permissible allocation size under this policy. A /25 is smaller than the minimum permissible allocation size under this policy. Therefore, IANA is unable to make an allocation until more address space is received. XXXXXXXXXXXXXXXXXXXXXXXXXXXXX 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. From info at arin.net Wed Oct 28 14:39:54 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:39:54 -0400 Subject: Draft Policy 2009-5: IPv6 Multiple Discrete Networks - Last Call Message-ID: <4AE88FFA.8020100@arin.net> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to send the following draft policy to last call: Draft Policy 2009-5: IPv6 Multiple Discrete Networks The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 November 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-5 IPv6 Multiple Discrete Networks Version/Date: 21 July 2009 Policy statement: Organizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: The organization shall be a single entity and not a consortium of smaller independent entities. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: Regulatory restrictions for data transmission, Geographic distance and diversity between networks, Autonomous multihomed discrete networks. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. The organization should notify ARIN at the time of the request their desire to apply this policy to their account. Requests for additional space: Organization must specify on the application which discreet network(s) the request applies to Each network will be judged against the existing utilization criteria specified in 6.5.2 as if it were a separate organization, rather than collectively as would be done for requests outside of this policy. Rationale: This proposed policy is suggested as NRPM 6.11. The policy is intended to provide parity between current IPv4 policy and allow discrete network operators to obtain IPv6 space. Timetable for implementation: Immediately From info at arin.net Wed Oct 28 14:40:11 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:40:11 -0400 Subject: Draft Policy 2009-6: IANA Policy for Allocation of ASN Blocks to RIRs - Last Call Message-ID: <4AE8900B.1080404@arin.net> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to send the following draft policy to last call: Draft Policy 2009-6: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 November 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-6 Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Version/Date: 31 August 2009 Policy statement: Modification of NRPM section 10.3 extending the deadline for an undifferentiated ASN pool by 1 year to read: 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 16-bit and 32-bit only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs, and will operate ASN allocations from an undifferentiated 32-bit ASN allocation pool. Rationale: a. Arguments supporting the proposal Due to operational issues external to the IANA/RIR policy process, 32-bit only ASNs are not being issued by the RIRs at the anticipated rate. As it stands, RIRs will likely not be able to justify a new block of ASNs from the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in the RIR's pool. This leaves available, essential 16-bit ASNs stranded in the IANA free pool. This proposal seeks to remedy the potential problem by extending the deadline for differentiation by one year. With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage. The subject was raised during RIPE 58 and a presentation was made: http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf The feedback in this session suggested that a global policy proposal should be developed and should be discussed. b. Arguments opposing the proposal Some may think that extending the previously set timeline can be perceived as some discouragement for the deployment of 32-bit ASNs. One counter argument to this is that RIRs and Internet community have some other mechanisms and activities to raise awareness for 32-bit ASN pool (via public presentations and trainings). These activities will continue while 16-bit ASN blocks are still allocated to RIRs by the IANA as they are available and they are needed. Timetable for implementation: Immediately upon ratification by ICANN Board From info at arin.net Wed Oct 28 14:40:52 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:40:52 -0400 Subject: Draft Policy 2009-7: Open Access To IPv6 - Last Call Message-ID: <4AE89034.8040301@arin.net> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to send a revised version of the following draft policy to last call: Draft Policy 2009-7: Open Access To IPv6 The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. The AC revised the draft. The draft policy is now limited to removing the IPv6 routing requirement from current policy. It does not change the initial IPv6 allocation criteria. However, the AC stated they intend to continue to work on that issue. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 November 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-7 Open Access To IPv6 Version/Date: 28 October 2009 Policy statement: Remove ?by advertising that connectivity through its single aggregated address allocation? from article 3 of section 6.5.1.1 Rationale: Removing the requirement for a single aggregate announcement benefits the NRPM itself, as it has been decided by the community that it should not contain routing advice. Timetable for implementation: immediately upon BoT ratification From info at arin.net Fri Oct 30 12:34:09 2009 From: info at arin.net (Member Services) Date: Fri, 30 Oct 2009 12:34:09 -0400 Subject: Policy Proposal 101: Multihomed initial allocation criteria Message-ID: <4AEB1581.8090607@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 101: Multihomed initial allocation criteria Proposal Originator: Chris Grundemann Proposal Version: 1 Date: 30 October 2009 Proposal type: modify Policy term: permanent Policy statement: Modify item number 4 under section 6.5.1.1. Initial allocation criteria to the following: 4. be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years or, if multihomed, demonstrate the efficient utilization of a minimum contiguous or noncontiguous /44 (sixteen /48s) from an upstream. Rationale: The bar for obtaining initial IPv4 allocations is lower for those ISPs which are multi-homed, it stands to reason that it also be lower in IPv6. Since efficient utilization is based on the use of /48s, this policy would effectively allow any ISP with 15 active customers (with one /48 each and one /48 for the ISPs own network) to receive an initial allocation of an IPv6 /32 from ARIN. I think this is a better approach than removing or lowering the end-site assignment requirement for _all_ ISPs while still providing more open access to IPv6. Timetable for implementation: immediate