From info at arin.net Tue Nov 3 15:53:41 2009 From: info at arin.net (Member Services) Date: Tue, 03 Nov 2009 15:53:41 -0500 Subject: [arin-announce] =?windows-1252?q?New_ARIN_Education_Multimedia_?= =?windows-1252?q?=96_Internet_Governance?= Message-ID: <4AF09855.6060109@arin.net> ARIN is proud to announce a new Flash-based primer on Internet governance, titled: Introduction to Managing Internet Number Resources. This presentation offers a brief history of how the process for managing Internet number resources has evolved and why individual participation in these community-driven governance methods is critical to the future growth and health of the Internet. This is available at: https://www.arin.net/knowledge/managing_resources/ ARIN strives to provide these types of resources that advance our mission to facilitate the advancement of the Internet through information and educational outreach. We hope you enjoy it, and if you have suggestions for other educational materials, please send them to info at arin.net. Regards, Member Services American Registry for Internet Numbers From info at arin.net Wed Nov 4 10:10:52 2009 From: info at arin.net (Member Services) Date: Wed, 04 Nov 2009 10:10:52 -0500 Subject: [arin-announce] Consultation Closed: Retiring ARIN E-mail Templates Message-ID: <4AF1997C.9050006@arin.net> ARIN appreciates the extensive community response to this suggestion, and as a result ARIN will plan continued support for e-mail templates to make registry changes. ARIN will also continue to explore new and improved technologies that could provide alternatives to the e-mail-based SWIP processing, and periodically will consult with the community for guidance as these alternatives gain popular support. 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 Wed Nov 4 14:28:59 2009 From: info at arin.net (Member Services) Date: Wed, 04 Nov 2009 14:28:59 -0500 Subject: [arin-announce] ARIN XXIV Meeting Report Now Available Message-ID: <4AF1D5FB.1080105@arin.net> From 21-23 October, the ARIN community took part in the ARIN XXIV Public Policy and Members Meeting, held in Dearborn, Michigan. The meeting report, including presentations, summaries, and transcripts of the proceedings, is now available at: https://www.arin.net/participate/meetings/reports/ARIN_XXIV/ An archive of the meeting's webcast will be available as part of the report next week. We thank Arbor Networks and Merit Network Inc. for their generous sponsorship of network connectivity for the meeting, and everyone in the community who participated in person or remotely and those who responded to the surveys. We look forward to seeing you 18-21 April 2010 for ARIN XXV in Toronto, Ontario. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Nov 5 10:46:16 2009 From: info at arin.net (Member Services) Date: Thu, 05 Nov 2009 10:46:16 -0500 Subject: [arin-announce] 2009 ARIN Board of Trustees and Advisory Council Election Results Message-ID: <4AF2F348.6010108@arin.net> Paul Andersen has been elected and Scott Bradner has been re-elected to the ARIN Board of Trustees. Each will serve a three-year term commencing 1 January 2010. Lee Howard has also been re-elected and will continue to fill the vacancy created by Bill Manning's resignation. He will serve a one-year term commencing 1 January 2010. The ARIN Board of Trustees congratulates Paul, Scott, and Lee. The Board thanks Aaron Hughes and Frederick Silny for their participation as candidates in the election and encourages their continued participation in the ARIN community. ARIN would also like to congratulate the individuals elected to the ARIN Advisory Council: Chris Morrow and Bill Sandiford have been elected, and Stacy Hughes, Heather Schiller, and Rob Seastrom have been re-elected. All five will serve three-year terms commencing 1 January 2010. The ARIN Board of Trustees wishes to thank Mark Bayliss, John Brown, Rudolf Daniel, Steve Feldman, Wes George, Chris Grundemann, Kevin Hunt, Mark Johnson, Ed Kern, Christopher Savage, Scott Weeks, and Tom Zeller for their participation as candidates in the election and looks forward to their continued involvement in ARIN's activities. The vote totals for this election are available at: https://www.arin.net/announcements/2009/20091105.html Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) From info at arin.net Thu Nov 5 13:49:32 2009 From: info at arin.net (Member Services) Date: Thu, 05 Nov 2009 13:49:32 -0500 Subject: [arin-announce] [Fwd: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations] Message-ID: <4AF31E3C.3050802@arin.net> The following is a new policy proposal that has been posted to the ARIN Public Policy Mailing List for discussion on that list. Regards, Member Services American Registry for Internet Numbers (ARIN) -------- Original Message -------- Subject: [arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations Date: Thu, 05 Nov 2009 13:46:45 -0500 From: Member Services To: arin-ppml at 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 102: Reduce and Simplify IPv4 Initial Allocations Proposal Originator: Chris Grundemann & Ted Mittelstaedt Proposal Version: 1 Date: 5 November 2009 Proposal type: modify Policy term: permanent Policy statement: Modify section 4.2.1.5. Minimum allocation: In general, ARIN allocates IP address prefixes no longer than /23 to ISPs. If allocations smaller than /23 are needed, ISPs should request address space from their upstream provider. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose whenever that is feasible. And Replace the contents of section 4.2.2. Initial allocation to ISPs: 4.2.2.1. Use of /24 The efficient utilization of an entire previously allocated /24 from their upstream ISP. 4.2.2.2. Efficient utilization Demonstrate efficient use of IP address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWHOIS server or by using the table format described in Section 4.2.3.7.5. 4.2.2.3. Three months Provide detailed information showing specifically how the initial allocation will be utilized within three months. 4.2.2.4. Renumber and return ISPs receiving an initial allocation smaller than /20 must agree that the newly requested IP address space will be used to renumber out of the current addresses which will be returned to the assigning organization within 12 months. ISPs receiving an initial allocation equal to or larger than /20 may wish to renumber out of their previously allocated space. In this case, an ISP must use the new prefix to renumber out of that previously allocated block of address space and must return the space to its upstream provider. 4.2.2.5. Replacement initial allocation Any ISP which has received an initial allocation, or previous replacement initial allocation, smaller than /20 who wishes to receive additional address space must request a replacement initial allocation. To receive a replacement initial allocation, an ISP must agree to renumber out of and return the existing allocation in it's entirety within 12 months of receiving a new allocation and provide justification for the new allocation as described in section 4.2.4. Rationale: This policy proposal fundamentally changes and simplifies the initial IPv4 allocations to ISPs by doing the following: 1) Makes moot whether the requesting ISP is multihomed or not, with this policy change all initial ISPs request under the same minimums. 2) Lowers the minimums, making it easier for smaller ISPs to qualify for direct allocations from ARIN. 3) Reduces fragmentation of the allocated IPv4 pool by forcing smaller ISPs who do qualify under the minimum to return the small allocation when they outgrow it. Note particularly that this does not "change the bar" for ISPs who have already received small allocations, as they will have not agreed to return those smaller allocations when they get larger allocations. 4) Indirectly encourages the adoption of IPv6 as the ISPs that now qualify for numbering under this policy change will be considered an LIR and thus satisfy one of the IPv6 requirements in section 6.5.1.1 This policy proposal idea grew out of Proposal 98 and 100 and the discussions surrounding those proposals as well as many discussions on the ppml and on arin-discuss mailing lists. For starters, it's well known that while transit networks have the ability to filter IPv4 BGP advertisements, few to none filter anything larger than a /24 (any who do filter /24 or larger have a default route to fall back on), and a /24 (for perhaps no better reason than it happens to be a "class C") has become the de-facto standard minimum. As a result, assigning blocks smaller than a /22 (the current minimum under 4.2.2) isn't going to break anything. Secondly, the primary motivator for denying smaller ISPs an initial allocation from ARIN is to slow the growth of the DFZ, due to concerns that growth of the so-called "IPv4 global routing table" would exceed memory requirements in routers operated by transit networks. This is why Section 4.2.2 was split into multihomed and non-multihomed in the first place, to help "raise the bar" and prevent a land rush. Section 4.2.2.1 makes it so that only really large ISPs qualify for an initial allocation, Section 4.2.2.2 makes it so that only ISPs with the financial ability to bring in multiple feeds can qualify. Basically, your either big and poor or small and rich - whereas the typical "garage operator" ISP would be small and poor. Our belief is that while this may have worked a decade ago, it's a moot issue now. For one thing, nothing prevents orgs that obtain larger allocations from splitting their advertisements. For example an org that has a /22 and 2 feeds, one larger than the other, might choose to advertise 2 /23's so they can prepend one of the /23's towards the smaller feed, so as to reduce traffic. Orgs that have distributed NOCS and even larger allocations have also done this for traffic flow reasons. There is no real guarantee than an org getting a contiguous block will actually advertise it under a single route entry, so it seems somewhat hypocritical to deny smaller ISPs an initial allocation because of the reason that small allocations clog up the so-called "global route table" when larger ISPs can and sometimes do clog it up by subnetting. The Internet landscape has changed tremendously, it is much more expensive now for "garage operators" to initiate operations, and the ISP industry has had a lot of consolidation. These factors are much more of a deterrent to small operators getting started and wanting an initial allocation. And, with small operators, labor is costly and renumbering out of an upstream-assigned IPv4 block is a big barrier as well. We feel that allowing smaller ISPs to qualify now for IPv4 will have a number of benefits: 1) It's possible that post-IPv4 runout, financial pressure to justify assignments will develop among transit networks as the "market rate" of IPv4 rises. That may lead to smaller ISPs who don't have their own assignments to be pressured to shrink operations (or be pushed out completely), by upstreams eager to sell IPv4 blocks on the transfer market. 2) Sometimes an issue is helped more by being "nibbled to death by ducks". If a large number of small ISPs were to obtain IPv4 and follow up by obtaining IPv6 at the same time, the cumulative effect of many small operators calling their upstreams and pressuring their upstreams to supply native IPv6 routing might be much stronger - and might cause more of them to get on the ball with IPv6 deployments. 3) Small IPv4 subnets that a /23 or /22 allocation can be made from will be increasingly available to ARIN from reclamation efforts, thus allocating small subnets that the RIR generates from these efforts to legitimate ISPs will help to prevent "squatting" on them from spammers and other network criminals, without consuming "virgin" blocks in the free pool. It might even be possible for ARIN to use portions of the "old swamp" (ie: 192.5.0.0/16, 192.12.0.0/16, 192.16.0.0/16, etc.) for this. Timetable for implementation: immediate _______________________________________________ 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 Fri Nov 6 15:28:52 2009 From: info at arin.net (Member Services) Date: Fri, 06 Nov 2009 15:28:52 -0500 Subject: [arin-announce] Consultation Closed: Changes to ARIN RSS Feed Message-ID: <4AF48704.4040904@arin.net> ARIN received no responses or suggestions for improvements to the "arin-issued" RSS feed that lists addresses returned and addresses issued directly by ARIN. Based on private comments, we will soon make two improvements to the feed: 1) Add language to clarify the nomenclature within the feed so that the community can understand the report more clearly 2) Highlight the feed in a more suitable place on the ARIN website ARIN offers the consultation process to allow for community input on operational issues. We hope that in the future you will take advantage of this opportunity to help us serve you better. Complete archives of past consultations 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 Nov 9 14:34:57 2009 From: info at arin.net (Member Services) Date: Mon, 09 Nov 2009 14:34:57 -0500 Subject: [arin-announce] [Fwd: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process] Message-ID: <4AF86EE1.2010502@arin.net> The following is a new policy proposal that has been posted to the ARIN Public Policy Mailing List for discussion on that list. Regards, Member Services American Registry for Internet Numbers (ARIN) -------- Original Message -------- Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process Date: Mon, 09 Nov 2009 14:31:33 -0500 From: Member Services To: arin-ppml at 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 103: Change IPv6 Allocation Process Proposal Originator: William Herrin Proposal Version: 1.0 Date: 9 November 2009 Proposal type: new Policy term: permanent. Policy statement: Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, 6.5.1-6.5.5, 6.5.8, 6.7, 6.10 Strike NRPM section 6.9 paragraph 2. Replace 6.2.5 as follows: 6.2.5 Allocate and Assign For the purposes of NRPM section 6, allocate and assign are synonymous. Both terms describe any or all use identified in section 2.5. Replace 6.5.7 with: 6.5.7. Existing IPv6 address space holders Organizations that received IPv6 allocations under the previous IPv6 address policy are entitled to either retain those allocations as is or trade them in for an allocation under 6.5.9. Add NRPM section 6.5.9 as follows: 6.5.9 IPv6 Allocations 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only the following denominations: /56, /48, /40, /32, /24 6.5.9.2 No utilization-based eligibility requirements shall apply to IPv6 allocations. 6.5.9.3 ARIN shall accept registration of no more than one address block of each size for any single organization. 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the identity of the allocation pool serves to classify the expected size of allocations within. ISPs may use that classification to filter or otherwise manage their routing tables. 6.5.9.5 For each allocation size, ARIN shall further manage the allocation pools such that the pool identity serves to classify whether or not the registrant is Multihomed. 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed only to organizations which ARIN has verified are multihomed on the public Internet per NRPM 2.7. 6.5.9.7 Where an organization ceases to be Multihomed it shall surrender all address allocations from within pools classified as multihomed within 3 months. Rationale: See the implementation notes section below for what should replace utilization-based eligibility. The existing IPv6 allocation policy under section 6.5 makes a number of unproven assumptions about how IPv6 allocations 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 space, its impractical to 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 multihomed 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 disaggregates 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 without a great deal of guesswork. B. Efficient utilization of BGP routing slots. No multihomed orgs will announce more than five unfilterable routes, and that only if they're so large that they can afford the price tag for the biggest address blocks. That's a good thing since IPv6 routes that propagate worldwide may impose an annual systemic overhead cost on ISPs of as much as US $16,000 each. 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 allocation. You pay for what you want and get what you pay for. You're either multihomed or you're not. F. Gets ARIN out of the business of being the gatekeeper for Internet routing policy. By classifying allocations instead of making eligibility decisions, ARIN empowers the ISPs to set appropriate routing eligibility policies instead. FAQ Q. Isn't this classfull addressing all over again? A. Yes. 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. What if I don't want to accept /56 routes for single-homed users? A. This policy proposal intentionally and fully places backbone routing policy in the hands of the ISPs who operate the Internet's "Default-Free Zone (DFZ)," colloquially known as the Internet backbone. The author expects that some of the allocations, especially some of the single-homed allocations, *will not* be routable on the public Internet. When we hold a general expectation that all of ARIN's allocations will be routable, we effectively mean that ARIN decides what the Internet routing policy will be. That's precisely the role this proposal removes from ARIN's hands and restores to the ISPs. Q. Spell it out for me. How exactly will pools and size classifications enable route filtering? A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows: 4000::/13 -- reserved 4008::/15 -- multihomed /24 allocations 400a::/15 -- non-multihomed /24 allocations 400c::/16 -- multihomed /32 allocations 400d::/16 -- non-multihomed /32 allocations 400e:0000::/18 -- multihomed /40 allocations 400e:4000::/18 -- non-multihomed /40 allocations 400e:8000::/24 -- multihomed /48 allocations 400e:8100::/24 -- non-multihomed /48 allocations 400e:8200::/24 -- multihomed /56 allocations 400e:8300::/24 -- non-multihomed /56 allocations 400e:8400::/22 -- reserved 400e:8800::/21 -- reserved 400e:9000::/20 -- reserved 400e:a000::/19 -- reserved 400e:c000::/18 -- reserved 400f::/16 -- reserved Now, you're an ISP. Here's a sample routing policy you might choose: Accept any routes to /32 because anyone paying $10k per year for addresses is big enough to ride. For /24 allow 2 bits of traffic engineering too. Single-homers who won't spend $10k/year on their addresses (smaller than /32) must use addresses from their ISP. Tough luck. Accept multihomers down to /48. The folks paying only $10/year for /56's aren't serious. Your route filter looks like this: accept 400e:8000::/24 equal 48 accept 400e:0000::/18 equal 40 accept 400c::/15 equal 32 accept 4008::/14 le 26 reject 4000::/12 le 128 Note how 400e:8000::/24 contains only /48 allocations and you're allowing only /48 announcements. Since there aren't any /47 or /46 allocations there, nobody in the pool can slip TE routes past you. On the other hand, you'll get some benefit of traffic engineering from the super-massive /24 registrants up in 4008::/14 because you're allowing them to disaggregate down to /26. Q. If its so expensive to announce routes into the DFZ, why not use something better than BGP? A. In 2008 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. The long answer is more complicated. Folks have tried very hard to devise multi-vendor multihomed systems which don't rely on BGP. The only approach that has ever come near success is dynamically changing DNS records to favor the currently working Internet connection. "Near" is a relative term here. Such network architectures are enormously complex and they don't work especially well. 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. So the Internet's resulting route policy will be to allow all the sizes that no major ISP decides to filter and restrict the rest? A. That's one possible outcome. On the other hand, research in the routing field suggests that with a sufficiently rich classification scheme, it may be possible to implement lower priority systems with provider-independent addresses yet without a global route. Hints for how such a thing might work can be found in http://www.cs.cornell.edu/people/francis/va-wp.pdf and http://bill.herrin.us/network/trrp.html. Such schemes need a rich classification process at the address allocation level that makes it possible for ISPs to make reasonable and simple decisions about which routes should be distributed to every DFZ router and which should not. Wouldn't that be something: IPv6 provider independent addresses for everybody without materially increasing the cost of the routing system. 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 then any route in the /32 pool which is longer than /32 is a traffic engineering (TE) route. As a router operator you can filter and discard TE 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 TE routes... If they're distinct 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 with certainty whether the routes you're filtering are only for TE. Q. Why allow only one allocation of each particular size? A. Without the address scarcity issue which drives IPv4 policy, the primary criteria for IPv6 addressing policy is suppressing the disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8). Such a criteria is not well served if an organization holds dozens of discontiguous address spaces as a result of acquisitions, mergers and and growing a little bit at a time. This proposal says, in effect, once you've consumed your smaller allocation it's time for you to get a *much* bigger allocation. The rest of us don't want to pay the routing table price for you coming back again and again and again. The proposal could require some renumbering as a result of mergers and acquisitions. However, with only modest planning on the registrant's part, the policy its 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 about the IETF recommendations? A. RFC 3177 recommends that ISPs receive a /32 while downstream customers receive a /48 assignment by default with so-called "sparse allocation" to allow those assignments to expand by changing the netmask. While this proposal supports organizations who wish to follow those recommendations, it is not this proposal's intention that ARIN follow RFC 3177. RFC 3177 is not the gospel truth. It was written back in 2001 when there was little IPv6 outside of academia and, indeed, little IPv6 at all. It's an engineers' SWAG about what operations folk should do that's now 8-years-stale. This proposal attempts to slow-start IPv6 allocations instead, while still maintaining the principle of suppressing the routing table size. As an ISP, 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. A /60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how many subnets do you think your normal downstream customer will actually use? Q. What happens when organizations merge or split? A. Entities which merge may renumber out of and return conflicting allocations, or they may maintain the existence of the acquired organization in order to keep it's addresses. Either way it should be a minor hardship. Entities which split have a bigger problem since the practical effect of route filtering may be that 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 likely 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. What about IPv6 addresses for uses which will not be connected to the Internet at all? A. Folks are welcome to get non-multihomed addresses for any purpose whatsoever. If they do eventually decide to connect to the Internet, the routes will follow whatever rules the ISPs have imposed for routes within the single-homed pools. Q. What about reporting requirements for downstream assignments? A. Reporting requirements were instituted for the purpose of verifying eligibility for additional allocations. They have proven useful for other purposes and the author encourages ARIN to maintain the SWIP system. Nevertheless, this proposal renders the use of SWIP for IPv6 optional since it is no longer needed to verify eligibility for allocations. Q. What if I need more than a /24? A. This proposal's author asserts as obvious: anyone who defines a need for more than a trillion subnets should make their case publicly on PPML, seeking a follow-on proposal that establishes address pools at the /16 level. Q. What are the struck sections of the current IPv6 policy and why should they be struck? A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the policy as revised by this proposal. The 6.4.3 notion of a minimum allocation is obsoleted by the allocation pools of specific size in this proposal. 6.4.4 is moot as this proposal does not expect registrants to justify their IPv6 allocation size. 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9. 6.5.5 is largely moot since it's no longer necessary to confirm downstream assignments in order to determine eligibility for additional addresses. 6.7 is moot as it is unnecessary to compute utilization to justify addresses under this proposal. 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 policy under this proposal. 6.10 is redundant since micro-allocations are trivially accomplished under 6.5.9. Implementation notes: To prevent wasteful consumption of IPv6 address space without a complicated eligibility regime, the author recommends an initial and annual fee regime for IPv6 address allocations similar to: /56 -- $10 USD /48 -- $100 USD /40 -- $1000 USD /32 -- $10,000 USD /24 -- $100,000 USD Legacy -- the lesser of the cost of the next larger size or the cost of the next smaller size times the number encompassed by the registration. The above notwithstanding, it may be advisable to discount /40s and /32s to a much lower price during IPv6's general deployment process in order to encourage adoption. Folks who already hold /31's should probably also get a big break on the $20k fee for a good long while, perhaps until the first time they request an additional block without offering a plan to return the legacy addresses. For verification of multihoming, the current way ARIN verifies multihoming for other parts of it's policy appears satisfactory. Should that change, the author suggests requiring that the AS# contacts for at least two AS#'s submit a template indicating that they intend to originate or propagate IPv6 BGP routes from the registrant's ORG. Timetable for implementation: immediate _______________________________________________ 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 Tue Nov 10 10:15:09 2009 From: info at arin.net (Member Services) Date: Tue, 10 Nov 2009 10:15:09 -0500 Subject: [arin-announce] ASO AC Call for Nominations for Seat 10 on the ICANN Board Message-ID: <4AF9837D.5030702@arin.net> Dear Colleagues, In line with the ASO Memorandum of Understanding and ICANN Bylaws, the Address Supporting Organization Address Council (ASO AC) calls for nominations for Seat Number 10 on the ICANN Board. The nomination period will close at 23:59 UTC on 10 January 2010. All candidates must sign a Letter of Certification detailing previous conduct and character. We will send this letter to each applicant along with instructions on what to do next. We are unable to consider candidates who fail to follow these instructions. If the ASO AC decides to conduct face-to-face interviews, candidates may need to travel (once) during March 2010. We expect all candidates to complete one or more questionnaires. Failure to do this by the advised deadlines may rule them out of the selection process. Submit nominations by email to nominations2010 at aso.icann.org including the following information: - Full name of the person being nominated - Contact email address for the person being nominated - Contact telephone number (if available) of the person being nominated - Full name of the person making the nomination - Contact email address for the person making the nomination - Contact telephone number of the person making the nomination The full timeframe for the selection process is as follows: - Nomination Phase - 12 November 2009 to 10 January 2010 - Comment Phase - 11 January 2010 to 10 March 2010 - Interview Phase - 10 February 2010 to 10 March 2010 (The deadline for return of written questionnaires is 20 February 2010. Face-to-face interviews with selected candidates will take place adjacent to the ICANN meeting in Nairobi, Kenya in March 2010.) - Selection Phase - 10 March 2010 to 24 March 2010 All phases will conclude at 23:59 UTC on the date specified. Regards, The ASO Secretariat From info at arin.net Thu Nov 12 15:16:22 2009 From: info at arin.net (Member Services) Date: Thu, 12 Nov 2009 15:16:22 -0500 Subject: [arin-announce] Consultation Closed: Changes to ARIN Resource Revocation Procedures Message-ID: <4AFC6D16.2080407@arin.net> ARIN thanks the community for its input regarding changes to ARIN?s Resource Revocation procedures. Based on the feedback received, ARIN will modify its current revocation procedures to reduce the amount of time an organization has to pay its overdue fees to six months from the current twelve months. Six months after the date of revocation, the resources will be considered permanently revoked. If an organization attempts to submit payment after the six-month limit, they will be required to reapply for the number resources. If approved, they could receive the same resources if still available, or new ones if not. Additional fees may apply for resource reinstatement following revocation. 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 Thu Nov 19 09:46:03 2009 From: info at arin.net (Member Services) Date: Thu, 19 Nov 2009 09:46:03 -0500 Subject: [arin-announce] Maintenance Work Scheduled for Saturday, 21 November Message-ID: <4B055A2B.3010607@arin.net> On Saturday, 21 November 2009, ARIN will be conducting maintenance on back-end systems. The work will take place from 8:00AM until approximately 10:00 AM EDT. ARIN will experience interruption of two external services while this maintenance is performed. For the duration, any mail sent to Registration Services (hostmaster at arin.net and reassign at arin.net) will be queued, and you will not be able to use your ARIN Online account to submit transactions. Once the systems are back online, queued mail will be processed, and you will regain use of your ARIN Online account. All other publicly available services (WHOIS, IRR, etc.) will not be affected by this outage. Thank you for your patience and cooperation, Mark Kosters Chief Technical Officer American Registry for Internet Numbers (ARIN) From info at arin.net Mon Nov 23 10:27:15 2009 From: info at arin.net (Member Services) Date: Mon, 23 Nov 2009 10:27:15 -0500 Subject: [arin-announce] New ARIN Online Features Released 21 November, 2009 Message-ID: <4B0AA9D3.9010903@arin.net> ARIN is pleased to release new features to increase the utility of your ARIN Online account. You can now view the ASN and network records you are associated with. You can also submit requests for a: * Reassignment Report ? available for networks that are direct allocations or reallocations; shows utilization and lists all sub-delegations for the given range as registered in ARIN?s WHOIS directory service via SWIP. * Associations Report ? lists all POCs your ARIN Web account is linked to as well as all organizations and number resources those POCs are associated with. These report requests will be ticketed. You will be notified in your Message Center when the report has finished processing. To see what is coming up next ? view the list of planned features at: https://www.arin.net/about_us/roadmap.html. Log in today and check out these enhancements, or create your ARIN Online account at https://www.arin.net Please send any questions, comments, or issues to: hostmaster at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) From info at arin.net Mon Nov 23 11:39:13 2009 From: info at arin.net (Member Services) Date: Mon, 23 Nov 2009 11:39:13 -0500 Subject: [arin-announce] Tom Zeller Appointed to Advisory Council Message-ID: <4B0ABAB1.6080402@arin.net> On 19 November 2009, the ARIN Advisory Council voted to appoint Tom Zeller to the Advisory Council for a one-year term beginning 1 January 2010. He will fill the seat being vacated by Paul Andersen. Following published procedures for interim appointments, the Advisory Council asked the next highest vote recipient in the recent Advisory Council election if he would be willing to fill the remaining year of Mr. Andersen?s term. Details are available at: https://www.arin.net/participate/elections/ac.html#acinterim Mr. Andersen was elected to the ARIN Board of Trustees for a three-year term commencing 1 January 2010 and has submitted his resignation from the Advisory Council effective 31 December 2009. Regards, Member Services American Registry for Internet Numbers (ARIN)