From info at arin.net Tue Jul 21 10:42:38 2009 From: info at arin.net (Member Services) Date: Tue, 21 Jul 2009 10:42:38 -0400 Subject: Advisory Council Meeting Results - July 2009 Message-ID: <4A65D3DE.2040303@arin.net> On 16 July 2009 the ARIN Advisory Council (AC) held a meeting and made decisions about several policy proposals and draft policies. The AC selected the following proposal and promoted it to a draft policy for adoption discussion. It will be posted shortly to the PPML. Policy Proposal 84: IPv6 Multiple Discrete Networks The AC accepted the following proposals onto the AC's docket for development and evaluation: Policy Proposal 96: Transfer Listing Service Policy Proposal 97: Waiting List for Unmet IPv4 Requests The AC abandoned the following policy proposal: Policy Proposal 87: Extend 16 bit ASN Assignments The AC stated, "Proposal #87: Extend 16 bit ASN Assignments has been abandoned by the AC because the ARIN staff has now made an implementation plan to combine both sets of numbers into one pool, and issue in numerical order starting with the lowest numbers first (starting in January 2010). With this plan in place the intention of this proposal is addressed and the need for this proposal no longer exists." The AC's decision to abandon proposal 87 can be petitioned. The purpose of a petition at this stage would be to advance it as draft policy for discussion on the Public Policy Mailing List and at the October meeting. The deadline to begin a petition for this proposal is 28 July 2009. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Policy Proposal texts under discussion 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 Tue Jul 21 10:45:48 2009 From: info at arin.net (Member Services) Date: Tue, 21 Jul 2009 10:45:48 -0400 Subject: Draft Policy 2009-5: IPv6 Multiple Discrete Networks Message-ID: <4A65D49C.7050407@arin.net> Draft Policy 2009-5 IPv6 Multiple Discrete Networks On 16 July 2009 the ARIN Advisory Council (AC) selected "Draft Policy 2009-5: IPv6 Multiple Discrete Networks" for adoption discussion on the PPML and at the Public Policy Meeting in Dearborn. The draft was developed by the AC from "Policy Proposal 84. IPv6 Multiple Discrete Networks". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to selection as a draft policy. After review of the assessment the text was revised (item 5 was added to the text). The assessment, along with the original text that was assessed, is located below the draft policy. You are encouraged to discuss Draft Policy 2009-5 on the PPML prior to the ARIN XXIV 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 regarding adopting this as policy. Draft Policy 2009-5 is below and can be found at: https://www.arin.net/policy/proposals/2009_5.html 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-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: 1. The organization shall be a single entity and not a consortium of smaller independent entities. 2. 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. 3. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. 4. The organization should notify ARIN at the time of the request their desire to apply this policy to their account. 5. Requests for additional space: a. Organization must specify on the application which discreet network(s) the request applies to. b. 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 ##### Staff Assessment Proposal: IPv6 Multiple Discrete Networks Date of Assessment: 7 July 2009 Text assessed: 23 June 2009 1. Summary (Staff Understanding) This proposal would allow network operators to request /32s (ISPs) or /48s (End-users), or larger blocks as justified, for each of their discrete networks. They would first need to meet current policy criteria for initial IPv6 allocations or assignments as described in NRPM section 6.5.1 or section 6.5.8 (as appropriate). The organization must have compelling criteria to create discrete networks, must keep detailed records, and must tell ARIN at the beginning of the request that they are applying under this policy. 2. Comments A. ARIN Staff Comments * The proposal says that it is for requesting new or additional address space, but it does not include criteria for additional requests. This means that staff would likely have to revert to existing NRPM 6.5.2 criteria for requesting additional IPv6 address space. * This policy creates no significant operational impact and would require very little staff time or effort to implement. * This policy could be utilized by network operators running multiple discrete networks who in the past, may have been denied under current policy and/or forced to open multiple accounts to accomplish their goals. B. ARIN General Counsel * Counsel saw no issues with this proposal. 3. Resource Impact This policy would have minimal resource impact. It is estimated that implementation would occur within three months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines * Staff training 4. Proposal Text Proposal: IPv6 Multiple Discrete Networks Version/Date: 23 June 2009 Organizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: 1. The organization shall be a single entity and not a consortium of smaller independent entities. 2. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: a. Regulatory restrictions for data transmission, b. Geographic distance and diversity between networks, c. Autonomous multihomed discrete networks. 3. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. 4. The organization should notify ARIN at the time of the request their desire to apply this policy to their account. 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. From info at arin.net Mon Jul 27 10:35:15 2009 From: info at arin.net (Member Services) Date: Mon, 27 Jul 2009 10:35:15 -0400 Subject: Policy Proposal: Last Minute Assistance for Small ISPs Message-ID: <4A6DBB23.5040605@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. 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) ## * ## 1. Policy Proposal Name: Last Minute Assistance for Small ISPs 2. Proposal Originator: Ted Mittelstaedt 3. Proposal Version: 1 4. Date: 7/24/2009 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Under section 4.2.2. Initial allocation to ISPs Section 4.2.2.1.1 (Use of /20) will be modified to be the following: Sentence: "Until ARIN has assigned 90% of it's remaining IP addressing," will be inserted at the beginning of the paragraph. The following four paragraphs will be added: When ARIN has reached 90% allocation of it's remaining IP free pool, the minimum allocation of /20 requirement will be changed to a minimum allocation of /21 in this section and all other sections that reference the /20 minimum EXCEPT for transfers under section 8.3. When ARIN has reached 95% allocation of it's remaining IP free pool, the minimum allocation of /21 requirement will be changed to a minimum allocation of /22 in this section and all other sections that reference the /21 minimum EXCEPT for transfers under section 8.3. When ARIN has reached 97% allocation of it's remaining IP free pool, the minimum allocation of /22 requirement will be changed to a minimum allocation of /23 in this section and all other sections that reference the /22 minimum EXCEPT for transfers under section 8.3. When ARIN has exhausted all of it's remaining IP free pool, for any transfers under section 8.3, the minimum allocation size will remain at /20, in this section and all other sections that reference a minimum allocation size. It will remain at /23 for IPv4 that is voluntarily returned to ARIN. 8. Rationale: Once ARIN is no longer able to assign IPv4, there will be many smaller ISP's who never qualified for an initial allocation under section 4.2.2.1.1. of the NRPM, who are using multiple /24 assignments from an upstream provider, and who will see their costs for continuing to use IPv4 numbering from their upstreams increasing as the "market price" set by section 8.3 of the NRPM applies a price on IPv4 numbers. For example, it would be perfectly logical for a large network that observes the price of a /20 transfer under section 8.3 at $10,000 to decide to apply a yearly usage price of $600 to any /24's they have assigned to their customers. As the "transfer market" setup under section 8.3 continues to operate post IPv4 runout, and costs of yearly IPv4 assignment fees from LIR's diverge further and further from the yearly fees for allocations from the RIR's, LIR's will have small ISP's using multiple /24 assignments at an extreme disadvantage. Those small ISP's will be unable to get IPv4 from ARIN even if they qualify at some time post-runout, they will be unable to afford to pay large sums of money for transfers under section 8.3 (and likely wouldn't meet minimum utilization requirements for the blocks that would be transferred under section 8.3 even if they could), and if they go to a competitive upstream, they will be essentially "going from the frying pan to the fire". It is likely that this could force many of them out of business. What this proposal attempts to do is give those small ISP's a chance to obtain some small amount of portable numbering BEFORE IPv4 runout, so that they can use this in conjunction with NAT or other technologies post-IPv4 runout to manage until the userbase on the Internet switches to IPv6. ARIN's original rationale for setting the minimum allocation at /20 was to prevent extreme fragmentation of the dfz and prevent it from growing to impossibly large levels. This goal has been pretty much met. And when 95% of the assignable IPv4 has been handed out by ARIN under the "/20 minimum" rule, even if the rest of the IP was handed out as /24's, it won't appreciably affect fragmentation in the dfz. In addition, as the years pass post-IPv4 runout, and organizations search around for available IPv4 it's logical to assume that many more small allocations that were assigned as "legacy" assignments, and are currently idle, will be found and put into use - policy should discourage this and encourage them to be returned to ARIN to be aggregated with other small allocations. Post IPv4 runout, the Internet should be transitioning to IPv6, this policy should therefore be regarded primarily as a stopgap to help small ISP's over the hump. The small ISPs will still be required to show that they can make efficient utilization of their requested block, still be required to pay fees and meet all the other obligations any org must meet. The only thing that changes is lowering the minimum limit. 9. Timetable for implementation; immediate