From info at arin.net Mon Jun 1 13:53:10 2009 From: info at arin.net (Member Services) Date: Mon, 01 Jun 2009 13:53:10 -0400 Subject: [arin-announce] =?windows-1252?q?Call_for_Community_Consultation_?= =?windows-1252?q?=96_ARIN=92s_DNSSEC_Deployment_Plan?= Message-ID: <4A241586.7080104@arin.net> ARIN has published a proposed plan for DNSSEC deployment and is seeking community review and comment. The document is available at https://www.arin.net/about_us/dnssec/. Please submit your comments to the consult at arin.net. You can subscribe to the arin-consult mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult. Discussion on consult at arin.net will close at noon EDT 16 June 2009. Based on the feedback provided, ARIN will update the deployment plan as needed with deployment currently planned for 1 July 2009. The ARIN Consultation and Suggestion Process documentation is available at: https://www.arin.net/participate/acsp/index.html All are welcome to participate. Please address any process questions to info at arin.net. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jun 1 15:37:26 2009 From: info at arin.net (Member Services) Date: Mon, 01 Jun 2009 15:37:26 -0400 Subject: [arin-announce] =?windows-1252?q?NRPM_2009=2E3_=96_New_Policy_Imp?= =?windows-1252?q?lemented_=28Transfers=29?= Message-ID: <4A242DF6.2080904@arin.net> A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2009.3 contains the implementation for the following policy: ? 2009-1: Transfer Policy At their meeting on 6 February 2009, the ARIN Board of Trustees adopted 2008-6: Emergency Transfer Policy for IPv4 Addresses. The Board delayed implementation of 2008-6 pending the outcome of 2009-1. 2009-1 came from the Board?s use of the Special Policy Action section of the ARIN Policy Development Process. 2009-1 was first posted to Public Policy Mailing List for discussion on 24 March 2009. It was presented at ARIN XXIII in San Antonio. Based on the feedback from the community on the PPML and at the Public Policy Meeting, the ARIN Advisory Council (AC) created a revised version of 2009-1 and recommended their version to the Board for adoption. On 28 May 2009 the Board, based on the recommendation of the AC and noting that the Policy Development Process had been followed, adopted 2009-1: Transfer Policy as amended by the AC. The Board directed staff to implement the policy on 1 June 2009. The implementation of 2008-6 has been replaced by 2009-1. 2009-1 will be presented at the next Public Policy Meeting for reconsideration as required by the Policy Development Process (PDP Part Two, Section 7.1). NRPM version 2009.3 is effective 1 June 2009 and supersedes the previous version. See the Change Log for information regarding revisions to the manual. For more information about transfers, please see the guidelines at: https://www.arin.net/resources/request/transfers.html The NRPM is available at: https://www.arin.net/policy/nrpm.html The Change Log is available at: https://www.arin.net/policy/nrpm_changelog.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The PDP is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Jun 4 11:21:58 2009 From: info at arin.net (Member Services) Date: Thu, 04 Jun 2009 11:21:58 -0400 Subject: [arin-announce] Policy Proposal: Sunset Clause for Liberalized Transfer Policy Message-ID: <4A27E696.7030605@arin.net> Please be advised that the following policy proposal has been posted to the ARIN Public Policy Mailing List. All discussion of the proposal must take place on the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Sunset Clause for Liberalized Transfer Policy Proposal Originator: Owen DeLong Proposal Version: 1.0 Date: 4 June 2009 Proposal type: delete Policy term: permanent Policy statement: Section 8.3, "Transfers to Specified Recipients", of the NRPM is deleted upon the effective date of this policy. Rationale: When the community reached consensus in support of 2008-6, it contained a sunset clause. In the process of developing 2009-1, the sunset clause was removed. The effect of this policy proposal is to restore the sunset clause while adopting a more rational date at which to sunset the policy. Timetable for implementation: 31 December, 2013 or 3 years after IANA issues the last /8s to the RIRs, whichever is later. From info at arin.net Fri Jun 5 13:37:05 2009 From: info at arin.net (Member Services) Date: Fri, 05 Jun 2009 13:37:05 -0400 Subject: [arin-announce] Policy Proposal: A Modest Proposal for an Alternate IPv6 Allocation Process Message-ID: <4A2957C1.8020609@arin.net> Please be advised that the following policy proposal has been posted to the ARIN Public Policy Mailing List. All discussion of the proposal must take place on the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 1. Policy Proposal Name: A Modest Proposal for an Alternate IPv6 Allocation Process 2. Proposal Originator: William Herrin 3. Proposal Version: 1.0 4. Date: 5 June 2009 5. Proposal type: new 6. Policy term: See 6.11.7 below. 7. Policy statement: Add section 6.11 as follows: 6.11 Alternate IPv6 allocation process Section 6.11 offers an alternative to the address assignment process laid out in sections 6.5 and 6.10. Except where explicitly mentioned, no elements of the process here are binding on the process in those sections and vice versa. 6.11.1 ARIN pools used for allocation. ARIN shall reserve 3 pools of IPv6 addresses for the purpose of address allocation under section 6.11. The first pool shall be used solely for making /48 allocations. ARIN will make no larger or smaller allocations from this pool. The second pool shall be used solely for making /32 allocations. ARIN will make no larger or smaller allocations from this pool. The third pool shall be used solely for making /24 allocations. ARIN will make no larger or smaller allocations from this pool. ARIN shall publish the locations of these pool such that folks operating routers in the Internet Default-Free Zone can filter route announcements based on these published sizes if they so choose. 6.11.2 Initial allocation 6.11.2.1 Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a. Be multihomed in the ARIN region with at least two different Internet Service Providers, both of whom agree to propagate the organization's IPv6 prefix into the Internet Default-Free Zone. b. Have already obtained an Autonomous System Number. c. Do not already hold a /48 or shorter IPv6 allocation from ARIN under any current or prior policy. d. If requesting a /32, hold at least a /18 of IPv4 addresses e. If requesting a /32, have implemented either SWIP or RWHOIS for all IPv4 allocations /28 or shorter. 6.11.2.2 Initial allocation size If requested, a /32 from the pool reserved for assigning /32's. Otherwise a /48 from the pool reserved for assigning /48's. 6.11.3 Extra /32 allocation Organizations which hold a /48 from ARIN are eligible for an additional /32 allocation from the pool reserved for /32 allocations if they: a. Demonstrate that they continue to meet the qualifications for the /48 assignment. b. Do not already hold a /32 or shorter allocation from ARIN under any current or prior policy. c. Plan to provide IPv6 service such that they will run out of space in the /48 within one year of making the second application. d. Have implemented either SWIP or RWHOIS for all downstream allocations shorter than /64. e. Agree to return all ARIN allocations longer than /33 except for one /48 allocation to ARIN within one year of receiving the /32 allocation. Although 6.11.2 permits only one /48 allocation to an organization (hence no need to return anything), they may hold more than one due to mergers, acquisitions, policy changes, etc. These extras must be removed from the DFZ BGP table and returned to ARIN once a /32 is assigned. 6.11.4 Extra /24 allocation Organizations which hold a /32 from ARIN are eligible for an additional /24 allocation from the pool reserved for /24 allocations if they: a. Demonstrate that they continue to meet the qualifications for the /32 assignment. b. Do not already hold a /24 or shorter allocation from ARIN under any current or prior policy. c. Plan to provide downstream IPv6 service with address space such that they will run out of space within the /32 within two years of making the third application. d. Return all /33 or longer allocations to ARIN prior to making the /24 application. e. Agree to return all allocations longer than /25 except for one /32 allocation to ARIN within one year of receiving the /24 allocation. 6.11.5 Additional allocations No additional allocation beyond the single /24 is contemplated for a single organization at this time. No known usage pattern could require more than a /24 of IPv6 address space without egregious waste. 6.11.6 Advice to multihomed users ARIN advises multihomed end-users that section 6.11 has been intentionally crafted to enable folks operating routers in the Internet Default-Free Zone to filter out route announcements longer than /48 within the /48 pool, longer than /32 within the /32 pool and longer than /24 within the /24 pool. Accordingly, it is probable that addresses assigned by an ISP instead of by ARIN will only be usable with that one ISP. 6.11.7 Policy term and re-evaluation Three years from policy implementation, ARIN staff and the ARIN advisory council shall separately review the efficacy of address allocations made under both section 6.11 and sections 6.5 plus 6.10. Each shall recommend to the ARIN Board of Trustees that either 6.11 or both 6.5 and 6.10 be struck from the NRPM. The board shall review the recommendations and either strike section 6.11, strike both sections 6.5 and 6.10, or take no action, retaining both policies. 8. Rationale: The IPv6 allocation policy under section 6.5 makes a number of unproven assumptions about how IPv6 will work. Unproven: we can make a reasonable guess about how many IPv6 subnets an organization will need at the outset when they first request IP addresses. When in all of human history has this ever proven true of any resource? Unproven: with sparse allocation, we can allow organizations to expand by just changing their subnet mask so that they don't have to announce additional routes into the DFZ. This claim is questionable. With sparse allocation, we either consume much larger blocks that what we assign (so why not just assign the larger block?) or else we don't consume them in which case the org either has to renumber to expand or he has to announce a second route. Worse, because routes of various sizes are all scattered inside the same address pool, its impractical to detect or filter out the traffic engineering routes. Unproven: we can force organizations not to disaggregate for traffic engineering purposes. Neither any of our experience with IPv4 nor any of the research in the IRTF Routing Research Group suggests that this is even remotely practical so long as BGP or any similar system rules the roost. Unproven: all non-ISPs can be reasonably expected to get their address space from ISPs instead of from ARIN. We can certainly operate that way, but it could prove deadly to the routing table. Any organization mutlihomed between two ISPs will need to announce that route via BGP, regardless of where they get the address space from. We have knobs and dials in the routers that let us easily filter disagregates from distant announcements, but we don't dare do so if there is a possibility that one of those disaggregates is a multihomed customer rather than traffic engineering. Benefits of this proposal: A. Efficient allocation of IP addresses. Orgs get what they need when they need it and not before without a great deal of guesswork trying to define that need. B. Efficient utilization of BGP routing slots. Few multihomed orgs will ever announce more than two unfilterable routes. C. Traffic engineering routes are trivially filterable. Any route longer than the published allocation size can be presumed to be traffic engineering, not a downstream multihomed customer, thus you can filter distant small routes with confidence and ease. D. Fair. No need to define the difference between ISP and not ISP. Everybody plays by the same rules. E. No complicated analysis for the first allocation. You're either multihomed or you're not. If you're multihomed, you qualify. F. For those who can live within the /48 there are distinct advantages: no swip or rwhois reporting and the generic end-user annual fee instead of the ISP annual fee. Once you're up to a /32, you pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize the /32 requests too closely either. G. No disruption to the prior IPv6 allocation policy until this new one proves itself. FAQ Q. Isn't this classful addressing all over again? A. Yes, with a twist. Now you have to fully use a class C before you can get a class B and fully use a class B before you can get a class A. And by the way, there are potentially 16 million class A's, not a mere 200. Classful addressing had a lot of virtues with respect to route filtering and management. We had to abandon it because there weren't enough B's for everyone who needed more than one C and there weren't enough A's period. With IPv6, we don't have that problem. Not yet and maybe not ever. Perhaps we can have our cake and eat it too. Q. Why prevent single-homed users from getting ARIN addresses? A. Any IPv6 allocation from ARIN must be announced into the Internet DFZ via BGP in order to use it on the Internet. That costs a lot of money, more than $10k per year according to http://bill.herrin.us/network/bgpcost.html Worse, it spends other people's money: no practical system exists for recovering the cost of a consumed routing slot from the folks who announced the route. If you don't get an allocation from ARIN then you have to renumber in order to change ISPs. That can cost a lot of money too. Sometimes far more than $10k. But it spends only your money, not somebody else's. Finally there's the technical consideration: regardless of who assigns the addresses, a multihomed system must announce a route into the DFZ. That's the way BGP works and we're stuck with it for at least another decade. So why not let the multihomed org get his IP addresses from ARIN? By contrast, a single-homed system works just fine with its addresses aggregated inside the shorter route announced by its ISP. Q. If it's so expensive to announce routes into the DFZ, why not use something better than BGP? A. Last year the IRTF Routing Research Group compiled an exhaustive study attempting to identify the possible ways to improve the routing system. A draft of the results is at http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While there are many promising ideas for how to replace BGP with something that scales better, we're at least a decade away and probably more from any significant deployment of a BGP replacement. Q. Is it really true that multihoming requires announcing a route via BGP? A. The short answer is yes, its true. The long answer is more complicated. Folks have tried very hard to devise multi-vendor multihomed systems which don't rely on BGP. Some even work OK for networks containing no Internet servers. The only non-BGP approach that has ever come close to success for a system that hosts Internet servers is dynamically changing DNS records to favor the currently working Internet connection. "Close" is a relative term here. Such network architectures are enormously complex and they don't work for a useful definition of "work." The DNS protocol itself supports quick changes but the applications which use it often don't. It takes hours to achieve two-nines recovery from an address change in the DNS and it takes months to achieve five-nines recovery. Web browsers, for example, don't immediately recover. Search google for "DNS Pinning." Q. Why allocate the /48's from a pool only for /48's, /32's from a /32 pool, etc.? Why not allocate from just one pool? A. If all assignments in a particular pool are /32 and all multihomed entities get their IP addresses directly from ARIN then any route in the /32 pool which is longer than /32 is a traffic engineering route. As a router operator you can filter and discard a traffic engineering routes if you find they give you insufficient benefit. The routes you filter don't cost you any money; only the routes you keep carry a price tag. You can only filter if you're sure they're traffic engineering routes... If they're downstream customer routes and you filter them, there goes the Internet. Or at least there goes your part of it. See customers. See customers run... straight to your competitor. Setting up the distinct pools makes it practical to know for certain that the routes you're filtering are only for TE. Q. Why make folks return all but one /48 to get a /32 and all but one /32 to get a /24? A. Without the address scarcity issue which drives IPv4 policy, the primary criteria for IPv6 addressing policy is suppressing the route count in the IPv6 DFZ. Such a criteria is not well served if an organization holds dozens of discontiguous address spaces as a result of acquisitions, mergers and the like. With the return policy in place, organizations will generally only announce one or two primary routes, routes necessary for the correct operation of the Internet. Any other announced routes will be for traffic engineering. Because of the segregated pools from which the allocations come, those traffic engineering routes can be filtered by anyone who gains insufficient advantage from them without harming the Internet as a whole. The return policy does require some renumbering activity. However, with only modest planning on the registrant's part, the policy is flexible enough to allow that renumbering to occur over a long period of time so that both cost and disruption are minimized. In many cases, customer churn can be expected to take care of much of the renumbering activity all by itself. Q. What if the first allocation from the /48 is a /48? A. RFC 3177 recommends that downstream customers receive a /48 assignment by default. Obviously there's a mismatch here if the ARIN allocation is also a /48. The short version is that RFC 3177 is not the gospel truth. It's based on the IPv6 allocation model embodied in ARIN policy section 6.5 where we try very hard to assign all the addresses you'll ever need up front so that you only ever use one routing slot. This proposal attempts to slow-start IPv6 allocations instead, while still maintaining the principle of suppressing the routing table size. With a /48 allocation under this proposal, consider implementing a slow start for your downstream customers as well: Give them a /60 initially, add a /56 when they need it and add a /52 when they run out of the /56. There are 16 /52's in your /48, or 4000 /60's. Plenty to get started. And a /60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. Q. What happens when organizations merge or split? A. Entities which merge will want to renumber out of and return one of the allocations so that they don't run into grief when they go to get the next larger allocation from ARIN. If done gradually, this should be a minor hardship. Entities which split have a bigger problem since only one of them can keep the addresses. To a large extent, that problem already exists and is a pain in the rump for IPv4 operations today. This policy doesn't solve it but it doesn't make it a whole lot worse either. Because disaggregates are expected to be filtered, this IPv6 policy does gives us a slightly better guarantee that the rest of us won't get stuck with the check (in the form of routing slot consumption) when an ISP goes bankrupt and gets split up. Q. Why allow folks announcing IPv4 /18's to jump straight to a /32? A. We're not really starting from scratch here and there are plenty of IPv6 addresses. Why make extra useless work for large ISPs who -are- going to use more than a /48? There are far fewer than 30k orgs holding /18s. How much grief should we cause them in order to save at most one whole /25? Q. Why not just replace section 6.5 instead of running this allocation system in parallel? A. The most experienced user of IPv6 still has only a fraction of the experience that we have with IPv4. Yet the network operating model proposed by the IETF is radically different than the IPv4 model. The author believes that the IETF recommendation is based on an errant operating model, but he respects those who believe otherwise. The author also believes that competition is a good thing and history backs up this claim. Since little long term harm can come from briefly running both systems in parallel, allowing them to compete directly will result in the selection of the superior system. Q. You've covered multihomed and single-homed. What about IPv6 addresses for uses which will not be connected to the Internet at all? A. "ULA Central" or an idea like it is not addressed in this policy proposal. If desired, it should probably be implemented in a separate, parallel policy. The author observes that all of 2002:0a00::/24 is available for your offline use and there are plenty of others if you don't like that one. Implementation notes: Initially, ARIN may want to use sparse allocation inside each of the three reserved pools until the policies are re-evaluated in three years. That way if section 6.11 is retired in favor of section 6.5, the 6.11 assignments may be able to grow by changing the netmask as intended in section 6.5. If 6.11 is retained, sparse allocation should cease. Because IPv6 addresses are plentiful and the largest possible allocation under this policy is /24, the author recommends against explicit criteria for efficiency at this time. Instead, ARIN should consider selecting a fee schedule for /48, /32 and /24 allocations which discourages asking for more addresses than are really needed. Something along the lines of $100, $10k and $100k per year respectively might do nicely. Under this proposal there is no difference whatsoever between an allocation and an assignment. The two words should be treated as synonyms. 9. Timetable for implementation: immediate; re-evaluate in 3 years From info at arin.net Mon Jun 8 15:11:17 2009 From: info at arin.net (Member Services) Date: Mon, 08 Jun 2009 15:11:17 -0400 Subject: [arin-announce] Policy Proposal: Predicable IPv4 Run Out by Prefix Size Message-ID: <4A2D6255.7050204@arin.net> Please be advised that the following policy proposal has been posted to the ARIN Public Policy Mailing List. All discussion of the proposal must take place on the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 1. Policy Proposal: Predicable IPv4 Run Out by Prefix Size 2. Proposal Originator: David Farmer 3. Proposal Version: 1.0 4. Date: 8 June 2009 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Create a new subsection in section 4 of the NRPM; 4.X Maximum Allocation or Assignment during and after Run-Out When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a maximum allocation and assignment size will be put into effect. The maximum allocation or assignment will be the next whole CIDR prefix less than or equal to one quarter (1/4) of the total unrestricted IPv4 resources available to ARIN for allocation or assignment at the time, but no longer than the applicable minimum allocation or assignment. All other allocation and assignment rules, requirements, or procedures apply in addition. If this maximum allocation or assignment provides insufficient resources, additional resources may be request after a three (3) month waiting period. This section (4.x) is applicable to allocations and assignments from ARIN's unrestricted IPv4 resources only, and is explicitly not applicable to resources received through Transfers to Specified Recipients per section 8.3, or any other specially designated resources. 8. Rationale: This proposal is intended to insure an equitable distribution of the remaining unrestricted IPv4 number resources available to ARIN once such resources are no longer abundantly available from IANA. Equity is achieved by insuring the available resources are spread among multiple entities and that no single entity may monopolize all of the resources available through a single request, at least until the maximum equals the minimum allocation or assignment size. Reducing the maximum allocation or assignment size in proportion to the amount of resources available should minimize, or possibly eliminate, the need to fulfill requests with multiple smaller blocks. Beyond providing predictability and order during the run out phase, this proposal provides an equitable means of distribution of resources if or when additional resources become available after ARIN has initially exhausted such resources. Such as if resources are returned, recovered by other means, or further resources are obtained from IANA. Other ratios, such as one half (1/2) or one eighth (1/8) could be considered. One eighth (1/8) would provide greater assurance of eliminating the need to use multiple blocks to fulfill requests and insure a greater number of entities receive resources. However, one eighth (1/8) is more likely to be seen as rationing and an attempt to artificially extend the lifetime of IPv4. During the ARIN XXIII policy discussion there seemed to be a consensus that attempts to extend the lifetime IPv4 resources would be undesirable. While on the other hand, one half (1/2) is less likely to ration the resources, it would likely result in the resource being spread across significantly fewer entities and increase the need to use multiple blocks to fulfill requests. Therefore, the ratio one quarter (1/4) is proposed as a compromise between competing sets of goals. 9. Timetable for implementation: Immediate From info at arin.net Mon Jun 8 15:55:28 2009 From: info at arin.net (Member Services) Date: Mon, 08 Jun 2009 15:55:28 -0400 Subject: [arin-announce] Policy Proposal: Predictable IPv4 Run Out by Allocation Window Message-ID: <4A2D6CB0.2040606@arin.net> Please be advised that the following policy proposal has been posted to the ARIN Public Policy Mailing List. All discussion of the proposal must take place on the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 1. Policy Proposal: Predictable IPv4 Run Out by Allocation Window 2. Proposal Originator: Leo Bicknell 3. Proposal Version: 1.0 4. Date: 8 June 2009 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Replace the text in NRPM 4.2.4.4 with: After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses. Starting on 1 July 2010, a gradual reduction in the allocation period will be applied as follows: As of 1 July 2010, they may choose to request up to a 9 month supply. As of 1 January 2011, they may choose to request up to a 6 month supply. As of 1 July 2011, they may choose to request up to a 3 month supply. 8. Rationale: During the ARIN XXIII policy discussion several individuals described ideas similar to RIPE policy proposal 2009-03 (http://www.ripe.net/ripe/policies/proposals/2009-03.html). This policy adapts the same idea into an ARIN policy for discussion in this region. From the RIPE proposal: ] This is a proposal to gradually reduce the allocation and assignment ] periods in step with the expected life time of the IPv4 unallocated ] pool in order to address the perception of unfairness once the pool ] has run out. ] ] The proposal is not intended to stretch the lifetime of the ] unallocated pool. ] ] The proposal is independent of other proposals to reserve address ] space for transition purposes and/or new entrants. It can be ] implemented independently of these. 9. Timetable for implementation: Immediate From info at arin.net Tue Jun 9 08:56:13 2009 From: info at arin.net (Member Services) Date: Tue, 09 Jun 2009 08:56:13 -0400 Subject: [arin-announce] Policy Proposal: Customer Confidentiality Message-ID: <4A2E5BED.3060900@arin.net> Please be advised that the following policy proposal has been posted to the ARIN Public Policy Mailing List. All discussion of the proposal must take place on the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 1. Policy Proposal Name: Customer Confidentiality 2. Proposal Originator: Aaron Wendel 3. Proposal Version: 1.0 4. Date: 9 June 2009 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: ISPs may choose to enter their own address and phone number in reassignments and reallocations in lieu of the customer's address and phone number. The customer's actual information must be provided to ARIN on request and will be held in the strictest confidence. 8. Rationale: Customer contact lists are one of the most proprietary and confidential pieces of information in any business. The requirements for ISPs to publish those lists via SWIP or RWHOIS runs contrary to good business practices and invites competitors and others to solicit both individuals and companies receiving reassignments and sub allocations from upstream providers. 9. Timetable for implementation: immediate From info at arin.net Fri Jun 12 10:50:34 2009 From: info at arin.net (Member Services) Date: Fri, 12 Jun 2009 10:50:34 -0400 Subject: [arin-announce] Policy Proposal: Transfer listing service Message-ID: <4A326B3A.6000406@arin.net> Please be advised that the following policy proposal has been posted to the ARIN Public Policy Mailing List. All discussion of the proposal must take place on the PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 1. Policy Proposal Name: Transfer listing service 2. Proposal Originator: Scott Leibrand 3. Proposal Version: 1.0 4. Date: 6/11/2009 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Add new subsection 8.3.1: 8.3.1 Listing service ARIN will develop and operate a listing service to provide a Centralized location to post information about IPv4 blocks available from Authorized resource holders and IPv4 blocks needed by potential transfer recipients. Participation in the listing service is voluntary. 8. Rationale: The proposal would have ARIN develop and operate a listing service to facilitate transfers and provide an authoritative central source of information on space available and requested for transfer. It would still allow private party transactions, but would encourage both parties to begin working with ARIN in advance, which will cut down on any surprises when they ask ARIN to process the transfer. ARIN staff has indicated that they do not intend to provide a listing service as a part of their implementation of the 2009-1 transfer policy, but could do so if directed by additional policy. 9. Timetable for implementation: Immediate (as soon as practical). From info at arin.net Fri Jun 12 13:27:12 2009 From: info at arin.net (Member Services) Date: Fri, 12 Jun 2009 13:27:12 -0400 Subject: [arin-announce] Policy Proposal: Waiting list for unmet IPv4 requests Message-ID: <4A328FF0.7020106@arin.net> Please be advised that the following policy proposal has been posted to the ARIN Public Policy Mailing List. All discussion of the proposal must take place on the PPML Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 1. Policy Proposal Name: Waiting list for unmet IPv4 requests 2. Proposal Originator: Scott Leibrand 3. Proposal Version: 1.0 4. Date: 6/11/2009 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Replace 4.1.6 with: 4.1.6. Aggregation In order to preserve aggregation, ARIN issues blocks of addresses on appropriate "CIDR-supported" bit boundaries. ARIN will make all allocations and assignments as a single continuous range of addresses. Add new section 4.1.8: 4.1.8 Unmet requests In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to either modify their request and request a smaller size block, or be placed on a waiting list of pre-qualified recipients. Repeated requests, in a manner that would circumvent 4.1.6, are not allowed. Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. 4.1.8.1 Waiting list The position of each qualified request on the waiting list will be determined by the date it was approved. ARIN may provide a validity duration on each qualification, in which case the requester may renew their request prior to its expiration to preserve their position on the waiting list. Each organization may have one approved request on the waiting list at a time. Any requests met through a transfer will be removed from the waiting list. 4.1.8.2 Fulfilling unmet needs As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block. Requests will not be partially filled. 8. Rationale: ARIN will soon be unable to meet all approved requests for IPv4 address space. In the absence of a policy like this, it is unclear what ARIN should do with subsequent requests. This policy would allocate reclaimed address blocks (and the last of the ARIN free pool) on a first-come-first-served basis, while preserving aggregation to the degree possible. As the free pool shrinks, requests larger than the largest block left would be placed on a waiting list, while smaller requests would use up the rest of it, until all requests have to go on the waiting list. As additional reclaimed addresses become available, the requests that have been waiting the longest would be met first. If a requester gets the addresses they need via transfer, then they would be removed from the waiting list and would need to wait and submit a new request for additional address space, either directly or via transfer. This policy does not attempt to ration addresses, define maximum allocations, or otherwise manage how much address space any given organization may request. As such, it is completely independent of any "Predictable IPv4 Run Out" proposals. 9. Timetable for implementation: Immediate. From info at arin.net Wed Jun 17 14:02:54 2009 From: info at arin.net (Member Services) Date: Wed, 17 Jun 2009 14:02:54 -0400 Subject: [arin-announce] ARIN Elections: Call for Nominee Questions Message-ID: <4A392FCE.5050809@arin.net> In October 2009 ARIN will hold elections for open seats on the ARIN Board of Trustees, ARIN Advisory Council, and NRO Number Council. To prepare for these elections we are opening the floor for Community "Ask the Nominee" questions! If you have questions on relevant policy issues and challenges facing ARIN that you?d like candidates to answer, send them to info at arin.net no later than 15 July 2009. Please indicate if your question is directed to candidates for the Board, Advisory Council, NRO Number Council or any combination of the three. The Nomination Committee (NomCom) will determine the final list and phrasing of all questions. The NomCom may solicit additional input from eligible voters on the final set of questions for Board, Advisory Council, and NRO Number Council nominees. ARIN will publish candidate bios and their questionnaire responses when the slate of candidates is announced. The current questionnaires may be viewed at: https://www.arin.net/participate/elections/ac.html#accv https://www.arin.net/participate/elections/board.html#botcv https://www.arin.net/participate/elections/nronumbercouncil.html#nccv The 2009 election schedule is available on the ARIN website at: https://www.arin.net/participate/elections/elec_calendar.html The page includes links to other election-related information.The Call for Nominations will be issued on 27 July. We look forward to your input. If you have any questions concerning the election process please contact us at info at arin.net or submit your question through your web account. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jun 22 12:10:22 2009 From: info at arin.net (Member Services) Date: Mon, 22 Jun 2009 12:10:22 -0400 Subject: [arin-announce] Consultation Closed: ARIN's DNSSEC Deployment Plan Message-ID: <4A3FACEE.4060702@arin.net> ARIN thanks the community for its input regarding DNSSEC deployment. Based on the limited feedback, ARIN plans to move forward with its 1 July 2009 deployment schedule. The plan document remains available at: https://www.arin.net/about_us/dnssec/ The archives of this discussion are available at: http://lists.arin.net/pipermail/arin-consult/ Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jun 22 16:23:12 2009 From: info at arin.net (Member Services) Date: Mon, 22 Jun 2009 16:23:12 -0400 Subject: [arin-announce] ARIN Hosts 4-byte ASN Wiki Message-ID: <4A3FE830.9060208@arin.net> In response to a suggestion received through the ARIN Consultation and Suggestion Process (ACSP), ARIN has created a wiki at www.get4byteasn.info to focus on issues related to 4-byte Autonomous System Numbers (ASNs). This wiki provides a central repository for ongoing discussion and information exchange associated with 4-byte ASN topics and issues. Ongoing Internet growth is rapidly depleting the existing pool of 2-byte ASNs (65,536 numbers in total). As a result, the IETF has approved the expansion of AS Numbers from 2-bytes to 4-bytes, to include over 4 billion ASNs. Following a globally coordinated policy, ARIN and the other Regional Internet Registries began assigning 4-byte ASNs by request in January 2007 and by default in January 2009. However, some routers do not support the use of these 4-byte ASNs. ARIN has set up this wiki to help educate the community about 4-byte ASN operational issues, to help vendors understand how to provide 4-byte ASN support in their products and to help network operators find those products. A wide range of community stakeholders will be able to share and benefit from information contributed to www.get4byteasn.info. ARIN looks forward to participation from everyone, including users, ISPs, and vendors, with interest in this topic. Regards, Leslie Nobile Director of Registration Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jun 22 16:47:04 2009 From: info at arin.net (Member Services) Date: Mon, 22 Jun 2009 16:47:04 -0400 Subject: [arin-announce] ARIN-Issued Daily Report Now Permanent Message-ID: <4A3FEDC8.5010409@arin.net> ARIN is pleased to announce it will continue to offer the ARIN-issued daily report service. On 2 January, ARIN implemented ACSP Suggestion 2008.2 - Tracking Address Blacklists and began publishing a daily report of addresses returned and addresses issued to a subscriber mailing list and an RSS feed. The reporting service was originally available on a trial basis. ARIN has determined that it will continue to offer this service to the community. This report contains only allocations/assignments made directly by ARIN or address blocks returned to ARIN's free pool. To subscribe complete the form at: http://lists.arin.net/mailman/listinfo/arin-issued or, send mail to arin-issued-subscribe at arin.net with the word "subscribe" in the body of the message. Further instructions can be found at: http://www.arin.net/participate/mailing_lists/index.html To utilize to the RSS feed, point your rss reader to: http://lists.arin.net/pipermail/arin-issued/rss.xml The format of the report is as follows: - Regards, Member Services American Registry for Internet Numbers (ARIN)