From alan at batie.org Sun Oct 4 14:28:04 2009 From: alan at batie.org (Alan Batie) Date: Sun, 04 Oct 2009 11:28:04 -0700 Subject: [arin-ppml] Dearborn: Calling all CAcert and/or Thawte Notaries In-Reply-To: References: Message-ID: <4AC8E934.1000501@batie.org> Owen DeLong wrote: > It occurs to me that in addition to the PGP key signings that tend to > happen at NANOG > meetings it might be worth having a group notary event for CAcert and/or > Thawte > notarizations. Speaking of...it's always made no sense to me that ARIN required you to use their certificates. I suppose it's mostly moot when actions moving to the web interface and away from email, but in the worst case, they could use whatever methods they use to valid your identity on their certificates to validate it for the one you submit... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3276 bytes Desc: S/MIME Cryptographic Signature URL: From info at arin.net Mon Oct 5 13:41:09 2009 From: info at arin.net (Member Services) Date: Mon, 05 Oct 2009 13:41:09 -0400 Subject: [arin-ppml] Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <4AAE4700.5050508@arin.net> References: <4AAE4700.5050508@arin.net> Message-ID: <4ACA2FB5.90602@arin.net> Draft Policy 2009-3 (Global Proposal) Allocation of IPv4 Blocks to Regional Internet Registries On 14 September 2009 a revised version of Draft Policy 2009-3 was posted to the Public Policy Mailing List (PPML). ARIN staff reviewed the text of the draft policy and produced the following revised staff and legal assessment. 2009-3 is under discussion on PPML and will be presented at the upcoming Public Policy Meeting in Dearborn. Draft Policy 2009-3 is below and can be found at: https://www.arin.net/policy/proposals/2009_3.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Staff Assessment Draft Policy 2009-3 (Global Proposal) Allocation of IPv4 Blocks to Regional Internet Registries Text assessed: 14 September 2009 I. Summary (Staff Understanding) (revised): Staff understands that this proposal would be implemented in 2 phases. Phase 1 says that the RIRs may elect to return any IPv4 addresses they recover (via policy or procedure) to the IANA but it does not require them to return recovered IPv4 address space to IANA. Phase 2 would start after the depletion of the IANA free pool and would nullify the existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The new IANA to RIR policy would allow each RIR to receive approximately 1/10th of the recovered IPv4 pool from IANA once every 6 months as long as it meets the qualification criteria written in paragraph B2. IANA will be required to keep a log of all returned IPv4 address space and all issued IPv4 address space from the recovered pool, as well as maintain a public registry of the current disposition of all IPv4 address space. II. Comments A. ARIN Staff Comments (revised) ? If an RIR is fully authoritative for a /8, and as a result of this policy, returns a portion of that /8 to IANA, it is likely that the DNS authority for the /8 could change. If the returned space is then re-issued by IANA to a different RIR, is the /8 now considered an ERX-like "fractured" /8, which the RIRs must then exchange zone fragments for to put together a complete set of zone files for the /8? Close coordination by the 5 RIRs will be required in order to successfully manage the potential reverse DNS implications. B. ARIN General Counsel Comments (revised): The current basis of allocating number resources was established in RFC's 2008 and 2050 and is defined to be according to operational need. If one region has greater needs than another, current allocation policy does not call for equal distribution of numbering resources to all RIR's. The revised portion of this policy removes objectionable requirements in the prior version that required ARIN to return all recovered IPV4 space to the IANA, when such space might be needed in this region, or other regions were not maintaining need's based distribution policies. That first problem was exacerbated by a second: the policy included a redistribution mechanism that did not follow RFC 2008 and 2050 but would provide ARIN, at best, only one fifth of such space, when it was also likely ARIN would return more than one fifth of the recovered space. The revision to voluntarily permit, but not require ARIN to return such recovered space is a substantial advance and removes strong legal and fiduciary objections to the prior draft. Accordingly, the revised policy also removes the prior version's disincentive for any RIR, including ARIN, to undertake financial expenditure of its financial resources for programs intended to obtain returned space, since it does not force 100% return to IANA. Since ARIN has expended significant resources seeking the return of unused number resources, this is again a positive change. It also appears, and it must be made so if it is not, that the revised language would not interfere with transfers made under ARIN's new policy, which is intended to encourage better use of otherwise underutilized resources. However, the revised proposal appears to retain the predecessor' drafts policy that each RIR with needs will be an equal recipient of such returned space, even if those needs are disparate. This policy could tend to reallocate returned space away from where it is recovered, in the ARIN region, to other regions. This would be objectionable from a fiduciary duty perspective if one or more of the other RIRs abandon needs-based policies, but are then permitted by this policy to obtain equal additional resources. However, since ARIN can choose not to return recovered resources if others RIRs are not maintaining needs based policies, this is no longer a fatal legal flaw, since ARIN can chose not to provide returned resources for redistribution under such circumstances. There is a concern over one particular piece of the policy. In 4 it states: "Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA." The 'new' reference appears unwise, with "recognized" RIRs being a better choice. III. Resource Impact The resource impact of implementing this policy is viewed as moderate as it represents a fundamental change to the business rules of ARIN?s inventory management of number resources. It is estimated that this policy would require a minimum of 6 person months of effort to implement following ratification by the ARIN Board of Trustees. Because this implementation is not planned, it may preempt ARIN's current project deployment schedule. It may require the following: ? Modifications to existing registration procedures to include the handling of returned/reclaimed address space and the process of requesting additional address space from the IANA. ? Modifications to the existing registration software and systems as well as the zone gen and any other processes tied to managing reverse DNS. ? Staff training ? Inter-RIR coordination End of assessment. Member Services wrote: > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > On 20 August 2009 the ARIN Advisory Council (AC) selected 2009-3 for > adoption discussion on the PPML and at the Public Policy Meeting in > Dearborn. > > 2009-3 comes from a global policy proposal. Global policies require the > agreement of all five RIRs according to their policy development > processes and ratification by ICANN. And, global policies require > specific actions by the IANA. > > After the ARIN Public Policy Meeting in April 2009 the AC returned > 2009-3 to their docket for further development and evaluation. > > The AC revised the text. The difference between the text presented at > the ARIN meeting in April and the current version is in "A. Phase I" as > follows: > > Old ARIN "A. Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. At > quarterly intervals, each RIR shall return to the IANA any legacy > address space recovered, and may return to the IANA any non-legacy > address space recovered, in aggregated blocks of /24 or larger, for > inclusion in the recovered IPv4 pool. > > New ARIN "A. Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA. Each RIR shall at > quarterly intervals return any such designated address space to the > IANA in aggregated blocks of /24 or larger, for inclusion in the > recovered IPv4 pool. > > Draft Policy 2009-3 is below and can be found at: > https://www.arin.net/policy/proposals/2009_3.html > > You are encouraged to discuss Draft Policy 2009-3 on the PPML prior to > the October Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > Note, the ARIN version of the global proposal is different from the text > at the other RIRs. The AC's version has a revised "A. Phase I" (APNIC's > equivalent is prop-069, see the second paragraph of 5.1). The ARIN > version also includes a definition of legacy space. > > The APNIC proposal can be found at: > http://www.apnic.net/policy/proposals/prop-069 > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > Version/Date: 14 September 2009 > > Policy statement: > > This document describes the policy governing the allocation of IPv4 > address space from the IANA to the Regional Internet Registries (RIRs). > This document does not stipulate performance requirements in the > provision of services by IANA to an RIR in accordance with this policy. > Such requirements should be specified by appropriate agreements among > the RIRs and ICANN. > > This policy is to be implemented in two phases. > > A. Phase I: Recovery of IPv4 Address Space > > Upon ratification of this policy by the ICANN Board of Directors the > IANA shall establish a mechanism to receive IPv4 address space which is > returned to it by the RIRs, and hold that address space in a 'recovered > IPv4 pool'. > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA. Each RIR shall at > quarterly intervals return any such designated address space to the IANA > in aggregated blocks of /24 or larger, for inclusion in the recovered > IPv4 pool. > > During Phase I, no allocations will be made from the recovered IPv4 > pool. Return of recovered address space (as described above) will > continue throughout Phase II. > > B. Phase II: Allocation of Recovered IPv4 address space by the IANA > > Upon ratification of this policy by the ICANN Board of Directors and a > declaration by the IANA that its existing free pool of unallocated IPv4 > address space is depleted; Global Addressing Policy ASO-001-2 (adopted > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to > allocate the IPv4 address space from the recovered IPv4 pool. > > 1. The following definitions apply to this policy: > > a. Recovered Address Space. Recovered address space is that address > space that is returned to an RIR as a result of any activity that seeks > to reclaim unused address space or is voluntarily returned to the RIR or > is reclaimed by the RIR as a result of legal action or abuse > determination. Recovered address space does not include that address > space that is reclaimed because of non-payment of contractual fees whose > reclamation date is less than 1 year at the time of the report. > > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 > address space held by an RIR to include recovered address space not yet > returned less that address space that is committed in accordance with > the RIR's reservation policy and practices. > > c. Aggregated address blocks. Aggregated address blocks are contiguous > prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 > and 10.0.1.0/24 are two contiguous prefixes that can be combined to form > an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two > contiguous prefixes that cannot be combined on a natural bit boundary to > form an aggregated block. > > d. Legacy address space. IPv4 address space allocated or assigned prior > to the creation of the RIR. > > 2. Allocation of IPv4 Address Space > > a. For the purposes of this policy, an 'IPv4 allocation period' is > defined as a 6-month period following 1 March or 1 September in each > year. > > b. At the beginning of each IPv4 allocation period, the IANA will > determine the 'IPv4 allocation unit' for that period, as 1/10 of its > IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. > The minimum 'IPv4 allocation unit' size will be a /24. > > c. In each allocation period, each RIR may issue one IPv4 request to the > IANA. Providing that the RIR satisfies the allocation criteria described > in paragraph B.2, the IANA will allocate a single allocation unit, > composed of the smallest possible number of blocks available in its IPv4 > address pool. > > 3. IPv4 Address Space Allocation Criteria > > A RIR is eligible to receive additional IPv4 address space from the IANA > when the total of its IPv4 address holdings is less than 50% of the > current IPv4 allocation unit, and providing that it has not already > received an IPv4 allocation from the IANA during the current IPv4 > allocation period. > > 4. Initial Allocation of IPv4 Address Space > > Each new RIR shall, at the moment of recognition, be allocated one (1) > allocation unit by the IANA. If an allocation unit is not available, > then the IANA will issue this block as soon as one is available. This > allocation will be made regardless of the newly formed RIR's projected > utilization figures and shall be independent of the IPv4 address space > that may have been transferred to the new RIR by the already existing > RIRs as part of the formal transition process. > > 5. Reporting > > a. All returned space is to be recorded in an IANA-published log of IPv4 > address space transactions, with each log entry detailing the returned > address block, the date of the return, and the returning RIR. > > b. All allocated space is also to be recorded in this IANA-published log > of IPv4 address space transactions, with each log entry detailing the > address blocks, the date of the allocation and the recipient RIR. > > c. The IANA will maintain a public registry of the current disposition > of all IPv4 address space, detailing all reservations and current > allocations and current IANA-held address space that is unallocated. > > d) The IANA may make public announcements of IPv4 address block > transactions that occur under this policy. The IANA will make > appropriate modifications to the "Internet Protocol V4 Address Space" > page of the IANA website and may make announcements to its own > appropriate announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry > they have been allocated. > > > > > > > > > > > > > From michael.dillon at bt.com Mon Oct 5 17:50:43 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Oct 2009 22:50:43 +0100 Subject: [arin-ppml] Straw poll on special policy for electric energy industry Message-ID: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> This is just a question to see what people think about creating a special policy that applies to companies wishing to provide infrastructure for the electric utility industry Smart Grid. Basically, the situation is this as described by Richard Shockey on the IETF list: Myself and others are deeply concerned by how this effort is developing. There is no current consensus on what the communications architecture of the SmartGrid is or how IP actually fits into it. The Utility Industry does not understand the current IPv4 number exhaust problem and the consequences of that if they want to put a IP address on every Utility Meter in North America. What is equally troubling is that many of the underlying protocols that utilities wish to deploy are not engineered for IPv6. We have an example of that in a recent ID. Basically, what I am suggesting is that we introduce a special policy that bans the Electric Utility industry from receiving any IPv4 addressing at all, either direct ARIN allocations or ISP assignments, if those addresses are intended for any kind of Smart Grid application. This ban would also apply to third parties and subcontractors who might be operating components of the Smart Grid. Note that this special policy would not apply to any other use of IP in an electric utility company, only to the Smart Grid. This would send a clear message to the utility industry that there is simply not enough IPv4 address space left for a new major user, and would help them get their plans around IPv6 worked out earlier, rather than wasting their time and money on something that will NEVER fly. Seems to me this fits well within ARIN's educational purpose. If possible, we should try to word this policy in such a way that it could be adopted by the other RIRs because the Smart Grid movement is now world wide. --Michael Dillon From michael.dillon at bt.com Mon Oct 5 18:23:07 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 5 Oct 2009 23:23:07 +0100 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <13CDEB23-F61D-41A5-81CE-8E3D1CA29EC3@gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745803695C66@E03MVZ2-UKDY.domain1.systemhost.net> > This seems like an opportunity for education and outreach, > rather than for punitive policy. Do you just put up a "No Trespassing" sign, or do you put up a fence as well? I think most people would put up the fence first, then the signs. The Smart Grid plans appear to be even bigger than the cable industry rollouts that led to net 24 being allocated, and the special cable industry policies. --Michael Dillon From dwhite at olp.net Mon Oct 5 18:26:18 2009 From: dwhite at olp.net (Dan White) Date: Mon, 5 Oct 2009 17:26:18 -0500 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20091005222618.GS5403@dan.olp.net> On 05/10/09?22:50?+0100, michael.dillon at bt.com wrote: > >This is just a question to see what people think about creating a >special policy that applies to companies wishing to provide >infrastructure for the electric utility industry Smart Grid. > >Basically, the situation is this as described by Richard Shockey on the >IETF list: > > Myself and others are deeply concerned by how this effort is >developing. > There is no current consensus on what the communications architecture >of the > SmartGrid is or how IP actually fits into it. A bigger issue to me is what security protocols and processes the smart grid will use. While trying to research that topic, I found out that that NIST has been charged with developing those security processes. I tried emailing them a few months ago to get more information, but have not been successful in getting a response. It may be there's a link somewhere to all the protocols they're developing, and I'd be happy if that were the case. >Basically, what I am suggesting is that we introduce a special policy >that >bans the Electric Utility industry from receiving any IPv4 addressing at >all, >either direct ARIN allocations or ISP assignments, if those addresses >are intended >for any kind of Smart Grid application. This ban would also apply to >third parties >and subcontractors who might be operating components of the Smart Grid. I think at this point shedding light on the networking development of the smart grid and how we can participate and advise is the best use of our resources. Which IETF list is this discussion on? -- Dan White BTC Broadband From scottleibrand at gmail.com Mon Oct 5 18:02:27 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 5 Oct 2009 15:02:27 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <13CDEB23-F61D-41A5-81CE-8E3D1CA29EC3@gmail.com> This seems like an opportunity for education and outreach, rather than for punitive policy. Scott On Oct 5, 2009, at 2:50 PM, wrote: > > This is just a question to see what people think about creating a > special policy that applies to companies wishing to provide > infrastructure for the electric utility industry Smart Grid. > > Basically, the situation is this as described by Richard Shockey on > the > IETF list: > > Myself and others are deeply concerned by how this effort is > developing. > There is no current consensus on what the communications > architecture > of the > SmartGrid is or how IP actually fits into it. > > The Utility Industry does not understand the current IPv4 number > exhaust > problem and the consequences of that if they want to put a IP > address > on > every Utility Meter in North America. > > What is equally troubling is that many of the underlying protocols > that > utilities wish to deploy are not engineered for IPv6. We have an > example of > that in a recent ID. > > Basically, what I am suggesting is that we introduce a special policy > that > bans the Electric Utility industry from receiving any IPv4 > addressing at > all, > either direct ARIN allocations or ISP assignments, if those addresses > are intended > for any kind of Smart Grid application. This ban would also apply to > third parties > and subcontractors who might be operating components of the Smart > Grid. > > Note that this special policy would not apply to any other use of IP > in > an > electric utility company, only to the Smart Grid. > > This would send a clear message to the utility industry that there is > simply not enough IPv4 address space left for a new major user, and > would > help them get their plans around IPv6 worked out earlier, rather than > wasting their time and money on something that will NEVER fly. > > Seems to me this fits well within ARIN's educational purpose. > > If possible, we should try to word this policy in such a way that it > could be adopted by the other RIRs because the Smart Grid movement is > now world wide. > > --Michael Dillon > _______________________________________________ > 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 gtb at slac.stanford.edu Mon Oct 5 18:20:58 2009 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Mon, 5 Oct 2009 15:20:58 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energyindustry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: > This is just a question to see what people think about creating a > special policy that applies to companies wishing to provide > infrastructure for the electric utility industry Smart Grid. I have a philosophical objection to rules/policies/legislation that target specific individuals, companies, or applications. Even dumb ones. The education part I approve of. A "Sense of the community" letter could probably be a good step, if the community can muster the resources for such an executive summary to be sent to the CEO/CIO/CxOs at the utilities. I'll note ARIN already sent out their "Plan for IPv6" letter. I'll also note a Cisco marketing blurb mentioned the Smart Grid would push IPv6 adoption. I guess the real question I have is what is needed to IPv6 enable these types of applications, and what is standing in the way to accomplish that? Gary From scottleibrand at gmail.com Mon Oct 5 18:28:15 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 05 Oct 2009 15:28:15 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C66@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C66@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4ACA72FF.60903@gmail.com> michael.dillon at bt.com wrote: >> This seems like an opportunity for education and outreach, >> rather than for punitive policy. >> > > Do you just put up a "No Trespassing" sign, or do you put > up a fence as well? > > I think most people would put up the fence first, then the > signs. > > The Smart Grid plans appear to be even bigger than the cable > industry rollouts that led to net 24 being allocated, and the > special cable industry policies. > So you're worried that they're going to qualify for and use up a large chunk of the remaining free pool? Perhaps another avenue, that wouldn't target a single network, would be to put some sort of maximum allocation size in place? -Scott From tedm at ipinc.net Mon Oct 5 18:35:39 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 05 Oct 2009 15:35:39 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4ACA74BB.4060001@ipinc.net> I happen to have my home electric service from PGE and my home is one of the ones that they are trialling remote utility meters on. 6 months ago PGE replaced the electric meter on my house with a smart meter that they can read remotely, we haven't had a meter reader at hour home since. I cannot understand why PGE would even want to apply a public IPv4 OR IPv6 number to my home meter when they can make all the private IPv4 numbers they need. I thus see this policy as premature. Before crying Chicken Little, and putting a policy into place that is not needed and could do harm, I think you should ascertain if applying public IPv4 addresses to meters is even a common practice in the electric power industry. One example of mis-engineered protocol posted to the IETF list does not mean we have a problem. What IS becoming more common is the use of SCADA systems on high voltage power lines, and in substations, that use TCP/IP. However, once more, I see no benefit and a lot of potential problems for electric power companies to use public numbers for such systems. If your interested in such a policy I would suggest you contact Sensus http://www.sensus.com/ who supplied the meters that PGE used, and ask them if they use IP addressing. PGE uses AMI meters using FlexNet: http://na.sensus.com/Module/Catalog/Category/electric?id=47 There's plenty of material there as well as contacts you can email. While I doubt that PGE would know what an IPv4 or IPv6 number is, I would guess that Sensus could answer your concerns regarding IP utilization. From looking over the marketing material, it certainly does not appear that they assign 1 IP number per meter. Ted michael.dillon at bt.com wrote: > This is just a question to see what people think about creating a > special policy that applies to companies wishing to provide > infrastructure for the electric utility industry Smart Grid. > > Basically, the situation is this as described by Richard Shockey on the > IETF list: > > Myself and others are deeply concerned by how this effort is > developing. > There is no current consensus on what the communications architecture > of the > SmartGrid is or how IP actually fits into it. > > The Utility Industry does not understand the current IPv4 number > exhaust > problem and the consequences of that if they want to put a IP address > on > every Utility Meter in North America. > > What is equally troubling is that many of the underlying protocols > that > utilities wish to deploy are not engineered for IPv6. We have an > example of > that in a recent ID. > > Basically, what I am suggesting is that we introduce a special policy > that > bans the Electric Utility industry from receiving any IPv4 addressing at > all, > either direct ARIN allocations or ISP assignments, if those addresses > are intended > for any kind of Smart Grid application. This ban would also apply to > third parties > and subcontractors who might be operating components of the Smart Grid. > > Note that this special policy would not apply to any other use of IP in > an > electric utility company, only to the Smart Grid. > > This would send a clear message to the utility industry that there is > simply not enough IPv4 address space left for a new major user, and > would > help them get their plans around IPv6 worked out earlier, rather than > wasting their time and money on something that will NEVER fly. > > Seems to me this fits well within ARIN's educational purpose. > > If possible, we should try to word this policy in such a way that it > could be adopted by the other RIRs because the Smart Grid movement is > now world wide. > > --Michael Dillon > _______________________________________________ > 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 joelja at bogus.com Mon Oct 5 19:00:45 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 05 Oct 2009 16:00:45 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <4ACA72FF.60903@gmail.com> References: <28E139F46D45AF49A31950F88C49745803695C66@E03MVZ2-UKDY.domain1.systemhost.net> <4ACA72FF.60903@gmail.com> Message-ID: <4ACA7A9D.4010203@bogus.com> The funny part of all this is that power companies appear among to most aggressive generators of functionality requests around ipv6 and ipsec, like maybe they actually know what they're doing... joel Scott Leibrand wrote: > michael.dillon at bt.com wrote: >>> This seems like an opportunity for education and outreach, rather >>> than for punitive policy. >>> >> >> Do you just put up a "No Trespassing" sign, or do you put up a fence >> as well? >> >> I think most people would put up the fence first, then the >> signs. >> >> The Smart Grid plans appear to be even bigger than the cable >> industry rollouts that led to net 24 being allocated, and the >> special cable industry policies. >> > > So you're worried that they're going to qualify for and use up a large > chunk of the remaining free pool? Perhaps another avenue, that wouldn't > target a single network, would be to put some sort of maximum allocation > size in place? > > -Scott > _______________________________________________ > 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 ppml at rs.seastrom.com Mon Oct 5 21:07:17 2009 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 05 Oct 2009 21:07:17 -0400 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <4ACA74BB.4060001@ipinc.net> (Ted Mittelstaedt's message of "Mon, 05 Oct 2009 15:35:39 -0700") References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> <4ACA74BB.4060001@ipinc.net> Message-ID: <86ocoluy7u.fsf@seastrom.com> Ted Mittelstaedt writes: > I cannot understand why PGE would even want > to apply a public IPv4 OR IPv6 number to my home meter > when they can make all the private IPv4 numbers they need. Whether PGE falls into this category or not is outside the scope of this discussion but there is a compelling case for globally unique addresses on power meters - outsourcing of bill generation and collection. It's also not uncommon for a utility to have a sufficiently large number of meters that they won't all fit in 10.0.0.0/8 even assuming really optimistic subnet engineering. -r From bill at herrin.us Mon Oct 5 21:25:38 2009 From: bill at herrin.us (William Herrin) Date: Mon, 5 Oct 2009 21:25:38 -0400 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3c3e3fca0910051825n3f0721a3n304f65224bb6925f@mail.gmail.com> On Mon, Oct 5, 2009 at 5:50 PM, wrote: > Basically, what I am suggesting is that we introduce a special policy > that bans the Electric Utility industry from receiving any IPv4 >addressing at all, either direct ARIN allocations or ISP assignments, > if those addresses are intended for any kind of Smart Grid > application. Michael, I would not support a ban that targets a single industry but I would support a ban on IPv4 address allocations for _embedded systems_ of any sort that do not function as publicly accessible Internet servers. To include cell phones and game consoles. And a cut-off date by which folks holding public addresses for such a purpose must recover and reallocate those addresses before they can get any more from ARIN. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From White.Andy at insightcom.com Mon Oct 5 21:30:51 2009 From: White.Andy at insightcom.com (White, Andy) Date: Mon, 5 Oct 2009 21:30:51 -0400 Subject: [arin-ppml] Straw poll on special policy for electric energyindustry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C66@E03MVZ2-UKDY.domain1.systemhost.net> References: <13CDEB23-F61D-41A5-81CE-8E3D1CA29EC3@gmail.com> <28E139F46D45AF49A31950F88C49745803695C66@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <1F2672B2A996FC4E8D31944956B9997401EE54B2@MAIL01.insight.ds> I think it's a natural that any new technology with multiple billions of potential endpoint addressable devices (even in North America) would be encouraged to use IPv6. Certainly there should be some education involved. But there is a fairly instructive parallel in terms of how broadband internet evolved. Since I've been mucking around with cable modems since, oh, 1994, I can say that virtually every cable modem out there has used RFC1918 private IP addresses, and each cable operator has "reused" the same space over and over. Just about every home served has a single public address, typically serving multiple PCs at this point. If the utilities want to go down the RFC1918 path, I'll feel sorry for them in advance - but if they put publicly addressable IPv4 addresses on my smart meter and other devices in my home or office, I'm gonna be really scared of what happens when they're hacked. Regardless, I think the same principles of justification and "efficient utilization" can and should apply in allocation to utilities just as they would to any other organization on the Internet. Intuitively, the limited supply of IPv4 space should translate to a need for most (if not all) utilities examining their options as soon as they realize they cannot get addresses to support anything beyond their initial small-scale deployments. --Andy White -----Original Message----- From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] Sent: Monday, October 05, 2009 6:23 PM To: ppml at arin.net Subject: Re: [arin-ppml] Straw poll on special policy for electric energyindustry > This seems like an opportunity for education and outreach, > rather than for punitive policy. Do you just put up a "No Trespassing" sign, or do you put up a fence as well? I think most people would put up the fence first, then the signs. The Smart Grid plans appear to be even bigger than the cable industry rollouts that led to net 24 being allocated, and the special cable industry policies. --Michael Dillon From michael.dillon at bt.com Tue Oct 6 02:47:47 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 07:47:47 +0100 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <20091005222618.GS5403@dan.olp.net> Message-ID: <28E139F46D45AF49A31950F88C49745803695CA7@E03MVZ2-UKDY.domain1.systemhost.net> > Which IETF list is this discussion on? There is something on the general IETF list here You can subscribe to it here: --Michael Dillon From michael.dillon at bt.com Tue Oct 6 06:21:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 11:21:27 +0100 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <4ACA74BB.4060001@ipinc.net> Message-ID: <28E139F46D45AF49A31950F88C497458037454DE@E03MVZ2-UKDY.domain1.systemhost.net> > If your interested in such a policy I would suggest you > contact Sensus http://www.sensus.com/ who supplied the meters > that PGE used, and ask them if they use IP addressing. > PGE uses AMI meters using FlexNet: They do. Sensus Announces IP-based Smart Grid for FlexNet Industry-leading FlexNet Solution addresses IPv4 and IPv6 endpoints on powerful and secure, licensed band, wireless Smart Grid and AMI Network The purpose of such a policy is to protect the rest of the IP using organizations from new entrants who want to use LARGE AMOUNTS of IPv4 addresses. We have already reached the end game of IPv4. There is not enough left for everybody. Those who already have IPv4 network dependencies should be served first by ARIN, and the rest should use IPv6. That is the reason for banning the entire Smart Grid industry from receiving globally registered IPv4 addresses. Of course, they can use all the RFC 1918 IPv4 addresses that they want, and they can get all the globally registered IPv6 addresses that they want. But the IPv4 watering is almost dried up and they are not welcome to join us. --Michael Dillon P.S. this is only a straw poll discussion at present, to see how people feel about an industry whose plans could cause IPv4 runout to happen suddenly with only a couple of months notice. From tedm at ipinc.net Tue Oct 6 10:31:29 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 06 Oct 2009 07:31:29 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <3c3e3fca0910051825n3f0721a3n304f65224bb6925f@mail.gmail.com> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> <3c3e3fca0910051825n3f0721a3n304f65224bb6925f@mail.gmail.com> Message-ID: <4ACB54C1.1050109@ipinc.net> William Herrin wrote: > On Mon, Oct 5, 2009 at 5:50 PM, wrote: >> Basically, what I am suggesting is that we introduce a special policy >> that bans the Electric Utility industry from receiving any IPv4 >> addressing at all, either direct ARIN allocations or ISP assignments, >> if those addresses are intended for any kind of Smart Grid >> application. > > Michael, > > I would not support a ban that targets a single industry but I would > support a ban on IPv4 address allocations for _embedded systems_ of > any sort that do not function as publicly accessible Internet servers. > To include cell phones and game consoles. And a cut-off date by which > folks holding public addresses for such a purpose must recover and > reallocate those addresses before they can get any more from ARIN. > I like this approach as well. Ted From mkline at segainc.com Tue Oct 6 10:33:26 2009 From: mkline at segainc.com (Mikel Kline) Date: Tue, 6 Oct 2009 09:33:26 -0500 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <1F2672B2A996FC4E8D31944956B9997401EE54B2@MAIL01.insight.ds> References: <13CDEB23-F61D-41A5-81CE-8E3D1CA29EC3@gmail.com><28E139F46D45AF49A31950F88C49745803695C66@E03MVZ2-UKDY.domain1.systemhost.net> <1F2672B2A996FC4E8D31944956B9997401EE54B2@MAIL01.insight.ds> Message-ID: I think that most electric utilities are much smarter than they appear to be getting credit for in this thread; even though this may be a newer evolution for them. Most utilities in North America are becoming very much aware of these addressing issues as a result of Critical Infrastructure Protection regulations and the implementation of mandated cyber security regimes. Our clients are looking at IPv6 as the natural course of development rather than IPv4. Many already support dual stacks on their networks today. I am very much opposed to this Chicken Little approach to a special policy that bans public access to utility companies for Smart Grid applications. It's unnecessary and unduly discriminatory. I believe that we'll run out of IPv4 addresses long before the Smart Grid applications become a widespread consumer of public IP addresses. Mikel Kline Sega Inc. From tedm at ipinc.net Tue Oct 6 10:56:33 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 06 Oct 2009 07:56:33 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <86ocoluy7u.fsf@seastrom.com> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> <4ACA74BB.4060001@ipinc.net> <86ocoluy7u.fsf@seastrom.com> Message-ID: <4ACB5AA1.90202@ipinc.net> Robert E. Seastrom wrote: > t there is a compelling case for globally unique > addresses on power meters - outsourcing of bill generation and > collection. The utility metering schemes - such as the sensus scheme I posted that is in operation, on real live gear - clearly have the meters on a completely private network. The cost to putting that network on the Internet would be more than just extending a private circuit from it to a 3rd party billing org. I realize someone could probably make a case for putting your refrigerator on the Internet. But, just because you can do something, doesn't mean you should do something. If you can come up with an actual in-production scheme that in in service in a utility in the United States that has the meters on the public Internet, with each meter running it's own IP address, then I'll agree you have a point, otherwise I think the supposition is as ridiculous as putting your refrigerator on the Internet. No wonder you don't want to discuss PGE. There's a gulf between theory and implementation, and this chicken-little scenario concerns theory. As the guy from the Midwest said, "Show me!" > It's also not uncommon for a utility to have a > sufficiently large number of meters that they won't all fit in > 10.0.0.0/8 even assuming really optimistic subnet engineering. > Even more reason to not assign IP addressing to the meters themselves. In the Sensus scheme the online literature on it only says the antenna controller that all the meters report to in a given area has an IP address on it. Ted From michael.dillon at bt.com Tue Oct 6 11:01:25 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 16:01:25 +0100 Subject: [arin-ppml] Straw poll on special policy for electric energyindustry In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745803745B74@E03MVZ2-UKDY.domain1.systemhost.net> > Most > utilities in North America are becoming very much aware of > these addressing issues as a result of Critical > Infrastructure Protection regulations and the implementation > of mandated cyber security regimes. Our clients are looking > at IPv6 as the natural course of development rather than > IPv4. Many already support dual stacks on their networks today. Anecdotal evidence indicates that while SOME people in the electric utility industry are aware of this, there are a lot who are not aware and the awareness is not embedded in their organizational memories yet. Note that dual stack is just as bad as plain IPv4 in this context because there will not be enough IPv4 addresses to dual-stack the whole Smart Grid. > I am very much opposed to this Chicken Little approach to a > special policy that bans public access to utility companies > for Smart Grid applications. > It's unnecessary and unduly discriminatory. Perhaps policy is unecessary, but publicity is not. And this proposed policy is NOT unduly discriminatory. It is, in fact, duly and specifically discriminatory based on the reality that we DO NOT HAVE enough IPv4 addresses to populate the whole of the Smart Grid, and that giving the electric utilities a big chunk of what is left, would impose undue hardship on the Internet industry as a whole. Fact is, that everybody is expecting IPv4 to last another couple of years and many of us have been testing and trialing IPv6 with that date in mine. If the Smart Grid folks come along and take a big chunk of address space, that will bring the date forward materially. In any case, there is no need to actually create this policy because even if the Smart Grid folks show up tomorrow and fully justify their /7 allocation, many ISPs will be applying for injunctions against them, and ARIN before the week is out. > I believe that we'll run out of IPv4 addresses long before > the Smart Grid applications become a widespread consumer of > public IP addresses. In which case, the Smart Grid folks should be happy to support a policy which bans them from receiving globally registered IPv4 addresses since it makes the road ahead much clearer. They can focus on IPv6 only, and drop the complexities of IPv4 and dual stack. --Michael Dillon From michael.dillon at bt.com Tue Oct 6 11:10:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 16:10:27 +0100 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <4ACB5AA1.90202@ipinc.net> Message-ID: <28E139F46D45AF49A31950F88C49745803745BB0@E03MVZ2-UKDY.domain1.systemhost.net> > I realize someone could probably make a case for putting your > refrigerator on the Internet. But, just because you can do > something, doesn't mean you should do something. "On the Internet" doesn't necessarily mean what you think. When 100% of homes and businesses have fixed-line Internet connectivity by fiber or copper, does it make sense to run more wires just for the meter? Of course not! "One the Internet" might mean addressable on the IPv6 Internet so that they can access it via Tinc or some similar VPN system. Yes, I know that we do not have 100% connectivity today, but that is the way that things are headed. Give it another 20 years, and the only buildings with no fixed-line Internet connectivity in North America will be the ones that are not on the electric grid. > If you can come up with an actual in-production scheme that > in in service in a utility in the United States that has the > meters on the public Internet, with each meter running it's > own IP address, then I'll agree you have a point, otherwise I > think the supposition is as ridiculous as putting your > refrigerator on the Internet. I never said that Smart Grid was more than a plan today. It is a dangerous plan that could end up being accelerated at great detriment to us in the next couple of years. On the other hand if we act now, we can prevent the damage and help the Smart Grid folks to put their effort and resources in the right technology, namely IPv6. I make no secret about this banning policy being a premptive strike to prevent a POTENTIAL future problem, not an actual present day problem. --Michael Dillon From tedm at ipinc.net Tue Oct 6 12:20:05 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 06 Oct 2009 09:20:05 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <28E139F46D45AF49A31950F88C49745803745BB0@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803745BB0@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4ACB6E35.6030506@ipinc.net> michael.dillon at bt.com wrote: >> I realize someone could probably make a case for putting your >> refrigerator on the Internet. But, just because you can do >> something, doesn't mean you should do something. > > "On the Internet" doesn't necessarily mean what you think. When > 100% of homes and businesses have fixed-line Internet connectivity > by fiber or copper, does it make sense to run more wires just for > the meter? Of course not! > It doesn't - but the Sensus setup - a setup that is INSTALLED in utilities today - uses a wireless transmitter and the meters have little wireless bits in them. I think PGE said they covered my entire city with 12 transmitters. According to the Sensus docs, the transmitters have IP on them. But I can't find anything on their website that shows the actual meters do. (the announcement you linked earlier does NOT indicate specifically where the IP is put) Given the number of subscribers in the city it's clear the ratio between transmitters and meters is very high, I would guess the system has the capability of several thousand meters per transmitter. This kind of star topology does not lend itself to unique IPv4 at the endpoints. While I agree with you that it makes much more sense to have the meters use a local ethernet connection to a shared DSL line in the home or business, that's a technical decision, not a business one. The business decision is the opposite - since doing it the technically sensible way puts the control of the meter access in the hands of the home or business owner, and I'm sure no utility is the least bit interested in that. Utilities in general are already not happy with owners having control over physical access to the meter, due to potential for interference with the meter readers, one of the selling points of this system is that it removes that potential for interference. Don't forget that business and technical reasoning is often at odds. For example from a technical viewpoint, it makes perfect sense to have the battery in an Apple macbook, be user replaceable so the user can just go to any store and buy a battery when theirs wears out - this is how every other laptop on Earth works. But from a business viewpoint, it makes sense to NOT have that battery user-replaceable if your users are dumb enough to allow you to do this, so that you can vastly overcharge your users for replacing the battery, and funnel money to your local dealers, that's why in the 2009 Macbook, Apple did this, it's also why Apple did it with the iphone, ipod, etc. > "One the Internet" might mean addressable on the IPv6 Internet > so that they can access it via Tinc > or some similar VPN system. > > Yes, I know that we do not have 100% connectivity today, but that > is the way that things are headed. Give it another 20 years, and > the only buildings with no fixed-line Internet connectivity in > North America will be the ones that are not on the electric > grid. > >> If you can come up with an actual in-production scheme that >> in in service in a utility in the United States that has the >> meters on the public Internet, with each meter running it's >> own IP address, then I'll agree you have a point, otherwise I >> think the supposition is as ridiculous as putting your >> refrigerator on the Internet. > > I never said that Smart Grid was more than a plan today. No, you didn't. But, it IS more than a plan today, today it's installed, and IN PRODUCTION at least, in my own home with my own utility. > It is > a dangerous plan that could end up being accelerated at great > detriment to us in the next couple of years. On the other hand > if we act now, we can prevent the damage and help the Smart Grid > folks to put their effort and resources in the right technology, > namely IPv6. > And I said you need to look at what the Smart Grid people have actually INSTALLED and HAVE RUNNING in REAL LIFE UTILITIES in large cities, before getting worried about it. > I make no secret about this banning policy being a premptive > strike to prevent a POTENTIAL future problem, not an actual > present day problem. > I think your overly focused on electric utilities and I think targeting an industry is the wrong approach. What makes a lot of sense is what Bill said, which is a ban on IPv4 address allocations for _embedded systems_ of any sort that do not function as publicly accessible Internet servers. An electric utility that did publicly-number every meter would easily fit that, as would a great many other hair-brained schemes (like the IP address on the refrigerator deal) that IMHO have no real need to even be deployed at all. Ted From michael.dillon at bt.com Tue Oct 6 12:35:11 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 17:35:11 +0100 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <4ACB6E35.6030506@ipinc.net> Message-ID: <28E139F46D45AF49A31950F88C49745803745D1C@E03MVZ2-UKDY.domain1.systemhost.net> > I think your overly focused on electric utilities and I think > targeting an industry is the wrong approach. What makes a > lot of sense > is what Bill said, which is a ban on IPv4 address allocations for > _embedded systems_ of any sort that do not function as publicly > accessible Internet servers. > > An electric utility that did publicly-number every meter would > easily fit that, as would a great many other hair-brained schemes > (like the IP address on the refrigerator deal) that IMHO have no > real need to even be deployed at all. Fair enough, a ban on globally unique IPv4 addresses for any embedded system applications seems more reasonable than targeting one type of usage (Smart Grid) for embedded systems. One example that I have seen of using globally registered IPv6 addresses for nothing more than the uniqueness of the number, was printing out RFID tags on a special inkjet printer. With just one /64 subnet allocation you could print, and discard RFID tags with globally unique registered IPv6 addresses as identifiers, and you would grow old and grey before you used up the 18.4 billion billion numbers in that single /64 block. So wierd and whacky embedded system ideas really should be looking at IPv6 today. Because with IPv6, we really do have plenty of address space to accomodate these ideas without thinking twice about it. --Michael Dillon From kkargel at polartel.com Tue Oct 6 12:43:06 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 6 Oct 2009 11:43:06 -0500 Subject: [arin-ppml] Straw poll on special policy for electric energyindustry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A339@mail> I have strong objections to implementing restrictive policy because of intended use or the perceived planning ability of the netadmin. Are you seriously suggesting that we should blacklist a consumer because they want to make plans to consume IP addresses?? Ar you suggesting that the electric company should be denied a large block of IP addresses when when large blocks have been granted to spammers and porn distributors? ARIN is a registry, as such we do not have the mission of dictating internal network policy. I think education and IPv6 assistance is the proper avenue to take if the facts are as represented. The electric utilities will figure out soon enough that public IPv4 is not a feasible communications vehicle. Best regards, Kevin Kargel > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Monday, October 05, 2009 4:51 PM > To: ppml at arin.net > Subject: [arin-ppml] Straw poll on special policy for electric > energyindustry > > > This is just a question to see what people think about creating a > special policy that applies to companies wishing to provide > infrastructure for the electric utility industry Smart Grid. > > Basically, the situation is this as described by Richard Shockey on the > IETF list: > > Myself and others are deeply concerned by how this effort is > developing. > There is no current consensus on what the communications architecture > of the > SmartGrid is or how IP actually fits into it. > > The Utility Industry does not understand the current IPv4 number > exhaust > problem and the consequences of that if they want to put a IP address > on > every Utility Meter in North America. > > What is equally troubling is that many of the underlying protocols > that > utilities wish to deploy are not engineered for IPv6. We have an > example of > that in a recent ID. > > Basically, what I am suggesting is that we introduce a special policy > that > bans the Electric Utility industry from receiving any IPv4 addressing at > all, > either direct ARIN allocations or ISP assignments, if those addresses > are intended > for any kind of Smart Grid application. This ban would also apply to > third parties > and subcontractors who might be operating components of the Smart Grid. > > Note that this special policy would not apply to any other use of IP in > an > electric utility company, only to the Smart Grid. > > This would send a clear message to the utility industry that there is > simply not enough IPv4 address space left for a new major user, and > would > help them get their plans around IPv6 worked out earlier, rather than > wasting their time and money on something that will NEVER fly. > > Seems to me this fits well within ARIN's educational purpose. > > If possible, we should try to word this policy in such a way that it > could be adopted by the other RIRs because the Smart Grid movement is > now world wide. > > --Michael Dillon > _______________________________________________ > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From tedm at ipinc.net Tue Oct 6 12:55:01 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 06 Oct 2009 09:55:01 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energyindustry In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A339@mail> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A339@mail> Message-ID: <4ACB7665.6050806@ipinc.net> Kevin, The entire ARIN justification scheme for address assignment is based on the intended use or perceived planning ability of the netadmin. TCP/IP addresses have ALWAYS been assigned based on projected utilization, which is as close to intended use or perceived planning ability of the netadmin as you can get. The utilization that Michael is concerned about, if it happened, would be an order of magnitude larger than spammers and porn distributors - I daresay that every spammer and porn distributor on the Internet today could fit into just a single assignment made to an entity that planned on using public IPv4 in a widely distributed embedded device. (such as a refrigerator) Ted Kevin Kargel wrote: > I have strong objections to implementing restrictive policy because of > intended use or the perceived planning ability of the netadmin. > > Are you seriously suggesting that we should blacklist a consumer because > they want to make plans to consume IP addresses?? Ar you suggesting that > the electric company should be denied a large block of IP addresses when > when large blocks have been granted to spammers and porn distributors? > > ARIN is a registry, as such we do not have the mission of dictating internal > network policy. > > I think education and IPv6 assistance is the proper avenue to take if the > facts are as represented. The electric utilities will figure out soon > enough that public IPv4 is not a feasible communications vehicle. > > > > > Best regards, > Kevin Kargel > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of michael.dillon at bt.com >> Sent: Monday, October 05, 2009 4:51 PM >> To: ppml at arin.net >> Subject: [arin-ppml] Straw poll on special policy for electric >> energyindustry >> >> >> This is just a question to see what people think about creating a >> special policy that applies to companies wishing to provide >> infrastructure for the electric utility industry Smart Grid. >> >> Basically, the situation is this as described by Richard Shockey on the >> IETF list: >> >> Myself and others are deeply concerned by how this effort is >> developing. >> There is no current consensus on what the communications architecture >> of the >> SmartGrid is or how IP actually fits into it. >> >> The Utility Industry does not understand the current IPv4 number >> exhaust >> problem and the consequences of that if they want to put a IP address >> on >> every Utility Meter in North America. >> >> What is equally troubling is that many of the underlying protocols >> that >> utilities wish to deploy are not engineered for IPv6. We have an >> example of >> that in a recent ID. >> >> Basically, what I am suggesting is that we introduce a special policy >> that >> bans the Electric Utility industry from receiving any IPv4 addressing at >> all, >> either direct ARIN allocations or ISP assignments, if those addresses >> are intended >> for any kind of Smart Grid application. This ban would also apply to >> third parties >> and subcontractors who might be operating components of the Smart Grid. >> >> Note that this special policy would not apply to any other use of IP in >> an >> electric utility company, only to the Smart Grid. >> >> This would send a clear message to the utility industry that there is >> simply not enough IPv4 address space left for a new major user, and >> would >> help them get their plans around IPv6 worked out earlier, rather than >> wasting their time and money on something that will NEVER fly. >> >> Seems to me this fits well within ARIN's educational purpose. >> >> If possible, we should try to word this policy in such a way that it >> could be adopted by the other RIRs because the Smart Grid movement is >> now world wide. >> >> --Michael Dillon >> _______________________________________________ >> 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. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 stephen at sprunk.org Tue Oct 6 12:53:32 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 06 Oct 2009 11:53:32 -0500 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4ACB760C.7060301@sprunk.org> michael.dillon at bt.com wrote: > Basically, what I am suggesting is that we introduce a special policy > that bans the Electric Utility industry from receiving any IPv4 addressing at all, either direct ARIN allocations or ISP assignments, if those addresses are intended for any kind of Smart Grid application. This ban would also apply to third parties and subcontractors who might be operating components of the Smart Grid. > I would oppose any solution specifically designed to present a special barrier to market entry for a particular company, industry, etc. That is blatantly anti-competitive. If we were to say that certain uses of addresses were not considered "justification", such as assigning IPv4 addresses to individual electric meters, that is somewhat defensible, but still wrong IMHO. Who are you/we to say that their use is any less valid than putting IP addresses on refrigerators? OTOH, I would support adopting a maximum allocation/assignment per org per annum; such a limit would apply to _all_ registrants and, given the impending exhaustion, has obvious technical justification. That such a limit would prevent certain people from doing certain stupid things is a side benefit. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From michael.dillon at bt.com Tue Oct 6 13:00:14 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 18:00:14 +0100 Subject: [arin-ppml] Straw poll on special policy for electric energyindustry In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A339@mail> Message-ID: <28E139F46D45AF49A31950F88C49745803745D58@E03MVZ2-UKDY.domain1.systemhost.net> > Are you seriously suggesting that we should blacklist a > consumer because they want to make plans to consume IP > addresses?? No. > Are you suggesting that the electric company > should be denied a large block of IP addresses when when > large blocks have been granted to spammers and porn distributors? Yes. > ARIN is a registry, as such we do not have the mission of > dictating internal network policy. ARIN's IPv4 policy has always been intended to flow through to providers' assignment policy, i.e. based on technical need. --Michael Dillon From tchristell at springnet.net Tue Oct 6 12:52:25 2009 From: tchristell at springnet.net (Todd Christell) Date: Tue, 6 Oct 2009 11:52:25 -0500 Subject: [arin-ppml] Straw poll on special policy for electric energyindustry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <56561F93336C3146836FDDE7831615469E803A@SPRINGNET-EX.springnet.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, As a metro network provider that is part of a municipal utility I can affirm that the observations are spot on. But it's a little worse than that, since we also want to meter gas and water meters. Not part of "Smart Grid" but part of AMI. So now we want 3 globally routed addresses per customer. The stimulus packages have pretty much closed down the AMI/Smart Grid suppliers that have proprietary systems, open (IP) systems are a requirement. The addresses need to be globally routable so that the Google PowerMeters of the world can get to our customers. I have been pushing IPv6 as a requirement in our RFP every chance I get. I agree that there should be some sort of control, this could be the "run on the bank" that will change the second derivative of the demand curve. tlc Todd Christell Manager Network Architecture and Support www.springnet.net 417.831.8688 Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 - -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Monday, October 05, 2009 4:51 PM To: ppml at arin.net Subject: [arin-ppml] Straw poll on special policy for electric energyindustry This is just a question to see what people think about creating a special policy that applies to companies wishing to provide infrastructure for the electric utility industry Smart Grid. Basically, the situation is this as described by Richard Shockey on the IETF list: Myself and others are deeply concerned by how this effort is developing. There is no current consensus on what the communications architecture of the SmartGrid is or how IP actually fits into it. The Utility Industry does not understand the current IPv4 number exhaust problem and the consequences of that if they want to put a IP address on every Utility Meter in North America. What is equally troubling is that many of the underlying protocols that utilities wish to deploy are not engineered for IPv6. We have an example of that in a recent ID. Basically, what I am suggesting is that we introduce a special policy that bans the Electric Utility industry from receiving any IPv4 addressing at all, either direct ARIN allocations or ISP assignments, if those addresses are intended for any kind of Smart Grid application. This ban would also apply to third parties and subcontractors who might be operating components of the Smart Grid. Note that this special policy would not apply to any other use of IP in an electric utility company, only to the Smart Grid. This would send a clear message to the utility industry that there is simply not enough IPv4 address space left for a new major user, and would help them get their plans around IPv6 worked out earlier, rather than wasting their time and money on something that will NEVER fly. Seems to me this fits well within ARIN's educational purpose. If possible, we should try to word this policy in such a way that it could be adopted by the other RIRs because the Smart Grid movement is now world wide. - --Michael Dillon _______________________________________________ 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. -----BEGIN PGP SIGNATURE----- Version: 9.10.0 (Build 500) Charset: utf-8 wj8DBQFKy3XMpX6SNVIC1QgRAtdoAJ9Y5ZgNT/Q4XWgPkrGBwo9gBStq4wCeILIq G0OzRqkKKRlLoDfpaQCw5Kg= =OGqT -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf Type: text/x-vcard Size: 548 bytes Desc: Christell Todd.vcf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf.sig Type: application/octet-stream Size: 190 bytes Desc: not available URL: From rudi.daniel at gmail.com Tue Oct 6 13:04:35 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Tue, 6 Oct 2009 13:04:35 -0400 Subject: [arin-ppml] Straw Poll Message-ID: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> I am really trying to understanding the point of a straw poll based on IPv4, a dodo of a resource?? Am I correct in thinking that any industry planning to use a dodo will probably join the extinct species too. :) Rudi Daniel > > Message: 1 > Date: Tue, 6 Oct 2009 11:21:27 +0100 > From: > To: > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: > < > 28E139F46D45AF49A31950F88C497458037454DE at E03MVZ2-UKDY.domain1.systemhost.net > > > > Content-Type: text/plain; charset="us-ascii" > > > If your interested in such a policy I would suggest you > > contact Sensus http://www.sensus.com/ who supplied the meters > > that PGE used, and ask them if they use IP addressing. > > PGE uses AMI meters using FlexNet: > > They do. > > Sensus Announces IP-based Smart Grid for FlexNet > Industry-leading FlexNet Solution addresses IPv4 and IPv6 endpoints on > powerful > and secure, licensed band, wireless Smart Grid and AMI Network > > The purpose of such a policy is to protect the rest of the IP using > organizations from new entrants who want to use LARGE AMOUNTS of > IPv4 addresses. We have already reached the end game of IPv4. There > is not enough left for everybody. Those who already have IPv4 network > dependencies should be served first by ARIN, and the rest should use > IPv6. That is the reason for banning the entire Smart Grid industry > from receiving globally registered IPv4 addresses. Of course, they > can use all the RFC 1918 IPv4 addresses that they want, and they can > get all the globally registered IPv6 addresses that they want. > > But the IPv4 watering is almost dried up and they are not welcome > to join us. > > --Michael Dillon > > P.S. this is only a straw poll discussion at present, to see how > people feel about an industry whose plans could cause IPv4 runout > to happen suddenly with only a couple of months notice. > > > > ------------------------------ > > Message: 2 > Date: Tue, 06 Oct 2009 07:31:29 -0700 > From: Ted Mittelstaedt > To: William Herrin > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: <4ACB54C1.1050109 at ipinc.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > William Herrin wrote: > > On Mon, Oct 5, 2009 at 5:50 PM, wrote: > >> Basically, what I am suggesting is that we introduce a special policy > >> that bans the Electric Utility industry from receiving any IPv4 > >> addressing at all, either direct ARIN allocations or ISP assignments, > >> if those addresses are intended for any kind of Smart Grid > >> application. > > > > Michael, > > > > I would not support a ban that targets a single industry but I would > > support a ban on IPv4 address allocations for _embedded systems_ of > > any sort that do not function as publicly accessible Internet servers. > > To include cell phones and game consoles. And a cut-off date by which > > folks holding public addresses for such a purpose must recover and > > reallocate those addresses before they can get any more from ARIN. > > > > I like this approach as well. > > Ted > > > ------------------------------ > > Message: 3 > Date: Tue, 6 Oct 2009 09:33:26 -0500 > From: "Mikel Kline" > To: > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > I think that most electric utilities are much smarter than they appear to > be > getting credit for in this thread; even though this may be a newer > evolution > for them. Most utilities in North America are becoming very much aware of > these addressing issues as a result of Critical Infrastructure Protection > regulations and the implementation of mandated cyber security regimes. Our > clients are looking at IPv6 as the natural course of development rather > than > IPv4. Many already support dual stacks on their networks today. > > I am very much opposed to this Chicken Little approach to a special policy > that bans public access to utility companies for Smart Grid applications. > It's unnecessary and unduly discriminatory. > > I believe that we'll run out of IPv4 addresses long before the Smart Grid > applications become a widespread consumer of public IP addresses. > > > > Mikel Kline > Sega Inc. > > > > ------------------------------ > > Message: 4 > Date: Tue, 06 Oct 2009 07:56:33 -0700 > From: Ted Mittelstaedt > To: "Robert E. Seastrom" > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: <4ACB5AA1.90202 at ipinc.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Robert E. Seastrom wrote: > > > t there is a compelling case for globally unique > > addresses on power meters - outsourcing of bill generation and > > collection. > > The utility metering schemes - such as the sensus > scheme I posted that is in operation, on real live gear - clearly > have the meters on a completely private network. The cost to > putting that network on the Internet would be more than just > extending a private circuit from it to a 3rd party billing > org. > > I realize someone could probably make a case for putting your > refrigerator on the Internet. But, just because you can do > something, doesn't mean you should do something. > > If you can come up with an actual in-production scheme that > in in service in a utility in the United States that has the > meters on the public Internet, with each meter running it's > own IP address, then I'll agree you have a point, otherwise I > think the supposition is as ridiculous as putting your > refrigerator on the Internet. > > No wonder you don't want to discuss PGE. There's a gulf between > theory and implementation, and this chicken-little scenario > concerns theory. > > As the guy from the Midwest said, "Show me!" > > > It's also not uncommon for a utility to have a > > sufficiently large number of meters that they won't all fit in > > 10.0.0.0/8 even assuming really optimistic subnet engineering. > > > > Even more reason to not assign IP addressing to the meters > themselves. In the Sensus scheme the online literature on it only > says the antenna controller that all the meters report to in a > given area has an IP address on it. > > Ted > > > ------------------------------ > > Message: 5 > Date: Tue, 6 Oct 2009 16:01:25 +0100 > From: > To: > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energyindustry > Message-ID: > < > 28E139F46D45AF49A31950F88C49745803745B74 at E03MVZ2-UKDY.domain1.systemhost.net > > > > Content-Type: text/plain; charset="us-ascii" > > > Most > > utilities in North America are becoming very much aware of > > these addressing issues as a result of Critical > > Infrastructure Protection regulations and the implementation > > of mandated cyber security regimes. Our clients are looking > > at IPv6 as the natural course of development rather than > > IPv4. Many already support dual stacks on their networks today. > > Anecdotal evidence indicates that while SOME people in the > electric utility industry are aware of this, there are a lot > who are not aware and the awareness is not embedded in their > organizational memories yet. Note that dual stack is just as > bad as plain IPv4 in this context because there will not be > enough IPv4 addresses to dual-stack the whole Smart Grid. > > > I am very much opposed to this Chicken Little approach to a > > special policy that bans public access to utility companies > > for Smart Grid applications. > > It's unnecessary and unduly discriminatory. > > Perhaps policy is unecessary, but publicity is not. > And this proposed policy is NOT unduly discriminatory. It is, > in fact, duly and specifically discriminatory based on the > reality that we DO NOT HAVE enough IPv4 addresses to populate > the whole of the Smart Grid, and that giving the electric > utilities a big chunk of what is left, would impose undue > hardship on the Internet industry as a whole. > > Fact is, that everybody is expecting IPv4 to last another > couple of years and many of us have been testing and trialing > IPv6 with that date in mine. If the Smart Grid folks come > along and take a big chunk of address space, that will bring > the date forward materially. > > In any case, there is no need to actually create this policy > because even if the Smart Grid folks show up tomorrow and > fully justify their /7 allocation, many ISPs will be applying > for injunctions against them, and ARIN before the week is out. > > > I believe that we'll run out of IPv4 addresses long before > > the Smart Grid applications become a widespread consumer of > > public IP addresses. > > In which case, the Smart Grid folks should be happy to support > a policy which bans them from receiving globally registered > IPv4 addresses since it makes the road ahead much clearer. They > can focus on IPv6 only, and drop the complexities of IPv4 and > dual stack. > > --Michael Dillon > > > ------------------------------ > > Message: 6 > Date: Tue, 6 Oct 2009 16:10:27 +0100 > From: > To: > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: > < > 28E139F46D45AF49A31950F88C49745803745BB0 at E03MVZ2-UKDY.domain1.systemhost.net > > > > Content-Type: text/plain; charset="us-ascii" > > > I realize someone could probably make a case for putting your > > refrigerator on the Internet. But, just because you can do > > something, doesn't mean you should do something. > > "On the Internet" doesn't necessarily mean what you think. When > 100% of homes and businesses have fixed-line Internet connectivity > by fiber or copper, does it make sense to run more wires just for > the meter? Of course not! > > "One the Internet" might mean addressable on the IPv6 Internet > so that they can access it via Tinc > or some similar VPN system. > > Yes, I know that we do not have 100% connectivity today, but that > is the way that things are headed. Give it another 20 years, and > the only buildings with no fixed-line Internet connectivity in > North America will be the ones that are not on the electric > grid. > > > If you can come up with an actual in-production scheme that > > in in service in a utility in the United States that has the > > meters on the public Internet, with each meter running it's > > own IP address, then I'll agree you have a point, otherwise I > > think the supposition is as ridiculous as putting your > > refrigerator on the Internet. > > I never said that Smart Grid was more than a plan today. It is > a dangerous plan that could end up being accelerated at great > detriment to us in the next couple of years. On the other hand > if we act now, we can prevent the damage and help the Smart Grid > folks to put their effort and resources in the right technology, > namely IPv6. > > I make no secret about this banning policy being a premptive > strike to prevent a POTENTIAL future problem, not an actual > present day problem. > > --Michael Dillon > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 52, Issue 4 > **************************************** > -- Rudi Daniel Independent Consultants http://www.svgpso.org http://danielcharles.weebly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred at cisco.com Tue Oct 6 13:08:47 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Oct 2009 10:08:47 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <0FACF1F4-9DE3-4415-BB43-D7E4FEC5AB97@cisco.com> My two yen... I'm very much in favor of having the electric industry use IPv6, for the same reason I'm interested in seeing the Internet deploy it. I would suggest a slightly different policy, however, as there is current use of IPv4 in the grid that one doesn't want to disrupt any more than one would want to disrupt a currently functioning ISP by suddenly refusing it IPv4 addresses. The policy I would suggest is a blanket policy: IPv4 addresses are available to ARIN members if and only if they can demonstrate progress on IPv6 deployment. Such progress would include equipment configured, routing, customers turning it on, and so on. On Oct 5, 2009, at 2:50 PM, wrote: > > This is just a question to see what people think about creating a > special policy that applies to companies wishing to provide > infrastructure for the electric utility industry Smart Grid. > > Basically, the situation is this as described by Richard Shockey on > the > IETF list: > > Myself and others are deeply concerned by how this effort is > developing. > There is no current consensus on what the communications > architecture > of the > SmartGrid is or how IP actually fits into it. > > The Utility Industry does not understand the current IPv4 number > exhaust > problem and the consequences of that if they want to put a IP > address > on > every Utility Meter in North America. > > What is equally troubling is that many of the underlying protocols > that > utilities wish to deploy are not engineered for IPv6. We have an > example of > that in a recent ID. > > Basically, what I am suggesting is that we introduce a special policy > that > bans the Electric Utility industry from receiving any IPv4 > addressing at > all, > either direct ARIN allocations or ISP assignments, if those addresses > are intended > for any kind of Smart Grid application. This ban would also apply to > third parties > and subcontractors who might be operating components of the Smart > Grid. > > Note that this special policy would not apply to any other use of IP > in > an > electric utility company, only to the Smart Grid. > > This would send a clear message to the utility industry that there is > simply not enough IPv4 address space left for a new major user, and > would > help them get their plans around IPv6 worked out earlier, rather than > wasting their time and money on something that will NEVER fly. > > Seems to me this fits well within ARIN's educational purpose. > > If possible, we should try to word this policy in such a way that it > could be adopted by the other RIRs because the Smart Grid movement is > now world wide. > > --Michael Dillon > _______________________________________________ > 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 kkargel at polartel.com Tue Oct 6 13:23:35 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 6 Oct 2009 12:23:35 -0500 Subject: [arin-ppml] Straw poll on special policy for electricenergyindustry In-Reply-To: <56561F93336C3146836FDDE7831615469E803A@SPRINGNET-EX.springnet.local> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> <56561F93336C3146836FDDE7831615469E803A@SPRINGNET-EX.springnet.local> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A33B@mail> If we really want to be proactive about this perhaps we should appoint a committee to contact the cognitive parties and arrange to reserve a block of IPv6 sufficient to their needs.. On a project of this scale it may be appropriate to permit special considerations for routing pico-allocations of IPv6 within a special netblock. This would be beyond the scope of ARIN and would require working with standards organizations. I can certainly see justification for working out a plan to allow something like 8 or 16 least significant bits of unique globally routable address space for every metered premise for the express purpose of utility comms. I will admit I am somewhat ignorant in that I have no idea what order of magnitude the global quantity of unique metered premises is. Quantifying that number will certainly have bearing on any plan. I assert that any plan that is made needs to be globally workable, and not custom fit to PG&E or any other individual corporate template. This should not be limited to electric service, but should be a shared resource available to all utility services. This seems like an appropriate time to lay the foundation for a new enterprise. It certainly makes more sense than trying to build defenses to thwart a necessary and inevitable public service. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From fred at cisco.com Tue Oct 6 13:26:51 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Oct 2009 10:26:51 -0700 Subject: [arin-ppml] Straw Poll In-Reply-To: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> Message-ID: On Oct 6, 2009, at 10:04 AM, RudOlph Daniel wrote: > Am I correct in thinking that any industry planning to use a dodo > will probably join the extinct species too. :) I agree with you, but let me reflect some comments I have heard from the Smart Grid side of the house. One thing they are very worried about is running the SG over the Internet. They are interested in control - the term "control freak" has been used - and they don't see the Internet as all that well controlled. That's not universal, of course; The Cisco/Yello thing in Germany uses a subscriber's broadband connection, I believe a DMVPN. But many do want direct connectivity to their customers and the ability to directly manage at least some appliances and instruments in subscriber's homes - notably the electric meter. From that perspective, they see the Smart Grid as a completely separate (even if occasionally an overlay on top of the) Internet. From that perspective, their view tends to be that they can completely re-use the existing IPv4 address space without colliding with the Internet. Not defending the viewpoint, reporting it. Don't shoot the messenger. What would probably be most helpful would be if ARIN and its members (separately) decided to comment on http://www.nist.gov/smartgrid/ and specifically http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf From bill at herrin.us Tue Oct 6 13:37:06 2009 From: bill at herrin.us (William Herrin) Date: Tue, 6 Oct 2009 13:37:06 -0400 Subject: [arin-ppml] Straw Poll In-Reply-To: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> Message-ID: <3c3e3fca0910061037q16e06c93y5a24b39ca0e5dd94@mail.gmail.com> On Tue, Oct 6, 2009 at 1:04 PM, RudOlph Daniel wrote: > I am really trying to understanding the point of a straw poll based on IPv4, > a dodo of a resource?? Am I correct in thinking that any industry planning > to use a dodo will probably join the extinct species too. :) Rudi, If you don't want any more IPv4 addresses, I think the rest of us can all agree not to give you any. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Tue Oct 6 13:47:12 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 06 Oct 2009 10:47:12 -0700 Subject: [arin-ppml] Straw Poll In-Reply-To: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> Message-ID: <4ACB82A0.2010004@ipinc.net> RudOlph Daniel wrote: > > I am really trying to understanding the point of a straw poll based on > IPv4, a dodo of a resource?? Am I correct in thinking that any industry > planning to use a dodo will probably join the extinct species too. :) > Not before shafting us with it. ARIN's justification for IPv4 does not deny a request from a gigantic consumer of it to be denied just because the consumer is doing something stupid. The fear is that if a gigantic request comes in right now that ARIN has no way in policy to deny it - and if ARIN honors it, then now IPv4 runout is tomorrow, not 2 years from now. The electric industry is being used as the scarecrow here just because what they are wanting to do with smartgrid (ie put a lot of remotely accessible meters out there) is easily understandable, even if they actually never do it precisely in the way we think they will, and never do make those gigantic requests for IPv4. But I think the risk is even more likely with some industry that none of us have ever heard anything about, suddenly jumping in with "this great idea" they have. I thus support a policy proposal along the lines that William Herrin was suggesting, and I'm hoping Michael or William will write one soon and send it in to ARIN so we can discuss it here, and it becomes part of the official record. Ted > Rudi Daniel > > > Message: 1 > Date: Tue, 6 Oct 2009 11:21:27 +0100 > From: > > To: > > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: > > <28E139F46D45AF49A31950F88C497458037454DE at E03MVZ2-UKDY.domain1.systemhost.net > > > > Content-Type: text/plain; charset="us-ascii" > > > If your interested in such a policy I would suggest you > > contact Sensus http://www.sensus.com/ who supplied the meters > > that PGE used, and ask them if they use IP addressing. > > PGE uses AMI meters using FlexNet: > > They do. > > Sensus Announces IP-based Smart Grid for FlexNet > Industry-leading FlexNet Solution addresses IPv4 and IPv6 endpoints on > powerful > and secure, licensed band, wireless Smart Grid and AMI Network > > The purpose of such a policy is to protect the rest of the IP using > organizations from new entrants who want to use LARGE AMOUNTS of > IPv4 addresses. We have already reached the end game of IPv4. There > is not enough left for everybody. Those who already have IPv4 network > dependencies should be served first by ARIN, and the rest should use > IPv6. That is the reason for banning the entire Smart Grid industry > from receiving globally registered IPv4 addresses. Of course, they > can use all the RFC 1918 IPv4 addresses that they want, and they can > get all the globally registered IPv6 addresses that they want. > > But the IPv4 watering is almost dried up and they are not welcome > to join us. > > --Michael Dillon > > P.S. this is only a straw poll discussion at present, to see how > people feel about an industry whose plans could cause IPv4 runout > to happen suddenly with only a couple of months notice. > > > > ------------------------------ > > Message: 2 > Date: Tue, 06 Oct 2009 07:31:29 -0700 > From: Ted Mittelstaedt > > To: William Herrin > > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: <4ACB54C1.1050109 at ipinc.net > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > William Herrin wrote: > > On Mon, Oct 5, 2009 at 5:50 PM, > wrote: > >> Basically, what I am suggesting is that we introduce a special > policy > >> that bans the Electric Utility industry from receiving any IPv4 > >> addressing at all, either direct ARIN allocations or ISP > assignments, > >> if those addresses are intended for any kind of Smart Grid > >> application. > > > > Michael, > > > > I would not support a ban that targets a single industry but I would > > support a ban on IPv4 address allocations for _embedded systems_ of > > any sort that do not function as publicly accessible Internet > servers. > > To include cell phones and game consoles. And a cut-off date by which > > folks holding public addresses for such a purpose must recover and > > reallocate those addresses before they can get any more from ARIN. > > > > I like this approach as well. > > Ted > > > ------------------------------ > > Message: 3 > Date: Tue, 6 Oct 2009 09:33:26 -0500 > From: "Mikel Kline" > > To: > > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > I think that most electric utilities are much smarter than they > appear to be > getting credit for in this thread; even though this may be a newer > evolution > for them. Most utilities in North America are becoming very much > aware of > these addressing issues as a result of Critical Infrastructure > Protection > regulations and the implementation of mandated cyber security > regimes. Our > clients are looking at IPv6 as the natural course of development > rather than > IPv4. Many already support dual stacks on their networks today. > > I am very much opposed to this Chicken Little approach to a special > policy > that bans public access to utility companies for Smart Grid > applications. > It's unnecessary and unduly discriminatory. > > I believe that we'll run out of IPv4 addresses long before the Smart > Grid > applications become a widespread consumer of public IP addresses. > > > > Mikel Kline > Sega Inc. > > > > ------------------------------ > > Message: 4 > Date: Tue, 06 Oct 2009 07:56:33 -0700 > From: Ted Mittelstaedt > > To: "Robert E. Seastrom" > > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: <4ACB5AA1.90202 at ipinc.net > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Robert E. Seastrom wrote: > > > t there is a compelling case for globally unique > > addresses on power meters - outsourcing of bill generation and > > collection. > > The utility metering schemes - such as the sensus > scheme I posted that is in operation, on real live gear - clearly > have the meters on a completely private network. The cost to > putting that network on the Internet would be more than just > extending a private circuit from it to a 3rd party billing > org. > > I realize someone could probably make a case for putting your > refrigerator on the Internet. But, just because you can do > something, doesn't mean you should do something. > > If you can come up with an actual in-production scheme that > in in service in a utility in the United States that has the > meters on the public Internet, with each meter running it's > own IP address, then I'll agree you have a point, otherwise I > think the supposition is as ridiculous as putting your > refrigerator on the Internet. > > No wonder you don't want to discuss PGE. There's a gulf between > theory and implementation, and this chicken-little scenario > concerns theory. > > As the guy from the Midwest said, "Show me!" > > > It's also not uncommon for a utility to have a > > sufficiently large number of meters that they won't all fit in > > 10.0.0.0/8 even assuming really optimistic > subnet engineering. > > > > Even more reason to not assign IP addressing to the meters > themselves. In the Sensus scheme the online literature on it only > says the antenna controller that all the meters report to in a > given area has an IP address on it. > > Ted > > > ------------------------------ > > Message: 5 > Date: Tue, 6 Oct 2009 16:01:25 +0100 > From: > > To: > > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energyindustry > Message-ID: > > <28E139F46D45AF49A31950F88C49745803745B74 at E03MVZ2-UKDY.domain1.systemhost.net > > > > Content-Type: text/plain; charset="us-ascii" > > > Most > > utilities in North America are becoming very much aware of > > these addressing issues as a result of Critical > > Infrastructure Protection regulations and the implementation > > of mandated cyber security regimes. Our clients are looking > > at IPv6 as the natural course of development rather than > > IPv4. Many already support dual stacks on their networks today. > > Anecdotal evidence indicates that while SOME people in the > electric utility industry are aware of this, there are a lot > who are not aware and the awareness is not embedded in their > organizational memories yet. Note that dual stack is just as > bad as plain IPv4 in this context because there will not be > enough IPv4 addresses to dual-stack the whole Smart Grid. > > > I am very much opposed to this Chicken Little approach to a > > special policy that bans public access to utility companies > > for Smart Grid applications. > > It's unnecessary and unduly discriminatory. > > Perhaps policy is unecessary, but publicity is not. > And this proposed policy is NOT unduly discriminatory. It is, > in fact, duly and specifically discriminatory based on the > reality that we DO NOT HAVE enough IPv4 addresses to populate > the whole of the Smart Grid, and that giving the electric > utilities a big chunk of what is left, would impose undue > hardship on the Internet industry as a whole. > > Fact is, that everybody is expecting IPv4 to last another > couple of years and many of us have been testing and trialing > IPv6 with that date in mine. If the Smart Grid folks come > along and take a big chunk of address space, that will bring > the date forward materially. > > In any case, there is no need to actually create this policy > because even if the Smart Grid folks show up tomorrow and > fully justify their /7 allocation, many ISPs will be applying > for injunctions against them, and ARIN before the week is out. > > > I believe that we'll run out of IPv4 addresses long before > > the Smart Grid applications become a widespread consumer of > > public IP addresses. > > In which case, the Smart Grid folks should be happy to support > a policy which bans them from receiving globally registered > IPv4 addresses since it makes the road ahead much clearer. They > can focus on IPv6 only, and drop the complexities of IPv4 and > dual stack. > > --Michael Dillon > > > ------------------------------ > > Message: 6 > Date: Tue, 6 Oct 2009 16:10:27 +0100 > From: > > To: > > Subject: Re: [arin-ppml] Straw poll on special policy for electric > energy industry > Message-ID: > > <28E139F46D45AF49A31950F88C49745803745BB0 at E03MVZ2-UKDY.domain1.systemhost.net > > > > Content-Type: text/plain; charset="us-ascii" > > > I realize someone could probably make a case for putting your > > refrigerator on the Internet. But, just because you can do > > something, doesn't mean you should do something. > > "On the Internet" doesn't necessarily mean what you think. When > 100% of homes and businesses have fixed-line Internet connectivity > by fiber or copper, does it make sense to run more wires just for > the meter? Of course not! > > "One the Internet" might mean addressable on the IPv6 Internet > so that they can access it via Tinc > or some similar VPN system. > > Yes, I know that we do not have 100% connectivity today, but that > is the way that things are headed. Give it another 20 years, and > the only buildings with no fixed-line Internet connectivity in > North America will be the ones that are not on the electric > grid. > > > If you can come up with an actual in-production scheme that > > in in service in a utility in the United States that has the > > meters on the public Internet, with each meter running it's > > own IP address, then I'll agree you have a point, otherwise I > > think the supposition is as ridiculous as putting your > > refrigerator on the Internet. > > I never said that Smart Grid was more than a plan today. It is > a dangerous plan that could end up being accelerated at great > detriment to us in the next couple of years. On the other hand > if we act now, we can prevent the damage and help the Smart Grid > folks to put their effort and resources in the right technology, > namely IPv6. > > I make no secret about this banning policy being a premptive > strike to prevent a POTENTIAL future problem, not an actual > present day problem. > > --Michael Dillon > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 52, Issue 4 > **************************************** > > > > > -- > Rudi Daniel > Independent Consultants > http://www.svgpso.org > http://danielcharles.weebly.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 kkargel at polartel.com Tue Oct 6 13:56:04 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 6 Oct 2009 12:56:04 -0500 Subject: [arin-ppml] Straw Poll In-Reply-To: References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A33F@mail> . > > From that perspective, they see the Smart Grid as a completely > separate (even if occasionally an overlay on top of the) Internet. > From that perspective, their view tends to be that they can > completely re-use the existing IPv4 address space without colliding > with the Internet. My question here is whether even a /0 of 32 bit space is enough to service a global scope of the plan with unique addresses. Of course they may be planning to implement the same /0 in multiple regions (continents?) and PAT between them if necessary. Not being privy to the plans leaves me only able to guess which is dangerous at best. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From dwhite at olp.net Tue Oct 6 14:26:10 2009 From: dwhite at olp.net (Dan White) Date: Tue, 6 Oct 2009 13:26:10 -0500 Subject: [arin-ppml] Straw Poll In-Reply-To: References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> Message-ID: <20091006182609.GF7127@dan.olp.net> On 06/10/09?10:26?-0700, Fred Baker wrote: > I agree with you, but let me reflect some comments I have heard from the > Smart Grid side of the house. > > One thing they are very worried about is running the SG over the > Internet. They are interested in control - the term "control freak" has > been used - and they don't see the Internet as all that well controlled. > That's not universal, of course; The Cisco/Yello thing in Germany uses a > subscriber's broadband connection, I believe a DMVPN. But many do want > direct connectivity to their customers and the ability to directly manage > at least some appliances and instruments in subscriber's homes - notably > the electric meter. Suppose they take that approach... everything's on a private network, including "approved" appliances. The meter reports current usage, and each appliance reports its need for energy, and what times of the day it need it - i.e. your futuristic electric car probably doesn't need to charge during peak hours. What happens when someone compromises their appliances, or their car, to game the system? Security won't be found in a private network or dependence on the ignorance of users, but in sound security principals. It shouldn't matter how the electric grid communicates - your home grid might choose to use your broadband connection is a backup communication medium. If properly managed and designed, it would be in a consumer's best interest to provide accurate information to the grid (because of pricing incentives). -- Dan White BTC Broadband From fred at cisco.com Tue Oct 6 14:31:54 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Oct 2009 11:31:54 -0700 Subject: [arin-ppml] Straw Poll In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A33F@mail> References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A33F@mail> Message-ID: On Oct 6, 2009, at 10:56 AM, Kevin Kargel wrote: > My question here is whether even a /0 of 32 bit space is enough to > service a global scope of the plan with unique addresses. I would tend to think not: if you assume that every person on the planet will have a smart grid device (if not the meter, then the refrigerator), there are more people on the planet than there are IPv4 addresses. There are also - of more practical importance from my perspective - requirements for O(5000) homes in a single AMI subnet. To my way of thinking, IPv6 is better suited from a variety of viewpoints. An important one is that of one of the electric utilities primary think tanks: EPRI. http://www.ietf.org/rfc/rfc1673.txt 1673 Electric Power Research Institute Comments on IPng. R. Skelton. August 1994. (Format: TXT=7476 bytes) (Status: INFORMATIONAL) The author of that really preferred OSI addressing. > 2. Basic Requirements. > - Scaleability > The addressing scheme must have essentially an unlimited address > space to encompass an arbitrarily large number of information > objects. Specifically it must solve the fundamental limitations of > 32 bit formats, a format for 20 octets and above is considered > suitable. His argument doesn't get me to 20 octets, but it certainly gets me above four. From kkargel at polartel.com Tue Oct 6 14:34:37 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 6 Oct 2009 13:34:37 -0500 Subject: [arin-ppml] Straw Poll In-Reply-To: <20091006182609.GF7127@dan.olp.net> References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> <20091006182609.GF7127@dan.olp.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A343@mail> We should really be embracing this scenario wholeheartedly. Right now in our laps is the killer app we have been looking for that will launch IPv6 into the mainstream. This will garner legislative support for overcoming obstacles. The carrot of huge contracts for connectivity should certainly spur the ISP's to move forward with native IPv6. Any connectivity for this purpose will of necessity need to be out-of-band as regards a consumers internet connectivity. While it would certainly be in the consumers best interest to facilitate such a network, mandating or legislating internet connectivity as a pre-requisite to utility connection is untenable. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Dan White > Sent: Tuesday, October 06, 2009 1:26 PM > To: Fred Baker > Cc: arin-ppml at arin.net; RudOlph Daniel > Subject: Re: [arin-ppml] Straw Poll > > On 06/10/09?10:26?-0700, Fred Baker wrote: > > I agree with you, but let me reflect some comments I have heard from the > > Smart Grid side of the house. > > > > One thing they are very worried about is running the SG over the > > Internet. They are interested in control - the term "control freak" has > > been used - and they don't see the Internet as all that well controlled. > > That's not universal, of course; The Cisco/Yello thing in Germany uses a > > subscriber's broadband connection, I believe a DMVPN. But many do want > > direct connectivity to their customers and the ability to directly > manage > > at least some appliances and instruments in subscriber's homes - notably > > the electric meter. > > Suppose they take that approach... everything's on a private network, > including "approved" appliances. The meter reports current usage, and each > appliance reports its need for energy, and what times of the day it need > it > - i.e. your futuristic electric car probably doesn't need to charge during > peak hours. > > What happens when someone compromises their appliances, or their car, to > game the system? > > Security won't be found in a private network or dependence on the > ignorance > of users, but in sound security principals. It shouldn't matter how the > electric grid communicates - your home grid might choose to use your > broadband connection is a backup communication medium. > > If properly managed and designed, it would be in a consumer's best > interest > to provide accurate information to the grid (because of pricing > incentives). > > -- > Dan White > BTC Broadband > _______________________________________________ > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From fred at cisco.com Tue Oct 6 14:40:32 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Oct 2009 11:40:32 -0700 Subject: [arin-ppml] Straw Poll In-Reply-To: <20091006182609.GF7127@dan.olp.net> References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> <20091006182609.GF7127@dan.olp.net> Message-ID: <6675D945-E6FF-466F-8D12-3C7117DCB0E3@cisco.com> On Oct 6, 2009, at 11:26 AM, Dan White wrote: > Security won't be found in a private network or dependence on the > ignorance > of users, but in sound security principals. It shouldn't matter how > the > electric grid communicates - your home grid might choose to use your > broadband connection is a backup communication medium. May I suggest that you make that comment in the context of the papers NIST is asking for comments on? You won't find disagreement from this quarter. From michael.dillon at bt.com Tue Oct 6 16:48:16 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 21:48:16 +0100 Subject: [arin-ppml] Straw Poll In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A343@mail> Message-ID: <28E139F46D45AF49A31950F88C49745803745DEC@E03MVZ2-UKDY.domain1.systemhost.net> > While it would certainly be in the consumers best interest to > facilitate such a network, mandating or legislating internet > connectivity as a pre-requisite to utility connection is untenable. Why? Nobody says that the consumer has to pay for Internet access over the Internet connection if they don't want to. If someone wants to live a 1940's style life, using the electric grid, then they have to have an Internet connection for the Smart Grid, and for 911 service, but nothing more. We already have the technology capable of operating a limited use IP network connection like this so the barriers to doing this are purely economic and policy issues. --Michael Dillon From cliffb at cjbsys.bdb.com Tue Oct 6 16:42:07 2009 From: cliffb at cjbsys.bdb.com (Cliff) Date: Tue, 6 Oct 2009 16:42:07 -0400 (EDT) Subject: [arin-ppml] [a-p] Straw poll on special policy for electric energy In-Reply-To: <28E139F46D45AF49A31950F88C497458037454DE@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <200910062042.n96Kg7Dp010212@cjbsys.bdb.com> > ........ deleted > > The purpose of such a policy is to protect the rest of the IP using > organizations from new entrants who want to use LARGE AMOUNTS of > IPv4 addresses. We have already reached the end game of IPv4. There > is not enough left for everybody. Those who already have IPv4 network > dependencies should be served first by ARIN, and the rest should use > IPv6. That is the reason for banning the entire Smart Grid industry > from receiving globally registered IPv4 addresses. Of course, they > can use all the RFC 1918 IPv4 addresses that they want, and they can > get all the globally registered IPv6 addresses that they want. > > But the IPv4 watering is almost dried up and they are not welcome > to join us. Why shouldn't they get first choice for getting numbers? You already have some and they don't. Who are you to say that because you have some numbers and they don't, you should get more and they can't have any? That seems very arbitrary and selfish. The group has been complaining about nobody converting to v6. Maybe if the power company came in and took the rest of the v4 addresses, people would be forced to change to v6. Given that nothing else has seemed to get the conversion going, maybe we need a shock point to make it happen. I'm not saying doing this is the best thing but I don't see any reason why a big consumer should be denied access to v4 just because they are a big consumer. If you can't convince them via system design/overwhelming logic that IPv6 is the best for them, there is truly no hope for v6 adoption. A little competition for IPv4 space might do for networking what Toyota/Honda/Nissan did for the quality of automobiles. FLAME RETARDANT SUIT ON Cliff > > --Michael Dillon > > P.S. this is only a straw poll discussion at present, to see how > people feel about an industry whose plans could cause IPv4 runout > to happen suddenly with only a couple of months notice. > > _______________________________________________ > 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. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From michael.dillon at bt.com Tue Oct 6 17:00:35 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 22:00:35 +0100 Subject: [arin-ppml] [a-p] Straw poll on special policy for electric energy In-Reply-To: <200910062042.n96Kg7Dp010212@cjbsys.bdb.com> Message-ID: <28E139F46D45AF49A31950F88C49745803745DF9@E03MVZ2-UKDY.domain1.systemhost.net> > Who are you to say that > because you have some numbers and they don't, you should get > more and they can't have any? Because the current IPv4 address holders are providing an important service that is dependent on a continued supply of IPv4 addresses for at least a couple more years until the transition picks up steam. And these newcomers, haven't got any NEED for IPv4, since they haven't actually built out their infrastructure, and everything that they want to do can be done with IPv6. In some cases they can do it better and cheaper with IPv6. > That seems very arbitrary and > selfish. ARIN's purpose is to be arbitrary and selfish. It is called "regulation" and it is not unlike making new laws. The main difference is that ARIN's activities are limited in scope (managing numbers) and that ARIN does its arbitrary and selfish allocation activity in public, in the open, with participation of all stakeholders who care to join in. > The group has been complaining about nobody > converting to v6. Maybe if the power company came in and > took the rest of the v4 addresses, people would be forced to > change to v6. Now that is arbitrary and selfish. It is also not something that ARIN could do because it is out of scope for ARIN as an organization. And it smacks of unilateral action to do this without openly discussing it with all stakeholders first. > I'm not saying doing this is the best thing but I don't see > any reason why a big consumer should be denied access to v4 > just because they are a big consumer. Numerically speaking, they would be a very big consumer, at least as big, if not bigger, than the cable industry. And they would set the mold for two other industries, gas and water, which will more than double the total consumption for this kind of use. In addition, if you count numbers in terms of the percentage of available unallocated IPv4 space globally, the electric utilities would be far larger than the largest ever use of IPv4 space in the past, which would be the US defense industry. > If you can't convince > them via system design/overwhelming logic that IPv6 is the > best for them, there is truly no hope for v6 adoption. "Convincing" is a political activity, not design and not engineering. Note that this is the ARIN public policy mailing list which means that anyone from the utility industries is more than welcome to explain things, and join in the dialog. --Michael Dillon From michael.dillon at bt.com Tue Oct 6 17:16:20 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 6 Oct 2009 22:16:20 +0100 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some category of organization Message-ID: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> I was just reading a legal opinion that RIPE has received related to rationing policies for the final IANA allocations to RIRs. There was an interesting paragraph there that I believe substantially applies in North America, and which is worth thinking about: A shortage of supply is indeed generally recognized as an objective justification for a dominant company to discriminate between its customers. In such cases, which applies to IPv4 address space, a dominant firm may e.g. prioritise long- standing customers over new or occasional customers and the Commission (EU) will limit its investigation to verifying that there is a genuine shortage and that the reduction in supplies is not merely a pretext for a downright abusive refusal to supply. Obviously, any policy proposed within ARIN would get its own legal review and we would see how the specific wording of such a policy would be viewed under the specific laws of the USA and Virginia. That is not the point. The point is that we have a REAL shortage looming of IPv4 addresses and that network operators are not yet ready to use IPv6 addresses as a substitute. That is a genuine shortage of supply, and I believe that it is justification for policies which specifically target new entrants. Whether the policies only target smart utility networks, or whether they go further and target any new entrants, I think that there is sufficient reason to think that such policies would pass muster. Therefore, I would like to see us discuss this type of policy now, while there is still some chance of easing the IPv6 transition, if only a little bit. ------------------------------------------------------- Michael Dillon GFS Network Addressing Authority - BT Innovation & Design 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 BTNet 660 3360 Internet: michael.dillon at bt.com Phone: +44 131312 3360 Fax: +44 20 7650 9030 http://www.btradianz.com Use the wiki: http://collaborate.bt.com/wiki From kkargel at polartel.com Tue Oct 6 17:20:17 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 6 Oct 2009 16:20:17 -0500 Subject: [arin-ppml] Straw Poll In-Reply-To: <28E139F46D45AF49A31950F88C49745803745DEC@E03MVZ2-UKDY.domain1.systemhost.net> References: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A343@mail> <28E139F46D45AF49A31950F88C49745803745DEC@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A347@mail> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Tuesday, October 06, 2009 3:48 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Straw Poll > > > > While it would certainly be in the consumers best interest to > > facilitate such a network, mandating or legislating internet > > connectivity as a pre-requisite to utility connection is untenable. > > Why? > Nobody says that the consumer has to pay for Internet access over the > Internet connection if they don't want to. If someone wants to live > a 1940's style life, using the electric grid, then they have to have > an Internet connection for the Smart Grid, and for 911 service, but > nothing more. Because there are MANY metered utility installations that have NO internet or telephone connectivity. Mandating that connectivity to be able to obtain utility connection could place a heavy burden. Yes, this is *only* an economic issue, but even economic issues can be a real concern. > > We already have the technology capable of operating a limited use > IP network connection like this so the barriers to doing this are > purely economic and policy issues. > > --Michael Dillon > _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From kkargel at polartel.com Tue Oct 6 17:24:30 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 6 Oct 2009 16:24:30 -0500 Subject: [arin-ppml] [a-p] Straw poll on special policy for electricenergy In-Reply-To: <28E139F46D45AF49A31950F88C49745803745DF9@E03MVZ2-UKDY.domain1.systemhost.net> References: <200910062042.n96Kg7Dp010212@cjbsys.bdb.com> <28E139F46D45AF49A31950F88C49745803745DF9@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A348@mail> > > > Who are you to say that > > because you have some numbers and they don't, you should get > > more and they can't have any? > > Because the current IPv4 address holders are providing an important > service that is dependent on a continued supply of IPv4 addresses > for at least a couple more years until the transition picks up steam. > And these newcomers, haven't got any NEED for IPv4, since they haven't > actually built out their infrastructure, and everything that they want > to do can be done with IPv6. In some cases they can do it better and > cheaper with IPv6. You seem to be forgetting that there is much territory even in the great United States that has no IPv6 native routing (right where I am sitting for example). This is not a matter of choice, it is simply not available. You can spout all you want about threatening providers with economic sanctions if they do not provide IPv6, but so long as they know that nobody in the area provides it then unless you are willing to close the doors on your business to spite them they can safely disregard your threats. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From mksmith at adhost.com Tue Oct 6 17:40:21 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 6 Oct 2009 14:40:21 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <17838240D9A5544AAA5FF95F8D52031606D01C74@ad-exh01.adhost.lan> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Tuesday, October 06, 2009 2:16 PM > To: ppml at arin.net > Subject: [arin-ppml] Fairness of banning IPv4 allocations to some > categoryof organization > > > I was just reading a legal opinion that RIPE has received related to > rationing policies for the final IANA allocations to RIRs. There > was an interesting paragraph there that I believe substantially > applies in North America, and which is worth thinking about: > > A shortage of supply is indeed generally recognized as an > objective justification for a dominant company to discriminate > between its customers. In such cases, which applies to IPv4 > address space, a dominant firm may e.g. prioritise long- > standing customers over new or occasional customers and the > Commission (EU) will limit its investigation to verifying that > there is a genuine shortage and that the reduction in supplies > is not merely a pretext for a downright abusive refusal to supply. > > Obviously, any policy proposed within ARIN would get its own legal > review and we would see how the specific wording of such a policy > would be viewed under the specific laws of the USA and Virginia. > That is not the point. > > The point is that we have a REAL shortage looming of IPv4 addresses > and that network operators are not yet ready to use IPv6 addresses > as a substitute. That is a genuine shortage of supply, and I believe > that it is justification for policies which specifically target > new entrants. Whether the policies only target smart utility > networks, or whether they go further and target any new entrants, > I think that there is sufficient reason to think that such > policies would pass muster. > > Therefore, I would like to see us discuss this type of policy now, > while there is still some chance of easing the IPv6 transition, > if only a little bit. > I don't think that the rationalization given fits the IPv4 run-out issue well at all; it seems to be geared towards an economic situation where the resource holder can discriminate in order to maximize their return in the event of a shortage of that resource. Since ARIN is not concerned with maximizing economic return but, instead, stewardship of a scarce resource, I don't see that giving preference to the existing membership, or some subset of the existing membership as that rationalization seems to suggest, is warranted. Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From fred at cisco.com Tue Oct 6 17:47:44 2009 From: fred at cisco.com (Fred Baker) Date: Tue, 6 Oct 2009 14:47:44 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some category of organization In-Reply-To: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <81A2E0FF-0A3D-474C-893F-8563FA08C1C8@cisco.com> It's a very reasonable thing to discuss. I suspect that the matter will ease the transition more and be more generally acceptable if it is handled the way I suggested earlier: discriminate not in favor of long-standing customers (which ARIN member will not argue that it has been a long-standing customer?) but in favor of those who are demonstrably moving their businesses to the next generation technology. On Oct 6, 2009, at 2:16 PM, wrote: > > I was just reading a legal opinion that RIPE has received related to > rationing policies for the final IANA allocations to RIRs. There > was an interesting paragraph there that I believe substantially > applies in North America, and which is worth thinking about: > > A shortage of supply is indeed generally recognized as an > objective justification for a dominant company to discriminate > between its customers. In such cases, which applies to IPv4 > address space, a dominant firm may e.g. prioritise long- > standing customers over new or occasional customers and the > Commission (EU) will limit its investigation to verifying that > there is a genuine shortage and that the reduction in supplies > is not merely a pretext for a downright abusive refusal to supply. > > Obviously, any policy proposed within ARIN would get its own legal > review and we would see how the specific wording of such a policy > would be viewed under the specific laws of the USA and Virginia. > That is not the point. > > The point is that we have a REAL shortage looming of IPv4 addresses > and that network operators are not yet ready to use IPv6 addresses > as a substitute. That is a genuine shortage of supply, and I believe > that it is justification for policies which specifically target > new entrants. Whether the policies only target smart utility > networks, or whether they go further and target any new entrants, > I think that there is sufficient reason to think that such > policies would pass muster. > > Therefore, I would like to see us discuss this type of policy now, > while there is still some chance of easing the IPv6 transition, > if only a little bit. > > ------------------------------------------------------- > Michael Dillon > GFS Network Addressing Authority - BT Innovation & Design > 66 Prescot St., London, E1 8HG, UK > Mobile: +44 7900 823 672 BTNet 660 3360 > Internet: michael.dillon at bt.com > Phone: +44 131312 3360 Fax: +44 20 7650 9030 > http://www.btradianz.com > > Use the wiki: http://collaborate.bt.com/wiki > > _______________________________________________ > 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 rlc at usfamily.net Tue Oct 6 17:41:00 2009 From: rlc at usfamily.net (Ron Cleven) Date: Tue, 06 Oct 2009 16:41:00 -0500 (CDT) Subject: [arin-ppml] [a-p] Straw poll on special policy for electricenergy In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A348@mail> References: <200910062042.n96Kg7Dp010212@cjbsys.bdb.com> <28E139F46D45AF49A31950F88C49745803745DF9@E03MVZ2-UKDY.domain1.systemhost.net> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A348@mail> Message-ID: <4ACBB969.8070202@usfamily.net> I don't get this discussion (though I admit I did not go back and read the entire thing, so maybe I am missing something important, if so I'm sorry). There seems to be an underlying assumption that all devices need their own ip address (whether ipv4 or ipv6). While that is obviously one way to architect things, it would seem that the devices could just as easily and more sensibly "phone home" via good ole NAT (whether ipv4 or ipv6), provide their unique identifier (NOT an ip address) and exchange whatever information is relevant with their home base. From JThomas at Clarecomputer.com Tue Oct 6 20:07:19 2009 From: JThomas at Clarecomputer.com (John Thomas) Date: Tue, 6 Oct 2009 17:07:19 -0700 Subject: [arin-ppml] [a-p] Straw poll on special policy for electricenergy In-Reply-To: <4ACBB969.8070202@usfamily.net> References: <200910062042.n96Kg7Dp010212@cjbsys.bdb.com> <28E139F46D45AF49A31950F88C49745803745DF9@E03MVZ2-UKDY.domain1.systemhost.net> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A348@mail> <4ACBB969.8070202@usfamily.net> Message-ID: <6010EA513C333E4DB009D624ED0307A0031530B3BA@ccs-sr-mail> Based on http://www.smartgridnews.com/artman/publish/companies/Cisco_Certifies_Smart_Grid_as_the_Next_Big_Thing_printer.html and http://www.smartsynch.com/news/091709.htm About SmartSynch SmartSynch has been the only provider of standard, IP communicating end-to-end smart grid solutions utilizing public wireless networks for the utility industry since 2000. It looks like they may want Globally Addressable IP for the end devices. It seems like they would likely want publicly addressable endpoints so that it would be easy to build secure tunnels as necessary. I can't imagine a utility using my DSL as a primary means to "phone home", although they may have a secure way of doing that. John -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ron Cleven Sent: Tuesday, October 06, 2009 2:41 PM To: ppml at arin.net Subject: [arin-ppml] [a-p] Straw poll on special policy for electricenergy I don't get this discussion (though I admit I did not go back and read the entire thing, so maybe I am missing something important, if so I'm sorry). There seems to be an underlying assumption that all devices need their own ip address (whether ipv4 or ipv6). While that is obviously one way to architect things, it would seem that the devices could just as easily and more sensibly "phone home" via good ole NAT (whether ipv4 or ipv6), provide their unique identifier (NOT an ip address) and exchange whatever information is relevant with their home base. _______________________________________________ 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 tedm at ipinc.net Tue Oct 6 20:26:54 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 06 Oct 2009 17:26:54 -0700 Subject: [arin-ppml] Straw Poll In-Reply-To: <20091006182609.GF7127@dan.olp.net> References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> <20091006182609.GF7127@dan.olp.net> Message-ID: <4ACBE04E.4050005@ipinc.net> Dan White wrote: > On 06/10/09 10:26 -0700, Fred Baker wrote: >> I agree with you, but let me reflect some comments I have heard from >> the Smart Grid side of the house. >> >> One thing they are very worried about is running the SG over the >> Internet. They are interested in control - the term "control freak" >> has been used - and they don't see the Internet as all that well >> controlled. That's not universal, of course; The Cisco/Yello thing in >> Germany uses a subscriber's broadband connection, I believe a DMVPN. >> But many do want direct connectivity to their customers and the >> ability to directly manage at least some appliances and instruments in >> subscriber's homes - notably the electric meter. > > Suppose they take that approach... everything's on a private network, > including "approved" appliances. The meter reports current usage, and each > appliance reports its need for energy, and what times of the day it need it > - i.e. your futuristic electric car probably doesn't need to charge during > peak hours. > > What happens when someone compromises their appliances, or their car, to > game the system? > To what end? The whole idea behind the smart grid thing is driven by the idea that at some point in the future the electric utilities will be able to charge peak usage rates. Meaning that if you have an appliance that has a CHOICE of whether it can draw power, it would choose off-peak. In the refrigerator example, perhaps the icemaker in the refrigerator will shut off during the day. And so on. There is no benefit to gaming your appliances, either your going to draw power during peak or not. The meter knows when it's supplying power during peak periods. To gain anything you would have to compromise the meter, and if the meter is on a private network the only possible entry point for the compromise is from the downstream side, ie: the side plugged into the subscriber. In which case it is a theft-of-power situation, and the utilities have been dealing with those for a century. > Security won't be found in a private network or dependence on the ignorance > of users, but in sound security principals. It shouldn't matter how the > electric grid communicates - your home grid might choose to use your > broadband connection is a backup communication medium. > > If properly managed and designed, it would be in a consumer's best interest > to provide accurate information to the grid (because of pricing > incentives). > I think the idea is the other way around, the grid tells the consumer when it would prefer that the consumer draw power. Ted From terry.l.davis at boeing.com Tue Oct 6 21:25:08 2009 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 6 Oct 2009 18:25:08 -0700 Subject: [arin-ppml] Straw Poll In-Reply-To: <4ACBE04E.4050005@ipinc.net> References: <8aeeaff60910061004m7d8d0080n49ef1c6d4655a147@mail.gmail.com> <20091006182609.GF7127@dan.olp.net> <4ACBE04E.4050005@ipinc.net> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF55109372A9@XCH-NW-05V.nw.nos.boeing.com> Ted Generally right. Fred, SmartGrid will have different security requirement levels depending on what is communicating. SCADA and grid controls will not likely be in the same network with home broadcast control and pricing info (I sure wouldn't! and v6 makes that simple separation even easier) nor will they use the same authentication. Industrial controls probably lie in between. Just as FYI, there are appropriately 350 million meters in the US from some stats I saw earlier this week and that doesn't include any Grid infrastructure; just end user metering (certainly not frigs :-). Anything that we can do to encourage good designs (i.e. IPv6) seems appropriate. FINALLY, we need to remember that existing "critical infrastructure" from Power to ICUs to water are likely to need some bridging IPv4 allocations to their "EXISTING" control networks before they can move them to IPv6. At this point I'd be far more concerned about reserving some resources for bridging existing CI control networks than most anything else; those bridging resources are something we definitely should plan for. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Tuesday, October 06, 2009 5:27 PM > To: Dan White > Cc: RudOlph Daniel; arin-ppml at arin.net > Subject: Re: [arin-ppml] Straw Poll > > Dan White wrote: > > On 06/10/09 10:26 -0700, Fred Baker wrote: > >> I agree with you, but let me reflect some comments I have heard from > >> the Smart Grid side of the house. > >> > >> One thing they are very worried about is running the SG over the > >> Internet. They are interested in control - the term "control freak" > >> has been used - and they don't see the Internet as all that well > >> controlled. That's not universal, of course; The Cisco/Yello thing in > >> Germany uses a subscriber's broadband connection, I believe a DMVPN. > >> But many do want direct connectivity to their customers and the > >> ability to directly manage at least some appliances and instruments in > >> subscriber's homes - notably the electric meter. > > > > Suppose they take that approach... everything's on a private network, > > including "approved" appliances. The meter reports current usage, and > each > > appliance reports its need for energy, and what times of the day it need > it > > - i.e. your futuristic electric car probably doesn't need to charge > during > > peak hours. > > > > What happens when someone compromises their appliances, or their car, to > > game the system? > > > > To what end? The whole idea behind the smart grid thing is driven by > the idea that at some point in the future the electric utilities will > be able to charge peak usage rates. Meaning that if you have an > appliance that has a CHOICE of whether it can draw power, it would > choose off-peak. In the refrigerator example, perhaps the icemaker in > the refrigerator will shut off during the day. And so on. > > There is no benefit to gaming your appliances, either your going to > draw power during peak or not. The meter knows when it's supplying > power during peak periods. To gain anything you would have to > compromise the meter, and if the meter is on a private network the > only possible entry point for the compromise is from the downstream > side, ie: the side plugged into the subscriber. In which case it is a > theft-of-power situation, and the utilities have been dealing with those > for a century. > > > Security won't be found in a private network or dependence on the > ignorance > > of users, but in sound security principals. It shouldn't matter how the > > electric grid communicates - your home grid might choose to use your > > broadband connection is a backup communication medium. > > > > If properly managed and designed, it would be in a consumer's best > interest > > to provide accurate information to the grid (because of pricing > > incentives). > > > > I think the idea is the other way around, the grid tells the consumer > when it would prefer that the consumer draw power. > > Ted > _______________________________________________ > 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 randy at psg.com Wed Oct 7 06:32:35 2009 From: randy at psg.com (Randy Bush) Date: Wed, 07 Oct 2009 03:32:35 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: <0FACF1F4-9DE3-4415-BB43-D7E4FEC5AB97@cisco.com> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> <0FACF1F4-9DE3-4415-BB43-D7E4FEC5AB97@cisco.com> Message-ID: > The policy I would suggest is a blanket policy: IPv4 addresses are > available to ARIN members if and only if they can demonstrate progress > on IPv6 deployment. i think, to get ipv4 space, they should also swear to vote for pigasus and not employ people with blue eyes. randy From ocl at gih.com Wed Oct 7 12:37:21 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Wed, 7 Oct 2009 18:37:21 +0200 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <061F384443684B4391AE7128687BB083@GIH.CO.UK> wrote: > The point is that we have a REAL shortage looming of IPv4 addresses > and that network operators are not yet ready to use IPv6 addresses > as a substitute. That is a genuine shortage of supply, and I believe > that it is justification for policies which specifically target > new entrants. Whether the policies only target smart utility > networks, or whether they go further and target any new entrants, > I think that there is sufficient reason to think that such > policies would pass muster. The heated discussion about a Smart Grid requiring large amounts of IP addresses and potentially being refused IPv4 addresses is one which made me smile. Watch how things are going to get hotter as fewer IPv4 addresses will be available. Having now spent more than 2 years speaking personally to hundreds of people about getting their organisation to embrace IPv6 ASAP, and being told that there's still plenty of time and that the pain level isn't high enough for them to even think about it, reading this week's messages made me smile. Talks of banning IPv4 allocations to some category of organisation remind me of the old, pre-internet Telco days. I am absolutely astonished that we're even discussing this! What we are witnessing here, is regression. It's going to hurt, and a lot faster than you think, if proper leadership is not shown very soon. By that, I mean, roadmaps, strategic and risk analysis, and a cost of: (1) how much will IPv6 implementation cost region-wide (2) how much will *lack* of IPv6 implementation cost region-wide Kind regards, -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html From rlc at usfamily.net Wed Oct 7 12:52:23 2009 From: rlc at usfamily.net (Ron Cleven) Date: Wed, 07 Oct 2009 11:52:23 -0500 (CDT) Subject: [arin-ppml] [a-p] Straw poll on special policy for electricenergy In-Reply-To: <6010EA513C333E4DB009D624ED0307A0031530B3BA@ccs-sr-mail> References: <200910062042.n96Kg7Dp010212@cjbsys.bdb.com> <28E139F46D45AF49A31950F88C49745803745DF9@E03MVZ2-UKDY.domain1.systemhost.net> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A348@mail> <4ACBB969.8070202@usfamily.net> <6010EA513C333E4DB009D624ED0307A0031530B3BA@ccs-sr-mail> Message-ID: <4ACCC747.1060101@usfamily.net> Ok, I read those links, and I still don't understand what this has to do with this list? They seem to be talking about a separate (non-Internet) ip-based wireless network. So, fine, like cell phones, that would seem to be a good application for ipv6, but it seems to have little or nothing to do with the transition to ipv6 on the Internet. What am I missing? > I can't imagine a utility using my DSL as a primary means to "phone home", although they may have a secure way of doing that. It's called SSL ... From brandon at dodecatec.com Wed Oct 7 13:30:32 2009 From: brandon at dodecatec.com (Brandon M Thetford) Date: Wed, 7 Oct 2009 13:30:32 -0400 Subject: [arin-ppml] Straw poll on special policy for electricenergy industry In-Reply-To: References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net><0FACF1F4-9DE3-4415-BB43-D7E4FEC5AB97@cisco.com> Message-ID: <000b01ca4773$dfd59c90$9f80d5b0$@com> I support this idea. Organizations who have made no progress or attempt at progress toward IPv6 adoption should not be considered for additional IPv4 space. Want to get more IPv4 without working on IPv6? Buy it from someone else who IS willing to take the plunge. Supporting continued expansion of IPv4 without incentive to move to IPv6 (or disincentive to use IPv4) is just going to get us to crunch time even faster. > The policy I would suggest is a blanket policy: IPv4 addresses are > available to ARIN members if and only if they can demonstrate progress > on IPv6 deployment. From info at arin.net Wed Oct 7 14:17:58 2009 From: info at arin.net (Member Services) Date: Wed, 07 Oct 2009 14:17:58 -0400 Subject: [arin-ppml] Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <4ACA2FB5.90602@arin.net> References: <4AAE4700.5050508@arin.net> <4ACA2FB5.90602@arin.net> Message-ID: <4ACCDB56.3070706@arin.net> A revised rationale has been added to the 2009-3 draft policy page: https://www.arin.net/policy/proposals/2009_3.html Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > On 14 September 2009 a revised version of Draft Policy 2009-3 was posted > to the Public Policy Mailing List (PPML). ARIN staff reviewed the text > of the draft policy and produced the following revised staff and legal > assessment. > > 2009-3 is under discussion on PPML and will be presented at the upcoming > Public Policy Meeting in Dearborn. > > Draft Policy 2009-3 is below and can be found at: > https://www.arin.net/policy/proposals/2009_3.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Staff Assessment > > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > Text assessed: 14 September 2009 > > I. Summary (Staff Understanding) (revised): > > Staff understands that this proposal would be implemented in 2 phases. > Phase 1 says that the RIRs may elect to return any IPv4 addresses they > recover (via policy or procedure) to the IANA but it does not require > them to return recovered IPv4 address space to IANA. > > Phase 2 would start after the depletion of the IANA free pool and would > nullify the existing IANA to RIR policy (Global Addressing Policy > ASO-001-2). The new IANA to RIR policy would allow each RIR to receive > approximately 1/10th of the recovered IPv4 pool from IANA once every 6 > months as long as it meets the qualification criteria written in > paragraph B2. IANA will be required to keep a log of all returned IPv4 > address space and all issued IPv4 address space from the recovered pool, > as well as maintain a public registry of the current disposition of all > IPv4 address space. > > II. Comments > > A. ARIN Staff Comments (revised) > ? If an RIR is fully authoritative for a /8, and as a result of this > policy, returns a portion of that /8 to IANA, it is likely that the DNS > authority for the /8 could change. If the returned space is then > re-issued by IANA to a different RIR, is the /8 now considered an > ERX-like "fractured" /8, which the RIRs must then exchange zone > fragments for to put together a complete set of zone files for the /8? > Close coordination by the 5 RIRs will be required in order to > successfully manage the potential reverse DNS implications. > > B. ARIN General Counsel Comments (revised): > > The current basis of allocating number resources was established in > RFC's 2008 and 2050 and is defined to be according to operational need. > If one region has greater needs than another, current allocation policy > does not call for equal distribution of numbering resources to all RIR's. > > The revised portion of this policy removes objectionable requirements in > the prior version that required ARIN to return all recovered IPV4 space > to the IANA, when such space might be needed in this region, or other > regions were not maintaining need's based distribution policies. That > first problem was exacerbated by a second: the policy included a > redistribution mechanism that did not follow RFC 2008 and 2050 but would > provide ARIN, at best, only one fifth of such space, when it was also > likely ARIN would return more than one fifth of the recovered space. The > revision to voluntarily permit, but not require ARIN to return such > recovered space is a substantial advance and removes strong legal and > fiduciary objections to the prior draft. > > Accordingly, the revised policy also removes the prior version's > disincentive for any RIR, including ARIN, to undertake financial > expenditure of its financial resources for programs intended to obtain > returned space, since it does not force 100% return to IANA. Since ARIN > has expended significant resources seeking the return of unused number > resources, this is again a positive change. It also appears, and it must > be made so if it is not, that the revised language would not interfere > with transfers made under ARIN's new policy, which is intended to > encourage better use of otherwise underutilized resources. > > However, the revised proposal appears to retain the predecessor' drafts > policy that each RIR with needs will be an equal recipient of such > returned space, even if those needs are disparate. This policy could > tend to reallocate returned space away from where it is recovered, in > the ARIN region, to other regions. This would be objectionable from a > fiduciary duty perspective if one or more of the other RIRs abandon > needs-based policies, but are then permitted by this policy to obtain > equal additional resources. > However, since ARIN can choose not to return recovered resources if > others RIRs are not maintaining needs based policies, this is no longer > a fatal legal flaw, since ARIN can chose not to provide returned > resources for redistribution under such circumstances. > > There is a concern over one particular piece of the policy. In 4 it > states: "Each new RIR shall, at the moment of recognition, be allocated > one (1) allocation unit by the IANA." The 'new' reference appears > unwise, with "recognized" RIRs being a better choice. > > III. Resource Impact > > The resource impact of implementing this policy is viewed as moderate as > it represents a fundamental change to the business rules of ARIN?s > inventory management of number resources. It is estimated that this > policy would require a minimum of 6 person months of effort to implement > following ratification by the ARIN Board of Trustees. Because this > implementation is not planned, it may preempt ARIN's current project > deployment schedule. > > It may require the following: > > ? Modifications to existing registration procedures to include the > handling of returned/reclaimed address space and the process of > requesting additional address space from the IANA. > > ? Modifications to the existing registration software and systems as > well as the zone gen and any other processes tied to managing reverse > DNS. > > ? Staff training > > ? Inter-RIR coordination > > End of assessment. > > Member Services wrote: >> Draft Policy 2009-3 (Global Proposal) >> Allocation of IPv4 Blocks to Regional Internet Registries >> >> On 20 August 2009 the ARIN Advisory Council (AC) selected 2009-3 for >> adoption discussion on the PPML and at the Public Policy Meeting in >> Dearborn. >> >> 2009-3 comes from a global policy proposal. Global policies require the >> agreement of all five RIRs according to their policy development >> processes and ratification by ICANN. And, global policies require >> specific actions by the IANA. >> >> After the ARIN Public Policy Meeting in April 2009 the AC returned >> 2009-3 to their docket for further development and evaluation. >> >> The AC revised the text. The difference between the text presented at >> the ARIN meeting in April and the current version is in "A. Phase I" as >> follows: >> >> Old ARIN "A. Phase I" >> >> Each RIR through their respective chosen policies and strategies may >> recover IPv4 address space which is under their administration. At >> quarterly intervals, each RIR shall return to the IANA any legacy >> address space recovered, and may return to the IANA any non-legacy >> address space recovered, in aggregated blocks of /24 or larger, for >> inclusion in the recovered IPv4 pool. >> >> New ARIN "A. Phase I" >> >> Each RIR through their respective chosen policies and strategies may >> recover IPv4 address space which is under their administration and >> designate any such space for return to the IANA. Each RIR shall at >> quarterly intervals return any such designated address space to the >> IANA in aggregated blocks of /24 or larger, for inclusion in the >> recovered IPv4 pool. >> >> Draft Policy 2009-3 is below and can be found at: >> https://www.arin.net/policy/proposals/2009_3.html >> >> You are encouraged to discuss Draft Policy 2009-3 on the PPML prior to >> the October Public Policy Meeting. Both the discussion on the list and >> at the meeting will be used by the ARIN Advisory Council to determine >> the community consensus for adopting this as policy. >> >> Note, the ARIN version of the global proposal is different from the text >> at the other RIRs. The AC's version has a revised "A. Phase I" (APNIC's >> equivalent is prop-069, see the second paragraph of 5.1). The ARIN >> version also includes a definition of legacy space. >> >> The APNIC proposal can be found at: >> http://www.apnic.net/policy/proposals/prop-069 >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy 2009-3 (Global Proposal) >> Allocation of IPv4 Blocks to Regional Internet Registries >> >> Version/Date: 14 September 2009 >> >> Policy statement: >> >> This document describes the policy governing the allocation of IPv4 >> address space from the IANA to the Regional Internet Registries (RIRs). >> This document does not stipulate performance requirements in the >> provision of services by IANA to an RIR in accordance with this policy. >> Such requirements should be specified by appropriate agreements among >> the RIRs and ICANN. >> >> This policy is to be implemented in two phases. >> >> A. Phase I: Recovery of IPv4 Address Space >> >> Upon ratification of this policy by the ICANN Board of Directors the >> IANA shall establish a mechanism to receive IPv4 address space which is >> returned to it by the RIRs, and hold that address space in a 'recovered >> IPv4 pool'. >> >> Each RIR through their respective chosen policies and strategies may >> recover IPv4 address space which is under their administration and >> designate any such space for return to the IANA. Each RIR shall at >> quarterly intervals return any such designated address space to the IANA >> in aggregated blocks of /24 or larger, for inclusion in the recovered >> IPv4 pool. >> >> During Phase I, no allocations will be made from the recovered IPv4 >> pool. Return of recovered address space (as described above) will >> continue throughout Phase II. >> >> B. Phase II: Allocation of Recovered IPv4 address space by the IANA >> >> Upon ratification of this policy by the ICANN Board of Directors and a >> declaration by the IANA that its existing free pool of unallocated IPv4 >> address space is depleted; Global Addressing Policy ASO-001-2 (adopted >> by ICANN Board 8 April 2005) is rescinded. IANA will then commence to >> allocate the IPv4 address space from the recovered IPv4 pool. >> >> 1. The following definitions apply to this policy: >> >> a. Recovered Address Space. Recovered address space is that address >> space that is returned to an RIR as a result of any activity that seeks >> to reclaim unused address space or is voluntarily returned to the RIR or >> is reclaimed by the RIR as a result of legal action or abuse >> determination. Recovered address space does not include that address >> space that is reclaimed because of non-payment of contractual fees whose >> reclamation date is less than 1 year at the time of the report. >> >> b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 >> address space held by an RIR to include recovered address space not yet >> returned less that address space that is committed in accordance with >> the RIR's reservation policy and practices. >> >> c. Aggregated address blocks. Aggregated address blocks are contiguous >> prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 >> and 10.0.1.0/24 are two contiguous prefixes that can be combined to form >> an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two >> contiguous prefixes that cannot be combined on a natural bit boundary to >> form an aggregated block. >> >> d. Legacy address space. IPv4 address space allocated or assigned prior >> to the creation of the RIR. >> >> 2. Allocation of IPv4 Address Space >> >> a. For the purposes of this policy, an 'IPv4 allocation period' is >> defined as a 6-month period following 1 March or 1 September in each >> year. >> >> b. At the beginning of each IPv4 allocation period, the IANA will >> determine the 'IPv4 allocation unit' for that period, as 1/10 of its >> IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. >> The minimum 'IPv4 allocation unit' size will be a /24. >> >> c. In each allocation period, each RIR may issue one IPv4 request to the >> IANA. Providing that the RIR satisfies the allocation criteria described >> in paragraph B.2, the IANA will allocate a single allocation unit, >> composed of the smallest possible number of blocks available in its IPv4 >> address pool. >> >> 3. IPv4 Address Space Allocation Criteria >> >> A RIR is eligible to receive additional IPv4 address space from the IANA >> when the total of its IPv4 address holdings is less than 50% of the >> current IPv4 allocation unit, and providing that it has not already >> received an IPv4 allocation from the IANA during the current IPv4 >> allocation period. >> >> 4. Initial Allocation of IPv4 Address Space >> >> Each new RIR shall, at the moment of recognition, be allocated one (1) >> allocation unit by the IANA. If an allocation unit is not available, >> then the IANA will issue this block as soon as one is available. This >> allocation will be made regardless of the newly formed RIR's projected >> utilization figures and shall be independent of the IPv4 address space >> that may have been transferred to the new RIR by the already existing >> RIRs as part of the formal transition process. >> >> 5. Reporting >> >> a. All returned space is to be recorded in an IANA-published log of IPv4 >> address space transactions, with each log entry detailing the returned >> address block, the date of the return, and the returning RIR. >> >> b. All allocated space is also to be recorded in this IANA-published log >> of IPv4 address space transactions, with each log entry detailing the >> address blocks, the date of the allocation and the recipient RIR. >> >> c. The IANA will maintain a public registry of the current disposition >> of all IPv4 address space, detailing all reservations and current >> allocations and current IANA-held address space that is unallocated. >> >> d) The IANA may make public announcements of IPv4 address block >> transactions that occur under this policy. The IANA will make >> appropriate modifications to the "Internet Protocol V4 Address Space" >> page of the IANA website and may make announcements to its own >> appropriate announcement lists. The IANA announcements will be limited >> to which address ranges, the time of allocation and to which Registry >> they have been allocated. >> >> >> >> >> >> >> >> >> >> >> >> >> > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From Scott.Beuker at sjrb.ca Wed Oct 7 14:27:19 2009 From: Scott.Beuker at sjrb.ca (Scott Beuker) Date: Wed, 7 Oct 2009 12:27:19 -0600 Subject: [arin-ppml] Straw poll on special policy for electric energyindustry In-Reply-To: <0FACF1F4-9DE3-4415-BB43-D7E4FEC5AB97@cisco.com> References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> <0FACF1F4-9DE3-4415-BB43-D7E4FEC5AB97@cisco.com> Message-ID: <46A2DD1223D7BF47B61799AFFBA8AD8907A93BB8@PRDCG4EXVW01-1.OSS.PRD> > The policy I would suggest is a blanket policy: IPv4 addresses are > available to ARIN members if and only if they can demonstrate progress > on IPv6 deployment. Such progress would include equipment configured, > routing, customers turning it on, and so on. The devil is in the details here... can you provide more of them? I'm curious what kind of an equation you, or others who support this, would foresee in determining who gets how much IPv4 space based on these various steps towards IPv6. I'm not trying to shoot down the idea, mind you... I could support it. I just think this might not be viable. IPv6 deployment for many ISPs, and many other businesses for that matter, breaks down to a process of testing and planning, and then holding that solution in hand until the time is right. For example, an ISP could have everything engineered and tested for IPv6, infrastructure in place or at least the budget there to put it in place over the next fiscal year. Still, everyone's going to want to make use of all the time they can to train their staff, develop tech support knowledge, spread out costs, flesh out backend tools, etc. I find IPv6 testing and deployment has a "95/5" rule. By the time you've done 95% of your testing and development to ready your business for IPv6, only 5% of that progress is visible to the outside world. The final 5% of the work is basically 'turning it on'. - Scott Beuker From tedm at ipinc.net Wed Oct 7 20:52:57 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 07 Oct 2009 17:52:57 -0700 Subject: [arin-ppml] Straw poll on special policy for electric energy industry In-Reply-To: References: <28E139F46D45AF49A31950F88C49745803695C50@E03MVZ2-UKDY.domain1.systemhost.net> <0FACF1F4-9DE3-4415-BB43-D7E4FEC5AB97@cisco.com> Message-ID: <4ACD37E9.2040708@ipinc.net> Randy Bush wrote: >> The policy I would suggest is a blanket policy: IPv4 addresses are >> available to ARIN members if and only if they can demonstrate progress >> on IPv6 deployment. > > i think, to get ipv4 space, they should also swear to vote for pigasus > and not employ people with blue eyes. > Blue eyes? I thought it was supposed to only be people who are black on the right side, and white on the left. ;-) Ted From tedm at ipinc.net Wed Oct 7 21:48:59 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 07 Oct 2009 18:48:59 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: <061F384443684B4391AE7128687BB083@GIH.CO.UK> References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> <061F384443684B4391AE7128687BB083@GIH.CO.UK> Message-ID: <4ACD450B.2030708@ipinc.net> Olivier MJ Crepin-Leblond wrote: > wrote: > >> The point is that we have a REAL shortage looming of IPv4 addresses >> and that network operators are not yet ready to use IPv6 addresses >> as a substitute. That is a genuine shortage of supply, and I believe >> that it is justification for policies which specifically target >> new entrants. Whether the policies only target smart utility >> networks, or whether they go further and target any new entrants, >> I think that there is sufficient reason to think that such >> policies would pass muster. > > The heated discussion about a Smart Grid requiring large amounts of IP > addresses and potentially being refused IPv4 addresses is one which made > me smile. Watch how things are going to get hotter as fewer IPv4 > addresses will be available. > > Having now spent more than 2 years speaking personally to hundreds of > people about getting their organisation to embrace IPv6 ASAP, and being > told that there's still plenty of time and that the pain level isn't > high enough for them to even think about it, reading this week's > messages made me smile. > > Talks of banning IPv4 allocations to some category of organisation > remind me of the old, pre-internet Telco days. I am absolutely > astonished that we're even discussing this! What we are witnessing here, > is regression. No, we are not. If you have studied history or how government functions or have any education you will know that a great many political problems are NOT solvable with win-win scenarios. Problems cause humans grief. There are 8 well-defined stages of grief and loss, and these are (not coincidentally) the same stages that people use when dealing with problems like losing IPv4. Here they are: 1) Shock. 2) Denial 3) prevarication/equivocation/bargaining 4) Guilt 5) Anger 6) Depression 7) Resignation 8) Acceptance This "electric utilities must be denied IPv4" could quite possibly be nothing more than an expression of Step 3 (if we can maybe deny "those guys" all that IPv4 that we might avoid the catastrophe) > It's going to hurt, and a lot faster than you think, if proper > leadership is not shown very soon. By that, I mean, roadmaps, strategic > and risk analysis, and a cost of: > (1) how much will IPv6 implementation cost region-wide > (2) how much will *lack* of IPv6 implementation cost region-wide > Oliver, I wonder if you are really only at Step 5 of your stages of IPv4 loss? You sound angry that "proper leadership" isn't being shown. I have to ask, for what end? What will proper leadership accomplish? Will it extend IPv4's life? People seem to think that if we tell everyone IPv4 is ending that they are going to drop everything and jump on IPv6. But, human nature being what it is, wouldn't the more likely outcome of increased education be for people to all jump in now and try to "stock up" on IPv4? Kind of the "I'll get mine and screw the other guy?? Then the end of IPv4 will come much, much sooner than expected. Quite the opposite of extending it's life, I think. Ted > Kind regards, > From mysidia at gmail.com Wed Oct 7 22:35:47 2009 From: mysidia at gmail.com (James Hess) Date: Wed, 7 Oct 2009 21:35:47 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: <4ACD450B.2030708@ipinc.net> References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> <061F384443684B4391AE7128687BB083@GIH.CO.UK> <4ACD450B.2030708@ipinc.net> Message-ID: <6eb799ab0910071935i2ad94e8fqffce20056ff79150@mail.gmail.com> On Wed, Oct 7, 2009 at 8:48 PM, Ted Mittelstaedt wrote: > Problems cause humans grief. ?There are 8 well-defined stages of Kind of irrelevent.. well, IPv4 is not lost yet. It's a fact that there will be V4 address scarcity and exhaustion of free space the registries can allocate in 3 or 4 years: will have to be dealt with in some manner. > This "electric utilities must be denied IPv4" could quite possibly be The RIRs don't need to be allowing anything they have control of that will cause undue ACCELERATION of the run-out . It would be a terrible idea for ARIN to discriminate based on the identity of the applicant. Instead they should be looking at the Intended USE of the addresses, what kinds of things IPs are to be assigned to, eg the justification. To that end, it is sensible, that the registries deny applicants that are plans for massive networks (such as ones which would require a /8) and consist mostly of non-computer devices that are not crit. internet infrastructure and that don't interact with the public, and give priority to applicants who have more traditional computer devices on their networks. Such as computer workstations and computer-based servers, justifiable in number for their use. Basically, i'm saying: if an org applies for a /8 for computer workstations, and they are assigning enough IPs to workstations to allow it (and they can show they have all that infrastructure and need), then the app could be accepted. Because (despite the unusually large request) they are connecting conventional computing devices. On the other hand.. If an org applies for a /8 to assign to 1 million coffee pots an IP address, the app should be rejected. Even if they have all those coffee pots, and it's a business requirement that their outsourced coffee pot management contractor have public IP connectivity to them. -- -J From cengel at sponsordirect.com Thu Oct 8 16:33:10 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 8 Oct 2009 16:33:10 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof Message-ID: The primary determining factor for whether an allocation of an IPv4 address space (IMO) is justified should be based on whether the applicant has reasonable ability to predict who will be connecting to the address or not. If the applicant has no ability to predict who might be connecting to that address (examples: an e-mail server, a webserver used to host sites intended for the general public), the request should generally be granted because there is no reasonable method of providing access to the resource without a public address. However, if the applicant can reasonably predict who will need to access the address space then the request should be denied because that access can be accomplished by other means, such as the use of VPN's and a Private Address space ( examples: Smart Meter's that will be accessed by a utility company and it's affiliates, workstations at a company that only connect to each other). Basically the criteria should be that the address provides services to individual/devices that cannot be predicted in ADVANCE of the provision of service. Christopher Engel -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of arin-ppml-request at arin.net Sent: Thursday, October 08, 2009 12:00 PM To: arin-ppml at arin.net Subject: [SPAM] - ARIN-PPML Digest, Vol 52, Issue 13 - Email has different SMTP TO: and MIME TO: fields in the email addresses Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net You can reach the person managing the list at arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: 1. Re: Straw poll on special policy for electric energy industry (Ted Mittelstaedt) 2. Re: Fairness of banning IPv4 allocations to some categoryof organization (Ted Mittelstaedt) 3. Re: Fairness of banning IPv4 allocations to some categoryof organization (James Hess) ---------------------------------------------------------------------- Message: 1 Date: Wed, 07 Oct 2009 17:52:57 -0700 From: Ted Mittelstaedt To: Randy Bush Cc: ppml at arin.net Subject: Re: [arin-ppml] Straw poll on special policy for electric energy industry Message-ID: <4ACD37E9.2040708 at ipinc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Randy Bush wrote: >> The policy I would suggest is a blanket policy: IPv4 addresses are >> available to ARIN members if and only if they can demonstrate >> progress on IPv6 deployment. > > i think, to get ipv4 space, they should also swear to vote for pigasus > and not employ people with blue eyes. > Blue eyes? I thought it was supposed to only be people who are black on the right side, and white on the left. ;-) Ted ------------------------------ Message: 2 Date: Wed, 07 Oct 2009 18:48:59 -0700 From: Ted Mittelstaedt To: Olivier MJ Crepin-Leblond Cc: ppml at arin.net Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization Message-ID: <4ACD450B.2030708 at ipinc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Olivier MJ Crepin-Leblond wrote: > wrote: > >> The point is that we have a REAL shortage looming of IPv4 addresses >> and that network operators are not yet ready to use IPv6 addresses as >> a substitute. That is a genuine shortage of supply, and I believe >> that it is justification for policies which specifically target new >> entrants. Whether the policies only target smart utility networks, or >> whether they go further and target any new entrants, I think that >> there is sufficient reason to think that such policies would pass >> muster. > > The heated discussion about a Smart Grid requiring large amounts of IP > addresses and potentially being refused IPv4 addresses is one which > made me smile. Watch how things are going to get hotter as fewer IPv4 > addresses will be available. > > Having now spent more than 2 years speaking personally to hundreds of > people about getting their organisation to embrace IPv6 ASAP, and > being told that there's still plenty of time and that the pain level > isn't high enough for them to even think about it, reading this week's > messages made me smile. > > Talks of banning IPv4 allocations to some category of organisation > remind me of the old, pre-internet Telco days. I am absolutely > astonished that we're even discussing this! What we are witnessing > here, is regression. No, we are not. If you have studied history or how government functions or have any education you will know that a great many political problems are NOT solvable with win-win scenarios. Problems cause humans grief. There are 8 well-defined stages of grief and loss, and these are (not coincidentally) the same stages that people use when dealing with problems like losing IPv4. Here they are: 1) Shock. 2) Denial 3) prevarication/equivocation/bargaining 4) Guilt 5) Anger 6) Depression 7) Resignation 8) Acceptance This "electric utilities must be denied IPv4" could quite possibly be nothing more than an expression of Step 3 (if we can maybe deny "those guys" all that IPv4 that we might avoid the catastrophe) > It's going to hurt, and a lot faster than you think, if proper > leadership is not shown very soon. By that, I mean, roadmaps, > strategic and risk analysis, and a cost of: > (1) how much will IPv6 implementation cost region-wide > (2) how much will *lack* of IPv6 implementation cost region-wide > Oliver, I wonder if you are really only at Step 5 of your stages of IPv4 loss? You sound angry that "proper leadership" isn't being shown. I have to ask, for what end? What will proper leadership accomplish? Will it extend IPv4's life? People seem to think that if we tell everyone IPv4 is ending that they are going to drop everything and jump on IPv6. But, human nature being what it is, wouldn't the more likely outcome of increased education be for people to all jump in now and try to "stock up" on IPv4? Kind of the "I'll get mine and screw the other guy?? Then the end of IPv4 will come much, much sooner than expected. Quite the opposite of extending it's life, I think. Ted > Kind regards, > ------------------------------ Message: 3 Date: Wed, 7 Oct 2009 21:35:47 -0500 From: James Hess To: Ted Mittelstaedt Cc: ppml at arin.net Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization Message-ID: <6eb799ab0910071935i2ad94e8fqffce20056ff79150 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 7, 2009 at 8:48 PM, Ted Mittelstaedt wrote: > Problems cause humans grief. ?There are 8 well-defined stages of Kind of irrelevent.. well, IPv4 is not lost yet. It's a fact that there will be V4 address scarcity and exhaustion of free space the registries can allocate in 3 or 4 years: will have to be dealt with in some manner. > This "electric utilities must be denied IPv4" could quite possibly be The RIRs don't need to be allowing anything they have control of that will cause undue ACCELERATION of the run-out . It would be a terrible idea for ARIN to discriminate based on the identity of the applicant. Instead they should be looking at the Intended USE of the addresses, what kinds of things IPs are to be assigned to, eg the justification. To that end, it is sensible, that the registries deny applicants that are plans for massive networks (such as ones which would require a /8) and consist mostly of non-computer devices that are not crit. internet infrastructure and that don't interact with the public, and give priority to applicants who have more traditional computer devices on their networks. Such as computer workstations and computer-based servers, justifiable in number for their use. Basically, i'm saying: if an org applies for a /8 for computer workstations, and they are assigning enough IPs to workstations to allow it (and they can show they have all that infrastructure and need), then the app could be accepted. Because (despite the unusually large request) they are connecting conventional computing devices. On the other hand.. If an org applies for a /8 to assign to 1 million coffee pots an IP address, the app should be rejected. Even if they have all those coffee pots, and it's a business requirement that their outsourced coffee pot management contractor have public IP connectivity to them. -- -J ------------------------------ _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml End of ARIN-PPML Digest, Vol 52, Issue 13 ***************************************** From ocl at gih.com Thu Oct 8 18:00:34 2009 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Fri, 9 Oct 2009 00:00:34 +0200 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> <061F384443684B4391AE7128687BB083@GIH.CO.UK> <4ACD450B.2030708@ipinc.net> Message-ID: "Ted Mittelstaedt" wrote: > Problems cause humans grief. There are 8 well-defined stages of > grief and loss, and these are (not coincidentally) the same stages that > people use when dealing with problems like losing IPv4. Here they are: > > 1) Shock. > 2) Denial > 3) prevarication/equivocation/bargaining > 4) Guilt > 5) Anger > 6) Depression > 7) Resignation > 8) Acceptance > > This "electric utilities must be denied IPv4" could quite possibly be > nothing more than an expression of Step 3 (if we can maybe deny > "those guys" all that IPv4 that we might avoid the catastrophe) An interesting scenario and you might well be right. But is this subject really supposed to be treated in an emotional way? A "Smart Grid" will require network connectivity, especially in the most remote places - such connectivity is only possible using IPv4 at the moment, thus their need for IPv4 addresses. Or perhaps metering equipment isn't IPv6 compatible yet? I understand the concern that should such a grid be built on IPv4 addressing, this will accelerate IPv4 address depletion. I also understand it would be a lot more *desirable* if the power utilities used IPv6. But if they wish to implement their plan today, what choice do they have? How do you choose whom to ban from obtaining IPv4 addresses? What would the criteria be? IMHO this would imply a serious slowdown to innovation already. > Oliver, I wonder if you are really only at Step 5 of your stages > of IPv4 loss? You sound angry that "proper leadership" isn't being > shown. I have to ask, for what end? > > What will proper leadership accomplish? Will it extend IPv4's life? I'm inclined to agree with you about your analysis re: IPv4 life extension, but you have somehow missed my point (and I am sorry, but it's probably my fault because I have not explained my point properly) which is that of speaking specifically about IPv6. For me, IPv4 address depletion is an irrelevant red herring and yet, the conversation seems to revolve around IPv4 all the time, with many brainy and talented people trying to slow the rate at which the brick wall will be hit instead using their brain power in thinking of ways to avoid hitting the wall altogether. I believe that arguing about IPv4 address depletion is irrelevant because the future is IPv6 - not IPv4. More money will be made by people designing new services on IPv6 than those scavengers trading crumbs of IPv4 addresses. The leadership I'd like to see is leadership on IPv6 transition. Okay, so I might be on your stage (5) :-) but that's only in order to get us out of that framework of "stages of grief and loss" which you describe. Why do so many people here have to look at the past? They should go out there and meet-up with the young generation. It's going to be their network, not their dad's. :-) Warm regards, Olivier -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html From ppml at rs.seastrom.com Thu Oct 8 18:25:05 2009 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Thu, 08 Oct 2009 18:25:05 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: (Olivier MJ Crepin-Leblond's message of "Fri, 9 Oct 2009 00:00:34 +0200") References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> <061F384443684B4391AE7128687BB083@GIH.CO.UK> <4ACD450B.2030708@ipinc.net> Message-ID: <86ocoh8qwu.fsf@seastrom.com> "Olivier MJ Crepin-Leblond" writes: > A "Smart Grid" will require network connectivity, especially in the most > remote places - such connectivity is only possible using IPv4 at the moment, > thus their need for IPv4 addresses. I don't think anyone is quite insane enough to suggest putting power meters on the public Internet. Yes, a smart grid will require connectivity of some sort, and the power companies will have to be the ones to haul it in. At that point, the layer 3 and up protocols are completely up to them. They could do it with CLNS or X.25 or Chaosnet or LU6.2 or whatever floated their boat (and suffer the consequences associated with each). > Or perhaps metering equipment isn't IPv6 > compatible yet? Not for lack of trying. The meter vendors I talked to through the end of 2008 all understood the importance of supporting IPv6 (some of them as a direct result of my arm-twisting). Whether such meters are available on the street yet, so to speak, is a good question. On the plus side, even under duress power generation and transmission companies make technology moves on a geological timescale. > I understand the concern that should such a grid be > built on IPv4 addressing, this will accelerate IPv4 address > depletion. I also understand it would be a lot more *desirable* if the > power utilities used IPv6. But if they wish to implement their plan > today, what choice do they have? How do you choose whom to ban from > obtaining IPv4 addresses? What would the criteria be? IMHO this would > imply a serious slowdown to innovation already. Eh, they'll be doing it on 1918 space, at least to start, and the first time their outsourced billing department (common, particularly for smaller utilities) gets the chocolate and peanut butter mixed up, they'll discover why globally unique addresses are a good idea. Hopefully by that time the IPv4 depletion clock will have run out and the choice will be a very easy economic one. -r From craig.finseth at state.mn.us Fri Oct 9 10:04:08 2009 From: craig.finseth at state.mn.us (Craig Finseth) Date: Fri, 9 Oct 2009 09:04:08 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: <86ocoh8qwu.fsf@seastrom.com> (ppml@rs.seastrom.com) References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> <061F384443684B4391AE7128687BB083@GIH.CO.UK> <4ACD450B.2030708@ipinc.net> <86ocoh8qwu.fsf@seastrom.com> Message-ID: <200910091404.n99E48mj021615@inana.itg.state.mn.us> ... I don't think anyone is quite insane enough to suggest putting power meters on the public Internet. Yes, a smart grid will require ... You'd be surprised, then. I've seen plans that effectively wind up doing just that. Craig From ppml at rs.seastrom.com Fri Oct 9 11:19:47 2009 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Fri, 09 Oct 2009 11:19:47 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: <200910091404.n99E48mj021615@inana.itg.state.mn.us> (Craig Finseth's message of "Fri, 9 Oct 2009 09:04:08 -0500") References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> <061F384443684B4391AE7128687BB083@GIH.CO.UK> <4ACD450B.2030708@ipinc.net> <86ocoh8qwu.fsf@seastrom.com> <200910091404.n99E48mj021615@inana.itg.state.mn.us> Message-ID: <86k4z4vbl8.fsf@seastrom.com> Craig Finseth writes: > ... > I don't think anyone is quite insane enough to suggest putting power > meters on the public Internet. Yes, a smart grid will require > ... > > You'd be surprised, then. I've seen plans that effectively wind up > doing just that. Nothing ever surprises me in terms of stupidity at the planning stage. The hope is that by the time people get around to actually doing a rollout that the design has been subject to review by competent network and security architects, who will no doubt give a firm "hell no" to putting that kind of equipment on the Internet. My professional opinion here is based not only on the low end CPUs and low end security capabilities found in the aforementioned meters, but also on the principle of least exposure corollary to the principle of least privilege. AMR is one thing, but as soon as ACD (automatic connect/disconnect) and other "real smart grid" features come into the mix, there's substantial incentive for nogoodniks to get involved. That's before you even get to "real SCADA" at substations and in the field. Our stated policy on multiple-customer-affecting SCADA at $PREVIOUS_JOB was that our involvement with *that* infrastructure would be limited to giving them strands and waves. Stakes are too high to do anything more. -r From mysidia at gmail.com Sat Oct 10 01:04:10 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 10 Oct 2009 00:04:10 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: <200910091404.n99E48mj021615@inana.itg.state.mn.us> References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> <061F384443684B4391AE7128687BB083@GIH.CO.UK> <4ACD450B.2030708@ipinc.net> <86ocoh8qwu.fsf@seastrom.com> <200910091404.n99E48mj021615@inana.itg.state.mn.us> Message-ID: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> If a special rule will be considered, it should be done expeditiously. It may even be too late to get any policy in ahead of an (unforseen) large allocation request.. If they were considering it at all, I would expect them to now be rushing to get their request written and submitted, in response to seeing this very discussion. RIR policy development is slow, compared to how long it might take a smartgrid initiative (or other unforseen requestor) to get an app for massive V4 space blocks written. > ? I don't think anyone is quite insane enough to suggest putting power > ? meters on the public Internet. ?Yes, a smart grid will require I really would not bet on nobody being that insane. If putting meters on the public internet reduces costs for the actor contemplating it, it will probably happen. Still.. security may be a bigger sticking point than addressing here. In 10 years, will "DoS attack", mean the event that occurs when a script kiddie exploits a TCP stack bug in power company's smartgrid meter attached to the datacenter mains, and flashes the firmware with worm code that forces power service disconnect (quick power cycle) at random intervals? I hope not, but can't say. In terms of policy "embedded device" seems like a good point to identify in policy for denying massive V4 allocations. We certainly don't need need to be writing another policy in 6 months when technology X in industry B is in a similar position. -- -J From michael.dillon at bt.com Sat Oct 10 12:34:19 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 10 Oct 2009 17:34:19 +0100 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> > In terms of policy "embedded device" seems like a good point to > identify in policy for denying massive V4 allocations. We > certainly don't need need to be writing another policy in 6 > months when > technology X in industry B is in a similar position. There seems to be some level of support for a policy which restricts the amount of IPv4 addresses that can be allocated for the purpose of embedded system devices that are not conventional PCs or servers. Since one might expect that there would be no issues with giving these devices globally registered IPv4 addresses *AFTER* the transition to IPv6, it seems wiser to phrase this as a limited time moratorium rather than an outright ban. The immediate effect is the same, but we can make sure that it expires automatically when people's attention is placed on more pressing IPv6 related issues in the future. Does anyone have ideas on how to word such a policy, where to put it in the NRPM, etc.? --Michael Dillon From mysidia at gmail.com Sat Oct 10 14:22:01 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 10 Oct 2009 13:22:01 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> On Sat, Oct 10, 2009 at 11:34 AM, wrote: > Does anyone have ideas on how to word such a policy, where > to put it in the NRPM, etc.? > --Michael Dillon Perhaps somewhere like 4.2.7 & / or 4.3.7 Thoughts something along the lines of...... perhaps? Embedded Devices End-users networks with embedded devices are encouraged to use IPv6 addressing, or private IP address numbers (see RFC1918). Individual embedded devices may not count towards any more than 20% of the shown utilization for justification of any IPv4 End-User assignment or ISP reassignment. An embedded device is any host device which is not a workstation, server, or router. A workstation is a host that provides an interactive, general-purpose computing service to at least one unique person who physically interacts with hardware attached to that host. A server is a host that provides a content or communications service and allows at least one unique human member of the general public (per host) to fully interact with that service. A router is a host that provides an IPv4 network connection service to at least two unique IPv4 networks, or one IPv4 network and one IPv6 network, where each network services an average of at least two unique workstations, servers, or routers. From scottleibrand at gmail.com Sat Oct 10 15:05:07 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 10 Oct 2009 12:05:07 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> Message-ID: <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> Is a mobile phone a workstation? Scott On Oct 10, 2009, at 11:22 AM, James Hess wrote: > On Sat, Oct 10, 2009 at 11:34 AM, wrote: >> Does anyone have ideas on how to word such a policy, where >> to put it in the NRPM, etc.? >> --Michael Dillon > > Perhaps somewhere like 4.2.7 & / or 4.3.7 > Thoughts something along the lines of...... perhaps? > > Embedded Devices > End-users networks with embedded devices are encouraged to use > IPv6 addressing, or private IP address numbers (see RFC1918). > > Individual embedded devices may not count towards any more than 20% of > the shown utilization for justification of any IPv4 End-User > assignment or ISP reassignment. > > An embedded device is any host device which is not a workstation, > server, or router. > A workstation is a host that provides an interactive, > general-purpose computing service to at least one unique person who > physically interacts with hardware attached to that host. > A server is a host that provides a content or communications > service and allows at least one unique human member of the general > public (per host) to fully interact with that service. > A router is a host that provides an IPv4 network connection > service to at least two unique IPv4 networks, or one IPv4 network > and one IPv6 network, where each network services an average of at > least two unique workstations, servers, or routers. > _______________________________________________ > 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 joelja at bogus.com Sat Oct 10 15:27:02 2009 From: joelja at bogus.com (joel jaeggli) Date: Sat, 10 Oct 2009 12:27:02 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization Message-ID: <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> My mobile phone is a router, also a server, I'll presume for the sake of arguement that it's also a workstation. Plently of servers don't interact with humans. Scott Leibrand wrote: >Is a mobile phone a workstation? > >Scott > >On Oct 10, 2009, at 11:22 AM, James Hess wrote: > >> On Sat, Oct 10, 2009 at 11:34 AM, wrote: >>> Does anyone have ideas on how to word such a policy, where >>> to put it in the NRPM, etc.? >>> --Michael Dillon >> >> Perhaps somewhere like 4.2.7 & / or 4.3.7 >> Thoughts something along the lines of...... perhaps? >> >> Embedded Devices >> End-users networks with embedded devices are encouraged to use >> IPv6 addressing, or private IP address numbers (see RFC1918). >> >> Individual embedded devices may not count towards any more than 20% of >> the shown utilization for justification of any IPv4 End-User >> assignment or ISP reassignment. >> >> An embedded device is any host device which is not a workstation, >> server, or router. >> A workstation is a host that provides an interactive, >> general-purpose computing service to at least one unique person who >> physically interacts with hardware attached to that host. >> A server is a host that provides a content or communications >> service and allows at least one unique human member of the general >> public (per host) to fully interact with that service. >> A router is a host that provides an IPv4 network connection >> service to at least two unique IPv4 networks, or one IPv4 network >> and one IPv6 network, where each network services an average of at >> least two unique workstations, servers, or routers. >> _______________________________________________ >> 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. >_______________________________________________ >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 Wesley.E.George at sprint.com Sat Oct 10 15:30:25 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Sat, 10 Oct 2009 14:30:25 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> Message-ID: By this definition, yes I think a mobile phone is a workstation. Also, it becomes even moreso when you consider the ability to tether the phone for use as a data modem for a standard PC (carrier rules around tethering notwithstanding of course). I support this concept of a general limit on embedded device allocations, but since it looks like we're getting close to draft policy language, I think we need to be careful with how we define server - the below could exempt any smart meter or other device that has a web interface for management. I'm not sure whether "provides a content or communications service" covers that possibility... Thoughts? I realize it's ultimately up to interpretation by ARIN employees, but we should be very clear about the spirit behind this policy in order to remove as much confusion as possible in the future. I haven't looked through the drafts, but I'm wondering if there isn't actually fodder for the class of device we're trying to cover here in the ROLL or 6LOWPAN IETF WGs that we can incorporate as a reference. The charters seem to have some good stuff. Wes George -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Saturday, October 10, 2009 3:05 PM To: James Hess Cc: ppml at arin.net Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization Is a mobile phone a workstation? On Oct 10, 2009, at 11:22 AM, James Hess wrote: > A workstation is a host that provides an interactive, > general-purpose computing service to at least one unique person who > physically interacts with hardware attached to that host. > A server is a host that provides a content or communications > service and allows at least one unique human member of the general > public (per host) to fully interact with that service. > A router is a host that provides an IPv4 network connection > service to at least two unique IPv4 networks, or one IPv4 network > and one IPv6 network, where each network services an average of at > least two unique workstations, servers, or routers This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From mueller at syr.edu Sat Oct 10 15:19:20 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 10 Oct 2009 15:19:20 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> I haven't intervened in this debate even though it is a highly interesting one. One element seems to be lacking from the discussion. To me, it is an incredibly clear demonstration of the complete breakdown of the needs-based allocation principle as soon as scarcity arises. What Michael Dillon has been saying, in effect, is that organizations that can demonstrate a perfectly viable technical "need" for IPv4 addresses shouldn't get them. Maybe this is so obvious to all of you that it's going unstated, or maybe its an unstated assumption and it will clarify debates going forward if this is more openly acknowledged. If you abandon "demonstrated need" and are _not_ willing to use prices or some other neutral, market-based rationing principle, then all that is left is finer and finer classification and prioritization of specific uses. And down that road lies a form of ever more intrusive central planning. I.e., the RIR has to step in and decide for organizations whether it is better for them to base their plans on IPv4 or to re-engineer their plans based on a migration to IPv6. However you resolve such a debate, let's at least openly recognize and acknowledge that "need" is gone as a rationing principle. --MM > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Saturday, October 10, 2009 12:34 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to > somecategoryof organization > > > In terms of policy "embedded device" seems like a good point to > > identify in policy for denying massive V4 allocations. We > > certainly don't need need to be writing another policy in 6 > > months when > > technology X in industry B is in a similar position. > > There seems to be some level of support for a policy which > restricts the amount of IPv4 addresses that can be > allocated for the purpose of embedded system devices that > are not conventional PCs or servers. > > Since one might expect that there would be no issues with > giving these devices globally registered IPv4 addresses > *AFTER* the transition to IPv6, it seems wiser to phrase > this as a limited time moratorium rather than an outright > ban. The immediate effect is the same, but we can make sure > that it expires automatically when people's attention is > placed on more pressing IPv6 related issues in the future. > > Does anyone have ideas on how to word such a policy, where > to put it in the NRPM, etc.? > > --Michael Dillon > _______________________________________________ > 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 mysidia at gmail.com Sat Oct 10 15:40:18 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 10 Oct 2009 14:40:18 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> Message-ID: <6eb799ab0910101240i188847fbh758756f2320ff35d@mail.gmail.com> On Sat, Oct 10, 2009 at 2:05 PM, Scott Leibrand wrote: > Is a mobile phone a workstation? > > Scott Absolutely... why wouldn't they be? -- -J From scottleibrand at gmail.com Sat Oct 10 16:01:44 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 10 Oct 2009 13:01:44 -0700 Subject: [arin-ppml] Restricting IPv4 allocations by device type In-Reply-To: <6eb799ab0910101240i188847fbh758756f2320ff35d@mail.gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> <6eb799ab0910101240i188847fbh758756f2320ff35d@mail.gmail.com> Message-ID: <4AD0E828.3050708@gmail.com> My iPhone is definitely a workstation, and sometimes a router/server as well. But what about my previous phone, that was incapable of providing a "general-purpose computing service", and limited to a handful of functions "embedded" into it by the carrier? Such definitions are hard to get exactly right. And there are more devices out there, such as not-quite-smart phones, than there are IPv4 addresses remaining. (A quick search indicates there are about twice as many total handsets, globally, as remaining IPv4 addresses). So, a few large requests, from any number of sources (carriers, in this example) could easily exhaust the remaining IPv4 space. Given the large variety of different potential sources of run-on-the-bank early exhaustion, I am currently of the opinion that attempting to narrowly define which classes of devices are eligible for IPv4 addressing will be ineffective in preventing such a run. In fact, attempting to place restrictions could encourage applicants to apply early, to get in before the new policy. At some point in the near future, we're going to hit the point where IPv4 addresses are no longer freely available from the RIRs. At that point, the transfer and "leasing" markets will take over, and behavior will switch from "addresses are free" to "IPv4 addresses cost money" activities. In my opinion, the ability of policy to significantly delay that switch is quite limited. The best we can hope for is an orderly and predictable transition. -Scott James Hess wrote: > On Sat, Oct 10, 2009 at 2:05 PM, Scott Leibrand wrote: > >> Is a mobile phone a workstation? >> >> Scott >> > > Absolutely... why wouldn't they be? > > -- > -J > From JOHN at egh.com Sat Oct 10 16:07:23 2009 From: JOHN at egh.com (John Santos) Date: Sat, 10 Oct 2009 16:07:23 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <1091010154542.37986A-100000@Ives.egh.com> On Sat, 10 Oct 2009, Milton L Mueller wrote: > I haven't intervened in this debate even though it is a highly interesting one. One element seems to be lacking from the discussion. To me, it is an incredibly clear demonstration of the complete breakdown of the needs-based allocation principle as soon a > s scarcity arises. > > What Michael Dillon has been saying, in effect, is that organizations > that can demonstrate a perfectly viable technical "need" for IPv4 > addresses shouldn't get them. > I think you are confusing "need for IP addresses" with "need for IPv4 addresses." The proposed application apparently requires new network infrastructure (wireless from the electric meters to local access points with order of 10 access points needed to service a medium-sized city.) They may need IP addresses for each meter, but they certainly don't need IPv4 addresses. They may also need IP addresses for each access point, which may need to connect to existing IPv4 infrastructure, but that's an at least 3 orders of magnitude smaller problem. Maybe the rule should be "new types of infrastructure (as opposed to extending existing infrastructure) must be IPv6." New ISPs or new end users (businesses, colleges, govt agencies, etc.) providing traditional services similar to those already provided by existing ISPs or existing end users would fall under extending existing infrastructure and would be entitled to request IPv4, though they should be encouraged to use IPv6 or RFC 1918 private space. New uses, such as refrigerators, electric meters, and so forth, and new types of networks such as wide-area wireless networks, should be classed as "new infrastructure" and required to use IPv6. After all, the principle objection to using IPv6 seems to be limitations of existing equipment and the cost of upgrading/replacing it with IPv6-capable equipment, and these objections don't apply when building a network with all new equipment. > Maybe this is so obvious to all of you that it's going unstated, or maybe its an unstated assumption and it will clarify debates going forward if this is more openly acknowledged. > > If you abandon "demonstrated need" and are _not_ willing to use prices or some other neutral, market-based rationing principle, then all that is left is finer and finer classification and prioritization of specific uses. And down that road lies a form of > ever more intrusive central planning. I.e., the RIR has to step in and decide for organizations whether it is better for them to base their plans on IPv4 or to re-engineer their plans based on a migration to IPv6. > > However you resolve such a debate, let's at least openly recognize and acknowledge that "need" is gone as a rationing principle. > > --MM > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > Behalf Of michael.dillon at bt.com > > Sent: Saturday, October 10, 2009 12:34 PM > > To: ppml at arin.net > > Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to > > somecategoryof organization > > > > > In terms of policy "embedded device" seems like a good point to > > > identify in policy for denying massive V4 allocations. We > > > certainly don't need need to be writing another policy in 6 > > > months when > > > technology X in industry B is in a similar position. > > > > There seems to be some level of support for a policy which > > restricts the amount of IPv4 addresses that can be > > allocated for the purpose of embedded system devices that > > are not conventional PCs or servers. > > > > Since one might expect that there would be no issues with > > giving these devices globally registered IPv4 addresses > > *AFTER* the transition to IPv6, it seems wiser to phrase > > this as a limited time moratorium rather than an outright > > ban. The immediate effect is the same, but we can make sure > > that it expires automatically when people's attention is > > placed on more pressing IPv6 related issues in the future. > > > > Does anyone have ideas on how to word such a policy, where > > to put it in the NRPM, etc.? > > > > --Michael Dillon > > _______________________________________________ > > 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. > _______________________________________________ > 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. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From JOHN at egh.com Sat Oct 10 16:09:50 2009 From: JOHN at egh.com (John Santos) Date: Sat, 10 Oct 2009 16:09:50 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <1091010154542.37986A-100000@Ives.egh.com> Message-ID: <1091010160759.37986B-100000@Ives.egh.com> On Sat, 10 Oct 2009, John Santos wrote: > On Sat, 10 Oct 2009, Milton L Mueller wrote: > > > I haven't intervened in this debate even though it is a highly interesting one. One element seems to be lacking from the discussion. To me, it is an incredibly clear demonstration of the complete breakdown of the needs-based allocation principle as soon a > > s scarcity arises. > > > > What Michael Dillon has been saying, in effect, is that organizations > > that can demonstrate a perfectly viable technical "need" for IPv4 > > addresses shouldn't get them. > > > > I think you are confusing "need for IP addresses" with "need for IPv4 > addresses." > > The proposed application apparently requires new network infrastructure > (wireless from the electric meters to local access points with order of > 10 access points needed to service a medium-sized city.) > > They may need IP addresses for each meter, but they certainly don't > need IPv4 addresses. > > They may also need IP addresses for each access point, which may need to > connect to existing IPv4 infrastructure, but that's an at least 3 orders > of magnitude smaller problem. > > > Maybe the rule should be "new types of infrastructure (as opposed to > extending existing infrastructure) must be IPv6." > > New ISPs or new end users (businesses, colleges, govt agencies, etc.) > providing traditional services similar to those already provided by > existing ISPs or existing end users would fall under extending existing > infrastructure and would be entitled to request IPv4, though they should > be encouraged to use IPv6 or RFC 1918 private space. > > New uses, such as refrigerators, electric meters, and so forth, and new > types of networks such as wide-area wireless networks, should be classed > as "new infrastructure" and required to use IPv6. After all, the principle > objection to using IPv6 seems to be limitations of existing equipment > and the cost of upgrading/replacing it with IPv6-capable equipment, and > these objections don't apply when building a network with all new > equipment. > P.S. I left out a paragraph... Cell phones, ideally, should fall under the "new infrastructure" category, but that horse has (most likely) already left the barn. > > > Maybe this is so obvious to all of you that it's going unstated, or maybe its an unstated assumption and it will clarify debates going forward if this is more openly acknowledged. > > > > If you abandon "demonstrated need" and are _not_ willing to use prices or some other neutral, market-based rationing principle, then all that is left is finer and finer classification and prioritization of specific uses. And down that road lies a form of > > ever more intrusive central planning. I.e., the RIR has to step in and decide for organizations whether it is better for them to base their plans on IPv4 or to re-engineer their plans based on a migration to IPv6. > > > > However you resolve such a debate, let's at least openly recognize and acknowledge that "need" is gone as a rationing principle. > > > > --MM > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > > Behalf Of michael.dillon at bt.com > > > Sent: Saturday, October 10, 2009 12:34 PM > > > To: ppml at arin.net > > > Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to > > > somecategoryof organization > > > > > > > In terms of policy "embedded device" seems like a good point to > > > > identify in policy for denying massive V4 allocations. We > > > > certainly don't need need to be writing another policy in 6 > > > > months when > > > > technology X in industry B is in a similar position. > > > > > > There seems to be some level of support for a policy which > > > restricts the amount of IPv4 addresses that can be > > > allocated for the purpose of embedded system devices that > > > are not conventional PCs or servers. > > > > > > Since one might expect that there would be no issues with > > > giving these devices globally registered IPv4 addresses > > > *AFTER* the transition to IPv6, it seems wiser to phrase > > > this as a limited time moratorium rather than an outright > > > ban. The immediate effect is the same, but we can make sure > > > that it expires automatically when people's attention is > > > placed on more pressing IPv6 related issues in the future. > > > > > > Does anyone have ideas on how to word such a policy, where > > > to put it in the NRPM, etc.? > > > > > > --Michael Dillon > > > _______________________________________________ > > > 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. > > _______________________________________________ > > 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. > > > > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From mysidia at gmail.com Sat Oct 10 16:54:46 2009 From: mysidia at gmail.com (James Hess) Date: Sat, 10 Oct 2009 15:54:46 -0500 Subject: [arin-ppml] Restricting IPv4 allocations by device type In-Reply-To: <4AD0E828.3050708@gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> <6eb799ab0910101240i188847fbh758756f2320ff35d@mail.gmail.com> <4AD0E828.3050708@gmail.com> Message-ID: <6eb799ab0910101354o7087cff3u17443638709da6f4@mail.gmail.com> Oh, sorry.. some mobile phones are workstations, some are not, I suppose. Many provide web browsing, e-mail services, ones that allow the user to program/create, install, and use any applications of their choice, those are workstations. However, a mobile customer may be able to swap their workstation mobile phone with a non-workstation model at any time they want, if the mobile provider is selling a general service.. in this case, the phone isn't actually a permanent part of the provider's network, the provider is just the ISP, and the end user plugs in whatever phone they want at any time they want, with no inherent requirement to know about the mobile customer's equipment, any more than a dialup ISP can tell if the user dialing in is a workstation, or embedded device. The average mobile phone owner won't ever be applying to any RIR for IP addresses (in my estimation).. In that case, the utilization justification is "number of active mobile subscribers" at any point in time (e.g.. number of people), not "number of mobile phones" that coincidentally happen to be the type of the device the subscriber picks to attach at any given point in time. If the customer reasonably might attach a device with general computing capabilities at any time they want (without having to subscribe to or buy an additional service in order to do so beyond what they have), then that end-user is much like any dialup or DSL subscriber, right? I don't expect broadband providers to have to justify IPs for DVR equipment, if the customer chooses to plug that in one day, instead of a PC. End user _can_ plug in a PC at any time.. they could also choose to plug nothing in, and keep the service ready, in case they need it some day years later. -- -J From Wesley.E.George at sprint.com Sat Oct 10 19:00:38 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Sat, 10 Oct 2009 18:00:38 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: Saturday, October 10, 2009 3:19 PM To: michael.dillon at bt.com; ppml at arin.net Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization >I haven't intervened in this debate even though it is a highly interesting one. One element seems to be >lacking from the discussion. To me, it is an incredibly clear demonstration of the complete breakdown of the >needs-based allocation principle as soon as scarcity arises. Milton, I'm not convinced it's so black and white. My support of this potential policy is not an attempt to prevent any market or need-based controls for future IPv4 allocations. In my opinion, this is an appropriate extension to put some teeth in a recommendation ARIN made *2 years ago* which said "...The available IPv4 resource pool has now been reduced to the point that ARIN is compelled to advise the Internet community that migration to IPv6 is necessary for any applications that require ongoing availability from ARIN of contiguous IP number resources." https://www.arin.net/announcements/2007/20070521.html >What Michael Dillon has been saying, in effect, is that organizations that can demonstrate a perfectly viable >technical "need" for IPv4 addresses shouldn't get them. This is providing technical/policy guidance as to what is indeed a valid need. In a way, it is empowering ARIN staff to say, "you do not actually have a valid technical need for IPv4 addresses, because you could and should use IPv6 instead". Yes, this is a slippery slope because this argument can be applied to a lot of applications depending on how stringent the test is, but I think it differs in this case because we're talking about a greenfield deployment of custom-spec devices here. If we had thought about it 2 or 3 or 4 years ago, we might have been able to force the mobile wireless industry in a similar direction, but now, as others have said, that ship has sailed because of the cost to replace the embedded base of handsets, and must happen as devices are naturally replaced by those that do have IPv6 support. This is targeting new entries, which have the ability due to their application to use a large amount of the remaining resources. They are by their definition starting at ground zero - they have little or no existing "business" that they must work to preserve by using IPv4 until they can transition to IPv6, and therefore no justification to use a scarce resource at the expense of those that do. This is the same drill as changes to building codes and grandfather clauses covering the existing construction. It's unfair to the new entries because they have to do something different, but otherwise it would never change. One can draw parallels in attempts to legislate energy conservation as well. We all benefit, and it's unfair to have existing installations held to a lower standard, but the economics of the situation end up making that the reality, because it's usually cheaper to force a new design in a certain direction than it is to retrofit the entirety of the existing industry. We want to be able to force this issue before we get to a repeat of other applications, where the cost of replacing the embedded base in order to support IPv6 becomes a valid concern. I'm not interested in "but power company X didn't use IPv6 because their vendor didn't offer it..." because a contract of that size has a way of forcing the issue if it's actually important to the deployment of the application, nor is it a reason for the hardware to not have been designed to support both IPv4 and IPv6 for forward compatibility. Thanks Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From bill at herrin.us Sun Oct 11 10:13:05 2009 From: bill at herrin.us (William Herrin) Date: Sun, 11 Oct 2009 10:13:05 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <3c3e3fca0910110713s3e04b201re02d3dc8441ae037@mail.gmail.com> On Sat, Oct 10, 2009 at 3:19 PM, Milton L Mueller wrote: > What Michael Dillon has been saying, in effect, is that organizations > that can demonstrate a perfectly viable technical "need" for IPv4 > addresses shouldn't get them. > > However you resolve such a debate, let's at least openly recognize > and acknowledge that "need" is gone as a rationing principle. Milton, I would call your attention to the allocation policy change years ago in which virtual IP addresses for web servers no longer qualified as need. The change under discussion breaks no new ground. At most it again moves the yardstick for measuring need so that another set of technically valid ways to use IP addresses (for embedded systems) no longer qualifies because, as with web server virtual IPs, it's deemed too wasteful in light of scarcity. While redefining need based on free market weighting is an interesting idea which may yet prove useful, it's a much more radical policy change that what has been proposed in this thread. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Sun Oct 11 11:46:40 2009 From: randy at psg.com (Randy Bush) Date: Sun, 11 Oct 2009 08:46:40 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <3c3e3fca0910110713s3e04b201re02d3dc8441ae037@mail.gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910110713s3e04b201re02d3dc8441ae037@mail.gmail.com> Message-ID: > I would call your attention to the allocation policy change years ago > in which virtual IP addresses for web servers no longer qualified as > need. because http 1.1 passes the hostname in a use fashion, so the mass of addresses is not needed. > The change under discussion breaks no new ground. At most it again > moves the yardstick for measuring need so that another set of > technically valid ways to use IP addresses (for embedded systems) false. there was no technical change making the address space no longer needed. there are just people thinking their needs are more important than the needs of others. randy From bill at herrin.us Sun Oct 11 12:31:52 2009 From: bill at herrin.us (William Herrin) Date: Sun, 11 Oct 2009 12:31:52 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910110713s3e04b201re02d3dc8441ae037@mail.gmail.com> Message-ID: <3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> On Sun, Oct 11, 2009 at 11:46 AM, Randy Bush wrote: >> I would call your attention to the allocation policy change years ago >> in which virtual IP addresses for web servers no longer qualified as >> need. > > because http 1.1 passes the hostname in a use fashion, so the mass of > addresses is not needed. Randy, As much as you may wish to dress it up that way, that simply isn't true. Https, for example, does not function properly without a different IP address for each hostname because the SSL certificate for the server name must be offered to the browser before the HTTP 1.1 server name is transmitted by the browser. Even excluding the https issues, there were still a not-insignificant number of folks at the time using http 1.0 browsers (like NCSA Mosaic) that didn't supply the Host: request parameter. The policy change resulted in a forced upgrade for those stragglers. No, the historical fact is that we became alarmed by the address consumption for http servers and made a value judgment as a community that the address pool shouldn't support web server names in a 1:1 ratio to IP addresses. The technology would simply have to accommodate that judgment rather than the address pool accommodating the technology. The technical nature of the address' use would no longer qualify as "need." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jay at handynetworks.com Sun Oct 11 17:04:19 2009 From: jay at handynetworks.com (Jay Sudowski - Handy Networks LLC) Date: Sun, 11 Oct 2009 15:04:19 -0600 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> Message-ID: On 10/11/09 10:31 AM, "William Herrin" wrote: > On Sun, Oct 11, 2009 at 11:46 AM, Randy Bush wrote: >>> I would call your attention to the allocation policy change years ago >>> in which virtual IP addresses for web servers no longer qualified as >>> need. >> Just to clarify, for those who are not aware, while this virtual IP policy was passed, it was suspended by the board. This policy: When an ISP submits a request for IP address space, ARIN will not accept IP-based webhosting as justification for an allocation, unless an exception is warranted. Along with the request, organizations must provide appropriate details demonstrating their virtual webhosting customer base. Exceptions may be made for ISPs that provide justification for requiring static addresses. ARIN will determine, on a case-by-case basis, whether an exception is appropriate. Was changed to this: When an ISP submits a request for IP address space to be used for IP-based web hosting, they will supply (for informational purposes only) their technical justification for this practice. ARIN will analyze this data continuously, evaluating the need for future policy change. So while there is precedent for this kind of policy, ultimately, the policy was effectively overridden and replaced by something much less severe. -Jay Sudowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Sun Oct 11 18:23:02 2009 From: mysidia at gmail.com (James Hess) Date: Sun, 11 Oct 2009 17:23:02 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> Message-ID: <6eb799ab0910111523i65950398v176ba2f1b8350f23@mail.gmail.com> On Sun, Oct 11, 2009 at 4:04 PM, Jay Sudowski - Handy Networks LLC wrote: > So while there is precedent for this kind of policy, ultimately, the policy > was effectively overridden and replaced by something much less severe. Which doesn't say anything at all about the validity of policies of that nature. What it showed is that particular policy was seen as no longer needed. The policy may very well have had a hand in DNS-based virtual hosting becoming industry standard, and implemented by all common browsers and servers. Removal of the policy... didn't suddenly remove or stop use of name-based virtual hosting as a best practice. But if that policy was never created, IP-based virtual hosting might have become standard, and IP exhaustion could have happened years ago. The desired outcome may have been achieved in a manner, that even removing the policy would not actually have any effect. Technology doesn't just influence RIRs such as ARIN. ARIN can influence the development of technology in responsible ways, when it is threatening that a new development or new administrative practice will subsume all or nearly all remaining address space, -- -J From joelja at bogus.com Sun Oct 11 20:38:59 2009 From: joelja at bogus.com (joel jaeggli) Date: Sun, 11 Oct 2009 17:38:59 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization Message-ID: <6eb799ab0910111523i65950398v176ba2f1b8350f23@mail.gmail.com> In all fairness even those of us who had a large number of ip based virtual hosts back in the day would have considered it somewhat retarded to burn a /20 on a single system. We already had cnames and mxes, name-based virtual hosts were just another tool to decouple applications from transport. You might even call it a locator/identity split... James Hess wrote: >On Sun, Oct 11, 2009 at 4:04 PM, Jay Sudowski - Handy Networks LLC > wrote: >> So while there is precedent for this kind of policy, ultimately, the policy >> was effectively overridden and replaced by something much less severe. > >Which doesn't say anything at all about the validity of policies of >that nature. >What it showed is that particular policy was seen as no longer needed. > >The policy may very well have had a hand in DNS-based virtual hosting >becoming industry standard, and implemented by all common browsers and >servers. >Removal of the policy... didn't suddenly remove or stop use of >name-based virtual hosting as a best practice. > >But if that policy was never created, IP-based virtual hosting might >have become standard, and IP exhaustion could have happened years >ago. > >The desired outcome may have been achieved in a manner, that even >removing the policy would not actually have any effect. > >Technology doesn't just influence RIRs such as ARIN. >ARIN can influence the development of technology in responsible ways, >when it is threatening that a new development or new administrative practice >will subsume all or nearly all remaining address space, > > >-- >-J >_______________________________________________ >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 michael.dillon at bt.com Mon Oct 12 04:28:48 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 12 Oct 2009 09:28:48 +0100 Subject: [arin-ppml] Fairness of banning IPv4 allocations tosomecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <28E139F46D45AF49A31950F88C4974580386D554@E03MVZ2-UKDY.domain1.systemhost.net> > What Michael Dillon has been saying, in effect, is that > organizations that can demonstrate a perfectly viable > technical "need" for IPv4 addresses shouldn't get them. Wrong! Back in the early days of the IPv4 address registry, we had specific policy relating to web server virtual hosts so that people could not justify one IP address per web domain. In other words, we were saying that since the technical possibility of virtual hosting exists and makes it cheap and easy and reliable for multiple domains to share an IP address, you should use it. And if you don't use virtual hosting, then we will not accept your count of addresses needed. "Technical need" always refers to the technology of the day and its possibilities. In this case, embedded systems like Smart Grid can certainly use IPv6 for their communications so we want to forewarn them that we will judge any application requests in that way. And maybe we should even include mobile devices like cellphones in this restrictive policy. > If you abandon "demonstrated need" InterNIC and ARIN policies were never based on demonstrated need but on technical need, i.e. the need imposed by the technology of the day. > And down > that road lies a form of ever more intrusive central > planning. Down any road lies the future in which IPv6 will be widely deployed, and any IPv4 moratorium will be lifted. --Michael Dillon From tvest at eyeconomics.com Mon Oct 12 06:21:09 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Mon, 12 Oct 2009 11:21:09 +0100 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: Hi Milton, I'll grant that some of the recent exchanges could be loosely construed to support the claim that a "complete breakdown of the needs- based allocation principle" has occurred -- especially if one had already decided a priori that that NBA principle was false or illegitimate or inferior to some preferred arrangement. However, your claim is false -- and even your premises are false. First of all, the logic that you use here would have also implied that the shift from classful allocation to CIDR, and the establishment of the RIRs themselves also counted as clear evidence of a "complete breakdown." Things change, alas, and any entrepreneur that doesn't recognize and prepare in advance for changes in the primary constraints that shape their environment is probably going to be frequently "shocked, terribly shocked" by all sorts of complete breakdowns. In the real world, their redemption would require a lot more than just the ossification of address management policies. More fundamentally, your attempts to reduce the relevance of needs- based allocation to "scarcity management" is wrong-headed on multiple counts. The basic goal/rationale for coordinated management of IP number resources is to *mitigate* the risks and reduce/postpone the likely impacts of a range of systemic imbalances in the Internet's decentralized routing system -- including the opposing problems of *underuse* and *overuse* of both shared and/or collectively produced resources, i.e., of both IP addresses and routing system carrying capacity. As many recently established industry members can tell you (and I'd bet the vast majority of members of recently established RIRs can tell you from personal experience), risks of underuse of both kinds of resources are reduced by the presence of the RIRs as an "IP address distributor of last resort." And, as you have noted, the existing system is also well-suited to managing the risks of IP address overuse, and hence premature exhaustion. What you clearly fail to recognize, however, is that the coordinated management system is also uniquely well-adapted to reducing the risks of overuse of that other "shared" resource, i.e., routing system capacity. In this sense, the "needs assessments" that you fixate on are nothing more than proof of the "capitalization" of the ISPs that are seeking to obtain IP number resources. The required evidence of investment and beneficial control (in some form) of, e.g., hardware, a home for the hardware, people to look after the hardware, raw network elements to connect the hardware to the rest of the Internet, serves as proof that the aspiring address and routing capacity consumer has skin in *this* game. Proof that they have a nontrivial private stake in the shared system that they will henceforth be a free, large self-determining autonomous agent -- a stake that would be at risk if the shared system is damaged or fails altogether -- tends to align private incentives and behavior in ways that are consistent with the preservation and continued functioning of that shared system over time. *This* assurance, and the resulting alignment of incentives represents, IMO, the single most important factor that has enabled the decentralized, self-governing Internet to continue working so well over time. Granted, this arrangement is far from perfect perfect -- and the looming discontinuity in addressing formats is going to test the system like nothing before in Internet history -- but from where I sit this arrangement looks like the most freedom-preserving option available to all direct and indirect Internet stakeholders everywhere. In other words, if and when it changes, I wouldn't bet on that change leading to greater access to or freedom of anything good (addressing, routing, privacy, openness, individual empowerment, competition, commercial strategy, cross-border transparency, etc., etc.). (Close observers of the recent/ongoing financial crisis may have noted that the primary mechanism through which the perverse synergies of CDOs and CDSs contributed the current unpleasantness was by enabling financial institutions to fabricate their own capital reserves virtually at will, which effectively negated the formal "skin in this game" regulations that had previously incentivized them to act prudently -- but that too is a story for another time/place). This failure to appreciate the subtleties of how this industry works, and how the IP number resource coordination mechanisms help it to keep working is not entirely surprising, but I would strongly recommend that you consider doing a bit more research before you submit another routing and addressing system proposal to the ITU or any other institution. For example, in the "transferable address block lease" plan that you recently recommended to the ITU [1], you propose creating auctions which could grant any private commercial entity the means to resell up to (4 x /32) or about one-quarter million /48 IPv6 prefixes -- i.e., to effectively charter as many as one-quarter million new, fully autonomous participants in the shared routing system. Your plan would relieve those hundreds of thousands ~ millions of new participants of any/all requirements to demonstrate technical need or anything else that might attest to any material interest in the continued survival of the routing system (presumably -- unless of course you imagine that each of those PI /48s would cost as much or more that the hardware and other inputs required to make them useful?). And yet you claim that this change "would not make the current system any worse or any better with respect to routing table growth"...? I guess that assertion alone speaks for itself. If this understanding of how needs-based allocation actually works is still unclear, perhaps it would be easier to think of it in more familiar terms, e.g., as IP address allocation through a process of "vibrant (but very slow) facilities-based competition" -- albeit in this case with facilities that are freely available to anyone at competitive open market prices. Enough for now -- I'll leave list members to learn more on their own about your unique views on what constitutes legitimate "registry functions" and "rules of good conduct," and how these would be translated/implemented through your routing, addressing, and registry proposal. Regards all, TV [1] Section 3.3., "The Transferable Address Block Lease (TABL)," in Mueller, "Economic Factors in the Allocation of IP Addresses." http://www.itu.int/net/ITU-T/ipv6/ http://www.itu.int/dms_pub/itu-t/.../T3B020000020003PDFE.pdf On Oct 10, 2009, at 8:19 PM, Milton L Mueller wrote: > I haven't intervened in this debate even though it is a highly > interesting one. One element seems to be lacking from the > discussion. To me, it is an incredibly clear demonstration of the > complete breakdown of the needs-based allocation principle as soon > as scarcity arises. > > What Michael Dillon has been saying, in effect, is that > organizations that can demonstrate a perfectly viable technical > "need" for IPv4 addresses shouldn't get them. > > Maybe this is so obvious to all of you that it's going unstated, or > maybe its an unstated assumption and it will clarify debates going > forward if this is more openly acknowledged. > > If you abandon "demonstrated need" and are _not_ willing to use > prices or some other neutral, market-based rationing principle, then > all that is left is finer and finer classification and > prioritization of specific uses. And down that road lies a form of > ever more intrusive central planning. I.e., the RIR has to step in > and decide for organizations whether it is better for them to base > their plans on IPv4 or to re-engineer their plans based on a > migration to IPv6. > > However you resolve such a debate, let's at least openly recognize > and acknowledge that "need" is gone as a rationing principle. > > --MM > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- >> bounces at arin.net] On >> Behalf Of michael.dillon at bt.com >> Sent: Saturday, October 10, 2009 12:34 PM >> To: ppml at arin.net >> Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to >> somecategoryof organization >> >>> In terms of policy "embedded device" seems like a good point to >>> identify in policy for denying massive V4 allocations. We >>> certainly don't need need to be writing another policy in 6 >>> months when >>> technology X in industry B is in a similar position. >> >> There seems to be some level of support for a policy which >> restricts the amount of IPv4 addresses that can be >> allocated for the purpose of embedded system devices that >> are not conventional PCs or servers. >> >> Since one might expect that there would be no issues with >> giving these devices globally registered IPv4 addresses >> *AFTER* the transition to IPv6, it seems wiser to phrase >> this as a limited time moratorium rather than an outright >> ban. The immediate effect is the same, but we can make sure >> that it expires automatically when people's attention is >> placed on more pressing IPv6 related issues in the future. >> >> Does anyone have ideas on how to word such a policy, where >> to put it in the NRPM, etc.? >> >> --Michael Dillon >> _______________________________________________ >> 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. > _______________________________________________ > 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 owen at delong.com Mon Oct 12 08:47:06 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Oct 2009 05:47:06 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4E7025CD-15F3-4815-8E5D-E2AC9847DC41@delong.com> On Oct 10, 2009, at 12:19 PM, Milton L Mueller wrote: > I haven't intervened in this debate even though it is a highly > interesting one. One element seems to be lacking from the > discussion. To me, it is an incredibly clear demonstration of the > complete breakdown of the needs-based allocation principle as soon > as scarcity arises. > Or not... > What Michael Dillon has been saying, in effect, is that > organizations that can demonstrate a perfectly viable technical > "need" for IPv4 addresses shouldn't get them. > And the rest of your argument proceeds from the assumption that this is fact. Personally, I don't think such a policy is a good idea. I think that it is far more appropriate to continue issuing IPv4 addresses on a needs basis until we run out. The community has had plenty of notice that the solution to address shortage is IPv6. In the meantime, I agree that abandoning our existing needs based criteria is not a good choice unless a clearly better solution is available. I do not believe that a market based solution is superior, nor do I believe that increasingly invasive classification and prioritization is superior. > Maybe this is so obvious to all of you that it's going unstated, or > maybe its an unstated assumption and it will clarify debates going > forward if this is more openly acknowledged. > > If you abandon "demonstrated need" and are _not_ willing to use > prices or some other neutral, market-based rationing principle, then > all that is left is finer and finer classification and > prioritization of specific uses. And down that road lies a form of > ever more intrusive central planning. I.e., the RIR has to step in > and decide for organizations whether it is better for them to base > their plans on IPv4 or to re-engineer their plans based on a > migration to IPv6. > Yes, in my opinion, this is one of the best arguments stated so far for preserving the existing needs-based system rather than careening off into market or central- planning systems. > However you resolve such a debate, let's at least openly recognize > and acknowledge that "need" is gone as a rationing principle. > Rationing only applies when you are attempting to forestall the depletion of a scarce resource. That is not necessarily the case here. While forestalling IPv4 runout would be convenient for many, it's not likely to be successful over a significant period of time, and, there is an alternative that is gaining acceptance and does not have the address scarcity issues associated with IPv4. This reminds me of a recent discussion with a flight instructor about a maneuver known as a canyon turn. A canyon turn is an extreme maneuver designed to make a course reversal in as little lateral distance as possible. It is so called because it is primarily used in a situation where the pilot has flown up a canyon and cannot climb above the walls of the canyon. The student asked "What do I do if there is not enough room to make the canyon turn?" The instructor replied "Then the accident has already occurred. The pieces just haven't stopped moving yet." IPv4 runout is inevitable. No proposed rationing, reclamation, or market scheme will change that fact at this point. We may be able to change the date by small amounts, or, we may be able to change the speed at impact, but, the event will happen. Returning to the aviation analogy, if you are faced with such a situation, you really need to know when there isn't enough room. A controlled attitude trip through the trees will destroy the airplane and likely injure the occupants, but, is survivable in the vast majority of cases. On the other hand, a canyon turn (60 degrees of bank, flaps extended, and the elevator pulled back hard (nearly to the stall point of the wings)) is likely to result in a very deadly impact if you don't have enough room. With IPv4 runout, we just don't have enough room for even a canyon turn. Let's land straight ahead as best we can. Owen From owen at delong.com Mon Oct 12 08:48:08 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Oct 2009 05:48:08 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> Message-ID: Is my home theater amplifier a server? It answers on port 80 and provides an interface for controlling the amplifier. Owen On Oct 10, 2009, at 12:30 PM, George, Wes E [NTK] wrote: > By this definition, yes I think a mobile phone is a workstation. > Also, it becomes even moreso when you consider the ability to tether > the phone for use as a data modem for a standard PC (carrier rules > around tethering notwithstanding of course). > > I support this concept of a general limit on embedded device > allocations, but since it looks like we're getting close to draft > policy language, I think we need to be careful with how we define > server - the below could exempt any smart meter or other device that > has a web interface for management. I'm not sure whether "provides a > content or communications service" covers that possibility... > Thoughts? I realize it's ultimately up to interpretation by ARIN > employees, but we should be very clear about the spirit behind this > policy in order to remove as much confusion as possible in the future. > I haven't looked through the drafts, but I'm wondering if there > isn't actually fodder for the class of device we're trying to cover > here in the ROLL or 6LOWPAN IETF WGs that we can incorporate as a > reference. The charters seem to have some good stuff. > > Wes George > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Scott Leibrand > Sent: Saturday, October 10, 2009 3:05 PM > To: James Hess > Cc: ppml at arin.net > Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to > somecategoryof organization > > Is a mobile phone a workstation? > > On Oct 10, 2009, at 11:22 AM, James Hess wrote: > >> A workstation is a host that provides an interactive, >> general-purpose computing service to at least one unique person who >> physically interacts with hardware attached to that host. >> A server is a host that provides a content or communications >> service and allows at least one unique human member of the general >> public (per host) to fully interact with that service. >> A router is a host that provides an IPv4 network connection >> service to at least two unique IPv4 networks, or one IPv4 network >> and one IPv6 network, where each network services an average of at >> least two unique workstations, servers, or routers > > This e-mail may contain Sprint Nextel Company proprietary > information intended for the sole use of the recipient(s). Any use > by others is prohibited. If you are not the intended recipient, > please contact the sender and delete all copies of the message. > > _______________________________________________ > 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 randy at psg.com Mon Oct 12 10:58:15 2009 From: randy at psg.com (Randy Bush) Date: Mon, 12 Oct 2009 07:58:15 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910110713s3e04b201re02d3dc8441ae037@mail.gmail.com> <3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> Message-ID: > Https, for example, does not function properly without a different IP > address for each hostname because the SSL certificate for the server > name must be offered to the browser before the HTTP 1.1 server name is > transmitted by the browser. first, you mean apache, not https. second, it does work. been using it for years. you have to be cert smart. > Even excluding the https issues, there were still a not-insignificant > number of folks at the time using http 1.0 browsers (like NCSA Mosaic) in the computer museum in menlo park? > No, the historical fact is that we became alarmed by the address > consumption for http servers and made a value judgment as a community > that the address pool shouldn't support web server names in a 1:1 > ratio to IP addresses. if i had been on the internet in those long-forgotten days, i might remember it quite differently randy From cengel at sponsordirect.com Mon Oct 12 12:08:38 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Mon, 12 Oct 2009 12:08:38 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization Message-ID: It seems to me that a truism of human nature in that, the more critical a resource truly is... the harder people will work to obtain it AND the harder humans have to work for a resource the more willing they are to attempt to find some alternative to it. I bring this up in the context of the current discussion because of the relevance it has to the growing scarcity of IPv4 addresses and the speed at which IPv6 (or other alternatives to the use of IPv4 addresses). While I am a fan of "needs based" allocation, there is a simple and basic problem with it....not only is it very tricky to define exactly what constitutes "need"... even once you have those definitions.... it is very simple for an applicant to simply "cheat" to qualify for them. That is another unfortunate truism of human nature, many people are willing to be dishonest to obtain what they desire...and large organizations/corporations are no less susceptible to such temptations than individuals. What an organization may claim as a "need" for IPv4 addresses may in reality translate to nothing more then "it will cost us 3 cents more per unit to use IPv4 then IPv6". However, an organization will most certainly not present it that way in their application. They will probably invent a very convincing rationalization why they absolutely and positively cannot implement a solution without IPv4 addresses. I'm hardly the most creative person and I can think of many different ways to "spin" such presentations. Rest assured that organizations with large budgets on the line will find very creative ways to justify their need. Getting to the actual truth of such justifications would be very difficult and expensive and probably impossible without some sort of subpoena power. Perhaps the better route, rather then a need based system, WOULD be to place some sort of cost on obtaining IPv4 addresses reflective of the actual scarcity of them. I think such a concept does have merit. You could also put some sort of weighting system in place that the more IPv4 addresses you own, the more it costs to obtain each additional one. This could help dampen "run on the bank" type effects when instituting such a system.... as it would make it financially unattractive to obtain more then you needed...as some sort of guard against future scarcity or to purchase large numbers simply to speculate with them. The whole idea behind such a scheme, of course, is to create a "soft crash" rather then a "hard crash" of address space which would be far more disruptive. Ultimately IPv4 space WILL run out, as we all know. However, if it becomes less cost effective to use large quantities of IPv4 space people will find alternatives (including IPv6)... and for those that truly face huge hurdles the ability to obtain them still exists...just at a premium. In many ways, this situation is a prime example of "the tragedy of the commons". Christopher Engel From kkargel at polartel.com Mon Oct 12 12:21:20 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 12 Oct 2009 11:21:20 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocationsto somecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com><28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A396@mail> Do I remember correctly that there was a discussion about implementing a general cap on allocation size that would cover this issue without all the politics? If we really want to do this perhaps the diminishing cap would solve the problem. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Milton L Mueller > Sent: Saturday, October 10, 2009 2:19 PM > To: michael.dillon at bt.com; ppml at arin.net > Subject: Re: [arin-ppml] Fairness of banning IPv4 allocationsto > somecategoryof organization > > I haven't intervened in this debate even though it is a highly interesting > one. One element seems to be lacking from the discussion. To me, it is an > incredibly clear demonstration of the complete breakdown of the needs- > based allocation principle as soon as scarcity arises. > > What Michael Dillon has been saying, in effect, is that organizations that > can demonstrate a perfectly viable technical "need" for IPv4 addresses > shouldn't get them. > > Maybe this is so obvious to all of you that it's going unstated, or maybe > its an unstated assumption and it will clarify debates going forward if > this is more openly acknowledged. > > If you abandon "demonstrated need" and are _not_ willing to use prices or > some other neutral, market-based rationing principle, then all that is > left is finer and finer classification and prioritization of specific > uses. And down that road lies a form of ever more intrusive central > planning. I.e., the RIR has to step in and decide for organizations > whether it is better for them to base their plans on IPv4 or to re- > engineer their plans based on a migration to IPv6. > > However you resolve such a debate, let's at least openly recognize and > acknowledge that "need" is gone as a rationing principle. > > --MM > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > Behalf Of michael.dillon at bt.com > > Sent: Saturday, October 10, 2009 12:34 PM > > To: ppml at arin.net > > Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to > > somecategoryof organization > > > > > In terms of policy "embedded device" seems like a good point to > > > identify in policy for denying massive V4 allocations. We > > > certainly don't need need to be writing another policy in 6 > > > months when > > > technology X in industry B is in a similar position. > > > > There seems to be some level of support for a policy which > > restricts the amount of IPv4 addresses that can be > > allocated for the purpose of embedded system devices that > > are not conventional PCs or servers. > > > > Since one might expect that there would be no issues with > > giving these devices globally registered IPv4 addresses > > *AFTER* the transition to IPv6, it seems wiser to phrase > > this as a limited time moratorium rather than an outright > > ban. The immediate effect is the same, but we can make sure > > that it expires automatically when people's attention is > > placed on more pressing IPv6 related issues in the future. > > > > Does anyone have ideas on how to word such a policy, where > > to put it in the NRPM, etc.? > > > > --Michael Dillon > > _______________________________________________ > > 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. > _______________________________________________ > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From tedm at ipinc.net Mon Oct 12 14:51:09 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 12 Oct 2009 11:51:09 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4AD37A9D.9090708@ipinc.net> Milton L Mueller wrote: > I haven't intervened in this debate even though it is a highly interesting one. One element seems to be lacking from the discussion. To me, it is an incredibly clear demonstration of the complete breakdown of the needs-based allocation principle as soon as scarcity arises. > I disagree. It's not a COMPLETE breakdown. However, you are correct in that it -IS- a breakdown. > What Michael Dillon has been saying, in effect, is that organizations that can demonstrate a perfectly viable technical "need" for IPv4 addresses shouldn't get them. > There is no perfectly viable need for IPv4 addresses, such a thing is impossible. But, essentially this is correct. Michael is saying that orgs that could demonstrate a need for large chunks of IPv4 under the current policy, shouldn't get them - thus we should change policy to exclude them. > Maybe this is so obvious to all of you that it's going unstated, I think it's not obvious to most people, Milton, because most people in the discussion like to think of themselves as no-regulation, hands-off kind of people. They are horrified to be pushed into regulating a market, and are trying desperately to make excuses to themselves that what they are discussing really isn't regulation - even when it is. > If you abandon "demonstrated need" and are _not_ willing to use prices or some other neutral, market-based rationing principle, > But, why should we? Your operating from the assumption that because a market's decisions are mindless, that they are somehow more "fair" This is a bankrupt assumption which has been more than adequately demonstrated by the recent economic events in the United States. All those "markets are fair" people were the first in line for TARP funds when their backs were against the wall. All that "market is good" conservativism was shown for the fraud it is when that happened. The first fact is that the IPv4 depletion is going to cause problems, that will cost some people money. I'd say a LOT of people money. The second fact is that this money is going to come from the users, ultimately. In higher Internet fees, or other less-visible side-effects. The third fact is that a network is more useful the more people are on it, and there is a snowball effect that's going - the more people who connect the more useful it is thus the more who are attracted to connect, etc. The last fact is that when you add up the pros and cons, the Internet has been good for humanity. It's not something we want to go away. The goal of ALL of the Internet governing communities and groups out there should be to attempt to mitigate as much as possible the effects of IPv4-runout. In other words, make decisions that will enable the maximum number of users to connect. Users, as in PEOPLE. The fact is that connecting an electric utility meter adds virtually NOTHING to attract more people to connect to the Internet. Connecting such a thing to the Internet benefits the utility. It does not reduce costs of everyone else on the Internet to connect to the Internet. It does not add anything to attract people to the Internet. It does not add warm bodies to the Internet, thus increasing the Internet's attractiveness to people. In other words, it's an action that is almost universally a detriment to the Internet. Just like having a billion people come tramping through Yellowstone park in a year would be a huge detriment. The conservatives and liberals would both agree that doing this to Yellowstone would harm it. However, the conservatives response is to turn Yellowstone into Disneyland and charge people to get in, and just raise prices until the number of people who get in are reduced to a sustainable level. This is like what your advocating in saying "market based rationing" for the Internet. Your advocating that it's fair. But, it would destroy Yellowstone because it would turn it in to a rich man's playground - and then the taxpayers would start asking why are we paying for this place out of our taxes to be a National Part when most of us will never get inside. Thus Yellowstone would be sold to the developers and parceled out into condos. The liberals would say the answer to Yellowstone is to regulate the number of times a person could come into Yellowstone, maybe to 10 times during their lifetime. Of course, this would piss off the conservatives - it's no surprise that most rich people are conservatives, by the way - but the advantage is it would preserve the ability for Joe Sixpack to go to Yellowstone - if he wanted. Thus preserving support for it BY REGULATION. What the ARIN community here needs to be doing is to be applying REGULATION to IPv4 numbering that preserves Joe Sixpack's access to the Internet. NOT the BigCo rich utilities access to the Internet so they can fire their meter readers (in the midst of a recession) and save some bucks in labor. We invented IPv6 for those BigCo's, they need to use it. I personally don't have a problem doing that. Most everyone else here doesn't either - although quite a lot of them seem to not want to face the fact that Regulating is what they are doing. Ted From farmer at umn.edu Mon Oct 12 19:20:30 2009 From: farmer at umn.edu (David Farmer) Date: Mon, 12 Oct 2009 18:20:30 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocationsto somecategoryof organization In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A396@mail> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com>, <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, <70DE64CEFD6E9A4EB7FAF3A06314106601F4A396@mail> Message-ID: <4AD3736E.1218.335E72F4@farmer.umn.edu> On 12 Oct 2009 Kevin Kargel wrote: > Do I remember correctly that there was a discussion about implementing > a general cap on allocation size that would cover this issue without > all the politics? If we really want to do this perhaps the > diminishing cap would solve the problem. There have been several discussion on PPML and within the AC about allocation limits, some say they are non-discriminatory others say that they discriminate against the large users of IP space, especially large ISPs. At ARIN XXIII in San Antonio, draft policy 2009-2: Depleted IPv4 reserves was discussed; basically once ARIN dropped below a /9, it limited all allocations to /20, within a 6 month period. Many felt this rationed IPv4 address space to much and wasn't fair to larger and medium sized ISPs. https://www.arin.net/policy/proposals/2009_2.html In response Leo and I provided two IPv4 run-out proposals which have been merged into a single draft policy 2009-8: Equitable IPv4 Run-Out. Which will be discussed next week at ARIN XXIV in Dearborn. https://www.arin.net/policy/proposals/2009_8.html This draft policy proposes to reduce the supply of IPv4 addresses that can be requested from a 12 month supply to a 6 month supply and then to a 3 month supply as the IANA free pool dwindles down. Then when ARIN receives it last /8, set a maximum allocation size of (1/4) one quarter of ARIN's available IPv4 resources within a three month period. The intent is to reduce and limit the likely competitive issues created as IPv4 runs-out. If some set of ISPs get a one year supply of addresses right before run-out and another set of ISPs do not, then this will create competitive issues within the ISP market. By gradually reducing the length of supply that can be requested, these competitive issues can be contained to approximately a quarter or two instead of as much as a year or two that is likely under current policy. Further by putting in place a maximum allocation of (1/4) one quarter of the available resources once ARIN receives its last /8, ensures that no one request can consume all of ARIN's resources. It is my belief that this policy is still needs based, it simply recognizes that the not everyones needs are going to be able to be meet and that some measure of equity is necessary in addition to a simple needs basis, as the IPv4 resources are depleted. While I believe that the Smart Gird folks should be encouraged to use IPv6, and it should be made plain to them that only IPv6 has the necessary resources to really meet their long-term needs. I believe they should have equal access to the remaining IPv4 resources under the same terms as everyone else. They should have the same limits on the supply they can request. Therefore, they should only be able to get what they can deploy in the given time frames and given that they would likely need to go touch each meter to do this, I think there is a reasonable self-limiting factor on the amount of address space they can consume before IPv4 is depleted. I think it is really dangerous to start talking about who is worthy or not worthy of receiving the remaining IPv4 address space. You could argue that only new users should get it, you could argue that only current users should get it, you could argue that only the big ISPs should get it, you could argue that only the small ISPs should get it, you could argue that only end-user organizations should get it, and you could argue that only those that have deployed IPv6 should get it. If we do any of those, I believe all we will do is waste effort on IPv4 that should be spent on deploying IPv6. Please understand 2009-8 is not intended to do anything to control the overall rate at which IPv4 is depleted, its only goals are to reduce and limit the likely competitive issues as we approach IPv4 depletion and to prevent a single request from exhausting ARIN's IPv4 resources once ARIN has received its last /8. Why is this important? If some believe there is even a medium-term competitive advantage with IPv4 and to not adopt IPv6, they my delay IPv6 adoption. Also, if there were a nasty surprise and ARIN all of a sudden runs- out of IPv4 because of a final large request takes everything that is left. Then effort will be spent arguing and making recriminations about how IPv4 depleted, and not spent on adopting IPv6. So, it is important to maintain some semblance of order as IPv4 depletes, to reduce distractions and allow people to focus on IPv6 adoption. We need to focus on IPv6 adoption, and only make those changes to IPv4 policy that helps us stay focused on IPv6 adoption. Continuing a debate about which uses justify the limited IPv4 that is left is distracting, and will likely only fracture our community when we need to be focus on IPv6 adoption. =============================================== David Farmer Email:farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 =============================================== From Wesley.E.George at sprint.com Mon Oct 12 20:02:43 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Mon, 12 Oct 2009 19:02:43 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> Message-ID: Owen, I thought about this sort of thing (I have a similar receiver) but didn't think it worth mentioning because step one is that the user must be asking for public IPs from ARIN, which a home user will not be doing. I highly doubt that you (or the manufacturer) ever intended it to have a public IP address and be world-reachable, and therefore it's unlikely that [insert HT maker or big-box electronics retailer here] is going to show up asking for multiple /8s to address them. It gets a 1918 address just like all the rest of the devices in your home LAN, and is perfectly happy with it. If you REALLY want it publicly accessible, you enable port forwarding, etc. If embedded devices all lived behind a SOHO router (and its associated NAT), using the existing public IPv4 address that has been allocated for the broadband connection, we wouldn't have a problem, except in the places where the meter uses its own connectivity (wireless usually) or it's otherwise not feasible to put the embedded device on an existing network. Thanks, Wes -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, October 12, 2009 8:48 AM To: George, Wes E [NTK] Cc: Scott Leibrand; James Hess; ppml at arin.net Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization Is my home theater amplifier a server? It answers on port 80 and provides an interface for controlling the amplifier. Owen This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From tedm at ipinc.net Mon Oct 12 20:44:34 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 12 Oct 2009 17:44:34 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <6eb799ab0910101122o5cf5dc34s930276057e3e71bd@mail.gmail.com> <1804C893-1B14-4EE4-83C6-8F99428E6310@gmail.com> Message-ID: <4AD3CD72.1030404@ipinc.net> Is this an assumption that NAT will be present forever? I have a 1 year old home receiver. It replaced a 30 year old home receiver, and does the same thing the old one did. I only replaced it because the old one wouldn't take a fiber input from my new HDTV. I'll be quite pissed if the assumption is that it will be obsoleted in 3 years!!! I would be willing to bet that Owen's receiver will outlast the IPv4 runout. I'll also be willing to bet that he won't have a proverbial snowballs chance in hell of ever getting a firmware update from the manufacturer to make it IPv6 compliant. All the more reason for something like this proposed ban! In the home receiver market it may only have "political" significance, but that matters! Ted George, Wes E [NTK] wrote: > Owen, I thought about this sort of thing (I have a similar receiver) but didn't think it worth mentioning because step one is that the user must be asking for public IPs from ARIN, which a home user will not be doing. I highly doubt that you (or the manufacturer) ever intended it to have a public IP address and be world-reachable, and therefore it's unlikely that [insert HT maker or big-box electronics retailer here] is going to show up asking for multiple /8s to address them. It gets a 1918 address just like all the rest of the devices in your home LAN, and is perfectly happy with it. If you REALLY want it publicly accessible, you enable port forwarding, etc. > > If embedded devices all lived behind a SOHO router (and its associated NAT), using the existing public IPv4 address that has been allocated for the broadband connection, we wouldn't have a problem, except in the places where the meter uses its own connectivity (wireless usually) or it's otherwise not feasible to put the embedded device on an existing network. > > > Thanks, > Wes > > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, October 12, 2009 8:48 AM > To: George, Wes E [NTK] > Cc: Scott Leibrand; James Hess; ppml at arin.net > Subject: Re: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization > > Is my home theater amplifier a server? > > It answers on port 80 and provides an interface for controlling the > amplifier. > > Owen > > This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > > _______________________________________________ > 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 mueller at syr.edu Tue Oct 13 07:16:24 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 13 Oct 2009 07:16:24 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, Message-ID: <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> >[1] Section 3.3., "The Transferable Address Block Lease (TABL)," in >Mueller, "Economic Factors in the Allocation of IP Addresses." >http://www.itu.int/net/ITU-T/ipv6/ >http://www.itu.int/dms_pub/itu-t/.../T3B020000020003PDFE.pdf Tom Thanks for calling attention to the ITU report, I was actually unaware that it had finally been released publicly. Understand what this report is. ITU was authorized by its member states to investigate its possible role in IPv6 address allocation. In connection with that mandate, it commissioned two reports. One, performed by the NAV6 center in Malaysia, investigated the possibility of doing IPv6 allocation by having the ITU delegate address blocks to Country Internet Registries (CIRs). The other, performed by me, investigated the use of ?market forces? as an alternative to both ITU delegation and RIR needs assessment in v6 allocation. As was written in the report, ?The purpose of [the report] is not necessarily to advocate market-oriented policies, but simply to gain a better understanding of what options exist and what implications they might have for [IPv6] address management.? As an organization whose members are nation-states, ITU obviously favors the CIR approach. ITU should be credited, however, with some degree of impartiality and integrity for its willingness to support an exploration of other alternatives. (It is worth noting that its staff's reaction to my critique of needs-based allocation was similar to yours.) Contrary to your representation, the report takes full account of the relationship between address allocation and routing, and indeed constitutes one of the first attempts to understand that relationship from the standpoint of institutional economics theory. Obviously, a lot more sophisticated analysis could be and needs to be done (and not just apologetics for the status quo such as yours). The report refers repeatedly to the ?interdependence of routing and addressing,? and says in Section 1.1, ?The policy problem we are faced with is not, in fact, one of efficiently allocating IP addresses per se. The overarching problem is actually the efficiency and scalability of Internet routing. The possession of IP addresses is significant and valuable only insofar as they can be used to route packets on the public Internet.? Please read section 1.3 for further analysis. Your attempt to criticize the report?s approach to the impact of TABLs on routing misses the mark. You commit a simple logical error, or perhaps didn?t actually read the proposal details, or maybe are simply misrepresenting what was said, it is hard to tell. You imply that address blocks would be auctioned when in fact, the report considers and rejects auctions as a method for initial allocation of ipv6 address blocks. See section 3.2. It proposes, instead, that RIRs use fees geared to size of address blocks to allocate resources. The TABL proposal specifies that blocks so allocated cannot be disaggregated and parcelled out to other ASs. By saying that the proposal "would not make the current system any worse or any better with respect to routing table growth" my point was that for routing purposes it matters not at all whether the initial allocation of ipv6 address blocks is based on ?need? as defined by RIRs or on the basis of fees, as suggested in the report ? what matters is the size of the blocks and the degree to which they are disaggregated. Can you dispute that? --MM From tedm at ipinc.net Tue Oct 13 11:35:57 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 13 Oct 2009 08:35:57 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4AD49E5D.8030401@ipinc.net> Milton L Mueller wrote: >> [1] Section 3.3., "The Transferable Address Block Lease (TABL)," in >> Mueller, "Economic Factors in the Allocation of IP Addresses." >> http://www.itu.int/net/ITU-T/ipv6/ >> http://www.itu.int/dms_pub/itu-t/.../T3B020000020003PDFE.pdf > > Tom Thanks for calling attention to the ITU report, I was actually > unaware that it had finally been released publicly. > > Understand what this report is. ITU was authorized by its member > states to investigate its possible role in IPv6 address allocation. > In connection with that mandate, it commissioned two reports. One, > performed by the NAV6 center in Malaysia, investigated the > possibility of doing IPv6 allocation by having the ITU delegate > address blocks to Country Internet Registries (CIRs). The other, > performed by me, investigated the use of ?market forces? as an > alternative to both ITU delegation and RIR needs assessment in v6 > allocation. As was written in the report, ?The purpose of [the > report] is not necessarily to advocate market-oriented policies, but > simply to gain a better understanding of what options exist and what > implications they might have for [IPv6] address management.? > > As an organization whose members are nation-states, ITU obviously > favors the CIR approach. ITU should be credited, however, with some > degree of impartiality and integrity for its willingness to support > an exploration of other alternatives. (It is worth noting that its > staff's reaction to my critique of needs-based allocation was similar > to yours.) > There are no other realistic alternatives. ITU supported an exploration because it's obvious that the opponents of a CIR approach - conservatives like you - are all favoring a Wild West, sale to the highest bidder market for IP addresses, and they might as well document how terrible that would be for all to see. You did your job admirably - but you still fail to grasp or respond to the underlying critique of a market-oriented policy when it comes to IP assignments, namely that by turning the Internet into a rich man's playground, it will destroy the fundamental usefulness of it. > Contrary to your representation, the report takes full account of the > relationship between address allocation and routing, and indeed > constitutes one of the first attempts to understand that relationship > from the standpoint of institutional economics theory. Obviously, a > lot more sophisticated analysis could be and needs to be done (and > not just apologetics for the status quo such as yours). The report > refers repeatedly to the ?interdependence of routing and addressing,? > and says in Section 1.1, ?The policy problem we are faced with is > not, in fact, one of efficiently allocating IP addresses per se. The > overarching problem is actually the efficiency and scalability of > Internet routing. The possession of IP addresses is significant and > valuable only insofar as they can be used to route packets on the > public Internet.? Please read section 1.3 for further analysis. > You cannot expect the mindless market to distribute IP addressing to enhance Internet access for everyone. Introducing the market merely changes the IP address distribution to favor the wealthy. > Your attempt to criticize the report?s approach to the impact of > TABLs on routing misses the mark. You commit a simple logical error, > or perhaps didn?t actually read the proposal details, or maybe are > simply misrepresenting what was said, it is hard to tell. You imply > that address blocks would be auctioned when in fact, the report > considers and rejects auctions as a method for initial allocation of > ipv6 address blocks. See section 3.2. It proposes, instead, that RIRs > use fees geared to size of address blocks to allocate resources. The > TABL proposal specifies that blocks so allocated cannot be > disaggregated and parcelled out to other ASs. By saying that the > proposal "would not make the current system any worse or any better > with respect to routing table growth" my point was that for routing > purposes it matters not at all whether the initial allocation of ipv6 > address blocks is based on ?need? as defined by RIRs or on the basis > of fees, as suggested in the report ? what matters is the size of the > blocks and the degree to which they are disaggregated. Can you > dispute that? > Once you replace need-based distribution into a market with fee-based distribution, what follows is lots of economic power that over time will erode all of the safeties installed in the initial market - such as your specification that blocks so allocated cannot be deaggregated. The moment that it would be economically advantageous to a wealthy org to break this rule, the rule would be broken and discarded. This is exactly what happened in the US housing market - originally the financial controls were installed to prevent the housing runup - these controls were chafed against by the wealthy, for many years, until eventually the wealthy managed to take over and remove them - and within 10 years, the market exploded and collapsed. That is the ultimate end to all market-based solutions like you conservatives advocate because you continually ignore the intrusion of political power into the market and it's corrupting influence. The battle cry of the conservatives is that "those" wealthy corrupting conservatives that destroy controls aren't "real" conservatives, the problem is in the people making poor choices, not in a flawed system. You fail to see that a flawed system rewards poor choices and penalizes good choices, thus it's ultimately going to influence even the best people to make flawed choices. (such as the TARP bailout) Ted From gih at apnic.net Tue Oct 13 13:21:00 2009 From: gih at apnic.net (Geoff Huston) Date: Wed, 14 Oct 2009 04:21:00 +1100 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <4AD49E5D.8030401@ipinc.net> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> <4AD49E5D.8030401@ipinc.net> Message-ID: <931666D5-0D93-4166-B994-7646E083444C@apnic.net> On 14/10/2009, at 2:35 AM, Ted Mittelstaedt wrote: > Milton L Mueller wrote: >>> [1] Section 3.3., "The Transferable Address Block Lease (TABL)," in >>> Mueller, "Economic Factors in the Allocation of IP Addresses." http://www.itu.int/net/ITU-T/ipv6/ >>> http://www.itu.int/dms_pub/itu-t/.../T3B020000020003PDFE.pdf >> Tom Thanks for calling attention to the ITU report, I was actually >> unaware that it had finally been released publicly. >> Understand what this report is. ITU was authorized by its member >> states to investigate its possible role in IPv6 address allocation. >> In connection with that mandate, it commissioned two reports. One, >> performed by the NAV6 center in Malaysia, investigated the >> possibility of doing IPv6 allocation by having the ITU delegate >> address blocks to Country Internet Registries (CIRs). The other, >> performed by me, investigated the use of ?market forces? as an >> alternative to both ITU delegation and RIR needs assessment in v6 >> allocation. As was written in the report, ?The purpose of [the >> report] is not necessarily to advocate market-oriented policies, but >> simply to gain a better understanding of what options exist and what >> implications they might have for [IPv6] address management.? >> As an organization whose members are nation-states, ITU obviously >> favors the CIR approach. ITU should be credited, however, with some >> degree of impartiality and integrity for its willingness to support >> an exploration of other alternatives. (It is worth noting that its >> staff's reaction to my critique of needs-based allocation was similar >> to yours.) > > There are no other realistic alternatives. ITU supported an > exploration because it's obvious that the opponents of a CIR > approach - > conservatives like you - are all favoring a Wild West, sale to the > highest bidder market for IP addresses, and they might as well > document how terrible that would be for all to see. > > You did your job admirably - but you still fail to grasp or respond > to the underlying critique of a market-oriented policy when it comes > to IP assignments, namely that by turning the Internet into a > rich man's playground, it will destroy the fundamental usefulness of > it. I happen to agree entirely with Ted in this comment that this latest nonsense from Milton and his ITU cronies represents a fundamental threat to the viability of the network by promoting an address distribution architecture that is unroutable at a global scale. This approach that Milton has been pedalling to the ITU-T for more than five years now is simply poorly conceived and poorly thought through, and it fosters outcomes that will destroy the utility of the Internet as Ted comments above. Its dismaying to see the ITU picking up on this - I truly thought that there were at least some folk in the ITU-T who were able to exercise some adult supervision in this area of activity. Evidently not. When I first heard of this work from Milton back in 2005 I was prompted to collaborate with Paul Wilson and write this item in response: http://www.potaroo.net/ispcol/2005-04/compete.html Nothing has changed over the past 5 years. When I read the revised ITU- published documents last week I could see anything new in it - it contains the same faulty thinking, the same poor research and the same warped attempts at logic based on a pretty comprehensive misunderstanding of the way in which a self-regulatory framework operates in this environment of address distribution and routing for the Internet. > >> Contrary to your representation, the report takes full account of the >> relationship between address allocation and routing, and indeed >> constitutes one of the first attempts to understand that relationship >> from the standpoint of institutional economics theory. That claim is of course arrogant nonsense! >> Obviously, a >> lot more sophisticated analysis could be and needs to be done (and >> not just apologetics for the status quo such as yours). or ill-concieved and poorly informed rhetoric cloaked in the format of a study as in the case of these ITU-published documents? >> The report >> refers repeatedly to the ?interdependence of routing and addressing,? >> and says in Section 1.1, ?The policy problem we are faced with is >> not, in fact, one of efficiently allocating IP addresses per se. The >> overarching problem is actually the efficiency and scalability of >> Internet routing. The possession of IP addresses is significant and >> valuable only insofar as they can be used to route packets on the >> public Internet.? Please read section 1.3 for further analysis. > > You cannot expect the mindless market to distribute IP addressing to > enhance Internet access for everyone. Introducing the market merely > changes the IP address distribution to favor the wealthy. I suspect that there are a range of possible outcomes and the scenario you paint here Ted is one possible such outcome. Other outcomes tend towards a "race to the bottom" in promoting address policies that emphasise "address portability" for consumers and unleash onto an unsuspecting and ill-equipped routing system a few hundred million independently routed /48s. None of these outcomes fill me with any confidence at all that the authors of these ITU papers have the slightest clue of what they are talking about in terms of their impact on network operators, on consumers and on the network's viability as a whole. If we really want to submarine any hope whatsoever of a transition to IPv6 this form of meddling in the address distribution framework is about as good a negative intervention as one could possibly imagine! It seems ironic to me that this proposal has been funded by the ITU, who has always had a deep and abiding interest in the welfare of the developing economies in our world. If there was just one aspect of Ipv6 that truly makes changes the environment, its a change in the availability of addresses in IPv6. At last we have the ability to not just ensure that there is one address for every person in this planet but one address for every device on this planet now and for a century or more to come. When ARIN discussed this at an IPv6 roundtable back in 2005 David Conrad presented the wonderful analogy that if an address was the same as a single grain of sand then IPv6 does not just represent the 90 mile beach, or the entire sahara or even the entire plant, but 300 million planets each the size of the entire earth. But what has NOT changed in the slightest is routing technology, We still have the same ceiling in routing that has managed to climb from a few tens of thousands of routing slots twenty years ago to a few millions of slots today. So the challenge here is one of self-imposed constraint in address distribution policies that strike rational balances between utility and versatility, between consumer and service provider, between global and local considerations. None of the ITU published material appears to address this underlying constraint, yet this precise constraint and this same effort of attempting to strike an appropriate balance has been at the heart of the address policy work I've seen in the RIR forums over the past decade and longer. I fail to see why a great leap backward into the morass of squabbling nation states, national monopolies, and the bizarre form of attempting to make rational technology decisions via voting across national delegations will work any better than the efforts of the ITU to push OSI two decades ago. If the Internet truly is a product of the progressive wave of deregulation in our industry and if it relied on the dismembering of such insular and inefficient national fiefdoms then I cannot see why we should give credence to such ill founded arguments to rebuild a now irrelevant and unneeded past. > >> Your attempt to criticize the report?s approach to the impact of >> TABLs on routing misses the mark. You commit a simple logical error, >> or perhaps didn?t actually read the proposal details, or maybe are >> simply misrepresenting what was said, it is hard to tell. You imply >> that address blocks would be auctioned when in fact, the report >> considers and rejects auctions as a method for initial allocation of >> ipv6 address blocks. See section 3.2. It proposes, instead, that RIRs >> use fees geared to size of address blocks to allocate resources. The >> TABL proposal specifies that blocks so allocated cannot be >> disaggregated and parcelled out to other ASs. By saying that the >> proposal "would not make the current system any worse or any better >> with respect to routing table growth" my point was that for routing >> purposes it matters not at all whether the initial allocation of ipv6 >> address blocks is based on ?need? as defined by RIRs or on the basis >> of fees, as suggested in the report ? what matters is the size of the >> blocks and the degree to which they are disaggregated. Can you >> dispute that? The ITU report proposes a market rationalist approach to address distributing by advocating blocks to countries and allowing countries to develop their own national address allocation frameworks? You are really calling this a "market based approach" Milton? You've made some rather strange claims in the past mate, and this one would have to rank right up there with them. Geoff Who is writing as myself as an individual here. From cengel at sponsordirect.com Tue Oct 13 14:11:29 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Tue, 13 Oct 2009 14:11:29 -0400 Subject: [arin-ppml] FW: [SPAM] - ARIN-PPML Digest, Vol 52, Issue 22 - Email has different SMTP TO: and MIME TO: fields in the email addresses Message-ID: Ted, I'll try to avoid the political overtones in your reply to Milton other then to point out the obvious.....those who always decry market-based solutions in favor of regulatory-agency based solutions overlook the obvious.... it is simply trading the potential for one type of favoritism (economic) for another (political connectedness). ANY time you empower a body to determine who may or may not have access to a resource you create the potential for abuse both overt and subvert. Furthermore that's only examining one axis of the issue, presumed fairness.... it doesn't even address considerations about the efficiency under which such a resource could be administered.... or questions of why people may choose that resource over other alternatives. One could easily argue that the problems in the US housing market originated with quasi-governmental agencies (Fannie May & Freddie Mac) whose mandate was specifically to ignore economic realities. Likewise TARP would not have been possible without the precedent that interference in the market lies within the normal bounds of governments legitimate prevue... certainly NOT a viewpoint forwarded by traditional conservatives. However, that's a digression. In market-based systems there is only a significant economic barrier to entry when the resource is significantly scarce. If it is not significantly scarce then the economic barrier is so low that it becomes inconsequential for normal usage. That system works as long there are rules in place to prevent some-one from creating a "false scarcity" by monopolizing the market. If we look at the Domain Name System we can see an example of such a system that works. At less then $10 a year at a cheap registrar, it is hardly a "playground for the wealthy" or any such thing. It's well within the budget of the average Joe out there. When you obtain a name, ICANN isn't concerned whether you truly NEED the name.... simply that you will USE it for a purpose other then simply manipulating the name market (i.e. creating a false scarcity)....and that there isn't some pre-existing legal claim on the name outside of the Domain Registry. Now if you want a specific name already in use....it's really upto you (and the existing holder) to determine whether having it is worth the cost of obtaining it...and only you are truly in a position to determine that. It would probably be impossible, just in terms of resources, for ICANN to determine the legitimate NEED for a name in any more then a VERY small minority of the claims and even then the system would be prone to flaws and abuse if ICANN was tasked with anything more then simply determining that the current holder was USING the name .... and there wasn't a prior standing legal claim to the name. " Once you replace need-based distribution into a market with fee-based distribution, what follows is lots of economic power that over time will erode all of the safeties installed in the initial market - such as your specification that blocks so allocated cannot be deaggregated. The moment that it would be economically advantageous to a wealthy org to break this rule, the rule would be broken and discarded. This is exactly what happened in the US housing market - originally the financial controls were installed to prevent the housing runup - these controls were chafed against by the wealthy, for many years, until eventually the wealthy managed to take over and remove them - and within 10 years, the market exploded and collapsed. That is the ultimate end to all market-based solutions like you conservatives advocate because you continually ignore the intrusion of political power into the market and it's corrupting influence. The battle cry of the conservatives is that "those" wealthy corrupting conservatives that destroy controls aren't "real" conservatives, the problem is in the people making poor choices, not in a flawed system. You fail to see that a flawed system rewards poor choices and penalizes good choices, thus it's ultimately going to influence even the best people to make flawed choices. (such as the TARP bailout) Ted" From tedm at ipinc.net Tue Oct 13 14:36:26 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 13 Oct 2009 11:36:26 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <931666D5-0D93-4166-B994-7646E083444C@apnic.net> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> <4AD49E5D.8030401@ipinc.net> <931666D5-0D93-4166-B994-7646E083444C@apnic.net> Message-ID: <4AD4C8AA.3030604@ipinc.net> Geoff Huston wrote: > > If we really want to submarine any hope whatsoever of a > transition to IPv6 this form of meddling in the address distribution > framework is about as good a negative intervention as one could possibly > imagine! A market-based ip allocation scheme encourages choices that are lower initial cost instead of choices that are higher initial cost - even though the higher initial cost choices may have a far, far greater long term payback. This is why you can take a century-old telephone and plug it in to the modern POTS telephone network. Advances in the subscriber handsets ground to a halt 100 years ago in the United States, because of lower-initial-cost short term decisions, first by Ma Bell, then after the Carterfone decision, by individual end-user subscribers. Going to a market-based IP allocation scheme is going to guarantee another century of IPv4. Perhaps that is why some people are advocating it? Ted From schnizlein at isoc.org Tue Oct 13 16:01:43 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Tue, 13 Oct 2009 16:01:43 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <4AD4C8AA.3030604@ipinc.net> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> <4AD49E5D.8030401@ipinc.net> <931666D5-0D93-4166-B994-7646E083444C@apnic.net> <4AD4C8AA.3030604@ipinc.net> Message-ID: <774ADE39-268E-474B-8D4C-04B79D569B88@isoc.org> The point that seems to me to be missing from the commentary in this thread is that the argument Milton and the ITU "experts" make about management of IPv6 addresses based on issues with IPv4 addresses is a classic non sequitur fallacy. Because of the huge increase in the size of IPv6 addresses, conservation of address allocation is not the issue it is with IPv4 addresses. Arguments about relative scarcity, allocation efficiency, recovery, and transfer that are contentious with IPv4 addresses simply do not apply when there are so many IPv6 addresses. The technical issue of conserving routing entries in the default-free zone is still relevant, but plays little or no part in the ITU arguments. My impression is that the ITU is "fighting the last war". John On 2009Oct13, at 2:36 PM, Ted Mittelstaedt wrote: > Geoff Huston wrote: > >> If we really want to submarine any hope whatsoever of a transition >> to IPv6 this form of meddling in the address distribution framework >> is about as good a negative intervention as one could possibly >> imagine! > > A market-based ip allocation scheme encourages > choices that are lower initial cost instead of choices that are > higher initial cost - even though the higher initial cost choices > may have a far, far greater long term payback. From randy at psg.com Tue Oct 13 16:22:31 2009 From: randy at psg.com (Randy Bush) Date: Tue, 13 Oct 2009 13:22:31 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <774ADE39-268E-474B-8D4C-04B79D569B88@isoc.org> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: > Arguments about relative scarcity, allocation efficiency, recovery, > and transfer that are contentious with IPv4 addresses simply do not > apply when there are so many IPv6 addresses. s/do no apply/will not apply for a few decades, if ipv6 is successful/ randy From mueller at syr.edu Tue Oct 13 21:22:08 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 13 Oct 2009 21:22:08 -0400 Subject: [arin-ppml] Geoff's screed In-Reply-To: <931666D5-0D93-4166-B994-7646E083444C@apnic.net> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> <4AD49E5D.8030401@ipinc.net> <931666D5-0D93-4166-B994-7646E083444C@apnic.net> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF60170@SUEX07-MBX-04.ad.syr.edu> Wow. Geoff, this outburst is incredible. I am truly sorry that someone whose scientific work I greatly respect, and which is cited and praised in the paper, has produced such a sloppy, illogical reaction. My take is, frankly, that you haven't read the report at all. Nothing else can explain your fulminations below. First, you confuse the TABL proposal with the CIR proposal. They are two separate reports, produced by separate teams, with different and often conflicting policy implications. Quite an astounding error, considering that I explained the difference in the email that prompted this exchange. So when you say, > The ITU report proposes a market [sic] rationalist approach to address > distributing [sic] by advocating blocks to countries and allowing > countries to develop their own national address allocation frameworks? > You are really calling this a "market based approach" Milton? No, I am not. That is what the CIR report proposed, not what I proposed. You are confusing two distinct reports and have probably not read either one. Second, if I am not mistaken, Geoff, you are and were one of the world's biggest supporters of ipv4 transfer markets, and are positioned as such in the upcoming Internet Governance Forum workshop, where you are teamed with me in a debate with Tom Vest and Bill Woodcock. It seems a bit schizophrenic for you to be issuing these blistering, condemnatory, and factless polemics alongside knee-jerk anti-market folks like Ted when the case for modest experimentation with Transferable AdBLs in v6 is not all that dissimilar to that of the arguments for transferability in v4. Third, you confuse this proposal with a 5-year old paper in which the idea of fostering competition in address allocation policies across different allocation authorities was proposed. That paper provoked one of the most amateurish attempts at economic analysis you have ever penned, Geoff: the joint paper with Wilson. In that paper you argued that whenever competing entities allocate the same resource there will be an uncontrollable spiral to fast depletion - an argument that conflicts with known facts about our experience with hundreds of natural and man made resources and with everything we know about how competing firms handle resources on which their existence depends. The argument of your paper was refuted easily and thoroughly, as it would fail as an Economics 101 term paper. Whatever, the paper we are discussing now makes a completely different argument, and the fact that a report by me irritated you 5 years ago really has no relevance to the assessment of the TABL proposal. Let me go through a few more items here in an attempt to clean up the mess. But the overall tone of this is astounding. When is this community going to be able to sustain a rational discussion of the basic institutional economics of IP addressing in a way that incorporates two decades of institutionalism from Ostrom (who just won the Nobel prize) and about 6 decades of transaction cost economics? You can demonize me, and you can demonize "markets" in this isolated echoe chamber but neither you nor society as a whole can escape the need for complete and full discussion of the policy alternatives around IPv6 allocations. Better get used to rational discourse and put aside the hyperventilating and accusations that so and so is out to "destroy the Internet." From mueller at syr.edu Tue Oct 13 22:00:09 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 13 Oct 2009 22:00:09 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: <774ADE39-268E-474B-8D4C-04B79D569B88@isoc.org> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> <4AD49E5D.8030401@ipinc.net> <931666D5-0D93-4166-B994-7646E083444C@apnic.net> <4AD4C8AA.3030604@ipinc.net> <774ADE39-268E-474B-8D4C-04B79D569B88@isoc.org> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF60171@SUEX07-MBX-04.ad.syr.edu> > The point that seems to me to be missing from the commentary in this > thread is that the argument Milton and the ITU "experts" make about > management of IPv6 addresses based on issues with IPv4 addresses is a > classic non sequitur fallacy. Because of the huge increase in the > size of IPv6 addresses, conservation of address allocation is not the > issue it is with IPv4 addresses. Arguments about relative scarcity, > allocation efficiency, recovery, and transfer that are contentious > with IPv4 addresses simply do not apply when there are so many IPv6 > addresses. Ah, so you haven't read the reports either, have you John? You might want to look at Section 2.1.2, where various arguments that we don't have to worry about reclamation and scarcity are carefully reviewed and discussed. My assessment that we DO need to pay attention to such concerns in ipv6 was influenced by some persuasive arguments and calculations made by, um, Geoff Huston (or some variant thereof) as well as Thomas Narten. Indeed, I showed that their calculations completely ignored the need for reclamation, and when you don't ignore the problem of reclamation the projected consumption can rise by a factor of four. I will agree with you that underlying many ITU attitudes, and especially the idea of block reservations for nation-states and allocation by CIRs, is an retrograde, IPv4-era fear of being left behind. I of course do NOT favor CIRs as the model and explored flexible markets as the alternative. However, the concern about a replay of IPv4-era scarcity received reinforcement from some guy named, um, Geoff Huston (or some variant thereof) in a 2005 report which said of existing v6 allocation policies: "we stand the risk of, yet again, visibly creating an early adopter reward and a corresponding late adopter set of barriers and penalties." >The technical issue of conserving routing entries in the default-free >zone is still relevant, but plays little or no part in the ITU arguments So once again, you make statements without having actually read the "ITU arguments". Of course route entry conservation is relevant, extremely relevant. And it is discussed in both reports. If you had read mine, you would know that one idea it explored was that of "aggregation fees", i.e. increasing the fees for address blocks based on the number of routing entries announced within them. This was and remains an interesting idea, because earlier ideas about charging for route announcements assumed that ISPs would have to bilaterally negotiate such charges, which was a non-started in terms of practical implementation. My idea was that RIR fees could provide a lower transaction cost method of doing this. My first draft actually recommended doing this. But we decided not to recommend it for a couple of reasons. One of them was that I consulted with Geoff Huston (or some variant thereof) who referred me to his studies that Moore's Law would easily allow routing tech to keep pace with routing table growth and who said that such a tax was a "solution in search of a problem." There were other reasons not to recommend routing table bloat fees, but if indeed such bloat is a major problem an aggregation fee-based solution remains an idea worth looking at. Lots of interesting definition, monitoring and enforcement issues would have to be resolved, of course; for now the issue is whether this community can have intelligent dialogue about policy options or starts screaming and demonizing people and institutions when challenging new ideas are floated. --MM From mueller at syr.edu Tue Oct 13 22:34:04 2009 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 13 Oct 2009 22:34:04 -0400 Subject: [arin-ppml] Aggregation fees Message-ID: <75822E125BCB994F8446858C4B19F0D78FF60175@SUEX07-MBX-04.ad.syr.edu> May as well provide the text of the report segment here. Interested in your comments Appendix 2 Aggregation fees We considered, but ultimately do not recommend, modifying the proposed system of address block fees to encourage route aggregation. Earlier discussions of the routing tragedy of the commons explored the notion of charging for route announcements. (Rekhter, Resnick and Bellovin, 1996) These explorations led many to conclude that it was impossible to do so, because it was assumed that ISPs would have to directly negotiate and compensate each other for route announcements on a bilateral basis. It is, however, possible to reward route aggregation (or conversely, to penalize de-aggregation) by linking the address block fees to aggregation efficiency. The fee for initial allocations would be based strictly on the size of the block, and the periodic recurring fee would be based on both the size of the block and on the address block holder's aggregation efficiency. Recipients of address allocations could pay recurring charges on an annual or quarterly basis. Recurring charges would be based on the size of the block with an added charge for the number of routes an organization announces per allocated block. E.g., if only 1 route is announced into the exterior routing domain for the allocated block, perhaps the recurring charge is 0; then it increases until it reaches its highest level when the routes announced are completely disaggregated to the /64 level. Such a fee would have to vary depending on the size of the block, increasing for smaller blocks and decreasing for larger ones. (This aspect requires further exploration.) Such a fee structure might combine and integrate the incentive to conserve with the incentive to aggregate routes. The purpose of such a fee structure would be to internalize the externality associated with routing table growth. Such an approach "taxes" deaggregation. Calibrating recurring fees to reward aggregation efficiency might make it possible to have a more liberal trading regime that would allow holders of TABLs to sell portions of their blocks, because it would ensure that trading of deaggregated blocks would occur mainly when it increased routing efficiency (or at worse, left it the same). Address block trades that led to deaggregation would increase the trading parties' recurring costs. The costs of deaggregation would overpower initial allocation costs unless extreme scarcity developed in the ipv6 space, which seems highly unlikely for the next 50-60 years at least. We do not recommend an aggregation fee, for two reasons. First, it is unclear whether the problem of routing table bloat is serious enough to justify it. Currently, ISPs can filter prefixes that exceed a certain length if they are concerned about that problem, and as noted earlier the projected growth of the routing table may fall within the technological capacity of improvements in router capacity. Second, the number of routing announcements often reflects traffic engineering concerns. That is, organizations and ISPs use route announcements to steer traffic over specific link facilities. Traffic engineering can be as important to the efficiency of the Internet as route aggregation. Unless a serious crisis of routing table scalability emerges, it is probably better to avoid any route aggregation fees and allow ISPs to make these tradeoffs on their own. From mysidia at gmail.com Tue Oct 13 23:27:37 2009 From: mysidia at gmail.com (James Hess) Date: Tue, 13 Oct 2009 22:27:37 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <4AD37A9D.9090708@ipinc.net> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> <4AD37A9D.9090708@ipinc.net> Message-ID: <6eb799ab0910132027t66a02b81i5997d1b99c4c1e5d@mail.gmail.com> On Mon, Oct 12, 2009 at 1:51 PM, Ted Mittelstaedt wrote: >> allocation principle as soon as scarcity arises. > I disagree. ?It's not a COMPLETE breakdown. ?However, you are > correct in that it -IS- a breakdown. Policy can make stipulations and exceptions as needed. Maybe "needs-based" has been qualified by something else implicitly for a long time? Like, uh "justified"? So what would/should ARIN tell a startup ISP/IX that went out today and (to save some cash) bought a bunch of ancient IPV4 routing gear that was so old it cannot implement CIDR or variable-length subnetting? And their customers have some network application that only works correctly when a /24 is available to them. So the ISP will want oversized classful blocks of ARIN, contrary to policy that VLSM should be used. They have a technical need for a /16, because they need it to allocate their 200 customers (each a class C, for an average 20 or so hosts per network, probably dialup customers, but a custom app designed for them requires a /24) -- and due to said lack of VLSM, this passes for "efficient" utilization.. (that is, as efficiently as it's technically feasible, given the strange designs they have chosen of their own free will). At some point, there should be a way to draw a line between *true* need and avoidable need. It's sensible that the answer to glaring waste should sometimes be "No, the address space requested is too large, given the use of the network." (as measured in increased number human participants, web servers, etc..). Or "this particular utilization, is deemed an excessively wasteful technology, as a matter of policy"; e.g. the technology itself is considered to create a usage of addressing, that we arbitrarily deem to be unjustified (regardless of the technical justifications). "Avoidable need" being a case where an org can obviously satisfy the same IP addressing function, just as effectively, and without impairment of functionality, using either IPv6 address space, or by using a much smaller amount of V4 address space, such as e.g. by implementing VLSM, or replacing the custom application, even if they only have to buy additional equipment or make design changes (including design change to existing network, and changes that require they have their custom application rewritten to remove the /24 assumption). -- -J From tvest at pch.net Wed Oct 14 02:09:52 2009 From: tvest at pch.net (Tom Vest) Date: Wed, 14 Oct 2009 08:09:52 +0200 Subject: [arin-ppml] Geoff's screed In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF60170@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu>, <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> <4AD49E5D.8030401@ipinc.net> <931666D5-0D93-4166-B994-7646E083444C@apnic.net> <75822E125BCB994F8446858C4B19F0D78FF60170@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4867337B-1BF8-4C44-895C-06F020367CB5@pch.net> On Oct 14, 2009, at 3:22 AM, Milton L Mueller wrote: > When is this community going to be able to sustain a rational > discussion of the basic institutional economics of IP addressing in > a way that incorporates two decades of institutionalism from Ostrom > (who just won the Nobel prize) and about 6 decades of transaction > cost economics? Gee, that sounds like an excellent idea... "In the complex and overlapping trading regimes discussed earlier, the rules address a wide range of rights and responsibilities relating to all relevant aspects of the affected ecological systems. Where hales assign certain people or groups rights without responsibilities,or responsibilities without rights, their willingness to negotiate modifications in the hales is likely to be limited. Elinor Ostrom has cautioned against the use of privatization of rights without careful consideration of the responsibility for managing those parts of the system that cannot be privatized. In groundwater resource management, for example, the flow of water can be privatized, but the basin itself must be managed jointly." Fred Bosselman, "Swamp swaps: the 'second nature' of wetlands," in Environmental Law (Vol. 39 No. 3: June 2009) "Elinor Ostrom and her colleagues, reviewing studies of thousands of common-pool resource problems, found that the groups most likely to find robust, sustainable cooperative solutions share characteristics like mutual monitoring, frequent communication, and graduated sanctions for violators. Studies in laboratory settings lend further support to Ellickson's hypothesis, with subjects cooperating more often when they know interactions will be repeated and when they can communicate face-to-face." Jed S. Ela, "Law and norms in collective action: maximizing social influence to minimize carbon emissions," in UCLA Journal of Environmental Law & Policy (Vol. 27 No. 1: June 2009). Elinor Ostrom found that when people work collectively, they can effectively manage resources well. Her empirical research illustrates how communication between players increases cooperation, leading to higher instances of sell-governance and cooperation. CPR (common pool resources) demonstrates that users who depend on a resource for their livelihood and who have some autonomy to make their own rules are more likely to perceive benefits from restrictions; but without a sense of how their use will affect others within their community, the expectation of benefits is reduced. Users are also interested in the sustainability of the resource so the expected joint benefits will seem to outweigh current costs. In every situation and over time, individual benefits must be viewed as less valuable than the benefits to the community of users; collective-choice rules establish and operate the governance process. Danielle M. Varda and Peter deLeon, "Toward a Theory of Collaborative Policy Networks: Identifying Structural Tendencies," in Policy Studies Journal (Vol. 37 No. 1: February 2009). Your goal of fully privatizing and anonymizing IP number resources would be diametrically at odds with the broad findings of Ostrom, et al. Time permitting, I'll try to pin up some Williamson quotes later today. Not that I think that it'll convince you of anything -- in fact I'm not even sure why you made such a reference. "As libertarians, the verdict of the free market is more important to us the verdict of any expert," right Milton? [1] The free market has spoken, and continues to speak in this matter; you just don't seem to understand the language it's uses in cases where the issues cannot be simply and cleanly boiled down to dollars and cents. TV [1] Milton Mueller, "Nuclear Power: Beyond 'For' or 'Against'," Illinois Libertarian (January 1978), reprinted in The Libertarian Forum (Vol. XII, No. 4: July-August 1979). Happy to share a copy with anyone who cannot find it online. From michael.dillon at bt.com Wed Oct 14 03:51:21 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 14 Oct 2009 08:51:21 +0100 Subject: [arin-ppml] Fairness of banning IPv4 allocations tosomecategoryof organization In-Reply-To: <6eb799ab0910132027t66a02b81i5997d1b99c4c1e5d@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C497458038DE83C@E03MVZ2-UKDY.domain1.systemhost.net> > So what would/should ARIN tell a startup ISP/IX that went out > today and (to save some cash) bought a bunch of ancient IPV4 > routing gear that was so old it cannot implement CIDR or > variable-length subnetting? > And their customers have some network application that only > works correctly when a /24 is available to them. First, you meant to say a class C address block, not /24. Older gear cannot handle /24s because that is a variable length subnet masking block. A class C block from between 192/8 and 223/8 would provide a /24 sized block on older gear. And ARIN should politely tell them to get stuffed because policy doesn't currently allow for allocating blocks out of specific address ranges. At the most, ARIN might give out one such allocation, but when they come back for more they will fail the utilization test. > They have a technical need for a /16, because they need it > to allocate their 200 customers (each a class C, for an > average 20 or so hosts per network, probably dialup > customers, but a custom app designed for them > requires a /24) -- and due to said lack of VLSM, this passes for > "efficient" utilization.. (that is, as efficiently as it's > technically feasible, given the strange designs they have > chosen of their own free will). If this ISP had non-VLSM gear, then a /16 would not work and a class B address block would also not work. They would require 200 or so class C blocks. You cannot subnet a class B address block into smaller blocks. That's one benefit of VLSM where any /16 can easily be subnetted into /24 blocks or any size you wish. > At some point, there should be a way to draw a line between > *true* need and avoidable need. Yes. > Or "this particular utilization, is deemed an excessively wasteful > technology, as a matter of policy"; e.g. the technology itself is > considered to create a usage of addressing, that we arbitrarily deem > to be unjustified (regardless of the technical justifications). Might be time for an IPv6 transition policy which restricts address allocations for reasons like the one which you state. It would just be a moratorium during the IPv6 transition phase. After IPv6 usage is widespread, then IPv4 can be opened up again, and if some museum network wants to set up a bunch of old non-VLSM routers using class B and class C address blocks, let them have their addresses. Just not now. --Michael Dillon From randy at psg.com Wed Oct 14 07:53:31 2009 From: randy at psg.com (Randy Bush) Date: Wed, 14 Oct 2009 07:53:31 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: > You're not a very nice man are you? you spam everybody on list and you call me names? cute. From bmanning at vacation.karoshi.com Wed Oct 14 08:13:31 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 14 Oct 2009 12:13:31 +0000 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <20091014121331.GA5249@vacation.karoshi.com.> On Wed, Oct 14, 2009 at 07:53:31AM -0400, Randy Bush wrote: > > You're not a very nice man are you? > > you spam everybody on list and you call me names? cute. > _______________________________________________ "not a nice..." is a character observation - not a name. the hard part is trying to figure out the difference btwn a title and a name... e.g. "Yes Highness". "Highness" might be a title or a name - hard to tell. in any case, it is pretty well known that some old timers (a classification) are in the position to not suffer fools gladly (yet another classification) ... and it takes a certain willingness to learn to get over ones own ego. what was the subject again? fairness? "three wolves and a sheep deciding whats for dinner"? Cheri - its not a clean slate. --bill From baptista at publicroot.org Wed Oct 14 11:05:44 2009 From: baptista at publicroot.org (Joe Baptista) Date: Wed, 14 Oct 2009 11:05:44 -0400 Subject: [arin-ppml] Geoff's screed In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF60170@SUEX07-MBX-04.ad.syr.edu> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> <4AD49E5D.8030401@ipinc.net> <931666D5-0D93-4166-B994-7646E083444C@apnic.net> <75822E125BCB994F8446858C4B19F0D78FF60170@SUEX07-MBX-04.ad.syr.edu> Message-ID: <874c02a20910140805ub5fdc29wf8a29599c9b7d8e@mail.gmail.com> Is it at all possible Milton that you can respond to something without initiating a personal attack against someone. It's a bit slimy for an academic respond in this fashion. cheers joe baptista On Tue, Oct 13, 2009 at 9:22 PM, Milton L Mueller wrote: > Wow. > > Geoff, this outburst is incredible. I am truly sorry that someone whose > scientific work I greatly respect, and which is cited and praised in the > paper, has produced such a sloppy, illogical reaction. My take is, frankly, > that you haven't read the report at all. Nothing else can explain your > fulminations below. > > First, you confuse the TABL proposal with the CIR proposal. They are two > separate reports, produced by separate teams, with different and often > conflicting policy implications. > > Quite an astounding error, considering that I explained the difference in > the email that prompted this exchange. So when you say, > > > The ITU report proposes a market [sic] rationalist approach to address > > distributing [sic] by advocating blocks to countries and allowing > > countries to develop their own national address allocation frameworks? > > You are really calling this a "market based approach" Milton? > > No, I am not. That is what the CIR report proposed, not what I proposed. > You are confusing two distinct reports and have probably not read either > one. > > Second, if I am not mistaken, Geoff, you are and were one of the world's > biggest supporters of ipv4 transfer markets, and are positioned as such in > the upcoming Internet Governance Forum workshop, where you are teamed with > me in a debate with Tom Vest and Bill Woodcock. It seems a bit > schizophrenic for you to be issuing these blistering, condemnatory, and > factless polemics alongside knee-jerk anti-market folks like Ted when the > case for modest experimentation with Transferable AdBLs in v6 is not all > that dissimilar to that of the arguments for transferability in v4. > > Third, you confuse this proposal with a 5-year old paper in which the idea > of fostering competition in address allocation policies across different > allocation authorities was proposed. That paper provoked one of the most > amateurish attempts at economic analysis you have ever penned, Geoff: the > joint paper with Wilson. In that paper you argued that whenever competing > entities allocate the same resource there will be an uncontrollable spiral > to fast depletion - an argument that conflicts with known facts about our > experience with hundreds of natural and man made resources and with > everything we know about how competing firms handle resources on which their > existence depends. The argument of your paper was refuted easily and > thoroughly, as it would fail as an Economics 101 term paper. Whatever, the > paper we are discussing now makes a completely different argument, and the > fact that a report by me irritated you 5 years ago really has no relevance > to the assessment of the TABL pr > oposal. > > Let me go through a few more items here in an attempt to clean up the mess. > But the overall tone of this is astounding. > > When is this community going to be able to sustain a rational discussion of > the basic institutional economics of IP addressing in a way that > incorporates two decades of institutionalism from Ostrom (who just won the > Nobel prize) and about 6 decades of transaction cost economics? > > You can demonize me, and you can demonize "markets" in this isolated echoe > chamber but neither you nor society as a whole can escape the need for > complete and full discussion of the policy alternatives around IPv6 > allocations. Better get used to rational discourse and put aside the > hyperventilating and accusations that so and so is out to "destroy the > Internet." > > _______________________________________________ > 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. > -- Joe Baptista www.publicroot.org PublicRoot Consortium ---------------------------------------------------------------- The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. ---------------------------------------------------------------- Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: www.joebaptista.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Oct 14 11:12:56 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 14 Oct 2009 10:12:56 -0500 Subject: [arin-ppml] Civility In-Reply-To: <874c02a20910140805ub5fdc29wf8a29599c9b7d8e@mail.gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu> <4AD49E5D.8030401@ipinc.net> <931666D5-0D93-4166-B994-7646E083444C@apnic.net> <75822E125BCB994F8446858C4B19F0D78FF60170@SUEX07-MBX-04.ad.syr.edu> <874c02a20910140805ub5fdc29wf8a29599c9b7d8e@mail.gmail.com> Message-ID: <4AD5EA78.4080209@gmail.com> Excellent advice for all of us. Let's please keep discussions here civil. If you write something that might trigger a response from the recipient, it might be useful to hold off on sending it, then come back and re-read it with an eye toward how someone reading it is likely to react. If there is anything that could conceivably be perceived as a personal attack, assume it will be, and see if it can be re-worded to be more objective and impersonal... My $.02, Scott Joe Baptista wrote: > Is it at all possible ... that you can respond to something without > initiating a personal attack against someone. From tvest at eyeconomics.com Wed Oct 14 12:01:55 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Wed, 14 Oct 2009 18:01:55 +0200 Subject: [arin-ppml] off-topic/tvest de-duping of ppml subscription addresses Message-ID: Sometime ago I subscribed to ppml as tvest at eyeconomics.com, in order to make plain the fact that any views that I express here are my own, and do not represent the opinions of anyone else, including any past or present employers, colleagues, friends, etc. At some point in the last few days I may have accidentally posted something to the list using an email address other than tvest at eyeconomics.com . This was an error on my part, which will not happen again (I am now subscribed *only* as tvest at eyeconomics.com). If anyone wishes to contact me offlist about anything, please use tvest at eyeconomics.com . Apologies for any confusion... thanks. TV From kkargel at polartel.com Wed Oct 14 12:10:17 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 14 Oct 2009 11:10:17 -0500 Subject: [arin-ppml] Geoff's screed In-Reply-To: <874c02a20910140805ub5fdc29wf8a29599c9b7d8e@mail.gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com><28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net><75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu><75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu><4AD49E5D.8030401@ipinc.net><931666D5-0D93-4166-B994-7646E083444C@apnic.net><75822E125BCB994F8446858C4B19F0D78FF60170@SUEX07-MBX-04.ad.syr.edu> <874c02a20910140805ub5fdc29wf8a29599c9b7d8e@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3C5@mail> Joe, I was actually rather glad to see his response. An attack of that type lets me know that the speaker is trying to defend a specious argument and is falling back on intimidation and character attacks to support a bad premise. When people break out in personal or character attacks I know I can discount or ignore their argument. It saves me a lot of work as I don't actually have to look at what they are saying. JMHO ____________________________________________________________________________ Is it at all possible Milton that you can respond to something without initiating a personal attack against someone. It's a bit slimy for an academic respond in this fashion. cheers joe baptista On Tue, Oct 13, 2009 at 9:22 PM, Milton L Mueller wrote: Wow. Geoff, this outburst is incredible. I am truly sorry that someone whose scientific work I greatly respect, and which is cited and praised in the paper, has produced such a sloppy, illogical reaction. My take is, frankly, that you haven't read the report at all. Nothing else can explain your fulminations below. [Gross snippage from this point on] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From cengel at sponsordirect.com Wed Oct 14 12:53:23 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 14 Oct 2009 12:53:23 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof In-Reply-To: Message-ID: Human history is replete with examples of market-based systems (with greater or lessor controls) that have operated with remarkable effectiveness, stability and even "fairness" ( I use that term in quotes because it is an entirely subjective measure. Different people will have entirely different perspectives of what is "fair". In fact, I would hazard that recognition of this is one of the major advantages of market-based systems). It is also replete with examples of need-based systems that have gone horribly awry. The reverse is true as well. There are many examples of market-based systems running amuck... and of need-based systems which served thier purpose admirably. Rather then get wraped up in an ideoligical debate about such systems which is likely unresolvable, can we admit that under the right circumstances and with the proper implimentation in place EITHER some form of market-based or needs-based system COULD be made to function effectively for the allocation of IP Address Space? If that is the case, then perhaps the discussion could be moved to focus on specific advantages and disadvantages of specific implimentations of such systems for the intended purpose? Christopher Engel From shuque at isc.upenn.edu Wed Oct 14 13:03:48 2009 From: shuque at isc.upenn.edu (Shumon Huque) Date: Wed, 14 Oct 2009 13:03:48 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: <3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910110713s3e04b201re02d3dc8441ae037@mail.gmail.com> <3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> Message-ID: <20091014170348.GA19875@isc.upenn.edu> On Sun, Oct 11, 2009 at 12:31:52PM -0400, William Herrin wrote: > > Https, for example, does not function properly without a different IP > address for each hostname because the SSL certificate for the server > name must be offered to the browser before the HTTP 1.1 server name is > transmitted by the browser. It's possible to support this, with more modern SSL/TLS implementations. See the TLS "Server Name Indication" extension (RFC 4366, Section 3.1), which a client can use to pass the server name during the TLS handshake. Most modern browsers today already support this. Apache either already supports it, or (last time I checked) had patches floating around. Even without SNI, you can make this work with a single certificate with multiple subjectAltName dnsname fields populated with the various server names. --Shumon. From tedm at ipinc.net Wed Oct 14 14:28:15 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 14 Oct 2009 11:28:15 -0700 Subject: [arin-ppml] Geoff's screed In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3C5@mail> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com><28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net><75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu><75822E125BCB994F8446858C4B19F0D78FFC9ECC@SUEX07-MBX-04.ad.syr.edu><4AD49E5D.8030401@ipinc.net><931666D5-0D93-4166-B994-7646E083444C@apnic.net><75822E125BCB994F8446858C4B19F0D78FF60170@SUEX07-MBX-04.ad.syr.edu> <874c02a20910140805ub5fdc29wf8a29599c9b7d8e@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3C5@mail> Message-ID: <4AD6183F.2090300@ipinc.net> Kevin Kargel wrote: > Joe, > > I was actually rather glad to see his response. An attack of that type lets > me know that the speaker is trying to defend a specious argument and is > falling back on intimidation and character attacks to support a bad premise. > > When people break out in personal or character attacks I know I can discount > or ignore their argument. It saves me a lot of work as I don't actually > have to look at what they are saying. > That's why I always put my character attacks at the end of my posts, meatbag. :-) Ted PS You won't get it if your not a Futurama fan From christopher.morrow at gmail.com Wed Oct 14 22:56:48 2009 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 14 Oct 2009 22:56:48 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some categoryof organization In-Reply-To: <200910091404.n99E48mj021615@inana.itg.state.mn.us> References: <28E139F46D45AF49A31950F88C49745803745E05@E03MVZ2-UKDY.domain1.systemhost.net> <061F384443684B4391AE7128687BB083@GIH.CO.UK> <4ACD450B.2030708@ipinc.net> <86ocoh8qwu.fsf@seastrom.com> <200910091404.n99E48mj021615@inana.itg.state.mn.us> Message-ID: <75cb24520910141956gb4eeda0l39988cdaef844e9b@mail.gmail.com> On Fri, Oct 9, 2009 at 10:04 AM, Craig Finseth wrote: > ? ? ? ?... > ? I don't think anyone is quite insane enough to suggest putting power > ? meters on the public Internet. ?Yes, a smart grid will require > ? ? ? ?... > > You'd be surprised, then. ?I've seen plans that effectively wind up > doing just that. google's powermeter thing actually... I think the salient point in Seastrom's note though is that if you put together a 'private' network today, you will either plan for interconnection to business partners now (use globally unique address space) or suffer some horrendous renumbering pain (or double nat hell) later on. Larger power folks may not see this now, but ... as Rob said, just wait until someone points out the SCADA network security implications of what they did. -chris From mueller at syr.edu Thu Oct 15 08:43:22 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 15 Oct 2009 08:43:22 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof In-Reply-To: References: Message-ID: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > Rather then get wraped up in an ideoligical debate about such systems > which is likely unresolvable, can we admit that under the right > circumstances and with the proper implimentation in place EITHER some form > of market-based or needs-based system COULD be made to function > effectively for the allocation of IP Address Space? > > If that is the case, then perhaps the discussion could be moved to focus > on specific advantages and disadvantages of specific implimentations of > such systems for the intended purpose? Thanks for your intervention, Chris. That's exactly where I've been trying to move. In that regard I find it interesting that despite the constant worrying about route aggregation, the proposal I made to use RIR fees to encourage aggregation (or "tax" deaggregation) has not attracted a single comment. People seem more interested in the broad ideological classifications than in assessing specific proposals. From scottleibrand at gmail.com Thu Oct 15 12:20:39 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 15 Oct 2009 09:20:39 -0700 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4AD74BD7.8070504@gmail.com> Milton L Mueller wrote: > > Thanks for your intervention, Chris. That's exactly where I've been trying to move. In that regard I find it interesting that despite the constant worrying about route aggregation, the proposal I made to use RIR fees to encourage aggregation (or "tax" deaggregation) has not attracted a single comment. People seem more interested in the broad ideological classifications than in assessing specific proposals. Perhaps people were ignoring the "fairness" thread? :-) Or perhaps, like me, most people generally agree with that particular point, so there's maybe not as much to discuss. My own thought is that using fees to encourage aggregation (discourage deaggregation) would probably work, but that there isn't a lot of need for doing so just yet. If we get to the point where multiple networks are having problems with routing table growth that can't be solved through filtering of distant more-specifics, through charging customers for route announcements, and/or through peering agreements, then perhaps someone will resurrect the idea on arin-discuss for the board's consideration. -Scott From tvest at eyeconomics.com Thu Oct 15 12:29:32 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 15 Oct 2009 18:29:32 +0200 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> Message-ID: <9DDFA14E-E051-4114-AF90-452A2440B105@eyeconomics.com> On Oct 15, 2009, at 2:43 PM, Milton L Mueller wrote: >> -----Original Message----- >> Rather then get wraped up in an ideoligical debate about such systems >> which is likely unresolvable, can we admit that under the right >> circumstances and with the proper implimentation in place EITHER >> some form >> of market-based or needs-based system COULD be made to function >> effectively for the allocation of IP Address Space? >> >> If that is the case, then perhaps the discussion could be moved to >> focus >> on specific advantages and disadvantages of specific >> implimentations of >> such systems for the intended purpose? > > Thanks for your intervention, Chris. That's exactly where I've been > trying to move. In that regard I find it interesting that despite > the constant worrying about route aggregation, the proposal I made > to use RIR fees to encourage aggregation (or "tax" deaggregation) > has not attracted a single comment. People seem more interested in > the broad ideological classifications than in assessing specific > proposals. What part would you like people to comment on -- your premises, the idea itself, or your recommendation that it not be adopted at this point? 1. The very notion of justifying a much more restrictive routing policy (even in part) in order to make it easier to have a more liberal address trading regime -- for IPv6 no less -- is both deeply misguided and absolutely self-defeating. 2. The policy idea itself is fatally ambiguous. Are you suggesting that network operators embrace this plan voluntarily, or be subjected to it by some external authority? The membership of this mailing list includes the vast majority of ARIN address-holding network operators, who typically have no problem at all speaking up when they like a policy proposal -- so if it's the former, then the silence is your answer. Don't let it make you feel special however -- silence is the same response accorded to all policy ideas that meet with zero enthusiasm. And if imposition by fiat is the plan, then this is the wrong forum for promoting it. 3. Who sets the fees? Who collects the fees? How would they be distributed? Who counts the level of de-aggregation, where, using what methodology? If the routing service providers themselves, how would they arrive at a mutually agreeable price/distribution? Why would this be any easier now than in the past, c. 1993, 1995? If anyone else, why should routing service providers abide that imposition when it's their infrastructure that's being encumbered? Even if all of the above questions can be answered, what would prevent the routing fees from becoming an increasingly artificial and arbitrary drag on the Internet's growth potential, just as fixed international telecom settlement rates ultimately came to be a deadweight impeding the extension of more affordable communications services to more potential telecom services users? 4. If the adoption of any of the above would involve or require decisions made by any less that 100% unanimous acclaim by all network service providers (at all times into the indefinite future), what would distinguish this idea from any of the competing sustainability proposals that you have consistently criticized (e.g., capital infrastructure-related eligibility criteria, a.k.a. "needs-based" allocation requirements)? 5. The closing point "not recommending" the adoption of the idea is excellent, but it should stand alone, without any further qualifications. TV From bill at herrin.us Thu Oct 15 12:58:46 2009 From: bill at herrin.us (William Herrin) Date: Thu, 15 Oct 2009 12:58:46 -0400 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <4AD74BD7.8070504@gmail.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> Message-ID: <3c3e3fca0910150958j2384c1e0x3a7abdaaebc3148c@mail.gmail.com> On Thu, Oct 15, 2009 at 12:20 PM, Scott Leibrand wrote: > Milton L Mueller wrote: >> >> Thanks for your intervention, Chris. That's exactly where I've been trying >> to move. In that regard I find it interesting that despite the constant >> worrying about route aggregation, the proposal I made to use RIR fees to >> encourage aggregation (or "tax" deaggregation) has not attracted a single >> comment. People seem more interested in the broad ideological >> classifications than in assessing specific proposals. > > Perhaps people were ignoring the "fairness" thread? ?:-) ?Or perhaps, like > me, most people generally agree with that particular point, so there's maybe > not as much to discuss. ?My own thought is that using fees to encourage > aggregation (discourage deaggregation) would probably work, but that there > isn't a lot of need for doing so just yet. Scott, Before we start talking about fees to encourage aggregation, I think we should talk about policy structure which assists route filtering. Given adequate tools to filter TE disaggregation, it's likely that the ISPs can address the problem on their own without resorting to communal public policy. That ship has sailed for IPv4. CIDR combined with imperfect record keeping and the concept of LIRs assigning addresses to multihomed entities killed the possibility of disaggregate filtering in IPv4. It isn't possible to compute with certainty whether or not that /24 is a unique multihomed entity, not algorithmically based on address class and not database-driven with a copy of the allocation records. For IPv4 we are, fortunately, already capable of building big enough routers to handle the likely maximum disaggregation which should be in the neighborhood of 6 or 7 million routes. There's still time to structure IPv6 policy to support disaggregate filtering, but if we want to to do it without having legacy IPv6 swamp as large and messy as the legacy IPv4 swamp, our window of opportunity is closing. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alex.ryu at kdlinc.com Thu Oct 15 13:11:37 2009 From: alex.ryu at kdlinc.com (Alex Ryu) Date: Thu, 15 Oct 2009 12:11:37 -0500 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <3c3e3fca0910150958j2384c1e0x3a7abdaaebc3148c@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <3c3e3fca0910150958j2384c1e0x3a7abdaaebc3148c@mail.gmail.com> Message-ID: <278B5E4BCD5E654385A9F83C7CA6D517CB2189E593@MAILBOX-01.qcommcorp.ad> One of ARIN's priciple was that ARIN is not responsible for routability of IP address allocated. If we proceed this idea, this means that ARIN will be involved in operational area of Internet, and I think there are a lot of challenges for operational issues. I think this aggregation should be dealt from operational group such as NANOG meeting discussion to come up with best common practice, and enforce it from upstream ISP policy, not from ARIN's. Alex -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, October 15, 2009 11:59 AM To: Scott Leibrand Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Using fees to encourage route aggregation On Thu, Oct 15, 2009 at 12:20 PM, Scott Leibrand wrote: > Milton L Mueller wrote: >> >> Thanks for your intervention, Chris. That's exactly where I've been trying >> to move. In that regard I find it interesting that despite the constant >> worrying about route aggregation, the proposal I made to use RIR fees to >> encourage aggregation (or "tax" deaggregation) has not attracted a single >> comment. People seem more interested in the broad ideological >> classifications than in assessing specific proposals. > > Perhaps people were ignoring the "fairness" thread? ?:-) ?Or perhaps, like > me, most people generally agree with that particular point, so there's maybe > not as much to discuss. ?My own thought is that using fees to encourage > aggregation (discourage deaggregation) would probably work, but that there > isn't a lot of need for doing so just yet. Scott, Before we start talking about fees to encourage aggregation, I think we should talk about policy structure which assists route filtering. Given adequate tools to filter TE disaggregation, it's likely that the ISPs can address the problem on their own without resorting to communal public policy. That ship has sailed for IPv4. CIDR combined with imperfect record keeping and the concept of LIRs assigning addresses to multihomed entities killed the possibility of disaggregate filtering in IPv4. It isn't possible to compute with certainty whether or not that /24 is a unique multihomed entity, not algorithmically based on address class and not database-driven with a copy of the allocation records. For IPv4 we are, fortunately, already capable of building big enough routers to handle the likely maximum disaggregation which should be in the neighborhood of 6 or 7 million routes. There's still time to structure IPv6 policy to support disaggregate filtering, but if we want to to do it without having legacy IPv6 swamp as large and messy as the legacy IPv4 swamp, our window of opportunity is closing. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ 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 bill at herrin.us Thu Oct 15 14:06:52 2009 From: bill at herrin.us (William Herrin) Date: Thu, 15 Oct 2009 14:06:52 -0400 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <278B5E4BCD5E654385A9F83C7CA6D517CB2189E593@MAILBOX-01.qcommcorp.ad> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <3c3e3fca0910150958j2384c1e0x3a7abdaaebc3148c@mail.gmail.com> <278B5E4BCD5E654385A9F83C7CA6D517CB2189E593@MAILBOX-01.qcommcorp.ad> Message-ID: <3c3e3fca0910151106w7d60f974y71c68d358838cc99@mail.gmail.com> On Thu, Oct 15, 2009 at 1:11 PM, Alex Ryu wrote: > One of ARIN's priciple was that ARIN is not responsible for > routability of IP address allocated. Alex, One of ARIN's legal limitations of liability is that it doesn't guarantee routability of any addresses it allocates. That's not at all the same thing. IIRC, Tony Li of IRTF RRG once observed: "Routing is addressing is routing." If it wasn't Tony I apologize, but whoever authored that statement captured the long and short of it. What's *possible* in the routing system follows from how the addresses are allocated and how the addresses are allocated follows from what's needed in the routing system. ARIN's liability for what 3rd parties do with the addresses notwithstanding. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alex.ryu at kdlinc.com Thu Oct 15 14:13:02 2009 From: alex.ryu at kdlinc.com (Alex Ryu) Date: Thu, 15 Oct 2009 13:13:02 -0500 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <3c3e3fca0910151106w7d60f974y71c68d358838cc99@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <3c3e3fca0910150958j2384c1e0x3a7abdaaebc3148c@mail.gmail.com> <278B5E4BCD5E654385A9F83C7CA6D517CB2189E593@MAILBOX-01.qcommcorp.ad> <3c3e3fca0910151106w7d60f974y71c68d358838cc99@mail.gmail.com> Message-ID: <278B5E4BCD5E654385A9F83C7CA6D517CB2189E5BC@MAILBOX-01.qcommcorp.ad> I understand that part. ARIN's allocation is basically affecting routing world. But charging additional fee for route aggregation effectiveness is operational part, which is not the task ARIN is doing now. That's what I'm talking. Setting minimum allocation for ISP and end users is done by ARIN. But breaking it down for customers and have some filtering to limit the routing table size is more for ISP operation. So it is not part of ARIN's task. It is more of best common practice, I believe. Alex -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Thursday, October 15, 2009 1:07 PM To: Alex Ryu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Using fees to encourage route aggregation On Thu, Oct 15, 2009 at 1:11 PM, Alex Ryu wrote: > One of ARIN's priciple was that ARIN is not responsible for > routability of IP address allocated. Alex, One of ARIN's legal limitations of liability is that it doesn't guarantee routability of any addresses it allocates. That's not at all the same thing. IIRC, Tony Li of IRTF RRG once observed: "Routing is addressing is routing." If it wasn't Tony I apologize, but whoever authored that statement captured the long and short of it. What's *possible* in the routing system follows from how the addresses are allocated and how the addresses are allocated follows from what's needed in the routing system. ARIN's liability for what 3rd parties do with the addresses notwithstanding. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Oct 15 14:22:23 2009 From: bill at herrin.us (William Herrin) Date: Thu, 15 Oct 2009 14:22:23 -0400 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <278B5E4BCD5E654385A9F83C7CA6D517CB2189E5BC@MAILBOX-01.qcommcorp.ad> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <3c3e3fca0910150958j2384c1e0x3a7abdaaebc3148c@mail.gmail.com> <278B5E4BCD5E654385A9F83C7CA6D517CB2189E593@MAILBOX-01.qcommcorp.ad> <3c3e3fca0910151106w7d60f974y71c68d358838cc99@mail.gmail.com> <278B5E4BCD5E654385A9F83C7CA6D517CB2189E5BC@MAILBOX-01.qcommcorp.ad> Message-ID: <3c3e3fca0910151122w17104b18nf2232369eed78d04@mail.gmail.com> On Thu, Oct 15, 2009 at 2:13 PM, Alex Ryu wrote: > ARIN's allocation is basically affecting routing world. > > But charging additional fee for route aggregation effectiveness > is operational part, which is not the task ARIN is doing now. > That's what I'm talking. Hi Alex, If I read you right, that more or less meshes with what I said: before we consider charging fees based on routing table consumption, we should explore changes to the allocation policy which might enable the ISPs to accomplish the same thing independently. I then added the observation that the *existing* allocation policy that started with CIDR makes it practically impossible for ISPs to resolve the disaggregation problem on their own. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Oct 15 15:30:33 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Oct 2009 12:30:33 -0700 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <4AD74BD7.8070504@gmail.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> Message-ID: <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> On Oct 15, 2009, at 9:20 AM, Scott Leibrand wrote: > Milton L Mueller wrote: >> >> Thanks for your intervention, Chris. That's exactly where I've been >> trying to move. In that regard I find it interesting that despite >> the constant worrying about route aggregation, the proposal I made >> to use RIR fees to encourage aggregation (or "tax" deaggregation) >> has not attracted a single comment. People seem more interested in >> the broad ideological classifications than in assessing specific >> proposals. > > Perhaps people were ignoring the "fairness" thread? :-) Or > perhaps, like me, most people generally agree with that particular > point, so there's maybe not as much to discuss. My own thought is > that using fees to encourage aggregation (discourage deaggregation) > would probably work, but that there isn't a lot of need for doing so > just yet. If we get to the point where multiple networks are having > problems with routing table growth that can't be solved through > filtering of distant more-specifics, through charging customers for > route announcements, and/or through peering agreements, then perhaps > someone will resurrect the idea on arin-discuss for the board's > consideration. I don't think most people agree with that particular point. The RIRs role is NOT to afflict routing policy with their judgment of how it should be done. The RIRs should focus on allocation policies that meet the needs of the community and leave routing issues to those that run routers and the IAB/IETF/IESG/ etc. Setting fees based on disaggregation is a quagmire that would leave the RIR staff in an untenable position. Which view of the routing table would be considered the authoritative reference for disaggregation? Would momentary leaks of more specifics count against someone if they just happened to coincide with the billing sweep through the table? Over what period of time should a prefix have to be disaggregated in order to increase the billing for the prefix? Should the bill increase with the amount of time the route remains in the table? If so, how do you account for convergence delay in the billing process? Due to scarcity, IPv4 unfortunately made the RIR the point where we needed to adjudicate the balance between two strongly conflicting principles... The ability to issue address space to those who needed (through mechanisms like slow- start, limited time consumption expectancies, etc.) vs. the ability to optimize the routing table. So far, that tradeoff has been readjusted several times with allocation periods changed, maximum prefix lengths adjusted, etc. I don't know for certain what the future will hold in this for IPv4, but, it doesn't matter too much since the RIRs won't be issuing IPv4 much past the next 3 or 4 policy cycles anyway. However, in IPv6, there really is no need for the RIRs to balance this. End users and ISPs are perfectly capable of developing mechanisms to determine what IP resources from what source are required to meet their needs. The RIRs should evaluate resource requests on the basis of justified need per the policies set by the community without regard to routing. Owen From kkargel at polartel.com Thu Oct 15 15:42:36 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 15 Oct 2009 14:42:36 -0500 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu><4AD74BD7.8070504@gmail.com> <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3E0@mail> As always I will stand hard and fast against artificial fees (can you say "taxes") to control behavior. The history of the internet has always been that things are arranged so that what works best is what is easiest. If you want people to adopt a certain behavior then make it so that it is easier for them to behave in the manner you want, they will do it. > On Oct 15, 2009, at 9:20 AM, Scott Leibrand wrote: > > > Milton L Mueller wrote: > >> > >> Thanks for your intervention, Chris. That's exactly where I've been > >> trying to move. In that regard I find it interesting that despite > >> the constant worrying about route aggregation, the proposal I made > >> to use RIR fees to encourage aggregation (or "tax" deaggregation) > >> has not attracted a single comment. People seem more interested in > >> the broad ideological classifications than in assessing specific > >> proposals. > > > > Perhaps people were ignoring the "fairness" thread? :-) Or > > perhaps, like me, most people generally agree with that particular > > point, so there's maybe not as much to discuss. My own thought is > > that using fees to encourage aggregation (discourage deaggregation) > > would probably work, but that there isn't a lot of need for doing so > > just yet. If we get to the point where multiple networks are having > > problems with routing table growth that can't be solved through > > filtering of distant more-specifics, through charging customers for > > route announcements, and/or through peering agreements, then perhaps > > someone will resurrect the idea on arin-discuss for the board's > > consideration. > > > I don't think most people agree with that particular point. > > The RIRs role is NOT to afflict routing policy with their judgment of > how it should be done. > > The RIRs should focus on allocation policies that meet the needs of > the community and > leave routing issues to those that run routers and the IAB/IETF/IESG/ > etc. > > Setting fees based on disaggregation is a quagmire that would leave > the RIR staff in > an untenable position. Which view of the routing table would be > considered the > authoritative reference for disaggregation? Would momentary leaks of > more specifics > count against someone if they just happened to coincide with the > billing sweep through > the table? Over what period of time should a prefix have to be > disaggregated in order > to increase the billing for the prefix? Should the bill increase with > the amount of time > the route remains in the table? If so, how do you account for > convergence delay in the > billing process? > > Due to scarcity, IPv4 unfortunately made the RIR the point where we > needed to > adjudicate the balance between two strongly conflicting principles... > The ability > to issue address space to those who needed (through mechanisms like > slow- > start, limited time consumption expectancies, etc.) vs. the ability to > optimize > the routing table. > > So far, that tradeoff has been readjusted several times with > allocation periods > changed, maximum prefix lengths adjusted, etc. I don't know for > certain what > the future will hold in this for IPv4, but, it doesn't matter too much > since the RIRs > won't be issuing IPv4 much past the next 3 or 4 policy cycles anyway. > > However, in IPv6, there really is no need for the RIRs to balance > this. End users > and ISPs are perfectly capable of developing mechanisms to determine > what > IP resources from what source are required to meet their needs. The > RIRs should > evaluate resource requests on the basis of justified need per the > policies set > by the community without regard to routing. > > Owen > > _______________________________________________ > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From mueller at syr.edu Thu Oct 15 17:36:55 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 15 Oct 2009 17:36:55 -0400 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF601C9@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > The RIRs role is NOT to afflict routing policy with their judgment of > how it should be done. > The RIRs should focus on allocation policies that meet the needs of > the community and leave routing issues to those that run routers and the I pretty much agree with that on principle (see proviso below), but it's interesting that on Tuesdays I get excoriated for not understanding how essential RIR central planning of the address space in order to enforce route aggregation and on Thursdays we hear how RIRs have nothing to do with routing. Let's get the story straight. To be consistent, the disclaimer above is pretty clearly false. It's clear that many, many things RIRs already do are based on routing considerations. Think of your approach to PI allocations, for example. The whole thrust of post-CIDR policy is to require ip address users to aggregate under providers, which is all about routing. Bearing in mind that I am not at this point arguing for an aggregation fee, it is nevertheless important to understand that such a fee doesn't tell people how to route (any more than policies that promote provider-based aggregation do), but sets parameters or incentives around which people base routing decisions. > Which view of the routing table would be > considered the authoritative reference for > disaggregation? Would momentary leaks of > more specifics count against someone if > they just happened to coincide with the > billing sweep through the table? Over what > period of time should a prefix have to be > disaggregated in order to increase the > billing for the prefix? Should the bill increase with > the amount of time the route remains in the table? These are the _interesting_ and _useful_ questions that my floating of the aggregation fee idea was meant to elicit. Thanks! But your ability to raise such questions, which are clearly unanswered at this point, does not mean that they cannot in principle be answered. Regulatory systems are full of such metrical issues From tvest at eyeconomics.com Thu Oct 15 17:59:48 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 15 Oct 2009 23:59:48 +0200 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF601C9@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> <75822E125BCB994F8446858C4B19F0D78FF601C9@SUEX07-MBX-04.ad.syr.edu> Message-ID: <6253A4D1-3F5B-4059-81E7-6309C500F674@eyeconomics.com> On Oct 15, 2009, at 11:36 PM, Milton L Mueller wrote: > > >> -----Original Message----- >> >> The RIRs role is NOT to afflict routing policy with their judgment of >> how it should be done. That said, for the last decade-plus, it has been the RIR's role, as the executor of community-defined policies, to administer eligibility (i.e., "needs"-based allocation) policies that ultimately determine *who* gets to exercise their judgement about how to route. The terms of those policies have varied over time, but they have always been defined in terms of beneficial, operational control of addressable capital equipment. That "capitalization" requirement has helped to incentivize address recipients to exercise their independent judgment in ways that are more often more likely to be aligned toward the survival of the Internet, and less often directed toward activities that might degrade both the Internet and the value of their own capex. Obviously it's not a perfect arrangement, but can anybody think of one that might provide a better trade-off between individual freedom of "routing judgment" and the preservation of a well functioning Internet? >> The RIRs should focus on allocation policies that meet the needs of >> the community and leave routing issues to those that run routers >> and the > > I pretty much agree with that on principle (see proviso below), but > it's interesting that on Tuesdays I get excoriated for not > understanding how essential RIR central planning of the address > space in order to enforce route aggregation and on Thursdays we hear > how RIRs have nothing to do with routing. Let's get the story > straight. The story remains straight, and intact despite the attempted grammatical contortions. > To be consistent, the disclaimer above is pretty clearly false. It's > clear that many, many things RIRs already do are based on routing > considerations. Think of your approach to PI allocations, for > example. The whole thrust of post-CIDR policy is to require ip > address users to aggregate under providers, which is all about > routing. > > Bearing in mind that I am not at this point arguing for an > aggregation fee, it is nevertheless important to understand that > such a fee doesn't tell people how to route (any more than policies > that promote provider-based aggregation do), but sets parameters or > incentives around which people base routing decisions. > > >> Which view of the routing table would be >> considered the authoritative reference for >> disaggregation? Would momentary leaks of >> more specifics count against someone if >> they just happened to coincide with the >> billing sweep through the table? Over what >> period of time should a prefix have to be >> disaggregated in order to increase the >> billing for the prefix? Should the bill increase with >> the amount of time the route remains in the table? > > These are the _interesting_ and _useful_ questions that my floating > of the aggregation fee idea was meant to elicit. Thanks! > > But your ability to raise such questions, which are clearly > unanswered at this point, does not mean that they cannot in > principle be answered. Regulatory systems are full of such metrical > issues > > > _______________________________________________ > 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 tvest at eyeconomics.com Thu Oct 15 17:59:25 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 15 Oct 2009 23:59:25 +0200 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF601C9@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> <75822E125BCB994F8446858C4B19F0D78FF601C9@SUEX07-MBX-04.ad.syr.edu> Message-ID: <878E7FB0-1D9E-417C-BC38-2136C9CA311F@eyeconomics.com> On Oct 15, 2009, at 11:36 PM, Milton L Mueller wrote: > > >> -----Original Message----- >> >> The RIRs role is NOT to afflict routing policy with their judgment of >> how it should be done. That said, for the last decade-plus, it has been the RIR's role, as the executor of community-defined policies, to administer eligibility (i.e., "needs"-based allocation) policies that ultimately determine *who* gets to exercise their judgement about how to route. The terms of those policies have varied over time, but they have always been defined in terms of beneficial, operational control of addressable capital equipment. That "capitalization" requirement has helped to incentivize address recipients to exercise their independent judgment in ways that are more often more likely to be aligned toward the survival of the Internet, and less often directed toward activities that might degrade both the Internet and the value of their own capex. Obviously it's not a perfect arrangement, but can anybody think of one that might provide a better trade-off between individual freedom of "routing judgment" and the preservation of a well functioning Internet? >> The RIRs should focus on allocation policies that meet the needs of >> the community and leave routing issues to those that run routers >> and the > > I pretty much agree with that on principle (see proviso below), but > it's interesting that on Tuesdays I get excoriated for not > understanding how essential RIR central planning of the address > space in order to enforce route aggregation and on Thursdays we hear > how RIRs have nothing to do with routing. Let's get the story > straight. The story remains straight, and intact despite the attempted grammatical contortions. > To be consistent, the disclaimer above is pretty clearly false. It's > clear that many, many things RIRs already do are based on routing > considerations. Think of your approach to PI allocations, for > example. The whole thrust of post-CIDR policy is to require ip > address users to aggregate under providers, which is all about > routing. > > Bearing in mind that I am not at this point arguing for an > aggregation fee, it is nevertheless important to understand that > such a fee doesn't tell people how to route (any more than policies > that promote provider-based aggregation do), but sets parameters or > incentives around which people base routing decisions. > > >> Which view of the routing table would be >> considered the authoritative reference for >> disaggregation? Would momentary leaks of >> more specifics count against someone if >> they just happened to coincide with the >> billing sweep through the table? Over what >> period of time should a prefix have to be >> disaggregated in order to increase the >> billing for the prefix? Should the bill increase with >> the amount of time the route remains in the table? > > These are the _interesting_ and _useful_ questions that my floating > of the aggregation fee idea was meant to elicit. Thanks! > > But your ability to raise such questions, which are clearly > unanswered at this point, does not mean that they cannot in > principle be answered. Regulatory systems are full of such metrical > issues > > > _______________________________________________ > 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 mueller at syr.edu Thu Oct 15 18:10:48 2009 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 15 Oct 2009 18:10:48 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof In-Reply-To: <9DDFA14E-E051-4114-AF90-452A2440B105@eyeconomics.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <9DDFA14E-E051-4114-AF90-452A2440B105@eyeconomics.com> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF601CA@SUEX07-MBX-04.ad.syr.edu> > 1. The very notion of justifying a much more restrictive routing > policy (even in part) in order to make it easier to have a more > liberal address trading regime -- for IPv6 no less -- is both deeply > misguided and absolutely self-defeating. The aggregation fee idea had nothing to do with address trading but was intended to make it easier to liberalize address allocation. > 2. Are you suggesting > that network operators embrace this plan voluntarily, or be subjected > to it by some external authority? I answer this question with more questions: Do network operators pay ARIN fees voluntarily or are they subjected to it by some external authority? Assuming that such a system was effective in reducing route table bloat, would network operators benefit from that? Are network operators capable of funding a policy that promotes a collective good? > 3. Who sets the fees? Who collects the fees? ARIN, ARIN. Just as they do now. > Who counts the level of de-aggregation, where, using what > methodology? We toyed with various ideas, but as I wrote in response to Owen this is an open and interesting issue. But not one that seems inherently insoluble. Note that the CIDR report publishes daily summaries that purport to show what percentage gain in aggregation various networks could attain if they were properly aggregated. http://www.cidr-report.org/as2.0/ > what would prevent the routing fees from > becoming an increasingly artificial and arbitrary drag on the > Internet's growth potential "Dang gummint bureaucrats" - it does my heart good to see you moving in this direction, Tom. > 5. The closing point "not recommending" the adoption of the idea is > excellent, but it should stand alone, without any further > qualifications. Not only have I led you into Gingrichian rhetoric but now I have you praising my report in public. I think I'll call it a day. Bye, MM From tvest at eyeconomics.com Thu Oct 15 18:50:26 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Fri, 16 Oct 2009 00:50:26 +0200 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF601CA@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <9DDFA14E-E051-4114-AF90-452A2440B105@eyeconomics.com> <75822E125BCB994F8446858C4B19F0D78FF601CA@SUEX07-MBX-04.ad.syr.edu> Message-ID: <19D66594-06B1-4648-8E4D-BB581110A7C0@eyeconomics.com> On Oct 16, 2009, at 12:10 AM, Milton L Mueller wrote: > >> 1. The very notion of justifying a much more restrictive routing >> policy (even in part) in order to make it easier to have a more >> liberal address trading regime -- for IPv6 no less -- is both deeply >> misguided and absolutely self-defeating. > > The aggregation fee idea had nothing to do with address trading but > was intended to make it easier to liberalize address allocation. > >> 2. Are you suggesting >> that network operators embrace this plan voluntarily, or be subjected >> to it by some external authority? > > I answer this question with more questions: > > Do network operators pay ARIN fees voluntarily or are they subjected > to it by some external authority? They are paid voluntarily. They are authorized by community-defined policies that were voluntarily enacted. Newer members that joined ARIN after the policies were promulgated implicitly buy into previous policies as the price of admission, but are then are at their liberty to work to change or rescind any policies that they disagree with, just like all of the other members. No doubt the fees are not always paid with equal and abundant joy, but in the real world that's not much of an counter-argument. Perhaps some people feel oppressed by every rule and law (maybe laws of physics too) that they did not unilaterally dictate themselves, but again in the real world that doesn't hold up as a very credible benchmark. > Assuming that such a system was effective in reducing route table > bloat, would network operators benefit from that? Are network > operators capable of funding a policy that promotes a collective good? > >> 3. Who sets the fees? Who collects the fees? > > ARIN, ARIN. Just as they do now. Who is ARIN, exactly? You either have to mean that the members voluntarily embrace this arrangement, and craft polices that define how it should be executed, or this is an incoherent statement. >> Who counts the level of de-aggregation, where, using what >> methodology? > > We toyed with various ideas, but as I wrote in response to Owen this > is an open and interesting issue. But not one that seems inherently > insoluble. Note that the CIDR report publishes daily summaries that > purport to show what percentage gain in aggregation various networks > could attain if they were properly aggregated. > > http://www.cidr-report.org/as2.0/ > >> what would prevent the routing fees from >> becoming an increasingly artificial and arbitrary drag on the >> Internet's growth potential > > "Dang gummint bureaucrats" - it does my heart good to see you moving > in this direction, Tom. You're confused here Milton. Are you suggesting that the ITU staffers dictated the settlement rates? I think if you check your notes, you'll find that it was the members -- i.e., monolithic national PSTNs (the plenipots) that were either practically or absolutely indistinguishable from the national telecom ministry officials that sat in Geneva. They defined the settlements rates, and it was their individual (corporate) private interests, rather than the machinations of permanent ITU staffers -- that kept the rates high even as technology was starting to bring the actual cost of telecom service delivery down by huge increments. At least that's how the system was until about 1996, when it started unravel. I'm glad that that little jab made you feel good, but now that we've excavated what you really meant, you really are suggesting that the RIRs -- pretty much the only non-router owning entities in the whole system -- will define, levy, and collect explicit routing de- aggregation fees from the institutions that actually invest in and operate routing service platforms? Not that it matters one bit (and this is my opinion only), but I don't think that RIR permanent staffers would exactly embrace that role -- nor do I think that you should expect a rush of support for this idea within the community. Give it a try though -- maybe I'll be surprised. >> 5. The closing point "not recommending" the adoption of the idea is >> excellent, but it should stand alone, without any further >> qualifications. > > Not only have I led you into Gingrichian rhetoric but now I have you > praising my report in public. I think I'll call it a day. Silly or not, it's nice to end on a happy note for a change -- good night! TV From scottleibrand at gmail.com Thu Oct 15 19:38:29 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 15 Oct 2009 16:38:29 -0700 Subject: [arin-ppml] Encouraging IPv6 route aggregation In-Reply-To: <4AD7AFB7.6060905@umn.edu> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <4AD7AFB7.6060905@umn.edu> Message-ID: <4AD7B275.7080306@gmail.com> David Farmer wrote: > I do believe it is important to deal with IPv6 route aggregation and > soon, because I also agree with Scott that "there isn't a lot of need > for doing so just yet". But that is because the IPv6 toothpaste is > still mostly in the tube. So while maybe we don't need it just yet, > we can't wait until we actually need it, it may be to late to > implement anything then. > > However, even with more and more IPv6 coming out of the toothpaste > tube everyday, I think we are better off in IPv6 than we are currently > in IPv4. With IPv6 there is simply just more room to work with. > Which allows for a generous but limited set of allocation sizes from > the RIRs, with /32s for most ISPs and larger for really large ISPs. > With /48s from the RIRs for multihomed PI end-user assignments, or > /48s, /56s, /64s, or /128s to end-users from providers for PA > assignments. > > So today for IPv6 ARIN provides /32s or greater for PA allocations > from a set of ranges, the /48s or greater for PA end-user space from > another range (probably set of ranges in the future, but only one > range so far), and there several other special purpose ranges with a > /48 allocation/assignment sizes, this creates up a pretty reasonable > set of filtering policies that can be implemented by the operator > community. > If ARIN can maintain allocation and assignment policies that segregate > the types of allocations and assignments into separate documented > ranges I think it will be possible for the operator community to > maintain reasonable routing policy and filters to implement their > chosen policy. Agreed. > > I believe the General Purpose ranges, along with the Critical > Infrastructure and maybe the Exchange Point Micro Allocation ranges, > should make up most of ARIN region's contribution to the mythical > global route table. > > An idea I've been kicking around is a class of end-user assignments > not intended for routing in the mythical global route table, but for > things like VPNs, and other private network needs, not necessarily > intended to have global reachability, but that needs global uniqueness > and reverse DNS. Some of you say use ULA for that, but ULA only > provides statical uniqueness, not the guarantee of uniqueness that an > assignment authority can, and since there is no assignment authority > for ULA, authoritative reverse DNS is not possible. This would be > similar to NRPM 6.10.2 but for end-users and not ISPs, since > Micro-allocations for Internal Infrastructure are restricted to > "Organizations that currently hold IPv6 allocations". I'd rather not > debate the merits of this idea now, but wanted to provide an example > that illustrates how ARIN policy can and should work with and enable > good routing policy. Sounds like ULA-Global (which I supported). > > I'm not sure how many operators currently filter the Internal > Infrastructure Micro Allocation range 2001:0506::/31. ARIN policy > doesn't require anyone to do so, but by having it as a separate > documented range ARIN policy makes it possible for operators to have a > routing policy that filters it if they so desire. Whereas if it were > not a separate documented range, it would probably be nearly > impossible to filter these allocations. > > So currently the main policy tool that ARIN, and the other RIRs have, > have that influences and enables routing policy is to create > classifications for allocations or assignments and to put them into > documented ranges. So I believe we need to remember that RIR policy > has a responsibility the consider and implement at least this part of > routing policy. > > So lets think about applying this to the IPv6 policies on the table > right now; > > 2008-3 Community Networks IPv6 Assignment - It is probably kind of > late in the process for this, but maybe it would be a good idea for > these assignments to come out of separate documented range. Do I recall correctly that ARIN staff said they would do so, even if not specifically required by policy? > > 2009-5 Multiple Discrete Networks - Should those allocations come out > of a separate documented range? No. These allocations are identical to other General Purpose allocations, except that an organization with multiple networks may have one for each network. > > 2009-7 Open Access To IPv6 - One of the things we are doing is > removing the requirement to advertise a singe aggregate of an > allocation. Rather than eliminating the restriction all together, it > might be better from a routing policy point of view to create a > separate documented range without the requirement to announce an > aggregate. Maybe it is not unreasonable for this to have an extra fee > associated with an allocation out of this block too? (Fees are not > directly a policy issue, but it could be a recommendation that the > Board consider an extra fee in this case.) I have heard some valid > reasons for some networks to not announce an aggregate of there IPv6 > allocation, but I still believe most network can and should announce > an aggregate. Maybe we shouldn't through the baby out with the bath > water on this one. Creating a range for allocations without the > requirement for announcing an aggregate would allow operators to have > a routing policy to require it for the vast majority that can and > should announce an aggregate. This seems like unnecessary complexity to me. > > Comments please, and please bend my ear in Dearborn next week on this > issue too. > Looking forward to it! -Scott From bill at herrin.us Thu Oct 15 19:45:21 2009 From: bill at herrin.us (William Herrin) Date: Thu, 15 Oct 2009 19:45:21 -0400 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <098FCE76-51E9-4F76-A4A9-EFA26D8BEC0E@delong.com> Message-ID: <3c3e3fca0910151645wa959c2j63cd3a9068fe50f4@mail.gmail.com> On Thu, Oct 15, 2009 at 3:30 PM, Owen DeLong wrote: > The RIRs should focus on allocation policies that meet the needs of the > community and leave routing issues to those that run routers and > the IAB/IETF/IESG/etc. Owen, The notion that decisions made at the allocation policy level don't determine the shape and nature of the routing issues is just plain silly. I wag my finger at you. Current *ARIN* routing policy is that anyone in the ARIN region can disaggregate any way they want and the rest of us will live with it. This isn't written anywhere, yet it's one sum effect of many other things that are. I'll break it down for you if you need, but I suspect you already understand how the pieces fit together to bring about that result. Personally I think preventing disaggregate filtering and reassembly is a *bad* ARIN policy. I'd like to see it change. In fact, I'd like to see ARIN actively seek to *empower* disaggregate filtering and reassembly for whatever fraction of the DFZ participants choose to do so. > The RIRs role is NOT to afflict routing policy with their judgment of how it > should be done. Yet with each decision, we do. Such is the nature of addressing policy. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Thu Oct 15 19:26:47 2009 From: farmer at umn.edu (David Farmer) Date: Thu, 15 Oct 2009 18:26:47 -0500 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <4AD74BD7.8070504@gmail.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> Message-ID: <4AD7AFB7.6060905@umn.edu> Scott Leibrand wrote: > Milton L Mueller wrote: >> >> Thanks for your intervention, Chris. That's exactly where I've been >> trying to move. In that regard I find it interesting that despite the >> constant worrying about route aggregation, the proposal I made to use >> RIR fees to encourage aggregation (or "tax" deaggregation) has not >> attracted a single comment. People seem more interested in the broad >> ideological classifications than in assessing specific proposals. > > Perhaps people were ignoring the "fairness" thread? :-) Or perhaps, > like me, most people generally agree with that particular point, so > there's maybe not as much to discuss. My own thought is that using fees > to encourage aggregation (discourage deaggregation) would probably work, > but that there isn't a lot of need for doing so just yet. If we get to > the point where multiple networks are having problems with routing table > growth that can't be solved through filtering of distant more-specifics, > through charging customers for route announcements, and/or through > peering agreements, then perhaps someone will resurrect the idea on > arin-discuss for the board's consideration. > > -Scott Not that I would be against a market based economic approach, fee based disincentives, or necessarily for a policy based regulatory approach to encourage aggregation. However I do agree with Bill comments that; "That ship has sailed for IPv4. CIDR combined with imperfect record keeping and the concept of LIRs assigning addresses to multihomed entities killed the possibility of disaggregate filtering in IPv4." I do believe it is important to deal with IPv6 route aggregation and soon, because I also agree with Scott that "there isn't a lot of need for doing so just yet". But that is because the IPv6 toothpaste is still mostly in the tube. So while maybe we don't need it just yet, we can't wait until we actually need it, it may be to late to implement anything then. However, even with more and more IPv6 coming out of the toothpaste tube everyday, I think we are better off in IPv6 than we are currently in IPv4. With IPv6 there is simply just more room to work with. Which allows for a generous but limited set of allocation sizes from the RIRs, with /32s for most ISPs and larger for really large ISPs. With /48s from the RIRs for multihomed PI end-user assignments, or /48s, /56s, /64s, or /128s to end-users from providers for PA assignments. So today for IPv6 ARIN provides /32s or greater for PA allocations from a set of ranges, the /48s or greater for PA end-user space from another range (probably set of ranges in the future, but only one range so far), and there several other special purpose ranges with a /48 allocation/assignment sizes, this creates up a pretty reasonable set of filtering policies that can be implemented by the operator community. For the ARIN region the current ranges are; General Purpose Provider Allocations /32 or shorter; 2001:0400::/23 2001:1800::/23 2001:4800::/23 2600:0000::/12 2610:0000::/23 General Purpose End-User Assignments (PI), /48 or shorter; 2620:0000:/23 Special Purpose Micro Allocations, /48 of shorter; Internal Infrastructure (non-routed), 2001:0506::/31 Exchange Points, 2001:0504::/31 Critical Infrastructure, 2001:0500::/30 If ARIN can maintain allocation and assignment policies that segregate the types of allocations and assignments into separate documented ranges I think it will be possible for the operator community to maintain reasonable routing policy and filters to implement their chosen policy. I believe the General Purpose ranges, along with the Critical Infrastructure and maybe the Exchange Point Micro Allocation ranges, should make up most of ARIN region's contribution to the mythical global route table. An idea I've been kicking around is a class of end-user assignments not intended for routing in the mythical global route table, but for things like VPNs, and other private network needs, not necessarily intended to have global reachability, but that needs global uniqueness and reverse DNS. Some of you say use ULA for that, but ULA only provides statical uniqueness, not the guarantee of uniqueness that an assignment authority can, and since there is no assignment authority for ULA, authoritative reverse DNS is not possible. This would be similar to NRPM 6.10.2 but for end-users and not ISPs, since Micro-allocations for Internal Infrastructure are restricted to "Organizations that currently hold IPv6 allocations". I'd rather not debate the merits of this idea now, but wanted to provide an example that illustrates how ARIN policy can and should work with and enable good routing policy. I'm not sure how many operators currently filter the Internal Infrastructure Micro Allocation range 2001:0506::/31. ARIN policy doesn't require anyone to do so, but by having it as a separate documented range ARIN policy makes it possible for operators to have a routing policy that filters it if they so desire. Whereas if it were not a separate documented range, it would probably be nearly impossible to filter these allocations. So currently the main policy tool that ARIN, and the other RIRs have, have that influences and enables routing policy is to create classifications for allocations or assignments and to put them into documented ranges. So I believe we need to remember that RIR policy has a responsibility the consider and implement at least this part of routing policy. So lets think about applying this to the IPv6 policies on the table right now; 2008-3 Community Networks IPv6 Assignment - It is probably kind of late in the process for this, but maybe it would be a good idea for these assignments to come out of separate documented range. 2009-5 Multiple Discrete Networks - Should those allocations come out of a separate documented range? 2009-7 Open Access To IPv6 - One of the things we are doing is removing the requirement to advertise a singe aggregate of an allocation. Rather than eliminating the restriction all together, it might be better from a routing policy point of view to create a separate documented range without the requirement to announce an aggregate. Maybe it is not unreasonable for this to have an extra fee associated with an allocation out of this block too? (Fees are not directly a policy issue, but it could be a recommendation that the Board consider an extra fee in this case.) I have heard some valid reasons for some networks to not announce an aggregate of there IPv6 allocation, but I still believe most network can and should announce an aggregate. Maybe we shouldn't through the baby out with the bath water on this one. Creating a range for allocations without the requirement for announcing an aggregate would allow operators to have a routing policy to require it for the vast majority that can and should announce an aggregate. Comments please, and please bend my ear in Dearborn next week on this issue too. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Thu Oct 15 21:32:31 2009 From: bill at herrin.us (William Herrin) Date: Thu, 15 Oct 2009 21:32:31 -0400 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <4AD7AFB7.6060905@umn.edu> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <4AD7AFB7.6060905@umn.edu> Message-ID: <3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com> On Thu, Oct 15, 2009 at 7:26 PM, David Farmer wrote: > I do believe it is important to deal with IPv6 route aggregation and soon, > because I also agree with Scott that "there isn't a lot of need for doing so > just yet". ?But that is because the IPv6 toothpaste is still mostly in the > tube. ?So while maybe we don't need it just yet, we can't wait until we > actually need it, it may be to late to implement anything then. > > General Purpose Provider Allocations /32 or shorter; > 2001:0400::/23 > 2001:1800::/23 > 2001:4800::/23 > 2600:0000::/12 > 2610:0000::/23 > > General Purpose End-User Assignments (PI), /48 or shorter; > 2620:0000:/23 Hi David, One ARIN policy problem that's turning this into an IPv6 swamp is the "or shorter" part. Every time ARIN hands out a /40 they've effectively handed out 256 disaggregable /48's. As a community we'd be far better off if everyone who could justify more than a /48 got a /32 from the /32 blocks instead. This isn't IPv4. We don't actually need to save the bits between /40 and /32 but it would be awfully handy if I could write a simple route filter that says, "your entire ARIN allocation (not subdivided parts of it) is what I'm willing to accept and route." I could even resort to, "whichever neighbor offers the largest chunk of a given ARIN allocation gets the packets for the whole thing so don't try to mess with me by failing to offer the aggregate route." Functionally, this means reintroducing what amounts to classful addressing at the interdomain level. The difference this time is that there actually are enough class B's for everyone who needs more than a class C. There are even enough class A's. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Thu Oct 15 22:14:29 2009 From: mysidia at gmail.com (James Hess) Date: Thu, 15 Oct 2009 21:14:29 -0500 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <4AD74BD7.8070504@gmail.com> <4AD7AFB7.6060905@umn.edu> <3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com> Message-ID: <6eb799ab0910151914q61c41f00l25bcff8e617f74c7@mail.gmail.com> On Thu, Oct 15, 2009 at 8:32 PM, William Herrin wrote: > On Thu, Oct 15, 2009 at 7:26 PM, David Farmer wrote: .. > One ARIN policy problem that's turning this into an IPv6 swamp is the > "or shorter" part. Every time ARIN hands out a /40 they've effectively > handed out 256 disaggregable /48's. As a community we'd be far better > off if everyone who could justify more than a /48 got a /32 from the > /32 blocks instead. Agreed, this may be quite a mess. It should be _either_ /32 or shorter, if more than 1 /48 is justified, or /48, if a /48 is sufficient. There should be no such thing as getting a /40 from the /48 blocks. That does basically begin to defeat any point of having separate ranges that /48s are allocated from, other than having a way to stop in advance someone with a /24 from generating 16,777,216 /48 announcements, that is. Perhaps methods of filtering based on number of announcements per AS will become popular in the V6 internet... E.g. filtering to 15 prefixes per AS, and discarding entries beyond the 15th, or selecting a previously accepted entry to replace (if prefix of received announce is shorter than the shortest prefix of a previously accepted item). Then and there (however) ISPs might seek to get more ASes for TE purposes. Might want to start thinking about expanding the ASN field to 128 bits -- -J From tvest at eyeconomics.com Fri Oct 16 09:05:14 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Fri, 16 Oct 2009 15:05:14 +0200 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF601CA@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu> <9DDFA14E-E051-4114-AF90-452A2440B105@eyeconomics.com> <75822E125BCB994F8446858C4B19F0D78FF601CA@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Oct 16, 2009, at 12:10 AM, Milton L Mueller wrote: > >> 1. The very notion of justifying a much more restrictive routing >> policy (even in part) in order to make it easier to have a more >> liberal address trading regime -- for IPv6 no less -- is both deeply >> misguided and absolutely self-defeating. > > The aggregation fee idea had nothing to do with address trading but > was intended to make it easier to liberalize address allocation. > >> 2. Are you suggesting >> that network operators embrace this plan voluntarily, or be subjected >> to it by some external authority? > > I answer this question with more questions: > > Do network operators pay ARIN fees voluntarily or are they subjected > to it by some external authority? > > Assuming that such a system was effective in reducing route table > bloat, would network operators benefit from that? Are network > operators capable of funding a policy that promotes a collective good? For the answer to this question, please check the current status of IPv6 deployment. TV >> 3. Who sets the fees? Who collects the fees? > > ARIN, ARIN. Just as they do now. > >> Who counts the level of de-aggregation, where, using what >> methodology? > > We toyed with various ideas, but as I wrote in response to Owen this > is an open and interesting issue. But not one that seems inherently > insoluble. Note that the CIDR report publishes daily summaries that > purport to show what percentage gain in aggregation various networks > could attain if they were properly aggregated. > > http://www.cidr-report.org/as2.0/ > >> what would prevent the routing fees from >> becoming an increasingly artificial and arbitrary drag on the >> Internet's growth potential > > "Dang gummint bureaucrats" - it does my heart good to see you moving > in this direction, Tom. > >> 5. The closing point "not recommending" the adoption of the idea is >> excellent, but it should stand alone, without any further >> qualifications. > > Not only have I led you into Gingrichian rhetoric but now I have you > praising my report in public. I think I'll call it a day. > > Bye, > MM From kkargel at polartel.com Fri Oct 16 11:38:28 2009 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 16 Oct 2009 10:38:28 -0500 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <6eb799ab0910151914q61c41f00l25bcff8e617f74c7@mail.gmail.com> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu><4AD74BD7.8070504@gmail.com> <4AD7AFB7.6060905@umn.edu><3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com> <6eb799ab0910151914q61c41f00l25bcff8e617f74c7@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3EE@mail> Regarding fees for behavior modification: ARIN properly charges reasonable fees for services provided. This is well and good. When ARIN starts to act like a government by emplacing mandatory taxes (artificial fees) to regulate behavior it will be bad. Be careful not to outgrow your britches. Remember that ARIN works only because of voluntary cooperation by the community. That cooperation exists because of the wonderful work done thus far ensuring that compliance is not too onorus a task and fees are not excessive. If you change either of those people will start finding ways around ARIN to avoid either the excessive fees or the onorus tasks. In fact people already do this. There are companies (some rather large corporations) using "public" IP networks not assigned to them for internal routing. The only penalty for doing so is that they cannot communicate with the rightful network. So long as they pick a network rightfully "on the far side of the earth" the impact of their policy is negligable. ARIN does not have an Army or direct force of law to police it's policies. What it does have is the support and cooperation of the community. Members correctly and voluntarily agree not to route networks operating outside of ARIN policy. Members voluntarily pay reasonable fees for services rendered and commit to policy agreements. I completely and enthusiastically support this methodology. It is the best, most effective and most efficient way to manage a global network possible. So far we have done a great job. Let's not muck it up now with taxes thinly veiled as economic incentives. We also need to think of the economy that everyone is complaining about. We should be working to find ways to make internet operations less costly, not dreaming up artificial fees to make it more expensive. We can directly affect the state of the economy. We can choose whether to make it better or worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3224 bytes Desc: not available URL: From warren at wholesaleinternet.com Fri Oct 16 12:17:35 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 16 Oct 2009 11:17:35 -0500 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3EE@mail> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu><4AD74BD7.8070504@gmail.com><4AD7AFB7.6060905@umn.edu><3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com><6eb799ab0910151914q61c41f00l25bcff8e617f74c7@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3EE@mail> Message-ID: Kevin, This is well said. ARIN's ability to enforce policy is fairly limited. In my limited experience, it seems enforcement is done primarily at the time when an organization requests it's first allocation or upon subsequent allocations. Post-IPv4 exhaustion ARIN's ability to enforce policy will diminish significantly if it doesn't find a way to keep itself relevant (i.e. managing some sort of IPv4 transfer market). I don't feel handing out IPv6 allocations will be enough because ultimately any organization only needs 1 allocation and thus enforcement is only done once. Right now, everything is pretty friendly. We all get the IPv4 Ips we need without much trouble. Post-exhaustion, the policy purists are going to be under pressure from a corporate master up the food chain (and there always is one) to affect policy that financially benefits them and their ipv4 holdings. Going to your point of cooperation, what the community should be concerned about is the world splitting into various factions and NOT cooperating in the way they have to date. There's a word for that. Thanks, Warren -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Friday, October 16, 2009 10:38 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Using fees to encourage route aggregation Regarding fees for behavior modification: ARIN properly charges reasonable fees for services provided. This is well and good. When ARIN starts to act like a government by emplacing mandatory taxes (artificial fees) to regulate behavior it will be bad. Be careful not to outgrow your britches. Remember that ARIN works only because of voluntary cooperation by the community. That cooperation exists because of the wonderful work done thus far ensuring that compliance is not too onorus a task and fees are not excessive. If you change either of those people will start finding ways around ARIN to avoid either the excessive fees or the onorus tasks. In fact people already do this. There are companies (some rather large corporations) using "public" IP networks not assigned to them for internal routing. The only penalty for doing so is that they cannot communicate with the rightful network. So long as they pick a network rightfully "on the far side of the earth" the impact of their policy is negligable. ARIN does not have an Army or direct force of law to police it's policies. What it does have is the support and cooperation of the community. Members correctly and voluntarily agree not to route networks operating outside of ARIN policy. Members voluntarily pay reasonable fees for services rendered and commit to policy agreements. I completely and enthusiastically support this methodology. It is the best, most effective and most efficient way to manage a global network possible. So far we have done a great job. Let's not muck it up now with taxes thinly veiled as economic incentives. We also need to think of the economy that everyone is complaining about. We should be working to find ways to make internet operations less costly, not dreaming up artificial fees to make it more expensive. We can directly affect the state of the economy. We can choose whether to make it better or worse. From cliffb at cjbsys.bdb.com Fri Oct 16 14:56:28 2009 From: cliffb at cjbsys.bdb.com (Cliff) Date: Fri, 16 Oct 2009 14:56:28 -0400 (EDT) Subject: [arin-ppml] [a-p] Fairness of banning IPv4 allocations Message-ID: <200910161856.n9GIuSmv017587@cjbsys.bdb.com> Michael Dillon wrote .....> > > If this ISP had non-VLSM gear, then a /16 would not work and > a class B address block would also not work. They would require > 200 or so class C blocks. You cannot subnet a class B address > block into smaller blocks. That's one benefit of VLSM where any > /16 can easily be subnetted into /24 blocks or any size you wish. I'm pretty sure even my old Xenix system would subnet Class Bs down to a Class C. Some of the older stuff wouldn't subnet a class C but almost everything could use the subnet mask so you could get 256 (254?) Class C subnets from a Class B. see http://articles.techrepublic.com.com/5100-10878_11-5033673.html Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From tedm at ipinc.net Fri Oct 16 16:03:03 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 16 Oct 2009 13:03:03 -0700 Subject: [arin-ppml] Using fees to encourage route aggregation In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3EE@mail> References: <75822E125BCB994F8446858C4B19F0D78FF601B0@SUEX07-MBX-04.ad.syr.edu><4AD74BD7.8070504@gmail.com> <4AD7AFB7.6060905@umn.edu><3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com> <6eb799ab0910151914q61c41f00l25bcff8e617f74c7@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A06314106601F4A3EE@mail> Message-ID: <4AD8D177.70006@ipinc.net> Kevin Kargel wrote: > > Regarding fees for behavior modification: > ARIN properly charges reasonable fees for services provided. This is well > and good. When ARIN starts to act like a government by emplacing mandatory > taxes (artificial fees) to regulate behavior it will be bad. Aside from the fact that the ARIN charter would have to be modified, it's been observed by many people in the past when this has come up that in most larger orgs, the bills are paid by an accounting dept. not by the admin, and are thus not effective as a means of modifying the admin's behavior. Ted From Melody_Palmer at heart-nta.org Fri Oct 16 16:14:56 2009 From: Melody_Palmer at heart-nta.org (Melody_Palmer at heart-nta.org) Date: Fri, 16 Oct 2009 15:14:56 -0500 Subject: [arin-ppml] AUTO: Melody Palmer is out of the office. (returning Mon 10/26/2009) Message-ID: I am out of the office from Fri 10/16/2009 until Mon 10/26/2009. I will respond to your message promptly when I return. Note: This is an automated response to your message "ARIN-PPML Digest, Vol 52, Issue 30" sent on 16/10/2009 10:36:58 AM. This is the only notification you will receive while this person is away. From tedm at ipinc.net Fri Oct 16 16:23:34 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 16 Oct 2009 13:23:34 -0700 Subject: [arin-ppml] [a-p] Fairness of banning IPv4 allocations In-Reply-To: <200910161856.n9GIuSmv017587@cjbsys.bdb.com> References: <200910161856.n9GIuSmv017587@cjbsys.bdb.com> Message-ID: <4AD8D646.5070703@ipinc.net> Cliff wrote: > Michael Dillon wrote > > .....> >> If this ISP had non-VLSM gear, then a /16 would not work and >> a class B address block would also not work. They would require >> 200 or so class C blocks. You cannot subnet a class B address >> block into smaller blocks. That's one benefit of VLSM where any >> /16 can easily be subnetted into /24 blocks or any size you wish. > > I'm pretty sure even my old Xenix system would subnet Class Bs down to a Class > C. Some of the older stuff wouldn't subnet a class C but almost everything > could use the subnet mask so you could get 256 (254?) Class C subnets from a > Class B. > > see http://articles.techrepublic.com.com/5100-10878_11-5033673.html > > > Cliff It's not that, it's that some of the older terminal server gear only spoke RIP v1, which is classful. I remember dealing with a pair of US Robotics 8 port terminal servers that were like this. This was circa 1996, a lot younger than Xenix. Ted From farmer at umn.edu Fri Oct 16 19:47:25 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 16 Oct 2009 18:47:25 -0500 Subject: [arin-ppml] Encouraging IPv6 route aggregation In-Reply-To: <3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com> References: , <4AD7AFB7.6060905@umn.edu>, <3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com> Message-ID: <4AD8BFBD.4852.AAADB9C@farmer.umn.edu> On 15 Oct 2009 William Herrin wrote: > On Thu, Oct 15, 2009 at 7:26 PM, David Farmer wrote: ... > > General Purpose End-User Assignments (PI), /48 or shorter; > > 2620:0000:/23 > > Hi David, > > One ARIN policy problem that's turning this into an IPv6 swamp is the > "or shorter" part. Every time ARIN hands out a /40 they've effectively > handed out 256 disaggregable /48's. As a community we'd be far better > off if everyone who could justify more than a /48 got a /32 from the > /32 blocks instead. This is interesting idea, I'm not convinced just yet, but my initial reaction is it might be a good idea. However, I realy want to hear what more people think about this idea. > This isn't IPv4. We don't actually need to save the bits between /40 > and /32 but it would be awfully handy if I could write a simple route > filter that says, "your entire ARIN allocation (not subdivided parts > of it) is what I'm willing to accept and route." I could even resort > to, "whichever neighbor offers the largest chunk of a given ARIN > allocation gets the packets for the whole thing so don't try to mess > with me by failing to offer the aggregate route." So then are you opposed to the part of 2009-7 that removes the requirement to announce the aggregate allocation? If we allow service providers to announce prefixes between /32 and /48 then why not assign blocks between /32 and /48 to end-users who justify them, that that the will reall be that many of them? I would be very much opposed to making a similar jump from /32 to /24 or shorter, but I can see the logic of going from /48 to /32. If you justify more than a /32, you should only get what you can justify, one bit at a time. I'll be leading one of the lunch tables topics on IPv6 on Thursday in Dearborn, I would like to here what people think. =============================================== David Farmer Email:farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 =============================================== From farmer at umn.edu Fri Oct 16 20:34:30 2009 From: farmer at umn.edu (David Farmer) Date: Fri, 16 Oct 2009 19:34:30 -0500 Subject: [arin-ppml] Encouraging IPv6 route aggregation In-Reply-To: <4AD7B275.7080306@gmail.com> References: , <4AD7AFB7.6060905@umn.edu>, <4AD7B275.7080306@gmail.com> Message-ID: <4AD8CAC6.32032.AD5F58B@farmer.umn.edu> On 15 Oct 2009 Scott Leibrand wrote: > David Farmer wrote: ... > > So lets think about applying this to the IPv6 policies on the table > > right now; > > > > 2008-3 Community Networks IPv6 Assignment - It is probably kind of > > late in the process for this, but maybe it would be a good idea for > > these assignments to come out of separate documented range. > > Do I recall correctly that ARIN staff said they would do so, even if not > specifically required by policy? Not sure, but we should probably ask staff in Dearborn. > > 2009-5 IPv6 Multiple Discrete Networks - Should those allocations come out > > of a separate documented range? > > No. These allocations are identical to other General Purpose > allocations, except that an organization with multiple networks may have > one for each network. I can see that argument, but since these organizations will have multiple networks, I will already receive multiple route entries from them. Therefore, I might be less incline to take longer prefixes from them in addition to the multiple networks I will need to take from them already. So, maybe we should segregate them from other networks, just a thought. Also, I thought I heard some say that 2009-5 might not be necessary if we remove the requirement to announce an aggregate. Is that a better way to deal with this issue? Or, if we allow IPv6 Multiple Discrete Networks can we keep the requirement to announce an aggregate for all allocations? Should multi-site end-users organizations be able to get more than one /48 and announce them separately? If not, why not. > > 2009-7 Open Access To IPv6 - One of the things we are doing is > > removing the requirement to advertise a singe aggregate of an > > allocation. Rather than eliminating the restriction all together, it > > might be better from a routing policy point of view to create a > > separate documented range without the requirement to announce an > > aggregate. Maybe it is not unreasonable for this to have an extra fee > > associated with an allocation out of this block too? (Fees are not > > directly a policy issue, but it could be a recommendation that the > > Board consider an extra fee in this case.) I have heard some valid > > reasons for some networks to not announce an aggregate of there IPv6 > > allocation, but I still believe most network can and should announce > > an aggregate. Maybe we shouldn't through the baby out with the bath > > water on this one. Creating a range for allocations without the > > requirement for announcing an aggregate would allow operators to have > > a routing policy to require it for the vast majority that can and > > should announce an aggregate. > > This seems like unnecessary complexity to me. Yes, this would add complexity, but so does having networks that are not willing or able to announce an aggregate. I'm willing to be a little flexible for the people that have real serious technical issues and can't announce an aggregate. But maybe they should have a little extra complexity. Because this does create complexity for everyone else, to allow them the option to not announce an aggregate. Maybe another option would be to require a SWIP for any longer prefixes announced and that a "No Aggregate" tag be put on their Allocation in ARIN's Database. And, I still think segregating them might be a good idea. If service providers can get a /32 allocation and announce part of it without announcing the aggregate, they why shouldn't end- users be able to do the same thing with a /48? If not, why not. > > Comments please, and please bend my ear in Dearborn next week on this > > issue too. > > > > Looking forward to it! > > -Scott =============================================== David Farmer Email:farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 =============================================== From bill at herrin.us Fri Oct 16 23:34:01 2009 From: bill at herrin.us (William Herrin) Date: Fri, 16 Oct 2009 23:34:01 -0400 Subject: [arin-ppml] Encouraging IPv6 route aggregation In-Reply-To: <4AD8BFBD.4852.AAADB9C@farmer.umn.edu> References: <4AD7AFB7.6060905@umn.edu> <3c3e3fca0910151832w5cc978d5m56518d872d8b3412@mail.gmail.com> <4AD8BFBD.4852.AAADB9C@farmer.umn.edu> Message-ID: <3c3e3fca0910162034j3b2d1e5ic10d11fcb5fe527d@mail.gmail.com> On Fri, Oct 16, 2009 at 7:47 PM, David Farmer wrote: > On 15 Oct 2009 William Herrin wrote: >> One ARIN policy problem that's turning this into an IPv6 swamp is the >> "or shorter" part. Every time ARIN hands out a /40 they've effectively >> handed out 256 disaggregable /48's. As a community we'd be far better >> off if everyone who could justify more than a /48 got a /32 from the >> /32 blocks instead. > > This is interesting idea, I'm not convinced just yet, but my initial reaction is it > might be a good idea. ?However, ?I realy want to hear what more people think > about this idea. Hi David, There's more than one sensible way to manage IPv6 allocations. The current ARIN method doesn't happen to be one of them but here's one that might be: Have two pools every 8 bits, 1 pool for multihomers and one for single-homers. 12 pools, 2 each for allocating /56's, /48's, /40's, /32's, /24's and /16's. Registrant gets an allocation from the smallest pool that accommodates his justification. So, if he can justify a multihomed /47, he gets a /40 from the multihomed /40 pool, not a /47 from the /48 pool. Two more rules to tweak it just so: No organization can register more than one allocation at each bit divide. So, if you have a /48 and you need another /48, you can't get another /48. Instead, your need for an additional /48 justifies a /40. If you cease to be multihomed you have 3 months to resume multihoming or surrender your mutlihomed allocations. What would be the impact of such a scheme? Allocating in this manner has the effect of "classifying" each registrant on two vectors: single/mutli homed and size. That classification is trivially decodeable at each router by evaluating which pool the prefix falls in. Classifying registrants in this manner allows the ISPs a wide range of flexibility in setting their own routing policies. It also removes ARIN as the gatekeeper for Internet routing policy: everybody qualifies for addresses but unlike with IPv4 the addresses you qualify for *really* might not be routable. If we're serious about ARIN extricating itself from IPv6 routing policy then we have to do a good enough and precise enough job classifying the allocations for ISPs to hang coherent routing policies on. >I would be very much opposed to making a similar jump >from /32 to /24 or shorter, but I can see the logic of going >from /48 to /32. Then nibble instead of byteing. Go to from /32 to /28 and then to /24, but do it with separate pools so that they're usable for classification purposes within ISP routing policy. > So then are you opposed to the part of 2009-7 that removes the requirement > to announce the aggregate allocation? I'm of the opinion that ARIN shouldn't set routing requirements until it has exhausted all approaches of the "empowerment" variety that could make it practical for the ISPs to deal with the bad actors directly. So in general, I favor removing the ARIN-level requirement to announce an aggregate. I'm not so sure about this particular proposal. I haven't scrutinized the second and third order effects of making just those two adjustments but it seems like it might be unbalanced, shifting the overall policy into a worse state instead of a better one. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mcr at sandelman.ca Tue Oct 20 13:33:59 2009 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 20 Oct 2009 13:33:59 -0400 Subject: [arin-ppml] SmartGrid deployments and talk Message-ID: <20243.1256060039@marajade.sandelman.ca> This is from the IETF ROLL WG mailing list. Date: Tue, 20 Oct 2009 11:13:59 -0400 Message-Id: <87k4yq85e0.fsf at kelsey-ws.hq.ember.com> From: Richard Kelsey Date: Tue, 20 Oct 2009 10:32:45 -0400 From: Tim Winter To provide some additional background, one of the RFC5548 areas that may require to operate networks on the order of 10^7 nodes are smart metering applications in support of a large utility in a dense urban area. RPL ought to allow a deployment in support of such a large network to dynamically partition itself into smaller independent operating regions, by providing for a `divide and conquer' strategy (some have used a `drainage basin' metaphor). Depending on the specifics of the deployment, implementation, number of LBRs, etc. it should be feasible to cause the partitioning such that each independent region may be operating over a target size, e.g. on the order of 10^3 nodes. Specifically, the ability to provision of LBRs to act as independent DAG roots will allow them to draw the `closest' nodes to them. As nodes affiliate themselves with specific LBR(s), and specific DAGs, they become logically partitioned and may exclude interaction with other neighboring nodes that are members of other unaffiliated DAGs. A large deployment on the order of 10^7 nodes may then logically be viewed as, e.g., ~10^4 DAGs with ~10^3 nodes each. This partitioning is dynamic and autonomous. The electric metering network in Gothenburg, Sweden works this way. They have 250k 802.15.4/ZigBee nodes of 8k are DAG roots ('concentrators' in ZigBee-speak), which averages out to about 32 nodes in each DAG. As an aside, Gothenburg's population is about 500k, so they have one node for every two people. I begin to understand all the interest in this market. There are some more details in this presentation by the Gothenburg utility's project manager: http://www.zigbee.org/imwp/download.asp?ContentID=16104 -Richard Kelsey _______________________________________________ Roll mailing list Roll at ietf.org https://www.ietf.org/mailman/listinfo/roll From mpetach at netflight.com Tue Oct 20 19:08:21 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 20 Oct 2009 16:08:21 -0700 Subject: [arin-ppml] 2009.10.20 ARIN open policy hour notes Message-ID: <63ac96a50910201608v37622d1cm955f79d7e838d4f1@mail.gmail.com> Just in case people remotely were curious, I took notes during today's open policy hour. I'm sure I missed some people's names and notes, but hopefully this will be of help for people not in the room. ^_^; Matt OK, back down to Grand ballroom for the ARIN open policy hour. They fire it off at 1805 hours Pacific time. Preview of draft policies on agenda policy experience report will get moved to Thursday Policy Proposal BoF your time recent list discussions Leslie Nobile, a few items from PPML list, NANOG list, and other places, and will solicit some feedback from the room on those. Anything that we want to bring to the mics? Nothing from anyone so far. Preview first, then BoF proper. Draft policy review 5 on agenda for this week. not for discussion at this BoF please read them, if you haven't already have staff and legal review draft policies have been on public list will be presented at full meeting. Don't talk about them tonight, save it for the list or tomorrow! Policy development process, flow chart are in it as well. 2009-3: Global proposal allocation of IPv4 blocks to RIRs been submitted to all 5 RIRs; must be accepted by all 5 RIRs, and then ICANN board will review and adopt. All 5 RIRs have it; this is the ARIN version. Right now, RIR can go to IANA, show what they use, and they get get more, usually 1 or 2 /8s. Once there's no more IANA /8s in free pool. At that point, RIRs return IPv4 space to IANA when they get it back to build new free pool Once every 6 months, RIR can ask for 1/10th of free pool as allocation. 2009-5: multiple discrete networks allow IPv6 initial and subsequent requests for discrete, independent networks /32 for ISPs, /48s for end users (and larger) 2009-6: Global: IANA policy for allocation of ASN blocks to RIRs. Right now, 2 pools; 16bit and 32bit as one pool gets lower, they can go to IANA and request more of that type. After Jan 1, 2010, all RIRs will be locked into same pool; will have to show usage of all ASNs before getting more. This would extend ability to get ASNs of each type for one more year. Submitted to all 5 RIRs. 2009-7: Open access to IPv6 removes to rules for initial allocation removes requirement to advertise single aggregate allocation remove requirement to be a known ISP in ARIN region or to have plane to make 200 assignments in 5 years. 2009-8: equitable IPv4 runout slows distribution of IPv4 space ISPs that come to ARIN, and that have been members for a year, can request a 12 month supply. This would reduce supply period based on how many available /8s IANA has left. At 20 /8s, goes down to 6 months supply. At 10 /8s, everyone stuck with 3 month need. Sets maximium prefix size based on ARINs free pool; 1/4 of ARIN's free pool, rounded down. Read the summaries, draft policies, staff assessments, etc, come to meetings prepared to discuss them. Now, on to Policy BoF Informal setting presentation of ideas discussion and feedback (5 minutes total) No committments at this time! Going forward your choice: do nothing continue discussions informally take the discussion to PPML submit a policy proposal. So...that's the rules--who has something to talk about? Remote participation is allowed too...but nobody's in the room. Lee Howard, TWC, ARIN board of trustees, the trustees not allowed to propose, so he's just breaking the ice. Some discussion during NANOG portion of week; routing considerations around ARIN policies. Should ARIN policies take into consideration any routing considerations? Dani from PeakWeb The precedent from IPv4 side is that ARIN doesn't guarantee routing; it just does registration services. That's really where it needs to be. We're smarter now, we need to take the language out. Not enough of us were really watching when the 2bit to 4bit ASNs transition happened; we need to start getting involved sooner, and speak up earlier in the process. We need to focus on proper sizing of allocations, and let business determine usage. In IPv4 world, we were trying to deaggregate class Bs...it eventually worked its way out in IPv4 world, it'll be able to work its way out in IPv6 if we let it. Jason Schiller, Verizon; ARIN is chartered to shape policy; and policies will shape routing decisions. If ARIN starts allocating /30s, they may not guarantee routability, but once ARIN starts giving them out, and one ISP routes them, the pressure will be there for everyone to route them. It's useful to be able to take ARIN policy back to help sell best practices inside your company. Jon, Internet society If we're walking in the space of a policy that will be discussed later...the transfer policy was difficult for the panelists to understand; they had to call in lawyers to try to interpret it. That kind of feedback from NANOG panelists doesn't fit with the 3 goals of ARIN. Clear, technically sound, and useful. The routing policy question--obligation of ARIN and other RIRs that they not just conserve scarce resource, but conserve slots in the routing table which is a shared commons, globally. There will be more discussion of economics during the week. The tragedy of the commons is well known, and is well documented; there's economic incentive for each, but if it happens unbounded, the commons get destroyed, and they all die. The global routing table is a global commons; adding to it will be in the interests of every individual network access provider. There is an obligation to preserve slots in the global routing table... Aggregation is a goal in the number resource model, but it's not a criteria. Cathy Aaronson--irony of statement. The aggregate part in statement was to preserve global routing table slots. That was the intent at the time. John Curran, president, CEO of ARIN. The incorporation and bylaws are wide-reaching, and talk about technical coordination, which is very vast. There are things tied to number allocation which are in NRPM, but talk about visibility of information in whois. the ability to abide by NRPM can be used to decide if people get new resources, or get to keep existing resources. If this group wants to govern what goes into the routing table, it can go in. But the community needs to decide if that's a space we get involved in adding and enforcing via the NRPM. We can put constraints on routing in NRPM, like we do with whois visibility. It's up to us. Ed Kern--he'd love to have it in the policy to make Jason to route all the /30s. :D The v6 allocation was BCP in the policy strategy. It should be taken out now, and moved to a BCP status. IETF and ITU aren't the right forums for this. Leo Bicknell, ARIN advisory council we have the discussions repeatedly. The numbers agency and network operators exist in symbiotic relationship; the numbers are needed for routing, and without routing, there's no need for number resource registration. As with any symbiotic relationship, both parties need to understand the other's needs; both sides need to keep the other healthy. ARIN community needs to understand the limitations of routers and policies that operators are using. It is not useful for ARIN community to dictate to operators how to configure their devices...in general. Operators need to understand implications of policy on a 50 year span, not just next year. Provide useful information on when routers are likely to fall over back to policy team. More information sharing, and less dictating needs to happen. Dave Farmer, ARIN AC. Everyone needs to chill out just a little bit. It's your routers, your policies, yes. But you have to let ARIN know what policies make routing policies possible. It wouldn't be possible to be able to take /48s for critical infrastructure if it didn't come from one little corner. "For this piece of stuff, this is what you can do" ARIN needs to assign numbers in a reasonable fashion to allow operators to make decisions around the numbers. The ability we have to write policies stems from ARIN's allocations of addresses in a coherent fashion. Cathy again. She's super-excited that people noticed the IPv6 allocation policy, since it's been there for 10 years! finally, people are looking! When they went from /19 to /20, they put notes in saying they were going to look at routing tables, and retract if it caused too much pain. Lee Howard--delighted with feedback to that topic of conversation. People need to send email indicating the words to arin.ppml at arin.net; if you don't know how to write the words, they will help you write the words. Their job is to help you write clear, concise, useful words. And vote for him on Friday! New topic from Cathy Something for ARIN to answer; with v6 allocations, they are not being sparsely allocated, they are consecutively being allocated. Is this on purpose? A: yes, it's on purpose. No sparse allocation in v6. Only 1 RIR is doing sparse, that's APNIC. They do need to discuss it, John is nodding, they will discuss it but have not done it yet. Doni again Question about if ARIN wants to move from consecutive to sparse, is that policy based, or can ARIN just move to do that internally? A: ARIN can do that internally; Dave Conrad notes that the initial goal was to use sparse allocation, so it is a goal, but also a work in progress. Leah Roberts, ARIN AC Increment between them could be bumped up before moving to sparse allocations; could it be moved up a few bits to a nibble boundry at least? /29 doesn't map very well. Anything else from community members, policy-wise? Martin Hannigan Recovery; should we revisit it today? it's becoming aparent there will be 2 internets out there; you'll need both addresses for quite some time. There will be a market for v4 addresses; it would be better to see it be rational and fair. There's operators, policy, and there are shareholders as well. Some want to be good, but others have to keep the economy going, and get our paycheck. We'll probably see /28s on the internet so v4 can still 'grow' while the move to v6 trundles along. How do we manage /8s locally, not just under global policy. Scott Liebrand There have been several policies to take baby steps along the path--what suggestions does he have for moving in that direction? Martin replies: Bite off the low hanging fruit--just define what it is. Stragglers, things out there that aren't in routing table, no valid contacts, etc. We've had a mishmash, but no coherent plan. This needs to not be tied into other policies. Needs to strictly be about reclamation. Start low, and then move to high stuff. Lee Howard you said recovery a few times; do you mean recovery of IPv4 unused or underused space? Unused is very different from underused. We don't have any policy about underuse of space; you need to have minimal use to get *more* space. NRPR section 12--John Curran notes that you should read the manual; he looks at it many times, and comes away shaking. Policy provides ARIN the necessary tool to do a few things: it's up to ARIN staff organization to use that policy; they use it now for addresses that are not legitimately held by anyone at all. They can prevent unheld resources from being held by a party. If that's low hanging fruit, as it is brought to ARIN, ARIN is attempting to make sure they don't get legitimized by ARIN updating records. But that's reactive based on suspicious requests coming in. Other case is resources that aren't being used, but are legitimately held, even if it's not being used, never routed, etc. Those unused or heavily underutilized resources are *not* being touched right now. They have a legacy RSA agreement, that once signed, prevents ARIN from ever doing anything with that block. So, no legitimate holder they can catch. But the ones with legitimate holders, they cannnot both offer a legacy RSA, and simultaneously move against those resources. To move against resources, we need to resolve that against legacy RSA agreements. 300 RSA signers, but that covers more than 25% of the legacy space; so there's more and more coverage of that space; once signed, they're part of the system, and by contract, they is no method to do reclamation on that space. If we're going to change the legacy RSA, he needs to know now! Chris Grundeman, TWC There was a policy after last meeting, 2008-7, enacted after last meeting, the intention was to help identify the fallow space. The tool will be there to help identify it for reclamation. Owen DeLong, HE.net section 12 para 5 attempts to reconcile issues; ARIN can reclaim space allocated by ARIN for under use when legacy RSA is signed. Leo Bicknell--the legacy space is mired in issues. non-legacy space, RSA states that if ARIN believes the space is not being used for the original purpose, you may need to re-justify it, and if it cannot be justified, ARIN may reclaim it. John: they go after such resources *when* they come to ARIN and attention is drawn to them. They have reviewed and revoked resources based on that, but they are not going out and looking for space that would fall under those terms. Most reporting to ARIN is under fraud reporting process. It only is used if people feel that fraudulent claims are made to ARIN in the application process; any other legal issues are *not* moved on. John, ISOC Low hanging fruit may still be on tree because it is rotten. APNIC talks about audit trails for space that is recovered. If you reallocate it to someone, and it turns it is ACL'd off or blacklisted for places they need to reach, they are not better off for getting the space. When space is recovered, can its history go with the block, so that potential recipients know what they are getting. Leslie Nobile notes that space reclaimed through various means is held for 1 full year, and they use RBLs, checking 140 RBLs and lists, and noting that it has been fallow for a year; they attempt to ensure they are issuing clean space as much as possible. they are very aware of this, it's not a policy, but it's an internal proceedure. Martin policies and procedures are great, perhaps if ARIN could wave the flag and let us know, that would be great. There's some low-hanging fruit that isn't caught by the policies; if you're the POC, and the company went bankrupt, it's really easy for POC to just hold onto the space. He thinks there's some low hanging fruit we may be stepped on. Also, legacy /8s getting returned need a local, non global policy to handle them. XXX from Jamaica, covers issues around ICT, learning a lot at ARIN meeting. Reading mission statement up on wall, a question to the staff and community. How do you draw line between a watchdog or deal with issues, when one main activity is to facilitate the advancement of Internet while outreach and education is a primary goal. It seems the Internet is such a huge monster, it needs this broad-based consensus at all times. The issues are overwhelming, the v4 to v6 migration needs even more education and outreach around it. She's learning a lot, and hopes ARIN can help educate even more about how these issues can be addressed and handled in the Carribean region. We're out of time; it's a few minutes after seven. Beer and pizza party up in rotunda, first elevator on the left, runs from 7pm to 9pm. Thanks to everyone who brought questions to the microphone today!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Melody_Palmer at heart-nta.org Tue Oct 20 23:00:40 2009 From: Melody_Palmer at heart-nta.org (Melody_Palmer at heart-nta.org) Date: Tue, 20 Oct 2009 22:00:40 -0500 Subject: [arin-ppml] AUTO: Melody Palmer is out of the office. (returning Mon 10/26/2009) Message-ID: I am out of the office from Mon 10/19/2009 until Mon 10/26/2009. I will respond to your message promptly when I return. Note: This is an automated response to your message "ARIN-PPML Digest, Vol 52, Issue 32" sent on 20/10/2009 06:06:46 PM. This is the only notification you will receive while this person is away. From sethm at rollernet.us Wed Oct 21 01:01:54 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Oct 2009 22:01:54 -0700 Subject: [arin-ppml] AUTO: Melody Palmer is out of the office. (returning Mon 10/26/2009) In-Reply-To: References: Message-ID: <4ADE95C2.8030901@rollernet.us> Melody_Palmer at heart-nta.org wrote: > I am out of the office from Mon 10/19/2009 until Mon 10/26/2009. > This is the only notification you will receive while this person is away. No, actually it's the second. To the list. Stop. ~Seth From info at arin.net Wed Oct 21 09:03:56 2009 From: info at arin.net (Member Services) Date: Wed, 21 Oct 2009 09:03:56 -0400 Subject: [arin-ppml] ARIN XXIV Now Underway Message-ID: <4ADF06BC.6030404@arin.net> The ARIN XXIV Public Policy and Members Meeting begins today in Dearborn, Michigan. For those in the community who are unable to be in Dearborn, ARIN is offering a webcast and live transcript of the proceedings. The times of the broadcast are as follows: Public Policy Meeting (Policy and technical discussions) Wednesday, 21 October 9AM - 5PM Thursday, 22 October 9AM - 5PM Members Meeting (ARIN reports, Board of Trustees and Advisory Council reports) Friday, 23 October 9AM - 12PM All times are Eastern Daylight Time (EDT), (UTC/GMT -4 hours) Note that all candidate speeches will be given on Wednesday, 21 October. The NRO NC candidate speeches will begin at 11 AM and ARIN Board and AC candidate speeches will begin at 2PM. Archives of these speeches will be posted on the ARIN website by Thursday, 22 October. You may register as a remote participant at any time throughout the meeting, and registered remote participants are invited to join in the meeting chat to vote in straw polls and submit questions or comments during the times listed above. Pre-register your Jabber Identifier (JID) to have full chat room access from the start of the meeting. You can register a JID at any time, but we will only be adding new participants during scheduled breaks in the meeting. The full agenda is available at: https://www.arin.net/ARIN-XXIV/agenda.html You can also follow us on Twitter @TeamARIN for schedule updates. Be sure to use the #arin24 tag for your own tweets about the meeting. For details about how to connect to the webcast, chat, and live transcript, or to refer to the Remote Participation Acceptable Use Policy, please see: http://www.arin.net/ARIN-XXIV/remote.html Regards, Member Services American Registry for Internet Numbers (ARIN) From mpetach at netflight.com Wed Oct 21 12:03:38 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 21 Oct 2009 09:03:38 -0700 Subject: [arin-ppml] 2009.10.21 ARIN 24 first day morning notes Message-ID: <63ac96a50910210903w72d2f940me7dc40df6091dada@mail.gmail.com> For those following remotely, here's some notes from the first half of the first day of ARIN 24. Matt 2009.10.21 ARIN Wednesday notes John Curran calls the ARIN 24 meeting to order at 1100 hours Eastern Time. Board of Trustees up at the desk. John, President and CEO Scott Bradner, Treasurer Timothy Denton, Lee Howard Advisory Council, most are in the room NRO number council is in the room RIR calleagues are in the room as well. ARIN management team is mostly here. Fellowship recipients are here learning lessons to take back to their community. The Postel Network Operator's Scholar is here too. First timer's lunch was yesterday Daily survey http://www.arin.net/ARIN-XXIV/survey/ submit between 8am and 6pm EDT Today's winner, prize will get emailed. Wesley George from Sprint wins today Welcome remote participants They do count for remote show of hands as well! You should have your participant's packet as well, all policies are listed in it as well. Your own NRPM is included in it as well. Election info is included as well. 179 attendees, 8 canada, 1 carribbean, remote 26, 107 joint NANOG/ARIN participants Get Social! Follow the meeting on Twitter--#arin24 TeamARIN on facebook /user/TeamARIN on youtube. Merit and Arbor, the sponsors, United Layer, transportation sponsors. Chair moderates discussion of all drafts. Please clearly state name and affiliation each time you are recognized at the mic Please, speak once at mic, and let all others go first before returning to mic. AGENDA PDP report Intenet numbers report Candidate speeches board advisory council drafts on deck today: 2009-6 --global allocation policy 2009-7 --open access to v6 John has a little presentation on transfer policy, policy 2009-1 This was an epic event. Board adopted 2008-6, emergency transfer policy for IPv4 addresses Board invoked a special policy action of the PDP to revise 2008-6 prior to its implementation PDP allows for special action allows for temporary creation, modification, or suspension of the policy. board notified ppml of the emergency action So 2009-1 was adopted in May Added requirement for recipient to be in ARIN region, and removed sunset clause Last part of PDP special policy actions requires presentation at the next public policy meeting after adoption Leo Bicknell, ISC Has anyone used the transfer policy? Yes, 2 completed, and 1 pending under policy It's visible in the actions, but not broken out separately. ARIN Elections 2009 ARIN region NRO number council Judd Lewis, member services The details 1 open seat, 3 year term, starts Jan 2010 ARIN DMR, registered NANOG47 attendees, and registered ARIN XXIV attendees Vote early! https://www.arin.net/app/election/ what email address should you use when voting today? Use DMR email if you have one otherwise, use email you signed up for the meeting with. Voting closes for everyone today at 5pm. You can stop by the election helpdesk if you have any issues with voting. Back to John to introduce candidates. Babak Pasdar statement is read by John, and can be found in the election packet and online. Louie Lee will read his own statement. Can multiple DMR accounts, can they be merged? Regional PDP report is next. Einar Bolan proposal of topics at the 5 RIRs 2 IPv4, 2 IPv6, 0 directory services, 1 ASNs, 0 Other for ARIN discussion table showing what status of different proposals is in each region. There's a table with links to the different policies in each region being discussed. Many are around IPv4 allocations in the face of runout, IPv6 allocation policies. http://www.nro.org/documents/index.html comparies policies in each region that are in process. Next up is Internet Number Resource Status Report Leslie Nobile is up next. IPv4 and IPv6 and AS number stats This goes back to 1999, 10 years of stats. IANA reserved space, 26 /8s remaining 35 /8s in tech community, not available central registry, legacy space, 91 /8s handed out prior to RIRs. 104 /8s for the other 5 RIRs since inception in 2008, a bit over 12 /8's allocated, with APNIC doing more than any other region. ASN assignments, ARIN slightly more than RIPE Total IPv6 space slides 506 /12s with IANA in reserve each RIRs get /12s Prior to that, /23s from IANA, 3 for special purpose Allocations for IPv6, RIPE is far above everyone else. RIPE is 1600 to ARIN 700. In terms of /32s, RIPE allocated almost 34,000 /32s ARIN about 15,000 /32s Links to RIR statistics Dave Barger, ATT Good information about history; are there plans to augment data with IPv4 exhaustion in this report? John doesn't maintain an IPv4 depletion forecast. There are sites that do it, Geoff Huston does that at APNIC. Do we really want to duplicate efforts? Is there value in doing a greenfield effort in that space? ATT responds--they use Geoff Huston's site for IPv6 efforts. But John published a report saying that we'll run out in 2 years. So, there's two sources of data; which one do they believe? They're more apt to believe ARIN. Where does responsibility reside? John--it would be a tragedy if they were ready too soon; but being a forecast, the number will move from time to time. Very soon, all RIRs coordinating through NRO will announce we are down to less than 10% of the space remaining. Perhaps an updated letter may be forthcoming. ATT--if Geoff's site is considered most accurate, perhaps send out note indicating that. Jason Schiller, Verizon Would like to see ARIN publish a number for runout, it would be good to have it be their *own* number, even if it's close to Tony or Geoff's number. A live number that gets updated perhaps monthly on the website. Joe Maimon--if all large allocations go to providers, is it known when they will be coming back to the well? John knows when everyone got their last block, and can build a sawtooth demand on when they are likely to come back for their next request based on history If you project that forward, you get a model that looks a lot like Geoff's data. Matt, Affilias ASN stats include 4byte; are there stats on how many people keep them? 278 4byte requsts, 49 issued, 11 active, rest have all been returned as unusable. Mystery person at mic says: If there were multiple sources, having a range of those numbers would show there's risk of analysis, might get people moving more quickly. Aaron Hughes--few different sources of data; live counter sites showing reclaimed and remaing data; others do averages on data. This is a moving date, and will change. Longer-term predictions based on chief scientists looking at models. Do we want to hire a chief scientist to do this, knowing that every time we make a policy decision, we affect the data for runout predictions? Mark McFadden, IANA update IANA pool's status Special addresses mechanism for allocating /8s introduction of reverse DNS self-management system IANA Free pool status 26 /8s unicast IPv4, 5 are reserved for end-state. Rate of IANA allocation rate to RIRs website lets you sort by date to see year by year how many are being allocated, and how fast it is accelerated. 8 16-bit ASN blocks remaining special addresses thanks to APNIC for providing 2 new /24s for documentation 198.51.100.0/24 203.0.113.0/24 draft-iana-ipv4-examples Throw some back 14.0.0.0/8 was recovered with x.25 operator community in 2007 That's the only /8 recovered by IANA in that way Been working on ARIN and IESG for smaller block recovery 128.66.0.0/16 192.128.0.0/17 192.0.48.0/18 etc. allocation scheme remaining /8s split into 2 pools based on Duane Wessels 2008 research RIRs get 1 /8 from each pool, when justified a "dirty" and "clean" pool selection mechanism is random and based on RFC 2777 2 less used /8s set aside for each of AfriNIC and LACNIC (clean pool)--their rate of request is so much lower. Introduce reverse DNS self management system. security based on HTTPS transport and x.509 PKI allows in-addr.arpa and ip6.arpa to be DNSSec signed allows RIRs to manage their delegations in real time. IDN ccTLD Fast Track Launch (intenationalized domain names in ccTLD) launch proposed for Nov 16 requests go through the fast track evaluation and then the regular IANA delegation process expect 50-60 requests for TLDs representing 15-20 languages. IANA business excellence 2009-2011 strategic plan includes "strive for excellence in core operations" as a priority. insanely long link included. introducing a work program to make sure there is a systematic, measturable, sustainable framework for improvement. Following a European model, but very similar to others people have heard of. Dec 16, document to be completed Jan 13, self assessment published 2009 Communication plan, aiming to take advantage of new communication methods, using new tools like what ARIN talked about this morning. IANA news posted to twitter http://www.twitter.com/theiana low volume, but good way to keep up with their work. Bill Dart, ARIN AC You mentioned there are 26 /8s available in the free pool, 5 set aside by policy for RIR at endgame. And 2 /8s reserved for LACNIC and AfriNIC, so is that 7 total? The 2 separate for LACNIC and AfriNIC are within the current clean pool within the 21 still remaining. Martin Hannigan Why do LACNIC and AfriNIC need clean space? Why can't they work with the rest of us to clean up the mess? The rate they use addresses is so slow, they might otherwise not ever get clean space. Paul Wilson, APNIC cleaning up mess is easier said than done. Can IANA do more to clean before handing over the addresses from the pool? To ask RIR outside of this part of world to take action from their part of the world against activities happening in this part of the world is asking a lot. IANA, as custodian of the blocks probably has the most ability to take action sooner rather than later. IANA would certainly take action if it were sure to be effective in some way. Yes, different regions have different abilities to affect the issue, certainly. An effective plan is needed for what IANA could do to address the problem; would it be a letter writing campaign, and who would it be sent to? He's very open to suggestions on what can be done to help reduce free pool abuse. OwenDeLong, HE.net, ARIN AC We first need to divide dirty pool into 2 categories; internal users, where we only see it via leaked DNS queries; and really dirty, where it's actually visible on the Internet. Internal issues are harder to deal with, but external leakage you can hit the upstream. David Williamson, tellme The final 5 blocks, have they been identified? NO which pool is larger? Dirty pool is larger LUNCH TIME! Bistro. AC topic tables -- choose your table based on interests. NRO voting closes at 5pm. Take valuables with you, there is no security in here during lunch! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Wed Oct 21 15:00:49 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Wed, 21 Oct 2009 15:00:49 -0400 Subject: [arin-ppml] ARIN-Meeting Message-ID: <8aeeaff60910211200h38e444o27ad2cbb4a1b85@mail.gmail.com> Let me wish all the Candidates for both the AC and the Board Good luck, I am participating in a local ICT event here in the Caribbean now and beyond the present Arin Meeting dates.Rudi Daniel > 3. ARIN XXIV Now Underway (Member Services) > > > -- Rudi Daniel ICT 4 dev Consultant http://www.svgpso.org http://danielcharles.weebly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Wed Oct 21 15:38:22 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 21 Oct 2009 13:38:22 -0600 Subject: [arin-ppml] ARIN-Meeting In-Reply-To: <8aeeaff60910211200h38e444o27ad2cbb4a1b85@mail.gmail.com> References: <8aeeaff60910211200h38e444o27ad2cbb4a1b85@mail.gmail.com> Message-ID: <443de7ad0910211238j32acddf8ibedbdaee388864ea@mail.gmail.com> On Wed, Oct 21, 2009 at 13:00, RudOlph Daniel wrote: > Let me ?wish all the Candidates ?for both the AC and the Board Good luck, I > am participating in a local ICT event here in the Caribbean now and beyond > the present Arin Meeting dates. > Rudi Daniel Thanks Rudi and good luck to you as well! ~Chris > >> >> ? 3. ARIN XXIV Now Underway (Member Services) >> >> > > > > -- > Rudi Daniel > ICT 4 dev Consultant > http://www.svgpso.org > http://danielcharles.weebly.com > > > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From bicknell at ufp.org Wed Oct 21 16:48:32 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 21 Oct 2009 13:48:32 -0700 Subject: [arin-ppml] Alternative to 2009-7. Message-ID: <20091021204832.GA24881@ussenterprise.ufp.org> As discussed today, the current IPv6 policy uses a criteria of "200 sites" as the threshold to receive IPv6 address space. Also polled was a 100 site requirement. Looking back at the IPv4 requirements (which are at https://www.arin.net/policy/nrpm.html#four22), there are basically two cases. Single Homed: You must show efficient utilization (80%) of a /20 from your upstream. A /20 is 4096 IP's, and 80% of that is 3277 IP's in use. Multi Homed: For a /22 (the smallest) you must show efficient utilization of a /23, or 512 IP's, and 80% of that would be 410 IP's in use. To that end, I would suggest replacing a requirement for 200 sites with a requirement that: - If single homed, demonstrate the ISP will connect at least 3277 devices. - If multi homed, demonstrate the ISP will connect at least 410 devices. The idea is to have essentially the same requirement for a brand new, IPv6 only ISP as there is today for a brand new IPv4 only ISP. This would retain the "be an existing ISP" as a simpler mechanism for someone who is already an IPv4 ISP to transition to dual-stack or IPv6 only. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From cgrundemann at gmail.com Wed Oct 21 16:58:43 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 21 Oct 2009 14:58:43 -0600 Subject: [arin-ppml] Alternative to 2009-7. In-Reply-To: <20091021204832.GA24881@ussenterprise.ufp.org> References: <20091021204832.GA24881@ussenterprise.ufp.org> Message-ID: <443de7ad0910211358o49a0de58w9ea16bf2a6698735@mail.gmail.com> On Wed, Oct 21, 2009 at 14:48, Leo Bicknell wrote: > > As discussed today, the current IPv6 policy uses a criteria of "200 > sites" as the threshold to receive IPv6 address space. ?Also polled > was a 100 site requirement. > > Looking back at the IPv4 requirements (which are at > https://www.arin.net/policy/nrpm.html#four22), there are basically > two cases. > > Single Homed: > > ?You must show efficient utilization (80%) of a /20 from your upstream. > ?A /20 is 4096 IP's, and 80% of that is 3277 IP's in use. > > Multi Homed: > > ?For a /22 (the smallest) you must show efficient utilization of a /23, > ?or 512 IP's, and 80% of that would be 410 IP's in use. > > To that end, I would suggest replacing a requirement for 200 sites > with a requirement that: > > ?- If single homed, demonstrate the ISP will connect at least 3277 > ? devices. > ?- If multi homed, demonstrate the ISP will connect at least 410 > ? devices. > > The idea is to have essentially the same requirement for a brand > new, IPv6 only ISP as there is today for a brand new IPv4 only ISP. > This would retain the "be an existing ISP" as a simpler mechanism > for someone who is already an IPv4 ISP to transition to dual-stack > or IPv6 only. Very quickly: What would the requirement be if they are a new org, building an IPv6 only network? I think that the current ISP requirement is satisfactory if it is implemented by ARIN staff as written. I have a hard time accepting that you are an ISP if you will never have over 200 customers. Perhaps what we need to look at is the end-user requirements...? ~Chris > > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From owen at delong.com Wed Oct 21 17:17:56 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Oct 2009 14:17:56 -0700 Subject: [arin-ppml] Alternative to 2009-7. In-Reply-To: <443de7ad0910211358o49a0de58w9ea16bf2a6698735@mail.gmail.com> References: <20091021204832.GA24881@ussenterprise.ufp.org> <443de7ad0910211358o49a0de58w9ea16bf2a6698735@mail.gmail.com> Message-ID: > > I think that the current ISP requirement is satisfactory if it is > implemented by ARIN staff as written. I have a hard time accepting > that you are an ISP if you will never have over 200 customers. > Perhaps what we need to look at is the end-user requirements...? > There are many ISPs that are small regional business-to-business providers that have less than 200 customers and have /20s or larger for the number of hosts their customers have. Is there any reason to believe it is not possible for such a business to start up in IPv6 going forward? Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpetach at netflight.com Wed Oct 21 17:36:39 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 21 Oct 2009 14:36:39 -0700 Subject: [arin-ppml] 2009.10.21 ARIN 24 meeting notes, second half Message-ID: <63ac96a50910211436q6bd871e3yb0fc5c46aca0ca44@mail.gmail.com> Here's my notes from the second half of today. Apologies for the delay, I've been wrestling with trying to get the daily survey link to work, but had no luck; no love for firefox or ie on my laptop. So, enough of trying to get that working, here's the notes. ^_^;; Matt 2009.10.21 ARIN 24 notes, day 1, second half ARIN 24 resumes after lunch John Curran welcomes everyone back at 1332 hours Eastern time. We have Advisory Council elections... Oh, but we talk about policy 2009-6 first. IANA policy for allocation of ASN blocks. May 29, 2009, originally proposed. In discussions in all regions Allows for one more year for RIRs to make separate requests for 16bit and 32-bit ASNs. Treat them separately until Jan 1, 2011. No liability risk or staff issue, minimal impact for implementation. Assessments available online. 12 posts by 5 people, 3 in favour, none against. Andrew de la Haye will present on it. Currently, as of Jan 1 2010, IANA will treat it as an undifferentiated pool. Currently, 125 32-bit ASNs. problems: 45% have hardware / software problems 22% peering partners do not accept 32-bit ASNs Current rate of ASN deployment will run out around 2012-2014. Current policy written when worries of earlier runout seemed imminent. 3 options do nothing extend by a year (cons, less incentive to get 32-bit working, we'll end up here again in 1 year) or just run out of 16-bit. This pushes for option 2; keep differentiated pool for 1 more year while we keep pushing for 4-byte. It's under discussion or in last call in all regions at this point. No questions about it. Scott Liebrand, Internap, he supports this proposal; we have code, we're moving forward, but it still needs a bit more fixing. Leo Bicknell, ISC, he supports the proposal; the appropriate place is for LIR to put pressure for this on vendors. He wants it extended for forever, and thinks we'll be back here in a year. But he'll support it as it is. Owen DeLong supports it; he doesn't think the year timeframe matters, they won't last much beyond that anyhow. This policy helps, RIR policies he proposed didn't help much, esp. in terms of staff efforts involved. Any other comments, discussion, proposal. Discussion closes. People and room to do show of hands in room and remotely. One show of hands; in favour, and then opposed. In Favour: 72 Against: Zero 135 participants Judd describes election procedures for board of trustees and advisory council Today at 3pm, after the candidate speeches, voting will open, and will stay open for 10 days. Candidate speeches will be available online as well. Select 3 people for board of trustees, 5 for Advisory Council Only the 1 DMR may vote in these elections; they were established on October 7th. In good standing with ARIN, and mail on file with email domain from personal account registering for it. Voting procedures https://www.arin.net/app/election/ register (or log in) vote CONFIRM your vote. Make sure you confirm it, and don't just close your browser! Advisory Council Candidate speeches (text or video available on the voting site) [notes in brackets are for jogging my memory, and are not to be taken as any type of commentary on or about any particular candidate] Mark Bayliss John Brown Rudolf Daniel (video presentation) Steve Feldman Wes George -- [Sprint v6 testbed, and working on v6 deployment. No specific agenda.] Chris Grundemann Stacy Hughes Kevin Hunt Mark Johnson Ed Kern--[platform is to prevent scope creep in ARIN; the controls should remain with the operators] Chris Morrow--[Google now, UUnet before] Bill Sandiford Christopher Savage Heather Schiller Rob Seastrom Scott Weeks Tom Zeller Next up, Board of Trustees candidates: Paul Anderson Scott Bradner Lee Howard Aaron Hughes Frederick Silny (video) OK, that completes candidate speeches. So, Andy Newton will do the ARIN templates presentation early. Cathy comes to the mic. A little side discussion about people working together to come up with more streamlined process to clean blocks to give into free pool; we'll need to shorten the timeline to less than a year. What do people think, and who can work with her on it? Apparently there's a process for domain names that can be a starting point. John volunteers Leslie Nobile. Eric Kline--domain names have a process for cleaning them, it takes about five days to clean up; he'd like to try to develop process to do that with IP names. Chris Morrow--Google. ARIN publishes the list of blocks that get reclaimed; the current blacklist operators could follow the RSS feeds; but most of them are lazy. It's a pain to try to get them take action. It could be an exercise in futility trying to push it. Now we have Andy Newton doing presentation on retiring ARIN email templates. Consultation sent to arin-consult at arin.net on sept 25th. feedback on when and if to retire email templates (NOT SWIP--just POC contacts, orgIDs, etc) Consultation is about templates not backed by an automated system. ORG/POC templates requests for new resources non-automated ARIN seldom processes them automatically likelihood for human email exchange not conducive for automation Email is insecure 234,246 POCs 19 use X.509 48 use PGP adoption of security measures is very low SPAM clogs inboxes, filters catch replies non-interactive non-intuitive Nothing is for Free there are costs to continuing dual operations maintenance training/support Engineering time to fix bugs ops staff to keep systems running continued management of certificate authority security practices key rollovers Training and support help desk needs to understand both systems training methods and docs need to list both for new users, email templates add to array of confusion New development conflicts slows data model changes new systems must accomodate legacy behaviour legacy systems do not know about newer systems IRR wall inflight X tickets considerably slows new development Adoption curve for POC curve; web pretty much always higher Online experience immediate feedback through web forms new X tickets can be tracked by users Online help. Online reporting, users can view their related records and resources Security ARIN Online requires password authentication over HTTPS Mitigates hostile POC takeovers POCS lead to ORGs which then lead to the keys to the kingdom, resources What should we do? should new development be slowed by legacy systems? Given that users are switching to ARIN Online, should users who wish Give feedback arin-consult at arin.net Aaron Hughes--he sent objection about SWIPs. he tried to log in, and got error about the system being down. This has to be 100% reliable in order for this to be acceptable! A: Well, email isn't 100% reliable either, and they have to work with helping people on their templates. OK, so templates can't be phased out until track record is more reliable. Joe Mamon likes paper trail; he would like email to be kept active until disuse shows it ready for retirement. Martin Hannigan uses this and only this to handle records; he likes the export function to do audits of his space. It's likely SMTP had issues for Aaron that were transparent to him, if he'd checked his queues. Concern about fees being needed to Peter from Cablevision--ran into issue with signing POCs to ORG-IDs--will that process be functionally available? A: That feature is now active on website. Arcadia speaker at mic--people still use email system for a reason; make the new system usable so people have no reason to use email system. Leo Bicknell applauds new system, and thinks that time to deprecate email when statistics show that users have moved to new system, and have largely moved off the email system. Joe, comment--also possibility that unsecured templates could be deprecated, and only PGP or X.509 be accepted. John asks if there's reliable, stable ARIN Online with widespread adoption, would they still need to keep the email system around? Scott Liebrand, Internap--early comments are in line with what he was going after. We need a paper trail through the online system; don't make everything hostage to web internal system; provide copy to people at each transaction. Rob Seastrom--how adopted is widely adopted and how much time would you give it? Substantial outreach time is needed to let the community know that we will be phasing a mode of access out. The number to start with should be single digit number of years. Owen DeLong, he.net, doesn't feel that retiring the templates is valuable; it's just another way to get data into system; he would propose the system should be able to take templates in, and be able to process them into the new system as a parallel input. Scott Bradner says we need to watch the numbers; if people are still using it, giving an arbitrary deadline will annoy people. David Farmer, U of Minn--a suggestion from cyberspace that we deprecate insecure templates. Let's do that, and raise the security of the system as a whole, and may be the way to thump the system. Aaron Hughes--one quite useful way to promote webservice is to add autoresponder at top of emails listing the URL for the new service, alerting them of the new system. Rob Seastrom notes it won't get to everyone, even though it's a great idea. And at the top, note that they're using a deprecated system that will be going away eventually. Stan Barber, ThePlanet--Would there be programmatic interfaces to this, like XML? For ORGs and POCs. A: nothing on the roadmap about doing those. At last meeting, they talked about SWIP templates, and decided they'd have to do at least that. They have some ideas, they might be able to extend to regular POC and ORG forms. Being able to create ORGs and POCs for customers would be good. Kelly, utah edu network. What about server maintenance, full redundancy, downtime, fault tolerance, etc. email has store-and-forward to deal with service interruptions. Kevin Oberman, ESnet--does ARIN website meet ADA section 508? A: Yes, it does, they have an external agency that helps with testing and verifying that. Now it's breaktime!! Info center up there, meet staff, watch videos, help desks are open, billing helpdesk is available by appointment, and don't forget to vote, it closes at 5pm for NRO!! For DMRs, if you're using same email, you'll see all entries under that domain on same voting page. John Curran starts us up after break at 1532 hours Pacific time. Mark Kosters is up next to talk about LAME testing and next steps. ARIN has been doing LAME DNS testing for some time now. Lame delegation process delegations tested daily until test good or removed. If still lame after 30 consecutive days of testing, POCs notified If still lame 30 days after initial notification, POCs notified again. If still lame another 30 days after that, delegation is analyzed manually, nameservers stripped if delegation determine to be wrong LAME: no A record for name server not responsive (times out) doesn't think it's authoritative for reverse zone (no A bit) no SOA record for reverse zone Leslie provided following report at ARIN 22 problems observed--no clear way of detecting a lame delegation potential legal liability operationally significant time spent on development, notification, and followup Service issues with current lame system turning off working delegations delegations in dns for a /16 when they have a /19 incorrectly configured DNS servers substantial customer support John challenged him to come up with a better way to define lame. 3 tests: Issue an SOA query for the delegation; if server responds, delegation is good. Note that AA bit doesn't have to be set on the response If that fails, fill out the dotted quad for the delegation, issue a PTR request; if the AA bit is set, the delegation is good. If test 2 fails, provide 3 random PTR queries for dotted quads that reside in the delegation; if any of three tests gets an answer, the delegation is good; note AA bit does not need to be set Consensus--is relaxed algorithm worthy? Leo Bicknell--ISC; comments in 2 directions. this is hard to define, it would be useful for ARIN to actually define what they *expect* of people who run nameservers to. It is much easier to tell them they were removed due to failing tests, if we first explicitly list what their requirements are for running a DNS server. Also, people throw into lame 2 problem. LAME--down the tree server replied with a reply that the up-the-tree server didn't agree with. But that's predecated on a response. Servers that are non-responsive (missing) is a totally different problem, and should be addressed differently. The non-response problem could be an issue with ARIN routing, the internet at large, etc. Some dude at back mic talked about not liking point 3, as during a transition, the response coming back will be from an unexpected server. Would be good to have a tool on website so that people can perform self-test to make sure that their DNS server is working properly. A: If you do transfer, you update your NS set first for it; so people in that part of the tree should still go to the right servers. Oh, he was talking about the reverse zone, in case your upstream still has records for your /19 within the /16. What is TTL of delegation from ARIN to space holder? 2 days? That could cause operational issues for email holders, for example. Center front, Andrew--if there's an org that considers their blocks private, don't allow external queries, but it works fine on the inside? A: some entitities do have internal blocks, and they flag those delegations; the pain point they try to address is ones visible to the external internet. Leo Bicknell--ISC--curious, thinking forward a few days; reverse zone DNSSec signed, will this check DS in parent vs child, and if mismatches there would count as lame? A: good point, but let's solve this first. Q: in that case, before the reverse zones are signed, ARIN should publish the rules for DS keys in a zone, and if action will be taken if DS keys are out of synch. At least one key must validate signatures for validating servers to work; should cases of no keys matching be considered LAME or not? Define it! David Farmer, U of Minn, the changes being proposed are reasonable, need to think about them a little longer; suggestions for process. This might be something we work with RIR brethern, and put an informational RFC, or a BCP document. A: definitely, we'd like to expose this to the other RIRs, to get more people aware of it. But we want to get it working within ARIN community first, definitely. Not everybody's day job here is working with DNS; mostly people here are router people. Might be good to get people with DNS as they day job. Final comment, OwenDeLong, He.net. He'd like to not redefine LAME; he does like these as criteria for what gets removed or not removed from the zone file, and publishing these as rules for people to follow. DNSSec is likely to force this issue along as well. Will this be done for ip6.arpa as well? Will be thinking about it. Draft policy 2009-7, open access to IPv6. Proposed 29 May 2009, draft 31 Aug 2009, under discussion in other registries. Removes requirement to advertise the single aggregate, and removes requirement to be ISP in ARIN region. legal risk; could encourage fraud. staff concerns; leaves only qualification to be an ISP to get space. Could be unfair to end sites, which would need to justify a /48, but could easily get a /32. Excerpts from PPML discussions are citing. Now over to Cathy to present. This was a very old policy, written a very long time ago. She started rewriting the policy for the Carribbean region, and then thought it might be good to apply to everyone. Most regions changed original language anyhow early on. Policy statements removes the "advertising single aggregate" and removes "200 site" requirement. Pros: promotes IPv6 adoption facilitates innovation and progress currently can't announce more specifics for traffic engineering current policy doesn't allow for more specifics for anycast current policy doesn't allow for more specifics to fight a hijacked /32. Cons: routing table growth Anyone want to say anything. Marla from FT. She wants to take the /32 aggregate out, that part doesn't belong. She isn't sure the 200 part should be taken out, as per the legal advisory about the abuse concerns. Aaron Hughes; looking for clarification from legal on this; is same text provided for v4 space? This seems to protect resources from people lying? wouldn't v4 need similar protection language? A: Steve said not fatally flawed... He understands goal we're trying to achieve, but it opens up policy to allow lots of unsavory people to get space with the changes. Aaron does support the policy. As a new organization, he had to acquire v4 space to build a v6-only network. Doni from PeakWeb supports the policy. The current policy leaves a portion of our membership stranded. Ah. This policy change does remove the "known ISP" part removed. And Aaron would be happy with it with 200 sites still in it, but "known ISP" removed. Doni notes that smaller networks with less than 200 still have to lie. Dan Alexander, Comcast. Cathy said these were removed from other RIRs; do the other RIRs have criteria they put in place of these, or are they as liberal as the proposed language would be? RIPE says they got rid of 200 end sites, and the ISP requirement is gone. APNIC was proposing to strengthen aggregation by pushing for additional aggregation, but that was defeated. End site requirement is still there. LACNIC removed 200 sites; they ask for aggregate to be announced within 1 year, and to provide service within 2 years. Kevin Oberman, ESnet--likes half, not likes the other half. First change, allowing de-aggregation isn't about open access to IPv6. The second half is entirely too liberal to do all at once; but we need to take smaller steps to get there, not just open the door to anyone who can breathe and send email. It's just a bit *too* liberal. John someone, it strikes him the panel at IPv6 panel is that there's a problem with current policy. The idea of having to consume some scarce v4 resource to get unscarce v6 resource is just wrong, and needs to go away. No limitations on getting space at all abrogates our stewardship of scarce slots in the routing tables. Cathy responds noting that ARIN does not dictate to operators what routing policy should be. This conversation at open mic last night...there's a difference between between "there can be only one" and "there are no constraints"--can we find something in between that allows for good operations as well as good stewardship without throwing the gate wide open. If you get a lot of growth very fast in IPv6 routes, and don't constrain it, the fears of gradual growth people worry about will be nothing compared to worries of routers falling over. Jason Schiller--clarification question; confused on 6.5.1.1b; it says "be known ISP *or* to provide 200 customers in next 2 years"--if a new entity starts up with 200 customers, is not a known ISP, would they get addresses. Aaron notes he was denied on that count; he requested a /32 for 200 customers over the next five years, but was not a known v4 ISP. Currently, the language requires ARIN to evaluate the stated business plan and make a value judgement. Jason is still confused if we have a policy problem, or an implementation problem? If you apply, you will need to submit a business plan that shows how you will get those 200 customers. In that case, he is opposed to this policy, as the bar is sufficiently low; with no requirement, the bar is too low, and even his house would qualify as an ISP. Igor, Yahoo--completely for part 1, and feels that it is a hinderance to development of the IPv6 internet, especially for content providers to develop this. And please leave operational problems to operators; the operators will take care of the routing table size issues. As far as part 2; really wish we could vote on part 1 separately. Is fee schedule for ISP separate for end site? Those fees are waived now, and will expire or be extended on December 31st. If you apply for v6 only; end users pay 1 time fee, and then nominal maintenance. ISPs pay for allocation, and pay same amount each year on their total allocated block. Couldn't the fee be used to disincent abuse of the system? Joe says we need to have a better end site plan. Scott speaks for Chris--says single aggregate is bad, need to remove it. He doesn't think dropping 200 end site would be good. Leo Bicknell ISC, first half he agrees with, it doesn't reflect reality, and operators are better poised to react as needed to changes, as routers grow, etc. Second half of proposal; agree that given Aaron's type of situation, the current situation is very flawed. We need to set a reasonable criteria for the bar at some level. Right now, interest in v6 is low; few people will start up v6 only businesses. However, over time, that will become more interesting. Transition may happen quickly. If we remove all limits, we could have hundreds of thousands of people trying to get space in too short a time for policy process. The problem of people not being able to qualify with real plans is real, but he doesn't support the second part as it stands. Owen DeLong, he.net; he feels 200 end site is too steep. Some requirement is worthwhile. Would be good input to AC if we can get a range sense of what a better bar should be. otherwise, good policy, the removal single aggregate are needed. random person at mic agrees part 1 needs to go away, otherwise the /32 used for anycast is stupid, the reasons for it are solid. For part 2, we have other things we require in v4 for doing this; can we tie v6 rules to same boundries and qualify for it to get v6, but not actually take it. Kevin Oberman, in response to tom, current policy does not require you to get IPv4 space before getting IPv6. Stewardship in terms of forwarding table sizes is not an ARIN issue, and that is a constantly sliding bar. The economics will control how networks are run, regardless of what policies ARIN sets, as one network rejects prefixes that ARIN allocates today. Igor from Yahoo--given that many people are in favour of part 1, and more discussion is needed for part 2; can we split it? They can poll the two parts separately, and AC can take that under advisement. So far, nobody has said the routing aggregate part needs to stay; if you support that, please go to the mic! And if you'd like to see a requirement for the block to be announced within a certain period of time like LACnic, please speak up. David Farmer, UofMinn, he supports first part of policy, he echoes discomfort with lack of criteria for part 2. And proposals for working on end user part of assignment policy will be forthcoming; it is on the list of policies that will be worked on very soon; he will be working on it shortly, so please talk to him if you have ideas about it. While he agrees that operators are more than capable of setting and defending policies, he feels ARIN is responsible for providing hooks for providers to hang their policies on. John will close mics shortly. Chris Grundeman, he would support splitting policy in two, and supports first half. If ARIN wants to preserve table slots, start allocating sparsely! For second half, 200 users in 5 years is not a challenge for any starting ISP; he's hit more than that as a four person ISP. That part does need more work. Center front. Kevin Loch, Carpathian network, he supports part 1 strongly; part 2, he's concerned about frivolous applications. Economic hurdles, $2250/year with no waiver for /32; 75% waiver this year, so at least $500 even today. And you can't get resources from ARIN without some legal entity, some LLC, etc.? A: No, does not think there is a requirement for a separate legal entity. You must be an organization, not an individual. Kevin Oberman, es.net; a family is an organization. :) There is a difference between stewarding the address allocations to allow for rational policies, vs enforcing policies. Mike, rear mic, a minnow in a shark tank; his business model is slightly different, supports medical facilities across country, provides /27s and /28s right now; if he is considered a known ISP now; but if you ask him to show a business plan on business model, he can't meet that criteria. As Cathy asked, he would support a plan like LACNIC with time-based criteria, not size. Jason Schiller, Verizon--some people may not qualify for 200 sites in 5 years, and are using known ISP clause as easy out to justify space. how about 3 parts; advertise single aggregate known ISP as third part 200 sites in 5 years as third part. Some might support policy with combination of the three items. He does not support the policy. Strike known ISP, and then would support it with keeping aggregate in place, and the 200 sites rule. That concludes discussion. Now, show of hands; draft policy as written first? In favour? 27 Opposed? 48 in room 147 same policy; instead of removing requirement for 200 end sites, reduce from 200 to 100. in favour: 42 against: 22 participants, 147 Many questions about clarifying what we're voting on get addressed. What about removing only the single aggregate statement, and leaving the minimum customer requirement? in favour: 64 against: 10 participants: 147 This concludes the polic portion for today. Open mic portion...be courteous, identify yourself at the mic. Leo Bicknell--if you attended 2 part ARIN/NANOG panel, there was near universal agreement that 2009-1 was hard to understand. Most people didn't come up to talk about it. Why didn't more people comment on it today? Igor from yahoo notes the people who spoke last night were too hung over to make it the morning to talk. He'd like to see a flow chart of how it's supposed to work, it's too confusing as it stands now. Tom Daly, dynamic networks, the day job needed some love too. Scott Bradner asks if he will take the advice for putting the flow chart to make it more understandable Yes, they will try. Cathy asks if Tom Daly can explain why he finds the transfer policy confusing. It seems nuance of removing M&A activity didn't come out at him; he might have been dense at the time. Igor, Yahoo, notes that M&A makes it confusing; is it or, and, or what that; those sections seem to be in conflict. mic open for all topics. martin hannigan, akamai, some traffic about some AC non-comm issues; what happened, and what will be done in the future? A: won't be discussed during current elections, but after the elections close, will be explained. Doni, peakweb, discussions around integrity of v4 routing table and future abuses. The topic is authoritative routing registry that ties prefix to originating ASN. for recent v4 requests, originating ASN has been added as optional field. There are multiple routing registries in use, some public, some private. He would like to get feedback about developing an authoritative routing registry; we would decide on which of the one would be the authoritative one, and all of the others would get folded into it. A: There are many IRRS out there; hard to envision how to get to a single worldwide routing registry; it's a bit bigger than just ARIN. Mark Kosters, CTO, ARIN; ARIN also mirrors everyone else, so even though there's islands of where the information resides, you can get a comprehensive view; only about 50% of the information is valid in the registry. There is an emerging system getting put in place, resource certification; ARIN and other RIRs are testing it, rpki-pilot.arin.net, it may subsume other projects over time. Right now, this is more about the certification process, not the single-uber-source. lea roberts, ARIN AC, stanford university. comment on 2009-7; ARIN doing sparse allocation benefit to community. It's not a policy issue, it's implementation; could we at least space the allocations out a bit more? Anyone want to speak against ARIN doing sparse allocations? By end of meeting Friday, he will have timeline for sparse allocations! Lee Howard, TWC, earlier during week there was a suggestion that Aaron Hughes write a best current practices document around it. Nobody has figured out which space that work should happen in, though. Should ARIN handle/facilitate this type of work. Jason schiller, Verizon; best current practices document is good, but need a process like what we do here, community writes their thoughts on what would be best, produce a living document that changes over time; don't write what you can and can't route; it's not a binding document, but a best common practices document would be good. Owen DeLong, HE.net, it's a great idea to develop BCP document; set aside a new category on a wiki and he can work with Aaron to develop it on the ipv6 wiki. Chris Grundeman, the ipv6 wiki on ARIN's website is a good place to start; perhaps it needs a little coaxing. We can get the ball rolling. Aaron, a repository somewhere would be good, the better place for this would be program committee at NANOG; but if we start something as ARIN, it won't have good operational support to make it useful. Closing floor to new topics. Stacy, question remotely. If you are a legacy v4 holder, must you sign legacy RSA in order to get v6 resources. To get IPv6 resources, you must sign RSA for the v6 resources, but v4 is not covered under it. Cathy wants more discussion around LACNIC requirements: 1 be LIR or ISP 2 document plan for services to be offered to other clients, cell phones, departments, 3 a single aggregate route will be advertised within 12 months 4 offer Ipv6 services within LACNIC region within 24 months. Perhaps this would be better than our 100 or 200 number? Scott Liebrand--hearing that made his head hurt, and think of 2008-2, first transfer policy. Cathy responds that there's a large number of prefixes that have never been announced into the table. Chris Grundeman, he talks about not needing to announce space. We don't require that under IPv4. Cathy notes that this is for ISP policy; and they require within 24 months to be reselling or providing services. Chris Morrow, Google, it would be difficult to go back and push people to announce blocks on the Internet. Making a requirement to announce it is not good for large private networks. Closing mics shortly. Leo Bicknell, ISC, he doesn't like the word announce; but he does like a requirement that it be in use within some period of time; could be announced, but could also be in use on private network. Requirements like this could alleviate issues like this in the IPv4 world. Every 12 or 24 months, we might re-look at it. There are a lot of large networks going down the path to enabling their networks, and are still in startup phase. It would be silly to put 12 month timeframe and spend ARIN cycles chasing cases where vendors are running late. But it would be good verify that resources are being used for *some* purposes. Chris Grundeman notes that the customer requirement does the same thing; instead of using announcement as a bar. If you don't have customers, you're not an ISP. Cathy agrees with it, but we keep dithering over the actual number. Basically, they require you to have visible customers as an ISP, where the count doesn't matter as much. Aaron--is there anything in NRPM about resource review policy for v6; there's no mandated review and nothing about v6. Scott asks if it *BLOCKS* resource review for v6? It's just resources, it doesn't specify which resource type. So the legacy resources are the only exemption. David Farmer, U of Minn, thanks to Cathy for bringing this up. We have a lot of work to do here, there's some obvious things we need to move forward with on this. Would like to thank two people: Leo and Lea, who are leaving the AC for their many years of service!! That concludes today, you have dinner on your own tonight! Fill out your survey online! http://www.arin.net/ARIN-XXIV/survey/ Breakfast 8am, meeting 9am, it'll be like it was today, and stay on target for policy proposals; other items will shuffle to make those stay constant to keep the remote participants able to participate. We wrap up for the day at 1718 hours Eastern time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaimon at chl.com Wed Oct 21 20:44:29 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 21 Oct 2009 20:44:29 -0400 Subject: [arin-ppml] Alternative to 2009-7. In-Reply-To: References: <20091021204832.GA24881@ussenterprise.ufp.org> <443de7ad0910211358o49a0de58w9ea16bf2a6698735@mail.gmail.com> Message-ID: <4ADFAAED.5030409@chl.com> Owen DeLong wrote: >> >> I think that the current ISP requirement is satisfactory if it is >> implemented by ARIN staff as written. I have a hard time accepting >> that you are an ISP if you will never have over 200 customers. >> Perhaps what we need to look at is the end-user requirements...? >> > There are many ISPs that are small regional business-to-business > providers that have less than 200 customers and have /20s or larger > for the number of hosts their customers have. Is there any reason > to believe it is not possible for such a business to start up in IPv6 > going forward? > > Owen > There are many many niches where a small ISP operation can provide quite comfortable revenues providing excellent service to a small number of large customers. Low volume, High margin. However: I am certain any such ISP's have a real hope and plan on how to try to obtain 200+ sites/customers. Its not like they made a business decision to turn away the 200 site because they dont want to get any bigger. As it stands, a new ISP without any IPv4 (which strikes me as a fairly rate occurrence) has only to present a good faith credible plan and intent to build their business and network past 200. From jmaimon at chl.com Wed Oct 21 21:32:19 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 21 Oct 2009 21:32:19 -0400 Subject: [arin-ppml] 2009.10.21 ARIN 24 first day morning notes In-Reply-To: <63ac96a50910210903w72d2f940me7dc40df6091dada@mail.gmail.com> References: <63ac96a50910210903w72d2f940me7dc40df6091dada@mail.gmail.com> Message-ID: <4ADFB623.7070405@chl.com> Matthew Petach wrote: > > Joe Maimon--if all large allocations go to providers, > is it known when they will be coming back to the well? > > John knows when everyone got their last block, and > can build a sawtooth demand on when they are likely > to come back for their next request based on history > If you project that forward, you get a model that > looks a lot like Geoff's data. Just to clarify, the remote question wasnt related to Ipv4 and runout predictions - it was related to the /32 allocation statistics. In other words, have all the expected large consumers of IPv6 received their /24's or whatever and are we expecting them back anytime in the next decade? Does ARIN have an idea of how much IPv6 /32's need to be allocated by IPv4 runout to cover all addressing needs at that point? From mpetach at netflight.com Thu Oct 22 13:30:49 2009 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 22 Oct 2009 10:30:49 -0700 Subject: [arin-ppml] 2009.10.22 ARIN 24 meeting notes, day 2, part 1 Message-ID: <63ac96a50910221030o3b40d24nc086d2fc955e9290@mail.gmail.com> Sorry, these were my "before lunch" notes, but I dashed off to grab lunch before sending them out, so they're a bit late this time, apologies for that. ^_^; Matt 2009.10.22 ARIN day 2 morning session John Curran calls the meeting to order promptly at 0900 hours Eastern time. Welcome back everyone, hope you had a good time exploring Dearborn last night. Welcome back to the remote participants. NRO election winner was louie lee Daily survey http://www.arin.net/surveys/ARIN-XXIV today's winner is a $120 carbon offset gift certificate Night at the museum tonight, 6:30 to 10:30 at the Henry Ford Museum food, fun, dancing, booze, lots of cool stuff. Get social! If you see something good at the meeting, you can post it on facebook or twitter. facebook/teamARIN Thanks to Arbor and Merit as sponsors. Meeting rules are explained for approaching the mic Agenda IPv6/IETF/IAB report RIR updates NRO NC report NRO activities report policy experience report WHOIS RESTful web service policies: 2009-5: IPv6 for multiple discrete 2009-3: IPv4 for RIR 2009-8: equitable runout IPv6 IAB/IETF activities report Marla will give that report This is not an official IETF report; there is no official liason between IETF and RIRs. routing area work group IP fast reroute using Not-via address IPv6 maint working group (6man) five documents in the workds one doc in IESG processing V6 ops, five active documents router vendor docs are being worked on to help shepherd vendor CPE efforts. also one recommending document, but non-binding SHIM6 WG little action, only one active document BEHAVE WG 7 active documents v6 to v4 translation via algorithmic translations DNS64, how to deploy with v6/v4 translators NAT64, NAT from v6 clients to v4 servers IESG processing 2 BEHAVE docs now Secure inter-domain routing (sidr) buttload of active documents on the slide lots of what-if scenarios about what will happen if ITU takes over path validation being discussed, even though part of another working group Softwire not much new in active docs 4 more docs published as RFCs DNS Operations (DNSOP) 3 active documents changing dns returns during network incidents, what are ethics of it. DNS extensions (DNSEXT) 9 active 1 published OpSEC 1 active document and 1 published RFC Global Routing Operations (GROW) 9 active documents Locator/Identifier Separation (LISP) new group met at Stockholm 5 active documents Hiroshima IETF Nov 8-13 IETF BOF wiki has info on it. Reference, next meeting http://tools.ietf.org/bof/trac/wiki Paul Wilson, APNIC update Services policy updates priority activities next meetings major resource delegations at APNIC IPv4 /8s growing (2009 numbers not complete) ASNs may be flattening out IPv6 on the rise (individual delegations) 2008 and 2009 huge growth Service levels 2000 members, July 2009 largest month on record for new members many member LIRs, though, about a 1000 members in those APNIC now averages 1400+ per month helpdesk enquiries, growing over last year allocations of space growing slowly, will slightly exceed last year 100 per month to 105 per month APNIC 28 policy outcomes 4 reached consensus, still subject to final call prop-050 -- v4 address transfer policy--receipt subject to approval according to current policies prop-073 -- simplify v6 allocation to existing v4 allocation prop-074 -- global policy on IANA block allocations prop-075 -- recovery of unused AS numbers in region No consensus on 3 policies prop-077 -- historical address transfer (currently needs no justification when transferring) -- proposed to require current justification prop-078 -- reserve /10 out of last /8 for v4 to v6 deployment; needs more modifications prop-076 -- requiring further aggregation for v6 blocks from LIRs to single announcement top 10 resource allocations every 2 years does member survey to assess where resources should be allocated 1: research and dev activies 2: support network engineering education ... Research and Development work with other RIRs on RPKI DNS service dynamics DNSSEC implementation anycast deployment expand network monitoring and reporting test traffic measurement (TTM) sponsorship of 12 AsiaPac nodes (part of RIPE NCC) day in the life of the internet (DITL) provided 478+ GB of DNS traffic to it Education support network engineering education in the region training team active in org develop institutional links training lab expansion (online training) more security training with Team Cymru tunneling project with AUSCert E-learning and self paced learning IPv6 support more IPv6 deployment coordinate and promote v6 activities across whole region ICONS IPv6 wiki IPv6 messages, materials, outreach, and information IPv6 workshop for APEC TEL 40 very good presence there; strong public interest in broadband. Services streamline request and allocation process MyAPNIC features integrate membership sign-up and resource request form automate data exchange using web services, provide secure channels, link member DSNSEC signed zones to APNIC signed zones Other: development of resource certification to support routing security RPKI for members more DNS root servers in AP region deployments in Taiwan, Mongolia deployment of TTM at root server locations APNIC meeting Kuala Lumpur, Feb 23 - 5 Mar 2010 with APRICOT 2010 More APNIC meetings Aug 2010, bangkok, APNIC 31 / APRICOT 2011 Hong kong joint meeting with APAN 21-25 Feb 2011 NRO Number Council report, Martin Hannigan NRO NC, Martin Hannigan, Louie Lee, Jason Schiller process global policy appoint 2 board members to the ICANN board of trustees function adminstratively; write proceedures, execute New stuff appointed Ray Plzak to ICANN BoT working on global policies 2009-6: 2009-3: Need another ICANN board member soon, too. RIPE re-elects Dave Wilson APNIC relects Dr Kenny Huang See you at ARIN 25 We're ahead of schedule so we'll see if Lixia can do her demo now instead of later. Demo of allocation vs routes She's not looking for testers, per se; the system won't handle many users. Looking for feedback, it's demoware. Cathy Aaronson gets most of the credit; this is her second meeting; first was in 2002, when minimum allocation getting moved from /20 to /22. Cathy asked if the minimum size changes, will that affect routing table size? Lixia said "don't worry"--but now we have an interest in actually visualizing the impact. She had one of her students do this as a project. One of her other students did Cyclops cyclops.cs.ucla.edu, shows if someone else announces your blocks The screen can't really show it; each block on the screen is a /8 The fills and colours show the reserved, allocated, multicast, legacy, and each RIR allocated block. you can check the RIR allocation, and it shows the colours of how the block is allocated You can keep clicking to drill in more and more and eventually get down to specific records for each individual allocation More interesting bit is the "what is seen via BGP" it shows the span of BGP announcements; one allocation, one announcement for 18/8. Apple, 17/8, you see many announcements (92) along with their /8 advertisement. If you can help them figure out the best way to visualize the data on where exactly the blocks are being announced, come talk to her. Draft policy 2009-5 still isn't ready to start yet. LACNIC update? Ricado Patara still growing in number of allocations membership growing; just reached 1000 members staff increasing every year, up to 22 now Membership evolution over time small blocks is largest growing segment 1033 members 2 NIRs, members of NIRs are also members of LACNIC registration services data number of allocations made, v4 vs v6 vs ASNs chart shows some growth in v6 policy development new process (PDP) since last year introducing expedite process only one meeting per year, may need faster process 2 co-chairs francisco aria (mexico) nicolas antonielly (uruguay), elected May 2009 Policy under discussion ratified by board, to be implemented shortly 2009-01 2009-02 2009-03 last-call: 2009-08: IANA policy for RIR allocations of ASNs LACNIC XII meeting in panama city, may 24 to may 29 2009 300 people from 40 economies LACNIC Caribbean 2 meeting July 16-17, trinidad/tobago 70 attendees, 17 countries IPv6 tour 2008-2009 visited: TT, AN, DO, PA, PE, BO, EC, CO PY, BZ, NI Frida program some money for ISP programs; call for projects finished beginning of october; soon will announce project selected for funding Outstanding Achievement Award First award, Ms. Ida Holz, head of central computer service of university of the republic, Uruguay Public affairs Government working group facilitate communication w/gov regarding Internet resources admin 1st meeting held in Organized CITEL workshop on regional interconnection +RAICES project anycast copies of f-root to be installed Sint Martin most recent deployment RPKI--issue certificate for each IP allocation DNS platform upgrade/DNSSEC deployment already signing lacnic.org as test bed. Any questions? Nope. OK, back to policy: draft policy 2009-5: multiple discrete networks allows IPv6 initial and subsequent allocations for discrete networks within single org. No legal impact staff impact minimal 28 posts, 12 people 3 in favour, none against Heather Schiller will do the AC presentation proposed to solve the problem of organizations that have several discrete and totally separate networks. IPv4 already allows this; this basically brings IPv6 into similar alignment. Text stayed same as 4.5 for IPv4 except for utilization requirements IPv4 has the specific utilization language. This just requires that you show you have a separate network requirement, following criteria in section 6.5.2 (which you can read in your NRPM program guide) Kevin Loch, Carpathia networks -- he does run multiple discrete networks today, he fully supports it. Kevin Oberman, ESnet, assuming the first part of 2009-7 was passed, it would completely obviate the need for this, would it not? David Williamson, tellme; if you get a single /48 as an end site, if you have multiple sites, you can't really break up the /48 into routable blocks, so 2009-7 doesn't cover this. He supports this policy, it sounds like? Owen DeLong, HE.net, they have many customers who have expressed a need for this policy; a video delivery company for example needs this; he supports the policy completely. Leo Bicknell, ARIN AC, he supports the policy. This applies to a small number of people, but for whom it is very important. Can we get an idea of how many people have a need like this? A: ARIN does not have this in any type of stastical model, right? Leslie notes that she does have the data, it's just not auto-accessible. Will it change his answer? Cathy Aaronson, Cascadia, she responds to Kevin about why removing /32 aggregate requirement doesn't help. She had 2 divisions with 2 different business models; one was mostly utilized, the other barely used; she couldn't split the /32 into 2 /33s, she really did need a second block for the second network. She is totally in support of the policy. Andrew Dul, wrote original v4 proposal, he supports the v6 proposal; it did make things easier for ARIN; it is about the way companies do business today. ARIN needs to foster v6 on the internet, we need to support companies in their ability to do business, and this is one way in which companies do business. In terms of removing single /32 announcement, he doesn't think this solves it either, same reasons as Cathy. Kevin Oberman comes back and after Cathy's explanation, he now supports this fully. Jason Schiller, Verizon, he is in favour of it even though it does add more routes into the global table. He can see a need for this for multiple stub networks; it should not lead to a large increase in global routing tables. In v4 flavour, there is a requirement where the overall utilization of all discrete networks is looked at. It is not clear if the v6 policy should have the same language; but it's not clear if we should have same language, but we may have a check to make sure earlier allocations are being used. David Farmer, U of Minn--is it staff's opinion that this applies to end site as well as ISPs? A: Yes, applies to both. Then he does support it. If you are against this, speak up. Joe Maimon, remote comment; policy as written appears to prevent opening the floodgates,...[I lose last part, as scott is speaking too quietly and quickly to make out.] microphones are now closed. Now we vote on 2009-5: in favour: 79 opposed: zero total in room and remote: 146 ACSP Open consultation question and answer process; a quick summary of these will be coming up momentarily This is basically a suggestion box provides a formal mechanism for the community to suggest change or additions or suspension of ARIN services or practices This allows for public view for issues, to make sure that a formal response is issued. There's also staff initiated questions that are raised to the community Changes to ARIN resource revocation procedures Should overdue period be shortened to 6 months from 12 months before address block is reassigned. At 6 month mark, it would be revoked, and be announced to the community in a feed; that way, it would be in hold-down for six months before getting re-assigned. Comments on this are welcome. Changes to ARIN RSS feed add daily recovered address space to the RSS feed should it be extended to provide data in XML to allow for programmatic sucking into databases? but that could be an announcement of blocks open for hijacking. Retiring ARIN email POC templates It's out there, we talked about it yesterday. Please feel free to put comments on ARIN discuss mailing list. Break time, talk to info center, see materials, election help desk is open, billing help desk is open, be back at 11. BREAK TIME! We come back from break, and jump into the NRO activities report from Adiel Akplogan (Numbers Resource Organization) RIRs working together Current office holders Adiel, Axwl, and Raul (AfriNIC, RIPE NCC, LACNIC) NRO coordination groups ECG (engineering) CCG: (communications coordination) PCG (public relations) NRO expense distribution 2008 AfriNIC 3.2 APNIC 26.5 ARIN 27.3 LACNIC ICANN meetings Mexico City, 1-6 March 2009 present status of IPv4, IPv6, what we're doing about it Future meeting next week in Seoul Internet Governance Forum NRO-EC represented in MAG (Raul Echeberria) Next meeting, Nov 15-18 in Egypt International cooperation ITU provide internet number stats to ITU members participate in Telecom World Meeting with ITU to understand IPv6 address management OECD NRO has joined ITAC contributing to several OECD meetings Timeline for IPv6 support by RIRs ip6.arpa delegation planning DNSSEC planning resource certification coordination Addressing IPv4/IPv6 issues Retreat outcome Create new public affairs coordination group (PCG) decided on some permanent distribution of some NRO functions CG chairs and EC chair to come from same RIR starting 2010 Agree on limiting ASN 2-byte allocations to RIRS to 2 per RIR. Update from the RIPE NCC Vital statistics 6388 members over 1000 members from russia alone Budget of 15.2M EUR staff: 112 stable board composition long term improving efficiency Planning for 2010 general meeting in october draft activity plan/budget (17.5M EUR) draft charging scheme (slight rise next year) articles of association simplify election proceedure enable e-voting for remote participation Yet another k k-root node in Africa deployed. Will talk to LACnic about south america TTM partnership with APNic new node in pakistan, more to follow BGPviz RIS backend arch improvements, 10x faster Hard at work on new portal Customer service highlight remember 2007-01 get a grip on those PI assignments As per 24-08-2009 1935 out of 4900 registries have participated 9101 out of 27k resources have status set Training and IPv6 IPv6 testimonials (interviews with members from the community about their experiences with IPv6 published on IPv5ActNow and Youtube short per-topic cuts e-learning news DNS SEC e-learning first module published Science group making progress on quality and consistency of mostly historical registration data. new tools: REX (resource explorer) dig up historical records for past 10 years on block Netsense status of internet INRDB RIPE Labs Robert Kisteleki Forum for presenting new ideas and tools http://labs.ripe.net/ launched at October RIPE still getting the bugs worked out, it can be a bit slow at times, but coming along nicely. Not meant to be RIPE NCC, but for whole community External relations and communications donated sizeable amount of paul rendeks' time to NRO for PR and Comms effort Also, secretariat support for ASO (heavy hit on resources) strong support for EU IPv6 survey 600 responses similar to previous ARIN study recently completed by APNIC Outreach 17-18 sept, Moscow 21 setp roundtable for gov't and regulators 22 sept LEA Workshop 5-9 october RIPE 59 as well as ITU telecom World, Geneva Meetings regional meeting in beirut, 28/29 October RIPE 60 (3-7 May 2010) Suggestion--next year, warm up the room!! Draft 2009-3: Global policy, allocation of Similar in every region but ARIN; adopted in other regions or in discussion. Does it help to have a global policy that's different in each region? Don't get hung up on exact wording, we may need to adjust a bit with ASO Original proposal required return of address space to IANA. ARIN required legacy space to go to IANA, other space return was 'optional'; reworked it; now says RIRs "may" return space to IANA. New IANA to RIR IPv4 allocation policy; 1/10th of IANA free pool to each RIR upon request, every 6 months No legal risk staff concerns; fractured /8s, serious reverse DNS concerns staff concerns; will take more work, but won't be impossible to do. 54 posts, 15 people, 1 in favour, 5 against If we use term "may", it becomes suggestion rather than policy; better places for suggestions. Once the free pool is exhausted (IPv4), no policy for IANA redistributing blocks smaller than /8, or for RIRs to share/transfer between them. This creates a new global pool of returned space that can be divided among RIRs. The concerns mainly focus on the mandatory return of the full block. The policy was revised to only return if it was designated for return under local policies or proceedures. any space designated for return would still follow the same formula as originally proposed. concerns: reverse dns implications for fractured /8s. Now you delegate all the sub-blocks. Not an insurmountable obstacle. Should we be fragmenting returned space among RIRs? Possibly this policy won't get much use since it's optional, so why bother Should we move it forward/why? avoid having smaller returned space get stuck in IANA because it's less than a /8 provides mechanism to move space between regions if appropriate All the other RIRs want to do this, let's show them that we want cooperate in good stewardship provides more flexibility for working with reclaimed space in the future. Floor is open for discussion of policy 2009-3: Leo Bicknell, ISC, thinks concepts involved are of paramount importance; we need to get space back from RIRs back to IANA. But original policy and amended policy go about it in the worst possible way, and create many problems for NRO. Policy combines policy to give space to RIRs (global issue, needs all 5 RIRs), with problem of RIR returning space to IANA (a local issue within each RIR). second thing, ommission in original document, no requirement that IANA use needs-based allocations. He thinks that there needs to be clear text explaining the rules behind it) He opposes both the original and proposed change. Owen DeLong -- HE.net -- creating problems for NRO isn't a reason to object to a policy. The policy makes it up to each RIR to return space as they see fit. Can we put policy into process with NRO, and then let NRO work it with the other RIRs to see if they want to adopt it with changes proposed Martin Hannigan, Akamai, he is opposed to policy, feels it is lipstick on the pig. RIR transfer policy is the heart of matter. A global transfer policy would be a better starting point. This is a problem in that it applies to just legacy space; needs to apply to all IP space. Fulfillment concern; at 10%, some may Joe Maimon CHL--if ARIN is only one to adopt with optional "may" clause, won't other RIRs call foul? John notes that ARIN "won't" return space due to "may" clause, it simply doesn't mandate it. Historically in this region, we've returned space; but that's no guarantee of future behaviour. Scott notes that there are two things global community wants to accomplish; handle redistribution of space, and provide pressure on all RIRs to consider global needs not just local needs when returning space. Impression is that other regions would rather have structure set up with optional return; this wouldn't hurt us, and would help provide that framework. Paul Wilson, APNIC -- transfer policy in APNIC requires that recipient justify space they wish to receive based on requirements. That is essentially needs-based policy, in compliance with ARINs policy. After run-out, the policy is no longer needs-based. Martin --historical precedent seems to refer to 46/8, 47/8, 50/8; references chosen strategy, do we really need a policy to identify chosen strategy? Scott--don't believe there's a way we can modify this proposal in a way that would make it better. We can either support, or reject, in which case the global policy fails. Lixia--the one fact people may not be aware of, routing could make use of which /8 is allocated to which RIR for doing route aggregation. From North America to Asia, only a few exits, so aggregating /8s to regions could be used to help the global routing table. She is not in favour of it. Paul notes the transfer policy is in final call, this policy is still under discussion. If this policy were adopted, IANA would still have a set of address to allocate, so "runout" would not have actually occurred. If there is address space at IANA being addressed by this, then runout has not happened. If we "runout" and then more space it appears, it's not clear if we flip back to 'pre-runout' language or not. John at rear mike--the perception that the RIR system of separate regions with bottom up policy building is incapable of fairly sharing across the globe is used in arguments that are detrimental to the RIRs. There may not be much of this space to return anyhow; it may be that more damage is done to the structure of the RIR system by worrying about the possiblity that some space may move away from ARIN than actually having space move. Martin Hannigan, Akamai, at any point without a global policy, any RIR could change their policy away from this. For second point, cooperating globally is good; but there's an expectation that everyone play by the same rules. From a business side, there are concerns about costs related to this. Mics will close shortly. Jason Schiller, Verizon, clarify Paul's point. This policy, and other flavours, seem to set up a *new* pool called the recovered IPv4 pool. It seems that according to 10.4, the existing policy phase is done through the IANA pool. If addresses get returned prior to depletion, they will go into recovered pool, and cannot be touched until the IANA pool empties, we move into exhaustion phase where 1 final /8 is given to every RIR; at that point, we are post-runout, and those rules apply. The trigger condition in APNIC 50 for when they can no longer receive additional space; until commencement of use of final /8 is the trigger; if they get final /8, but use RIR recovered space in the meantime could last a while. Joe Maimon, CHL, without mandatory return, policy has little harm, but also could be useless under scarcity pressure. Would also support policy with return size greater than RIR 6 or 12 month. The concern about size of legacy space is also a concern. mics are now closed. Leo Bicknell ISC -- can you clarify why these go into recovered pool instead of IANA pool? John notes that there's a specific allocation algorithm on how to evenly divide up the space when regions have unequal draw rates. Designed to have even distribution over time; that can't happen unless it goes into a specific pool with specific rules. Jason Schiller, Verizon; if we vote this down, indicate why we don't like it, so it can be documented so that other regions can work to address the concerns. If we vote down either original policy or the proposal, we should explain why. Voting on draft policy, 2009-3: in favour: 21 against: 26 voting members, local and remote: 146 Regardless of which way you voted, talk to the AC members; let them know what you think; they have a very difficult job to do on this one! It's time for lunch, 90 minutes; we're going to be at lunch until 1330, on second floor in Bistro; take your valuables with you, no security here. LUNCH!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaimon at chl.com Thu Oct 22 14:02:51 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 22 Oct 2009 14:02:51 -0400 Subject: [arin-ppml] 2009.10.22 ARIN 24 meeting notes, day 2, part 1 In-Reply-To: <63ac96a50910221030o3b40d24nc086d2fc955e9290@mail.gmail.com> References: <63ac96a50910221030o3b40d24nc086d2fc955e9290@mail.gmail.com> Message-ID: <4AE09E4B.6020500@chl.com> Matt, Thank you for the continued effort you put into these running notes. I have copied and pasted the remote comments I made to attempt to clarify any missing holes there. Matthew Petach wrote: > > > OK, back to policy: > draft policy 2009-5: multiple discrete networks > allows IPv6 initial and subsequent allocations for > discrete networks within single org. > > Joe Maimon, remote comment; policy as written appears > to prevent opening the floodgates,...[I lose last part, > as scott is speaking too quietly and quickly to make out.] (10:16:05 AM) jmaimon: The policy as written appears to take steps to prevent the opening of the floodgates, and as such I support it, with the caveat that if the restriction on single aggregate advertisement is removed, technical justification why that would not suit for applications under this policy should at that point be added. > > Draft 2009-3: Global policy, allocation of > Similar in every region but ARIN; adopted in other regions > or in discussion. > Does it help to have a global policy that's different > in each region? > > Joe Maimon CHL--if ARIN is only one to adopt with optional > "may" clause, won't other RIRs call foul? (11:45:23 AM) jmaimon: If ARIN is the only one who adopts this policy but with optional return, wont all the other RIR's cry foul? Why should any RIR want to return space if they dont have to? > > John notes that ARIN "won't" return space due to "may" > clause, it simply doesn't mandate it. Historically in > this region, we've returned space; but that's no > guarantee of future behaviour. > > John at rear mike--the perception that the RIR system > of separate regions with bottom up policy building > is incapable of fairly sharing across the globe is > used in arguments that are detrimental to the RIRs. > There may not be much of this space to return > anyhow; it may be that more damage is done to the > structure of the RIR system by worrying about the > possiblity that some space may move away from ARIN > than actually having space move. (12:01:27 PM) jmaimon: I believe without mandatory return, the policy is likely to have little potential harm but it also may be useless under scarcity pressure. On the chance that voluntary return would continue, I support the policy. I would also support a policy that required return of returned space that exceeded the RIR's 6 or 12 month supply needs. As per Martin's concern, perhaps the distribution of returned space should factor in the RiR consumption needs. In response to public perception, the fact ithat legacy+unavailable is almost 50% of the pie is a fairly significant one. > > > Joe From schnizlein at isoc.org Thu Oct 22 14:58:52 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Thu, 22 Oct 2009 14:58:52 -0400 Subject: [arin-ppml] policy proposal 2009-8 EQUITABLE IPv4 RUN-OUT Message-ID: Having failed to say this during my opportunity at the mic, this policy is not so much about any organization that gets one of the last few allocations. The policy is to reduce the degree of outrage, or at least sympathy for that outrage, by the organization that is among the first who are told the addresses are all gone. It really does not matter how "terminally stupid" (as described at the mic) this party is, they can make a lot of trouble that we can preclude now. John From jmaimon at chl.com Thu Oct 22 15:35:14 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 22 Oct 2009 15:35:14 -0400 Subject: [arin-ppml] policy proposal 2009-8 EQUITABLE IPv4 RUN-OUT In-Reply-To: References: Message-ID: <4AE0B3F2.6040602@chl.com> John Schnizlein wrote: > Having failed to say this during my opportunity at the mic, this policy > is not so much about any organization that gets one of the last few > allocations. The policy is to reduce the degree of outrage, or at least > sympathy for that outrage, by the organization that is among the first > who are told the addresses are all gone. > > It really does not matter how "terminally stupid" (as described at the > mic) this party is, they can make a lot of trouble that we can preclude > now. > > John While I believe you are correct, I also think that there could be better solutions than only this policy, which I did express support for. Joe From jmaimon at chl.com Thu Oct 22 15:39:10 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 22 Oct 2009 15:39:10 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern Message-ID: <4AE0B4DE.7070607@chl.com> 2009-8, the latest in a number of attempts to deal with the upcoming depletion appears to show a community still divided. This raises for me the underlying question and I would appreciate any feedback. Are you in favor of changing anything at all or can you think of no better course of action than to continue exactly as is now? Offlist replies will remain private, summarized if appropriate. Joe From matthew at matthew.at Thu Oct 22 16:12:14 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 22 Oct 2009 13:12:14 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE0B4DE.7070607@chl.com> References: <4AE0B4DE.7070607@chl.com> Message-ID: <4AE0BC9E.5070405@matthew.at> Joe Maimon wrote: > 2009-8, the latest in a number of attempts to deal with the upcoming > depletion appears to show a community still divided. > > This raises for me the underlying question and I would appreciate any > feedback. > > Are you in favor of changing anything at all or can you think of no > better course of action than to continue exactly as is now? Who is more likely to sue, whine, complain, or otherwise make a stink: A) Someone who can justify a /18, knows that a /18 worth of space or more is still available, and is told they can't have that much space even with the justification because rationing is in effect to ensure that other requesters can also have smaller allocations fulfilled; or B) Someone who can justify a /18, knows that there's no longer a /18 worth of space left to allocate because it is all gone, and is told they're out of luck. As someone who's dealt with small children and a diminishing supply of cookies, I can tell you that showing them the empty box of cookies works way better than telling them they can only have one each tonight (even though last night they could have two) just because we're down to only 5 left. Matthew Kaufman From mpetach at netflight.com Thu Oct 22 17:03:50 2009 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 22 Oct 2009 14:03:50 -0700 Subject: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes Message-ID: <63ac96a50910221403k5f4f77dq51aafe6466e88294@mail.gmail.com> Wow. that was quite a bunch of discussion today. ^_^; This is long, and there's a few gaps where I couldn't keep up with people, but hopefully this captures most of the debates that went back and forth. Thanks!! Matt 2009.10.22 ARIN 24 notes, day 2, part 2 We return from lunch at 1330 hours Eastern time when John starts things off. We start off with presentation from Andy Newton talking about the RESTful WHOIS service. Whois-RWS Representational State Transfer defines a pattern of usage with HTTP to create, read, update, and delete (CRUD) data "resources" are addressable in URLs very popular protocol model amazon S3, Yahoo, Google services, twitter clients... Why now? major refactoring needed for current WHOIS services to support DNSSEC implementation of new system just as much work as fixing old ones. reused ARIN Online components Higher utility than just NICNAME/WHOIS POC, ORG, NET, ASN resources have URLs that you can cut and paste gives simple programmatic API into whois data compared to NICNAME TCP/43 better inputs and queries more meaningful outputs builds on HTTP parsing RESTful web services O'Reilly, Sam Ruby, Leonard Richardson http://whoisrws-demo.arin.net/ demo available now currently have RESTful web service, database for server cluster, sync'd to registration database. NICNAME/WHOIS port 43 proxy now feeds data to RESTful service. Web From interface is what you see on the page, it emulates the text box on main page, it uses XML with XSLT style sheet to transform it You already have clients it's called a browser. You can use command line clients to retrieve info as well. Modern web browsers do XSL transforms stylesheet not yet inserted into the XML needs software upgrade Firefox will show formatted XML that part is usable today all browsers can use the web form. Command line clients: found on unix and cygwin curl -- robust HTTP client wget -- robust HTTP client xmllint -- XML tool supporting HTTP xsltproc -- XSL transformer supporting HTTP Offer port 43 proxy use host option with favorite client: whois -h whoisrws-demo.arin.net blah Demo of request: /rest/poc/KOSTE-ARIN Addressable URLs http://whoisrws-demo.arin.net/rest/poc/KOSTE-ARIN /rest/org/ARIN/asns /rest/org/ARIN/pocs Searches: same capabilities as port 43, but can be refined Matrix URLS /rest/orgs/;name=ARIN /rest/orgs/;name=ARIN* /rest/orgs/;first=Mark;last=Kosters IP Addresses /rest/ip/v4/192.149.252.254 /rest/cidr/v4/192.149.252.0/24 relative CIDR /rest/cidr/v4/192.149.252.0/24/less Outputs XML JSON very popular for AJAX web2.0 type sites, popular for clients for mobile phones. Originates with javascript. with stylesheets, you can transform the output to your needs we provide some XSL stylesheets for translation to make XML look like traditional whois demonstration of xsltproc using xsl template (detail-template.xsl) Future enabled: caching addressable URLs make HTTP caching work with WHOIS data useful for automated security analysis 91% of Whois queries are IP address lookups Security analyzer<->local web proxy<->RESTful Web Service Future enabled: referrals rwhois referrals to downstream RESTful services Future enabled: Auth* Authentication allows tiered authorization policies no longer need to assume all or nothing. Versioning: with standard HTTP headers we can version the output change data model with as little disruption as possible Always gets the latest if you don't specify Accept: application/arin.whoisrws-v1+xml Documentation on website http://whoisrws-demo.arin.net/docs/whoisrws-api.pdf mailing list, arin-rwhiosrws Frequency of updates featuring 'near realtime' updates data replicated from registration database every 10 minutes made possible by re-using components developed for ARIN online Feedback. Rob Seastrom, Affilias, this is good, and really cool; he focuses on cacheability of this. It's not just the addressable URL, it's max-age, and cacheable; does it support If-Modified-Since? A: that can get complicated quickly; they punted and didn't do anything. You can assign your own local policy on that. They run mod_memcache and mod_poxy, and set their own policies on how long data gets cached. In his opinion, people should think about local policy first. Owen DeLong, HE.net, lots of talk on the channel looking for text output instead of just PDF and DOC. There are a lot of tools that depend on port 43 output; CIDR queries on RESTful good; lack of CIDR on port 43, bad. A: They run confluence internally, it spits out doc and pdf; it's hard to find a format that appeals to many people, but they'll try. And they're not going to get rid of WHOIS on port 43 any time soon. The current service doesn't provide CIDR lookup support, because the parsing on port 43 is non-trivial. The query actually hits many different elements on port 43, which makes the parsing hard. Ted Middlestat, internet partners, -- the policy only allows ISPs to run rwhois as permittable alternative to SWIP at the moment; NPRM needs to be updated to allow RESTful interface as alternative to SWIP or RWHOIS before ISPs move in this direction. David Williamson, TellMe--finding one output format for everyone is tough; don't find one, provide many formats is good!! XML and JSON were chosen, the stack supports them out of the box. TEXT is actually harder to do, more formatting rules Steve, MIT, thanks for CIDR blocks; will this be rate limited at all, and will it be rate limited different for good guys vs bad? A: No rate limits now; limited result set size. Will look at where it's appropriate, and what size responses are appropriate. This is a pilot service; it will at times go down. This is for community to evaluate. If you need production level service for this, let them know. Leo Bicknell, ISC -- does this support :: notation for IPv6, or do we have to fully specify? A: Not sure, test it and let him know. ^_^; Thanks to Andy!! Draft policy 2009-8: equitable IPv4 run-out June 8th, 2009, draft policy 2009 aug 31 similar policies in all regions. Slows distribution of IPv4 space Changes policy for ISPs who have been ARIN members for more than 1 year, decreases from 12 month supply to 6 month supply at 20 /8s in ARIN free pool When IANA hits 10 /8s, largest request is 1/4 of free pool, once every 3 months. Legal risk--the rules must make clear, rational sense, and must be checked for side effects that would favour one ISP over another. max prefix size may not be available as a single allocation by the time the request is granted. 4 posts, 2 people, none in favour, none against. will minimum allocation shrink? If they get a /22 every 12 months, what do they get at 6 months or 3 months? Goals: ensure an equitable distribution of the remaining v4 addresses ensure multiple organizations have an opportunity to receive IPv4 resources Reduce the disparity of IPv4 resource availablity between competitive entities Goals demonstrate due diligence when ARIN is called to task by the courts the politicians the press the public in general Reduce chance that IPv4 run-out leads to instability of the internet Avoid a friday night massacre of the ARIN free pool someone cleans out ARIN with a LARGE request late on a friday everyone gets big surprise Monday morning NOT intended to extend life of IPv4 resources you just request smaller bits more frequently Reduces length of supply from 12 months to 6 months then 3 months Creates a maximum allocation size from last /8 of 1/4 of the available ARIN free pool thus, maximum allocation size will decrease over time, accelerating towards the end The current text may have the trigger too soon will definitely cause some additional deaggregation may cause some extra work for larger consumers and ARIN, as they come back more often Trigger adjustment looking at the run-out projections, may be able to trigger later than expected possible change first half to IANA down to 10 /8s, reduce to 6 month, don't drop to 3 month supply until ARIN at last /8 Why is first part triggered on IANA pool, when ARIN isn't biggest drain on IANA pool? Editorial note: change 4.2.4.4 from twelve months to subscriber members after one year change 4.2.4.3 three months to subscriber members less than one year Floor is now open for questions/comments. Martin Hannigan, Akamai, wildly objects. Distribution method needs to be fixed. Smaller will get 100% fulfillment, larger will not get fulfillment. Need to incorporate percentages, not fixed allocation size. Igor, Yahoo--how does this affect the transfer policy; it does not affect the transfer policy. Both exempt each other, so this will not affect justification for transfers or how frequently you request transfers or from these pools. Stacy rejects this policy, and any other policy that stretches the party out. A: but this isn't stretching the party out; this is setting down rules of equity as we get to the last five minutes of the party. We're not trying to conserve resources, we're splitting up the last six pack! Stacy thinks if a large ISP can justify the last /8, they should get it. someone else at mic -- having seen the issues at other RIRs, congratulations on cleaving the baby cleanly! Trying to avoid bad hurts at the bitter end is good. The second half is reasonable when the space is completely under your control. Cutting back the earlier half to a later date is good. The early slowing may provoke the same concerns that were just heard unnecessarily. He would support it as is, but would prefer the last part only about 1/4 as biggest when there's one /8 left. A: Leo notes that the place from which they started approaching it was the case that if there was no wind-down, there would be ISPs who get address space on last day, edging out the guy who was in a meeting that day. The 12 month delay was to minimize that disparity, and to give people more time to be pickier about what they give out to bigger customers. Trying to find the least intrusive policy window to allow ISPs to get a 12 month advantage by sniping at the last minute. Also, when last /8 is allocated to ARIN, /10 is reserved, so only 3 /10 ISPs could be given out anyhow. Rob Seastrom, the cour of public appeals--this will be perceived in the press as having been done to lessen the impact of runout, or that it somehow preserves IPv4, and it softens our message that the future is in IPv6. It's not clear that any level of change to the policy will affect that perception. John notes ARIN retains a PR firm which is used occasionally. For something like this, they could do briefings ahead of time, and prepare the right answer for people who may be reporting on this to help get the right message out. Mark Wilson, uncommon technology -- he opposes the policy as written. The final trigger, the last allocation; instead of waiting for random emails, why not take poker approach; look at the last year's requests, and divide up the pool based on the percentage of the previous year. Second comment; after the IPs run out, we'll see some industry consolidation take place, esp. at smaller end of the marketplace. Chris Morrow--has concerns about the wording; it's not about equity, it's about need. There's always going to be someone who comes in after the last block, someone will always lose. A: the wall is coming. someone will eventually lose. We just don't want to hit the wall at supersonic speed. Ted Middlestat--in favour of policy, though he doesn't think policy will help; orgs who are smart will move to IPv6. The stupid ones will be gaming the system anyhow, and generating bogus needs. Orgs that need a /17 will generate requests for /15s instead. The Friday night party will be all the procrastinators who haven't prepared, and will be out of business 6 months later. So, this is harmless anyhow. Matt, Affilias, he's in agreement with being against the policy. The due diligence is getting people to move on, not soften the landing. This policy will give the impression of wanting IPv4 to last longer. But the minimum allocation size doesn't shrink. Text needs to be explicit about that. Scott Liebrand supports the proposal; he feels that the concern that we shouldn't look like we're fixing things is not what we should do. We are in a situation where what we're doing is trying to head off percieved unfairness. This won't be just about need, because there will be *more* need than supply; when there's more need than supply, we don't have a defined behaviour. If we don't define it, others (gov't) will do it for us. Joe Maimon supports the policy; if one or a few big players clear out the final supply, we can end up with a prime time sound bite. ARIN should aim to prevent gaming. Cathy, what if the wall moves? What if we hit it, and then a big block is given back? None of these policies address that. A: If ARIN gets a sufficently large enough block to move the 1/4 maximum allocation size, that's all that really happens; it still holds. Chris Grundeman, supports the policy. To the competitor getting a bigger percentage, that's why this is time based; you get 100% of your six month need, so is everyone else. Only when there isn't enough left for your six month need, do you get less than your full need, down to three months. But really, the big ISPs need to be looking now to move to IPv6, not when the runout happens. The addresses will get used up just as fast no matter which model we use, this just divides them a bit more fairly, and allows new ISPS to play. Robert Duncan, Merit--this is more of a CYA for ARIN; anyone smart is already planning ahead; just the procrastinators who are terminally stupid will get into this. Fishing industry has precedents for controlling limited, dwindling resource. This has to interact with 2009-3; what happens with the address space that comes back needs to be explicitly stated. But he supports it. mics are closing Alex Kostella, could a show of hands be made for support of policy with adjusted triggers. A: understood Leo, ISC, if you have comments on triggers, please comment on 10 /8s and last /8 as trigger points. Also, earlier comment about an ISP who received resources late in the game would become an acquisition for a less fortunate company. Is it really a bad thing? Can there be clarity or explanation around that? How is allowing someone to be an acquisition target for their IPs is a good thing? Mark says it'll happen, it's neither a good thing nor a bad thing. Normally in startup mode, one of the easiest ways to grow bottom line is to buy up competitors. You'll see consolidation, the small garage operations will get slammed together to get critical mass. Intent here is that this will happen, it always happens, it always will happen. We want to avoid the runout from causing a hugely artificial surge in them, to the point of causing market disruption. A: this reduces chance of someone being in that position *solely* by being last one through the door. Ted Mittlestat, internet partner--if wall moves, it must be understood that when IPv6 is in gear, there will be spare IPv4 being returned. IPv4 will never likely go all the way, but it will just go to maintenance mode. Joe Maimon, show of hands for doign nothing? someone from ATT, opposed based on perception of this; if we put together policy, we're almost sending message that we're extending the life of IPv4 until we don't know when. If Geoff's prediction say 2012 now, will they extend out to 2013 due to the smaller pools being left. Right now, ATT is pushing for IPv6 rollout, but the beancounters want to delay the deployment as much as possible; they want to send the message that they have to do IPv6 conversion as fast as possible. A: There's a perception problem, yes, but the perception will be worse if it looks like we did nothing at all to prepare. Right now, the policy says that if you're a big consumer, you can take that last big chunk on your own. Scott, Internap -- Leo's question, should thresholds change? First threshold takes us back 6 months; everyone else changed it, we can go back to where it was earlier, but it shouldn't be a reason to oppose it. If there's people at the party, they're not just the idiots; they'll be dual stack, they'll have v6 customers, but they'll still need v4 to talk to the rest of the internet still. So, the question is really do you get 'free' addresses vs having to pay for them. Chris Grundemann, the 20 and 10 /8's seem to be about 2 and 1 year trigger points based on current burn rates. Is the concern about the *perception* of extending v4, or does anyone actually think this will really extend to the real runout? Because it won't extend it at all. Martin Hannigan; it won't do anything for extending it, it may just create unfair distributions. If he wants to battle people, he just wants it to be fair at the end. Scott; if someone goes to the well, and there's not enough for them, that by definition is runout. It means some can dither longer, but they will have run out at that date. Owen DeLong, HE.net; this policy goes from a situation where one large request empties the well, to one where many smaller requests empties the well. It's not clear which one is "fairer" -- one big drink, or many small sips. It won't exend the life. Matt, Affilias--this changes from one big request can blow away, to one big request just gets a part. It doesn't extend significantly at all. It's just a perception issue. Trigger conditions: For those who will vote yes only with existing trigger, or only with modified trigger; if you're so sensitive to trigger you can only be in favour of one trigger or the other, or you won't support, go to a mic now. one at mic; he's opposed to current trigger. He thinks that two steps seems like trying to slow the train; he wants just one step, otherwise he'll support. Dave Barber, he's against the proposal; but if he takes second bullet alone, and moves to a single step, to a six month cycle. He would be in favour with just that trigger adjustment. Matt affilias--might support it if just the triggers were there; if we remove the "quarter of the supply", and let everyone get 100%. But if we just change the trigger, he'd still oppose. Martin Hannigan opposes the policy regardless of trigger. Is there anyone who will only vote for it with the original trigger conditions? Nope. yay. OK, the 1/4 limit in the final /8, is that needlessly complex or wrong; if you are against the 1/4 limit, approach the mics. Dan Alexander--in regards to triggers in general, there's a sense we have to do something to show to try to soften the wall. But what if we all decide to just hit the wall? Dave Barber, ATT--we're getting too granular at that point. If we cut back to a six month allocation at that point, then 3 months, and 25%, that's where the perception will look like we're going to rationing to try to extend this. Owen DeLong speaks against 25% limit; it just selects who fights over the last crumb. The downside to it being there increases the number of prefixes handed out without providing benefit to the community. John, it's not about anyone who gets address blocks at runout; it's the org who shows up just afterwards; their anger will be smaller if we haven't set up a 'winner take all' model for the final allocation. That will reduce the threat to this community. Chris Grundemann, he likes it, because the last /8 is the dregs; with this, it sets the perception that you can't get lucky and get a big allocation at the end. if you can only get 25%, it helps push big ISPs to move *sooner* rather than later, since they're less likely to fit into the space. Support of proposal with triggers AS reduced according to the alternate slide: trigger conditions set to IANA pool at 10 /8s for 6 month supply, and ARIN supply at last /8 to move to 3 month supply. This is the SOLE vote for adoption; there will be some discussion about 25% later. If you vote NO, you reject the entire policy! The other changes on next slide will be left to AC to consider. For 2009-8: in favour: 30 opposed: 28 total voting, in room, and online: 136 AC has a complicated job with this one...one more show of hands. Assuming the policy gets adopted due to stellar support. Would they like to have the 25% or no limit? YES in favour of 25% in last /8, or NO to 25% limit in last /8. in favour: 26 against: 33 total voters, in room and online: 137 How about asking how many would support it with the change he just proposed? No, too many combinatorics. BREAK time! 19 minutes, get moving! Be here at 1530! OK, back after break Policy Experience Report Leslie Nobile PDP cycle slide shows where in the formal process this lies; after the implement phase before the next need phase is this evaluate phase. Review existing policies look at existing policies abiguous text, inconsistencies, gaps identify areas where new policies or modifications may be needed operational experience customer feedback provide feedback to community make recommendations Policies reviewed identify invalid whois POC 2008-7 not fully implemented, some issues to bring to community and get feedback M&A transfers (NRPM 8.2) On 2008-7 sentence about email sent to "every POC in the whois database" Sprint cleaning/trial run emailed all registered POCs with direct resources contacted 42,920 POCs, asked to update records. Staggered emails; 4 months to complete 4% response rate. POCs with reassignments left to contact, about 359,000! It will take 33 months to contact the 359,000 with staggered emails to avoid getting slammed by responses and calls. ARIN has no direct relationship or contract with downstream POCs upstream is responsible for entering reassignment information; could cause confusion on part of the downstream. RSA 5.b says the org must maintain and update data put in for their customers as well as their own. Would like to *only* send to all direct allocation POCs; make upstream responsible for their POCs and their downstream. Q:? Owen Delong, he.net; it is important to spot check that ISPs are maintaining the information, to do the due diligence on reclaimed blocks. While a 33 month project every 12 months is untenable, can we select 10% of the downstream POCs and change the policy language to support this? Chris Grundemann; for the 43k POCs contacted, did email request *all* respond, or only respond if there were changes. The 4% was scary if they were *all* supposed to respond. The original intent was to automate the process, so that automated email goes out, with a link to click to validate the person is still alive. Wouldn't that vastly reduce the amount of time needed for this? A: yes, would be automated via ARIN Online. But the 359K don't know who ARIN is, and don't have a relationship with ARIN. Opposal to the 10% part; goal was to have this done *before* the free pool runout. This is just updating the POC information. But he meant that address space with no valid POCs could be investigated for reclaim. Ted Middlestat, he was well aware that downstream POCs would not respond; didn't intend for this to aim at those. Joe Maimon, why don't these logistics warrant emergency action. someone at mic; you're only supposed to be able to update POC if you're that person. Can ISP just update the POC records for customers, even if not listed. Nate Davis, ARIN, can they talk about phone level support needed for these. They got hundreds of phone calls from this effort. Leo Bicknell, ISC -- one question, one suggestion. Did they look at volume of POC changes coming in, rather than replies. The POC updates was the 4% number, and 12% bounceback rate as undeliverable. All POCs got sent same email, which led to one updating about others no longer existing. If ARIN sends to downstream POCs, the correct thing is to say to to contact upstream POC, not to call ARIN; the upstream may not be happy with that increase in NOC support, but they did promise to handle that. Ted Middlestat, none of the staff working this have contacted the authors about modifying it; please contact them outside the meeting for suggestions. A: Once a policy comes into existence, it belongs to the community, not the authors. Andrew Dul, does not agree to sending email to the downstreams. Intrigued by sending from the upstream, or directing them to the upstream. How do you verify the people who come back are the ones authorized to make the changes if you go to downstream; you don't have a business relationship with the downstream. Focus the efforts on the direct allocations; worry about the other parts later; not what the authors intended. Heather Schiller, Verizon, giving feedback, as one of co-authors; she disagrees with Ted, and feels coming to community is right. They got a bunch of emails from ARIN, went to all the POCs, with a link to each POC; they weren't as on top of their records as they thought; there were people listed as POCs from other companies, couldn't even untangle how it happened, and was glad she got the mail first before they asked to have her removed from the records. It may create additional burden, but please take it seriously; you could get removed from your own resources! Those with BGP validation may not worry, but the rest of us need to worry. When the email comes out, it's a race condition. Chris Grundemann--whois authorization between POCs is separate from these. Other main concern of this is to have abuse contacts is useful, rather than just main contacts. Owen Delong, ISC -- ARIN has a contract with upstream, there is a transitive clause in it; it's not certain it'll prevent it from being blocked. Ted; if you don't support sending email to the downstream, raise policy to change NRPM. Joe Maimon, if you don't agree with this, emergency policy action may be needed. M&A transfers (NRPM 8.2) this says that the assets being transferred must have been used by the entity at the time of the acquisition. Issues: text could be made clearer transfer requests often come years later; hard to know what was in use at the time of the M&A should utilization at the time of transfer request be considered? if there's little or no utilization, should future use count? The more stringent the requirement, the more likely the transfers are to be abandonded and the ARIN data inaccurate currently 60-75% of transfers get abandonded Currently, requirement is to know how the resources were being used at the time of the acquisition. If there's usage 2 years later when the paperwork is submitted, should they be penalized? And if they have a plan at the time of paperwork submission, should that be allowed? Current practice: focus is on completing transfer and getting accurate info into whois typically if transfers have proper documentation, but resources are under-utilized, they will request return, but will approve the request. Recommendations liberalize the utilization requirements by allowing any of: resources in use at time of acquisition or in use at time of transfer forms or demonstrate they will be utilized within 12 months Leo Bicknell -- ISC -- doesn't like the OR. They could be in use at time of M&A and then abandonded, which isn't quite right. Actual problem is that ARIN needs to find a way to make sure that M&A transfers happen closer to actual event. What if ARIN got a check for payment of fees with a new name, can they flag a start of transfer process much closer to the time event? A: it can be hard to unravel the person paying the check from the company acquisitions involved. Q: you don't want to let someone get away for long periods of time without updating information. How about a penalty financially for not updating M&A information? But often there's no payment coming in for these, often; not getting charged fees. Owen DeLong, he.net; there should be payment coming in for the year assets were transferred seems a worthwhile endeavour. You can't transfer legacy without signing RSA and paying fees. So at time of transfer, they should have started paying money. But they don't accrue back. Present operational practice is not to accrue back. But at the moment, the policy is to charge from the point of the transfer. We should make policy clearer. The issue in this is that there is legacy space, and it goes off into ether for years, and then someone realizes that transfers can be used for hijacking space. The problem isn't really solved, the address space is still there if the transfer is aborted. There's nothing preventing ARIN from reclaiming space from aborted transfers, because they're no longer the holder of record for it anymore. :) He does not like the ORs at all. Tom Watkins, Intellus -- he acquired IP space in past with acquisition; he still pays bill from old company name, it was probably never transferred because it was too much of a hassle. He's current on payment for both, but they go back 8 or 9 years, so the OR really are importnat. Ted Middlestat, current utilization policies are fine, but do not let them keep stale records out there! Scott Liebrand, volunteered to help rewrite it, wants lots of input from people. Now that IPv4 transfers are easy, and don't require M&A documentation, is this easier. Most have ASNS as well which still need this. Next up, AC has many policy proposals on the docket; AC on-docket proposals John Sweeting, advisory council chair Proposals 4 on docket, not yet ready for presentation, prior to open mic period runs through them proposals added to docket or abandonded; if on docket, goes to AC and PPM for discussion Proposal 95: customer confidentiality Proposal 97: waiting list for unmet IPv4 requests proposal 98: last minute assistance for small ISPs proposal 99: /24 minimum allocation PP95: only require names for customers, ISP can provide their address and phone number; but if ARIN requests it ISP must provide it to ARIN. Aaron Wendell PP97--waiting list for unmet IPv4 requests; would require a single contiguous allocation be granted for each request, and create waiting list by stopping people from getting smaller blocks. pp98--last minute assistance for small ISPs, reduce ISP min alloc size from /20 to /23 as the last /8 runs out applies only to last /8, not transfers pp99, owen delong, multihomed end user minimum lowered to /24; getting larger block requires renumbering and giving smaller block back. Your feedback appreciated, lunch conversations were really good. AC to work these with clear goal of developing these into clear policy drafts. Back on schedule. Allowed 1 hour, we have 43 minutes, that should be plenty! Any suggestions, operations. Bill Darte, Wash U, at this meeting and past meetings, we had lunch conversations; we used that time in part to look at these proposals on the dockets; thanks to those at their table, it has been greatly appreciated as they go into deliberation on it. Stan Barber, director of texas IPv6 task force. Appreciation to ARIN for sponsoring initial activity Nov 3 and 4th in Houston, ARIN is gold sponsor, check out the website for more, www.txv6tf.org Ted Middlestat--show of hands on how many want to soften supersonic crash, and how many want to do nothing? Owen--canyon flying, point of no return; canyon is narrow enough you can't turn around, and walls are high enough you can't climb out. Scott liebrand--alternate is a subsonic crash! Ted wants to know if we should work on this, or abandon David's efforts. Chris Grundemann, doesn't like metaphor of crash; IPv4 doesn't stop working, we just can't grow that portion of internet; we can coast to the nearest gas station, or just stop. Kevin Oberman, es.net; this will be a crash, as many companies go belly up, as their business plan turns out to be worthless. There will be a crash, it will be bloody. 33 for crash 27 against the crash Jason Schiller -- verizon -- in favour of crash. We've always had need based policy here; it seems to be a fair approach. Why is what we're moving to "more fair" close to the finish line? Rationing is it increases pain point because they cannot get addresses they need; they can't get what they need sooner. Scott--follow up for Jason; does reducing the time window have that effect, or is it OK because it doesn't actual ration it. Remote: Ted, newspaper and media will call it a supersonic crash. Chris Grundemann -- limiting amount of addresses or time at the end, allows *more* communities to get addresses in areas like Caribbean. less served areas will be completely out. Cathy, Chris' comments made her think about working in ARIN booth at trade shows; their network will continue to work. The great wall will happen because they don't have translation between old network and new network. People's customers still work, they just can't get more. Joe Maimon--why one group over another? The huge companies have had huge advantages up until now; give back time to the rest of the community. Heather--is paul wilson still here? Presentation said help desk requests went up 55% over past year; are people asking about running out of v4, or how to ask about v6? The address requests have gone up 5% in the last year. But he has no idea about what the rest of the questions was. Leo, ISC, Cathy mentioned translation technologies, it's not right for ARIN, but his company is working on that translation tech. We set aside last /10 in the last /8, but we haven't defined what those are. Someone is going to show up and apply in that space for a "translation" technology, we should define it first. Aaron Hughes--gardner--don't sweat move to IPv6; article tells world that IPv6 is just for the military, it's not important for everyone else. Nov 3rd, 2 hour block to talk to Gartner about that and correct that. We can't always catch them in advance. Will ARIN go to analysts to present articles to try to get the right information out first? Trade first, then financial analysts. Joe Maimon; can PDP delay proposals if they feel they are not ready for current adoption, or must they reject for reworking? AC can do anything to the proposal it is deemed necessary. Decisions made in meetings are posted to PPML, you can petition to have your proposal voted on even if AC does not agree. David Farmer, UofMinn; we have been paying attention to Caribbean region recently. There are global political reasons to do this. Should we set aside a chunk of space that would make a really big deal for them, and would probably be 5 minutes of runtime for the rest of the region. Rob Seastrom -- while that's a well meaning sentiment, you're handing those folks a millstone; shipping the garbage somewhere else. Martin Hannigan--they're not teensy weensy, they're smart folks down there, and they'd be offended we try to give them special treatment like that. Woody--this has come up before with LACnic and AfriNIC; everyone would agree that as a social matter, that would be "fair" and "just" in some way. But that a higher fairness and justice is served by having everyone obey the same rules, hence the needs-based allocation. We need to work hard to preserve that at the end as everyone strives in their own self-interest at the endgame. If we suddenly throw out rules to become generous, this opens door to self interest on other parts. Matt, Affilias, it's well meaning, but we've set aside a /10 for transition technologies, it'll serve developing areas as well; we want them on IPv6, so focus on transition elements instead. Leslie Nobile--point of information about multiple discrete networks. Looked at v4, about 12% for ISPs are done under multiple discreet networks. About 300 so far in the life of the policy. Closing mics shortly. Closed. No remote participants. Close of today's meeting at 1640 hours. Fill out your surveys. Ted Middlestat -- thin net works, but isn't used. transitions go faster than we expect. Faster than we expect, IPv4 will become second class when large content moves to IPv6 only. yes, betamax and laserdiscs lasted after the transition, but the mainstream moved on quickly. They'll want it even though they don't know what it is. Cathy responds that her point is exactly that; the networks on v4 will *have* to translate; they won't readdress to v6 instantly. There will be stuff you can't get to one way or the other. Calling all DMRs!! VOTE NOW!! Sponsors, Arbor and Merit. Breakfast tomorrow at 8am, meeting at 9am Agenda is online and in folder. A night at the museum. 6:30 to 10:30, busses at 6, first one out at 6:15, then shuttles back at 8:30-11pm. OK, now we're really done at 1644 hours! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Oct 22 17:26:52 2009 From: bill at herrin.us (William Herrin) Date: Thu, 22 Oct 2009 17:26:52 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE0B4DE.7070607@chl.com> References: <4AE0B4DE.7070607@chl.com> Message-ID: <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> On Thu, Oct 22, 2009 at 3:39 PM, Joe Maimon wrote: > Are you in favor of changing anything at all or can you think of no better > course of action than to continue exactly as is now? Joe, IMO, it's time now to think about what we do *beyond* the end of the free pool when IPv4 addressing policy changes to a zero-sum game. Where giving one org new addresses means taking them from someone else. The address market strategy might work. Ought to work. But we should probably make some contingency plans. As for changes to the policy right now to try to slow the rate of consumption, frankly it's far to late in the day. We'd waste time and acrimony to gain months if we're lucky. That's my 2 cents. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Thu Oct 22 17:36:08 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 22 Oct 2009 14:36:08 -0700 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> Message-ID: <4AE0D048.7080608@gmail.com> William Herrin wrote: > > IMO, it's time now to think about what we do *beyond* the end of the > free pool when IPv4 addressing policy changes to a zero-sum game. > Where giving one org new addresses means taking them from someone > else. > > The address market strategy might work. Ought to work. But we should > probably make some contingency plans. > Have you looked at proposal 97, Waiting List for Unmet IPv4 Requests? I'd be interested in your feedback on whether this would be helpful or not. Here's my latest draft text. It contains some minor updates to address staff concerns that haven't been published anywhere until now. -Scott Replace 4.1.6 with: 4.1.6. Aggregation In order to preserve aggregation, ARIN attempts to issue blocks of addresses on appropriate "CIDR-supported" bit boundaries. As long as sufficient space is available, ARIN may reserve space to maximize aggregation possibilities. ARIN will make each allocation and assignment 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. Each organization may have one approved request on the waiting list at a time. 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 and a re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. 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. From farmer at umn.edu Thu Oct 22 17:23:32 2009 From: farmer at umn.edu (David Farmer) Date: Thu, 22 Oct 2009 16:23:32 -0500 Subject: [arin-ppml] policy proposal 2009-8 EQUITABLE IPv4 RUN-OUT In-Reply-To: References: Message-ID: <4AE0CD54.3080901@umn.edu> For everyone on the list, at the meeting in Dearborn today 2009-8 EQUITABLE IPv4 RUN-OUT was presented. The following are the slides, pick your favored format; https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/thursday/2009-8_presentation.pdf https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PPT/thursday/2009-8_presentation.ppt https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PPT/thursday/2009-8_presentation.pptx The current full policy is at; https://www.arin.net/policy/proposals/2009_8.html I would like feed back from the list on the proposed modification to the triggers of the first part of the policy; Remove this; When IANA reaches 20 or fewer unallocated /8s, an organization may choose to request up to a 6 month supply of IP addresses; When IANA reaches 10 or fewer unallocated /8s, an organization may choose to request up to a 3 month supply of IP addresses; And replace it with; When IANA reaches 10 or fewer unallocated /8s, an organization may choose to request up to a 6 month supply of IP addresses; There seemed to have been support for this on the floor here in Dearborn. Also there was an editorial change proposed; In the NRPM 4.2.4.4 is currently titled 4.2.4.4 Twelve months Staff recommended a new title, which is included in this Draft Policy 4.2.4.4 Subscriber Members After One Year I while back I asked about NRPM 4.2.4.3 which is currently titled 4.2.4.3 Three months For consistency and clarity we recommend the AC also change this to 4.2.4.3 Subscriber Members Less Than One Year Any feedback before the AC meeting tomorrow afternoon would be appreciated. Thanks John Schnizlein wrote: > Having failed to say this during my opportunity at the mic, this policy > is not so much about any organization that gets one of the last few > allocations. The policy is to reduce the degree of outrage, or at least > sympathy for that outrage, by the organization that is among the first > who are told the addresses are all gone. > > It really does not matter how "terminally stupid" (as described at the > mic) this party is, they can make a lot of trouble that we can preclude > now. > > John > _______________________________________________ > 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. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jmaimon at chl.com Thu Oct 22 17:43:57 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 22 Oct 2009 17:43:57 -0400 Subject: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes In-Reply-To: <63ac96a50910221403k5f4f77dq51aafe6466e88294@mail.gmail.com> References: <63ac96a50910221403k5f4f77dq51aafe6466e88294@mail.gmail.com> Message-ID: <4AE0D21D.1060908@chl.com> Thanks Matt! Matthew Petach wrote: > > Draft policy 2009-8: equitable IPv4 run-out > June 8th, 2009, draft policy 2009 aug 31 > > similar policies in all regions. > Ted Middlestat--in favour of policy, though he doesn't > think policy will help; orgs who are smart will move > to IPv6. The stupid ones will be gaming the system > anyhow, and generating bogus needs. Orgs that need a /17 > will generate requests for /15s instead. The Friday > night party will be all the procrastinators who haven't > prepared, and will be out of business 6 months later. > So, this is harmless anyhow. > Joe Maimon supports the policy; if one or a few big > players clear out the final supply, we can end up with > a prime time sound bite. ARIN should aim to prevent > gaming. (2:26:17 PM) jmaimon: Joe Maimon - CHL, Pronouncable in many equally correct ways, but usually as Maymin or Mymin with equal stress on each half. I support this policy. I think that a scenario described where all scarce resources are cleaned out by one or a few big players could be the final black eye for the rir system in the eyes of many. It may even create a prime time news sound bite. I do not believe this policy is the be all end all, but I do not believe that policies should address potential gaming, ARIN staff is responsible as always for detecting and preventing gaming. > Policies reviewed > identify invalid whois POC 2008-7 > not fully implemented, some issues to bring to community > and get feedback > Ted; if you don't support sending email to the downstream, > raise policy to change NRPM. > > Joe Maimon, if you don't agree with this, emergency policy > action may be needed. (3:50:41 PM) jmaimon: Yes, but if ARIN is going to delay implementation, then emergency policy action to excise reassignments is actually more apropriate I made this comment to address Chris concern that a complete review occur before run out, I suggested that instead of waiting policy cycle without implementation, this could qualify for the BoT to take more prompt action. From warren at wholesaleinternet.com Thu Oct 22 17:44:46 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Thu, 22 Oct 2009 16:44:46 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> Message-ID: <7C39BE64BA364E768F6362D79FAC9AE6@johnsonvhjjf8v> agreed -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, October 22, 2009 4:27 PM To: Joe Maimon Cc: ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern On Thu, Oct 22, 2009 at 3:39 PM, Joe Maimon wrote: > Are you in favor of changing anything at all or can you think of no > better course of action than to continue exactly as is now? Joe, IMO, it's time now to think about what we do *beyond* the end of the free pool when IPv4 addressing policy changes to a zero-sum game. Where giving one org new addresses means taking them from someone else. The address market strategy might work. Ought to work. But we should probably make some contingency plans. As for changes to the policy right now to try to slow the rate of consumption, frankly it's far to late in the day. We'd waste time and acrimony to gain months if we're lucky. That's my 2 cents. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ 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 warren at wholesaleinternet.com Thu Oct 22 17:50:25 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Thu, 22 Oct 2009 16:50:25 -0500 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <4AE0D048.7080608@gmail.com> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> Message-ID: <581B4C9D0B6444FBBD14D86529703C1C@johnsonvhjjf8v> I like it. It basically says "if you want some Ips from the free pool, then you're going to have to request an amount we can reasonably provide". It's going to force orgs to request strategically based on what they can get. I am not a fan of the idea of stockpiling IP addreses until you have enough to meet a really large request as it precludes all those smaller requests from getting filled. In addition, it allows a large requestor to essentially lock-out allocations for an extended period of time. Besides, companies that need big blocks can just buy up orgs with those size blocks. It's a good policy and gets us through the last few allocations before exhaustion. I think we need it so we are covering all bases. At the end of the day, I don't reckon much freespace will come BACK post-exhaustion so the policy is made moot. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Thursday, October 22, 2009 4:36 PM To: William Herrin Cc: ppml at arin.net Subject: [arin-ppml] Post-exhaustion IPv4 policy William Herrin wrote: > > IMO, it's time now to think about what we do *beyond* the end of the > free pool when IPv4 addressing policy changes to a zero-sum game. > Where giving one org new addresses means taking them from someone > else. > > The address market strategy might work. Ought to work. But we should > probably make some contingency plans. > Have you looked at proposal 97, Waiting List for Unmet IPv4 Requests? I'd be interested in your feedback on whether this would be helpful or not. Here's my latest draft text. It contains some minor updates to address staff concerns that haven't been published anywhere until now. -Scott Replace 4.1.6 with: 4.1.6. Aggregation In order to preserve aggregation, ARIN attempts to issue blocks of addresses on appropriate "CIDR-supported" bit boundaries. As long as sufficient space is available, ARIN may reserve space to maximize aggregation possibilities. ARIN will make each allocation and assignment 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. Each organization may have one approved request on the waiting list at a time. 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 and a re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. 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. _______________________________________________ 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 warren at wholesaleinternet.com Thu Oct 22 16:00:19 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Thu, 22 Oct 2009 15:00:19 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE0B4DE.7070607@chl.com> References: <4AE0B4DE.7070607@chl.com> Message-ID: Joe, This goes back to my point from last week about factions. Right now things are divided but reasonably civil. Come post-exhaustion we may find the battlelines drawn and the factions competing more ferociously thus eroding cooperation in the ipv4 space. Right now as a group we can draw up the relevant policy without concern of corporate or government interference. If those policies are in place when the well dries up we will have a much better chance of weathering the storm together in the years before true ipv6 adoption. On the other hand, if we don't have proper REALISTIC policy in place, and the well dries up, we may be making this policy under intense corporate and governmental scrutiny. Not a place I want to be. Also, lest you think we have several years to come to an agreement consider that Ben Edelman is working furiously on an estimate for IPv4 cost post-exhaustion. I don't have to draw you a picture of what's going to happen if he comes back with a high per-IP dollar figure. When in line to buy milk at the store, we are very cordial but if there is a shortage of milk, and I need it for my toddler, things can get prickly very quickly. Rhyme unintentional. Thanks, Warren -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Maimon Sent: Thursday, October 22, 2009 2:39 PM To: ppml at arin.net Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern 2009-8, the latest in a number of attempts to deal with the upcoming depletion appears to show a community still divided. This raises for me the underlying question and I would appreciate any feedback. Are you in favor of changing anything at all or can you think of no better course of action than to continue exactly as is now? Offlist replies will remain private, summarized if appropriate. Joe _______________________________________________ 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 bill at herrin.us Thu Oct 22 18:12:05 2009 From: bill at herrin.us (William Herrin) Date: Thu, 22 Oct 2009 18:12:05 -0400 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <4AE0D048.7080608@gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> Message-ID: <3c3e3fca0910221512h2b171916t13e2870d6f01394b@mail.gmail.com> On Thu, Oct 22, 2009 at 5:36 PM, Scott Leibrand wrote: > William Herrin wrote: >> The address market strategy might work. Ought to work. But we should >> probably make some contingency plans. > > Have you looked at proposal 97, Waiting List for Unmet IPv4 Requests? ?I'd > be interested in your feedback on whether this would be helpful or not. Scott, It seems like a reasonable place to start. I have two concerns: 1. If I request a /16 and you tell me you only have a /18, what's to stop me from saying "Okay, give me the /18" and then two days later saying, "Okay, put me on the wait list for a /16." 2. How is giving me the /18 fair to the guy who is on the waiting list for a /17? There's no guidance in the policy as to how ARIN is supposed to build up enough addresses to satisfy that /17 request. This also doesn't address how ARIN is going to get the addresses to fill the waiting list in the first place, but I gather you intend that to be a separate policy issue. #1 is probably not too hard. Just say that so long as anyone is on the wait list, 1 year must elapse between requests from any single org for IPs. Favor those with patience: a guy on the wait list for 8 months when his request is filled waits only 4 more months before he can make another request. No answers jump out at me for #2. FIFO is just as bad or worse. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Thu Oct 22 18:13:26 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 22 Oct 2009 15:13:26 -0700 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <3c3e3fca0910221503y115d6d8du5f0a4a41d6ff7f16@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> <3c3e3fca0910221503y115d6d8du5f0a4a41d6ff7f16@mail.gmail.com> Message-ID: <4AE0D906.60105@gmail.com> William Herrin wrote: > On Thu, Oct 22, 2009 at 5:36 PM, Scott Leibrand wrote: > >>> The address market strategy might work. Ought to work. But we should >>> probably make some contingency plans. >>> >> Have you looked at proposal 97, Waiting List for Unmet IPv4 Requests? I'd >> be interested in your feedback on whether this would be helpful or not. >> > > Scott, > > It seems like a reasonable place to start. I have two concerns: > > 1. If I request a /16 and you tell me you only have a /18, what's to > stop me from saying "Okay, give me the /18" and then two days later > saying, "Okay, put me on the wait list for a /16." > The policy attempts to address that, in a deliberately vague statement that "Repeated requests, in a manner that would circumvent 4.1.6, are not allowed." The idea, of course, is to give ARIN staff leeway to use their excellent fraud detection skills, combined with operational procedures that can be adjusted as needed. > 2. How is giving me the /18 fair to the guy who is on the waiting list > for a /17? There's no guidance in the policy as to how ARIN is > supposed to build up enough addresses to satisfy that /17 request. > My take on this is similar to what Warren just posted. Basically, if the /17 holder will settle for a /18, he can change his request to be for the smaller size, and he'll be in the list before you. If he wants to hold out for that /17 to be returned, he's welcome to. But more than likely, he'll go find his own /17 on the transfer market before that. > This also doesn't address how ARIN is going to get the addresses to > fill the waiting list in the first place, but I gather you intend that > to be a separate policy issue. > > #1 is probably not too hard. Just say that so long as anyone is on the > wait list, 1 year must elapse between requests from any single org for > IPs. Favor those with patience: a guy on the wait list for 8 months > when his request is filled waits only 4 more months before he can make > another request. > I considered that, but I thought it better to leave it up to staff. If it turns out that we need a time limit, we can do that, but then we have to define it in advance in policy. My initial thought was 6 months, but perhaps if David's policy advances as modified, 3 months would be better. -Scott > No answers jump out at me for #2. FIFO is just as bad or worse. > > Regards, > Bill Herrin > > > > From jmaimon at chl.com Thu Oct 22 18:23:26 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 22 Oct 2009 18:23:26 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> Message-ID: <4AE0DB5E.1040502@chl.com> William Herrin wrote: > On Thu, Oct 22, 2009 at 3:39 PM, Joe Maimon wrote: > >> Are you in favor of changing anything at all or can you think of no better >> course of action than to continue exactly as is now? >> > > Joe, > > IMO, it's time now to think about what we do *beyond* the end of the > free pool when IPv4 addressing policy changes to a zero-sum game. > Where giving one org new addresses means taking them from someone > else. > The address market strategy might work. Ought to work. But we should > probably make some contingency plans. > Ration, Reclaim, Return, Reuse. Those are the alternatives to transfers based on market principles. I greatly prefer the market which is why I advocated for it, but policy for what to do with reclaimed space after depletion is still needed and any approach to it that doesnt consist of giving it all to whoever can show need will smack of rationing. And in the strictest sense of the word they are correct, it is rationing. However supply and demand markets are also a form of rationing, so the word in and of itself does not carry automatic negative connotations. Only in a worst case scenario where neither transfers or returns are meeting even a portions of needs and ipv6 is not obviating ipv4 need should any attention be given to reclaimation of non-abandoned resources. > As for changes to the policy right now to try to slow the rate of > consumption, frankly it's far to late in the day. We'd waste time and > acrimony to gain months if we're lucky. > > That's my 2 cents. > > Regards, > Bill Herrin > > > I think we have one more real opportunity to advance depletion polices from start to implementation before depletion. Joe From bill at herrin.us Thu Oct 22 18:25:48 2009 From: bill at herrin.us (William Herrin) Date: Thu, 22 Oct 2009 18:25:48 -0400 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <4AE0D906.60105@gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> <3c3e3fca0910221503y115d6d8du5f0a4a41d6ff7f16@mail.gmail.com> <4AE0D906.60105@gmail.com> Message-ID: <3c3e3fca0910221525v546aa3c9l461c5469c3ab5aa3@mail.gmail.com> On Thu, Oct 22, 2009 at 6:13 PM, Scott Leibrand wrote: > William Herrin wrote: >> 1. If I request a /16 and you tell me you only have a /18, what's to >> stop me from saying "Okay, give me the /18" and then two days later >> saying, "Okay, put me on the wait list for a /16." > > The policy attempts to address that, in a deliberately vague statement that > "Repeated requests, in a manner that would > circumvent 4.1.6, are not allowed." ?The idea, of course, is to give ARIN > staff leeway to use their excellent fraud detection skills, combined with > operational procedures that can be adjusted as needed. Hi Scott, Staff will be making such decisions under intense scrutiny. Any judgment they're forced to exercise will tend to be the most lenient the policy allows. Which is to say: no restriction on repeat requests at all. Giving staff discretion can be a good thing if done with appropriate checks, but you also have to give them a policy vehicle that validates and reinforces that discretion. In other words, it's better to say, "You can have 1 a day but staff can waive the requirement" than "you can have as many as you want but staff can limit you to 1 a day." >> 2. How is giving me the /18 fair to the guy who is on the waiting list >> for a /17? There's no guidance in the policy as to how ARIN is >> supposed to build up enough addresses to satisfy that /17 request. > > My take on this is similar to what Warren just posted. ?Basically, if the > /17 holder will settle for a /18, he can change his request to be for the > smaller size, and he'll be in the list before you. ?If he wants to hold out > for that /17 to be returned, he's welcome to. ?But more than likely, he'll > go find his own /17 on the transfer market before that. Most likely he'll take the /18 and then go find a bunch of /24's on the transfer market. Which defeats the purpose both of having a waiting list and of trying to build to aggregation. That's why it concerns me. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at chl.com Thu Oct 22 18:31:06 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 22 Oct 2009 18:31:06 -0400 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <4AE0D048.7080608@gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> Message-ID: <4AE0DD2A.90904@chl.com> Scott Leibrand wrote: > William Herrin wrote: > > Have you looked at proposal 97, Waiting List for Unmet IPv4 Requests? > I'd be interested in your feedback on whether this would be helpful or not. > > Here's my latest draft text. It contains some minor updates to address > staff concerns that haven't been published anywhere until now. > > -Scott It does allow the pool to be cleaned out at once. But its not a bad approach aside from that problem, which is controversial. From scottleibrand at gmail.com Thu Oct 22 23:19:29 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 22 Oct 2009 23:19:29 -0400 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <4AE0DD2A.90904@chl.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> <4AE0DD2A.90904@chl.com> Message-ID: <87A66EB0-EBDE-433A-A8F6-2F9232C6AF8E@gmail.com> On Oct 22, 2009, at 6:31 PM, Joe Maimon wrote: > > > Scott Leibrand wrote: >> William Herrin wrote: >> >> Have you looked at proposal 97, Waiting List for Unmet IPv4 >> Requests? I'd be interested in your feedback on whether this would >> be helpful or not. >> Here's my latest draft text. It contains some minor updates to >> address staff concerns that haven't been published anywhere until >> now. >> -Scott > > > > It does allow the pool to be cleaned out at once. But its not a bad > approach aside from that problem, which is controversial. Yeah, it is really designed to deal with the post-exhaustion phase rather than the endgame. Scott From mpetach at netflight.com Thu Oct 22 23:52:27 2009 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 22 Oct 2009 20:52:27 -0700 Subject: [arin-ppml] policy proposal 2009-8 EQUITABLE IPv4 RUN-OUT In-Reply-To: <4AE0CD54.3080901@umn.edu> References: <4AE0CD54.3080901@umn.edu> Message-ID: <63ac96a50910222052y122b358fqb9e0b537e0615c6@mail.gmail.com> On Thu, Oct 22, 2009 at 2:23 PM, David Farmer wrote: > For everyone on the list, at the meeting in Dearborn today 2009-8 EQUITABLE > IPv4 RUN-OUT was presented. > ... > I would like feed back from the list on the proposed modification to the > triggers of the first part of the policy; > > Remove this; > > When IANA reaches 20 or fewer unallocated /8s, an organization may choose > to request up to a 6 month supply of IP addresses; > > When IANA reaches 10 or fewer unallocated /8s, an organization may choose > to request up to a 3 month supply of IP addresses; > > And replace it with; > > When IANA reaches 10 or fewer unallocated /8s, an organization may choose > to request up to a 6 month supply of IP addresses; > > There seemed to have been support for this on the floor here in Dearborn. > I am in favour of the proposal with that modification, yes. > Also there was an editorial change proposed; > > In the NRPM 4.2.4.4 is currently titled > > 4.2.4.4 Twelve months > > Staff recommended a new title, which is included in this Draft Policy > > 4.2.4.4 Subscriber Members After One Year > > I while back I asked about NRPM 4.2.4.3 which is currently titled > > 4.2.4.3 Three months > > For consistency and clarity we recommend the AC also change this to > > 4.2.4.3 Subscriber Members Less Than One Year > > Any feedback before the AC meeting tomorrow afternoon would be appreciated. > > That sounds like a smashingly good pair of changes. Matt > Thanks > > > John Schnizlein wrote: > >> Having failed to say this during my opportunity at the mic, this policy is >> not so much about any organization that gets one of the last few >> allocations. The policy is to reduce the degree of outrage, or at least >> sympathy for that outrage, by the organization that is among the first who >> are told the addresses are all gone. >> >> It really does not matter how "terminally stupid" (as described at the >> mic) this party is, they can make a lot of trouble that we can preclude now. >> >> John >> _______________________________________________ >> 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. >> > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > _______________________________________________ > 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvest at eyeconomics.com Thu Oct 22 21:13:49 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 22 Oct 2009 21:13:49 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE0DB5E.1040502@chl.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> Message-ID: <827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> >>> Are you in favor of changing anything at all or can you think of >>> no better >>> course of action than to continue exactly as is now? >>> >> >> >> IMO, it's time now to think about what we do *beyond* the end of the >> free pool when IPv4 addressing policy changes to a zero-sum game. >> Where giving one org new addresses means taking them from someone >> else. >> The address market strategy might work. Ought to work. But we should >> probably make some contingency plans. >> > > Ration, Reclaim, Return, Reuse. > > Those are the alternatives to transfers based on market principles. > I greatly prefer the market which is why I advocated for it, but > policy for what to do with reclaimed space after depletion is still > needed and any approach to it that doesnt consist of giving it all > to whoever can show need will smack of rationing. > > And in the strictest sense of the word they are correct, it is > rationing. However supply and demand markets are also a form of > rationing, so the word in and of itself does not carry automatic > negative connotations. > > Only in a worst case scenario where neither transfers or returns are > meeting even a portions of needs and ipv6 is not obviating ipv4 need > should any attention be given to reclaimation of non-abandoned > resources. Is anyone else experiencing any cognitive dissonance here? A. No clear community consensus in favor of mitigating the impact of IPv4 runout; many concerns raised about the fairness of depriving current IPv4 holders of anything less than the max. IPv4 that they can justify between now and runout. B. No significant likelihood of anything close to IPv6 substitutability in the foreseeable future; zero probability before IPv4 runout. C. No apparent acknowledgement of what this implies for anyone/ everything who might need -- and be able to justify -- "usable" IP addresses of any kind after IPv4 runout. D. *** IMO, this combination suggests that it would be prudent to anticipate that the "worst case scenario" as described above is also the highest probability scenario, by a wide margin. It's still not too late for some version of prior planning... TV From bill at herrin.us Fri Oct 23 08:53:35 2009 From: bill at herrin.us (William Herrin) Date: Fri, 23 Oct 2009 08:53:35 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE0DB5E.1040502@chl.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> Message-ID: <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> On Thu, Oct 22, 2009 at 6:23 PM, Joe Maimon wrote: > Only in a worst case scenario where neither transfers or returns are meeting > even a portions of needs and ipv6 is not obviating ipv4 need should any > attention be given to reclaimation of non-abandoned resources. Hi Joe, Then before we talk about what a draconian address recovery policy looks like, perhaps we should consider the circumstances under which such a policy should be employed. My thought is that a darp should be activated when all of the following conditions are met: 1. IANA has allocated the last /8 to an RIR 2. ARIN is unable to meet a qualified request for a /18 or larger. 3. The BoT determines that blocks of ARIN-managed IP addresses of /24 and larger are not generally available for purchase via the transfer market for less than $10/address. Your thoughts? Regards, Bill Herrin > >> As for changes to the policy right now to try to slow the rate of >> consumption, frankly it's far to late in the day. We'd waste time and >> acrimony to gain months if we're lucky. >> >> That's my 2 cents. >> >> Regards, >> Bill Herrin >> >> >> > > I think we have one more real opportunity to advance depletion polices from > start to implementation before depletion. > > Joe > -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mpetach at netflight.com Fri Oct 23 09:07:58 2009 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 23 Oct 2009 06:07:58 -0700 Subject: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes In-Reply-To: <4AE0D21D.1060908@chl.com> References: <63ac96a50910221403k5f4f77dq51aafe6466e88294@mail.gmail.com> <4AE0D21D.1060908@chl.com> Message-ID: <63ac96a50910230607p4c81709x10e5df8cf80f9a59@mail.gmail.com> Thanks for the corrections--it's harder to jot down the text being read from the remote participants, because the person reading it doesn't have to pause to think, the way everyone else in the room has to--which tends to overrun my internal buffer, leading to more dropped bits in the notes. ^_^; Maybe I should put these on a twiki so they can be edited directly afterwards. :) Thanks again! Matt On Thu, Oct 22, 2009 at 2:43 PM, Joe Maimon wrote: > Thanks Matt! > > Matthew Petach wrote: > > > >> Draft policy 2009-8: equitable IPv4 run-out >> June 8th, 2009, draft policy 2009 aug 31 >> >> similar policies in all regions. >> > > > > > Ted Middlestat--in favour of policy, though he doesn't >> think policy will help; orgs who are smart will move >> to IPv6. The stupid ones will be gaming the system >> anyhow, and generating bogus needs. Orgs that need a /17 >> will generate requests for /15s instead. The Friday >> night party will be all the procrastinators who haven't >> prepared, and will be out of business 6 months later. >> So, this is harmless anyhow. >> > > > > Joe Maimon supports the policy; if one or a few big >> players clear out the final supply, we can end up with >> a prime time sound bite. ARIN should aim to prevent >> gaming. >> > > (2:26:17 PM) jmaimon: Joe Maimon - CHL, Pronouncable in many equally > correct ways, but usually as Maymin or Mymin with equal stress on each half. > > I support this policy. I think that a scenario described where all scarce > resources are cleaned out by one or a few big players could be the final > black eye for the rir system in the eyes of many. It may even create a prime > time news sound bite. I do not believe this policy is the be all end all, > but I do not believe that policies should address potential gaming, ARIN > staff is responsible as always for detecting and preventing gaming. > > > > Policies reviewed >> identify invalid whois POC 2008-7 >> not fully implemented, some issues to bring to community >> and get feedback >> > > > Ted; if you don't support sending email to the downstream, >> raise policy to change NRPM. >> >> Joe Maimon, if you don't agree with this, emergency policy >> action may be needed. >> > > (3:50:41 PM) jmaimon: Yes, but if ARIN is going to delay implementation, > then emergency policy action to excise reassignments is actually more > apropriate > > > I made this comment to address Chris concern that a complete review occur > before run out, I suggested that instead of waiting policy cycle without > implementation, this could qualify for the BoT to take more prompt action. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaimon at chl.com Fri Oct 23 09:21:41 2009 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 23 Oct 2009 09:21:41 -0400 Subject: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes In-Reply-To: <63ac96a50910230607p4c81709x10e5df8cf80f9a59@mail.gmail.com> References: <63ac96a50910221403k5f4f77dq51aafe6466e88294@mail.gmail.com> <4AE0D21D.1060908@chl.com> <63ac96a50910230607p4c81709x10e5df8cf80f9a59@mail.gmail.com> Message-ID: <4AE1ADE5.5010002@chl.com> Being as remote comments are copy pasteable from my jabber window, I think I have an unfair advantage. I dont think there is any reason locals cant hang out in the jabber chat as well. Matthew Petach wrote: > > Thanks for the corrections--it's harder to jot down the text being > read from the remote participants, because the person reading > it doesn't have to pause to think, the way everyone else in the > room has to--which tends to overrun my internal buffer, leading > to more dropped bits in the notes. ^_^; > > Maybe I should put these on a twiki so they can be edited > directly afterwards. :) > > Thanks again! > > Matt > > > > On Thu, Oct 22, 2009 at 2:43 PM, Joe Maimon > wrote: > > Thanks Matt! > > > Matthew Petach wrote: > > > > Draft policy 2009-8: equitable IPv4 run-out > June 8th, 2009, draft policy 2009 aug 31 > > similar policies in all regions. > > > > > > Ted Middlestat--in favour of policy, though he doesn't > think policy will help; orgs who are smart will move > to IPv6. The stupid ones will be gaming the system > anyhow, and generating bogus needs. Orgs that need a /17 > will generate requests for /15s instead. The Friday > night party will be all the procrastinators who haven't > prepared, and will be out of business 6 months later. > So, this is harmless anyhow. > > > > > Joe Maimon supports the policy; if one or a few big > players clear out the final supply, we can end up with > a prime time sound bite. ARIN should aim to prevent > gaming. > > > (2:26:17 PM) jmaimon: Joe Maimon - CHL, Pronouncable in many > equally correct ways, but usually as Maymin or Mymin with equal > stress on each half. > > I support this policy. I think that a scenario described where all > scarce resources are cleaned out by one or a few big players could > be the final black eye for the rir system in the eyes of many. It > may even create a prime time news sound bite. I do not believe > this policy is the be all end all, but I do not believe that > policies should address potential gaming, ARIN staff is > responsible as always for detecting and preventing gaming. > > > > > Policies reviewed > identify invalid whois POC 2008-7 > not fully implemented, some issues to bring to community > and get feedback > > > > Ted; if you don't support sending email to the downstream, > raise policy to change NRPM. > > Joe Maimon, if you don't agree with this, emergency policy > action may be needed. > > > (3:50:41 PM) jmaimon: Yes, but if ARIN is going to delay > implementation, then emergency policy action to excise > reassignments is actually more apropriate > > > I made this comment to address Chris concern that a complete > review occur before run out, I suggested that instead of waiting > policy cycle without implementation, this could qualify for the > BoT to take more prompt action. > > From spiffnolee at yahoo.com Fri Oct 23 09:29:34 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 23 Oct 2009 06:29:34 -0700 (PDT) Subject: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes In-Reply-To: <63ac96a50910230607p4c81709x10e5df8cf80f9a59@mail.gmail.com> References: <63ac96a50910221403k5f4f77dq51aafe6466e88294@mail.gmail.com> <4AE0D21D.1060908@chl.com> <63ac96a50910230607p4c81709x10e5df8cf80f9a59@mail.gmail.com> Message-ID: <535773.80575.qm@web63302.mail.re1.yahoo.com> I think these notes are probably very useful for a lot of people, but I wouldn't worry too much about exact wording. I believe a transcript will be made available as part of the Meeting Report, look near https://www.arin.net/participate/meetings/ARIN-XXIV/index.html about November 4. You can use that as a source for exact wording or just point that way. Lee > >From: Matthew Petach >To: Joe Maimon >Cc: PPML ppml >Sent: Fri, October 23, 2009 9:07:58 AM >Subject: Re: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes > > >Thanks for the corrections--it's harder to jot down the text being >read from the remote participants, because the person reading >it doesn't have to pause to think, the way everyone else in the >room has to--which tends to overrun my internal buffer, leading >>to more dropped bits in the notes. ^_^; > >Maybe I should put these on a twiki so they can be edited >directly afterwards. :) > >Thanks again! > >Matt > > > > >On Thu, Oct 22, 2009 at 2:43 PM, Joe Maimon wrote: > >Thanks Matt! >> >> >>>>Matthew Petach wrote: >> >> >> >> >>>>>>Draft policy 2009-8: equitable IPv4 run-out >>>>>>June 8th, 2009, draft policy 2009 aug 31 >>> >>>>>>similar policies in all regions. >>> >> >> >> >> >>>>>Ted Middlestat--in favour of policy, though he doesn't >>>>>>think policy will help; orgs who are smart will move >>>>>>to IPv6. The stupid ones will be gaming the system >>>>>>anyhow, and generating bogus needs. Orgs that need a /17 >>>>>>will generate requests for /15s instead. The Friday >>>>>>night party will be all the procrastinators who haven't >>>>>>prepared, and will be out of business 6 months later. >>>>>>So, this is harmless anyhow. >>> >> >> >> >>>>>Joe Maimon supports the policy; if one or a few big >>>>>>players clear out the final supply, we can end up with >>>>>>a prime time sound bite. ARIN should aim to prevent >>>>>>gaming. >>> >> >>(2:26:17 PM) jmaimon: Joe Maimon - CHL, Pronouncable in many equally correct ways, but usually as Maymin or Mymin with equal stress on each half. >> >>>>I support this policy. I think that a scenario described where all scarce resources are cleaned out by one or a few big players could be the final black eye for the rir system in the eyes of many. It may even create a prime time news sound bite. I do not believe this policy is the be all end all, but I do not believe that policies should address potential gaming, ARIN staff is responsible as always for detecting and preventing gaming. >> >> >> >> >> >>>>>Policies reviewed >>>>>>identify invalid whois POC 2008-7 >>>>>> not fully implemented, some issues to bring to community >>>>>> and get feedback >>> >> >> >>>>>Ted; if you don't support sending email to the downstream, >>>>>>raise policy to change NRPM. >>> >>>>>>Joe Maimon, if you don't agree with this, emergency policy >>>>>>action may be needed. >>> >> >>(3:50:41 PM) jmaimon: Yes, but if ARIN is going to delay implementation, then emergency policy action to excise reassignments is actually more apropriate >> >> >>>>I made this comment to address Chris concern that a complete review occur before run out, I suggested that instead of waiting policy cycle without implementation, this could qualify for the BoT to take more prompt action. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Oct 23 09:40:53 2009 From: jcurran at arin.net (John Curran) Date: Fri, 23 Oct 2009 09:40:53 -0400 Subject: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes In-Reply-To: <535773.80575.qm@web63302.mail.re1.yahoo.com> References: <63ac96a50910221403k5f4f77dq51aafe6466e88294@mail.gmail.com> <4AE0D21D.1060908@chl.com> <63ac96a50910230607p4c81709x10e5df8cf80f9a59@mail.gmail.com> <535773.80575.qm@web63302.mail.re1.yahoo.com> Message-ID: Correct. For example, the presentations and official transcripts for San Antonio are available here: That doesn't mean that this quick notes aren't valuable, they have the strong advantage of timeliness... (whereas the transcripts show up several weeks after) Thanks for all your efforts Matt! /John On Oct 23, 2009, at 9:29 AM, Lee Howard wrote: I think these notes are probably very useful for a lot of people, but I wouldn't worry too much about exact wording. I believe a transcript will be made available as part of the Meeting Report, look nearhttps://www.arin.net/participate/meetings/ARIN-XXIV/index.html about November 4. You can use that as a source for exact wording or just point that way. Lee From: Matthew Petach > To: Joe Maimon > Cc: PPML ppml > Sent: Fri, October 23, 2009 9:07:58 AM Subject: Re: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes Thanks for the corrections--it's harder to jot down the text being read from the remote participants, because the person reading it doesn't have to pause to think, the way everyone else in the room has to--which tends to overrun my internal buffer, leading to more dropped bits in the notes. ^_^; Maybe I should put these on a twiki so they can be edited directly afterwards. :) Thanks again! Matt On Thu, Oct 22, 2009 at 2:43 PM, Joe Maimon > wrote: Thanks Matt! Matthew Petach wrote: Draft policy 2009-8: equitable IPv4 run-out June 8th, 2009, draft policy 2009 aug 31 similar policies in all regions. Ted Middlestat--in favour of policy, though he doesn't think policy will help; orgs who are smart will move to IPv6. The stupid ones will be gaming the system anyhow, and generating bogus needs. Orgs that need a /17 will generate requests for /15s instead. The Friday night party will be all the procrastinators who haven't prepared, and will be out of business 6 months later. So, this is harmless anyhow. Joe Maimon supports the policy; if one or a few big players clear out the final supply, we can end up with a prime time sound bite. ARIN should aim to prevent gaming. (2:26:17 PM) jmaimon: Joe Maimon - CHL, Pronouncable in many equally correct ways, but usually as Maymin or Mymin with equal stress on each half. I support this policy. I think that a scenario described where all scarce resources are cleaned out by one or a few big players could be the final black eye for the rir system in the eyes of many. It may even create a prime time news sound bite. I do not believe this policy is the be all end all, but I do not believe that policies should address potential gaming, ARIN staff is responsible as always for detecting and preventing gaming. Policies reviewed identify invalid whois POC 2008-7 not fully implemented, some issues to bring to community and get feedback Ted; if you don't support sending email to the downstream, raise policy to change NRPM. Joe Maimon, if you don't agree with this, emergency policy action may be needed. (3:50:41 PM) jmaimon: Yes, but if ARIN is going to delay implementation, then emergency policy action to excise reassignments is actually more apropriate I made this comment to address Chris concern that a complete review occur before run out, I suggested that instead of waiting policy cycle without implementation, this could qualify for the BoT to take more prompt action. _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaimon at chl.com Fri Oct 23 09:41:55 2009 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 23 Oct 2009 09:41:55 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> Message-ID: <4AE1B2A3.1010307@chl.com> William Herrin wrote: > On Thu, Oct 22, 2009 at 6:23 PM, Joe Maimon wrote: > >> Only in a worst case scenario where neither transfers or returns are meeting >> even a portions of needs and ipv6 is not obviating ipv4 need should any >> attention be given to reclaimation of non-abandoned resources. >> > > Hi Joe, > > Then before we talk about what a draconian address recovery policy > looks like, perhaps we should consider the circumstances under which > such a policy should be employed. > > My thought is that a darp should be activated when all of the > following conditions are met: > > 1. IANA has allocated the last /8 to an RIR > 2. ARIN is unable to meet a qualified request for a /18 or larger. > 3. The BoT determines that blocks of ARIN-managed IP addresses of /24 > and larger are not generally available for purchase via the transfer > market for less than $10/address. > > Your thoughts? > > Regards, > Bill Herrin > > > I really dont know what price per address would be considered reasonable per target market for ipv4 and at which point in time it will go up or down. Already, reputable companies are charging more for static blocks of addresses, at a significant markup from their ARIN prices (but at prices ranging from .5 per address to .001 per address thats easily achievable). We should consider some other factors, such as whether or not the returns and reclaims, which are fairly significant even if trickles in the bucket of current demand, will dry up after depletion and resulting value changes for ipv4, whether IPv6 adoption is actually measurably increasing and how the political and public winds are blowing. And fee changes should also be a factor considered well before darp. But that is not policy. Really hoping that things never get as far as the darrrrp and I doubt that people would knowingly chart that direction. Joe From rudi.daniel at gmail.com Fri Oct 23 09:54:23 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Fri, 23 Oct 2009 09:54:23 -0400 Subject: [arin-ppml] ARIN-Meeting ARIN notes Message-ID: <8aeeaff60910230654w39521786nb0e30349700bdcf@mail.gmail.com> Since I have been unable to actively participate at this meet, the meeting notes have been extremely useful in keeping me abreast of whats going down...thx Matt RD I think these notes are probably very useful for a lot of people, but I > wouldn't worry too much about exact wording. I believe a transcript will be > made available as part of the Meeting Report, look near > https://www.arin.net/participate/meetings/ARIN-XXIV/index.html about > November 4. You can use that as a source for exact wording or just point > that way. > > Lee > > > > > >From: Matthew Petach > >To: Joe Maimon > >Cc: PPML ppml > >Sent: Fri, October 23, 2009 9:07:58 AM > >Subject: Re: [arin-ppml] 2009.10.22 ARIN 24 day 2 part 2 notes > > > > > >Thanks for the corrections--it's harder to jot down the text being > >read from the remote participants, because the person reading > >it doesn't have to pause to think, the way everyone else in the > >room has to--which tends to overrun my internal buffer, leading > >>to more dropped bits in the notes. ^_^; > > > >Maybe I should put these on a twiki so they can be edited > >directly afterwards. :) > > > >Thanks again! > > > >Matt > > > > > > > > > >On Thu, Oct 22, 2009 at 2:43 PM, Joe Maimon wrote: > > > >Thanks Matt! > >> > >> > >>>>Matthew Petach wrote: > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at wholesaleinternet.com Fri Oct 23 10:29:11 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 23 Oct 2009 09:29:11 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com> <827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> Message-ID: <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> I agree completely. For the last six months I have discussed and debated privately with individuals about what I consider the probable situation once IPv4 allocation requests can no longer be met. The situation we are facing is horrible at best. We're running out of IPv4 addresses and the world is not even remotely situated to start using IPv6. Let us consider the not-so-meager issue of critical mass. Consider the unlikely near-term scenario that the world is 80% onto ipv6. So I'm running a website and I am only on iPv6. That precludes 20% of the internet from getting to my website. Am I willing to pay $20 or $30 a month for an IPv4 address so I can capture the last 20%? If I was a business concern (majority of websites) I would do it of course. Add on to that dual-stacking and you basically have everyone using IPv4 addresses until we reach ultimate critical mass (95%+ conversion maybe?). And if we're all on ipv4 anyway, why bother spending the money on ipv6? Let us also consider the potential power of the ipv4 cartel. Right now the big boys in the USA (ATT, Comcast, Time Warner Cable) are among the largest non-legacy IP holders. Officially, these guys all have ipv6 gameplans. But that is PR in my opinion. I'll tell you why. Suppose you want to start a new cable internet company. You figure you can get 1 million subscribers so you go to ARIN and you request 1 million IP addresses. Ooops, sorry none left. So you have to use ipv6. Well ipv6 isn't going to cut it because the world isn't converted over enough yet. So what happens? You don't start an internet cable provider company. Who does that benefit? Can you imagine going to the board of directors of COMCAST and telling them "let's go to ipv6... Sure it'll open comeptition up again but we'll be promoting the well being of the world". A more likely scenario is "Officially, let's have an ipv6 policy but let's not really push ipv6 because ipv4 gives us a virtual monopoly on this market, stiffles competition and makes us more powerful and rich". Here is something everyone needs to consider VERY CAREFULLY: The current ipv4 stakeholders have an economic incentive to block or delay the transition because it drives up the value of their IPv4 holdings. Good-bye IPv6, it was nice knowing you. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of tvest at eyeconomics.com Sent: Thursday, October 22, 2009 8:14 PM To: ARIN PPML Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern >>> Are you in favor of changing anything at all or can you think of no >>> better course of action than to continue exactly as is now? >>> >> >> >> IMO, it's time now to think about what we do *beyond* the end of the >> free pool when IPv4 addressing policy changes to a zero-sum game. >> Where giving one org new addresses means taking them from someone >> else. >> The address market strategy might work. Ought to work. But we should >> probably make some contingency plans. >> > > Ration, Reclaim, Return, Reuse. > > Those are the alternatives to transfers based on market principles. > I greatly prefer the market which is why I advocated for it, but > policy for what to do with reclaimed space after depletion is still > needed and any approach to it that doesnt consist of giving it all to > whoever can show need will smack of rationing. > > And in the strictest sense of the word they are correct, it is > rationing. However supply and demand markets are also a form of > rationing, so the word in and of itself does not carry automatic > negative connotations. > > Only in a worst case scenario where neither transfers or returns are > meeting even a portions of needs and ipv6 is not obviating ipv4 need > should any attention be given to reclaimation of non-abandoned > resources. Is anyone else experiencing any cognitive dissonance here? A. No clear community consensus in favor of mitigating the impact of IPv4 runout; many concerns raised about the fairness of depriving current IPv4 holders of anything less than the max. IPv4 that they can justify between now and runout. B. No significant likelihood of anything close to IPv6 substitutability in the foreseeable future; zero probability before IPv4 runout. C. No apparent acknowledgement of what this implies for anyone/ everything who might need -- and be able to justify -- "usable" IP addresses of any kind after IPv4 runout. D. *** IMO, this combination suggests that it would be prudent to anticipate that the "worst case scenario" as described above is also the highest probability scenario, by a wide margin. It's still not too late for some version of prior planning... TV _______________________________________________ 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 tvest at eyeconomics.com Fri Oct 23 11:24:02 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Fri, 23 Oct 2009 11:24:02 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com> <827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> Message-ID: <0EDE2AB4-85EE-48E9-A3B6-5E08ABC90993@eyeconomics.com> Thanks Warren. However, to repeat something I've said here many times before, I personally don't that anything so cynical as this is going on. Doubtless there are a few parties who are looking forward to becoming (and remaining) the exclusive brokers of the world's few remaining usable IP addresses, but I think the majority of people (esp. participants in this list / policy process) are just doing what they always do, what their job descriptions and careers and personal expertise mandates that they do, i.e., plan ahead for potential problems and potential opportunities as much as possible given the time and budget constraints that everyone faces. People aren't "evil" now, nor are they going to become evil when IPv4 runs out -- I don't think so anyway. In the end the exhaustion of IPv4 is a certainty, and nothing that any hypothetical speculator or aspiring would-be monopolist could do, or not do, will change that fact. The problem is that once IPv4 ceases to be available through the current mechanism, the normal, prudential, professional decision making calculus of commercial network operators will inevitably, unavoidably shift to accommodate that fact. At that point, it won't matter who wanted or really didn't want to be a speculator or monopolist. At that point, every IPv4 holder will become an IPv4 broker, active or passive, whether they like it or not. At that point the uncertainties and commercial pressures that have resulted in the current level of IPv6 deployment are only going to become more acute. As the old saying goes, when life gives you lemons, make lemonade. In this case, however, making lemonade is not the only option; one could also cause all of the other sources of potable liquids to become unavailable indefinitely. Even the nicest commercial lemonade vendor might have a tough time resisting that option. TV On Oct 23, 2009, at 10:29 AM, Warren Johnson wrote: > I agree completely. For the last six months I have discussed and > debated > privately with individuals about what I consider the probable > situation once > IPv4 allocation requests can no longer be met. The situation we are > facing > is horrible at best. We're running out of IPv4 addresses and the > world is > not even remotely situated to start using IPv6. > > > Let us consider the not-so-meager issue of critical mass. Consider > the > unlikely near-term scenario that the world is 80% onto ipv6. So I'm > running > a website and I am only on iPv6. That precludes 20% of the internet > from > getting to my website. Am I willing to pay $20 or $30 a month for > an IPv4 > address so I can capture the last 20%? If I was a business concern > (majority of websites) I would do it of course. Add on to that > dual-stacking and you basically have everyone using IPv4 addresses > until we > reach ultimate critical mass (95%+ conversion maybe?). And if we're > all on > ipv4 anyway, why bother spending the money on ipv6? > > Let us also consider the potential power of the ipv4 cartel. Right > now the > big boys in the USA (ATT, Comcast, Time Warner Cable) are among the > largest > non-legacy IP holders. Officially, these guys all have ipv6 > gameplans. > But that is PR in my opinion. I'll tell you why. Suppose you want > to start > a new cable internet company. You figure you can get 1 million > subscribers > so you go to ARIN and you request 1 million IP addresses. Ooops, > sorry none > left. So you have to use ipv6. Well ipv6 isn't going to cut it > because the > world isn't converted over enough yet. So what happens? You don't > start an > internet cable provider company. Who does that benefit? Can you > imagine > going to the board of directors of COMCAST and telling them "let's > go to > ipv6... Sure it'll open comeptition up again but we'll be promoting > the well > being of the world". A more likely scenario is "Officially, let's > have an > ipv6 policy but let's not really push ipv6 because ipv4 gives us a > virtual > monopoly on this market, stiffles competition and makes us more > powerful and > rich". > > Here is something everyone needs to consider VERY CAREFULLY: > > The current ipv4 stakeholders have an economic incentive to block or > delay > the transition because it drives up the value of their IPv4 holdings. > > > Good-bye IPv6, it was nice knowing you. > > > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > Behalf Of tvest at eyeconomics.com > Sent: Thursday, October 22, 2009 8:14 PM > To: ARIN PPML > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > > >>>> Are you in favor of changing anything at all or can you think of no >>>> better course of action than to continue exactly as is now? >>>> >>> >>> >>> IMO, it's time now to think about what we do *beyond* the end of the >>> free pool when IPv4 addressing policy changes to a zero-sum game. >>> Where giving one org new addresses means taking them from someone >>> else. >>> The address market strategy might work. Ought to work. But we should >>> probably make some contingency plans. >>> >> >> Ration, Reclaim, Return, Reuse. >> >> Those are the alternatives to transfers based on market principles. >> I greatly prefer the market which is why I advocated for it, but >> policy for what to do with reclaimed space after depletion is still >> needed and any approach to it that doesnt consist of giving it all to >> whoever can show need will smack of rationing. >> >> And in the strictest sense of the word they are correct, it is >> rationing. However supply and demand markets are also a form of >> rationing, so the word in and of itself does not carry automatic >> negative connotations. >> >> Only in a worst case scenario where neither transfers or returns are >> meeting even a portions of needs and ipv6 is not obviating ipv4 need >> should any attention be given to reclaimation of non-abandoned >> resources. > > Is anyone else experiencing any cognitive dissonance here? > > A. No clear community consensus in favor of mitigating the impact of > IPv4 runout; many concerns raised about the fairness of depriving > current > IPv4 holders of anything less than the max. IPv4 that they can justify > between now and runout. > > B. No significant likelihood of anything close to IPv6 > substitutability in > the foreseeable future; zero probability before > IPv4 runout. > > C. No apparent acknowledgement of what this implies for anyone/ > everything > who might need -- and be able to justify -- "usable" IP addresses of > any > kind after IPv4 runout. > > D. > > *** > > IMO, this combination suggests that it would be prudent to anticipate > that the "worst case scenario" as described above is also the highest > probability scenario, by a wide margin. > > It's still not too late for some version of prior planning... > > TV > > > > _______________________________________________ > 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 bill at herrin.us Fri Oct 23 11:37:18 2009 From: bill at herrin.us (William Herrin) Date: Fri, 23 Oct 2009 11:37:18 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE1B2A3.1010307@chl.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> Message-ID: <3c3e3fca0910230837u27e29dd3y340c7d4d3e3f1a60@mail.gmail.com> On Fri, Oct 23, 2009 at 9:41 AM, Joe Maimon wrote: > William Herrin wrote: >> Then before we talk about what a draconian address recovery policy >> looks like, perhaps we should consider the circumstances under which >> such a policy should be employed. >> >> My thought is that a darp should be activated when all of the >> following conditions are met: >> >> 1. IANA has allocated the last /8 to an RIR >> 2. ARIN is unable to meet a qualified request for a /18 or larger. >> 3. The BoT determines that blocks of ARIN-managed IP addresses of /24 >> and larger are not generally available for purchase via the transfer >> market for less than $10/address. > > I really dont know what price per address would be considered reasonable per > target market for ipv4 and at which point in time it will go up or down. > Already, reputable companies are charging more for static blocks of > addresses, at a significant markup from their ARIN prices (but at prices > ranging from .5 per address to .001 per address thats easily achievable). The exact number isn't all that important. The number we pick should be a price at which consensus places it well past reasonable for cell phones to have public IPv4 addresses that the registrant gets to hold on to at pennies per. Start at $1 and keep adding until only the loonies say, "My cell phone should have a public IP even at that price." > We should consider some other factors, such as whether or not the returns > and reclaims, which are fairly significant even if trickles in the bucket of > current demand, will dry up after depletion and resulting value changes for > ipv4, whether IPv6 adoption is actually measurably increasing and how the > political and public winds are blowing. This is for a contingency plan which means the assumptions for these factors are deliberately worst case. For contingency planning, we assume that returns don't match demands, that addresses aren't readily available on the transfer market and that IPv6 adoption in whatever state it's in hasn't yet adequately suppressed IPv4 demand. As for the political winds, that's a no-brainer. Before any contingency activates, they'll be blowing towards "Do Something Right Now Or Else." > And fee changes should also be a factor considered well before darp. But > that is not policy. That's a possible avenue for "how" and I think there are some policy-level things we can do with dollar signs. But before we explore "how," I'd like to zero in on "when." Irrespective of what action we think ARIN should take, what criteria should compel ARIN to take further action beyond allowing the market to do its thing? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mpetach at netflight.com Fri Oct 23 12:08:25 2009 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 23 Oct 2009 09:08:25 -0700 Subject: [arin-ppml] 2009.10.23 ARIN 24 day 3 part 1 Message-ID: <63ac96a50910230908l1d1650eeg8b28cac9ddbd5f0c@mail.gmail.com> Last set of notes from ARIN 24. Sorry about the typos, rushing a lot more, I hear the wireless will go away momentarily. ^_^;; Matt 2009.10.23 ARIN 24 day 3 part 1 John calls the meeting to order at 0907 hours Pacific time. Daily survey results from last night, time for the drawing. Thanks to Arbor and Merit again as sponsors! Reminder of the rules for the microphones. Agenda for today is all reports, then open mic time. Government affairs and public policy report Cathy Handley, Executive director Activities since last meeting CITEL PCCI MAG Navajo Nation (building fiber ring, will participate in US government broadband project, hooking up with NSRC) ICANN APNIC(2) CANTO (25th anniversary in Trinidad, CTU announced ARIN as partner in ICT roadshow) IGF Prep (for Nov meeting) RIPE Gov Roundtables PCG (public affairs coordination group in NRO) ITU Telecom World Significant events--NRO NRO public affairs coordination group formed ICANN: rod beckstrom selected as new ICANN CEO ICANN/USDOC joint project agreement ended sept 30 2009 signed new affirmation of committment agreement agreement will stay in perpetuity, no end date ICANN will stay headquartered in US reviews still called for, will now be community + USG reaffirms role of Government Advisory Committee upcoming activities Internet Governance Forum, Nov 15-18, Nate and John will be there; focus on critical internet resources IPs, DNS, etc. child safety, youth, social networking cyber security internet governance developing countries, human rights Questions? Registration Services Leslie Nobile RSD Team slide Current focus working on ARIN Online creating "user stories" and features for releases processing Q&A and POCs Legacy RSA 30, 60, 90 day follow up -- too many pending, 400 in queue will close after 90 days Resource Revocations Fraud activity and reports business as usual Fraud Reporting Services Way to report fraud about internet numbers eg fraudulent submissions to ARIN, or changes to data submission via web form investigated by staff all information kept private and anonymous Fraud reporting results brief description of results; anonymized 43 reports since Mar 2009 39 involved abuse reports like phishing 4 involved suspected numbers fraud none resulted in reclamation yet NRPM 12 has started being used where it looks like there may be misuse of resources Recovered resources slide Returned: 270 /16s, 1213 ASNs Revoked: 84.21 /16's 3943 ASNs Reclaimed: 2.04 /16's 9 ASNs Issuing Recycled Address Space current practice all recovered space held for 1 year check routing tables--if routed, identify and stop check RBLs for blacklisting, try to get it cleared if they can't get it cleared from multiple RBLs, put it back at bottom of the list publish RSS feed with daily update of returned space. IPv4 requests received have gone down a bunch this past summer, in terms of requests and space issued. But IPv6 growth trend is really on a rapid rise. Questions? Mark Wilson--how much IP space is sitting in hold at ARIN, the whole list? A: it's generally 1 year hold, so it's different every day. She can look at current queue after this. Leo Bicknell, ISC -- request for future reports: on IPv6 report number of requests for which they have no IPv4, but just IPv6? A: yes, will add that. Human Resources and Administration report Mary K Lee, director department update HR admin report shout out to michigan Rundown on all the tasks HR and admin does...wow! Doing document retention and re-inventory of records; now classifying everything, then will do disposition schedule. six month reviews finished end of June, good feedback from managers, update annual review forms as well. 50 full time employee, 24 women, 26 men, 5.5 year tenure, 26% at more than 5 years, 5 more than 10 years next year. picture of breakdown, similar to US workforce 16% lived in michigan, 43% visited michigan Lots of Fords owned by the staff members. Songs about michigan they've heard; wreck of the edmund fitzgerald, 8 mile, Member Services Report Susan Hamlin, director Motown theme for her slides. the whole team of "happy people" is here. 3497 ARIN members 340 canada, 3114 US, 36 caribbean, outside ARIN, 7 what's going on member services takes care of communication, website, content, outreach, develop swag, help with shipping, facilitate and adminster policy development process elections, ACSP ARIN meeting fellowship program Elections and corporate documents lately: news flash piece -- managing internet number resources developed to take on road to explain RIR system, policy process, mailing lists, etc. on the website in knowledge section--give feedback! NRO communications support ITU telecom world geneva with ICANN/ISOC NRO website additions supporting ARIN elections ongoing, if you're DMR you get lots of email about registering and becoming eligible. DMRs get certified letter asking you to vote, and will call you. Reach out: info at arin.net ARIN-Discuss mailing list The ARIN Consultation and Suggestion process Through Q&A in ARIN Online ARINs gone social avenues Getting Ready 2 meetings next year; Toronto and Atlanta network sponsors for both meetings, but still need social sponsors, etc. fellowship program, would ask for help and suggestions, would like to get word further out in the community, to apply and get them more involved with ARIN Financial Services Department Bob Stratton, Director Overview staff operations contracts green intiatives trends list of staff slide Operations working with Mark's staff on integrating ARIN online with accounting overdue maintenance cleanup refined reminder email process close books a bit faster improved monthly account receivable reporting FSD's revocation process invoice sent via email 2 months before due 1 month, billing, tech, admin POC email due, same 3 1 month over 2 months over, stronger language after that, turn it over to RSD at 90 days, they look for ANY POCS associated for space before revocation happens. When ARIN Online kicks in, you can check your status at any point, paid or unpaid. Contracts review process in place for all contracts, standard template for review developed to compare against RFP process in place ARINs green initiatives car pooling employees switching to hybrids, using motorcycles purchase carbon offsets for staff recycle Revenue vs Expenses the engineering and infrastructure and v4 exhaustion and IPv6 outreach are causing revenue and expenses to come together. Economic snapshot US slowdown, developing countries still growing. ATT, Ken Barter? Looking at email process, as you go through reminders, how many get to end? A: very few actual revocations; v4 space is valuable to people. They try to get people aware, they seem to be paying bills earlier than they were. Q: could consider using CEO or corp officer information they are gathering for new allocations, possibly use as last resort point of contact. Q: is this process described on the web space anywhere? A: No, it's not listed anywhere. Possible list it at bottom of notice, or put URL pointing to where it is. He doesn't want companies to figure out how long they can delay before needing to really pay the invoice. Engineering Report Mark Kosters, CTO Staffing ops, 6 people (one was intern) dev, 10 people, (4 are contractors) QA, 3 people requirements pointy haired boss (PHB) 1 Ops disaster recover replication ARIN site not very safe, lots of hazards diversity in serving up /8's under in-addr.arpa Used to just be Verisign; working on second provider site operational for west coast peering with 4 byte ASNs would like people to peer with them! DNSSEC operational nobody noticed any loss of service with it will talk about it next week v6 support for IRR in pilot suggestions for new name? Roger? IT 589 administrative requests answered Whois statistics--grown, grown, grown, then plateaued v6 whois statistics, a fraction of percent... these are queries via v6 transport, not for v6 records development working on ARIN online improve existing systems improved rocess flows with business processs re-engineering resource certification pilot DNSSEC Whois-RWS (restful web services) IRR v6, Roger, going into prod soon ARIN online 2.1 release POC updates performed with direct database updates POC recovery improvements over email submitted POC templates ARIN Online 2.2 out later new functionality resource record display ARIN Online 2.2 --resources associated with org Associations with a POC or ORG ARIN Online active accounts = 10,878 with profile: 9k Agile Methodology used waterfall method -- slow release cycles working on strengths of organization integration of QA within development more frequent releases quality assurance every update working through QA focusing on the customer experience broad browser support full regression testing requirements testable systems trying to stay faster than development working on "user stories" lightweight documentation leading into sprints. upcoming challenges additional ARIN online features RESCERT to be moved from pilot to production next year DNSSEC will be a phased approach integration with ARIN Online in 2010 Document management / retention systems replacement of legacy gear LISP participation Q? Cathy Aaronson -- Did people indicate why they couldn't peer with 4 byte ASN? A: OS on hardware couldn't support 4 byte ASNs yet. Q: Kevin Oberman -- DNSSEC implementation is great, which pieces do you have? A: signing zones they're authoritative for. They're not doing validating for zones yet in tools. And the ARIN resolvers are not doing DNSSEC in terms of doing validation. No, wait, Matt says they are actually internally validating using ISCs data. An incorrectly signed zone will be thrown out. Q: Leo Bicknell, ISC -- do they publish in-addr.arpa in any trust registry, or in ISC's DLV until root is signed? A: Yes, they have put the trust anchors in ISC's DLV; haven't followed up in others yet. Randy Epstein, WVfiber, is it only 4 byte ASN on west coast. A: West coast is exclusively 4 byte ASN; east coast has 2 byte and 4 byte. A handful have done 4 byte ASN peering, but not many; Matt looks up a number, 8 peers, 2 east, 6 west, that can do 4 byte ASN. Joe Maimon, CHL, does ARIN think it is appropriate about fee scale disparity, public perception, are other models under discussion for analysis? A: That might be better at open mic session. Board has lowered fees 5 times over the past 5 years. Very interested to find out what people think, esp. about v6 resources. Leo Bicknell, ISC -- ARIN is only 4 byte ASN peer for them, and it didn't blow up or melt down. There is a transition technology, use ASN 23456 for peering; you can peer using that technology, many people don't know about it; can be challenging with route reflectors or confederation; please read the docs! ARIN outreach activities report Megan Cruise(?) It's Megan and Richard Jimmerson for the team. contact various stakeholders beyond traditional ARIN community raise awareness of ARIN and key messages topics: ARIN, RIRs, PDP and participation, IPv4 depletion, IPv6 adoption, Legacy RSA, 4 byte ASN numbers. audiences: providers, ISPs, content providers, application service providers equipment and software vendors methods: presentations exhibits (direct and reverse) media interviews advertisements event attendance and participation microphone time hallway outreach Materials fact and information sheets (and CDs) multimedia pieces giveaways (pens, stickers, etc) slide decks comic books etc Exhibit speaking events slide--lots of text, go read it yourself. ^_^; They're not home much with all the events! Public Relations Firm hired LEWIS public relations in July PR strategy and planning Social Media Strategy and Tactics Securing: media interviews speaking engagements ARIN goes social joint effort between MSD and outreach Youtube, facebook, twitter get the name out there, promote presence, interact with ARIN members, internet technical community she's megan at arin and teamARIN on twitter uses teamARIN on all 3 sites. Working on outreach site detail ARIN exhibit and speaking events archive presentations, papers, etc support community members presenting on ARIN-related topics interact with ARIN archive of past articles, interviews, etc. questions? We're ahead of schedule, so John gives update. Sparse allocations. By November 16th, they will be doing sparse allocations for IPv6! So, in the far future, second allocations will be aggregatable. Legacy RSA update from John. issues prior to December 1997 created to allow for formal agreement between legacy holder and ARIN NOT required $100 annual fee for legacy RSA holders to support replication of reverse record support ARIN will continue to provide services without a signed legacy RSA minus any policy changes passed by the community Those who sign the legacy RSA aren't subject to policy changes by the community. Those who *don't* sign legacy RSA don't get that guarnantee 764 requests 334 signed as of august 2009 47 not required 35 added to existing RSA 339 pending; takes a *lot* of research to validate that the allocation really is authentic educational 86, government 31, otehr 204, total 321 ISPs, 13 nearly 4 /8's under legacy RSAs 764 requests out of estimated 17,000 legacy space holders. Most of the 17000 are holding /24s. About 24% space-wise is covered, but very small in terms of numeric count. This is not a success yet; but it's a start. There's a lot of legacy space that's not really space anymore; orgs that brought David Farmer, U of Minn: is that included in the 4 /8s? A: no, it's not included in that total. Covered by legacy RSA is about 5% (4 /8s), nearly 18% of legacy space has been brought under RSAs. Q: John Springer -- why do numbers not line up on left and right? A: 343 signed is end users plus 13. 334 + 13? No, the numbers really *don't* add up; they'll update the chart and numbers to match. BREAK time, come back at 11am. [*serious* kudos to whomever filled the iPod--the music this time has kicked serious ass. Love the inclusion of Jonathan Coulton!] John calls us back to schedule at 11am. Refreshed slides from Legacy RSA 343 breakdown: edu 87, gov 33, other 210, total 330, 13 ISPs Dec 30, 2009, Legacy RSA expires; it is done on a year by year basis. If you don't start the process now, you may not have the option. David Farmer would encourage board to consider extending it for one more year; he would like pending state requests to be completed at least. Owen deLong, ISC, also encourages the board to extend the deadline, as well as allowing inprogress requests to complete. Cathy Aaronson--would be useful to have percentage of space the 764 represent; the completed in total ones are the nearly 4 /8 equivalents; the 339 pending are not listed spacewise. The percentage, spacewise, of the 17,000, this set of people represent is not known. It would be good to encourage legacy people to sign RSA, so they can get benefits of new services being rolled out, like RPKI, DNSSEC, etc. Remind your legacy holder friends about this! Arin Advisory Council report now Planning to start AC meeting 30 minutes after we adjourn from ARIN 15 member AC 3 year terms Thank you Lea and Leo, Lea Roberts, 10 years Leo Bicknell, 6 years, past chair Thank you, and good luck!! Advisory Council Election Leo, Stacy, Lea, Rob, Heather are expiring this year 17 nominated individuals for 5 positions AC Role in PDP evaluate policy proposals develop draft policy present draft policy at public policy meetings 25 proposals reviewed in 2009 15 accepted, 10 discarded 15 accepted onto docket 11 draft 4 deferred 11 drafts 5 pending 4 approved 2 abandonded 1 emergency draft policy, approved Meetings 2 ARIN meetings -- all 1 ARIN caribbean sector meeting 3 NANOG meetings 2 RIPE 2 APNIC etc Fellowship program participate on selection committee mentor selected fellows during meetings outreach program participate in ARIN booth PLEASE remember to vote! Lots of seats open, lots of people running! ARIN Financial Report Scott Bradner, Treasurer Overview Reviewed fee structure and suggestions monitor ARIN financial results IRS requirements Fee structure keep current structure in place keep parallel between v4 and v6 maint fees continue reviewed suggestions hardship -- rejected non-profit -- rejected Projected year-end financials GAAP calls for expense on web updates to be capitalized, goof in accounting on that being fixed. Some estimates for colo site and disaster recover were much larger than actual costs. Changes to investment funds capital improvement is now operating reserve mainly short duration CDs, true draw account deferred revenue to legal reserve longer term CDs operating reserve to long term reserve equity and bond funds 501.c IRS reporting change; new requirements FIN Comm and board will review changes. Last year was bad, dipped into reserves. 2008 drew a million on reserves; this year, only a half million draw on reserves. Projections on revenue streams. v4 renewals will be lion's share of revenue over next four years as guess. v6 and maint will grow, v4 initials will go to zero, v4 renews will continue. ARIN, Board of Trustees report Paul Vixie, John Curran stepping in BoT Policy Actions ratification of Draft Policy 2008-7: identify invalid POCs ratified 2009-1 transfer policy Management: hired new president and CEO -- John establish ARIN research process look at routing table resources, effects of rationing IPv4 addresses, etc. ARIN may ask partners for research efforts set resource PKI (RPKI) service direction everybody working on pilots now, goal of pilots on a single TA later strengthen IPv6 outreach program John doing 20-30 presentations a month now; still running into people who don't understand the need for IPv6, or thought it had been cancelled. work with related organizations RIRs/NRO ICANN ISOC another good partner for outreach! Review and approve finance committee recommendations Looking forward considering membership and anti-takeover committee how should membership be structured long term? you can buy membership; what keeps someone from stacking the room? significant time/resource committments for international education on the RIR system Government and groups like ITU looking at the v4 runout very closely, and considering taking a hand. Many people don't understand how RIR system works. Bill Woodcock notes that those of us in companies here with government affairs officers, they might want to get in touch with Bill, Cathy, or John, to help them understand how to further the cause for self-governance in the internet resource realm Establishing long-term vision for services via ARIN strategic planning process Current one starting to get results; looking at how it will evolve over time. Not everyone wants ARIN to run all services for them; run their own RPKI, their own rWhois service, etc. Questions Lee Howard--delighted and surprised, this is the first board report he's done where he has slides. :D John Springer; 22nd September, research opportunity had been granted to...someone... [looking to get clarification on a long paragraph he reads very quickly] One research reward was done under council, and will not be disclosed under full detail about how people could break in or game the system. Ben Edelman is studying implications of transfer policy and economic impact on the organization. Once board has reviewed it, it may be released; it isn't done yet, though, so they don't really know. Keep an eye on mailing lists for other announcements. Remote question--what does "takeover" mean? We expect to have board members who know about our issues, and represent us fairly; could an entity buy up seats, vote for members in their camp, and take over ARIN over time. Need to make it non-trivial to take over the organization simply through buckets of money. End of trustee report. Open Mic. Owen DeLong, ISC -- as it stands, there is dichotomy where AC represents community at large, but is elected by ARIN membership. Should AC be elected by the community? ARIN would count votes from "the community" to decide who was appropriately on the AC. But what would constitute a "member" at that point? How about the metric used for the NRO? Why does it take $500/year to influence content of AC? You elect based on knowledge and wisdom to shepherd the policy process, not to create policies themselves; a good set of 15 should be fine. But fine for who? The need to be a 'member' to vote on the AC may skew the AC membership away from the rest of the community. Lee Howard -- should people think about whether we have a well constituted AC or are there groups not represented? How do you qualify a voter? You can't support efforts without knowing who will be voting on it. Joe Maimon, CHL, various petition processes; do they work or not? POlicy petition, not understood, the A: Board and staff have discussed it a bit, and they will make the election petition process much clearer to understand. Probably need to communicate that much better to the community. Orgs can pretty much petition at just about any point in the decision process. Leo Bicknell, ISC -- sympathetic to owen's concept; one area AC has difficulty with is when policies are only relevant to a subset of the community; it may only matter to 10% of the room, and the other 90% of people don't care; show of hands of 10 for, none against, 150 don't care. Those groups are under represented in the process, which makes it harder for them to effect change in the process. Perhaps NANOG attendees should be able to vote for AC candidates, they have a well-defined membership as well, and are definitely part of the community. A: remote participation is wide open, the slides are there, the agenda is followed, they're counted in polls as remote participation. IF 100 remote network attendees chose to join remotely, they would not need to pay, and could vote on policies. In some communities, that could be a challenge. There's also perception problem with PDP change, that AC members opinions have a new importance. Bill Woodcock, seems organizationally difficult to extend voting rights to arbitrary third groups. On the other hand, NANOG and ARIN memberships are similar costs, we already integrate closely; could the two be reciprocal, so that membership in one group confers membership rights to the other, etc. That could be a way to do it a bit less arbitrarily. Remote comment, Joe Maimon, CHL, to Owen; he was pleasantly suprised at how few remote participants there are, but was happy at how ARIN Andrew Dul, voting for board vs AC; there's a group of orgs that have no vote today, and that's the end users; how could we make more effort to include them in the process, so they can participate much like the ISPs? Not sure what suggestion could be used to help bring them in; a little bit of creative thinking might help get us wider participation. Policy process is open to end users, would like to see board or AC voting also open to them. Jason Schiller, Verizon--reciprocation between ARIN community and NANOG community; we need to reciprocate information between them; number policy and routing policy shouldn't happen in a vacuum on each side; to have good number policy and good routing policy, you have to be aware of both sides. John notes wednesdays meetings were about as joint as you can get without merging...what more do you want? A: well, share voting memberships; and make it easier for people to attend both meetings; maybe a single registration, or discount for both, or a day between conferences to discuss the issues, and have time to weigh in on issues; could that get more people involved. Cathy Aaronson; to Jason, she's now on NANOG program committee; so let her know suggestions about tying the two orgs together. Also, anyone can be on board or AC, even if you're not a member; all you need is a member to nominate you. Why isn't NRO election process appropriate? Why can't NRO election process be used for AC? A: that's historical, from the time of the MOU with ICANN; it's just that they came from two different origins, that's all. Wouldn't it work well for AC? Lee Howard: Risk of capture to NRO is very low, at most, 3 of 15 members can be "bought". Hard to imagine why anyone would want to "buy" the NRO. Bill Woodcock notes that this isn't paranoia; as non-profit bank account gets bigger, and as they gain control over more serious assets, they become targets. Two domainers took over two national registrars, who just wanted to take the money and run. John Springer, 2 pursuits, hostile takeover protection and expanded membership access are orthogonal OwenDelong, HE.net, respond to Andrew; it is wrong to open up voting for board to community; board has fiduciary responsibility to the paying membership. It's not clear the situation is broken, or needs fixing. If you are a POC with resources attached to your handle, you get one vote; otherwise, you do not. That would open it from members to members+end users+ASN holders+legacy holders. Interesting proposal. Andrew Dul, responding to Owen; was not suggesting open to non-members, was suggesting making end-users more like members. Remote participant, Joe Maimon, CHL, he believes ARIN is an incredibly open and welcoming organization; a takeover would only cost about $5 million...ack, that's fast talking. Steve Feldman, NANOG SC--if there are ways that NANOG and ARIN can work together, NANOG would be open to helping with that. NANOG surveys say the joint efforts were very valuable. We will strive to do more. We only do what we do because we've always done it; we have inertia. Leo Bicknell, ISC, one thing he noticed even with joint sessions; a lot of routing folks leave, and addressing folks show up. At RIPE, they interleave the schedules during the week, so people can't leave. Aaron Hughes, loves it, except that company justification may be harder; educate people more, but smaller group of people may be able to attend. Lee Howard, ARIN board. New topic. Thank the remote participants this week; the comments are valuable and useful; during show of hands outcome tilted based on remote participation. Closing the microphones in a moment. Scott Liebrand--we have a lot of really good candidates, limited number of slots; Not all five of his votes will get elected, he has no say in other two. Could we consider doing rank-choice voting, to indicate your preference for candidates to better steer the candidate selection? A: As part of the NomComm, he will suggest that. Closing microphones now. Rob Seastrom, Affilias -- while he understands the motivation behind Leo's recommendation that we interleave the two meetings, it could be a logistical nightmare; he's not entirely in favour of it. Steve Woodrow, MIT, fellowship program. Thanks to everyone for an enlightening four days. Thanks for selecting him, and keep it up! David Farmer, UofMinn--wednesday's v6 panel; having your address showing up on ARIN web page when you go there was raised as concerned; 2009-2 from suggestion process. A: It's a difficult thing to do via content management system; it will happen...slowly. Not forgotten, but more challenging than expected with content mangement system. Other RIRs have figured out it out...we will catch up. That concludes open mic portion. This is end of meeting. Fill out your general survey! There will be a consolation prize as well! Calling all DMRs; elections are open, vote NOW! or visit Jud at election desk. All DMRs will get called. Thanks to Arbor and Merit. Holders are recycled! Drop them at desk out there! Meeting adjourns at 1206 hours Eastern time. See you in 2010! -------------- next part -------------- An HTML attachment was scrubbed... URL: From llynch at civil-tongue.net Fri Oct 23 11:57:40 2009 From: llynch at civil-tongue.net (Lucy Lynch) Date: Fri, 23 Oct 2009 08:57:40 -0700 (PDT) Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) Message-ID: Now that my girl Elinor Ostrom has won the noble prize for economics, I thought I'd re-forward this post of two years ago with a couple of updated links. The Core Challenges of Moving Beyond Garrett Hardin http://dlc.dlib.indiana.edu/dlc/handle/10535/2662 Basurto, Xavier; Ostrom, Elinor The Internet commons: towards an eclectic theoretical framework http://www.thecommonsjournal.org/index.php/ijc/article/view/111/106 I still think managing the pot for the common good benefits us all in the long run.... - Lucy ---------- Forwarded message ---------- Date: Wed, 1 Aug 2007 09:03:26 -0700 (PDT) From: Lucy Lynch To: David Conrad Cc: ppml at arin.net, Paul Vixie Subject: Re: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) On Tue, 31 Jul 2007, David Conrad wrote: > On Jul 31, 2007, at 3:44 PM, Paul Vixie wrote: >> can each extant enterprise /8 be carved up into 64K /24's without >> exploding >> the global routing table / default free zone / internet core? > > I'm told YFRV have indicated we're currently at 10% what routers > today can handle and by the time we see the shattering of legacy > space into the routing system, the limits will be much higher. > Plenty o' room... > > NOTE: I do not believe this, however the people paying the bills will > use arguments along these lines in CEO and board room discussions and > guess where network operators' input will land? > > Anyhow, there won't be an explosion. As Randy points out elsewhere, > routing table growth is boiling the frog. See http://en.wikipedia.org/ > wiki/Boiling_frog or http://en.wikipedia.org/wiki/ > Tragedy_of_the_commons (Wikipedia is great! :-)). commons isn't quite right - common pool closer - "Common pool resources (CPR) are characterised by the difficulty of excluding actors from using them and the fact that the use by one individual or group means that less is available for use by others. (The latter point distinguishes CPR from pure public goods which exhibit both non excludability and non rivalry in consumption). CPRs include some fisheries, irrigation systems and grazing areas. Also: A valued natural or human-made resource or facility in which one person's use subtracts from another's use and [from which] it is often necessary but difficult to exclude potential users." Jointly managing the common-pool is tough and we (collective we: IANA/RIRs/ISPs/vendors/standards folk/etc.) will need to show a very high level of co-ordination, fairness, and foresight if we want to have continued governmental support for the current distributed model of resource allocation. A relevant paper from the CPR field: Common Property,Regulatory Property, and Environmental Protection:. Comparing Community-Based Management to Tradable Environmental Allowances Carol M. Rose (2000) http://dlc.dlib.indiana.edu/archive/00000333/00/rosec041200.pdf and for some idea of the scale of resources and planning needed to pull off multi-stakehold common-pool management see: The Millennium Ecosystem Assessment assessed the consequences of ecosystem change for human well-being. From 2001 to 2005, the MA involved the work of more than 1,360 experts worldwide. Their findings provide a state-of-the-art scientific appraisal of the condition and trends in the worlds ecosystems and the services they provide, as well as the scientific basis for action to conserve and use them sustainably... http://www.millenniumassessment.org/en/Index.aspx and for a fairly depressing read on how shared resourses drift toward private property see: Establishing Ownership: First Possession versus Accession (Thomas Merrill) http://repositories.cdlib.org/cgi/viewcontent.cgi?article=1174&context=berkeley_law_econ - Lucy > Rgds, > -drc > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From warren at wholesaleinternet.com Fri Oct 23 12:29:29 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 23 Oct 2009 11:29:29 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <0EDE2AB4-85EE-48E9-A3B6-5E08ABC90993@eyeconomics.com> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com><827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com><59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> <0EDE2AB4-85EE-48E9-A3B6-5E08ABC90993@eyeconomics.com> Message-ID: <143B118CFD7D44B088ABF127A25AA718@johnsonvhjjf8v> Tom, I understand your point of view and appreciate the response. But, your comment below is very interesting: " doing what they always do, what their job descriptions and careers and personal expertise mandates that they do, i.e., plan ahead for potential problems and potential opportunities as much as possible given the time and budget constraints that everyone faces" 1) If your comment refers to the executive end of the company then we must consider that this person's mandate is to make as much money as possible for the stakeholders in the organization as quickly as possible. If this means hoarding IP addresses, exercising monopoly or cartel power, than that is what is going to happen (provided it is legal in their jurisdiction). If you have enough IPv4 addresses to grow, then going to IPv6 simply opens the market back up to competition and incurs migration costs. That's a hard sale to the board of directors. 2) If your comment refers to the technology braintrust end of the company then we must consider they don't make the business decisions. See point 1. I never said people were evil. I only said that in a market driven situation, the tendency is going to be to make as much money as possible, as fast as possible and for as long as possible. If that means blocking IPv6 transition, than that is what is going to happen. You're right though, that encumbants will find themselves in the extremely enviable position of having acquired their holdings during the happy times. What particularly distresses me is that there is a lot of discussion on minimum allocations, fair distribution right before run-out etc. And very little discussion about how to prepare for and deal with the cartel-like atmosphere that is going to develop once Ips run out. Around 1936, the city of New York issued about 11,500 taxicab licenses. You couldn't pick up a fare without one of those licenses. In 2000 how many of those licenses do you think existed? Same amount. What you have is a closed system where there only so many tickets to get in and you need to purchase an existing one if you want to be involved. If your family or company happened to be around when the city issued them for $10 each back in the 30's then you're doing well now (medallion for a taxi costs about 700k now). What you get is a cartel like situation in New York City. Thanks, Warren -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of tvest at eyeconomics.com Sent: Friday, October 23, 2009 10:24 AM To: ARIN PPML Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern Thanks Warren. However, to repeat something I've said here many times before, I personally don't that anything so cynical as this is going on. Doubtless there are a few parties who are looking forward to becoming (and remaining) the exclusive brokers of the world's few remaining usable IP addresses, but I think the majority of people (esp. participants in this list / policy process) are just doing what they always do, what their job descriptions and careers and personal expertise mandates that they do, i.e., plan ahead for potential problems and potential opportunities as much as possible given the time and budget constraints that everyone faces. People aren't "evil" now, nor are they going to become evil when IPv4 runs out -- I don't think so anyway. In the end the exhaustion of IPv4 is a certainty, and nothing that any hypothetical speculator or aspiring would-be monopolist could do, or not do, will change that fact. The problem is that once IPv4 ceases to be available through the current mechanism, the normal, prudential, professional decision making calculus of commercial network operators will inevitably, unavoidably shift to accommodate that fact. At that point, it won't matter who wanted or really didn't want to be a speculator or monopolist. At that point, every IPv4 holder will become an IPv4 broker, active or passive, whether they like it or not. At that point the uncertainties and commercial pressures that have resulted in the current level of IPv6 deployment are only going to become more acute. As the old saying goes, when life gives you lemons, make lemonade. In this case, however, making lemonade is not the only option; one could also cause all of the other sources of potable liquids to become unavailable indefinitely. Even the nicest commercial lemonade vendor might have a tough time resisting that option. TV On Oct 23, 2009, at 10:29 AM, Warren Johnson wrote: > I agree completely. For the last six months I have discussed and > debated privately with individuals about what I consider the probable > situation once > IPv4 allocation requests can no longer be met. The situation we are > facing is horrible at best. We're running out of IPv4 addresses and > the world is not even remotely situated to start using IPv6. > > > Let us consider the not-so-meager issue of critical mass. Consider > the unlikely near-term scenario that the world is 80% onto ipv6. So > I'm running a website and I am only on iPv6. That precludes 20% of > the internet from getting to my website. Am I willing to pay $20 or > $30 a month for an IPv4 address so I can capture the last 20%? If I > was a business concern (majority of websites) I would do it of course. > Add on to that dual-stacking and you basically have everyone using > IPv4 addresses until we reach ultimate critical mass (95%+ conversion > maybe?). And if we're all on > ipv4 anyway, why bother spending the money on ipv6? > > Let us also consider the potential power of the ipv4 cartel. Right > now the big boys in the USA (ATT, Comcast, Time Warner Cable) are > among the largest > non-legacy IP holders. Officially, these guys all have ipv6 > gameplans. > But that is PR in my opinion. I'll tell you why. Suppose you want to > start a new cable internet company. You figure you can get 1 million > subscribers so you go to ARIN and you request 1 million IP addresses. > Ooops, sorry none left. So you have to use ipv6. Well ipv6 isn't > going to cut it because the world isn't converted over enough yet. So > what happens? You don't start an internet cable provider company. Who > does that benefit? Can you imagine going to the board of directors of > COMCAST and telling them "let's go to ipv6... Sure it'll open > comeptition up again but we'll be promoting the well being of the > world". A more likely scenario is "Officially, let's have an > ipv6 policy but let's not really push ipv6 because ipv4 gives us a > virtual monopoly on this market, stiffles competition and makes us > more powerful and rich". > > Here is something everyone needs to consider VERY CAREFULLY: > > The current ipv4 stakeholders have an economic incentive to block or > delay the transition because it drives up the value of their IPv4 > holdings. > > > Good-bye IPv6, it was nice knowing you. > > > > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > Behalf Of tvest at eyeconomics.com > Sent: Thursday, October 22, 2009 8:14 PM > To: ARIN PPML > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > > >>>> Are you in favor of changing anything at all or can you think of no >>>> better course of action than to continue exactly as is now? >>>> >>> >>> >>> IMO, it's time now to think about what we do *beyond* the end of the >>> free pool when IPv4 addressing policy changes to a zero-sum game. >>> Where giving one org new addresses means taking them from someone >>> else. >>> The address market strategy might work. Ought to work. But we should >>> probably make some contingency plans. >>> >> >> Ration, Reclaim, Return, Reuse. >> >> Those are the alternatives to transfers based on market principles. >> I greatly prefer the market which is why I advocated for it, but >> policy for what to do with reclaimed space after depletion is still >> needed and any approach to it that doesnt consist of giving it all to >> whoever can show need will smack of rationing. >> >> And in the strictest sense of the word they are correct, it is >> rationing. However supply and demand markets are also a form of >> rationing, so the word in and of itself does not carry automatic >> negative connotations. >> >> Only in a worst case scenario where neither transfers or returns are >> meeting even a portions of needs and ipv6 is not obviating ipv4 need >> should any attention be given to reclaimation of non-abandoned >> resources. > > Is anyone else experiencing any cognitive dissonance here? > > A. No clear community consensus in favor of mitigating the impact of > IPv4 runout; many concerns raised about the fairness of depriving > current > IPv4 holders of anything less than the max. IPv4 that they can justify > between now and runout. > > B. No significant likelihood of anything close to IPv6 > substitutability in > the foreseeable future; zero probability before > IPv4 runout. > > C. No apparent acknowledgement of what this implies for anyone/ > everything > who might need -- and be able to justify -- "usable" IP addresses of > any > kind after IPv4 runout. > > D. > > *** > > IMO, this combination suggests that it would be prudent to anticipate > that the "worst case scenario" as described above is also the highest > probability scenario, by a wide margin. > > It's still not too late for some version of prior planning... > > TV > > > > _______________________________________________ > 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. > > _______________________________________________ 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 warren at wholesaleinternet.com Fri Oct 23 12:32:33 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 23 Oct 2009 11:32:33 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910230837u27e29dd3y340c7d4d3e3f1a60@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com><3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com><4AE1B2A3.1010307@chl.com> <3c3e3fca0910230837u27e29dd3y340c7d4d3e3f1a60@mail.gmail.com> Message-ID: I'm not so sure about how effective politics will be. You have about 190+ countries in the world. Getting the various political bodies to agree on some policy is going to be tough. Hell, you can't get 190 people in a room and get them to agree on what's for lunch. Even if you consider that the real stakeholders are really just a fraction of those 190 countries, you still are talking many many people with various competing positions all trying to agree on something. This is for a contingency plan which means the assumptions for these factors are deliberately worst case. For contingency planning, we assume that returns don't match demands, that addresses aren't readily available on the transfer market and that IPv6 adoption in whatever state it's in hasn't yet adequately suppressed IPv4 demand. As for the political winds, that's a no-brainer. Before any contingency activates, they'll be blowing towards "Do Something Right Now Or Else." -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Friday, October 23, 2009 10:37 AM To: Joe Maimon Cc: ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern On Fri, Oct 23, 2009 at 9:41 AM, Joe Maimon wrote: > William Herrin wrote: >> Then before we talk about what a draconian address recovery policy >> looks like, perhaps we should consider the circumstances under which >> such a policy should be employed. >> >> My thought is that a darp should be activated when all of the >> following conditions are met: >> >> 1. IANA has allocated the last /8 to an RIR 2. ARIN is unable to meet >> a qualified request for a /18 or larger. >> 3. The BoT determines that blocks of ARIN-managed IP addresses of /24 >> and larger are not generally available for purchase via the transfer >> market for less than $10/address. > > I really dont know what price per address would be considered > reasonable per target market for ipv4 and at which point in time it will go up or down. > Already, reputable companies are charging more for static blocks of > addresses, at a significant markup from their ARIN prices (but at > prices ranging from .5 per address to .001 per address thats easily achievable). The exact number isn't all that important. The number we pick should be a price at which consensus places it well past reasonable for cell phones to have public IPv4 addresses that the registrant gets to hold on to at pennies per. Start at $1 and keep adding until only the loonies say, "My cell phone should have a public IP even at that price." > We should consider some other factors, such as whether or not the > returns and reclaims, which are fairly significant even if trickles in > the bucket of current demand, will dry up after depletion and > resulting value changes for ipv4, whether IPv6 adoption is actually > measurably increasing and how the political and public winds are blowing. This is for a contingency plan which means the assumptions for these factors are deliberately worst case. For contingency planning, we assume that returns don't match demands, that addresses aren't readily available on the transfer market and that IPv6 adoption in whatever state it's in hasn't yet adequately suppressed IPv4 demand. As for the political winds, that's a no-brainer. Before any contingency activates, they'll be blowing towards "Do Something Right Now Or Else." > And fee changes should also be a factor considered well before darp. > But that is not policy. That's a possible avenue for "how" and I think there are some policy-level things we can do with dollar signs. But before we explore "how," I'd like to zero in on "when." Irrespective of what action we think ARIN should take, what criteria should compel ARIN to take further action beyond allowing the market to do its thing? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ 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 warren at wholesaleinternet.com Fri Oct 23 12:41:49 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 23 Oct 2009 11:41:49 -0500 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: References: Message-ID: No one is debating that managing the (non-herbal) pot for the common good does not make sense. Unfortunately we don't live in the Star Trek - Next Generation universe where humans, and other life forms, do things for the advancement of civilization. It shouldn't come as a surprise to anyone that basically monied interests run everything in this world and dictate policy. Look how hard of a time we're having in the USA getting healthcare reform pushed through. Why should this be any different with a market such as IPv4 addresse.s I guess the problem is we've not been looking at these addresses as a market or an asset, but as a freely distributable item. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lucy Lynch Sent: Friday, October 23, 2009 10:58 AM To: ppml at arin.net Subject: Re: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) Now that my girl Elinor Ostrom has won the noble prize for economics, I thought I'd re-forward this post of two years ago with a couple of updated links. The Core Challenges of Moving Beyond Garrett Hardin http://dlc.dlib.indiana.edu/dlc/handle/10535/2662 Basurto, Xavier; Ostrom, Elinor The Internet commons: towards an eclectic theoretical framework http://www.thecommonsjournal.org/index.php/ijc/article/view/111/106 I still think managing the pot for the common good benefits us all in the long run.... - Lucy ---------- Forwarded message ---------- Date: Wed, 1 Aug 2007 09:03:26 -0700 (PDT) From: Lucy Lynch To: David Conrad Cc: ppml at arin.net, Paul Vixie Subject: Re: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) On Tue, 31 Jul 2007, David Conrad wrote: > On Jul 31, 2007, at 3:44 PM, Paul Vixie wrote: >> can each extant enterprise /8 be carved up into 64K /24's without >> exploding the global routing table / default free zone / internet >> core? > > I'm told YFRV have indicated we're currently at 10% what routers today > can handle and by the time we see the shattering of legacy space into > the routing system, the limits will be much higher. > Plenty o' room... > > NOTE: I do not believe this, however the people paying the bills will > use arguments along these lines in CEO and board room discussions and > guess where network operators' input will land? > > Anyhow, there won't be an explosion. As Randy points out elsewhere, > routing table growth is boiling the frog. See http://en.wikipedia.org/ > wiki/Boiling_frog or http://en.wikipedia.org/wiki/ > Tragedy_of_the_commons (Wikipedia is great! :-)). commons isn't quite right - common pool closer - "Common pool resources (CPR) are characterised by the difficulty of excluding actors from using them and the fact that the use by one individual or group means that less is available for use by others. (The latter point distinguishes CPR from pure public goods which exhibit both non excludability and non rivalry in consumption). CPRs include some fisheries, irrigation systems and grazing areas. Also: A valued natural or human-made resource or facility in which one person's use subtracts from another's use and [from which] it is often necessary but difficult to exclude potential users." Jointly managing the common-pool is tough and we (collective we: IANA/RIRs/ISPs/vendors/standards folk/etc.) will need to show a very high level of co-ordination, fairness, and foresight if we want to have continued governmental support for the current distributed model of resource allocation. A relevant paper from the CPR field: Common Property,Regulatory Property, and Environmental Protection:. Comparing Community-Based Management to Tradable Environmental Allowances Carol M. Rose (2000) http://dlc.dlib.indiana.edu/archive/00000333/00/rosec041200.pdf and for some idea of the scale of resources and planning needed to pull off multi-stakehold common-pool management see: The Millennium Ecosystem Assessment assessed the consequences of ecosystem change for human well-being. From 2001 to 2005, the MA involved the work of more than 1,360 experts worldwide. Their findings provide a state-of-the-art scientific appraisal of the condition and trends in the worlds ecosystems and the services they provide, as well as the scientific basis for action to conserve and use them sustainably... http://www.millenniumassessment.org/en/Index.aspx and for a fairly depressing read on how shared resourses drift toward private property see: Establishing Ownership: First Possession versus Accession (Thomas Merrill) http://repositories.cdlib.org/cgi/viewcontent.cgi?article=1174&context=berke ley_law_econ - Lucy > Rgds, > -drc > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml _______________________________________________ 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 jmaimon at chl.com Fri Oct 23 13:06:12 2009 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 23 Oct 2009 13:06:12 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com> <827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> Message-ID: <4AE1E284.30902@chl.com> Warren Johnson wrote: > And if we're all on > ipv4 anyway, why bother spending the money on ipv6? These potential problems and scenarios have all been discussed in one form or another and many people have differing opinions on which are most likely. > > Let us also consider the potential power of the ipv4 cartel. Right now the > big boys in the USA (ATT, Comcast, Time Warner Cable) are among the largest > non-legacy IP holders. True. > A more likely scenario is "Officially, let's have an > ipv6 policy but let's not really push ipv6 because ipv4 gives us a virtual > monopoly on this market, stiffles competition and makes us more powerful and > rich". Speculation. I tend to believe that things are the way they are because there wasnt any much better way to do things and that people are proceeding with good faith and intentions, but with their own interests in the forefront. It is definitely possible that various board level management of the timing of all this is concerned with the bottom line more than we think they should be. However, we should not jump to conclusions and accusations. There are bound to be plenty of those from people less familiar with the state of things. > > Here is something everyone needs to consider VERY CAREFULLY: > > The current ipv4 stakeholders have an economic incentive to block or delay > the transition because it drives up the value of their IPv4 holdings. > I think it is more important to consider that a bad reputation of address management and consumption, deserved or not is not going to be helpful down the near term road. There is still time to make an effort to correct any injustices or inequities perceived or real, trumped up or accurate, mistaken or not. Joe From warren at wholesaleinternet.com Fri Oct 23 13:40:52 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 23 Oct 2009 12:40:52 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE1E284.30902@chl.com> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com> <827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> <4AE1E284.30902@chl.com> Message-ID: -----Original Message----- From: Joe Maimon [mailto:jmaimon at chl.com] Sent: Friday, October 23, 2009 12:06 PM To: Warren Johnson Cc: tvest at eyeconomics.com; 'ARIN PPML' Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern Warren Johnson wrote: > And if we're all on > ipv4 anyway, why bother spending the money on ipv6? These potential problems and scenarios have all been discussed in one form or another and many people have differing opinions on which are most likely. >>>>>>>>>> and your point? <<<<<<<<<<<<<< > > Let us also consider the potential power of the ipv4 cartel. Right > now the big boys in the USA (ATT, Comcast, Time Warner Cable) are > among the largest non-legacy IP holders. True. > A more likely scenario is "Officially, let's have an > ipv6 policy but let's not really push ipv6 because ipv4 gives us a > virtual monopoly on this market, stiffles competition and makes us > more powerful and rich". Speculation. >>>>>>>>>>>>>>>>>>>>>>>> yes, entirely speculation. But, as a business executive I can tell you that my responsibility to the shareholders trumps many many things......... <<<<<<<<<<<<<<<<<<<<<<<<<< I tend to believe that things are the way they are because there wasnt any much better way to do things and that people are proceeding with good faith and intentions, but with their own interests in the forefront. >>>>>>>>>>>>>>>>>>>>>>>>> I wouldn't be so sure that everyone is proceeding with good faith and intentions. All of that goes out the window when corporate interest starts smelling the blood. And really, aren't "their own interests in the forefront" and "good faith and intentions" likely to be mutually exclusive in a scarcity situation? <<<<<<<<<<<<<<<<<<<<<<<<<<< It is definitely possible that various board level management of the timing of all this is concerned with the bottom line more than we think they should be. However, we should not jump to conclusions and accusations. There are bound to be plenty of those from people less familiar with the state of things. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> True, best not to jump to conclusions. However, failing to plan is planning to fail. And we must expect the market to take over as it tends to do. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Here is something everyone needs to consider VERY CAREFULLY: > > The current ipv4 stakeholders have an economic incentive to block or > delay the transition because it drives up the value of their IPv4 holdings. > I think it is more important to consider that a bad reputation of address management and consumption, deserved or not is not going to be helpful down the near term road. >>>>>>>>>>>>>>>>>>>>>>>>>>>> Bad address management and consumption is subjective. Also, it can be irrelevant if we are in a cartel-like situation because new-entrants have no real ability to complain. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< There is still time to make an effort to correct any injustices or inequities perceived or real, trumped up or accurate, mistaken or not. >>>>>>>>>>>>>>>> Vague. <<<<<<<<<<<<<<<<<<<< Joe Thanks JOE!! From spiffnolee at yahoo.com Fri Oct 23 22:03:10 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 23 Oct 2009 19:03:10 -0700 (PDT) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com> <827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> Message-ID: <126967.89111.qm@web63301.mail.re1.yahoo.com> > unlikely near-term scenario that the world is 80% onto ipv6. Look at lists of top websites, CDNs, news servers, and hosting companies, then look up their IPv6 plans. About 50% of top content has plans for 2010. Not crazy to think it could be 80% in 2011. > So I'm running > a website and I am only on iPv6. Your virtual IP on your load balancer should be dual-stack. Everything behind it should be IPv6 or private IPv4. > The current ipv4 stakeholders have an economic incentive to block or delay > the transition because it drives up the value of their IPv4 holdings. Find an action that supports that assertion and we can have a debate. The companies you mention seem to be promoting IPv6, not interfering with it. Lee From Wesley.E.George at sprint.com Fri Oct 23 22:53:44 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 23 Oct 2009 21:53:44 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com> <827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Warren Johnson Sent: Friday, October 23, 2009 10:29 AM To: tvest at eyeconomics.com; 'ARIN PPML' Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern Let us also consider the potential power of the ipv4 cartel. Right now the big boys in the USA (ATT, Comcast, Time Warner Cable) are among the largest non-legacy IP holders. Officially, these guys all have ipv6 gameplans. But that is PR in my opinion. I'll tell you why. Suppose you want to start a new cable internet company. You figure you can get 1 million subscribers so you go to ARIN and you request 1 million IP addresses. Ooops, sorry none left. So you have to use ipv6. Well ipv6 isn't going to cut it because the world isn't converted over enough yet. So what happens? You don't start an internet cable provider company. Who does that benefit? Can you imagine going to the board of directors of COMCAST and telling them "let's go to ipv6... Sure it'll open comeptition up again but we'll be promoting the well being of the world". A more likely scenario is "Officially, let's have an ipv6 policy but let's not really push ipv6 because ipv4 gives us a virtual monopoly on this market, stiffles competition and makes us more powerful and rich". [WEG] Conspiracy theories aside, this is really simplistic. It's not like the only barrier to entry for a new cable internet company is the (un)availability of IPv4 addresses. There are plenty of other ways to play that system to prevent new entries - franchise agreements, lobbying, net neutrality, actual capital costs, take your pick. Plus, they have a few words for behavior like this - collusion or antitrust or monopolistic, choose your favorite. If you can prove it, there are some regulators that would like to talk to you. Otherwise, let's keep the speculation and railing against your perceived big, bad "cartel" to a minimum, shall we? Here is something everyone needs to consider VERY CAREFULLY: The current ipv4 stakeholders have an economic incentive to block or delay the transition because it drives up the value of their IPv4 holdings. Good-bye IPv6, it was nice knowing you. [WEG] As has been said elsewhere in this thread, those (non-technical, executive or financial people) who might drive that decision are not even thinking along those lines right now. It's not a matter of being cynical or paranoid, or optimistic or na?ve - they are simply not smart enough to be evil in that way, because they don't understand the intricacies of the situation, IF they even know the difference between IPv4 and IPv6. They are thinking in terms of, "how can I delay our investment in this IPv6 thing as long as possible because it's cash out the door for which I can't see an incremental benefit in revenue?" The only thing that is combating *that* delay tactic is technical people like me spreading FUD by citing potential lost revenue for customers who leave us because we can't offer IPv6, and inability to service existing customers when we run out of IPv4 addresses. At my own company, we are well on our way to having IPv6 rolled out, and my aim is to have it out there long before anyone realizes that we could have done something different to somehow screw the community and raise the theoretical value of our IPv4 space, something that today is barely even seen as an asset by our beancounters. And let's be realistic here, the reason that those companies have large IP allocations is that they have been doing something that qualifies as a justified use of addresses under ARIN policy, and their business model expects them to continue growing if they are successful. They have IPv6 plans because they're going to be in bad shape *when* they run out of IPv4. It's not in their economic best interest to drag their feet on IPv4 if it means that IPv6 is harder for them to use because it isn't widely deployed, and therefore they are interfering with their primary business because their users aren't happy or they can't sell to any new ones. No amount of driving up the theoretical value of IPv4 assets will compensate for no longer having a customer base. Thanks Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From Wesley.E.George at sprint.com Fri Oct 23 22:59:07 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 23 Oct 2009 21:59:07 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910230837u27e29dd3y340c7d4d3e3f1a60@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> <3c3e3fca0910230837u27e29dd3y340c7d4d3e3f1a60@mail.gmail.com> Message-ID: > William Herrin wrote: The exact number isn't all that important. The number we pick should be a price at which consensus places it well past reasonable for cell phones to have public IPv4 addresses that the registrant gets to hold on to at pennies per. Start at $1 and keep adding until only the loonies say, "My cell phone should have a public IP even at that price." I understand that this is just an example, but it may not be the best one. Mobile carriers (at least the one I work for) already have contingency plans that involve categorizing mobile devices into those which can have IPv6-only (+ALG for IPv4), IPv4 + NAT, and those which actually still require a public IPv4 address, so that we can make sure we're using public IPs in the most efficient way possible, because we're pretty sure we're going to run out before IPv6-only mobile devices can do everything they need to in a way that's seamless to the end user. Also, keep in mind that any suggestion of making it more expensive to have a public address would translate into something similar to what you see in some hotels - $X for standard service (which probably means NAT or ALG) and $1.5X for service if we have to give you a public IP. The transfer market might drive the same behavior, but you need to let the market decide what that pricing is, not try to artificially raise it beforehand. Thanks Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From warren at wholesaleinternet.com Fri Oct 23 23:51:54 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 23 Oct 2009 22:51:54 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com><827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> Message-ID: <2676E4ECCFCA4585BA7F56C779562FBD@johnsonvhjjf8v> [WEG] Conspiracy theories aside, this is really simplistic. It's not like the only barrier to entry for a new cable internet company is the (un)availability of IPv4 addresses. There are plenty of other ways to play that system to prevent new entries - franchise agreements, lobbying, net neutrality, actual capital costs, take your pick. Plus, they have a few words for behavior like this - collusion or antitrust or monopolistic, choose your favorite. If you can prove it, there are some regulators that would like to talk to you. Otherwise, let's keep the speculation and railing against your perceived big, bad "cartel" to a minimum, shall we? [WDJ] You're right, there are more things to consider HOWEVER the inability to get Ips is still the inability to get Ips. I can lobby, spend money, sign franchise agreements, bribe local officials to get my infrastructure built etc, but I still can't materialize a million IPv4 ip addresses out of thin air for virtually no cost as is done today. If IP addresses wind up trading at $200 per IP, that puts a million of them at 200,000,000. I wonder if that winds up being cost prohibitive? Large monopolies hardly worry about being large monopolies. Microsoft has had a virtual lock on the Pc for almost 3 decades now. The governments of the world have been chasing them for almost two of those decades but they're still doing great. Yeah, maybe someday Microsoft will get what's coming to it but it seems to me that by the time they do, they've made so much money and influenced so many people with their monopoly behavior that it was worth it to them. [WEG] As has been said elsewhere in this thread, those (non-technical, executive or financial people) who might drive that decision are not even thinking along those lines right now. It's not a matter of being cynical or paranoid, or optimistic or na?ve - they are simply not smart enough to be evil in that way, because they don't understand the intricacies of the situation, IF they even know the difference between IPv4 and IPv6. They are thinking in terms of, "how can I delay our investment in this IPv6 thing as long as possible because it's cash out the door for which I can't see an incremental benefit in revenue?" The only thing that is combating *that* delay tactic is technical people like me spreading FUD by citing potential lost revenue for customers who leave us because we can't offer IPv6, and inability to service existing customers when we run out of IPv4 addresses. At my own company, we are well on our way to having IPv6 rolled out, and my aim is to have it out there long before anyone realizes that we could have done something different to somehow screw the community and raise the theoretical value of our IPv4 space, something that today is barely even seen as an asset by our beancounters. [WDJ] Assuming you're right and the CTO of the organization is a moron and doesn't know IPv4 is coming and hasn't filled the rest of the C-level people in on the potential benefit of being an OA (Original Allocator) the point is still moot. When IANA hands out the last /8s, it's going to be worldwide news and they're going to catch on really quickly. Furthermore, it's not really about number of subscribers, it's about number of dollars in the bank account. I reckon they don't care how many customers (within reason) it takes to make the maximum return on investment. Making customers happy and giving them services they need is only as important as the profit is high. And let's be realistic here, the reason that those companies have large IP allocations is that they have been doing something that qualifies as a justified use of addresses under ARIN policy, and their business model expects them to continue growing if they are successful. They have IPv6 plans because they're going to be in bad shape *when* they run out of IPv4. It's not in their economic best interest to drag their feet on IPv4 if it means that IPv6 is harder for them to use because it isn't widely deployed, and therefore they are interfering with their primary business because their users aren't happy or they can't sell to any new ones. No amount of driving up the theoretical value of IPv4 assets will compensate for no longer having a customer base. [WDJ] Sometimes you don't have to expand to make more money. Sometimes you just raise the price. From owen at delong.com Sat Oct 24 00:39:39 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Oct 2009 21:39:39 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <2676E4ECCFCA4585BA7F56C779562FBD@johnsonvhjjf8v> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com><827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> <2676E4ECCFCA4585BA7F56C779562FBD@johnsonvhjjf8v> Message-ID: <66F0521C-DA77-4D4F-9DC5-B2214C093445@delong.com> > > > IF they even know the difference between IPv4 and IPv6. They are > thinking in > terms of, "how can I delay our investment in this IPv6 thing as long > as > possible because it's cash out the door for which I can't see an > incremental > benefit in revenue?" The only thing that is combating *that* delay > tactic is > technical people like me spreading FUD by citing potential lost > revenue for > customers who leave us because we can't offer IPv6, and inability to > service > existing customers when we run out of IPv4 addresses. Small nit here... FUD stands for Fear, Uncertainty, Doubt and is usually used in the context of creating false fears, unwarranted uncertainty, and unreasonable doubt, such as the fear tactics commonly used by politicians. All of the things you just mentioned about IPv6 are 100% real and will happen. I can't say for sure whether it's going to happen in 2 years, 3 years, or 5 years, or somewhere in between, but, within 5 years, it will happen. An organization that large CANNOT reinvent their network in 2 years, and, 3 years is pretty aggressive. As such, given the current status, I'd say it's very important to start working on IPv6 NOW to avoid those consequences in that time frame because waiting another quarter is placing you at risk of being an additional quarter behind when it does hit. > > [WDJ] Assuming you're right and the CTO of the organization is a > moron and > doesn't know IPv4 is coming and hasn't filled the rest of the C- > level people > in on the potential benefit of being an OA (Original Allocator) the > point is > still moot. When IANA hands out the last /8s, it's going to be > worldwide > news and they're going to catch on really quickly. Furthermore, > it's not > really about number of subscribers, it's about number of dollars in > the bank > account. I reckon they don't care how many customers (within > reason) it > takes to make the maximum return on investment. Making customers > happy and > giving them services they need is only as important as the profit is > high. > That's a really cynical approach to business. It may be popular in todays 10-Q driven world, but, I don't work for an organization that views its customers with such contempt, and, I can't imagine it would be very pleasant to do so. (Although my friends who work at M$ say it is). > > And let's be realistic here, the reason that those companies have > large IP > allocations is that they have been doing something that qualifies as a > justified use of addresses under ARIN policy, and their business model > expects them to continue growing if they are successful. They have > IPv6 > plans because they're going to be in bad shape *when* they run out > of IPv4. > It's not in their economic best interest to drag their feet on IPv4 > if it > means that IPv6 is harder for them to use because it isn't widely > deployed, > and therefore they are interfering with their primary business > because their > users aren't happy or they can't sell to any new ones. No amount of > driving > up the theoretical value of IPv4 assets will compensate for no > longer having > a customer base. > That's a much smarter view of the world. > [WDJ] Sometimes you don't have to expand to make more money. > Sometimes you > just raise the price. > Given the amount of low-priced IPv6 available and the number of content providers who now have public IPv6 deployment plans as well as the number that have existing IPv6 service availability, I think that's going to be a hard sell in the competitive market that will exist at the time. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sat Oct 24 03:05:56 2009 From: randy at psg.com (Randy Bush) Date: Sat, 24 Oct 2009 16:05:56 +0900 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: References: Message-ID: > No one is debating that managing the (non-herbal) pot for the common > good does not make sense. Unfortunately we don't live in the Star > Trek - Next Generation universe where humans, and other life forms, do > things for the advancement of civilization. It shouldn't come as a > surprise to anyone that basically monied interests run everything in > this world and dictate policy. Look how hard of a time we're having > in the USA getting healthcare reform pushed through. Why should this > be any different with a market such as IPv4 addresse.s I guess the > problem is we've not been looking at these addresses as a market or an > asset, but as a freely distributable item. did you read the urls lucy sent? it was a pleasure to read real economists in an understandable context, as opposed to net amateurs cranking themselves up in to a (non-lucy) lynch mob. randy From Wesley.E.George at sprint.com Sat Oct 24 08:44:23 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Sat, 24 Oct 2009 07:44:23 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <66F0521C-DA77-4D4F-9DC5-B2214C093445@delong.com> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com><827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> <2676E4ECCFCA4585BA7F56C779562FBD@johnsonvhjjf8v> <66F0521C-DA77-4D4F-9DC5-B2214C093445@delong.com> Message-ID: ________________________________ From: Owen DeLong [mailto:owen at delong.com] Sent: Saturday, October 24, 2009 12:40 AM To: Warren Johnson Cc: George, Wes E [NTK]; tvest at eyeconomics.com; 'ARIN PPML' Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern IF they even know the difference between IPv4 and IPv6. They are thinking in terms of, "how can I delay our investment in this IPv6 thing as long as possible because it's cash out the door for which I can't see an incremental benefit in revenue?" The only thing that is combating *that* delay tactic is technical people like me spreading FUD by citing potential lost revenue for customers who leave us because we can't offer IPv6, and inability to service existing customers when we run out of IPv4 addresses. Small nit here... FUD stands for Fear, Uncertainty, Doubt and is usually used in the context of creating false fears, unwarranted uncertainty, and unreasonable doubt, such as the fear tactics commonly used by politicians. [weg] yeah, didn't really mean FUD in that way, just couldn't think of a better way to describe the out and out fearmongering I'm having to do internally to move this at something above our standard glacial pace. I'm saying things that are 100% true, but one can spin it by choosing the more aggressive and unpleasant scenarios to increase the perceived urgency. I have started introducing myself at some internal meetings as "the crazy guy on the streetcorner with the sandwich board that says 'the end of IPv4 is nigh'" ;-) Wes ________________________________ This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Sat Oct 24 10:05:51 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 24 Oct 2009 10:05:51 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE1B2A3.1010307@chl.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > 3. The BoT determines that blocks of ARIN-managed IP addresses of /24 > > and larger are not generally available for purchase via the transfer > > market for less than $10/address. What hat was _that_ number pulled out of? From bill at herrin.us Sat Oct 24 15:16:24 2009 From: bill at herrin.us (William Herrin) Date: Sat, 24 Oct 2009 15:16:24 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> Message-ID: <3c3e3fca0910241216p7e8be5c0w4897f68521c8b502@mail.gmail.com> On Sat, Oct 24, 2009 at 10:05 AM, Milton L Mueller wrote: >> > 3. The BoT determines that blocks of ARIN-managed IP addresses of /24 >> > and larger are not generally available for purchase via the transfer >> > market for less than $10/address. > > What hat was _that_ number pulled out of? Milton, There's no particular rationale behind that number. I needed to fill the blank and I offer it as a starting point for discussion. Is it too high? Too low? Until the end of the free pool, cost per address is as low as fractional cents. After depletion, how much per address is too much? How much is so much that for all intents and purposes the address market has locked up and become ineffective? Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From warren at wholesaleinternet.com Sat Oct 24 15:48:41 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Sat, 24 Oct 2009 14:48:41 -0500 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: References: Message-ID: Randy, You're right, I'm certainly not a nobel prize winning economist and I'm sure it was very interesting reading. I did book mark it but didn't get a chance to check it out. It would be interesting for someone to take the study and apply it to ipv4 addresses space. It looks to me like the "net amateur" part is a 'slight' but I can't tell for sure. I am an advocate of anyone with an opinion on this or any matter to speak it regardless of credentials as we all have something to input. I try to find value in everyone's opinion regardless of education. Otherwise we'd have very short conversations in the world. As for cranking ourselves up into a lynch mob. That's offbase. I'm not suggesting any particular course of action only brainstorming on what could happen when we're out of v4 Ips. You never know what might popup when people are brainstorming that ends up being critical. I get into trouble a lot for playing "what-if" games :-). Thanks, Warren -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Saturday, October 24, 2009 2:06 AM To: Warren Johnson Cc: 'Lucy Lynch'; ppml at arin.net Subject: Re: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) > No one is debating that managing the (non-herbal) pot for the common > good does not make sense. Unfortunately we don't live in the Star > Trek - Next Generation universe where humans, and other life forms, do > things for the advancement of civilization. It shouldn't come as a > surprise to anyone that basically monied interests run everything in > this world and dictate policy. Look how hard of a time we're having > in the USA getting healthcare reform pushed through. Why should this > be any different with a market such as IPv4 addresse.s I guess the > problem is we've not been looking at these addresses as a market or an > asset, but as a freely distributable item. did you read the urls lucy sent? it was a pleasure to read real economists in an understandable context, as opposed to net amateurs cranking themselves up in to a (non-lucy) lynch mob. randy From warren at wholesaleinternet.com Sat Oct 24 15:53:06 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Sat, 24 Oct 2009 14:53:06 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <66F0521C-DA77-4D4F-9DC5-B2214C093445@delong.com> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com><827C73AA-7AD0-47CF-AE03-8012E257EC51@eyeconomics.com> <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> <2676E4ECCFCA4585BA7F56C779562FBD@johnsonvhjjf8v> <66F0521C-DA77-4D4F-9DC5-B2214C093445@delong.com> Message-ID: [WDJ] Assuming you're right and the CTO of the organization is a moron and doesn't know IPv4 is coming and hasn't filled the rest of the C-level people in on the potential benefit of being an OA (Original Allocator) the point is still moot. When IANA hands out the last /8s, it's going to be worldwide news and they're going to catch on really quickly. Furthermore, it's not really about number of subscribers, it's about number of dollars in the bank account. I reckon they don't care how many customers (within reason) it takes to make the maximum return on investment. Making customers happy and giving them services they need is only as important as the profit is high. That's a really cynical approach to business. It may be popular in todays 10-Q driven world, but, I don't work for an organization that views its customers with such contempt, and, I can't imagine it would be very pleasant to do so. (Although my friends who work at M$ say it is). [WDJ] I didn't mean to say that customer happiness is not important. I only meant to say that sure it's great to have happy customers 1. but if you're not making a reasonable profit all the happiness in the world isn't going to pay your rent. On your other note, I often wonder how the employees feel working at companies who's M.O. is to step on everyone to make the most money. -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at wholesaleinternet.com Sat Oct 24 16:00:44 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Sat, 24 Oct 2009 15:00:44 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910241216p7e8be5c0w4897f68521c8b502@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com><3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com><4AE0DB5E.1040502@chl.com><3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com><4AE1B2A3.1010307@chl.com><75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910241216p7e8be5c0w4897f68521c8b502@mail.gmail.com> Message-ID: <6FE346ABDEF642E7AEDE7D59FBAEE909@johnsonvhjjf8v> I'll be interested to see what Ben comes back with for IP pricing. How much is *TOO* much is relative because we all have different size checkbooks. A large telecom company might be able to drop a million dollars for a large block of Ips whereas a small <100k in sales data center simply can't afford them. I think $10 per IP is low. Many datacenters out there charge from 50 cents to $1 per month per IP address. They can make $10 in less than a year. And that's with Ips being freely available from the RIR. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Saturday, October 24, 2009 2:16 PM To: Milton L Mueller Cc: ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern On Sat, Oct 24, 2009 at 10:05 AM, Milton L Mueller wrote: >> > 3. The BoT determines that blocks of ARIN-managed IP addresses of >> > /24 and larger are not generally available for purchase via the >> > transfer market for less than $10/address. > > What hat was _that_ number pulled out of? Milton, There's no particular rationale behind that number. I needed to fill the blank and I offer it as a starting point for discussion. Is it too high? Too low? Until the end of the free pool, cost per address is as low as fractional cents. After depletion, how much per address is too much? How much is so much that for all intents and purposes the address market has locked up and become ineffective? Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ 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 randy at psg.com Sat Oct 24 17:24:57 2009 From: randy at psg.com (Randy Bush) Date: Sun, 25 Oct 2009 06:24:57 +0900 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: References: Message-ID: > It looks to me like the "net amateur" part is a 'slight' but I can't tell > for sure. I am an advocate of anyone with an opinion on this or any matter > to speak it regardless of credentials as we all have something to input. I > try to find value in everyone's opinion regardless of education. Otherwise > we'd have very short conversations in the world. > > As for cranking ourselves up into a lynch mob. That's offbase. I'm not > suggesting any particular course of action only brainstorming on what could > happen when we're out of v4 Ips. You never know what might popup when > people are brainstorming that ends up being critical. I get into trouble a > lot for playing "what-if" games :-). to quote a friend I'm amazed that these fat guys are still fighting over scraps when there is a banquet in front of them. Why would anyone give up self-governance for a short term/dead-end gain? and you seriously underestimate the embarrassing nature and long term damage of the rir policy wonks' public display. randy From bill at herrin.us Sat Oct 24 17:38:50 2009 From: bill at herrin.us (William Herrin) Date: Sat, 24 Oct 2009 17:38:50 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization In-Reply-To: References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com> <28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net> <75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910110713s3e04b201re02d3dc8441ae037@mail.gmail.com> <3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> Message-ID: <3c3e3fca0910241438q446d3ba3r37acf313c9e8a26d@mail.gmail.com> On Mon, Oct 12, 2009 at 10:58 AM, Randy Bush wrote: >> No, the historical fact is that we became alarmed by the address >> consumption for http servers and made a value judgment as a community >> that the address pool shouldn't support web server names in a 1:1 >> ratio to IP addresses. > > if i had been on the internet in those long-forgotten days, i might > remember it quite differently Randy, Quite regardless of what you or I think we remember, Jay Sudowski found and posted the actual results. I didn't realize that the board had modified it further, but there it is: precedent in black and white for declaring a particular use of IP addresses insufficient to demonstrate need. >> Https, for example, does not function properly without a different IP >> address for each hostname because the SSL certificate for the server >> name must be offered to the browser before the HTTP 1.1 server name is >> transmitted by the browser. > > first, you mean apache, not https. ?second, it does work. ?been using it > for years. ?you have to be cert smart. If I meant apache I'd have said apache. Why don't you worry more about explaining what you mean than you do about explaining what I mean. Your terse "cert smart" comment is naive at best. Sure there are some 10th percentile solutions down in the technical minutiae that can share an address but together they don't add up an answer that works for the most commonly needed setup: distinct keys for distinct web sites with non-overlapping names, all on TCP port 443 of the same host today. RFC 3546's server_name extension to TLS covers this common case but deployment is far from sufficiently ubiquitous to trust your e-commerce server to it. Unless of course you live a charmed life in the jet set where losing a customer or sales opportunity is more a blow to your pride than your pocketbook. Look, I'd prefer to see a market decide which uses of IPv4 addresses are worthwhile and which are not. Markets are generally good at that sort of thing. Nevertheless, the financial reality is that the IPv4 Internet won't stop growing just because the free pool runs out. Prudence suggests that we should consider other ways to tear IP addresses loose from low-value applications so that they can be available for high-value applications. You know, just in case that market thing doesn't pan out. And the lowest of the low-value applications is any that can be readily accomplished without consuming a public IP address. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From warren at wholesaleinternet.com Sat Oct 24 17:46:29 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Sat, 24 Oct 2009 16:46:29 -0500 Subject: [arin-ppml] Fairness of banning IPv4 allocations tosomecategoryof organization In-Reply-To: <3c3e3fca0910241438q446d3ba3r37acf313c9e8a26d@mail.gmail.com> References: <6eb799ab0910092204vebc95b9l1e0e1500995111af@mail.gmail.com><28E139F46D45AF49A31950F88C4974580386D325@E03MVZ2-UKDY.domain1.systemhost.net><75822E125BCB994F8446858C4B19F0D78FF6007A@SUEX07-MBX-04.ad.syr.edu><3c3e3fca0910110713s3e04b201re02d3dc8441ae037@mail.gmail.com><3c3e3fca0910110931n48cb2187n6fca23bf61c0ccdd@mail.gmail.com> <3c3e3fca0910241438q446d3ba3r37acf313c9e8a26d@mail.gmail.com> Message-ID: <37577E8D3A6644AFAD35DA1586C7A718@johnsonvhjjf8v> I imagine all kinds of creative technical stuff is going to happen after run-out. One of them would be a nice apache module that takes one click to install and lets you have multiple certs easily on one IP. >>>>>>>>>>>>>>>>>>>>> Look, I'd prefer to see a market decide which uses of IPv4 addresses are worthwhile and which are not. Markets are generally good at that sort of thing. Nevertheless, the financial reality is that the IPv4 Internet won't stop growing just because the free pool runs out. Prudence suggests that we should consider other ways to tear IP addresses loose from low-value applications so that they can be available for high-value applications. You know, just in case that market thing doesn't pan out. And the lowest of the low-value applications is any that can be readily accomplished without consuming a public IP address. Regards, Bill Herrin From jmaimon at chl.com Sat Oct 24 21:09:08 2009 From: jmaimon at chl.com (Joe Maimon) Date: Sat, 24 Oct 2009 21:09:08 -0400 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: References: Message-ID: <4AE3A534.80100@chl.com> Randy Bush wrote: > and you seriously underestimate the embarrassing nature and long term > damage of the rir policy wonks' public display. > > randy > be quiet and nobody will notice. Feeling lucky? From mueller at syr.edu Sat Oct 24 21:54:20 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 24 Oct 2009 21:54:20 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910241216p7e8be5c0w4897f68521c8b502@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910241216p7e8be5c0w4897f68521c8b502@mail.gmail.com> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF60343@SUEX07-MBX-04.ad.syr.edu> > > Until the end of the free pool, cost per address is as low as > fractional cents. After depletion, how much per address is too much? > How much is so much that for all intents and purposes the address > market has locked up and become ineffective? > A priori, the concept of "too much" is literally meaningless. If the market is functioning (i.e. sufficient levels of liquidity, appropriate ways to bring together buyers, sellers, etc.) the price passively reflects what a willing buyer is paying a willing seller. It could be $1 million per address and if transactions occur it means that someone thinks an address is worth that much and they will profit from having it. It also means that ARIN and the rest of society need to take seriously the objective reality of what is happening and ask themselves why an ip address has become so valuable. Covering that up may do more harm than the high price. A more serious measure of an "ineffective" market is one where no transactions take place at all. Or there are legitimate reasons for intervention when and if a price spike is part of a panic or some kind of temporary emergency shortage, etc. But in neither case could one specify a specific number. A decision that, say $10 (or $100, or $1000) is "too much" is simply to impose a form of non-price rationing. So if the actual market price is indeed $1000/address and ARIN or someone decides that anything over $10 is "too much" then you get all the well-known and well-document problems with price controls. i.e., shortages, non-transparent or political forms of rationing as a substitute, back and gray markets, etc. But even then to intervene properly one would need a very clear _economic_ understanding of what is driving the demand for and supply of addresses and what the impact of an intervention would be. It would be primarily an economic policy issue, not a pure engineering issue. Just be aware of the complexity and interdependence with which one is dealing. From warren at wholesaleinternet.com Sat Oct 24 22:24:06 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Sat, 24 Oct 2009 21:24:06 -0500 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: <4AE3A534.80100@chl.com> References: <4AE3A534.80100@chl.com> Message-ID: <67714C591D5546C1B09822B534225992@johnsonvhjjf8v> I guess I'm not underrstanding what this all means........ -----Original Message----- From: Joe Maimon [mailto:jmaimon at chl.com] Sent: Saturday, October 24, 2009 8:09 PM To: Randy Bush Cc: Warren Johnson; ppml at arin.net Subject: Re: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) Randy Bush wrote: > and you seriously underestimate the embarrassing nature and long term > damage of the rir policy wonks' public display. > > randy > be quiet and nobody will notice. Feeling lucky? From randy at psg.com Sat Oct 24 22:51:05 2009 From: randy at psg.com (Randy Bush) Date: Sun, 25 Oct 2009 11:51:05 +0900 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: <4AE3A534.80100@chl.com> References: <4AE3A534.80100@chl.com> Message-ID: >> and you seriously underestimate the embarrassing nature and long term >> damage of the rir policy wonks' public display. > be quiet and nobody will notice. Feeling lucky? act as if this was a serious and mature subject and hope someone will notice. right now, arin ac, ppml, ... are pure itu fodder. randy From jmaimon at chl.com Sun Oct 25 08:45:56 2009 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 25 Oct 2009 08:45:56 -0400 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: References: <4AE3A534.80100@chl.com> Message-ID: <4AE44884.6060704@chl.com> Randy Bush wrote: >>> and you seriously underestimate the embarrassing nature and long term >>> damage of the rir policy wonks' public display. >>> >> be quiet and nobody will notice. Feeling lucky? >> > > act as if this was a serious and mature subject and hope someone will > notice. right now, arin ac, ppml, ... are pure itu fodder. > > randy > > no chance of that now. the reality is what can harm us all. joe From tvest at eyeconomics.com Sun Oct 25 14:53:39 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Sun, 25 Oct 2009 14:53:39 -0400 Subject: [arin-ppml] [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) (fwd) In-Reply-To: References: <4AE3A534.80100@chl.com> Message-ID: <366D943F-B6DC-40BF-9169-62BA00218443@eyeconomics.com> On Oct 24, 2009, at 10:51 PM, Randy Bush wrote: >>> and you seriously underestimate the embarrassing nature and long >>> term >>> damage of the rir policy wonks' public display. >> be quiet and nobody will notice. Feeling lucky? > > act as if this was a serious and mature subject and hope someone will > notice. That certainly sounds like excellent advice, assuming "someone" is paying attention and has the same broad objectives. > right now, arin ac, ppml, ... are pure itu fodder. > > randy In the end, the more people act on the above advice, and the more it has the desired effect, the less it will matter what anyone said, here or anywhere else. Who knows, maybe when the next crisis comes, everyone will just spontaneously recognize it for what it is, and intrinsically know exactly what to do, and immediately act accordingly -- all without discussion or coordination. Optimistically, TV From michael.dillon at bt.com Mon Oct 26 05:57:44 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 26 Oct 2009 09:57:44 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> Message-ID: <28E139F46D45AF49A31950F88C49745803B908BB@E03MVZ2-UKDY.domain1.systemhost.net> > We're running out of IPv4 > addresses and the world is not even remotely situated to > start using IPv6. The world is already using IPv6 and has been for some time now. In Europe, there is already one gigabit of traffic on IPv6 at the biggest exchange point. Compare that to MAE-East in 1996 when the Internet was in the papers every day. > So I'm running a website and I am only on > iPv6. That precludes 20% of the internet from getting to my > website. Please let's not let megalomania run away with us. Nobody, that means 0% of websites that exist today, have 100% of the Internet using them. Nobody even gets close to that. If a website is a business, or like a business, then it has a target market, and the target market for every website is different. > Am I willing to pay $20 or $30 a month for an IPv4 > address so I can capture the last 20%? If I was a business > concern (majority of websites) I would do it of course. Silly move. That last 20% is in Russia and China and India and Argentina and it is not going to want to go to your website ever. > Let us also consider the potential power of the ipv4 cartel. > Right now the big boys in the USA (ATT, Comcast, Time Warner > Cable) are among the largest > non-legacy IP holders. Now we are in cloud cuckoo land. Have you heard of the dot com collapse, the telecom collapse, the collapse of Worldcom, etc. There is no cartel and there are no big boys, just some companies that haven't made too many mistakes..... yet! > Officially, these guys all have ipv6 > gameplans. > But that is PR in my opinion. I'll tell you why. Suppose you > want to start a new cable internet company. You figure you > can get 1 million subscribers so you go to ARIN and you > request 1 million IP addresses. Ooops, sorry none left. So > you have to use ipv6. Well ipv6 isn't going to cut it because > the world isn't converted over enough yet. Let me tell you what else. The world isn't connected to your network yet so you have bigger fish to fry. In fact, ARIN won't even give you those IPv6 addresses since you haven't even built your network yet. How are you planning to get that cable to the 1 million subscribers? If you can build out a new cable network, it is easy enough to get a vendor to supply you with DOCSIS 3.0 boxes to connect your customers. DOCSIS 3.0 supports IPv6 > Can you imagine going to the board of > directors of COMCAST and telling them "let's go to ipv6... > Sure it'll open comeptition up again but we'll be promoting > the well being of the world". No, I can't imagine being so dumb. Instead I would give it to him straight. In a couple of years, you won't be able to grow your network any more unless you start using IPv6. It ain't easy, but it does allow you to continue growing the network. Your choice is to give up and do nothing, or to take the hit and get IPv6 ready to go when doomsday arrives. A few years ago, IPv6 was inevitable. Today, IPv6 is here and it works. In three years, IPv6 will be ubiquitous. In five years IPv6 will be dominant. And in 50 years, IPv6 will have wiped out the last pockets of IPv4. --Michael Dillon From michael.dillon at bt.com Mon Oct 26 06:41:20 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 26 Oct 2009 10:41:20 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <2676E4ECCFCA4585BA7F56C779562FBD@johnsonvhjjf8v> Message-ID: <28E139F46D45AF49A31950F88C49745803B909EA@E03MVZ2-UKDY.domain1.systemhost.net> > If IP > addresses wind up trading at $200 per IP, that puts a million > of them at 200,000,000. Your math is simplistic. If there aren't very many IPv4 addresses available, then $200 per IPv4 address seems a likely cost. But there will only be 256 addresses on offer. To get a million IPv4 addresses will require you to pay billions of dollars to shake them loose, to the extent of buying controlling interest in the IPv4 address holder. There is no IPv4 address market, and there is not likely to ever be such a market as IPv4 addresses become scarcer and scarcer as every day passes. Yes, their value rises, but the supply is shrinking faster than the rise in value. > When IANA hands out the last /8s, it's going to be worldwide > news and they're going to catch on really quickly. And it will be to late to do anything other than to accelerate your IPv6 deployment programs. It's probably even too late today to do anything else. --Michael Dillon From michael.dillon at bt.com Mon Oct 26 07:35:36 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 26 Oct 2009 11:35:36 -0000 Subject: [arin-ppml] Fairness of banning IPv4 allocationstosomecategoryof organization In-Reply-To: <37577E8D3A6644AFAD35DA1586C7A718@johnsonvhjjf8v> Message-ID: <28E139F46D45AF49A31950F88C49745803B90B04@E03MVZ2-UKDY.domain1.systemhost.net> > I imagine all kinds of creative technical stuff is going to > happen after run-out. One of them would be a nice apache > module that takes one click to install and lets you have > multiple certs easily on one IP. What's the point? We can stop running name-based virtual hosting altogether and give every site their own unique IP address. IPv6 has no shortage especially not interface IDs. --Michael Dillon From warren at wholesaleinternet.com Mon Oct 26 10:03:35 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 26 Oct 2009 09:03:35 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <28E139F46D45AF49A31950F88C49745803B908BB@E03MVZ2-UKDY.domain1.systemhost.net> References: <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> <28E139F46D45AF49A31950F88C49745803B908BB@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <05FD33C401F04A139B28808CD1E74688@johnsonvhjjf8v> -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Monday, October 26, 2009 4:58 AM To: ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > We're running out of IPv4 > addresses and the world is not even remotely situated to start using > IPv6. The world is already using IPv6 and has been for some time now. In Europe, there is already one gigabit of traffic on IPv6 at the biggest exchange point. Compare that to MAE-East in 1996 when the Internet was in the papers every day. [WDJ] I guess if your argument that the world is using IPv6 because there's a gig of transfer somewhere, then technically you're right. 1 gigabit of traffic is a speck of dust on the poop of a horse fly. I know small, inconsequential datacenters that push a gigabit of traffic over a whisker of fiber. > So I'm running a website and I am only on iPv6. That precludes 20% of > the internet from getting to my website. Please let's not let megalomania run away with us. Nobody, that means 0% of websites that exist today, have 100% of the Internet using them. Nobody even gets close to that. If a website is a business, or like a business, then it has a target market, and the target market for every website is different. [WDJ] OK, megalomania aside, let's say it's even 10%. What's that 10% worth to me? > Am I willing to pay $20 or $30 a month for an IPv4 address so I can > capture the last 20%? If I was a business concern (majority of > websites) I would do it of course. Silly move. That last 20% is in Russia and China and India and Argentina and it is not going to want to go to your website ever. [WDJ] OK, let us take your American-centric viewpoint out of the picture. Suppose I am running the site in Russia, China (with by the way, the most people on the planet) and India. Surely they care if their countrymen can get to their website. Any issue to be concerned about here, is to be concerned about anywhere. > Let us also consider the potential power of the ipv4 cartel. > Right now the big boys in the USA (ATT, Comcast, Time Warner > Cable) are among the largest > non-legacy IP holders. Now we are in cloud cuckoo land. Have you heard of the dot com collapse, the telecom collapse, the collapse of Worldcom, etc. There is no cartel and there are no big boys, just some companies that haven't made too many mistakes..... yet! [WDJ] This is hardly cloud cuckoo land. You know speaking of which, I don't know why these discussions (and other topics of discussion) get snippy. I debate stuff all the time with friends but don't feel the need to get snippy and decend into name calling. Struck a raw nerve? I would be careful about underestimating the potential power these people hold. You've got a handful of companies that control a large portion of the eyeballs in this country. I am sure it's worse in other countries. If you still don't get it, think to election time in the USA and what the "Teachers Union" or the "Fireman's Union" can get away with because some candidate wants their vote. > Officially, these guys all have ipv6 > gameplans. > But that is PR in my opinion. I'll tell you why. Suppose you want to > start a new cable internet company. You figure you can get 1 million > subscribers so you go to ARIN and you request 1 million IP addresses. > Ooops, sorry none left. So you have to use ipv6. Well ipv6 isn't > going to cut it because the world isn't converted over enough yet. Let me tell you what else. The world isn't connected to your network yet so you have bigger fish to fry. In fact, ARIN won't even give you those IPv6 addresses since you haven't even built your network yet. How are you planning to get that cable to the 1 million subscribers? [WDJ] Maybe I don't understand the justification process. It would seem to me a company like Cricket wireless appeared on the scene in the last few years and they have data plans. Where did they get the IPS? If you can build out a new cable network, it is easy enough to get a vendor to supply you with DOCSIS 3.0 boxes to connect your customers. DOCSIS 3.0 supports IPv6 [WDJ] OK, IPv6. That' sthe point, it's not IPv4. So, you start the company and get v6 IPs and oops there's not a critical mass of content. So your subscribers bitch and moan and complain and you spend a lot of money on customer service explaining it. Eventually they leave and go to Time Warner cable because they want the whole internet. > Can you imagine going to the board of directors of COMCAST and telling > them "let's go to ipv6... > Sure it'll open comeptition up again but we'll be promoting the well > being of the world". No, I can't imagine being so dumb. Instead I would give it to him straight. In a couple of years, you won't be able to grow your network any more unless you start using IPv6. It ain't easy, but it does allow you to continue growing the network. Your choice is to give up and do nothing, or to take the hit and get IPv6 ready to go when doomsday arrives. [WDJ] That's one potential conversation. Another conversation is monopoly related. What is so hard to believe about cable companies making a strategic decision to block IPv6 migration? If the top providers in the US make the decision to leave their customers on ipv4, it goes a long way to torpedoing the ipv6 movement. When 30% of the US-based subscribers aren't going to IPv6, it is a major hit. Killing ipv6 in the US is a major advantage for incumbants. I'm not saying this WILL happen. Only that it's a potential scenario. We shouldn't underestimate what greed will do to people. If you're not convinced, look at how wealth has been redistributed in the US in the last 30 years. People tend towards greed. And in regards to expanding their network, they can always make more efficient use of their IP address space (shake loose low paying customers for example, or raise their prices). Likely they have too much space already anyway. Or, they can buy up companies with IP address space. Suppose a small datacenter has 65k, Ips. They buy that company for 10 or 20 million (purely for address sapce) and use those IP addresses for something more lucrative. Or you could merge with a provider who has legacy space. Welcome to Time Warner Cable Internet, a division of Haliburton! A few years ago, IPv6 was inevitable. Today, IPv6 is here and it works. In three years, IPv6 will be ubiquitous. In five years IPv6 will be dominant. And in 50 years, IPv6 will have wiped out the last pockets of IPv4. [WDJ] I guess we shall see :-) From warren at wholesaleinternet.com Mon Oct 26 10:05:47 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 26 Oct 2009 09:05:47 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <28E139F46D45AF49A31950F88C49745803B909EA@E03MVZ2-UKDY.domain1.systemhost.net> References: <2676E4ECCFCA4585BA7F56C779562FBD@johnsonvhjjf8v> <28E139F46D45AF49A31950F88C49745803B909EA@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: > If IP > addresses wind up trading at $200 per IP, that puts a million of them > at 200,000,000. Your math is simplistic. If there aren't very many IPv4 addresses available, then $200 per IPv4 address seems a likely cost. But there will only be 256 addresses on offer. To get a million IPv4 addresses will require you to pay billions of dollars to shake them loose, to the extent of buying controlling interest in the IPv4 address holder. There is no IPv4 address market, and there is not likely to ever be such a market as IPv4 addresses become scarcer and scarcer as every day passes. Yes, their value rises, but the supply is shrinking faster than the rise in value. [WDJ] If the value is high enough, the Ips will be available. You can bet on that. From lear at cisco.com Mon Oct 26 10:14:12 2009 From: lear at cisco.com (Eliot Lear) Date: Mon, 26 Oct 2009 15:14:12 +0100 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF60343@SUEX07-MBX-04.ad.syr.edu> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910241216p7e8be5c0w4897f68521c8b502@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D78FF60343@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4AE5AEB4.6070904@cisco.com> Milton, > A priori, the concept of "too much" is literally meaningless. If the market is functioning (i.e. sufficient levels of liquidity, appropriate ways to bring together buyers, sellers, etc.) the price passively reflects what a willing buyer is paying a willing seller. It could be $1 million per address and if transactions occur it means that someone thinks an address is worth that much and they will profit from having it. It also means that ARIN and the rest of society need to take seriously the objective reality of what is happening and ask themselves why an ip address has become so valuable. Covering that up may do more harm than the high price. > > A more serious measure of an "ineffective" market is one where no transactions take place at all. Or there are legitimate reasons for intervention when and if a price spike is part of a panic or some kind of temporary emergency shortage, etc. But in neither case could one specify a specific number. > > A decision that, say $10 (or $100, or $1000) is "too much" is simply to impose a form of non-price rationing. So if the actual market price is indeed $1000/address and ARIN or someone decides that anything over $10 is "too much" then you get all the well-known and well-document problems with price controls. i.e., shortages, non-transparent or political forms of rationing as a substitute, back and gray markets, etc. > > But even then to intervene properly one would need a very clear _economic_ understanding of what is driving the demand for and supply of addresses and what the impact of an intervention would be. It would be primarily an economic policy issue, not a pure engineering issue. > > Just be aware of the complexity and interdependence with which one is dealing. > _ > Your message raises as many questions as your previous. Here are a few: 1. What is a reasonable transaction volume to expect, absent any regulation? 2. How will we distinguish that volume from the "initial" adjustment to market equilibrium? 3. What policy implications are there for new entrants to the SP market, and for enterprises? This may sound like we're covering old ground (we are), but as you point out, while perhaps these are simple questions, I doubt there are simple answers. Eliot From bill at herrin.us Mon Oct 26 10:40:40 2009 From: bill at herrin.us (William Herrin) Date: Mon, 26 Oct 2009 10:40:40 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF60343@SUEX07-MBX-04.ad.syr.edu> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910241216p7e8be5c0w4897f68521c8b502@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D78FF60343@SUEX07-MBX-04.ad.syr.edu> Message-ID: <3c3e3fca0910260740r2b6f535cv517949f6c637da58@mail.gmail.com> On Sat, Oct 24, 2009 at 9:54 PM, Milton L Mueller wrote: > A priori, the concept of "too much" is literally meaningless. > If the market is functioning (i.e. sufficient levels of liquidity, > appropriate ways to bring together buyers, sellers, etc.) the > price passively reflects what a willing buyer is paying a > willing seller. It could be $1 million per address and if transactions > occur it means that someone thinks an address is worth that much Hi Milton, Long before it hits $1M per address, the US Congress will step in and smack us down for facilitating the hording of an economically critical resource. If it's all the same to you I like ARIN to take a more proactive stance before that happens. Besides, the past 24 months events in the world financial markets have pretty well put paid to the notion that there's no such thing as too much. That having been said... > A more serious measure of an "ineffective" market is one >where no transactions take place at all. Or there are legitimate >reasons for intervention when and if a price spike is part of a >panic or some kind of temporary emergency shortage, etc. >But in neither case could one specify a specific number. Would you prefer to see a measure of transactions per month instead of dollars per address so that the dollar value can float as long as the transfers still happen? Are there additional useful ways to measure liquidity in the presumed transfer market that we should consider? If it's a useful measure then you can specify a number. For example, we could talk in terms of number of address transactions relative to the free pool assignments today. If the rate of addresses changing hands falls to 10% of the rate of free pool assignments now and if it isn't because IPv6 adoption has happened then the address transfer market has probably frozen up, recommending further action by ARIN to get things moving. > Just be aware of the complexity and interdependence with which one is dealing. I rarely fail to. But let's not make Nick Biddle's mistake either. Any ten year old can accurately tell us, yes or no, whether carrots are affordable at the grocery store. We need only encode that sensibility into words and numbers. Suggesting that we require PhD economists to continuously evaluate the situation in a way we can't quite explain is a recipe for political interference. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at matthew.at Mon Oct 26 11:18:59 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 26 Oct 2009 08:18:59 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4AE5BDE3.2000506@matthew.at> Milton L Mueller wrote: > >> -----Original Message----- >> >>> 3. The BoT determines that blocks of ARIN-managed IP addresses of /24 >>> and larger are not generally available for purchase via the transfer >>> market for less than $10/address. >>> > > What hat was _that_ number pulled out of? > That's a good question, because $10/address is pretty clearly "too low" for the mechanisms I believe will be the only real source of IP addresses (companies with large holdings who don't really need to use them behind their firewall, but for whom there is a real transition cost to renumbering tens of thousands of machines who will use the money to renumber their IPv4 to RFC1918 space *and* to finish whatever IPv6 transition they might have started, or at least use that promise of money to get the CEO and/or CIO to sign off on the IT department's plan to spend time/money that way.) And we most certainly do need a way to free up some additional IPv4 space, as it has been clear for over a year now that the transition was started too late by almost everyone. Matthew Kaufman From bill at herrin.us Mon Oct 26 11:49:34 2009 From: bill at herrin.us (William Herrin) Date: Mon, 26 Oct 2009 11:49:34 -0400 Subject: [arin-ppml] Fairness of banning IPv4 allocationstosomecategoryof organization In-Reply-To: <28E139F46D45AF49A31950F88C49745803B90B04@E03MVZ2-UKDY.domain1.systemhost.net> References: <37577E8D3A6644AFAD35DA1586C7A718@johnsonvhjjf8v> <28E139F46D45AF49A31950F88C49745803B90B04@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <3c3e3fca0910260849jed78ab0oc0a62c38d1aaa3a1@mail.gmail.com> On Mon, Oct 26, 2009 at 7:35 AM, wrote: >> I imagine all kinds of creative technical stuff is going to >> happen after run-out. ?One of them would be a nice apache >> module that takes one click to install and lets you have >> multiple certs easily on one IP. > > What's the point? We can stop running name-based virtual hosting > altogether and give every site their own unique IP address. > IPv6 has no shortage especially not interface IDs. Michael, The point can be found in an understanding of pragmatists and ideologues. The pragmatists seek to identify ways to keep the Internet functioning and growing while whatever happens with new tech like IPv6 sorts itself out. The present is reality and until the future becomes the present they figure out ways to get along in those parts of the future that are confidently assured. Like the existence and growth of the IPv4 Internet 5 years from now. And the end of the IANA free pool sooner. The ideologues clearly understand that IPv6 is The Future, capital T, capital F. If you're not on board the train before the doors close you'll be left standing at the station. And if you're fool enough not to get on board then you should be left behind. I think both pragmatists and ideologues have valuable roles to play, but quite frankly trying to insert ideology into the pragmatists' discussion is distracting and unhelpful. So knock it off, hey? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Mon Oct 26 12:09:07 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 26 Oct 2009 16:09:07 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <05FD33C401F04A139B28808CD1E74688@johnsonvhjjf8v> Message-ID: <28E139F46D45AF49A31950F88C49745803C32FAB@E03MVZ2-UKDY.domain1.systemhost.net> > [WDJ] > OK, let us take your American-centric viewpoint out of the > picture. Suppose I am running the site in Russia, China > (with by the way, the most people on the planet) and India. > Surely they care if their countrymen can get to their > website. Any issue to be concerned about here, is to be > concerned about anywhere. Yes, lets consider China. What are they doing about IPv6? Read this Wikipedia article for a start Then consider that in the Olympics, one year ago, they had all their networking and video data feeds running on IPv6. But, you know, America could decide to let China leave them in the dust. The choice is there. > [WDJ] > That's one potential conversation. Another conversation is > monopoly related. What is so hard to believe about cable > companies making a strategic decision to block IPv6 > migration? If the top providers in the US make the decision > to leave their customers on ipv4, it goes a long way to > torpedoing the ipv6 movement. When 30% of the US-based > subscribers aren't going to IPv6, it is a major hit. Killing > ipv6 in the US is a major advantage for incumbants. I'm not > saying this WILL happen. Only that it's a potential > scenario. We shouldn't underestimate what greed will do to > people. Yep, China would just love it if the USA would stick with IPv4. In fact, they may even do something behind the scenes to help the greedy big boys make that decision. It will be GSM all over again with the rest of the world enjoying ubiquitous mobile phone coverage with text messaging and cameraphones for many years while the USA lags behind squabbling about the "best" way to do it. In the end, Chinese companies have done well in the global GSM market. If the USA wants to stick with IPv4, then China will no doubt be happy to step in and help the rest of the world scale up their IPv6 deployments. This is no joke. This is real economic life in the 21st century. It is better for all of us if everybody jumps on the bandwagon this time and deploys IPv6. The potential market for everyone will be larger and you won't have artificial technical barriers blocking you ability to win a share of that market, such as the debacle of the history of US cellphone deployment. --Michael Dillon From spiffnolee at yahoo.com Mon Oct 26 12:10:19 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Mon, 26 Oct 2009 09:10:19 -0700 (PDT) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <05FD33C401F04A139B28808CD1E74688@johnsonvhjjf8v> References: <59F22A771F5647FAB4443B5041810EAD@johnsonvhjjf8v> <28E139F46D45AF49A31950F88C49745803B908BB@E03MVZ2-UKDY.domain1.systemhost.net> <05FD33C401F04A139B28808CD1E74688@johnsonvhjjf8v> Message-ID: <798338.16340.qm@web63307.mail.re1.yahoo.com> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Monday, October 26, 2009 4:58 AM > To: ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > OK, IPv6. That' sthe point, it's not IPv4. So, you start the company and > get v6 IPs and oops there's not a critical mass of content. So your > subscribers bitch and moan and complain and you spend a lot of money on > customer service explaining it. Eventually they leave and go to Time Warner > cable because they want the whole internet. In what way is Time Warner Cable different than the "you" to whom you address your comments? Large == bad? > That's one potential conversation. Another conversation is monopoly > related. What is so hard to believe about cable companies making a > strategic decision to block IPv6 migration? Because that's not what's happening. Comcast, in particular, has shown great leadership in IPv6 deployment. Lee From michael.dillon at bt.com Mon Oct 26 12:17:38 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 26 Oct 2009 16:17:38 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910260740r2b6f535cv517949f6c637da58@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745803C32FD7@E03MVZ2-UKDY.domain1.systemhost.net> > Long before it hits $1M per address, the US Congress will > step in and smack us down for facilitating the hording of an > economically critical resource. The US Congress does not act quickly enough to smack anyone down. Long before they get a chance to act, there will be horror in the boardrooms of companies who haven't pushed their IPv6 deployment programs ahead enough. And the sobre second thoughts in those boardrooms will be that it is better to get their deployment programs in gear than it is to wait and hope that Congress can do anything meaningful. Because there is a whole world out there where Congressional acts are meaningless. The smart money is already moving towards IPv6 so that they can put all of this complexity and uncertainty and politicking of IPv4, behind them. Anybody who pays $1 millon for an IPv4 address is just shooting themselves in the foot because that very act of offering to pay such a high sum will light a fire under all of their competitors to move to IPv6 sooner, and since a network based business requires the same protocol as its competitors, that price offer will drastically shorten the period of time in which the buyer gets to exploit their purchase. --Michael Dillon From michael.dillon at bt.com Mon Oct 26 12:20:33 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 26 Oct 2009 16:20:33 -0000 Subject: [arin-ppml] Fairness of banning IPv4 allocationstosomecategoryof organization In-Reply-To: <3c3e3fca0910260849jed78ab0oc0a62c38d1aaa3a1@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745803C32FE2@E03MVZ2-UKDY.domain1.systemhost.net> > The pragmatists seek to identify ways to keep the Internet > functioning and growing while whatever happens with new tech > like IPv6 sorts itself out. The pragmatists are out their running IPv6 today and have real IPv6 customers on their networks. Some of them are small network operators and some are larger, but the pragmatists are out there doing it, not arguing the point on ARIN. --Michael Dillon From scottleibrand at gmail.com Mon Oct 26 12:26:48 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 26 Oct 2009 09:26:48 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocations to some category of organization In-Reply-To: <28E139F46D45AF49A31950F88C49745803C32FE2@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803C32FE2@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4AE5CDC8.8040505@gmail.com> michael.dillon at bt.com wrote: >> The pragmatists seek to identify ways to keep the Internet >> functioning and growing while whatever happens with new tech >> like IPv6 sorts itself out. >> > > The pragmatists are out their running IPv6 today and have > real IPv6 customers on their networks. Some of them are > small network operators and some are larger, but the pragmatists > are out there doing it, not arguing the point on ARIN. Some of us are pragmatically doing both. I fully anticipate that I'll need to provide my customers with both IPv6 and IPv4 service for a number of years. I suspect a lot of us will need to be prepared with dual-stack network connectivity, and some plan for dealing with post-exhaustion v4 addressing (even if it's just telling your customers to BYOA). -Scott From matthew at matthew.at Mon Oct 26 12:50:08 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 26 Oct 2009 09:50:08 -0700 Subject: [arin-ppml] Fairness of banning IPv4 allocationstosomecategoryof organization In-Reply-To: <28E139F46D45AF49A31950F88C49745803C32FE2@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803C32FE2@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4AE5D340.30400@matthew.at> michael.dillon at bt.com wrote: > The pragmatists are out their running IPv6 today and have > real IPv6 customers on their networks. Some of them are > small network operators and some are larger, but the pragmatists > are out there doing it, not arguing the point on ARIN. > > But none of them are operating pure IPv6-only networks that provide their customers with a "complete Internet experience", as that is currently (and may forever be) impossible. They're operating dual-stack, and for every new dual-stack customer you sign up, you've got to get some IPv4 from somewhere. Even if that means multiple layers of NAT or other address-sharing technology. And even with all that, you'll still need to find more IPv4 somewhere if you grow enough... that's why transfer will happen. Folks who don't need nearly as many unique addresses as they have will be who growing dual-stack providers get them from. Matthew Kaufman From owen at delong.com Mon Oct 26 19:55:45 2009 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Oct 2009 16:55:45 -0700 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 Message-ID: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> The following proposal has been sent to PPML before. It is now on the AC docket. There was, unfortunately, insufficient time to get it to the Dearborn meeting for adoption discussion outside of the petition process. At this time, I would like to solicit any additional community feedback regarding changes that should be made to the proposal before asking the AC to place it on the next meeting agenda for adoption discussion. Thanks, Owen > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: /24 End User Minimum Allocation Unit > 2. Proposal Originator: Owen DeLong > > > 3. Proposal Version: 0.9 > 4. Date: 8/3/09 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > > Replace section 4.3.2.2 of the NRPM with the following: > > 4.3.2.2 Multihomed Connection > > For end-users who demonstrate an intent to announce the requested space in a > multihomed fashion to two or more distinct providers, the minimum block of IP > address space assigned is a /24. If assignments smaller than a /24 are needed, > multihomed end-users should contact their upstream providers. When prefixes are > assigned which are longer than /20, they will be from a block reserved for that > purpose so long as that is feasible. End-users may not receive a block > smaller > than /22 under this policy if they already have resources from ARIN, > except as > specified in section 4.3.6.2. > > Renumber the existing paragraph under the 4.3.6 to > > 4.3.6.1 Utilization requirements for additional Assignment > > Add the following paragraph 4.3.6.2 > > 4.3.6.2 Replacement assignments for small multi-homers > > Any end-user that possesses an assignment smaller than /22 under any > part of > section 4.3 shall not be able to get an additional assignment unless > they agree > to return all existing assignments within 12 months of receiving a new > assignment. > The new assignment shall be sized to accommodate their existing > utilization in > addition to their justified additional growth space under section 4.3.6.1. > The common cases for this are expected to be a /24 returned after > receipt of a /23, > or a /23 returned after receipt of a /22. > > 8. Rationale: > > This policy attempts to incorporate the recent and historical discussions of > policy for multi-home users on PPML. The intent is to provide as fair a process > as possible for multi-homed organizations down to the smallest feasible size > while still preserving some control over growth in the routing table. > > It has been repeatedly noted that /24 multi-homers exist today with PA space > and still occupy a routing table slot, so, it is unlikely that moving this > boundary to /24 would significantly impact the routing table. > > By requiring smaller assignments to renumber and return, rather than add more > small blocks to their assignments, this policy seeks to further reduce the > chances of unnecessary growth in the routing table and encourage good aggregation > where possible. > > 9. Timetable for implementation: Immediate > > END OF TEMPLATE > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at ibctech.ca Mon Oct 26 21:09:30 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 26 Oct 2009 21:09:30 -0400 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 In-Reply-To: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> References: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> Message-ID: <4AE6484A.60104@ibctech.ca> Owen DeLong wrote: > The following proposal has been sent to PPML before. It is now on the > AC docket. There > was, unfortunately, insufficient time to get it to the Dearborn meeting > for adoption discussion > outside of the petition process. > > At this time, I would like to solicit any additional community feedback > regarding changes that > should be made to the proposal before asking the AC to place it on the > next meeting agenda > for adoption discussion. To me, it seems as though there are many places within the proposal where the term 'assignment' appears where I would expect the term 'allocation'. This is slightly clouding my understanding of the policy proposal. If the true intent of the proposer was to use 'assignment' in all cases, please forgive me. If the terminology is indeed misrepresented, can that be fixed? Steve From marquis at roble.com Mon Oct 26 22:20:22 2009 From: marquis at roble.com (Roger Marquis) Date: Mon, 26 Oct 2009 19:20:22 -0700 (PDT) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <20091027022022.D07142B211C@mx5.roble.com> Matthew Kaufman wrote: > And we most certainly do need a way to free up some additional > IPv4 space Perhaps a rhetorical question but how would you propose getting back the legacy /8s, doled out in the dozens back in the day. Virtually none of the owners, organizations like Cisco and HP, really need more than any other company their size (i.e., a few /24s). Then there are all the legacy owners of /16s who aren't using a fraction of their addresses. It is not even difficult to identify the squatters thanks to a strong correlation with the date of their arin whois record. Personally I think the outcome is inevitable, as soon as a few politically savvy businesses start feeling the budget pinch from IPv4 resale pump and dumpers, their lobbyists will be all over the US Congress. Congressional aids will read this lists's archives, and all the plotting over IP resale values, and laws will be passed accordingly. > as it has been clear for over a year now that the transition was > started too late by almost everyone. I don't know about that. The transition was started in time but has been stonewalled by those planning to monetize their IP real-estate. The stonewalling has been in the form of continued FUD regarding IPv6 NAT. It has also been slowed by short-sighted implementors who fail to see that there is no value in IPv6 until a v6 node can access 100% of the IPv4 Internet as well. The bridge from v4 to v6 has only two real obstacles: 1) a standardized version of IPv6 NAT, and 2) a 1:1 mapping of legacy v4 routing to v6. But you won't hear much about these two roadblocks in this forum due to the signal to noise ratio, skewed by planning (sometimes salivating) over the coming v4 resale market. IMO, Roger Marquis From mpetach at netflight.com Mon Oct 26 22:48:09 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 26 Oct 2009 19:48:09 -0700 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 In-Reply-To: <4AE6484A.60104@ibctech.ca> References: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> <4AE6484A.60104@ibctech.ca> Message-ID: <63ac96a50910261948n749b004s23cdc2fee9b6b9ec@mail.gmail.com> On Mon, Oct 26, 2009 at 6:09 PM, Steve Bertrand wrote: > Owen DeLong wrote: > > The following proposal has been sent to PPML before. ?It is now on the > > AC docket. ?There > > was, unfortunately, insufficient time to get it to the Dearborn meeting > > for adoption discussion > > outside of the petition process. > > > > At this time, I would like to solicit any additional community feedback > > regarding changes that > > should be made to the proposal before asking the AC to place it on the > > next meeting agenda > > for adoption discussion. > > To me, it seems as though there are many places within the proposal > where the term 'assignment' appears where I would expect the term > 'allocation'. > > This is slightly clouding my understanding of the policy proposal. > > If the true intent of the proposer was to use 'assignment' in all cases, > please forgive me. If the terminology is indeed misrepresented, can that > be fixed? > > Steve I think if Owen simply changes the title from: Policy Proposal Name: /24 End User Minimum Allocation Unit to Policy Proposal Name: /24 End User Minimum Assignment it should put the entire text once again into consistent usage, right? At that point, the change would refer entirely to the end site assignments, not to ISP/LIR allocations. Matt From mueller at syr.edu Mon Oct 26 22:55:15 2009 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 26 Oct 2009 22:55:15 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910260740r2b6f535cv517949f6c637da58@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0DB5E.1040502@chl.com> <3c3e3fca0910230553m63863651y4dfb57125778d2cb@mail.gmail.com> <4AE1B2A3.1010307@chl.com> <75822E125BCB994F8446858C4B19F0D78FF60337@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910241216p7e8be5c0w4897f68521c8b502@mail.gmail.com> <75822E125BCB994F8446858C4B19F0D78FF60343@SUEX07-MBX-04.ad.syr.edu> <3c3e3fca0910260740r2b6f535cv517949f6c637da58@mail.gmail.com> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF603BA@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > Long before it hits $1M per address, the US Congress will step in and > smack us down for facilitating the hording of an economically critical > resource. Maybe, maybe not. I don't think good policy can be based on such speculation. Congress has no legal authority over the address space and the U.S. Congress won't do anything unless well-organized interest groups urge it to do something. Who might those groups be? How would they benefit politically or economically by "smacking ARIN down"? How would such an intervention make addresses any less expensive? > Besides, the past 24 months events in the world financial markets have > pretty well put paid to the notion that there's no such thing as too > much. It's amazing how many different conclusions the "events in the world financial markets" confirm in the minds of nonspecialists with no special analytical insight into what happened and what caused it, but frankly I don't see the relevance of this comment. (The financial crisis btw was caused by LOW prices (low interest rates, easy credit)). Appeals to "what the financial crisis proves" are approaching the Hitler metaphor as a useless dead end in policy debates. > Would you prefer to see a measure of transactions per month instead of > dollars per address so that the dollar value can float as long as the > transfers still happen? Are there additional useful ways to measure > liquidity in the presumed transfer market that we should consider? Conceptually, that's a better approach. But I don't see the need for a specific metric or threshold (as you suggest with your carrots metaphor). If we run into severe IPv4 address shortages and we know that there are unused or underutilized v4 blocks around and nothing is changing hands then it will be clear that transfer markets aren't working. Then you need to analyze why and what to do about it. Are the conditions attached to them too stringent and constraining? Are there other problems? > If it's a useful measure then you can specify a number. For example, > we could talk in terms of number of address transactions relative to > the free pool assignments today. If the rate of addresses changing > hands falls to 10% of the rate of free pool assignments now and if it > isn't because IPv6 adoption has happened then the address transfer > market has probably frozen up, recommending further action by ARIN to > get things moving. As I have always said, the worst thing that can happen with transfers is that they just don't happen. V4 markets are only one arrow in the quiver. So when I say this: > > Just be aware of the complexity and interdependence with which one is > dealing. I am talking about: 1) identifying what is causing the problems and 2) defining WHAT to do about it. Poorly conceived interventions (e.g., price controls or dumb forms of rationing) can easily make things much worse. From steve at ibctech.ca Mon Oct 26 23:07:44 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 26 Oct 2009 23:07:44 -0400 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 In-Reply-To: <63ac96a50910261948n749b004s23cdc2fee9b6b9ec@mail.gmail.com> References: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> <4AE6484A.60104@ibctech.ca> <63ac96a50910261948n749b004s23cdc2fee9b6b9ec@mail.gmail.com> Message-ID: <4AE66400.3090808@ibctech.ca> Matthew Petach wrote: > On Mon, Oct 26, 2009 at 6:09 PM, Steve Bertrand wrote: >> Owen DeLong wrote: >>> The following proposal has been sent to PPML before. It is now on the >>> AC docket. >> To me, it seems as though there are many places within the proposal >> where the term 'assignment' appears where I would expect the term >> 'allocation'. >> >> This is slightly clouding my understanding of the policy proposal. >> >> If the true intent of the proposer was to use 'assignment' in all cases, >> please forgive me. If the terminology is indeed misrepresented, can that >> be fixed? > I think if Owen simply changes the title from: > > Policy Proposal Name: /24 End User Minimum Allocation Unit > > to > > Policy Proposal Name: /24 End User Minimum Assignment > > it should put the entire text once again into consistent usage, > right? At that point, the change would refer entirely to the end site > assignments, not to ISP/LIR allocations. Yes, the change would make it clear as to what is being referred to, and would put the text into consistent usage. I read assignment as something that I hand out. I read allocation as something that I receive from ARIN (or my local RIR, as it were). I'm sorry to have come forward about my confusion, but normally, when I review a proposal to change the NRPM (or anything related to it), I always assume 'allocation'. Your title change makes it crystal clear (to me) as to what the intent is. Steve From warren at wholesaleinternet.com Mon Oct 26 23:11:48 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 26 Oct 2009 22:11:48 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <20091027022022.D07142B211C@mx5.roble.com> References: <20091027022022.D07142B211C@mx5.roble.com> Message-ID: I am not an expert on the matter but I think ARIN lacks the authority required to simply "take back" the various /8s doled out in the early days. And even if it could put together some semblence of authority for this purpose, it would likely fight a steep uphill legal battle during the process. Lacking the authority, it seems to me we need to provide them with an incentive that is more interesting to them, than the potential of that IPv4 address space. I have no idea what that would be. Anyone? Perhaps a rhetorical question but how would you propose getting back the legacy /8s, doled out in the dozens back in the day. Virtually none of the owners, organizations like Cisco and HP, really need more than any other company their size (i.e., a few /24s). Then there are all the legacy owners of /16s who aren't using a fraction of their addresses. It is not even difficult to identify the squatters thanks to a strong correlation with the date of their arin whois record. From bill at herrin.us Tue Oct 27 00:06:55 2009 From: bill at herrin.us (William Herrin) Date: Tue, 27 Oct 2009 00:06:55 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <20091027022022.D07142B211C@mx5.roble.com> References: <20091027022022.D07142B211C@mx5.roble.com> Message-ID: <3c3e3fca0910262106v2cffedf9x67f40c1afea93d5f@mail.gmail.com> On Mon, Oct 26, 2009 at 10:20 PM, Roger Marquis wrote: > Perhaps a rhetorical question but how would you propose getting back the > legacy /8s, doled out in the dozens back in the day. ?Virtually none of the > owners, organizations like Cisco and HP, really need more than any other > company their size (i.e., a few /24s). ?Then there are all the legacy > owners of /16s who aren't using a fraction of their addresses. ?It is not > even difficult to identify the squatters thanks to a strong correlation > with the date of their arin whois record. Roger, You don't, at least not without changing the legal underpinnings on which ARIN functions. The "legacy" addresses were handed out without any provisions for the involuntarily canceling the registration. It's been that way so long that the doctrine of laches comes into play even if someone could find a sound legal theory taking the addresses back. ARIN could probably get away with escheating addresses that the registrant of record declines to defend. They could certainly get away with demanding payment for RDNS delegation. They might possibly be able to get away with subtracting your legacy space from your justifiable non-legacy space. But that's about the limit. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at matthew.at Mon Oct 26 23:54:51 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 26 Oct 2009 20:54:51 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <20091027022022.D07142B211C@mx5.roble.com> References: <20091027022022.D07142B211C@mx5.roble.com> Message-ID: <4AE66F0B.20607@matthew.at> Roger Marquis wrote: > Matthew Kaufman wrote: >> And we most certainly do need a way to free up some additional >> IPv4 space > > Perhaps a rhetorical question but how would you propose getting back the > legacy /8s, doled out in the dozens back in the day. Virtually none > of the > owners, organizations like Cisco and HP, really need more than any other > company their size (i.e., a few /24s). Then there are all the legacy > owners of /16s who aren't using a fraction of their addresses. It is not > even difficult to identify the squatters thanks to a strong correlation > with the date of their arin whois record. Money. When the money available to Cisco and HP for consolidating to a few external /24s and renumbering the inside to RFC1918 by selling a few /16s is enough that the CIO sees that as a good way for the IT guys to be spending their time, that's when it'll happen. Even better is if the money is also sufficient to finish the IPv6 upgrades. > > Personally I think the outcome is inevitable, as soon as a few > politically > savvy businesses start feeling the budget pinch from IPv4 resale pump and > dumpers, their lobbyists will be all over the US Congress. Congressional > aids will read this lists's archives, and all the plotting over IP resale > values, and laws will be passed accordingly. The number of companies with IP space they can part with once it makes any financial sense is a lot bigger than the number of companies that are growing ISPs in need of more IPv4 space even as they go dual-stack with IPv6. There might be lobbying, but it might very well be orthogonal to what you're thinking. > >> as it has been clear for over a year now that the transition was >> started too late by almost everyone. > > I don't know about that. The transition was started in time but has been > stonewalled by those planning to monetize their IP real-estate. The > stonewalling has been in the form of continued FUD regarding IPv6 > NAT. It > has also been slowed by short-sighted implementors who fail to see that > there is no value in IPv6 until a v6 node can access 100% of the IPv4 > Internet as well. That depends on whether or not the v6 node is dual-stack or not. If the latter really mattered, then the IPv6 protocol design would've put legacy compatibility a lot higher on the list, right? (ahem) I don't think it is "stonewalled" so much as "doesn't matter yet" to almost everyone's brain. It is very hard to focus on quarterly financial results and following SOX-compliant IT proceedures than it is to worry about IPv6, especially when the IPv4 Internet is working so well for everyone. > > The bridge from v4 to v6 has only two real obstacles: 1) a standardized > version of IPv6 NAT, and 2) a 1:1 mapping of legacy v4 routing to v6. > But > you won't hear much about these two roadblocks in this forum due to the > signal to noise ratio, skewed by planning (sometimes salivating) over the > coming v4 resale market. The former is being talked about in BEHAVE, but did suffer from getting shot down in the first round by the belief that the transition would take place in such a way that dual-stack would work forever. The latter doesn't make any technical sense at all, given how IPv6 was designed. Matthew Kaufman From rudi.daniel at gmail.com Tue Oct 27 01:25:42 2009 From: rudi.daniel at gmail.com (RudOlph Daniel) Date: Tue, 27 Oct 2009 01:25:42 -0400 Subject: [arin-ppml] v4 to v6 obstacles Message-ID: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> Hi Roger Your suggestion is that NAT-PT is not going to be a worker, which was also the suggestion of RFC4966. So what alternatives do we have for 100% v6 access to v4 and how can we live with less than 100% if the solution is as you suggest not yet available? Seems to me that a short term strategy has turned into a longterm roadblock to v6 progress? Rudi From: Roger Marquis > > > > as it has been clear for over a year now that the transition was > > started too late by almost everyone. > > I don't know about that. The transition was started in time but has been > stonewalled by those planning to monetize their IP real-estate. The > stonewalling has been in the form of continued FUD regarding IPv6 NAT. It > has also been slowed by short-sighted implementors who fail to see that > there is no value in IPv6 until a v6 node can access 100% of the IPv4 > Internet as well. > > The bridge from v4 to v6 has only two real obstacles: 1) a standardized > version of IPv6 NAT, and 2) a 1:1 mapping of legacy v4 routing to v6. But > you won't hear much about these two roadblocks in this forum due to the > signal to noise ratio, skewed by planning (sometimes salivating) over the > coming v4 resale market. > > IMO, > Roger Marquis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaimon at chl.com Tue Oct 27 07:00:30 2009 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 27 Oct 2009 07:00:30 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910262106v2cffedf9x67f40c1afea93d5f@mail.gmail.com> References: <20091027022022.D07142B211C@mx5.roble.com> <3c3e3fca0910262106v2cffedf9x67f40c1afea93d5f@mail.gmail.com> Message-ID: <4AE6D2CE.9020006@chl.com> William Herrin wrote: > > You don't, at least not without changing the legal underpinnings on > which ARIN functions. The "legacy" addresses were handed out without > any provisions for the involuntarily canceling the registration. But they were not handed out by ARIN under contractual relationship. What legal obligation or theory prevents ARIN from updating a record in their database associating one string of numbers with one organization or another? ARIN does not actually ever do more than that. No ISP's are bound by contract to route according to that. ARIN's actions neither provide or deprive any other entity of any property or abilities. It is the belief in the collective behavior of the entities who make up the global network to assign meaning to ARIN's database that causes it have the relevance it enjoys now. The desire to preserve that situation is most likely many times more compelling then any legal theory about obligations that possibly do not exist. > It's > been that way so long that the doctrine of laches comes into play even > if someone could find a sound legal theory taking the addresses back. I am looking for a sound legal theory why the numbers cant be associated the in ARIN database to anyone they wish. Is there any legal theory why I cant create my own database and associate any string of numbers to anyone I wish? What makes ARIN different? > > ARIN could probably get away with escheating addresses that the > registrant of record declines to defend. They could certainly get away > with demanding payment for RDNS delegation. They might possibly be > able to get away with subtracting your legacy space from your > justifiable non-legacy space. But that's about the limit. > > Regards, > Bill Herrin > If the argument is what ARIN can get away without legal battle, thats a much smaller territory. The answer is that they can get away with only so much as does not seriously annoy more litigation happy entities then they want to deal with. Joe From jmaimon at chl.com Tue Oct 27 09:15:33 2009 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 27 Oct 2009 09:15:33 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> Message-ID: <4AE6F275.7060006@chl.com> RudOlph Daniel wrote: > Hi Roger > Your suggestion is that NAT-PT is not going to be a worker, which was > also the suggestion of RFC4966. So what alternatives do we have for 100% > v6 access to v4 and how can we live with less than 100% if the solution > is as you suggest not yet available? > > Seems to me that a short term strategy has turned into a longterm > roadblock to v6 progress? > > Rudi > I was under the impression that complaints about ipv6-ipv4 interoperability generally refer to the idealogical reasons that did their best to sink nat-pt, even while grudgingly acknowledging " However, it is clear that in some circumstances an IPv6-IPv4 protocol translation solution may be a useful transitional solution, " Due to this style of idealogical design, the best that seems to be standardized now is dual stack with rfc1918 and nat on the ipv4 side. We now have a plethora of obsoleted, standardized, non standardized and not yet standardized interoperability schemes, which is kind of irritating this late in the game. NAT arrived late to IPv4 and it appears to be arriving late to IPv6 as well. Joe From owen at delong.com Tue Oct 27 10:12:41 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Oct 2009 07:12:41 -0700 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 In-Reply-To: <4AE6484A.60104@ibctech.ca> References: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> <4AE6484A.60104@ibctech.ca> Message-ID: <8829A504-751F-4803-B206-E5268A5E242C@delong.com> On Oct 26, 2009, at 6:09 PM, Steve Bertrand wrote: > Owen DeLong wrote: >> The following proposal has been sent to PPML before. It is now on >> the >> AC docket. There >> was, unfortunately, insufficient time to get it to the Dearborn >> meeting >> for adoption discussion >> outside of the petition process. >> >> At this time, I would like to solicit any additional community >> feedback >> regarding changes that >> should be made to the proposal before asking the AC to place it on >> the >> next meeting agenda >> for adoption discussion. > > To me, it seems as though there are many places within the proposal > where the term 'assignment' appears where I would expect the term > 'allocation'. > Allocations are to ISPs. This proposal is entirely about assignments to end users and does not modify the policy for allocations to ISPs. > This is slightly clouding my understanding of the policy proposal. > I hope that clarifies. > If the true intent of the proposer was to use 'assignment' in all > cases, > please forgive me. If the terminology is indeed misrepresented, can > that > be fixed? > The true intent of the proposer (me) was to use assignment in all cases for the reasons clarified above. Owen From Keith at jcc.com Tue Oct 27 10:28:11 2009 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 27 Oct 2009 10:28:11 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE6D2CE.9020006@chl.com> References: <20091027022022.D07142B211C@mx5.roble.com> <3c3e3fca0910262106v2cffedf9x67f40c1afea93d5f@mail.gmail.com> <4AE6D2CE.9020006@chl.com> Message-ID: > > Joe Maimon responding to William Herrin wrote: > > > > > You don't, at least not without changing the legal underpinnings on > > which ARIN functions. The "legacy" addresses were handed out without > > any provisions for the involuntarily canceling the registration. > > But they were not handed out by ARIN under contractual relationship. > > What legal obligation or theory prevents ARIN from updating a > record in > their database associating one string of numbers with one > organization > or another? > In the 2.5 years I've been on this list, the evilness of "legacy" resource holders has been discussed many times. The contractual status of legacy address holders is ambiguous enough that aggressive attempts by ARIN to assert authority would be very, very expensive in multiple ways, including time, goodwill, and legal costs. In my opinion, the low key approach ARIN has been taking with the Legacy RSA agreement is the correct approach. It provides a mechanism by which legacy resource holders can sign up but does not try to force them to sign. So, get over it. Stop salivating over address space held by legacy resource holders and get on with figuring out how to make IPv6 successful. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From owen at delong.com Tue Oct 27 10:31:57 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Oct 2009 07:31:57 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <20091027022022.D07142B211C@mx5.roble.com> References: <20091027022022.D07142B211C@mx5.roble.com> Message-ID: > I don't know about that. The transition was started in time but has > been > stonewalled by those planning to monetize their IP real-estate. The > stonewalling has been in the form of continued FUD regarding IPv6 > NAT. It > has also been slowed by short-sighted implementors who fail to see > that > there is no value in IPv6 until a v6 node can access 100% of the IPv4 > Internet as well. > I don't buy into either of those statements. First, I'm not really sure why you think NAT is necessary in IPv6. It really isn't, and, it really isn't a good idea. This isn't FUD, it's fact. There's really nothing in NAT that helps anything except address conservation. Many people mistake the fact that NAT requires a stateful inspection gateway to function for security being provided by NAT. The security is not provided by NAT, it is provided by stateful inspection. Second, there is lots of value in IPv6 even though IPv6 nodes cannot access the IPv4 internet. True, there's not much value today in having an IPv6 only node, but, there's lots of value in having dual-stack nodes, which is what we are really trying to get as many people as possible to move towards between now and IPv4 free pool depletion. > The bridge from v4 to v6 has only two real obstacles: 1) a > standardized > version of IPv6 NAT, and 2) a 1:1 mapping of legacy v4 routing to > v6. But > you won't hear much about these two roadblocks in this forum due to > the > signal to noise ratio, skewed by planning (sometimes salivating) > over the > coming v4 resale market. > Again, please explain why you think that NAT and all that it breaks is a necessary tool for IPv6 migration? What functionality is it that NAT provides that isn't already available without NAT? Second, I'm not sure what you mean by a 1:1 mapping of v4 routing to v6. There are already IPv4 mapped addresses in IPv6 in the form of ::ffff:192.168.5.3. If you're talking about some way for all IPv6 only nodes to reach all IPv4 only nodes and/or vice-versa, that's been shown to be a very difficult problem to solve, but, there are two solutions that seem to be gaining some traction. There is IPv4 NAT-PT, and, there is work by ISC and Comcast on a process known as Dual-Stack Lite (ds-lite). Both have their issues (mostly related to the kind of brokenness you expect from NAT), but, within certain limitations, seem to mostly work. In any case, if you think that changes to ARIN policy can in some way make this better, please let us know what changes you would like to see or, better yet, submit a proposal to effect those changes. Owen From owen at delong.com Tue Oct 27 10:34:05 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Oct 2009 07:34:05 -0700 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 In-Reply-To: <63ac96a50910261948n749b004s23cdc2fee9b6b9ec@mail.gmail.com> References: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> <4AE6484A.60104@ibctech.ca> <63ac96a50910261948n749b004s23cdc2fee9b6b9ec@mail.gmail.com> Message-ID: > > I think if Owen simply changes the title from: > > Policy Proposal Name: /24 End User Minimum Allocation Unit > > to > > Policy Proposal Name: /24 End User Minimum Assignment > > it should put the entire text once again into consistent usage, > right? At that point, the change would refer entirely to the end site > assignments, not to ISP/LIR allocations. > > Matt I can do that. The proposal does refer entirely to end-user assignments, and, the title used the term End User to specify, but, while we talk about assignments, we still (strangely) often use the term "Minimum Allocation Unit" to define the smallest assignment which can be made. However, in the interest of clarity, I will update the title prior to submitting it to the next step. Thanks, Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From BillD at cait.wustl.edu Tue Oct 27 11:29:49 2009 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 27 Oct 2009 10:29:49 -0500 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs Message-ID: Hello, I am the ARIN Advisory Council shepherd for policy proposal #98 Last Minute Assistance for Small ISPs. This policy proposal(PP) was authored by Ted Mittelstaedt and accepted onto the ACs docket to review and work on. It was received too late to evaluate fully, fashion acceptable text to become a draft policy and be presented at the Dearborn meeting, just past. Essentially, the PP asks ARIN to follow a predetermined lowering of the minimum allocation size of blocks for ISPs as the free pool(FP) of ARIN addresses depletes. The minimum allocation size of /20 would be lowered to /21 when ARIN has allocated 90% of its FP (which presumably is the last IANA /8 allocated according to NRPM 10.4). Subsequently, when the FP exhausts 95% the minimum will become a /22. At 97% exhaustion, the minimum becomes /23 and remains so. The purpose is to allow ISPs who have never been able to qualify for /20 allocations, to qualify under this policy for small blocks of address space. The AC accepted this PP because it is yet another end-game tool proposed to transition the industry and expectations during the runout of IPv4 addresses and there seems to be sympathy with this in the community. Reservations expressed by myself at the time of acceptance was that the proposal seemed overly complex with thresholds and tiggers that rely upon 1/ ARIN's ability to accurately assess the remaining free pool in small, single digit percentages; 2/ the ability of ARIN to react to changes in status of the free pool based upon these thresholds and announce the changes to the public; and 3/ most importantly, that all these thresholds and all the remaining FP might be eliminated with a single justified large allocation rendering the policy's incremental process mute. However, IF space were returned in small amounts to ARIN, post runout, then this policy would establish a new and continuing small size for allocations to help emerging or other small ISPs. It is impossible to predict the status of the Internet routing table at this time and whether upstream providers would announce such small networks. It is therefore impossible to predict the usefulness of this outcome of the policy. In preparation for AC discussion of this PP to determine its fate (abandonment or adoption as a draft policy), I ask the Internet community to read the PP at http://lists.arin.net/pipermail/arin-ppml/2009-July/014747.html and comment on this list. Specifically, I would request your 1/ interpretation of this policy as it may differ from my explanation above; 2/ assessment of the practicality and usefulness of this policy; and 3/ a clear statement of support or lack of support for this PP becoming a draft policy. If it becomes a draft policy, it will be discussed at the Toronto public policy meeting and perhaps eventually become an implemented policy. Thank you for your support of ARIN and your involvement in the policy development process. Bill Darte ARIN Advisory Council From tedm at ipinc.net Tue Oct 27 12:11:21 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 27 Oct 2009 09:11:21 -0700 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 In-Reply-To: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> References: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> Message-ID: <4AE71BA9.4090002@ipinc.net> Sorry for the top post, I also agree the title needs to be changed to assignment. While I have no problem with the idea of the proposal I do have a concern about this sentence: "...When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose so long as that is feasible..." To me, this sentence is basically deadweight. The first part of it mandates use of a special block reserved for this purpose (what makes that block special is not defined) then the second part of it lets ARIN staff off the hook since there is no definition of what constitutes feasibility. It seems your trying to kill 2 birds with one stone - you want to reduce fragmentation by making the less-than-/20 crowd renumber and return (which is a goal I agree with, as renumbering a couple /24's over a year's time should not be a problem) and you want to push the small block holders into a "neighborhood" of other small block holders - yet your not mandating this, your just kind of "encouraging" it. Stuff that doesn't mandate the ARIN staff to follow a particular set of rules is a distraction, may cause some people who would support the proposal to oppose it, and in the event that the proposal gets accepted, the ARIN staffers may end up stumbling over the thinly-defined section of the policy. At the risk of beating a dead horse, look at the WHOIS POC cleanup - that was deliberately written with a vague section because the concern was that a more explicit definition would tie ARIN staff's hands - yet instead of being happy about that, and using the freedom to overcome implementation roadblocks on the cleanup - ARIN staff pushed back, wanting to delay implementation, saying they had a problem implementing that section. :-( (Kind of a damned if you do, damned if you don't issue) Anyway, I think you ought to either strike that sentence entirely or add more sentences that more clearly define what it is that your getting at. Ted Owen DeLong wrote: > The following proposal has been sent to PPML before. It is now on the > AC docket. There > was, unfortunately, insufficient time to get it to the Dearborn meeting > for adoption discussion > outside of the petition process. > > At this time, I would like to solicit any additional community feedback > regarding changes that > should be made to the proposal before asking the AC to place it on the > next meeting agenda > for adoption discussion. > > Thanks, > > Owen > > >>/ TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > />/ > />/ 1. Policy Proposal Name: /24 End User Minimum Allocation Unit > />/ 2. Proposal Originator: Owen DeLong > />/ > />/ > />/ 3. Proposal Version: 0.9 > />/ 4. Date: 8/3/09 > />/ 5. Proposal type: new > />/ 6. Policy term: permanent > />/ 7. Policy statement: > />/ > />/ Replace section 4.3.2.2 of the NRPM with the following: > />/ > />/ 4.3.2.2 Multihomed Connection > />/ > />/ For end-users who demonstrate an intent to announce the requested space in a > />/ multihomed fashion to two or more distinct providers, the minimum block of IP > />/ address space assigned is a /24. If assignments smaller than a /24 are needed, > />/ multihomed end-users should contact their upstream providers. When prefixes are > />/ assigned which are longer than /20, they will be from a block reserved for that > />/ purpose so long as that is feasible. End-users may not receive a block > />/ smaller > />/ than /22 under this policy if they already have resources from ARIN, > />/ except as > />/ specified in section 4.3.6.2. > />/ > />/ Renumber the existing paragraph under the 4.3.6 to > />/ > />/ 4.3.6.1 Utilization requirements for additional Assignment > />/ > />/ Add the following paragraph 4.3.6.2 > />/ > />/ 4.3.6.2 Replacement assignments for small multi-homers > />/ > />/ Any end-user that possesses an assignment smaller than /22 under any > />/ part of > />/ section 4.3 shall not be able to get an additional assignment unless > />/ they agree > />/ to return all existing assignments within 12 months of receiving a new > />/ assignment. > />/ The new assignment shall be sized to accommodate their existing > />/ utilization in > />/ addition to their justified additional growth space under section 4.3.6.1. > />/ The common cases for this are expected to be a /24 returned after > />/ receipt of a /23, > />/ or a /23 returned after receipt of a /22. > />/ > />/ 8. Rationale: > />/ > />/ This policy attempts to incorporate the recent and historical discussions of > />/ policy for multi-home users on PPML. The intent is to provide as fair a process > />/ as possible for multi-homed organizations down to the smallest feasible size > />/ while still preserving some control over growth in the routing table. > />/ > />/ It has been repeatedly noted that /24 multi-homers exist today with PA space > />/ and still occupy a routing table slot, so, it is unlikely that moving this > />/ boundary to /24 would significantly impact the routing table. > />/ > />/ By requiring smaller assignments to renumber and return, rather than add more > />/ small blocks to their assignments, this policy seeks to further reduce the > />/ chances of unnecessary growth in the routing table and encourage good aggregation > />/ where possible. > />/ > />/ 9. Timetable for implementation: Immediate > />/ > />/ END OF TEMPLATE > /> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tedm at ipinc.net Tue Oct 27 13:19:35 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 27 Oct 2009 10:19:35 -0700 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: References: Message-ID: <4AE72BA7.8000901@ipinc.net> Bill Darte wrote: > Hello, > > I am the ARIN Advisory Council shepherd for policy proposal #98 Last > Minute Assistance for Small ISPs. > > This policy proposal(PP) was authored by Ted Mittelstaedt and accepted > onto the ACs docket to review and work on. It was received too late to > evaluate fully, fashion acceptable text to become a draft policy and be > presented at the Dearborn meeting, just past. > > Essentially, the PP asks ARIN to follow a predetermined lowering of the > minimum allocation size of blocks for ISPs as the free pool(FP) of ARIN > addresses depletes. The minimum allocation size of /20 would be lowered > to /21 when ARIN has allocated 90% of its FP (which presumably is the > last IANA /8 allocated according to NRPM 10.4). Subsequently, when the > FP exhausts 95% the minimum will become a /22. At 97% exhaustion, the > minimum becomes /23 and remains so. The purpose is to allow ISPs who > have never been able to qualify for /20 allocations, to qualify under > this policy for small blocks of address space. > > The AC accepted this PP because it is yet another end-game tool proposed > to transition the industry and expectations during the runout of IPv4 > addresses and there seems to be sympathy with this in the community. > > Reservations expressed by myself at the time of acceptance was that the > proposal seemed overly complex with thresholds and tiggers that rely > upon 1/ ARIN's ability to accurately assess the remaining free pool in > small, single digit percentages; 2/ the ability of ARIN to react to > changes in status of the free pool based upon these thresholds and > announce the changes to the public; and 3/ most importantly, that all > these thresholds and all the remaining FP might be eliminated with a > single justified large allocation rendering the policy's incremental > process mute. > > However, IF space were returned in small amounts to ARIN, post runout, > then this policy would establish a new and continuing small size for > allocations to help emerging or other small ISPs. It is impossible to > predict the status of the Internet routing table at this time and > whether upstream providers would announce such small networks. It is > therefore impossible to predict the usefulness of this outcome of the > policy. > > In preparation for AC discussion of this PP to determine its fate > (abandonment or adoption as a draft policy), I ask the Internet > community to read the PP at > http://lists.arin.net/pipermail/arin-ppml/2009-July/014747.html and > comment on this list. > > Specifically, I would request your 1/ interpretation of this policy as > it may differ from my explanation above; Bill, your interpretation and assessment is excellent. The policy working likely needs to be tweaked a bit, but you have the intent right. > 2/ assessment of the > practicality and usefulness of this policy; I would like to know this as well, particularly as my employer is not in the affected group. > and 3/ a clear statement of > support or lack of support for this PP becoming a draft policy. If it > becomes a draft policy, it will be discussed at the Toronto public > policy meeting and perhaps eventually become an implemented policy. > > Thank you for your support of ARIN and your involvement in the policy > development process. > > Bill Darte > ARIN Advisory Council > Thanks, Ted From cgrundemann at gmail.com Tue Oct 27 13:36:43 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 27 Oct 2009 11:36:43 -0600 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: References: Message-ID: <443de7ad0910271036w4e72cda1rd757a389bd182b97@mail.gmail.com> On Tue, Oct 27, 2009 at 09:29, Bill Darte wrote: > Hello, > > I am the ARIN Advisory Council shepherd for policy proposal #98 Last > Minute Assistance for Small ISPs. > > This policy proposal(PP) was authored by Ted Mittelstaedt and accepted > onto the ACs docket to review and work on. ?It was received too late to > evaluate fully, fashion acceptable text to become a draft policy and be > presented at the Dearborn meeting, just past. > > Essentially, the PP asks ARIN to follow a predetermined lowering of the > minimum allocation size of blocks for ISPs as the free pool(FP) of ARIN > addresses depletes. ?The minimum allocation size of /20 would be lowered > to /21 when ARIN has allocated 90% of its FP (which presumably is the > last IANA /8 allocated according to NRPM 10.4). Subsequently, when the > FP exhausts 95% the minimum will become a /22. ?At 97% exhaustion, the > minimum becomes /23 and remains so. ?The purpose is to allow ISPs who > have never been able to qualify for /20 allocations, to qualify under > this policy for small blocks of address space. > > The AC accepted this PP because it is yet another end-game tool proposed > to transition the industry and expectations during the runout of IPv4 > addresses and there seems to be sympathy with this in the community. > > Reservations expressed by myself at the time of acceptance was that the > proposal seemed overly complex with thresholds and tiggers that rely > upon 1/ ARIN's ability to accurately assess the remaining free pool in > small, single digit percentages; 2/ the ability of ARIN to react to > changes in status of the free pool based upon these thresholds and > announce the changes to the public; and 3/ most importantly, that all > these thresholds and all the remaining FP might be eliminated with a > single justified large allocation rendering the policy's incremental > process mute. I agree. With regard to this PP and other PP and DP which deal with IPv4-free-pool-run-out / soft-landing strategies: I am beginning to wonder if it isn't better to do away with all of the staggered triggers and accompanying complexity for a much simpler approach. In this case specifically, if the community believes that lowering the minimum allocation may help as we approach and pass IPv4 free-pool exhaustion, why not just lower it now? Forget the triggers all together. One of the most frequent, loud and justified complaints I have heard regarding other trigger-based policies is that they make it harder to plan. Add to that the added complexity for ARIN staff during what will likely be an already complex time. Eliminating them doesn't seem to reduce the potential effectiveness of this policy, imo. The fact is that we are very close, in policy-cycle terms, to the end of unallocated IPv4 and as such I think that we may want to carefully consider what benefit, if any, these triggers offer. If lowering the minimum allocation is a good idea, let's just do it now. If lowering the maximum allocation is a good idea, let's just do it now. Etc. I think our time is better spent arguing the merits of the actual changes rather than the details of the triggering events. > > However, IF space were returned in small amounts to ARIN, post runout, > then this policy would establish a new and continuing small size for > allocations to help emerging or other small ISPs. ?It is impossible to > predict the status of the Internet routing table at this time and > whether upstream providers would announce such small networks. ?It is > therefore impossible to predict the usefulness of this outcome of the > policy. Despite the title and rational, this would not only help small ISPs; post run-out especially it would potentially help anyone willing to take a small allocation from any return pool which emerges (I don't see anything in the policy which actually limits it to small ISPs). If IPv4 continues to become more valuable, larger and larger ISPs will have to learn to do more and more with less and less. I also note that this PP may compliment PP 97 - Waiting List for Unmet IPv4 Requests in that it could help offer more options to folks post run-out if small blocks (legacy /24s perhaps) are returned; take this /23 that we _do_ have or go find your /20 via a transfer... > In preparation for AC discussion of this PP to determine its fate > (abandonment or adoption as a draft policy), I ask the Internet > community to read the PP at > http://lists.arin.net/pipermail/arin-ppml/2009-July/014747.html and > comment on this list. > > Specifically, I would request your 1/ interpretation of this policy as > it may differ from my explanation above; 2/ assessment of the > practicality and usefulness of this policy; and 3/ a clear statement of > support or lack of support for this PP becoming a draft policy. ?If it > becomes a draft policy, it will be discussed at the Toronto public > policy meeting and perhaps eventually become an implemented policy. 1) My interpretation basically matches yours, with additional comments above. 2) As written the policy is not practical, lowering the minimum allocation may be useful however. 3) I think that the triggering events should be removed so that we can discuss the merits of lowering the minimum allocation. I support the creation of a draft policy which simply lowers the size of the minimum allocation for _non-transfer_ allocations. > Thank you for your support of ARIN and your involvement in the policy > development process. > > Bill Darte > ARIN Advisory Council > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From bicknell at ufp.org Tue Oct 27 13:57:08 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 27 Oct 2009 10:57:08 -0700 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: References: Message-ID: <20091027175708.GA44686@ussenterprise.ufp.org> In a message written on Tue, Oct 27, 2009 at 10:29:49AM -0500, Bill Darte wrote: > minimum becomes /23 and remains so. The purpose is to allow ISPs who > have never been able to qualify for /20 allocations, to qualify under > this policy for small blocks of address space. This is the part of the proposal that has me the most confused. It seems to purposely target ISPs who do not interact with ARIN today and attempt to make them deal with ARIN at the last minute. I find it likely most of these ISP's, given their modest needs, would only get a single allocation of IPv4 resources from ARIN, ever. I'm not quite sure I see how it is of assistance to these extra small ISP's to make them jump through a hoop they are not familiar with at all in order to receive a one-time, very small allocation of IPv4 resources. I would find it extremely helpful if someone could provide two or three plausable scenarios where this policy would cause a benefit greater than the work it introduces. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From owen at delong.com Tue Oct 27 14:34:47 2009 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Oct 2009 11:34:47 -0700 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 In-Reply-To: <4AE71BA9.4090002@ipinc.net> References: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> <4AE71BA9.4090002@ipinc.net> Message-ID: On Oct 27, 2009, at 9:11 AM, Ted Mittelstaedt wrote: > > Sorry for the top post, I also agree the title needs to be > changed to assignment. While I have no problem with the > idea of the proposal I do have a concern about this sentence: > The title will be changed, as I already stated. > "...When prefixes are assigned which are longer than /20, they will > be from a block reserved for that purpose so long as that is > feasible..." > > To me, this sentence is basically deadweight. The first part of it > mandates use of a special block reserved for this purpose (what > makes that block special is not defined) then the second part of it > lets > ARIN staff off the hook since there is no definition of what > constitutes feasibility. > The first phrase is verbatim from the existing policy allowing for assignments to be made down to /22. The "So long as it is feasible" refers to the fact that if ARIN runs out of space in this block, we don't want them to be unable to assign these addresses while there is still space in the block previously reserved for /20 and shorter assignments. > It seems your trying to kill 2 birds with one stone - you want to > reduce fragmentation by making the less-than-/20 crowd renumber > and return (which is a goal I agree with, as renumbering a couple > /24's over a year's time should not be a problem) and you want > to push the small block holders into a "neighborhood" of other > small block holders - yet your not mandating this, your just kind > of "encouraging" it. > No, we're mandating it as long as it can be maintained. I have reason to believe that ARIN staff is quite clear on the meaning of this and their obligations as a result. It doesn't let ARIN off the hook until such time as they have no space to assign from this separate block and must issue the space from the few remaining blocks which contain some /20 and shorter issuances. > Stuff that doesn't mandate the ARIN staff to follow a particular > set of rules is a distraction, may cause some people who would > support the proposal to oppose it, and in the event that the > proposal gets accepted, the ARIN staffers may end up stumbling > over the thinly-defined section of the policy. > Agreed, but, that's not the case here. > At the risk of beating a dead horse, look at the WHOIS POC cleanup - > that was deliberately written with a vague section because the > concern was that a more explicit definition would tie ARIN staff's > hands - yet instead of being happy about that, and using the > freedom to overcome implementation roadblocks on the cleanup - > ARIN staff pushed back, wanting to delay implementation, saying they > had a problem implementing that section. :-( (Kind of a damned if you > do, damned if you don't issue) > This issue is, actually being worked on and I think we will see cooperation from staff going forward. > Anyway, I think you ought to either strike that sentence entirely > or add more sentences that more clearly define what it is that > your getting at. > Tell you what... Let's wait for the staff and legal assessment on this one. If staff doesn't clearly state what they accept the phrase to mean along the lines I just specified above, I'll update with clarifying language. However, I think it is pretty clear as it stands and believe that more verbiage to explain the meaning of the term feasible in this context would simply be superfluous. Owen > Ted > > Owen DeLong wrote: >> The following proposal has been sent to PPML before. It is now on >> the AC docket. There >> was, unfortunately, insufficient time to get it to the Dearborn >> meeting for adoption discussion >> outside of the petition process. >> At this time, I would like to solicit any additional community >> feedback regarding changes that >> should be made to the proposal before asking the AC to place it on >> the next meeting agenda >> for adoption discussion. >> Thanks, >> Owen >>> / TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 >> />/ >> />/ 1. Policy Proposal Name: /24 End User Minimum Allocation >> Unit >> />/ 2. Proposal Originator: Owen DeLong >> />/ />/ >> />/ 3. Proposal Version: 0.9 >> />/ 4. Date: 8/3/09 >> />/ 5. Proposal type: new >> />/ 6. Policy term: permanent >> />/ 7. Policy statement: >> />/ >> />/ Replace section 4.3.2.2 of the NRPM with the following: >> />/ >> />/ 4.3.2.2 Multihomed Connection >> />/ >> />/ For end-users who demonstrate an intent to announce the >> requested space in a >> />/ multihomed fashion to two or more distinct providers, the >> minimum block of IP >> />/ address space assigned is a /24. If assignments smaller than a / >> 24 are needed, >> />/ multihomed end-users should contact their upstream providers. >> When prefixes are >> />/ assigned which are longer than /20, they will be from a block >> reserved for that >> />/ purpose so long as that is feasible. End-users may not receive >> a block />/ smaller >> />/ than /22 under this policy if they already have resources from >> ARIN, />/ except as >> />/ specified in section 4.3.6.2. >> />/ >> />/ Renumber the existing paragraph under the 4.3.6 to />/ >> />/ 4.3.6.1 Utilization requirements for additional Assignment >> />/ >> />/ Add the following paragraph 4.3.6.2 >> />/ >> />/ 4.3.6.2 Replacement assignments for small multi-homers >> />/ >> />/ Any end-user that possesses an assignment smaller than /22 >> under any />/ part of >> />/ section 4.3 shall not be able to get an additional assignment >> unless />/ they agree >> />/ to return all existing assignments within 12 months of >> receiving a new />/ assignment. >> />/ The new assignment shall be sized to accommodate their >> existing />/ utilization in >> />/ addition to their justified additional growth space under >> section 4.3.6.1. >> />/ The common cases for this are expected to be a /24 returned >> after />/ receipt of a /23, >> />/ or a /23 returned after receipt of a /22. >> />/ >> />/ 8. Rationale: >> />/ >> />/ This policy attempts to incorporate the recent and historical >> discussions of >> />/ policy for multi-home users on PPML. The intent is to provide >> as fair a process >> />/ as possible for multi-homed organizations down to the smallest >> feasible size >> />/ while still preserving some control over growth in the routing >> table. >> />/ >> />/ It has been repeatedly noted that /24 multi-homers exist today >> with PA space >> />/ and still occupy a routing table slot, so, it is unlikely that >> moving this >> />/ boundary to /24 would significantly impact the routing table. >> />/ >> />/ By requiring smaller assignments to renumber and return, rather >> than add more >> />/ small blocks to their assignments, this policy seeks to further >> reduce the >> />/ chances of unnecessary growth in the routing table and >> encourage good aggregation >> />/ where possible. >> />/ >> />/ 9. Timetable for implementation: Immediate >> />/ >> />/ END OF TEMPLATE >> /> >> ------------------------------------------------------------------------ >> _______________________________________________ >> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From tedm at ipinc.net Tue Oct 27 15:04:03 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 27 Oct 2009 12:04:03 -0700 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: <20091027175708.GA44686@ussenterprise.ufp.org> References: <20091027175708.GA44686@ussenterprise.ufp.org> Message-ID: <4AE74423.4050805@ipinc.net> Leo Bicknell wrote: > In a message written on Tue, Oct 27, 2009 at 10:29:49AM -0500, Bill Darte wrote: >> minimum becomes /23 and remains so. The purpose is to allow ISPs who >> have never been able to qualify for /20 allocations, to qualify under >> this policy for small blocks of address space. > > This is the part of the proposal that has me the most confused. It > seems to purposely target ISPs who do not interact with ARIN today > and attempt to make them deal with ARIN at the last minute. Essentially correct. The problem is that these ISP currently do NOT interface with ARIN today BUT WANT TO. > I find > it likely most of these ISP's, given their modest needs, would only > get a single allocation of IPv4 resources from ARIN, ever. > Also correct. > I'm not quite sure I see how it is of assistance to these extra > small ISP's to make them jump through a hoop they are not familiar > with at all in order to receive a one-time, very small allocation > of IPv4 resources. > I will leave it to the small ISP's to let you know how much of assistance it would be. > I would find it extremely helpful if someone could provide two or > three plausable scenarios where this policy would cause a benefit > greater than the work it introduces. > There's a huge, and in my ever so humble opinion, well founded, fear among the small ISP's that when IPv4 runout happens, the LIR's they are getting their IPv4 allocations from are going, to put it bluntly, bend them over the table and completely screw them over. Think about it for a minute. Suppose a big ISP like, say, Jono-gent, were to have this large, luscious /18 that they got from an acquisition, and they have, as is customary for them due to their horribly awful tracking, been paying very little attention to. Over the years as customers have disconnected, or gone to translation, large sections of this /18 have become abandoned. SO, 6 months after IPv4 runout, this hytra-headed transfer market that we have allowed through "emergency action" of the Board to come into existence, has put a market price of a million bucks on that /18 Jono-gent, strapped for cash, sees these wild prices and thinks, Hey, I can clean up my IPv4 allocations and sell off some of them. This is, after all, behavior that we WANT to happen, that we are HOPING the transfer market will provoke. So, SmallCo ISP gets a letter from Jono-gent saying that first, they must vacate that /24 that they have their nameservers on (with 2000 domains on) in 90 days, and second, that the new /24 that Jono-gent is going to renumber them into is going to have just a -slight- price increase, nothing that a few extra thousand bucks a year won't cover. Well, I can assure you that I have heard from some small ISP's who are afraid of such a scenario. They want to get their own IPv4 block NOW. They are MORE than willing to jump into IPv6, but their admins cannot justify spending a lot of money on direct IPv6 assignments (not to mention that Jono-gent isn't even running IPv6 natively yet) when they are spending a few thousand bucks a year with Jono-gent on a /24 If we allow them to climb into the ship with ARIN before the train wreck, then they can get both IPv4 and IPv6 for the same price, and then start working on their IPv6 deployments with tunnel brokers or whatever. They know they will never get another IPv4 block, not just because of being small, but because once the transfer market is in full swing, prices on that will be out of their league. And, frankly, the sad truth is that the vast majority of these small ISP's won't be coming to ARIN for help until that day 3-4 years from now that they get their own Jono-gent letter ordering them to be renumbered - and will be screwed. It will be bad enough to tell them "Sorry, but you guys HAD your chance a few years ago to get a small allocation and you were asleep at the stick" I don't want to be the one telling the ones who WEREN'T asleep at the stick, and are asking for a small block NOW, that we won't help them. Do you? Ted From tedm at ipinc.net Tue Oct 27 15:11:04 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 27 Oct 2009 12:11:04 -0700 Subject: [arin-ppml] Proposal 99 -- IPv4 multihomed end-user minimum to /24 In-Reply-To: References: <18DC16EE-5028-4C40-B7C7-FCF0B200E291@delong.com> <4AE71BA9.4090002@ipinc.net> Message-ID: <4AE745C8.7080103@ipinc.net> Owen DeLong wrote: > > >> Anyway, I think you ought to either strike that sentence entirely >> or add more sentences that more clearly define what it is that >> your getting at. >> > Tell you what... Let's wait for the staff and legal assessment on > this one. If staff doesn't clearly state what they accept the phrase > to mean along the lines I just specified above, I'll update with > clarifying language. However, I think it is pretty clear as it stands > and believe that more verbiage to explain the meaning of the > term feasible in this context would simply be superfluous. > It sounds reasonable, but I don't think reason always enters into these things. :-) I'm just warning you. I'd keep that staff assessment handy, though. Ted From cengel at sponsordirect.com Wed Oct 28 12:50:54 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 28 Oct 2009 12:50:54 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: Message-ID: Owen, Only addressing the portion of your post that deals with NAT.... "First, I'm not really sure why you think NAT is necessary in IPv6. It really isn't, and, it really isn't a good idea. This isn't FUD, it's fact. There's really nothing in NAT that helps anything except address conservation. Many people mistake the fact that NAT requires a stateful inspection gateway to function for security being provided by NAT. The security is not provided by NAT, it is provided by stateful inspection" NAT is an EXTREMELY usefull tool to Network/System Admins. While it is certainly possible to function without it...the utility of it should not be underestimated. Here are examples of it's utility.... 1) It acts as an insurance policy against FW misconfigurations. Simply put for most businesses/organizations, the majority of devices on your network you do NOT want reachable by external traffic. While it is certainly possible to do that with assigning each device a public address and using FW rules to deny external access.... in the real world we know that FW misconfigurations are not that uncommon...particularly when you have complex series of rules at multiple individuals responsible for the creation and maintenance of them. NAT allows you to utilize private network addresses for ALL your internal devices.... which makes them unaccessable to external traffic BY DEFAULT...and then allows you to assign public IP's to ONLY those devices which are intended to be externaly accessible. Simply screw that up (i.e. purposefully taking action to NAT something that shouldn't be) then it is to make sure that NONE of your (possibly several hundred) FW rules inadvertantly opens a hole to a device that it shouldn't. 2) NAT allows Network Admins the flexability to organize thier own private address space and the assignment of IP's in ways that logicaly make sense to them. For example, on my own network.... by looking at the IP address I can instantly tell not only what network segment a device is on but what TYPE of address it is as well (Server, Workstation, Printer, etc). I don't believe I would be able to achieve the same results if I had to limit my assignments to the public address range that was provided by my ISP (even if they gave me as many addresses as I wanted). 3) NAT allows you to abstract your internal infrastructure from the external services you present. This has alot of utility. For example, lets say I provide a service to external users on (external IP) x.x.x.28 If I want to upgrade or change the device that provides that service NAT makes it very easy. I simply bring up the new device on it's own internal IP.... seperate from the internal IP assigned to the existing device.... and when I want to bring the new device into service all I need to do is switch the NATing on the FW and the new device is now instantly providing that service for external users. Nothing needs to change about how the external users access the device.... they may not even be aware that there was a change of device providing the service.... however all my internal references for both devices remain intact and distinct... which can be very important. Without NAT, I would either have to bring the new device up on a new public IP and inform all external users of how to access it (which may not even be possible) OR I would have to assign the device the existing devices IP address (and presumably give the existing device a new one) so that external access remained the same. However in that case I'd have to CHANGE ALL MY INTERNAL REFERENCES to the devices to make sure they were pointing at the right machines. That method would be far, far less efficient the utilizing NAT. 4) Conservation of addresses has utility beyond just the sparcity/difficulty in acquiring the resource. It saves time and effort. Simply put, it is far easier to manage 12 public IP addresses then 300. I only need to worry about doing DNS/RDNS/FW Rules/Usage Tracking, etc for those 12. Without NAT I'm doomed to either do it for all 300 or constantly shuffling around the IP addresses assigned to individual NIC's..... either way spells doing alot more work then would be truely neccesary otherwise. These are just a few of the uses NAT has for me. I don't think I'm alone among Network Admins in saying it's a very usefull tool....regardless of how many IP's we were able to get assigned to us. Christopher Engel From spiffnolee at yahoo.com Wed Oct 28 12:45:45 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Wed, 28 Oct 2009 09:45:45 -0700 (PDT) Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE6F275.7060006@chl.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> Message-ID: <395061.64110.qm@web63302.mail.re1.yahoo.com> ----- Original Message ---- > From: Joe Maimon > To: RudOlph Daniel > Cc: arin-ppml at arin.net > Sent: Tue, October 27, 2009 7:15:33 AM > Subject: Re: [arin-ppml] v4 to v6 obstacles > > > > RudOlph Daniel wrote: > > Hi Roger > > Your suggestion is that NAT-PT is not going to be a worker, which was also the > suggestion of RFC4966. So what alternatives do we have for 100% v6 access to v4 > and how can we live with less than 100% if the solution is as you suggest not > yet available? > > > I was under the impression that complaints about ipv6-ipv4 interoperability > generally refer to the idealogical reasons that did their best to sink nat-pt, > even while grudgingly acknowledging > > " > However, it is clear that in some circumstances an IPv6-IPv4 protocol > translation solution may be a useful transitional solution, > " > > Due to this style of idealogical design, the best that seems to be standardized > now is dual stack with rfc1918 and nat on the ipv4 side. > > We now have a plethora of obsoleted, standardized, non standardized and not yet > standardized interoperability schemes, which is kind of irritating this late in > the game. > > NAT arrived late to IPv4 and it appears to be arriving late to IPv6 as well. Different issues. I don't see a need for NAT66. But Address Family Translation (AFT, or NAT46 and NAT64) would be useful. NAPT-PT, being deprecated, is poorly supported. Seems like people are holding their breath for NAT64, and maybe someday somebody will submit a draft for NAT46. Which is too late to get gear fielded. And doesn't solve most of the issues identified in RFC4966. Is it possible to "reprecrate" something that has been deprecated? Can we obsolete RFC4966? Anyone have a pointer to the right list for that? Lee From spetty at iconnect-corp.com Wed Oct 28 12:58:22 2009 From: spetty at iconnect-corp.com (Steven E. Petty) Date: Wed, 28 Oct 2009 12:58:22 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <402EB9414506BC40BB42CD47317FD1B312CE56A251@Maggie.iconnect-corp.com> You may want to do a little more research into IPv6. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Engel Sent: Wednesday, October 28, 2009 12:51 PM To: 'owen at delong.com' Cc: 'arin-ppml at arin.net' Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern Owen, Only addressing the portion of your post that deals with NAT.... "First, I'm not really sure why you think NAT is necessary in IPv6. It really isn't, and, it really isn't a good idea. This isn't FUD, it's fact. There's really nothing in NAT that helps anything except address conservation. Many people mistake the fact that NAT requires a stateful inspection gateway to function for security being provided by NAT. The security is not provided by NAT, it is provided by stateful inspection" NAT is an EXTREMELY usefull tool to Network/System Admins. While it is certainly possible to function without it...the utility of it should not be underestimated. Here are examples of it's utility.... 1) It acts as an insurance policy against FW misconfigurations. Simply put for most businesses/organizations, the majority of devices on your network you do NOT want reachable by external traffic. While it is certainly possible to do that with assigning each device a public address and using FW rules to deny external access.... in the real world we know that FW misconfigurations are not that uncommon...particularly when you have complex series of rules at multiple individuals responsible for the creation and maintenance of them. NAT allows you to utilize private network addresses for ALL your internal devices.... which makes them unaccessable to external traffic BY DEFAULT...and then allows you to assign public IP's to ONLY those devices which are intended to be externaly accessible. Simply screw that up (i.e. purposefully taking action to NAT something that shouldn't be) then it is to make sure that NONE of your (possibly several hundred) FW rules inadvertantly opens a hole to a device that it shouldn't. 2) NAT allows Network Admins the flexability to organize thier own private address space and the assignment of IP's in ways that logicaly make sense to them. For example, on my own network.... by looking at the IP address I can instantly tell not only what network segment a device is on but what TYPE of address it is as well (Server, Workstation, Printer, etc). I don't believe I would be able to achieve the same results if I had to limit my assignments to the public address range that was provided by my ISP (even if they gave me as many addresses as I wanted). 3) NAT allows you to abstract your internal infrastructure from the external services you present. This has alot of utility. For example, lets say I provide a service to external users on (external IP) x.x.x.28 If I want to upgrade or change the device that provides that service NAT makes it very easy. I simply bring up the new device on it's own internal IP.... seperate from the internal IP assigned to the existing device.... and when I want to bring the new device into service all I need to do is switch the NATing on the FW and the new device is now instantly providing that service for external users. Nothing needs to change about how the external users access the device.... they may not even be aware that there was a change of device providing the service.... however all my internal references for both devices remain intact and distinct... which can be very important. Without NAT, I would either have to bring the new device up on a new public IP and inform all external users of how to access it (which may not even be possible) OR I would have to assign the device the existing devices IP address (and presumably give the existing device a new one) so that external access remained the same. However in that case I'd have to CHANGE ALL MY INTERNAL REFERENCES to the devices to make sure they were pointing at the right machines. That method would be far, far less efficient the utilizing NAT. 4) Conservation of addresses has utility beyond just the sparcity/difficulty in acquiring the resource. It saves time and effort. Simply put, it is far easier to manage 12 public IP addresses then 300. I only need to worry about doing DNS/RDNS/FW Rules/Usage Tracking, etc for those 12. Without NAT I'm doomed to either do it for all 300 or constantly shuffling around the IP addresses assigned to individual NIC's..... either way spells doing alot more work then would be truely neccesary otherwise. These are just a few of the uses NAT has for me. I don't think I'm alone among Network Admins in saying it's a very usefull tool....regardless of how many IP's we were able to get assigned to us. Christopher Engel _______________________________________________ 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 cgrundemann at gmail.com Wed Oct 28 13:02:07 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 28 Oct 2009 11:02:07 -0600 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> On Wed, Oct 28, 2009 at 10:50, Chris Engel wrote: > Owen, > > Only addressing the portion of your post that deals with NAT.... > > > "First, I'm not really sure why you think NAT is necessary in IPv6. ?It > really isn't, > and, it really isn't a good idea. ?This isn't FUD, it's fact. ?There's > really nothing > in NAT that helps anything except address conservation. Many people > mistake > the fact that NAT requires a stateful inspection gateway to function for > security being provided by NAT. ?The security is not provided by NAT, it > is provided by stateful inspection" > > > NAT is an EXTREMELY usefull tool to Network/System Admins. While it is certainly possible to function without it...the utility of it should not be underestimated. Here are examples of it's utility.... > Just for fun; I have not worked on an enterprise network in a while but a lot of this sounds a bit flimsy, even to me... > > 1) It acts as an insurance policy against FW misconfigurations. ?Simply put for most businesses/organizations, the majority of devices on your network you do NOT want reachable by external traffic. While it is certainly possible to do that with assigning each device a public address and using FW rules to deny external access.... in the real world we know that FW misconfigurations are not that uncommon...particularly when you have complex series of rules at multiple individuals responsible for the creation and maintenance of them. NAT allows you to utilize private network addresses for ALL your internal devices.... which makes them unaccessable to external traffic BY DEFAULT...and then allows you to assign public IP's to ONLY those devices which are intended to be externaly accessible. Simply screw that up (i.e. purposefully taking action to NAT something that shouldn't be) then it is to make sure that NONE of your (possibly several hundred) FW rules inadvertantly opens a hole > ?to a device that it shouldn't. > Create a default rule in your firewall to deny all inbound non-established connections to all internal devices and then poke holes just to devices that need to be accessed externally. This still requires an active change to allow access and all internal devices are unaccessible by default. > > 2) NAT allows Network Admins the flexability to organize thier own private address space and the assignment of IP's in ways that logicaly make sense to them. For example, on my own network.... by looking at the IP address I can instantly tell not only what network segment a device is on but what TYPE of address it is as well (Server, Workstation, Printer, etc). I don't believe I would be able to achieve the same results if I had to limit my assignments to the public address range that was provided by my ISP (even if they gave me as many addresses as I wanted). > If you can do this with 32 bits I do not see how you would be unable to do it with 80 bits. > > 3) NAT allows you to abstract your internal infrastructure from the external services you present. This has alot of utility. For example, lets say I provide a service to external users on ?(external IP) x.x.x.28 ? If I want to upgrade or change the device that provides that service NAT makes it very easy. I simply bring up the new device on it's own internal IP.... seperate from the internal IP assigned to the existing device.... and when I want to bring the new device into service all I need to do is switch the NATing on the FW and the new device is now instantly providing that service for external users. Nothing needs to change about how the external users access the device.... they may not even be aware that there was a change of device providing the service.... however all my internal references for both devices remain intact and distinct... which can be very important. ?Without NAT, I would either have to bring the new device up on a new public IP and inform all external > ?users of how to access it (which may not even be possible) OR I would have to assign the device the existing devices IP address (and presumably give the existing device a new one) so that external access remained the same. However in that case I'd have to CHANGE ALL MY INTERNAL REFERENCES to the devices to make sure they were pointing at the right machines. That method would be far, far less efficient the utilizing NAT. > I would use a different three letters for that: DNS > > 4) Conservation of addresses has utility beyond just the sparcity/difficulty in acquiring the resource. It saves time and effort. Simply put, it is far easier to manage 12 public IP addresses then 300. I only need to worry about doing DNS/RDNS/FW Rules/Usage Tracking, etc for those 12. Without NAT I'm doomed to either do it for all 300 or constantly shuffling around the IP addresses assigned to individual NIC's..... either way spells doing alot more work then would be truely neccesary otherwise. > I don't understand this argument at all. If you only have 12 IPs that need external access, then you only have 12 IPs that need DNS/RDNS/FW Rules/Usage Tracking, etc - whether the other 288 are rfc1918 IPv4 addresses or globally unique IPv6 addresses... ??? > > These are just a few of the uses NAT has for me. I don't think I'm alone among Network Admins in saying it's a very usefull tool....regardless of how many IP's we were able to get assigned to us. > > You are used to using it, habits are not all good. with a smile, ~Chris > > > > > > > > > > > > > > > > > > > Christopher Engel > > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From jmaimon at chl.com Wed Oct 28 13:48:33 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 13:48:33 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <395061.64110.qm@web63302.mail.re1.yahoo.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> Message-ID: <4AE883F1.1020108@chl.com> Lee Howard wrote: > >> >> NAT arrived late to IPv4 and it appears to be arriving late to IPv6 as well. >> > > Different issues. I don't see a need for NAT66. But Address Family Translation > (AFT, or NAT46 and NAT64) would be useful. > In the context of depletion, address family translation is what I was primarily referring to. It certainly is not only late, but has already been ejected from the party previously. In the context of end user networks deciding to deploy ipv6 or not, unavailability of NAT66 may very well be a deciding concern, and it very possibly will also arrive late to IPv6. It may also cause NAT46 to gain prominence should enough networks choose to skip out on internal deployment for whatever reason. Also late. > NAPT-PT, being deprecated, is poorly supported. And seems to have been removed from various versions of IOS. > Seems like people are holding > their breath for NAT64, and maybe someday somebody will submit a draft for > NAT46. Which is too late to get gear fielded. And doesn't solve most of the > issues identified in RFC4966. > Even the NAT haters should be able to come together on this. Because the only non deprecated standardized workable alternative is dual stack with rfc1918 and more NAT. And while I think current AFT efforts are being well spent, its from behind the 8-ball. > Is it possible to "reprecrate" something that has been deprecated? Can we > obsolete RFC4966? Anyone have a pointer to the right list for that? > > Lee I suspect that only in the absence of proper user demand to help steer the ship do vendors pay such close attention to RFC document status. I suppose anyone can go join an IETF WG and write a RFC draft. Joe From bill at herrin.us Wed Oct 28 13:54:33 2009 From: bill at herrin.us (William Herrin) Date: Wed, 28 Oct 2009 13:54:33 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> References: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> Message-ID: <3c3e3fca0910281054n6e440f0x8959e993106613f4@mail.gmail.com> On Wed, Oct 28, 2009 at 12:58 PM, Steven E. Petty wrote: > You may want to do a little more research into IPv6. Steven, To what end? Chris E's points 1, 3 and 4 are spot on about the utility of NAT in a way that transcends the differences between IPv4 and IPv6. My only quibble is that I wouldn't describe his point 4 as "address conservation." Address conservation should be a fifth point that only applies to IPv4. I'd describe Chris' point 4 as "address management overhead." On Wed, Oct 28, 2009 at 1:02 PM, Chris Grundemann wrote: > On Wed, Oct 28, 2009 at 10:50, Chris Engel wrote: >> 1) [NAT] acts as an insurance policy against FW misconfigurations. > Create a default rule in your firewall to deny all inbound > non-established connections to all internal devices and then poke And when the misconfiguration is that the default rule is accidentally erased or is overridden for a non-trivial number of cases? The NAT firewall in the common scenario fails closed. You really have to work at getting it to fail open in the inbound direction. The non-NAT firewall tends to fail open so that unintended inbound communication is allowed. >> 3) NAT allows you to abstract your internal infrastructure >> from the external services you present. > I would use a different three letters for that: DNS Then you don't know as much about the DNS as you think you do. The DNS TTL is functionally indefinite (which is to say: ignored) for many common protocols and applications including Firefox and Internet Explorer. Chris E is correct that the use of virtual IPs (VIPs) is necessary for a 100% working abstraction between internal infrastructure and externally presented services. Though NAT is not strictly required to use VIPs, NAT inherently offers extra useful capability here such as splitting each VIP by layer-4 port number and delivering to different back-end machines. >> 4) Simply put, it is far easier to manage 12 public IP addresses then 300. > > I don't understand this argument at all. ?If you only have 12 IPs that > need external access, then you only have 12 IPs that need DNS/RDNS/FW > Rules/Usage Tracking, etc - whether the other 288 are rfc1918 IPv4 > addresses or globally unique IPv6 addresses... ??? Scope. It's about management overhead for equipment whose addresses are in different scopes. Addresses in a private, local scope are much easier to manage than addresses in a global scope. NAT allows addresses in the private scope to access global systems without increasing their management overhead to the level required if they had global scope addresses. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cengel at sponsordirect.com Wed Oct 28 13:59:58 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 28 Oct 2009 13:59:58 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> Message-ID: Chris, "Create a default rule in your firewall to deny all inbound non-established connections to all internal devices and then poke holes just to devices that need to be accessed externally. This still requires an active change to allow access and all internal devices are unaccessible by default." Yes, that is the standard way to configure FW rules, pretty much all FW admins do that now ON TOP OF NAT. However relying on that alone assumes that no-one screws up in the "poking the holes" process which in practice we know is not the case. In fact, one of the most common screw ups is by creating a larger hole then is actually necessary. For example, lets imagine that one of your admins wants to allow OUTGOING FTP from all internal devices.... it's really NOT that hard on many FW's for them (either inadvertently or through inexperience) to open a hole for HTTP to go bi-directionally (INCOMING and OUTGOING) instead. In that case, one screw up and your exposed.... under the NAT scenario you'd still have some protection, as all those internal devices would be non-routable from external sources...thus no one WOULD be able to make HTTP requests of them, even if the FW didn't stop them...since they have no external IP. For the same vulnerability to take place under the NAT scenario.... you have to have TWO separate screw ups.... some-one has to screw up the FW rule THEN they have to screw up the addressability of the internal devices be assigning them an external IP through NAT. That's the whole doctrine behind security these days....MULTI-LAYERED DEFENSE.... We KNOW mistakes and screw ups will happen. What you try to do is minimize the impact of a mistake on any ONE layer....so that a single mistake doesn't topple the entire castle. With the NAT solution...you add an additional layer of defense that must be breached. It must be routable AND it must conform to firewall rules to get through. "If you can do this with 32 bits I do not see how you would be unable to do it with 80 bits." Not that simple.... the idea is that you get the ENTIRE reserved private address space to play with to choose what bits mean what. For instance if you use 10.x.x.x which is pretty common choice for a private network space.... you can subnet the second octet using a /16 internally to control your network segments and then use the third octect to simply indicate the type of host you are assigning (printer,server,workstation, etc). Even with a plethora of address space available under IPV6 I can hardly envision an ISP giving a small/medium business the equivalent of a 10.x.x.x simply so it can conveniently organize it's ip address assignment. "I would use a different three letters for that: DNS" And I would respond with one word PROPAGATION. Even assuming that the service could make use of DNS (and not all can) with Propogation and local DNS caching....you have no control of WHEN an individual client picks the right device to connect to..... A user in Boston might resolve the DNS to the new IP and try to connect AT THE SAME TIME a user in Hong Kong was still resolving the old one and trying to connect to it. That situation is FAR from ideal. With NATing you have PRECISE control over when the switch occurs for EVERYONE. "I don't understand this argument at all. If you only have 12 IPs that need external access, then you only have 12 IPs that need DNS/RDNS/FW Rules/Usage Tracking, etc - whether the other 288 are rfc1918 IPv4 addresses or globally unique IPv6 addresses... ???" No.... if you do that THEN you need to be changing the IP address on the NIC of each device every time you have a change in the device you are using to provide services on one of those 12 IP's....which opens it's own can of worms. Not to mention the fact that since most FW's can handle NAT on a Port by Port basis... you might increase the number of IP's you have to manage externals rather dramaticaly. Christopher Engel -----Original Message----- From: Chris Grundemann [mailto:cgrundemann at gmail.com] Sent: Wednesday, October 28, 2009 12:02 PM To: Chris Engel Cc: owen at delong.com; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern On Wed, Oct 28, 2009 at 10:50, Chris Engel wrote: > Owen, > > Only addressing the portion of your post that deals with NAT.... > > > "First, I'm not really sure why you think NAT is necessary in IPv6. > It really isn't, and, it really isn't a good idea. This isn't FUD, > it's fact. There's really nothing > in NAT that helps anything except address conservation. Many people > mistake > the fact that NAT requires a stateful inspection gateway to function for > security being provided by NAT. The security is not provided by NAT, it > is provided by stateful inspection" > > > NAT is an EXTREMELY usefull tool to Network/System Admins. While it is > certainly possible to function without it...the utility of it should > not be underestimated. Here are examples of it's utility.... > Just for fun; I have not worked on an enterprise network in a while but a lot of this sounds a bit flimsy, even to me... > > 1) It acts as an insurance policy against FW misconfigurations. > Simply put for most businesses/organizations, the majority of devices > on your network you do NOT want reachable by external traffic. While > it is certainly possible to do that with assigning each device a > public address and using FW rules to deny external access.... in the > real world we know that FW misconfigurations are not that > uncommon...particularly when you have complex series of rules at > multiple individuals responsible for the creation and maintenance of > them. NAT allows you to utilize private network addresses for ALL your > internal devices.... which makes them unaccessable to external traffic > BY DEFAULT...and then allows you to assign public IP's to ONLY those > devices which are intended to be externaly accessible. Simply screw > that up (i.e. purposefully taking action to NAT something that > shouldn't be) then it is to make sure that NONE of your (possibly > several hundred) FW rules inadvertantly opens a hole to a device that > it shouldn't. > Create a default rule in your firewall to deny all inbound non-established connections to all internal devices and then poke holes just to devices that need to be accessed externally. This still requires an active change to allow access and all internal devices are unaccessible by default. > > 2) NAT allows Network Admins the flexability to organize thier own > private address space and the assignment of IP's in ways that logicaly > make sense to them. For example, on my own network.... by looking at > the IP address I can instantly tell not only what network segment a > device is on but what TYPE of address it is as well (Server, > Workstation, Printer, etc). I don't believe I would be able to achieve > the same results if I had to limit my assignments to the public > address range that was provided by my ISP (even if they gave me as > many addresses as I wanted). > If you can do this with 32 bits I do not see how you would be unable to do it with 80 bits. > > 3) NAT allows you to abstract your internal infrastructure from the external services you present. This has alot of utility. For example, lets say I provide a service to external users on (external IP) x.x.x.28 If I want to upgrade or change the device that provides that service NAT makes it very easy. I simply bring up the new device on it's own internal IP.... seperate from the internal IP assigned to the existing device.... and when I want to bring the new device into service all I need to do is switch the NATing on the FW and the new device is now instantly providing that service for external users. Nothing needs to change about how the external users access the device.... they may not even be aware that there was a change of device providing the service.... however all my internal references for both devices remain intact and distinct... which can be very important. Without NAT, I would either have to bring the new device up on a new public IP and inform all external > users of how to access it (which may not even be possible) OR I would > have to assign the device the existing devices IP address (and > presumably give the existing device a new one) so that external access > remained the same. However in that case I'd have to CHANGE ALL MY > INTERNAL REFERENCES to the devices to make sure they were pointing at > the right machines. That method would be far, far less efficient the > utilizing NAT. > I would use a different three letters for that: DNS > > 4) Conservation of addresses has utility beyond just the > sparcity/difficulty in acquiring the resource. It saves time and > effort. Simply put, it is far easier to manage 12 public IP addresses > then 300. I only need to worry about doing DNS/RDNS/FW Rules/Usage > Tracking, etc for those 12. Without NAT I'm doomed to either do it for > all 300 or constantly shuffling around the IP addresses assigned to > individual NIC's..... either way spells doing alot more work then > would be truely neccesary otherwise. > I don't understand this argument at all. If you only have 12 IPs that need external access, then you only have 12 IPs that need DNS/RDNS/FW Rules/Usage Tracking, etc - whether the other 288 are rfc1918 IPv4 addresses or globally unique IPv6 addresses... ??? > > These are just a few of the uses NAT has for me. I don't think I'm > alone among Network Admins in saying it's a very usefull > tool....regardless of how many IP's we were able to get assigned to > us. > > You are used to using it, habits are not all good. with a smile, ~Chris > > > > > > > > > > > > > > > > > > > Christopher Engel > > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From jmaimon at chl.com Wed Oct 28 14:05:11 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 14:05:11 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> References: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> Message-ID: <4AE887D7.60406@chl.com> Chris Grundemann wrote: > > You are used to using it, habits are not all good. > > with a smile, > ~Chris Now that is a flimsy objection, even while true. Eradicating NAT should not be about rehabilitating network administrators habits and preferences. It should come by itself, on the day that it offers no positive cost-benefit-ratio to anyone. NAT does allow admins and orgs to organize their networks in the manner they wish under their own control. For all those who want them to do so with public IPv6, unless they all use PI ipv6, that argument is specious - as soon as they change their providers they may have to change their scheme. That means they do not control it. Automatic renumbering. That is not synonymous with network addressing control and design, even were it to work for all renumbering issues under the sun. Which it clearly does not. Do we want to require every organization who wants to control their internal addressing to get ipv6 PI? That could easily amount to hundreds of thousands. I am not quite certain thats really a great way to go. And I am not quite certain that for these organizations anything other than PI space thats exactly utilitarian equivalent to all other PI space fits the bill, with all due respect to SHIM6, HIB, LISP. Furthermore, assuming PI IPv6 removes any technical benefit NAT offers to an organizations internal addressing control, it can require them to do things differently than they are comfortable with. And all because NAT is evil. Why is NAT evil? Because it puts obstacles into end users utilizing protocols in the manner they wish. Is not that what you are doing by advocating denying NAT to these administrators, the end users of these protocols? If they are quite satisfied dealing with the obstacles and limitations NAT brings them with IPv4, why the strenuous objections to allowing them to continue that way with IPv6? So whats the real reason NAT is so hated? Because it also gives protocol designers and people OTHER than the end user or network administrator grief. So in summary, NAT66 detractors want to override network administrators habits and concerns because it makes their world view happier. That seems a bit one sided. Allow network administrators to decide on their own whether or not NAT66 fits their needs. If protocols continued to be designed that cause issues when used with NAT, allow the network administrators the independence to decide whether they want to put up with it or not, whether the cost-benefit-ratio supports their use of NAT or not. Thats what IPv6 should bring to NAT. Choice. Instead it is currently serving the ulterior agenda to remove the choice to use NAT. Let the chips fall where they will. Which will probably happen anyways without all this debate of questionable value. Educating people on the new ways to do things is good, campaigning to not allow old ways of doing things to work is bad. Joe From Wesley.E.George at sprint.com Wed Oct 28 14:21:14 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 28 Oct 2009 13:21:14 -0500 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: <443de7ad0910271036w4e72cda1rd757a389bd182b97@mail.gmail.com> References: <443de7ad0910271036w4e72cda1rd757a389bd182b97@mail.gmail.com> Message-ID: From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann Sent: Tuesday, October 27, 2009 1:37 PM Subject: Re: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs On Tue, Oct 27, 2009 at 09:29, Bill Darte wrote: > Reservations expressed by myself at the time of acceptance was that the > proposal seemed overly complex with thresholds and tiggers that rely > upon 1/ ARIN's ability to accurately assess the remaining free pool in > small, single digit percentages; 2/ the ability of ARIN to react to > changes in status of the free pool based upon these thresholds and > announce the changes to the public; and 3/ most importantly, that all > these thresholds and all the remaining FP might be eliminated with a > single justified large allocation rendering the policy's incremental > process mute. I agree. With regard to this PP and other PP and DP which deal with IPv4-free-pool-run-out / soft-landing strategies: I am beginning to wonder if it isn't better to do away with all of the staggered triggers and accompanying complexity for a much simpler approach. In this case specifically, if the community believes that lowering the minimum allocation may help as we approach and pass IPv4 free-pool exhaustion, why not just lower it now? Forget the triggers all together. [WEG] +1. Can we simply abandon this in favor of proposal 99, or is there something in this proposal besides the sliding trigger that would make it distinct? I've reread both, and I'm not really seeing anything, besides maybe the specific references to small ISPs, which I'm not convinced is necessary to achieve the intended result by simply making it possible to get /24s as end allocations for multihomed networks. Thanks Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From jmaimon at chl.com Wed Oct 28 14:23:21 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 14:23:21 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <4AE88C19.4070200@chl.com> Chris Engel wrote: > For instance if you use 10.x.x.x which is pretty common choice for a private network space.... you can subnet the second octet using a /16 internally to control your network segments and then use the third octect to simply indicate the type of host you are assigning (printer,server,workstation, etc). Even with a plethora of address space available under IPV6 I can hardly envision an ISP giving a small/medium business the equivalent of a 10.x.x.x simply so it can conveniently organize it's ip address assignment. Chris G. is quite correct. But on closer consideration a /48 is roughly the subnetting equivalent of a 10/8, mostly due to the /64 per subnet convention. This isnt all that great an advantage. Furthermore, RFC1918 is a form is non globally routable PI. To properly replace that without NAT conceptually means many hundreds of thousands more PI prefixes. > Christopher Engel From info at arin.net Wed Oct 28 14:39:06 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:39:06 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - October 2009 Message-ID: <4AE88FCA.4090706@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 23 October 2009 and made decisions about several draft policies. The AC moved the following four draft policies to last call. Two are being sent to last call as they were presented at the ARIN XXIV Public Policy Meeting, and two were revised by the AC. Each draft policy will be posted separately to last call. 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries (revised) 2009-5: IPv6 Multiple Discrete Networks 2009-6 (Global Proposal): Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries 2009-7: Open Access To IPv6 (revised) The AC returned ?2009-8: Equitable IPv4 Run-Out? to the AC?s docket for further development. 2009-8 can be petitioned to last call if someone is dissatisfied with the AC?s decision to return it to their docket for more work. 2009-3 and 2009-7 may also be petitioned if someone is dissatisfied with the AC?s decision to send revised text to last call. The deadline to begin a petition is 4 November 2009. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Oct 28 14:39:36 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:39:36 -0400 Subject: [arin-ppml] Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries - Last Call Message-ID: <4AE88FE8.5080103@arin.net> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to send a revised version of the following draft policy to last call: Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. The AC revised the draft. The AC removed sections B.1.d and B.4. B.1. ?d. Legacy address space. IPv4 address space allocated or assigned prior to the creation of the RIR.? B. ?4. Initial Allocation of IPv4 Address Space Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process.? Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 November 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-3 (Global Proposal) Allocation of IPv4 Blocks to Regional Internet Registries Version/Date: 28 October 2009 Policy statement: This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases. A. Phase I: Recovery of IPv4 Address Space Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool. Return of recovered address space (as described above) will continue throughout Phase II. B. Phase II: Allocation of Recovered IPv4 address space by the IANA Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 1. The following definitions apply to this policy: a. Recovered Address Space. Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than 1 year at the time of the report. b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices. c. Aggregated address blocks. Aggregated address blocks are contiguous prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 and 10.0.1.0/24 are two contiguous prefixes that can be combined to form an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two contiguous prefixes that cannot be combined on a natural bit boundary to form an aggregated block. 2. Allocation of IPv4 Address Space a. For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year. b. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. The minimum 'IPv4 allocation unit' size will be a /24. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph B.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 3. IPv4 Address Space Allocation Criteria A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period. 5. Reporting a. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR. b. All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR. c. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated. d) The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. Rationale: With the depletion of the IANA free pool of IPv4 address space, the current policy regarding the allocation of IPv4 address space to the RIRs will become obsolete. The RIRs may already, according to their individual policies and procedures, recover IPv4 address blocks of any size. However, current policy requires IANA to make allocations to the RIRs in blocks of /8. If any blocks smaller than /8 are returned to the IANA, current policy does not provide a way to allocate that space. This policy provides a mechanism for the RIRs to return recovered IPv4 address space to the IANA and provides the IANA the policy by which it can allocate it back to the RIRs on a needs basis. This policy creates a new global pool of IPv4 address space that can be allocated where it is needed on a global basis without a transfer of address space between the RIRs. The original version of Global Policy Proposal for the Allocation of IPv4 Blocks to Regional Internet Registries (ARIN policy 2009-3) was proposed in the ARIN region, discussed on the Public Policy Mailing List (PPML), and by the Advisory Council (AC). A number of concerns were expressed, mostly related to the mandatory requirement to return reclaimed space to IANA. In an attempt to alleviate some of these concerns, the AC modified 2009-3 to make the return of non-legacy space to IANA optional. This version of the proposal was discussed at the April 2009 ARIN XXIII meeting in San Antonio. During that discussion, it became clear that there was not a consensus in the ARIN region for either the original proposal, or the modified legacy-only version. As a result of subsequent discussions of the global policy at the spring AfriNIC and LACNIC meetings, it became clear that one of the reasons 2009-3 is such a difficult policy to get consensus on is that the original policy, as proposed, is a global policy proposal that has some local policy aspects, namely that requires each RIR to return reclaimed space. Ideally, global policies are supposed to maintain a clean separation from local policies: global policy is supposed to only govern the relationship between the IANA and the RIRs, and local policy defines what the RIR can do internally. As a side effect of the blurring of global and local policy in the current revision of 2009-3, ARIN (and most of the other RIRs) have been having an interesting debate about exactly which space should be covered by the policy. To sidestep this issue, the changes made to the proposal are in the 2nd paragraph of section A: "Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool." The original version read: "Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool." The distinction is that under the revised version of 2009-3, recovered space is returned after it is designated for return under local policies and strategies. The original text dictated the terms of what must be returned (everything /24 or larger) as part of the global policy. Since global policy is supposed to only govern the relationship between the IANA and the RIRs, and local policy defines what the RIR can do internally. This change brings the proposal more in line with that definition of a global policy, and should address a number of other concerns as well. As this is a global policy, it will need to be reconciled with the version passed in the other RIRs. As this appears to be a substantive change, that most likely means the other RIRs will need to go back and pass the modified version as well. XXXXXXXXXXXXXXXXXXXXXXXXXXXXX Below are 3 exemplar scenarios of the execution of this policy after Phase II is in force. These are not part of the rationale but are provided for illustrative purposes. Example 1: On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 3,276 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /21 (2,048 addresses). 3. Each RIR can request and receive a single allocation unit equivalent to a /21 worth of addresses. 4. While IANA may not be able to allocate a contiguous /21 and can allocate noncontiguous smaller blocks equivalent to a /21 worth of addresses. Example 2: On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 409 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /24 (256 addresses). 3. Each RIR can request and receive a single allocation unit equivalent to a /24 worth of addresses. 4. As the minimum size of address space returned to IANA is /24, IANA can allocate a contiguous range of addresses that amount to a /24. Example 3: On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 204 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /25 (128 addresses). 3. A /25 is smaller than the minimum permissible allocation size under this policy. A /25 is smaller than the minimum permissible allocation size under this policy. Therefore, IANA is unable to make an allocation until more address space is received. XXXXXXXXXXXXXXXXXXXXXXXXXXXXX Timetable for implementation: This policy is to be implemented immediately upon ratification by the ICANN Board of Directors according to the global policy process described in the ASO MoU. From info at arin.net Wed Oct 28 14:39:54 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:39:54 -0400 Subject: [arin-ppml] Draft Policy 2009-5: IPv6 Multiple Discrete Networks - Last Call Message-ID: <4AE88FFA.8020100@arin.net> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to send the following draft policy to last call: Draft Policy 2009-5: IPv6 Multiple Discrete Networks The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 November 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-5 IPv6 Multiple Discrete Networks Version/Date: 21 July 2009 Policy statement: Organizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: The organization shall be a single entity and not a consortium of smaller independent entities. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: Regulatory restrictions for data transmission, Geographic distance and diversity between networks, Autonomous multihomed discrete networks. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. The organization should notify ARIN at the time of the request their desire to apply this policy to their account. Requests for additional space: Organization must specify on the application which discreet network(s) the request applies to Each network will be judged against the existing utilization criteria specified in 6.5.2 as if it were a separate organization, rather than collectively as would be done for requests outside of this policy. Rationale: This proposed policy is suggested as NRPM 6.11. The policy is intended to provide parity between current IPv4 policy and allow discrete network operators to obtain IPv6 space. Timetable for implementation: Immediately From info at arin.net Wed Oct 28 14:40:11 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:40:11 -0400 Subject: [arin-ppml] Draft Policy 2009-6: IANA Policy for Allocation of ASN Blocks to RIRs - Last Call Message-ID: <4AE8900B.1080404@arin.net> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to send the following draft policy to last call: Draft Policy 2009-6: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 November 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-6 Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries Version/Date: 31 August 2009 Policy statement: Modification of NRPM section 10.3 extending the deadline for an undifferentiated ASN pool by 1 year to read: 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 16-bit and 32-bit only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs, and will operate ASN allocations from an undifferentiated 32-bit ASN allocation pool. Rationale: a. Arguments supporting the proposal Due to operational issues external to the IANA/RIR policy process, 32-bit only ASNs are not being issued by the RIRs at the anticipated rate. As it stands, RIRs will likely not be able to justify a new block of ASNs from the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in the RIR's pool. This leaves available, essential 16-bit ASNs stranded in the IANA free pool. This proposal seeks to remedy the potential problem by extending the deadline for differentiation by one year. With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage. The subject was raised during RIPE 58 and a presentation was made: http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf The feedback in this session suggested that a global policy proposal should be developed and should be discussed. b. Arguments opposing the proposal Some may think that extending the previously set timeline can be perceived as some discouragement for the deployment of 32-bit ASNs. One counter argument to this is that RIRs and Internet community have some other mechanisms and activities to raise awareness for 32-bit ASN pool (via public presentations and trainings). These activities will continue while 16-bit ASN blocks are still allocated to RIRs by the IANA as they are available and they are needed. Timetable for implementation: Immediately upon ratification by ICANN Board From info at arin.net Wed Oct 28 14:40:52 2009 From: info at arin.net (Member Services) Date: Wed, 28 Oct 2009 14:40:52 -0400 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call Message-ID: <4AE89034.8040301@arin.net> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to send a revised version of the following draft policy to last call: Draft Policy 2009-7: Open Access To IPv6 The AC met in accordance with the ARIN Policy Development Process which requires the AC to meet within 30 days of the conclusion of the Public Policy Meeting to make decisions about the draft policies that had been presented. The AC revised the draft. The draft policy is now limited to removing the IPv6 routing requirement from current policy. It does not change the initial IPv6 allocation criteria. However, the AC stated they intend to continue to work on that issue. Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 November 2009. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-7 Open Access To IPv6 Version/Date: 28 October 2009 Policy statement: Remove ?by advertising that connectivity through its single aggregated address allocation? from article 3 of section 6.5.1.1 Rationale: Removing the requirement for a single aggregate announcement benefits the NRPM itself, as it has been decided by the community that it should not contain routing advice. Timetable for implementation: immediately upon BoT ratification From scottleibrand at gmail.com Wed Oct 28 14:56:25 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 28 Oct 2009 11:56:25 -0700 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: References: <443de7ad0910271036w4e72cda1rd757a389bd182b97@mail.gmail.com> Message-ID: <4AE893D9.8000206@gmail.com> George, Wes E [NTK] wrote: > > +1. Can we simply abandon this in favor of proposal 99, or is there something in this proposal besides the sliding trigger that would make it distinct? I've reread both, and I'm not really seeing anything, besides maybe the specific references to small ISPs, which I'm not convinced is necessary to achieve the intended result by simply making it possible to get /24s as end allocations for multihomed networks. When the AC decided to put both proposal 98 and 99 on our docket, my recollection is that we intended to merge the two into a single draft policy to present in Toronto. My own opinion is that the simpler policy (99) is a good starting framework, but we did feel that there were some aspects of 98 that we would probably want to include as well. If would be quite useful if everyone could take a look at the proposals with an eye toward providing the AC feedback on which aspects of the proposal(s) would be most useful and beneficial to include in a merged version. Thanks, Scott From Lee at Dilkie.com Wed Oct 28 15:28:48 2009 From: Lee at Dilkie.com (Lee Dilkie) Date: Wed, 28 Oct 2009 15:28:48 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE887D7.60406@chl.com> References: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> <4AE887D7.60406@chl.com> Message-ID: <4AE89B70.7060304@Dilkie.com> Joe Maimon wrote: > > Is not that what you are doing by advocating denying NAT to these > administrators, the end users of these protocols? If they are quite > satisfied dealing with the obstacles and limitations NAT brings them > with IPv4, why the strenuous objections to allowing them to continue > that way with IPv6? > > So whats the real reason NAT is so hated? > > Because it also gives protocol designers and people OTHER than the end > user or network administrator grief. > > So in summary, NAT66 detractors want to override network > administrators habits and concerns because it makes their world view > happier. > > That seems a bit one sided. > > Indeed. Except that NAT breaks lots of protocols by breaking a fundamental network requirement. Universal addressing. And how many billions of dollars are wasted in re-designing protocols to work with NAT because, despite what the net admin wants, the actual users require working applications and protocols. What NAT brings to the table is, if I may use a telephony analogy, a return to the time before direct dial long distance calling. To the time of calling the operator to place a call. For brief time in the early 90's, pre NAT, we early adoptors all had real addresses at our desks and clean protocols... Oh yeah, we also have firewalls too.. -lee From Lee at Dilkie.com Wed Oct 28 15:34:58 2009 From: Lee at Dilkie.com (Lee Dilkie) Date: Wed, 28 Oct 2009 15:34:58 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <395061.64110.qm@web63302.mail.re1.yahoo.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> Message-ID: <4AE89CE2.3020907@Dilkie.com> My comment on the subject, repeated from last year. The only proper way forward is dual stack and the faster we achieve some magic number (80%?) of dual stack penetration, the faster we can roll out v6 only. One good way for organizations like ARIN to help with dual stack is to simply give out v6 addresses, free, to all current v4 address holders and encourage them to roll it out. Or add a stick like "here's your free v6, you have x years to roll out v6 to your customers or you loose your v4"... not that I favour the stick, just tossing it out. {flame proof underwear on} -lee From ptimmins at clearrate.com Wed Oct 28 15:25:19 2009 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Wed, 28 Oct 2009 15:25:19 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE887D7.60406@chl.com> References: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> <4AE887D7.60406@chl.com> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Maimon Sent: Wednesday, October 28, 2009 2:05 PM To: Chris Grundemann Cc: Chris Engel; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > Chris Grundemann wrote: > > > > > You are used to using it, habits are not all good. > > > > with a smile, > > ~Chris > > Now that is a flimsy objection, even while true. Eradicating NAT should > not be about rehabilitating network administrators habits and preferences. > > It should come by itself, on the day that it offers no positive > cost-benefit-ratio to anyone. Taking this to its logical conclusion, it's not necessary for community consensus to implement NAT66. If people demand it, and equipment vendors want to implement it, they will, and then will standardize it after the fact, much like many other current standards have been done. The fact that no such standard exists and no platform I'm aware of implements NAT66 is pretty telling in and of itself. -Paul From sethm at rollernet.us Wed Oct 28 15:44:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 28 Oct 2009 12:44:47 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE89CE2.3020907@Dilkie.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> Message-ID: <4AE89F2F.9040700@rollernet.us> Lee Dilkie wrote: > My comment on the subject, repeated from last year. > > The only proper way forward is dual stack and the faster we achieve some > magic number (80%?) of dual stack penetration, the faster we can roll > out v6 only. > > One good way for organizations like ARIN to help with dual stack is to > simply give out v6 addresses, free, to all current v4 address holders > and encourage them to roll it out. Or add a stick like "here's your free > v6, you have x years to roll out v6 to your customers or you loose your > v4"... not that I favour the stick, just tossing it out. > It won't help until IPv6 has routability parity to that of IPv4 among the big players. ~Seth From jmaimon at chl.com Wed Oct 28 15:50:39 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 15:50:39 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> <4AE887D7.60406@chl.com> Message-ID: <4AE8A08F.7000708@chl.com> Paul G. Timmins wrote: > > Taking this to its logical conclusion, it's not necessary for community > consensus to implement NAT66. If people demand it, and equipment vendors > want to implement it, they will, and then will standardize it after the > fact, much like many other current standards have been done. > > The fact that no such standard exists and no platform I'm aware of > implements NAT66 is pretty telling in and of itself. > > -Paul > > > What is proper is to stop demanding that everyone not want to use it. Furthermore, at this similar state in IPv4 global deployment, NAT44 wasnt really available either, and instead people were using other horrible workarounds. From ptimmins at clearrate.com Wed Oct 28 15:57:45 2009 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Wed, 28 Oct 2009 15:57:45 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE8A08F.7000708@chl.com> References: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> <4AE887D7.60406@chl.com> <4AE8A08F.7000708@chl.com> Message-ID: -----Original Message----- From: Joe Maimon [mailto:jmaimon at chl.com] Sent: Wednesday, October 28, 2009 3:51 PM To: Paul G. Timmins Cc: Chris Grundemann; Chris Engel; arin-ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > Paul G. Timmins wrote: > > > > Taking this to its logical conclusion, it's not necessary for community > > consensus to implement NAT66. If people demand it, and equipment vendors > > want to implement it, they will, and then will standardize it after the > > fact, much like many other current standards have been done. > > > > The fact that no such standard exists and no platform I'm aware of > > implements NAT66 is pretty telling in and of itself. > > > > -Paul > > > > > > > What is proper is to stop demanding that everyone not want to use it. I demand people stop using ISL and EIGRP and they seem to proliferate anyway. Features people want seem to trump even vocal opposition. If you want it, make vendor C and vendor J implement it. They won't care what we say if you're waving cash under their nose. > Furthermore, at this similar state in IPv4 global deployment, NAT44 > wasnt really available either, and instead people were using other > horrible workarounds. Yea, like public IPs and stateful firewalls. Possibly even floating IPs that get bound to whatever machine is doing things. Awful stuff! I remember those days and wonder how we ever survived. Amusingly a reading of RFC-1631 shows even its designers had the misgivings about it we're articulating now. -Paul From cengel at sponsordirect.com Wed Oct 28 16:06:12 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 28 Oct 2009 16:06:12 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: Message-ID: Paul, Respectfully, that is because for the vast majority of Network/System Admins IPv6 and the details of it's implementation are barely a blip on the radar screen....if that. I can attest that NAT is a tool which see's extensive use among said Admins...and NOT simply because one cannot obtain enough public IP addresses. As I believe I have illustrated...it has a variety of useful functionality for us. I can assure you that if something in IPv6 does not offer the equivalent functionality to that which NAT currently provides for IPV4 and in a similarly convenient manner.....you are going to hear a VERY loud wailing and gnashing of teeth from this population. I'm sure that is a sound that will resonate with equipment vendors. However without some confidence that some sort of NAT66 solution will be provided (or nearly identical functionality can be achieved).....your going to see alot of resistance in this population to IPv6 adoption. If you want people to actually be SUPPORTIVE of that adoption rather then RESISTANT then you have to provide some assurance that the tools they are used to working with to solve real problems will be available in some form.....or at the very least a substitute that achieves equivalent functionality and is easily translatable. "Taking this to its logical conclusion, it's not necessary for community consensus to implement NAT66. If people demand it, and equipment vendors want to implement it, they will, and then will standardize it after the fact, much like many other current standards have been done. The fact that no such standard exists and no platform I'm aware of implements NAT66 is pretty telling in and of itself. -Paul" From cengel at sponsordirect.com Wed Oct 28 16:31:33 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 28 Oct 2009 16:31:33 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE89B70.7060304@Dilkie.com> Message-ID: "Except that NAT breaks lots of protocols by breaking a fundamental network requirement. Universal addressing. And how many billions of dollars are wasted in re-designing protocols to work with NAT because, despite what the net admin wants, the actual users require working applications and protocols. What NAT brings to the table is, if I may use a telephony analogy, a return to the time before direct dial long distance calling. To the time of calling the operator to place a call. For brief time in the early 90's, pre NAT, we early adoptors all had real addresses at our desks and clean protocols... Oh yeah, we also have firewalls too.. -lee" Respectfully, The "actual end users" also want to surf adult movie sites, click on every link that says Download Me and publish thier network passwords on thier facebook page so that they don't forget them. They are perfectly welcome to do that..... ON THIER OWN DIME...and on thier own home networks. However organizations pay Network Admins specificaly to prevent the "actual users" from doing all these sorts of things when using THE ORGANIZATIONS NETWORK. Admins are responsible for assuring that have control over are healthy and functional and support ONLY those applications and protocols that organization WANTS to work....and NOTHING ELSE. NAT is a tool that has some very important functionality for doing just that.....among other things. There are VERY GOOD reasons to want to abstract an networks internal structure from it's external presence. There are very good reasons to have BOUNDRIES and INTERMEDIARIES between end users and the outside world....or vice versa. "Universal addressing" ia actualy...in practice... very much NOT a Universal good. From jmaimon at chl.com Wed Oct 28 16:29:33 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 16:29:33 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> <4AE887D7.60406@chl.com> <4AE8A08F.7000708@chl.com> Message-ID: <4AE8A9AD.4060408@chl.com> Paul G. Timmins wrote: > Yea, like public IPs and stateful firewalls. Possibly even floating IPs > that get bound to whatever machine is doing things. Awful stuff! I > remember those days and wonder how we ever survived. > Proxies. From jmaimon at chl.com Wed Oct 28 16:32:32 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 16:32:32 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE89CE2.3020907@Dilkie.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> Message-ID: <4AE8AA60.6090001@chl.com> Lee Dilkie wrote: > My comment on the subject, repeated from last year. > > The only proper way forward is dual stack and the faster we achieve some > magic number (80%?) of dual stack penetration, the faster we can roll > out v6 only. > > Its not the proper way forward. It is the theoretically ideal way forward (albeit at 100%). It is also the way forward that hasnt gotten enough momentum yet and is uncertain that it will in time, unaided. Waiting for 80% penetration before depletion is very likely overly optimistic, probably because real uptake of IPv6 depends on depletion. Even then, it is hardly likely it will occur in any meaningfully quick fashion. Here is the oft-quoted chicken and egg problem in its expanded form. Why would any existing user of IPv4 need to add dual stack to IPv6? To access the IPv6 only users. Why would anybody ever be publicly accessible only via IPv6? Because they cant get any IPv4. Who is going to put up with that? Only people who dont mind waiting for large percentages of the internet to decide it is worth getting IPv6 to talk to them. What will the rest do? Beg borrow and steal to get IPv4. Rinse, Repeat. The waiting for dual stack to reach critical mass plan is proceeding too slowly, calling into doubt whether it is smart to continue waiting on it. Due to address shortage, continuing with waiting for dual stacking to reach critical is going to require more and more NAT, and more and more wrangling over past inefficiencies. Which is bad, even as it may become more and more necessary. Furthermore, as a plan formula it sucks. We have to invest 80% of the effort to get the 20% payoff? The 80 20 rule is supposed to work in the other way. If the plan was to wait until 20% of the internet was dual stack and then the rest would "automatically" follow and cause IPv6 only to be practical, now thats more achievable, but still unlikely. > One good way for organizations like ARIN to help with dual stack is to > simply give out v6 addresses, free, to all current v4 address holders > Which they do for the most part. To date the only significant complaints I have seen have been regarding those who arent IPv4 holders or with the single prefix policy. > and encourage them to roll it out. Or add a stick like "here's your free > v6, you have x years to roll out v6 to your customers or you loose your > v4"... not that I favour the stick, just tossing it out. > ARIN is not in the position to be waving sticks at people for things like this, and I think they know that. And where is the carrot in your plan? > {flame proof underwear on} > > -lee > > > Joe From RMoore at fnsky.com Wed Oct 28 16:37:31 2009 From: RMoore at fnsky.com (Rodgers Moore) Date: Wed, 28 Oct 2009 16:37:31 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> Only because I can chime in... Any system that uses IPv6 will not be PCI-DSS compliant. PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies-for example, port address translation (PAT)." It matters not how much B.S. this is, only that being non-compliant (as per the technically challenged auditor determines) allows Visa, MasterCard, Discover, and Amex to fine the *&^$# out of you and/or revoke your organization's ability to transact credit cards. Sorry, I couldn't help but bring a new twist to the conversation. Or, uh, throw gas on the fire. Rodgers Moore, CCIE# 8153 CSO Fortress Network Security 2500 Technology Dr Louisville KY 40299 -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Engel Sent: Wednesday, October 28, 2009 4:06 PM To: 'Paul G. Timmins'; Joe Maimon; Chris Grundemann Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern Paul, Respectfully, that is because for the vast majority of Network/System Admins IPv6 and the details of it's implementation are barely a blip on the radar screen....if that. I can attest that NAT is a tool which see's extensive use among said Admins...and NOT simply because one cannot obtain enough public IP addresses. As I believe I have illustrated...it has a variety of useful functionality for us. I can assure you that if something in IPv6 does not offer the equivalent functionality to that which NAT currently provides for IPV4 and in a similarly convenient manner.....you are going to hear a VERY loud wailing and gnashing of teeth from this population. I'm sure that is a sound that will resonate with equipment vendors. However without some confidence that some sort of NAT66 solution will be provided (or nearly identical functionality can be achieved).....your going to see alot of resistance in this population to IPv6 adoption. If you want people to actually be SUPPORTIVE of that adoption rather then RESISTANT then you have to provide some assurance that the tools they are used to working with to solve real problems will be available in some form.....or at the very least a substitute that achieves equivalent functionality and is easily translatable. "Taking this to its logical conclusion, it's not necessary for community consensus to implement NAT66. If people demand it, and equipment vendors want to implement it, they will, and then will standardize it after the fact, much like many other current standards have been done. The fact that no such standard exists and no platform I'm aware of implements NAT66 is pretty telling in and of itself. -Paul" _______________________________________________ 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 bicknell at ufp.org Wed Oct 28 16:53:56 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Oct 2009 13:53:56 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> References: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> Message-ID: <20091028205356.GA51268@ussenterprise.ufp.org> In a message written on Wed, Oct 28, 2009 at 04:37:31PM -0400, Rodgers Moore wrote: > PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to > prevent internal addresses from being translated and revealed on > the Internet, using RFC 1918 address space. Use network address > translation (NAT) technologies-for example, port address translation > (PAT)." If I take away all the IPv4 specific blather, I get: "Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet." It would seem to me that IPv6 Privacy Extensions (prehaps better known as "temporary addresses") would fit the bill. http://www.ietf.org/rfc/rfc3041.txt Indeed, I've used this on my OSX and FreeBSD boxes. Outbound connections make use of randomly generated IPv6 host identifiers, and with careful configuration none of your internal addresses (e.g. what SSH is listening on) are ever exposed. I think it's a credible argument that the 2^64 search space in IPv6 is at least as secure as the 2^32 (source+dest 16 bit port fields, as adjusted by a NAT) in IPv4, and it's probably more secure. Lots of standards, BCP's and other documents will have to be updated to include IPv6. To suggest the only way to do that is to 100% mirror IPv4 is foolish. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From scottleibrand at gmail.com Wed Oct 28 16:56:16 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 28 Oct 2009 13:56:16 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> References: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> Message-ID: <4AE8AFF0.1010605@gmail.com> Does anyone know what the mechanism is for getting the next version of PCI-DSS updated to translate that requirement into something that covers IPv6? Their concern is reasonable, and we should probably be engaging in a conversation with the PCI Security Standards Council and working with them to address those concerns as networks move to IPv6. Unless someone here is involved in that process, it sounds like an opportunity for ARIN to do some additional outreach (if they're not already)... -Scott Rodgers Moore wrote: > Only because I can chime in... Any system that uses IPv6 will not be PCI-DSS compliant. > > PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies-for example, port address translation (PAT)." > > It matters not how much B.S. this is, only that being non-compliant (as per the technically challenged auditor determines) allows Visa, MasterCard, Discover, and Amex to fine the *&^$# out of you and/or revoke your organization's ability to transact credit cards. > > Sorry, I couldn't help but bring a new twist to the conversation. Or, uh, throw gas on the fire. > > Rodgers Moore, CCIE# 8153 > CSO > Fortress Network Security > 2500 Technology Dr > Louisville KY 40299 > > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Engel > Sent: Wednesday, October 28, 2009 4:06 PM > To: 'Paul G. Timmins'; Joe Maimon; Chris Grundemann > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > Paul, > > > Respectfully, that is because for the vast majority of Network/System Admins IPv6 and the details of it's implementation are barely a blip on the radar screen....if that. > > I can attest that NAT is a tool which see's extensive use among said Admins...and NOT simply because one cannot obtain enough public IP addresses. As I believe I have illustrated...it has a variety of useful functionality for us. I can assure you that if something in IPv6 does not offer the equivalent functionality to that which NAT currently provides for IPV4 and in a similarly convenient manner.....you are going to hear a VERY loud wailing and gnashing of teeth from this population. > > I'm sure that is a sound that will resonate with equipment vendors. However without some confidence that some sort of NAT66 solution will be provided (or nearly identical functionality can be achieved).....your going to see alot of resistance in this population to IPv6 adoption. > > If you want people to actually be SUPPORTIVE of that adoption rather then RESISTANT then you have to provide some assurance that the tools they are used to working with to solve real problems will be available in some form.....or at the very least a substitute that achieves equivalent functionality and is easily translatable. > > > > > > > "Taking this to its logical conclusion, it's not necessary for community consensus to implement NAT66. If people demand it, and equipment vendors want to implement it, they will, and then will standardize it after the fact, much like many other current standards have been done. > > The fact that no such standard exists and no platform I'm aware of implements NAT66 is pretty telling in and of itself. > > -Paul" > _______________________________________________ > 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. > _______________________________________________ > 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 mksmith at adhost.com Wed Oct 28 17:02:14 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 28 Oct 2009 14:02:14 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE8AFF0.1010605@gmail.com> References: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> <4AE8AFF0.1010605@gmail.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031606EA6440@ad-exh01.adhost.lan> It appears that you have to become a participating organization for $2500.00 per year. Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Wednesday, October 28, 2009 1:56 PM > To: Rodgers Moore > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > Does anyone know what the mechanism is for getting the next version of > PCI-DSS updated to translate that requirement into something that > covers > IPv6? Their concern is reasonable, and we should probably be engaging > in a conversation with the PCI Security Standards Council and working > with them to address those concerns as networks move to IPv6. > > Unless someone here is involved in that process, it sounds like an > opportunity for ARIN to do some additional outreach (if they're not > already)... > > -Scott > > Rodgers Moore wrote: > > Only because I can chime in... Any system that uses IPv6 will not be > PCI-DSS compliant. > > > > PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to > prevent internal addresses from being translated and revealed on the > Internet, using RFC 1918 address space. Use network address translation > (NAT) technologies-for example, port address translation (PAT)." > > > > It matters not how much B.S. this is, only that being non-compliant > (as per the technically challenged auditor determines) allows Visa, > MasterCard, Discover, and Amex to fine the *&^$# out of you and/or > revoke your organization's ability to transact credit cards. > > > > Sorry, I couldn't help but bring a new twist to the conversation. > Or, uh, throw gas on the fire. > > > > Rodgers Moore, CCIE# 8153 > > CSO > > Fortress Network Security > > 2500 Technology Dr > > Louisville KY 40299 > > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Chris Engel > > Sent: Wednesday, October 28, 2009 4:06 PM > > To: 'Paul G. Timmins'; Joe Maimon; Chris Grundemann > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > > > Paul, > > > > > > Respectfully, that is because for the vast majority of Network/System > Admins IPv6 and the details of it's implementation are barely a blip on > the radar screen....if that. > > > > I can attest that NAT is a tool which see's extensive use among said > Admins...and NOT simply because one cannot obtain enough public IP > addresses. As I believe I have illustrated...it has a variety of useful > functionality for us. I can assure you that if something in IPv6 does > not offer the equivalent functionality to that which NAT currently > provides for IPV4 and in a similarly convenient manner.....you are > going to hear a VERY loud wailing and gnashing of teeth from this > population. > > > > I'm sure that is a sound that will resonate with equipment vendors. > However without some confidence that some sort of NAT66 solution will > be provided (or nearly identical functionality can be > achieved).....your going to see alot of resistance in this population > to IPv6 adoption. > > > > If you want people to actually be SUPPORTIVE of that adoption rather > then RESISTANT then you have to provide some assurance that the tools > they are used to working with to solve real problems will be available > in some form.....or at the very least a substitute that achieves > equivalent functionality and is easily translatable. > > > > > > > > > > > > > > "Taking this to its logical conclusion, it's not necessary for > community consensus to implement NAT66. If people demand it, and > equipment vendors want to implement it, they will, and then will > standardize it after the fact, much like many other current standards > have been done. > > > > The fact that no such standard exists and no platform I'm aware of > implements NAT66 is pretty telling in and of itself. > > > > -Paul" > > _______________________________________________ > > 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. > > _______________________________________________ > > 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. > > > _______________________________________________ > 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 jmaimon at chl.com Wed Oct 28 17:11:41 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 17:11:41 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <20091028205356.GA51268@ussenterprise.ufp.org> References: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> <20091028205356.GA51268@ussenterprise.ufp.org> Message-ID: <4AE8B38D.2020408@chl.com> Leo Bicknell wrote: > In a message written on Wed, Oct 28, 2009 at 04:37:31PM -0400, Rodgers Moore wrote: >> PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to >> prevent internal addresses from being translated and revealed on >> the Internet, using RFC 1918 address space. Use network address >> translation (NAT) technologies-for example, port address translation >> (PAT)." > > If I take away all the IPv4 specific blather, I get: The only reason it is IPv4 specific is because it happens not to be available YET in ipv6. > > Indeed, I've used this on my OSX and FreeBSD boxes. Outbound > connections make use of randomly generated IPv6 host identifiers, > and with careful configuration none of your internal addresses (e.g. > what SSH is listening on) are ever exposed. So do you think PCI compliance will be updated to include verifying that all the public IPv6 addresses used to source traffic from the thousands of lan machines are not listening on any sockets on those address? > I think it's a credible > argument that the 2^64 search space in IPv6 is at least as secure > as the 2^32 (source+dest 16 bit port fields, as adjusted by a NAT) > in IPv4, and it's probably more secure. I think its possible the intent of the standard language is not nearly as narrowly technical as you are reading it. > > Lots of standards, BCP's and other documents will have to be updated > to include IPv6. To suggest the only way to do that is to 100% > mirror IPv4 is foolish. And it is possible they will be updated to require features that currently are not widely available in IPv6 or to otherwise explicitly disallow it. It is not foolish to suggest that providing all abilities in IPv6 that are widely used in IPv4 lowers the barrier to adoption. Joe From cgrundemann at gmail.com Wed Oct 28 17:50:09 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 28 Oct 2009 15:50:09 -0600 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE8AA60.6090001@chl.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> Message-ID: <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> On Wed, Oct 28, 2009 at 14:32, Joe Maimon wrote: > > > Lee Dilkie wrote: >> >> My comment on the subject, repeated from last year. >> >> The only proper way forward is dual stack and the faster we achieve some >> magic number (80%?) of dual stack penetration, the faster we can roll >> out v6 only. >> >> > > Its not the proper way forward. It is the theoretically ideal way forward > (albeit at 100%). It is also the way forward that hasnt gotten enough > momentum yet and is uncertain that it will in time, unaided. Waiting for 80% > penetration before depletion is very likely overly optimistic, probably > because real uptake of IPv6 depends on depletion. Even then, it is hardly > likely it will occur in any meaningfully quick fashion. > > Here is the oft-quoted chicken and egg problem in its expanded form. > > Why would any existing user of IPv4 need to add dual stack to IPv6? > > To access the IPv6 only users. > > Why would anybody ever be publicly accessible only via IPv6? > > Because they cant get any IPv4. > > Who is going to put up with that? > > Only people who dont mind waiting for large percentages of the internet to > decide it is worth getting IPv6 to talk to them. > > What will the rest do? > > Beg borrow and steal to get IPv4. > > Rinse, Repeat. > > The ?waiting for dual stack to reach critical mass plan is proceeding too > slowly, calling into doubt whether it is smart to continue waiting on it. > > Due to address shortage, continuing with waiting for dual stacking to reach > critical is going to require more and more NAT, and more and more wrangling > over past inefficiencies. Which is bad, even as it may become more and more > necessary. > > Furthermore, as a plan formula it sucks. We have to invest 80% of the effort > to get the 20% payoff? The 80 20 rule is supposed to work in the other way. > > If the plan was to wait until 20% of the internet was dual stack and then > the rest would "automatically" follow and cause IPv6 only to be practical, > now thats more achievable, but still unlikely. I don't think it depends on a % of everyone but rather on the right groups leading. If a significant amount of content (facebook, youtube, itunes, major news sites and what have you) was dual-stacked, that could make at least residential / home-use IPv6 only service practical for at least some users, especially if it was offered at a reduced cost. That opens the door and starts the ball rolling. I am not going to say that we will (or even can) reach 100% IPv6 penetration before we run out of available IPv4 in that manner but I am not positive that it is out of reach yet either... ~Chris > >> One good way for organizations like ARIN to help with dual stack is to >> simply give out v6 addresses, free, to all current v4 address holders >> > > Which they do for the most part. To date the only significant complaints I > have seen have been regarding those who arent IPv4 holders or with the > single prefix policy. >> >> and encourage them to roll it out. Or add a stick like "here's your free >> v6, you have x years to roll out v6 to your customers or you loose your >> v4"... not that I favour the stick, just tossing it out. >> > > ARIN is not in the position to be waving sticks at people for things like > this, and I think they know that. > > And where is the carrot in your plan? >> >> {flame proof underwear on} >> >> -lee >> >> >> > > Joe > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From earl at baugh.org Wed Oct 28 18:12:58 2009 From: earl at baugh.org (Earl Baugh) Date: Wed, 28 Oct 2009 18:12:58 -0400 Subject: [arin-ppml] v4 to v6 obstacles Message-ID: Joe Maimon wrote: >>Lee Dilkie wrote: >> >> One good way for organizations like ARIN to help with dual stack is to >> simply give out v6 addresses, free, to all current v4 address holders >> >Which they do for the most part. To date the only significant complaints >I have seen have been regarding those who arent IPv4 holders or with the >single prefix policy. As a "small" legacy IPv4 holder, I can attest that one of the main reasons I haven't rolled out IPv6 is mostly because I wasn't offered an IPv6 equivalent to the IPv4 I hold. I know of other similar small legacy IPv4 holders who are in the exact came boat. I did see where I could pay $$ to register and then continuously pay $$ for it each year... But I'll be fairly honest, what would be in it for me? Yes, it's a self-centered attitude, I acknowledge that, however businesses and organizations on the whole need some reason, aside from the "we'd all like you to", or "this is the latest technology, trust me you HAVE to have it". For a lot of businesses and organizations neither of those reasons will get them to change. If what I have meets my needs, and there aren't any IPv6 features or services that I "have-to-have" along with the additional cost to even get started, what's the motivation? (even IF it is free, I still have to incur additional time and labor to manage the dual stacks, but I'd be at least willing and able to at least "start" moving if I had one in hand....) For example, at least to some degree, Windows XP to Windows Vista adoption numbers support this type of thought process. What's going to "force" people to move from XP is Microsoft stopping support for it, (that's what happened with Win98) and/or there being some device or application that breaks the old, or requires the newer OS (USB devices for Windows 98 to Windows XP for example). However, in the IPv4 case, you're not going to get "support dropped" for it, and to date there isn't any IPv6 "killer-app" / device. People continue to cleverly and creatively develop apps for and get more and more mileage out of IPv4... ( personally I feel that NAT came out of this "clever-creative-stretch-the-spec" thought process. ) So I agree with Lee that without a "carrot" of "You have an IPv4 allocation, here's your equivalent IPv6 allocation, no questions asked", you're going to have to either wait for no address availability or some IPv6 "killer-app" to see folks start to move in any significant number. And given how clever folks are, I'm not sure how much of a forcing function 0 IPv4 addresses is going to be yet... No vendor is going to "drop" IPv4 support... not if they want to stay in business. Every piece of equipment I have supports a IPv6 and IPv4 stack...and has for years, so it's not because I couldn't do it... Earl Baugh -------------- next part -------------- An HTML attachment was scrubbed... URL: From Keith at jcc.com Wed Oct 28 18:25:33 2009 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 28 Oct 2009 18:25:33 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE8B38D.2020408@chl.com> References: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> <20091028205356.GA51268@ussenterprise.ufp.org> <4AE8B38D.2020408@chl.com> Message-ID: <8663deb08fd0c22c65383a21be7e40b94ae8c4dc@jcc.com> > Joe Maimon wrote: >It is not foolish to suggest that providing all abilities in IPv6 that >are widely used in IPv4 lowers the barrier to adoption. Joe, We can debate your statement for a great deal of time, but to what point? This mailing list is the ARIN policy mailing list. ARIN is responsible for number assignments, not for network protocols. The underlying issue is that the available pool of IPv4 addresses will dry up in the next couple of years. IPv6 is the solution to IPv4 pool exhaustion whether or not IPv6 protocols and products have all of the abilities that are widely used in IPv4. This list is a good place to debate topics such as the tradeoff between Provider Independent (PI) assignments and Provider Aggregatable (PA) allocations. (Or is it PI allocations and PA assignments?) However, ARIN is not in a position to do anything about NAT6-6 no matter how much technical merit it has. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From jmaimon at chl.com Wed Oct 28 18:31:34 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 18:31:34 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <8663deb08fd0c22c65383a21be7e40b94ae8c4e2@jcc.com> References: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> <20091028205356.GA51268@ussenterprise.ufp.org> <4AE8B38D.2020408@chl.com> <8663deb08fd0c22c65383a21be7e40b94ae8c4e2@jcc.com> Message-ID: <4AE8C646.2030607@chl.com> Keith W. Hare wrote: > However, ARIN is not in a position to do anything about NAT6-6 no matter how much technical merit it has. > > Keith > > ARIN is in the position of doing something or nothing, policy-wise, in response to coming depletion. Whether it is important or not to try to do something meaningful with regards to the upcoming depletion depends on whether you believe that IPv6 adoption will be swift or slow, painless or painful. IPv6 adoption uptake depends on many factors, possibly those related to NAT66, but more probably those related to NAT64. While ARIN cant do anything about protocol design, forming conclusions and opinions about protocol design has an effect on potential policy. Joe From scottleibrand at gmail.com Wed Oct 28 18:35:14 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 28 Oct 2009 15:35:14 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: References: Message-ID: <4AE8C722.9060102@gmail.com> Earl, Just to clarify: you're just referring to the dollar cost of getting IPv6, right? (We adopted policy not too long ago to make sure you qualify for a direct IPv6 assignment if you want one.) Have you considered getting an IPv6 /48 from your upstream(s)? That should be completely free, and should allow you to dual-stack at no cost... One thing that may develop into an effective carrot is that the IPv4 transfer market will put a price on your IPv4 block. Have you thought at all about how high that price would have to be to get you to renumber out of it? -Scott Earl Baugh wrote: > Joe Maimon wrote: > >>Lee Dilkie wrote: > >> > >> One good way for organizations like ARIN to help with dual stack is to > >> simply give out v6 addresses, free, to all current v4 address holders > >> > >Which they do for the most part. To date the only significant complaints > >I have seen have been regarding those who arent IPv4 holders or with the > >single prefix policy. > > As a "small" legacy IPv4 holder, I can attest that one of the main > reasons I haven't rolled out IPv6 > is mostly because I wasn't offered an IPv6 equivalent to the IPv4 I > hold. > > I know of other similar small legacy IPv4 holders who are in the exact > came boat. > > I did see where I could pay $$ to register and then continuously pay > $$ for it each year... > But I'll be fairly honest, what would be in it for me? Yes, it's a > self-centered attitude, I acknowledge that, however > businesses and organizations on the whole need some reason, aside from > the "we'd all like you to", > or "this is the latest technology, trust me you HAVE to have it". > For a lot of businesses and organizations > neither of those reasons will get them to change. If what I have > meets my needs, and there aren't any IPv6 features > or services that I "have-to-have" along with the additional cost to > even get started, what's the motivation? > (even IF it is free, I still have to incur additional time and labor > to manage the dual stacks, but I'd be at least > willing and able to at least "start" moving if I had one in hand....) > > For example, at least to some degree, Windows XP to Windows Vista > adoption numbers support this type of thought process. > What's going to "force" people to move from XP is Microsoft stopping > support for it, (that's what happened with Win98) and/or there being > some device or application that breaks the old, or requires the newer > OS (USB devices for Windows 98 to Windows XP for example). > > However, in the IPv4 case, you're not going to get "support dropped" > for it, and to date there isn't any IPv6 "killer-app" / device. > People continue to cleverly and creatively develop apps for and get > more and more mileage out of IPv4... > ( personally I feel that NAT came out of this > "clever-creative-stretch-the-spec" thought process. ) > > So I agree with Lee that without a "carrot" of "You have an IPv4 > allocation, here's your equivalent IPv6 allocation, no questions asked", > you're going to have to either wait for no address availability or > some IPv6 "killer-app" to see folks start to move in any significant > number. > And given how clever folks are, I'm not sure how much of a forcing > function 0 IPv4 addresses is going to be yet... > > No vendor is going to "drop" IPv4 support... not if they want to stay > in business. > Every piece of equipment I have supports a IPv6 and IPv4 stack...and > has for years, so it's not because I couldn't do it... > > > Earl Baugh > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Keith at jcc.com Wed Oct 28 18:38:04 2009 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 28 Oct 2009 18:38:04 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE8C646.2030607@chl.com> References: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> <20091028205356.GA51268@ussenterprise.ufp.org> <4AE8B38D.2020408@chl.com> <8663deb08fd0c22c65383a21be7e40b94ae8c4e2@jcc.com> <4AE8C646.2030607@chl.com> Message-ID: > -----Original Message----- > From: Joe Maimon [mailto:jmaimon at chl.com] > Sent: Wednesday, October 28, 2009 6:32 PM > To: Keith W. Hare > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > > > Keith W. Hare wrote: > > However, ARIN is not in a position to do anything about > NAT6-6 no matter how much technical merit it has. > > > > Keith > > > > > ARIN is in the position of doing something or nothing, > policy-wise, in > response to coming depletion. > > Whether it is important or not to try to do something meaningful with > regards to the upcoming depletion depends on whether you believe that > IPv6 adoption will be swift or slow, painless or painful. > > IPv6 adoption uptake depends on many factors, possibly those > related to > NAT66, but more probably those related to NAT64. > > While ARIN cant do anything about protocol design, forming > conclusions > and opinions about protocol design has an effect on potential policy. That's a fair statement. So, based on your belief that NAT66 and/or NAT64 are critical factors in IPv6 adoption, what policy directions do you propose? Keith From marty at akamai.com Wed Oct 28 18:43:08 2009 From: marty at akamai.com (Martin Hannigan) Date: Wed, 28 Oct 2009 18:43:08 -0400 Subject: [arin-ppml] Draft Policy 2009-3 (Global Proposal): Allocation ofIPv4 Blocks to Regional Internet Registries - Last Call In-Reply-To: <4AE88FE8.5080103@arin.net> References: <4AE88FE8.5080103@arin.net> Message-ID: I'm encouraged that there is something resembling a policy. Since this appears to be more than slight contextual edits of the originally submitted policy I strongly encourage the authors to resubmit their policy in this form to the other RIR forums for consensus and their hopeful adoption. Best Regards, Martin Hannigan NRO NC On Oct 28, 2009, at 2:39 PM, Member Services wrote: > The ARIN Advisory Council (AC) met on 23 October 2009 and decided to > send a revised version of the following draft policy to last call: > > Draft Policy 2009-3 (Global Proposal): Allocation of IPv4 Blocks > to > Regional Internet Registries > > The AC met in accordance with the ARIN Policy Development Process > which > requires the AC to meet within 30 days of the conclusion of the Public > Policy Meeting to make decisions about the draft policies that had > been > presented. The AC revised the draft. The AC removed sections B.1.d > and B.4. > > B.1. ?d. Legacy address space. IPv4 address space allocated or > assigned > prior to the creation of the RIR.? > > B. ?4. Initial Allocation of IPv4 Address Space > Each new RIR shall, at the moment of recognition, be allocated one (1) > allocation unit by the IANA. If an allocation unit is not available, > then the IANA will issue this block as soon as one is available. This > allocation will be made regardless of the newly formed RIR's projected > utilization figures and shall be independent of the IPv4 address space > that may have been transferred to the new RIR by the already existing > RIRs as part of the formal transition process.? > > Feedback is encouraged during this last call period. All comments > should > be provided to the Public Policy Mailing List. This last call will > expire on 13 November 2009. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-3 (Global Proposal) > Allocation of IPv4 Blocks to Regional Internet Registries > > Version/Date: 28 October 2009 > > Policy statement: > > This document describes the policy governing the allocation of IPv4 > address space from the IANA to the Regional Internet Registries > (RIRs). > This document does not stipulate performance requirements in the > provision of services by IANA to an RIR in accordance with this > policy. > Such requirements should be specified by appropriate agreements among > the RIRs and ICANN. > > This policy is to be implemented in two phases. > > A. Phase I: Recovery of IPv4 Address Space > > Upon ratification of this policy by the ICANN Board of Directors the > IANA shall establish a mechanism to receive IPv4 address space which > is > returned to it by the RIRs, and hold that address space in a > 'recovered > IPv4 pool'. > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA. Each RIR shall at > quarterly intervals return any such designated address space to the > IANA > in aggregated blocks of /24 or larger, for inclusion in the recovered > IPv4 pool. > > During Phase I, no allocations will be made from the recovered IPv4 > pool. Return of recovered address space (as described above) will > continue throughout Phase II. > > B. Phase II: Allocation of Recovered IPv4 address space by the IANA > > Upon ratification of this policy by the ICANN Board of Directors and a > declaration by the IANA that its existing free pool of unallocated > IPv4 > address space is depleted; Global Addressing Policy ASO-001-2 (adopted > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to > allocate the IPv4 address space from the recovered IPv4 pool. > > 1. The following definitions apply to this policy: > > a. Recovered Address Space. Recovered address space is that address > space that is returned to an RIR as a result of any activity that > seeks > to reclaim unused address space or is voluntarily returned to the > RIR or > is reclaimed by the RIR as a result of legal action or abuse > determination. Recovered address space does not include that address > space that is reclaimed because of non-payment of contractual fees > whose > reclamation date is less than 1 year at the time of the report. > > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated > IPv4 > address space held by an RIR to include recovered address space not > yet > returned less that address space that is committed in accordance with > the RIR's reservation policy and practices. > > c. Aggregated address blocks. Aggregated address blocks are contiguous > prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 > and 10.0.1.0/24 are two contiguous prefixes that can be combined to > form > an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two > contiguous prefixes that cannot be combined on a natural bit > boundary to > form an aggregated block. > > 2. Allocation of IPv4 Address Space > > a. For the purposes of this policy, an 'IPv4 allocation period' is > defined as a 6-month period following 1 March or 1 September in each > year. > > b. At the beginning of each IPv4 allocation period, the IANA will > determine the 'IPv4 allocation unit' for that period, as 1/10 of its > IPv4 address pool, rounded down to the next CIDR (power-of-2) > boundary. > The minimum 'IPv4 allocation unit' size will be a /24. > > c. In each allocation period, each RIR may issue one IPv4 request to > the > IANA. Providing that the RIR satisfies the allocation criteria > described > in paragraph B.2, the IANA will allocate a single allocation unit, > composed of the smallest possible number of blocks available in its > IPv4 > address pool. > > 3. IPv4 Address Space Allocation Criteria > > A RIR is eligible to receive additional IPv4 address space from the > IANA > when the total of its IPv4 address holdings is less than 50% of the > current IPv4 allocation unit, and providing that it has not already > received an IPv4 allocation from the IANA during the current IPv4 > allocation period. > > 5. Reporting > > a. All returned space is to be recorded in an IANA-published log of > IPv4 > address space transactions, with each log entry detailing the returned > address block, the date of the return, and the returning RIR. > > b. All allocated space is also to be recorded in this IANA-published > log > of IPv4 address space transactions, with each log entry detailing the > address blocks, the date of the allocation and the recipient RIR. > > c. The IANA will maintain a public registry of the current disposition > of all IPv4 address space, detailing all reservations and current > allocations and current IANA-held address space that is unallocated. > > d) The IANA may make public announcements of IPv4 address block > transactions that occur under this policy. The IANA will make > appropriate modifications to the "Internet Protocol V4 Address Space" > page of the IANA website and may make announcements to its own > appropriate announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry > they have been allocated. > > Rationale: > > With the depletion of the IANA free pool of IPv4 address space, the > current policy regarding the allocation of IPv4 address space to the > RIRs will become obsolete. The RIRs may already, according to their > individual policies and procedures, recover IPv4 address blocks of any > size. However, current policy requires IANA to make allocations to the > RIRs in blocks of /8. If any blocks smaller than /8 are returned to > the > IANA, current policy does not provide a way to allocate that space. > This > policy provides a mechanism for the RIRs to return recovered IPv4 > address space to the IANA and provides the IANA the policy by which it > can allocate it back to the RIRs on a needs basis. This policy > creates a > new global pool of IPv4 address space that can be allocated where it > is > needed on a global basis without a transfer of address space between > the > RIRs. > > The original version of Global Policy Proposal for the Allocation of > IPv4 Blocks to Regional Internet Registries (ARIN policy 2009-3) was > proposed in the ARIN region, discussed on the Public Policy Mailing > List > (PPML), and by the Advisory Council (AC). A number of concerns were > expressed, mostly related to the mandatory requirement to return > reclaimed space to IANA. In an attempt to alleviate some of these > concerns, the AC modified 2009-3 to make the return of non-legacy > space > to IANA optional. This version of the proposal was discussed at the > April 2009 ARIN XXIII meeting in San Antonio. During that discussion, > it became clear that there was not a consensus in the ARIN region for > either the original proposal, or the modified legacy-only version. > > As a result of subsequent discussions of the global policy at the > spring > AfriNIC and LACNIC meetings, it became clear that one of the reasons > 2009-3 is such a difficult policy to get consensus on is that the > original policy, as proposed, is a global policy proposal that has > some > local policy aspects, namely that requires each RIR to return > reclaimed > space. Ideally, global policies are supposed to maintain a clean > separation from local policies: global policy is supposed to only > govern > the relationship between the IANA and the RIRs, and local policy > defines > what the RIR can do internally. As a side effect of the blurring of > global and local policy in the current revision of 2009-3, ARIN (and > most of the other RIRs) have been having an interesting debate about > exactly which space should be covered by the policy. > > To sidestep this issue, the changes made to the proposal are in the > 2nd > paragraph of section A: > > "Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA. Each RIR shall at > quarterly intervals return any such designated address space to the > IANA > in aggregated blocks of /24 or larger, for inclusion in the recovered > IPv4 pool." > > The original version read: > > "Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. Each > RIR > shall at quarterly intervals return any such recovered address space > to > the IANA in aggregated blocks of /24 or larger, for inclusion in the > recovered IPv4 pool." > > The distinction is that under the revised version of 2009-3, recovered > space is returned after it is designated for return under local > policies > and strategies. The original text dictated the terms of what must be > returned (everything /24 or larger) as part of the global policy. > > Since global policy is supposed to only govern the relationship > between > the IANA and the RIRs, and local policy defines what the RIR can do > internally. This change brings the proposal more in line with that > definition of a global policy, and should address a number of other > concerns as well. > > As this is a global policy, it will need to be reconciled with the > version passed in the other RIRs. As this appears to be a substantive > change, that most likely means the other RIRs will need to go back and > pass the modified version as well. > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXX > > Below are 3 exemplar scenarios of the execution of this policy after > Phase II is in force. These are not part of the rationale but are > provided for illustrative purposes. > > Example 1: > > > > On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses) > worth of IPv4 addresses. > > 1. IANA calculates that 1/10 of this space is 3,276 addresses. > > 2. IANA rounds this down to the next bit boundary, which creates a > minimum allocation size of /21 (2,048 addresses). > > 3. Each RIR can request and receive a single allocation unit > equivalent > to a /21 worth of addresses. > > 4. While IANA may not be able to allocate a contiguous /21 and can > allocate noncontiguous smaller blocks equivalent to a /21 worth of > addresses. > > Example 2: > > On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses) > worth of IPv4 addresses. > > 1. IANA calculates that 1/10 of this space is 409 addresses. > > 2. IANA rounds this down to the next bit boundary, which creates a > minimum allocation size of /24 (256 addresses). > > 3. Each RIR can request and receive a single allocation unit > equivalent > to a /24 worth of addresses. > > 4. As the minimum size of address space returned to IANA is /24, IANA > can allocate a contiguous range of addresses that amount to a /24. > > Example 3: > > On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses) > worth of IPv4 addresses. > > 1. IANA calculates that 1/10 of this space is 204 addresses. > > 2. IANA rounds this down to the next bit boundary, which creates a > minimum allocation size of /25 (128 addresses). > > 3. A /25 is smaller than the minimum permissible allocation size under > this policy. A /25 is smaller than the minimum permissible allocation > size under this policy. Therefore, IANA is unable to make an > allocation > until more address space is received. > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXX > > Timetable for implementation: > > This policy is to be implemented immediately upon ratification by the > ICANN Board of Directors according to the global policy process > described in the ASO MoU. > > > > _______________________________________________ > 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 owen at delong.com Wed Oct 28 18:53:56 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Oct 2009 15:53:56 -0700 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call In-Reply-To: <4AE89034.8040301@arin.net> References: <4AE89034.8040301@arin.net> Message-ID: I feel that we should include in this policy as it goes to the board a reduction in the 200 site requirement to 100 sites. I feel that the community supported that modification in general and in the show of hands. I encourage the advisory council to consider this modification as the proposal comes out of last call before handing it off to the board. I encourage others present on this list to express support for this idea if they feel it should be done. Owen (Speaking only as an individual interested in improving policy and not in my role as a member of the AC) On Oct 28, 2009, at 11:40 AM, Member Services wrote: > The ARIN Advisory Council (AC) met on 23 October 2009 and decided to > send a revised version of the following draft policy to last call: > > Draft Policy 2009-7: Open Access To IPv6 > > The AC met in accordance with the ARIN Policy Development Process > which > requires the AC to meet within 30 days of the conclusion of the Public > Policy Meeting to make decisions about the draft policies that had > been > presented. The AC revised the draft. The draft policy is now limited > to > removing the IPv6 routing requirement from current policy. It does not > change the initial IPv6 allocation criteria. However, the AC stated > they > intend to continue to work on that issue. > > Feedback is encouraged during this last call period. All comments > should > be provided to the Public Policy Mailing List. This last call will > expire on 13 November 2009. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-7 > Open Access To IPv6 > > Version/Date: 28 October 2009 > > Policy statement: > > Remove ?by advertising that connectivity through its single aggregated > address allocation? from article 3 of section 6.5.1.1 > > Rationale: > > Removing the requirement for a single aggregate announcement benefits > the NRPM itself, as it has been decided by the community that it > should > not contain routing advice. > > Timetable for implementation: immediately upon BoT ratification > > _______________________________________________ > 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 jmaimon at chl.com Wed Oct 28 18:56:37 2009 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 28 Oct 2009 18:56:37 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: <8EA9DEDC7319124EB668DCFCB99C0546AE84D8D968@fnskyexch01.fnsky.com> <20091028205356.GA51268@ussenterprise.ufp.org> <4AE8B38D.2020408@chl.com> <8663deb08fd0c22c65383a21be7e40b94ae8c4e2@jcc.com> <4AE8C646.2030607@chl.com> Message-ID: <4AE8CC25.206@chl.com> Keith W. Hare wrote: > That's a fair statement. > > So, based on your belief that NAT66 and/or NAT64 are critical factors in IPv6 adoption, what policy directions do you propose? > > Keith > Thats not quite it. My opinion is that due to the current state of nat64, the most likely scenario is dual stack, but with more and more nat44, with market pressures wringing out inefficiencies until IPv6 succeeds in replacing ipv4 as the primary player. I also do not believe many large end user networks will rush to adopt ipv6 without it meeting their business needs and comfort levels. I believe that policies that try to improve the general state of IPv4 during and after depletion should be worked on. What I am interested in hearing is just how prevalent is the viewpoint that nothing should be done policy-wise. Joe From cgrundemann at gmail.com Wed Oct 28 19:01:31 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 28 Oct 2009 17:01:31 -0600 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: <4AE893D9.8000206@gmail.com> References: <443de7ad0910271036w4e72cda1rd757a389bd182b97@mail.gmail.com> <4AE893D9.8000206@gmail.com> Message-ID: <443de7ad0910281601ld73d3b0uff7c730dc2f14870@mail.gmail.com> On Wed, Oct 28, 2009 at 12:56, Scott Leibrand wrote: > George, Wes E [NTK] wrote: >> >> +1. Can we simply abandon this in favor of proposal 99, or is there >> something in this proposal besides the sliding trigger that would make it >> distinct? I've reread both, and I'm not really seeing anything, besides >> maybe the specific references to small ISPs, which I'm not convinced is >> necessary to achieve the intended result by simply making it possible to get >> /24s as end allocations for multihomed networks. PP98 applies to ISPs via initial allocations PP99 applies to end-users via initial assignments (specifically multi-homed end-users) > > When the AC decided to put both proposal 98 and 99 on our docket, my > recollection is that we intended to merge the two into a single draft policy > to present in Toronto. ?My own opinion is that the simpler policy (99) is a > good starting framework, but we did feel that there were some aspects of 98 > that we would probably want to include as well. I do not think that the policies should be merged. I think that it is likely enough that some in the community will support changing the minimum for multi-homed assignments while not supporting the change in minimum for initial allocations - and vice verse - that the two concepts be discussed and debated individually. > > If would be quite useful if everyone could take a look at the proposals with > an eye toward providing the AC feedback on which aspects of the proposal(s) > would be most useful and beneficial to include in a merged version. IMHO: (1) pp99 is ready to become a draft policy. (2) pp98 should be simplified before becoming a draft policy. Something along the lines of: Replace the current section 4.2.2.1.1 with: 4.2.2.1.1. Use of /22 The efficient utilization of an entire previously allocated /22 from their upstream ISP. This /22 allocation may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 4 /24s. For example, if an organization holds a smaller allocation, such as 3 /24s, from its upstream provider, the organization would not meet the minimum utilization requirements of a /22. (3) And while we are on the topic, Is there any interest in lowering the minimum allocation for multi-homed ISPs? It would be as easy as adding a line to section 4.2.2.2. Multihomed, like this: When requesting a /23, demonstrate the efficient utilization of a minimum contiguous or noncontiguous /24 from an upstream. If there is any interest in discussing that as well, I can submit a formal proposal... $.02 ~Chris > > Thanks, > Scott > > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From scottleibrand at gmail.com Wed Oct 28 19:21:06 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 28 Oct 2009 16:21:06 -0700 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: <443de7ad0910281601ld73d3b0uff7c730dc2f14870@mail.gmail.com> References: <443de7ad0910271036w4e72cda1rd757a389bd182b97@mail.gmail.com> <4AE893D9.8000206@gmail.com> <443de7ad0910281601ld73d3b0uff7c730dc2f14870@mail.gmail.com> Message-ID: <4AE8D1E2.9080504@gmail.com> Chris Grundemann wrote: > PP98 applies to ISPs via initial allocations > PP99 applies to end-users via initial assignments (specifically > multi-homed end-users) > > I do not think that the policies should be merged. I think that it is > likely enough that some in the community will support changing the > minimum for multi-homed assignments while not supporting the change in > minimum for initial allocations - and vice verse - that the two > concepts be discussed and debated individually. > Good point. No argument here. > IMHO: > > (1) pp99 is ready to become a draft policy. > > (2) pp98 should be simplified before becoming a draft policy. > Something along the lines of: > > Replace the current section 4.2.2.1.1 with: > > 4.2.2.1.1. Use of /22 > > The efficient utilization of an entire previously allocated /22 from > their upstream ISP. This /22 allocation may have been provided by an > ISP's upstream provider(s), and does not have to be contiguous address > space. The organization must meet the requirement of efficient use of > 4 /24s. For example, if an organization holds a smaller allocation, > such as 3 /24s, from its upstream provider, the organization would not > meet the minimum utilization requirements of a /22. > > (3) And while we are on the topic, Is there any interest in lowering > the minimum allocation for multi-homed ISPs? It would be as easy as > adding a line to section 4.2.2.2. Multihomed, like this: > > When requesting a /23, demonstrate the efficient utilization of a > minimum contiguous or noncontiguous /24 from an upstream. > > If there is any interest in discussing that as well, I can submit a > formal proposal... > I would support either or both of these changes. We'll also need to consider how the minimum allocation and assignment size interact with transfer policy (for example, whether they allow legacy /24s to be transferred). I understand that ARIN staff will be publishing their transfer implementation plan soon, so I'll hold off on making any specific suggestions until I see that. -Scott From Lee at dilkie.com Wed Oct 28 19:25:24 2009 From: Lee at dilkie.com (Lee Dilkie) Date: Wed, 28 Oct 2009 19:25:24 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> Message-ID: <4AE8D2E4.8080200@dilkie.com> Chris Grundemann wrote: > I don't think it depends on a % of everyone but rather on the right > groups leading. If a significant amount of content (facebook, > youtube, itunes, major news sites and what have you) was dual-stacked, > that could make at least residential / home-use IPv6 only service > practical for at least some users, especially if it was offered at a > reduced cost. That opens the door and starts the ball rolling. I am > not going to say that we will (or even can) reach 100% IPv6 > penetration before we run out of available IPv4 in that manner but I > am not positive that it is out of reach yet either... > > > Agreed. That is why I put a ? on the 80%. If some really big and important players (applications) go dual stack, that covers a lot of territory. From cgrundemann at gmail.com Wed Oct 28 19:49:07 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 28 Oct 2009 17:49:07 -0600 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE8A08F.7000708@chl.com> References: <443de7ad0910281002y3cddcf64n411cfe1bb4f172d9@mail.gmail.com> <4AE887D7.60406@chl.com> <4AE8A08F.7000708@chl.com> Message-ID: <443de7ad0910281649x2b73cc1as61efb6b0e27dd23@mail.gmail.com> On Wed, Oct 28, 2009 at 13:50, Joe Maimon wrote: > > > Paul G. Timmins wrote: >> >> Taking this to its logical conclusion, it's not necessary for community >> consensus to implement NAT66. If people demand it, and equipment vendors >> want to implement it, they will, and then will standardize it after the >> fact, much like many other current standards have been done. >> >> The fact that no such standard exists and no platform I'm aware of >> implements NAT66 is pretty telling in and of itself. >> >> -Paul >> >> >> > > What is proper is to stop demanding that everyone not want to use it. I was not trying to demand that no-one use NAT (although that case _can_ be made). I was trying to point out (perhaps not very well) that there _are_ other ways to do _everything_ that NAT has come to be used for in IPv4 (a handful have been listed elsewhere in this thread). It may require changing your mindset a bit and it may even require a bit more work but it is very possible. The exception is what NAT44 was originally designed to do; which is prolong the useful life of IPv4 - and its effectiveness at that task is nearing its end. The only thing that I would demand (if I could) is that everyone take IPv6 seriously. If it is lacking features that you need, make that known to your vendors - and do it soon (I would encourage some research first though, you may not need exactly what you think you need). You _will_ need to deploy IPv6. The sooner your network is capable of that deployment, the less it will cost you and the easier it will make the rest of our lives as well. Of course, if you wait 'till the last minute others will likely be able to make a fortune as IPv6 transition consultants... (using the words "you", "our" and "others" very generally, not directly) $.02 ~Chris > Furthermore, at this similar state in IPv4 global deployment, NAT44 wasnt > really available either, and instead people were using other horrible > workarounds. > > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From owen at delong.com Wed Oct 28 20:04:38 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Oct 2009 17:04:38 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE8D2E4.8080200@dilkie.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> Message-ID: <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> On Oct 28, 2009, at 4:25 PM, Lee Dilkie wrote: > > > Chris Grundemann wrote: >> I don't think it depends on a % of everyone but rather on the right >> groups leading. If a significant amount of content (facebook, >> youtube, itunes, major news sites and what have you) was dual- >> stacked, >> that could make at least residential / home-use IPv6 only service >> practical for at least some users, especially if it was offered at a >> reduced cost. That opens the door and starts the ball rolling. I am >> not going to say that we will (or even can) reach 100% IPv6 >> penetration before we run out of available IPv4 in that manner but I >> am not positive that it is out of reach yet either... >> >> >> > Agreed. That is why I put a ? on the 80%. If some really big and > important players (applications) go dual stack, that covers a lot of > territory. You mean like: Google Yahoo MSN (All of whom have publicly announced dual stack plans)? Owen From steve at ibctech.ca Wed Oct 28 21:37:15 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 28 Oct 2009 21:37:15 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> Message-ID: <4AE8F1CB.1060403@ibctech.ca> Chris Grundemann wrote: > On Wed, Oct 28, 2009 at 14:32, Joe Maimon wrote: >> >> Lee Dilkie wrote: >>> My comment on the subject, repeated from last year. >>> >>> The only proper way forward is dual stack and the faster we achieve some >>> magic number (80%?) of dual stack penetration, the faster we can roll >>> out v6 only. >>> >>> >> Its not the proper way forward. It is the theoretically ideal way forward >> (albeit at 100%). It is also the way forward that hasnt gotten enough >> momentum yet and is uncertain that it will in time, unaided. Waiting for 80% >> penetration before depletion is very likely overly optimistic, probably >> because real uptake of IPv6 depends on depletion. Even then, it is hardly >> likely it will occur in any meaningfully quick fashion. >> >> Here is the oft-quoted chicken and egg problem in its expanded form. >> >> Why would any existing user of IPv4 need to add dual stack to IPv6? >> >> To access the IPv6 only users. >> >> Why would anybody ever be publicly accessible only via IPv6? >> >> Because they cant get any IPv4. >> >> Who is going to put up with that? >> >> Only people who dont mind waiting for large percentages of the internet to >> decide it is worth getting IPv6 to talk to them. >> >> What will the rest do? >> >> Beg borrow and steal to get IPv4. >> >> Rinse, Repeat. >> >> The waiting for dual stack to reach critical mass plan is proceeding too >> slowly, calling into doubt whether it is smart to continue waiting on it. >> >> Due to address shortage, continuing with waiting for dual stacking to reach >> critical is going to require more and more NAT, and more and more wrangling >> over past inefficiencies. Which is bad, even as it may become more and more >> necessary. >> >> Furthermore, as a plan formula it sucks. We have to invest 80% of the effort >> to get the 20% payoff? The 80 20 rule is supposed to work in the other way. >> >> If the plan was to wait until 20% of the internet was dual stack and then >> the rest would "automatically" follow and cause IPv6 only to be practical, >> now thats more achievable, but still unlikely. > > I don't think it depends on a % of everyone but rather on the right > groups leading. If a significant amount of content (facebook, > youtube, itunes, major news sites and what have you) was dual-stacked, > that could make at least residential / home-use IPv6 only service > practical for at least some users, especially if it was offered at a > reduced cost. Even though I'm but a shadow in the ISP world, we're small, and I only have one level of management above me, I can't forsee this going over well with ANY size ISP: - sir, we're going to lower prices for these users by $x/month - 'why?' - because they have IPv6 only - 'does that save us money on bandwidth?' - no - 'does it save us money on our v4 allocation fees?' - no - 'so we're giving less value for less money, but higher engineering costs' - yes I can understand that in the larger orgs, policy matters and rules have to be followed. Where I forsee change happening, is at the smaller orgs like myself, where the engineers/ops have complete control of the network with little/no policy, and can 'force migrate' their users to dual-stack (at least offer it with their access). Much like the economy... the small businesses (in aggregate) generally have the largest impact. The big boys are already migrating. We need more of the small guys like myself to do so. Show the big boys that we are ready, and that we are supporting their migration. Rally the troops, so to speak. (no, I'm not a 'fanatic', btw...) Steve ps. and fwiw, push forward. The protocol 'bikeshed' stuff should be left to the IETF. There are too many people making complaints. Let's just implement, and show that we're implementing. From matthew at matthew.at Thu Oct 29 00:49:57 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 28 Oct 2009 21:49:57 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> Message-ID: <4AE91EF5.6030201@matthew.at> Owen DeLong wrote: > > On Oct 28, 2009, at 4:25 PM, Lee Dilkie wrote: > >> >> >> Chris Grundemann wrote: >>> I don't think it depends on a % of everyone but rather on the right >>> groups leading. If a significant amount of content (facebook, >>> youtube, itunes, major news sites and what have you) was dual-stacked, >>> that could make at least residential / home-use IPv6 only service >>> practical for at least some users, especially if it was offered at a >>> reduced cost. That opens the door and starts the ball rolling. I am >>> not going to say that we will (or even can) reach 100% IPv6 >>> penetration before we run out of available IPv4 in that manner but I >>> am not positive that it is out of reach yet either... >>> >>> >>> >> Agreed. That is why I put a ? on the 80%. If some really big and >> important players (applications) go dual stack, that covers a lot of >> territory. > > You mean like: > > Google > Yahoo > MSN > > (All of whom have publicly announced dual stack plans)? > If I have dual-stack IPv6 + NAT (or if my ISP was lucky, public) IPv4 service, how is my access to Google, Yahoo or MSN better than it is if I have *only* IPv4 via NAT? When there's an answer to that question more exciting than "the turtle dances when you go to kame.net", people will care and demand IPv6. Until then, why would they bother? I've had every desktop in my house IPv6-enabled for over a year. I've experienced absolutely no difference, except for a few sites that are a bit slower to reach as a result. On those days when, for whatever reason, the IPv6 is down... I don't even notice until I happen to see it in the logs. Matthew Kaufman From spiffnolee at yahoo.com Thu Oct 29 01:27:21 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Wed, 28 Oct 2009 22:27:21 -0700 (PDT) Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE91EF5.6030201@matthew.at> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <4AE91EF5.6030201@matthew.at> Message-ID: <705270.55338.qm@web63304.mail.re1.yahoo.com> ----- Original Message ---- > From: Matthew Kaufman > To: Owen DeLong > > If I have dual-stack IPv6 + NAT (or if my ISP was lucky, public) IPv4 > service, how is my access to Google, Yahoo or MSN better than it is if I > have *only* IPv4 via NAT? IPv6 is cheaper (for the ISP, who doesn't have to pass the expense on to you) than large-scale NAT. > When there's an answer to that question more exciting than "the turtle > dances when you go to kame.net", people will care and demand IPv6. Until > then, why would they bother? > > I've had every desktop in my house IPv6-enabled for over a year. I've > experienced absolutely no difference, except for a few sites that are a > bit slower to reach as a result. On those days when, for whatever > reason, the IPv6 is down... I don't even notice until I happen to see it > in the logs. That's the goal! If you can't tell the difference, then that's a success! Lee From matthew at matthew.at Thu Oct 29 01:35:17 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 28 Oct 2009 22:35:17 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <705270.55338.qm@web63304.mail.re1.yahoo.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <4AE91EF5.6030201@matthew.at> <705270.55338.qm@web63304.mail.re1.yahoo.com> Message-ID: <4AE92995.40107@matthew.at> Lee Howard wrote: > > > ----- Original Message ---- > >> From: Matthew Kaufman >> To: Owen DeLong >> >> If I have dual-stack IPv6 + NAT (or if my ISP was lucky, public) IPv4 >> service, how is my access to Google, Yahoo or MSN better than it is if I >> have *only* IPv4 via NAT? >> > > IPv6 is cheaper (for the ISP, who doesn't have to pass the expense on > to you) than large-scale NAT. > But since they need to provide it *anyway* in order to give me dual-stack (which I need enabled anyway to reach the N% of the Internet that hasn't yet switched *and* my 10 year old laser printer and my in-home music system and the web interface of my solar power system and, and, and...), all we're talking about is "the ISP must pay for the NAT (and maybe some more public address space via a transfer market if they grow) *and* IPv6" vs. "the ISP must pay for the NAT and *not* IPv6". > >> When there's an answer to that question more exciting than "the turtle >> dances when you go to kame.net", people will care and demand IPv6. Until >> then, why would they bother? >> >> I've had every desktop in my house IPv6-enabled for over a year. I've >> experienced absolutely no difference, except for a few sites that are a >> bit slower to reach as a result. On those days when, for whatever >> reason, the IPv6 is down... I don't even notice until I happen to see it >> in the logs. >> > > That's the goal! If you can't tell the difference, then that's a success! > Actually that's the *problem*. If I can't tell the difference, then there's no reason for me to demand IPv6 *or* for my provider to give it to me. IF it is possible to continue indefinitely providing dual-stack (NAT or otherwise for the IPv4), THEN it is possible to continue indefinitely *not* providing IPv6 at all. Until there's an application for which I *can* tell the difference, in a big way. Matthew Kaufman From michael.dillon at bt.com Thu Oct 29 07:13:06 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 29 Oct 2009 11:13:06 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745803D241FF@E03MVZ2-UKDY.domain1.systemhost.net> > Many people > mistake the fact that NAT requires a stateful inspection > gateway to function for security being provided by NAT. The > security is not provided by NAT, it is provided by stateful > inspection" Why not redefine IPv6 NAT to be Network Access Taming (or some other T word) which carries out basic stateful inspection functions? Demand that vendors supply this stateful inspection in all routers and network access gateway boxes with the default setting of "turned ON". > NAT > allows you to utilize private network addresses for ALL your > internal devices.... which makes them unaccessable to > external traffic BY DEFAULT...and then allows you to assign > public IP's to ONLY those devices which are intended to be > externaly accessible. IPv6 with ULA allows you to utilise private network addresses etc., etc... > 2) NAT allows Network Admins the flexability to organize > thier own private address space and the assignment of IP's in > ways that logicaly make sense to them. IPv6 with ULA allows.... > 3) NAT allows you to abstract your internal infrastructure > from the external services you present. This has alot of > utility. IPv6 with ULA allows.... Perhaps every ISP should define a ULA /48 and then reuse that for every customer's internal addressing. In other words, instead of asking every customer to figure out ULA and allocate their own ULA /48, the ISP would say, "Here, just use this prefix for all your private addressing and use this other one for interfaces which need to be publicly accessible for incoming calls". It wouldn't even matter if a smart user, reused that ULA for their friends networks on another ISP, or published it in a magazine article resulting in thousands of sites thinking that ULA /48 is the IPv6 private address range. We really need more articles published covering experiences. --Michael Dillon From Lee at dilkie.com Thu Oct 29 07:30:48 2009 From: Lee at dilkie.com (Lee Dilkie) Date: Thu, 29 Oct 2009 07:30:48 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE92995.40107@matthew.at> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <4AE91EF5.6030201@matthew.at> <705270.55338.qm@web63304.mail.re1.yahoo.com> <4AE92995.40107@matthew.at> Message-ID: <4AE97CE8.6090907@dilkie.com> Matthew Kaufman wrote: > Lee Howard wrote: >> >> >> >> That's the goal! If you can't tell the difference, then that's a >> success! >> > Actually that's the *problem*. If I can't tell the difference, then > there's no reason for me to demand IPv6 *or* for my provider to give > it to me. Yup. It is the problem. Except that at some point your ISP will be unable to give you a v4 address at all and then the ISP would have a very serious business crisis on it's hands. If the ISP were looking ahead then it would understand that eating the cost of v6 rollout to customers, who are not demanding it but it "just works", would be in their best long term business interests. When they get to the point where they cannot hand out a v4 address to go with the v6, if the rest of the net has reached that magic number, then the customer still won't notice. > > IF it is possible to continue indefinitely providing dual-stack (NAT > or otherwise for the IPv4), THEN it is possible to continue > indefinitely *not* providing IPv6 at all. Of course, but we all know it's not possible to continue handing out v4 addresses. > > Until there's an application for which I *can* tell the difference, in > a big way. Agreed. A v6 only killer app would go a long way to helping this. -lee From warren at wholesaleinternet.com Thu Oct 29 08:25:43 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Thu, 29 Oct 2009 07:25:43 -0500 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com><443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com><4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> Message-ID: <80208C10D5BB470680C6D97BF952446C@johnsonvhjjf8v> I think that 80% number is misleading. You're talking 80% because these guys have a lot of content, not because they have a lot of websites. The other 20% could be comprised of literally 10s or 100s of million websites, all of which also need to be accessible to everyone for the transition to be a success. Just because I can get to the top 50 websites on the internet doesn't mean that I don't need access to the other 500 million (or whatever the number is). >> > Agreed. That is why I put a ? on the 80%. If some really big and > important players (applications) go dual stack, that covers a lot of > territory. You mean like: Google Yahoo MSN (All of whom have publicly announced dual stack plans)? Owen _______________________________________________ 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 michael.dillon at bt.com Thu Oct 29 08:51:43 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 29 Oct 2009 12:51:43 -0000 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> Message-ID: <28E139F46D45AF49A31950F88C49745803D24418@E03MVZ2-UKDY.domain1.systemhost.net> > > Agreed. That is why I put a ? on the 80%. If some really big and > > important players (applications) go dual stack, that covers > a lot of > > territory. > > You mean like: > > Google > Yahoo > MSN > > (All of whom have publicly announced dual stack plans)? This is meaningless. It is one thing to "go dual stack" on your core network architecture that rarely grows in number of devices, and which has enough spare IPv4 addresses in existing blocks to last another 5 years. But it is an entirely different thing to "go dual stack" on an edge architecture that is continuosly growing and which need an infusion of new IPv4 addresses every 6 months to handle growth. I think that it is good for providers to dual stack their cores, but I think that the decision to dual stack the edge is one that should not be made lightly. For a provider like Yahoo, Google and MSN, where the edge of the network is the core of their business (i.e. the insides of the data center are the edge of the network), it certainly makes sense to dual-stack their core network while relying on NAT in the data center (or IPv6 with NAT-PT and 6to4) for their core business. However this is a very different topology and business scenario to the one that network operators are grappling with. --Michael Dillon From jweyand at computerdata.com Thu Oct 29 09:28:21 2009 From: jweyand at computerdata.com (Jim Weyand) Date: Thu, 29 Oct 2009 09:28:21 -0400 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call References: <4AE89034.8040301@arin.net> Message-ID: <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> +1 - As a very small ISP I am sure we can say that we are planning on 200 or 250 IPv6 sites but the reality is more likely to be less. -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, October 28, 2009 6:54 PM To: Member Services Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call I feel that we should include in this policy as it goes to the board a reduction in the 200 site requirement to 100 sites. I feel that the community supported that modification in general and in the show of hands. I encourage the advisory council to consider this modification as the proposal comes out of last call before handing it off to the board. I encourage others present on this list to express support for this idea if they feel it should be done. Owen (Speaking only as an individual interested in improving policy and not in my role as a member of the AC) On Oct 28, 2009, at 11:40 AM, Member Services wrote: > The ARIN Advisory Council (AC) met on 23 October 2009 and decided to > send a revised version of the following draft policy to last call: > > Draft Policy 2009-7: Open Access To IPv6 > > The AC met in accordance with the ARIN Policy Development Process > which > requires the AC to meet within 30 days of the conclusion of the Public > Policy Meeting to make decisions about the draft policies that had > been > presented. The AC revised the draft. The draft policy is now limited > to > removing the IPv6 routing requirement from current policy. It does not > change the initial IPv6 allocation criteria. However, the AC stated > they > intend to continue to work on that issue. > > Feedback is encouraged during this last call period. All comments > should > be provided to the Public Policy Mailing List. This last call will > expire on 13 November 2009. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-7 > Open Access To IPv6 > > Version/Date: 28 October 2009 > > Policy statement: > > Remove "by advertising that connectivity through its single aggregated > address allocation" from article 3 of section 6.5.1.1 > > Rationale: > > Removing the requirement for a single aggregate announcement benefits > the NRPM itself, as it has been decided by the community that it > should > not contain routing advice. > > Timetable for implementation: immediately upon BoT ratification > > _______________________________________________ > 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. _______________________________________________ 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 spiffnolee at yahoo.com Thu Oct 29 10:56:12 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 29 Oct 2009 07:56:12 -0700 (PDT) Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE92995.40107@matthew.at> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <4AE91EF5.6030201@matthew.at> <705270.55338.qm@web63304.mail.re1.yahoo.com> <4AE92995.40107@matthew.at> Message-ID: <74793.47478.qm@web63303.mail.re1.yahoo.com> > > IPv6 is cheaper (for the ISP, who doesn't have to pass the expense on to you) > than large-scale NAT. > > > But since they need to provide it *anyway* in order to give me dual-stack (which Large-scale NAT is only required after runout, and only for connections over IPv4. More IPv6 traffic means few NAT boxes. > > > On those days when, for whatever reason, the IPv6 > > > is down... I don't even notice until I happen to see it in the logs. > > That's the goal! If you can't tell the difference, then that's a success! > Actually that's the *problem*. If I can't tell the difference, then there's no > reason for me to demand IPv6 *or* for my provider to give it to me. Maybe we have different goals. My goal is to provide connectivity to my customers. IPv6 is a tool to do that, not an end in itself. > > IF it is possible to continue indefinitely providing dual-stack (NAT or > otherwise for the IPv4), THEN it is possible to continue indefinitely *not* > providing IPv6 at all. > > Until there's an application for which I *can* tell the difference, in a big > way. Does anything break when it goes through two layers of NAT (i.e., home gateway NAT and CGN, a.k.a. NAT444)? Several of the widely used NAT traversal systems assume a single NAT layer; not sure how VoIP, online gaming, p2p will work with NAT444 (or, if the other endpoint is also NAT444, you have NAT44444). Lee From Wesley.E.George at sprint.com Thu Oct 29 11:05:09 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 29 Oct 2009 10:05:09 -0500 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call In-Reply-To: <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> References: <4AE89034.8040301@arin.net> <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> Message-ID: I support this policy as written. I'm struggling with Owen's recommended change a bit. I wasn't in favor of it at the meeting, but I'm trying to keep an open mind. I believe that the general spirit of the recommended changes is to remove as many barriers as possible to deployment of IPv6 by making it very easy to qualify for IPv6 space. I support that in principle. However, I don't understand why direct PI allocations are a requirement for networks of this size vs. simply getting PD space from an upstream. We're talking about networks which do not believe they can put together a plan that passes the red-face test that they will have 200 customers within 5 years. What drives the need for PI space in this case? Having had to personally renumber hundreds of end sites when we deprecated 6bone, I don't view having to renumber if you change providers as a barrier in a network this small (sorry). So that leaves multihoming... Section 6 of the NRPM has no references at all to multihoming. Perhaps that's a problem, given its prevalence in the sections on IPv4. I would be in support of something that adds a reference to being multihomed in the criteria as justification for PI space, rather than a reduction in the number of end sites. IPv6 address space is mindbogglingly big, so I know that talk about trying to be prudent in our use of it will largely be shouted down, but I'll say it anyway. This maybe goes a bit too far. To ask a related question - why would big ISPs need huge blocks (/32-29 or larger) if nearly all of their downstreams can qualify for a PI block either as an end user or an LIR? If we really want nearly everyone to be able to qualify for space directly from ARIN, perhaps we should be looking to move away from the PD model entirely, and leave ISPs to allocate only infrastructure blocks and dynamic end hosts (mobile devices, homes, etc)? I'm not trying to start a discussion about routing table explosion here, so let's leave that on the sidelines for now. I'm simply asking because that's the general direction I see this going if we continue to make it easier for direct allocations from ARIN. Is that the aim? Thanks Wes George -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jim Weyand Sent: Thursday, October 29, 2009 9:28 AM To: Owen DeLong; Member Services Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call +1 - As a very small ISP I am sure we can say that we are planning on 200 or 250 IPv6 sites but the reality is more likely to be less. -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, October 28, 2009 6:54 PM To: Member Services Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call I feel that we should include in this policy as it goes to the board a reduction in the 200 site requirement to 100 sites. I feel that the community supported that modification in general and in the show of hands. I encourage the advisory council to consider this modification as the proposal comes out of last call before handing it off to the board. I encourage others present on this list to express support for this idea if they feel it should be done. Owen (Speaking only as an individual interested in improving policy and not in my role as a member of the AC) On Oct 28, 2009, at 11:40 AM, Member Services wrote: > The ARIN Advisory Council (AC) met on 23 October 2009 and decided to > send a revised version of the following draft policy to last call: > > Draft Policy 2009-7: Open Access To IPv6 > > The AC met in accordance with the ARIN Policy Development Process > which > requires the AC to meet within 30 days of the conclusion of the Public > Policy Meeting to make decisions about the draft policies that had > been > presented. The AC revised the draft. The draft policy is now limited > to > removing the IPv6 routing requirement from current policy. It does not > change the initial IPv6 allocation criteria. However, the AC stated > they > intend to continue to work on that issue. > > Feedback is encouraged during this last call period. All comments > should > be provided to the Public Policy Mailing List. This last call will > expire on 13 November 2009. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-7 > Open Access To IPv6 > > Version/Date: 28 October 2009 > > Policy statement: > > Remove "by advertising that connectivity through its single aggregated > address allocation" from article 3 of section 6.5.1.1 > > Rationale: > > Removing the requirement for a single aggregate announcement benefits > the NRPM itself, as it has been decided by the community that it > should > not contain routing advice. > > Timetable for implementation: immediately upon BoT ratification > > _______________________________________________ > 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. _______________________________________________ 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. _______________________________________________ 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. This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From spiffnolee at yahoo.com Thu Oct 29 11:15:36 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 29 Oct 2009 08:15:36 -0700 (PDT) Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <80208C10D5BB470680C6D97BF952446C@johnsonvhjjf8v> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com><443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com><4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <80208C10D5BB470680C6D97BF952446C@johnsonvhjjf8v> Message-ID: <294122.28437.qm@web63302.mail.re1.yahoo.com> > I think that 80% number is misleading. You're talking 80% because these > guys have a lot of content, not because they have a lot of websites. The > other 20% could be comprised of literally 10s or 100s of million websites, > all of which also need to be accessible to everyone for the transition to be > a success. Just because I can get to the top 50 websites on the internet > doesn't mean that I don't need access to the other 500 million (or whatever > the number is). Yes, there's a long tail. But several of the largest companies hosting those long-tail websites have also declared IPv6 plans. If you run www.MomAndPopsBaitAndTackle.com off a virtual server in a mammoth web hoster, you may never even know that your site is now available over IPv6. Set some intermediate goals: 50%, 80%, 93%, 98%, 99.6%. Do we define penetration by number of hosts reachable by IPv6, or number of bits passed over IPv6, or number of IPv6 flows? Lee From warren at wholesaleinternet.com Thu Oct 29 11:25:34 2009 From: warren at wholesaleinternet.com (Warren Johnson) Date: Thu, 29 Oct 2009 10:25:34 -0500 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <294122.28437.qm@web63302.mail.re1.yahoo.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com><443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com><4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <80208C10D5BB470680C6D97BF952446C@johnsonvhjjf8v> <294122.28437.qm@web63302.mail.re1.yahoo.com> Message-ID: I'm not certain we can even set goals. I think the market will tell us when we've reached the goal because the noise will quiet down to a low level. When major residential internet providers are receiving a much-lower amount of calls from people saying "I can't get to such-and-such website, what's up??" then we'll know we've hit a milestone. I reckon there's going to be a lot of tech support calls that go like this "Hi, this is Warren, I'm a customer of your cable company and I can't seem to get to the following sites......." -----Original Message----- From: Lee Howard [mailto:spiffnolee at yahoo.com] Sent: Thursday, October 29, 2009 10:16 AM To: Warren Johnson; Owen DeLong; Lee Dilkie Cc: ARIN-PPML at arin.net Subject: Re: [arin-ppml] v4 to v6 obstacles > I think that 80% number is misleading. You're talking 80% because > these > guys have a lot of content, not because they have a lot of websites. > The other 20% could be comprised of literally 10s or 100s of million > websites, all of which also need to be accessible to everyone for the > transition to be a success. Just because I can get to the top 50 > websites on the internet doesn't mean that I don't need access to the > other 500 million (or whatever the number is). Yes, there's a long tail. But several of the largest companies hosting those long-tail websites have also declared IPv6 plans. If you run www.MomAndPopsBaitAndTackle.com off a virtual server in a mammoth web hoster, you may never even know that your site is now available over IPv6. Set some intermediate goals: 50%, 80%, 93%, 98%, 99.6%. Do we define penetration by number of hosts reachable by IPv6, or number of bits passed over IPv6, or number of IPv6 flows? Lee From owen at delong.com Thu Oct 29 11:57:38 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Oct 2009 08:57:38 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <80208C10D5BB470680C6D97BF952446C@johnsonvhjjf8v> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com><443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com><4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <80208C10D5BB470680C6D97BF952446C@johnsonvhjjf8v> Message-ID: If the top 50 web sites make it to IPv6 dual-stack, then, that's probably enough for the rest of the web to decide they'll start playing catch-up, frankly. I'm not sure what the critical mass of web sites and other services on dual- stack is for eye-ball ISPs to start issuing IPv6-only customers once IPv4 becomes difficult, but, I'm betting that as IPv6 deployment grows and IPv4 depletion passes, the difficulty of issuing IPv4 addresses will increase and the threshold of acceptability of IPv6-only will continue to drop until some point where those values meet. Owen On Oct 29, 2009, at 5:25 AM, Warren Johnson wrote: > I think that 80% number is misleading. You're talking 80% because > these > guys have a lot of content, not because they have a lot of > websites. The > other 20% could be comprised of literally 10s or 100s of million > websites, > all of which also need to be accessible to everyone for the > transition to be > a success. Just because I can get to the top 50 websites on the > internet > doesn't mean that I don't need access to the other 500 million (or > whatever > the number is). > > >>> >> Agreed. That is why I put a ? on the 80%. If some really big and >> important players (applications) go dual stack, that covers a lot of >> territory. > > You mean like: > > Google > Yahoo > MSN > > (All of whom have publicly announced dual stack plans)? > > Owen > > _______________________________________________ > 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 owen at delong.com Thu Oct 29 12:00:04 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Oct 2009 09:00:04 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <28E139F46D45AF49A31950F88C49745803D24418@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803D24418@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Oct 29, 2009, at 5:51 AM, wrote: >>> Agreed. That is why I put a ? on the 80%. If some really big and >>> important players (applications) go dual stack, that covers >> a lot of >>> territory. >> >> You mean like: >> >> Google >> Yahoo >> MSN >> >> (All of whom have publicly announced dual stack plans)? > > This is meaningless. > No, it really isn't... > It is one thing to "go dual stack" on your core network > architecture that rarely grows in number of devices, and > which has enough spare IPv4 addresses in existing blocks > to last another 5 years. But it is an entirely different > thing to "go dual stack" on an edge architecture that is > continuosly growing and which need an infusion of new > IPv4 addresses every 6 months to handle growth. > Uh, those three have publicly committed to having IPv6-enabled services for end-users. That's not just their core, that's their web servers, load balancers, etc. The whole 9 yards, as it were. That's not meaningless, it's major progress. The more content producers that make it to full dual-stack functionality before IPv4 runout, the better. If enough get there, then, IPv6-only eyeballs won't be such a bad thing as current speculation seems to think. Owen From cgrundemann at gmail.com Thu Oct 29 12:34:58 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 29 Oct 2009 10:34:58 -0600 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call In-Reply-To: References: <4AE89034.8040301@arin.net> <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> Message-ID: <443de7ad0910290934gf3397c3tdeb70653aedce016@mail.gmail.com> On Thu, Oct 29, 2009 at 09:05, George, Wes E [NTK] wrote: > > I support this policy as written. > > I'm struggling with Owen's recommended change a bit. I wasn't in favor of it at the meeting, but I'm trying to keep an open mind. I believe that the general spirit of the recommended changes is to remove as many barriers as possible to deployment of IPv6 by making it very easy to qualify for IPv6 space. I support that in principle. However, I don't understand why direct PI allocations are a requirement for networks of this size vs. simply getting PD space from an upstream. We're talking about networks which do not believe they can put together a plan that passes the red-face test that they will have 200 customers within 5 years. What drives the need for PI space in this case? Having had to personally renumber hundreds of end sites when we deprecated 6bone, I don't view having to renumber if you change providers as a barrier in a network this small (sorry). So that leaves multihoming... > Section 6 of the NRPM has no references at all to multihoming. Perhaps that's a problem, given its prevalence in the sections on IPv4. > I would be in support of something that adds a reference to being multihomed in the criteria as justification for PI space, rather than a reduction in the number of end sites. IPv6 address space is mindbogglingly big, so I know that talk about trying to be prudent in our use of it will largely be shouted down, but I'll say it anyway. This maybe goes a bit too far. I like this idea. Advance the current policy as revised and start work on a new pp to add a multihome policy to section 6. ~Chris > > To ask a related question - why would big ISPs need huge blocks (/32-29 or larger) if nearly all of their downstreams can qualify for a PI block either as an end user or an LIR? If we really want nearly everyone to be able to qualify for space directly from ARIN, perhaps we should be looking to move away from the PD model entirely, and leave ISPs to allocate only infrastructure blocks and dynamic end hosts (mobile devices, homes, etc)? I'm not trying to start a discussion about routing table explosion here, so let's leave that on the sidelines for now. I'm simply asking because that's the general direction I see this going if we continue to make it easier for direct allocations from ARIN. Is that the aim? > > Thanks > Wes George > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jim Weyand > Sent: Thursday, October 29, 2009 9:28 AM > To: Owen DeLong; Member Services > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call > > +1 - As a very small ISP I am sure we can say that we are planning on > 200 or 250 IPv6 sites but the reality is more likely to be less. > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, October 28, 2009 6:54 PM > To: Member Services > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last > Call > > I feel that we should include in this policy as it goes to the board a > reduction in the 200 site requirement to 100 sites. ?I feel that the > community > supported that modification in general and in the show of hands. > > I encourage the advisory council to consider this modification as the > proposal comes out of last call before handing it off to the board. > > I encourage others present on this list to express support for this > idea if they > feel it should be done. > > Owen > (Speaking only as an individual interested in improving policy and not > in > my role as a member of the AC) > > > On Oct 28, 2009, at 11:40 AM, Member Services wrote: > >> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to >> send a revised version of the following draft policy to last call: >> >> ? Draft Policy 2009-7: Open Access To IPv6 >> >> The AC met in accordance with the ARIN Policy Development Process >> which >> requires the AC to meet within 30 days of the conclusion of the Public >> Policy Meeting to make decisions about the draft policies that had >> been >> presented. The AC revised the draft. The draft policy is now limited >> to >> removing the IPv6 routing requirement from current policy. It does not >> change the initial IPv6 allocation criteria. However, the AC stated >> they >> intend to continue to work on that issue. >> >> Feedback is encouraged during this last call period. All comments >> should >> be provided to the Public Policy Mailing List. This last call will >> expire on 13 November 2009. After last call the AC will conduct their >> last call review. >> >> The draft policy text is below and available at: >> https://www.arin.net/policy/proposals/ >> >> The ARIN Policy Development Process is available at: >> https://www.arin.net/policy/pdp.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy 2009-7 >> Open Access To IPv6 >> >> Version/Date: 28 October 2009 >> >> Policy statement: >> >> Remove "by advertising that connectivity through its single aggregated >> address allocation" from article 3 of section 6.5.1.1 >> >> Rationale: >> >> Removing the requirement for a single aggregate announcement benefits >> the NRPM itself, as it has been decided by the community that it >> should >> not contain routing advice. >> >> Timetable for implementation: immediately upon BoT ratification >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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. > _______________________________________________ > 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. > > > This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From scottleibrand at gmail.com Thu Oct 29 12:42:48 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 29 Oct 2009 09:42:48 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <28E139F46D45AF49A31950F88C49745803D241FF@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803D241FF@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <06C5FE2A-38EC-47BA-A0EF-A3BAFBBE8552@gmail.com> Reusing the same ULA prefix would defeat the purpose (Uniqueness). Better to have the ISPs do random prefix generations for their clients. Scott On Oct 29, 2009, at 4:13 AM, wrote: >> Many people >> mistake the fact that NAT requires a stateful inspection >> gateway to function for security being provided by NAT. The >> security is not provided by NAT, it is provided by stateful >> inspection" > > Why not redefine IPv6 NAT to be Network Access Taming (or some > other T word) which carries out basic stateful inspection > functions? Demand that vendors supply this stateful inspection > in all routers and network access gateway boxes with the > default setting of "turned ON". > >> NAT >> allows you to utilize private network addresses for ALL your >> internal devices.... which makes them unaccessable to >> external traffic BY DEFAULT...and then allows you to assign >> public IP's to ONLY those devices which are intended to be >> externaly accessible. > > IPv6 with ULA allows you to utilise private network addresses > etc., etc... > >> 2) NAT allows Network Admins the flexability to organize >> thier own private address space and the assignment of IP's in >> ways that logicaly make sense to them. > > IPv6 with ULA allows.... > >> 3) NAT allows you to abstract your internal infrastructure >> from the external services you present. This has alot of >> utility. > > IPv6 with ULA allows.... > > Perhaps every ISP should define a ULA /48 and then reuse that > for every customer's internal addressing. In other words, > instead of asking every customer to figure out ULA and > allocate their own ULA /48, the ISP would say, "Here, just > use this prefix for all your private addressing and use > this other one for interfaces which need to be publicly > accessible for incoming calls". It wouldn't even matter > if a smart user, reused that ULA for their friends networks > on another ISP, or published it in a magazine article > resulting in thousands of sites thinking that ULA /48 > is the IPv6 private address range. > > We really need more articles published covering experiences. > > --Michael Dillon > _______________________________________________ > 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 cengel at sponsordirect.com Thu Oct 29 13:01:52 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 29 Oct 2009 13:01:52 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: Message-ID: I'm going to be very upfront with you guys. Without confidence that something very similar to NAT will be available for IPv6.... I'm going to eschew any adoption of IPv6 on the networks I'm responsible for. I guess that would also entail...grabbing, hoarding and stockpiling as many IPv4 addresses as possible that might be required for future use. If you think my reaction is atypical for the Network/System/IT admins on corporate side end user networks.... I think you are going to be in for a rude awakening. You are going to start seeing alot more of this type behavior as awareness of the details of IPv6 increases in that population. The number one way to INSURE resistance to the adoption of a new technology is to REMOVE FUNCTIONALITY that people already enjoy under their existing functionality. I believe that is the exact opposite reaction toward IPv6 that most people on this list would like to see occur. It is pretty much IRRELEVANT that some people find NAT problematic or unusefull. Those of us who do rely on it...and there are many...obviously find it useful. On the other hand....the best way to promote the adoption of a new technology is to make transition to it as SEAMLESS as possible....meaning the absolute MINIMUM number of changes in end user behavior or functionality required to make it work. IPv6 has ZERO utility for me other then the possibility of allowing a few more public addresses if I need them. Changing the abstraction of my internal network would actually be a significant NEGATIVE. Changing fundamentally the design architecture on my internal network and the operating procedures necessary to manage it would be a significant NEGATIVE. There would already a HUGE amount of work and cost involved in just setting up the ability for end users to connect to IPv6 addresses....for frankly NEGLIGIBLE benefit (at least initially). There is already a fairly strong chance that the initial adopters of IPv6 only addresses are going to be balkanized from many existing (IPv4) sites due the cost/benefit ratio of implementing IPv6 for many organizations. Placing more hurdles and disincentives then are necessary for Network Admins to support interoperability with IPv6 sites on thier networks is NOT going to help that. That's all I'm saying. Whether ARIN's role or policies would effect that equation.... I would have no clue. Certainly anything policy wise that would bar or preclude some sort of IPv6 NAT adoption would be detrimental.... and certainly being aware of such issues/concerns in it's planning in regard to IPv6 would be helpful...I would think. Christopher Engel From matthew at matthew.at Thu Oct 29 13:00:33 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 29 Oct 2009 10:00:33 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com><443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com><4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <80208C10D5BB470680C6D97BF952446C@johnsonvhjjf8v> Message-ID: <4AE9CA31.50401@matthew.at> Owen DeLong wrote: > If the top 50 web sites make it to IPv6 dual-stack, then, that's > probably enough > for the rest of the web to decide they'll start playing catch-up, > frankly. I'm not > sure what the critical mass of web sites and other services on > dual-stack is for > eye-ball ISPs to start issuing IPv6-only customers once IPv4 becomes > difficult, > but, I'm betting that as IPv6 deployment grows and IPv4 depletion passes, > the difficulty of issuing IPv4 addresses will increase and the > threshold of > acceptability of IPv6-only will continue to drop until some point > where those > values meet. If the top 50 web sites are dual-stack, then dual-stack customers whose IPv4 comes via NAT will have happy ISPs, as the NAT doesn't need to work nearly as hard if the top 50 destinations don't go through it. But the ISPs will still need those NATs to reach the IPv4 Internet (assuming, of course, that we really ever run out of purchasable address space) But my prediction is that "IPv6-only" will *never* be acceptable to customers except in specialized circumstances (customers who are attaching a specific device that is IPv6-capable that they only need to reach from the IPv6 Internet) or if IPv6-to-IPv4 translation is perfected to the point where an IPv6-only user can still reach the entire IPv4 Internet that still exists. (But even the latter is painful, as to talk to your local printer you bought last year you need IPv4 enabled on your hosts anyway and so dual-stack from your ISP is really much more likely to work properly for reaching the IPv4 Internet) Matthew Kaufman From matthew at matthew.at Thu Oct 29 13:07:56 2009 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 29 Oct 2009 10:07:56 -0700 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <74793.47478.qm@web63303.mail.re1.yahoo.com> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <4AE91EF5.6030201@matthew.at> <705270.55338.qm@web63304.mail.re1.yahoo.com> <4AE92995.40107@matthew.at> <74793.47478.qm@web63303.mail.re1.yahoo.com> Message-ID: <4AE9CBEC.6030805@matthew.at> Lee Howard wrote: >>> IPv6 is cheaper (for the ISP, who doesn't have to pass the expense on to you) >>> > > >> than large-scale NAT. >> >>> >>> >> But since they need to provide it *anyway* in order to give me dual-stack (which >> > > Large-scale NAT is only required after runout, and only for connections over IPv4. > Agreed, assuming that enough IPv4 addresses can't be found via transfer "after runout". I think the real answer is that it becomes needed after the *real* runout, which is after holders of IPv4 who don't really need it (see all the companies with legacy class A and class B space for their internal nets who NAT all of them to the outside world anyway) sell it to people who can use it more effectively. > More IPv6 traffic means few NAT boxes. > Agreed. Which reduces ISP cost... something most users don't care about. (And it doesn't help that $19 multi-megabit service and $0 dialup are so common that the users are trained to not cover ISP costs anyway) > >>>> On those days when, for whatever reason, the IPv6 >>>> is down... I don't even notice until I happen to see it in the logs. >>>> >>> That's the goal! If you can't tell the difference, then that's a success! >>> >> Actually that's the *problem*. If I can't tell the difference, then there's no >> reason for me to demand IPv6 *or* for my provider to give it to me. >> > > Maybe we have different goals. My goal is to provide connectivity to my > customers. IPv6 is a tool to do that, not an end in itself. > Sure. But you'll still need to provide them with IPv4 (NAT or not), perhaps forever. > >> IF it is possible to continue indefinitely providing dual-stack (NAT or >> otherwise for the IPv4), THEN it is possible to continue indefinitely *not* >> providing IPv6 at all. >> >> Until there's an application for which I *can* tell the difference, in a big >> way. >> > > Does anything break when it goes through two layers of NAT (i.e., > home gateway NAT and CGN, a.k.a. NAT444)? Several of the > widely used NAT traversal systems assume a single NAT layer; not > sure how VoIP, online gaming, p2p will work with NAT444 (or, if > the other endpoint is also NAT444, you have NAT44444). > All NAT traversal systems currently fail in some NAT scenarios and must resort to relaying the traffic. The percentage might change as more NAT is deployed, but end-users don't usually care about this problem either. (When was the last time you used Skype and actually checked to see whether your VoIP was going over TCP vs. UDP, much less whether it was being relayed via some far-away university network or not?) Matthew Kaufman From dlw+arin at tellme.com Thu Oct 29 13:05:55 2009 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 29 Oct 2009 10:05:55 -0700 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call In-Reply-To: References: <4AE89034.8040301@arin.net> <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> Message-ID: <20091029170554.GE18310@shell02.cell.sv2.tellme.com> On Thu, Oct 29, 2009 at 10:05:09AM -0500, George, Wes E [NTK] wrote: > I'm struggling with Owen's recommended change a bit. I wasn't in favor of it at the meeting, but I'm trying to keep an open mind. I believe that the general spirit of the recommended changes is to remove as many barriers as possible to deployment of IPv6 by making it very easy to qualify for IPv6 space. I support that in principle. However, I don't understand why direct PI allocations are a requirement for networks of this size vs. simply getting PD space from an upstream. We're talking about networks which do not believe they can put together a plan that passes the red-face test that they will have 200 customers within 5 years. What drives the need for PI space in this case? Having had to personally renumber hundreds of end sites when we deprecated 6bone, I don't view having to renumber if you change providers as a barrier in a network this small (sorry). So that leaves multihoming... The NRPM spends a bunch of text defining terms in section 6.2, but nowhere does it define "customer". There's some allusions to users, but I think the common reading of it in this context is persons or organizations who buy transit services from the LIR/ISP. That definition is why there's a need for the PI policy, and why there is a need to look at the arbitrary 200 customer number. I agree with most of your above statements in the context of small to large transit ISPs. There are, however, non-transit service providers (like my employer) that have legitimate need for our own address space. We simply cannot use reassigned PA space. And I disagree with your assertion that renumbering is easy. It can be, but many enterprises have substantial VPN infrastructures, and changing the configs of your portners devices to accomodate a renumbering is a manpower expense that trivially justifies the ongoing cost of your own space. Furthermore, we simply do not qualify as an LIR, and we don't have any transit customers, which makes the 200 number seem very large indeed. > Section 6 of the NRPM has no references at all to multihoming. Perhaps that's a problem, given its prevalence in the sections on IPv4. On this, I entirely concur. If you are going to be singlehomed, please don't use a routing slot, and please just use PA. > I would be in support of something that adds a reference to being multihomed in the criteria as justification for PI space, rather than a reduction in the number of end sites. IPv6 address space is mindbogglingly big, so I know that talk about trying to be prudent in our use of it will largely be shouted down, but I'll say it anyway. This maybe goes a bit too far. Makes sense to me. But the original discussion is really about LIRs, which won't be getting PI space anyway. > To ask a related question - why would big ISPs need huge blocks (/32-29 or larger) if nearly all of their downstreams can qualify for a PI block either as an end user or an LIR? If we really want nearly everyone to be able to qualify for space directly from ARIN, perhaps we should be looking to move away from the PD model entirely, and leave ISPs to allocate only infrastructure blocks and dynamic end hosts (mobile devices, homes, etc)? I'm not trying to start a discussion about routing table explosion here, so let's leave that on the sidelines for now. I'm simply asking because that's the general direction I see this going if we continue to make it easier for direct allocations from ARIN. Is that the aim? 'cause not every org needs to be multihomed. :-) (See my comment above.) The hard problem here is where to set the arbitrary customer number. We don't want to create a swamp. (Really, I just don't want Jason's basement to have it's own /32.) On the other hand, we don't want to discourage adoption. The 200 number seems a tad high, but that's just gut instinct, and not backed by any data. I think I'd be in favor of a new PP that changes the number to 100. I would prefer to detach that from the draft as it is currently written, though. -David From michael.dillon at bt.com Thu Oct 29 13:16:07 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 29 Oct 2009 17:16:07 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <06C5FE2A-38EC-47BA-A0EF-A3BAFBBE8552@gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745803D248EE@E03MVZ2-UKDY.domain1.systemhost.net> > Reusing the same ULA prefix would defeat the purpose (Uniqueness). > Better to have the ISPs do random prefix generations for > their clients. How often does difficulty in merging the network of consumer A and the network of consumer B, have a chance of scuttling the merger, or have a material impact on the financial terms of the merger? As far as I can see it, in divorce and remarriage situations, the network topology is not even relevant. Therefore ULA uniqueness serves no purpose to consumers. And probably very little purpose for small businesses as well. Now look on the ISP side? Uniqueness means one more thing to track and one more thing to go wrong when configuring a new customer or repairing a customer fault. In this case, having one ULA prefix to be used for all customers' private internal addressing is a good thing. It's best that they don't use the same ULA prefix as the ISP down the road, but no big catastrophe if they do. It's a different thing when it comes to the internal private addressing of the ISP's own network, where they definitely should generate their own random prefix according to RFC 4193, or if that is too confusing, just go to plug in a MAC address from one of the routers, and click Generate. Register it as well for good measure. Note that my comments about reusing a ULA, only applies to the internal customer infrastructure (prefixes longer than /48) in those customers where the ISP sets things up, and the customer leaves it alone. Savvy tech customer will, of course, generate their own unique ULA in preparation for that day, 10 years down the road, when they are bought out by Huawei-Cisco or CTC-Verizon. --Michael Dillon From spiffnolee at yahoo.com Thu Oct 29 13:32:29 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 29 Oct 2009 10:32:29 -0700 (PDT) Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE9CBEC.6030805@matthew.at> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <4AE91EF5.6030201@matthew.at> <705270.55338.qm@web63304.mail.re1.yahoo.com> <4AE92995.40107@matthew.at> <74793.47478.qm@web63303.mail.re1.yahoo.com> <4AE9CBEC.6030805@matthew.at> Message-ID: <56100.57994.qm@web63305.mail.re1.yahoo.com> > > Large-scale NAT is only required after runout, and only for connections over > > IPv4. > > > Agreed, assuming that enough IPv4 addresses can't be found via transfer "after > runout". I think the real answer is that it becomes needed after the *real* > runout, which is after holders of IPv4 who don't really need it (see all the > companies with legacy class A and class B space for their internal nets who NAT > all of them to the outside world anyway) sell it to people who can use it more > effectively. Do you think there will be enough IPv4 addresses available via transfer to cover the annual growth of the Internet in the region? Will those addresses be cheaper or more expensive than large-scale NAT? (my guesses: not even close, and much more expensive) > > More IPv6 traffic means few NAT boxes. > > > Agreed. Which reduces ISP cost... something most users don't care about. (And it > doesn't help that $19 multi-megabit service and $0 dialup are so common that the > users are trained to not cover ISP costs anyway) Are you suggesting that pricing has no correlation to cost of goods? > >>> That's the goal! If you can't tell the difference, then that's a success! > >> Actually that's the *problem*. If I can't tell the difference, then there's > >>no reason for me to demand IPv6 *or* for my provider to give it to me. > > > > Maybe we have different goals. My goal is to provide connectivity to my > > customers. IPv6 is a tool to do that, not an end in itself. > > > Sure. But you'll still need to provide them with IPv4 (NAT or not), perhaps > forever. Sorry, I didn't follow your logic. You say: Without an IPv6 killer app, you (as a consumer) don't care about IPv6. Your ISP is going to give it to you anyway, to avoid LSN costs. But there will still be some LSN cost, and therefore. . . IPv6 will never happen? > > Does anything break when it goes through two layers of NAT (i.e., home gateway > > NAT and CGN, a.k.a. NAT444)? Several of the widely used NAT traversal systems > > assume a single NAT layer; not > > sure how VoIP, online gaming, p2p will work with NAT444 (or, if > > the other endpoint is also NAT444, you have NAT44444). > All NAT traversal systems currently fail in some NAT scenarios and must resort > to relaying the traffic. The percentage might change as more NAT is deployed, > but end-users don't usually care about this problem either. (When was the last > time you used Skype and actually checked to see whether your VoIP was going over > TCP vs. UDP, much less whether it was being relayed via some far-away university > network or not?) It sounds like you're saying, "No problem, the applications will find ways to work around LSN breakage." But why is LSN workaround easier than IPv6? I'm really trying to understand what you're arguing for or against. It sounds like you're saying: After ARIN can't fulfill IPv4 requests, ISPs will buy address transfers for an extended period of time. Only once the transfer market is drained will ISPs deploy Large-Scale NAT. LSN will work so well that nobody will ever need or use IPv6. Here's what I'm saying: Paying for space in a transfer market will be expensive. Large-Scale NAT will be expensive, but maybe not as expensive. LSN may break some applications. LSN use can be reduced (eliminated?) by using IPv6. IPv6 is cheap. Deployment of IPv6 requires project planning and a bit of engineering; about the same amount as LSN. As more traffic uses IPv6, the network effect increases the value of using IPv6; it becomes ever cheaper and more useful. Therefore, to avoid LSN, everyone should run IPv6 before IPv4 runout. IOW: Choosing among Good, Fast, Cheap: Buying space: fast LSN: cheaper IPv6: good, cheap Lee From Lee at Dilkie.com Thu Oct 29 13:37:27 2009 From: Lee at Dilkie.com (Lee Dilkie) Date: Thu, 29 Oct 2009 13:37:27 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE9CA31.50401@matthew.at> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com><443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com><4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <80208C10D5BB470680C6D97BF952446C@johnsonvhjjf8v> <4AE9CA31.50401@matthew.at> Message-ID: <4AE9D2D7.6070803@Dilkie.com> Matthew Kaufman wrote: > Owen DeLong wrote: >> If the top 50 web sites make it to IPv6 dual-stack, then, that's >> probably enough >> for the rest of the web to decide they'll start playing catch-up, >> frankly. I'm not >> sure what the critical mass of web sites and other services on >> dual-stack is for >> eye-ball ISPs to start issuing IPv6-only customers once IPv4 becomes >> difficult, >> but, I'm betting that as IPv6 deployment grows and IPv4 depletion >> passes, >> the difficulty of issuing IPv4 addresses will increase and the >> threshold of >> acceptability of IPv6-only will continue to drop until some point >> where those >> values meet. > If the top 50 web sites are dual-stack, then dual-stack customers > whose IPv4 comes via NAT will have happy ISPs, as the NAT doesn't need > to work nearly as hard if the top 50 destinations don't go through it. > But the ISPs will still need those NATs to reach the IPv4 Internet > (assuming, of course, that we really ever run out of purchasable > address space) > > But my prediction is that "IPv6-only" will *never* be acceptable to > customers except in specialized circumstances (customers who are > attaching a specific device that is IPv6-capable that they only need > to reach from the IPv6 Internet) or if IPv6-to-IPv4 translation is > perfected to the point where an IPv6-only user can still reach the > entire IPv4 Internet that still exists. (But even the latter is > painful, as to talk to your local printer you bought last year you > need IPv4 enabled on your hosts anyway and so dual-stack from your ISP > is really much more likely to work properly for reaching the IPv4 > Internet) I disagree. At some point the ISP will offer "v6 only" because most folks can get the job done due to the number of dual-stack servers out there. If you happen to need v4 connectivity to connect to some second rate server that hasn't gone dual-stack, then it's very likely the ISP will offer v4 addresses for a premium price (or/and natted already). The minute that happens, Owen's prediction will happen very fast, a lot of catch up will occur. What business wants to outright reject all new net customers? I think you can count on porn sites going dual stack quickly! ;) -lee From Lee at Dilkie.com Thu Oct 29 13:48:34 2009 From: Lee at Dilkie.com (Lee Dilkie) Date: Thu, 29 Oct 2009 13:48:34 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <4AE9D572.6080608@Dilkie.com> Sorry for top-posting but it's not important to answer your concerns on a point by point basis. I've heard this from a lot of IT admins and even from my own company's IT admins. But the fact is, you are not the problem. Companies, like yours, do not use all that many v4 addresses today. They have nice, profitable, v4 address blocks from an ISP and are well managed entities. You can stay with v4 for a very long time. No, I think what we're after is getting the major consumers, ISP's for public consumption, to move dual then eventually v6 only. And for that, all we need is to get a good number of the servers they connect to, to go dual stack. And yes, while you'll still be running v4 inside and using some small v4 public address block, you'll very likely run dual stack on your public internet-facing servers to allow the new "v6 only" customers to see your wares. And that effort is a *lot* easier and cheaper than rolling out v6 in your entire enterprise. -lee Chris Engel wrote: > I'm going to be very upfront with you guys. Without confidence that something very similar to NAT will be available for IPv6.... I'm going to eschew any adoption of IPv6 on the networks I'm responsible for. I guess that would also entail...grabbing, hoarding and stockpiling as many IPv4 addresses as possible that might be required for future use. > > If you think my reaction is atypical for the Network/System/IT admins on corporate side end user networks.... I think you are going to be in for a rude awakening. You are going to start seeing alot more of this type behavior as awareness of the details of IPv6 increases in that population. > > > The number one way to INSURE resistance to the adoption of a new technology is to REMOVE FUNCTIONALITY that people already enjoy under their existing functionality. I believe that is the exact opposite reaction toward IPv6 that most people on this list would like to see occur. > > It is pretty much IRRELEVANT that some people find NAT problematic or unusefull. Those of us who do rely on it...and there are many...obviously find it useful. > > On the other hand....the best way to promote the adoption of a new technology is to make transition to it as SEAMLESS as possible....meaning the absolute MINIMUM number of changes in end user behavior or functionality required to make it work. > > IPv6 has ZERO utility for me other then the possibility of allowing a few more public addresses if I need them. Changing the abstraction of my internal network would actually be a significant NEGATIVE. Changing fundamentally the design architecture on my internal network and the operating procedures necessary to manage it would be a significant NEGATIVE. There would already a HUGE amount of work and cost involved in just setting up the ability for end users to connect to IPv6 addresses....for frankly NEGLIGIBLE benefit (at least initially). > > There is already a fairly strong chance that the initial adopters of IPv6 only addresses are going to be balkanized from many existing (IPv4) sites due the cost/benefit ratio of implementing IPv6 for many organizations. Placing more hurdles and disincentives then are necessary for Network Admins to support interoperability with IPv6 sites on thier networks is NOT going to help that. > > > That's all I'm saying. Whether ARIN's role or policies would effect that equation.... I would have no clue. Certainly anything policy wise that would bar or preclude some sort of IPv6 NAT adoption would be detrimental.... and certainly being aware of such issues/concerns in it's planning in regard to IPv6 would be helpful...I would think. > > > > Christopher Engel > _______________________________________________ > 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 micah at riseup.net Thu Oct 29 14:04:48 2009 From: micah at riseup.net (Micah Anderson) Date: Thu, 29 Oct 2009 14:04:48 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE91EF5.6030201@matthew.at> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <4AE91EF5.6030201@matthew.at> Message-ID: <20091029180448.GZ18278@pond.riseup.net> * Matthew Kaufman [2009-10-29 00:50-0400]: > Owen DeLong wrote: > > When there's an answer to that question more exciting than "the > turtle dances when you go to kame.net", people will care and demand > IPv6. Until then, why would they bother? Most everything I do is done in such a way so that people have absolutely no idea that I've done it. My goal is to seamlessly make necessary transitions to technologies without having to justify some new carrot to the users in order to do it. I don't want IPv6 because I'll get a dancing turtle, the dancing turtle just tells me that I got it working. > I've had every desktop in my house IPv6-enabled for over a year. > I've experienced absolutely no difference, except for a few sites > that are a bit slower to reach as a result. On those days when, for > whatever reason, the IPv6 is down... I don't even notice until I > happen to see it in the logs. Sounds like you are running from a tunnel broker, with variable instability. I don't think it is fair to blame IPv6 for issues you've had with a tunnel provider. micah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jweyand at computerdata.com Thu Oct 29 14:14:10 2009 From: jweyand at computerdata.com (Jim Weyand) Date: Thu, 29 Oct 2009 14:14:10 -0400 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call References: <4AE89034.8040301@arin.net> <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> <443de7ad0910290934gf3397c3tdeb70653aedce016@mail.gmail.com> Message-ID: <1582DCBFF968F044A9A910C0AB177C90461467@cliff.cdi.local> So then you are proposing that just because an ISP is small today, it should always and forever be stuck with the same upstream provider in an IPv6 world? That makes it tough to negotiate better terms with that provider. Or, even worse, if that provider pulls a Northpoint and pulls out of region or goes out of business the ISP has an even bigger problem. Even at the risk of allocating a /32 to Jason's basement (and remember, at some point, Jason still has to pay his ARIN fees so he probably is not doing this just for grins) this seems very anti-competitive. For these business reasons I oppose adding a requirement for multi-homing. Jim Weyand -----Original Message----- From: Chris Grundemann [mailto:cgrundemann at gmail.com] Sent: Thursday, October 29, 2009 12:35 PM To: George, Wes E [NTK] Cc: Jim Weyand; Owen DeLong; Member Services; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call On Thu, Oct 29, 2009 at 09:05, George, Wes E [NTK] wrote: > > I support this policy as written. > > I'm struggling with Owen's recommended change a bit. I wasn't in favor of it at the meeting, but I'm trying to keep an open mind. I believe that the general spirit of the recommended changes is to remove as many barriers as possible to deployment of IPv6 by making it very easy to qualify for IPv6 space. I support that in principle. However, I don't understand why direct PI allocations are a requirement for networks of this size vs. simply getting PD space from an upstream. We're talking about networks which do not believe they can put together a plan that passes the red-face test that they will have 200 customers within 5 years. What drives the need for PI space in this case? Having had to personally renumber hundreds of end sites when we deprecated 6bone, I don't view having to renumber if you change providers as a barrier in a network this small (sorry). So that leaves multihoming... > Section 6 of the NRPM has no references at all to multihoming. Perhaps that's a problem, given its prevalence in the sections on IPv4. > I would be in support of something that adds a reference to being multihomed in the criteria as justification for PI space, rather than a reduction in the number of end sites. IPv6 address space is mindbogglingly big, so I know that talk about trying to be prudent in our use of it will largely be shouted down, but I'll say it anyway. This maybe goes a bit too far. I like this idea. Advance the current policy as revised and start work on a new pp to add a multihome policy to section 6. ~Chris > > To ask a related question - why would big ISPs need huge blocks (/32-29 or larger) if nearly all of their downstreams can qualify for a PI block either as an end user or an LIR? If we really want nearly everyone to be able to qualify for space directly from ARIN, perhaps we should be looking to move away from the PD model entirely, and leave ISPs to allocate only infrastructure blocks and dynamic end hosts (mobile devices, homes, etc)? I'm not trying to start a discussion about routing table explosion here, so let's leave that on the sidelines for now. I'm simply asking because that's the general direction I see this going if we continue to make it easier for direct allocations from ARIN. Is that the aim? > > Thanks > Wes George > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jim Weyand > Sent: Thursday, October 29, 2009 9:28 AM > To: Owen DeLong; Member Services > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call > > +1 - As a very small ISP I am sure we can say that we are planning on > 200 or 250 IPv6 sites but the reality is more likely to be less. > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, October 28, 2009 6:54 PM > To: Member Services > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last > Call > > I feel that we should include in this policy as it goes to the board a > reduction in the 200 site requirement to 100 sites. ?I feel that the > community > supported that modification in general and in the show of hands. > > I encourage the advisory council to consider this modification as the > proposal comes out of last call before handing it off to the board. > > I encourage others present on this list to express support for this > idea if they > feel it should be done. > > Owen > (Speaking only as an individual interested in improving policy and not > in > my role as a member of the AC) > > > On Oct 28, 2009, at 11:40 AM, Member Services wrote: > >> The ARIN Advisory Council (AC) met on 23 October 2009 and decided to >> send a revised version of the following draft policy to last call: >> >> ? Draft Policy 2009-7: Open Access To IPv6 >> >> The AC met in accordance with the ARIN Policy Development Process >> which >> requires the AC to meet within 30 days of the conclusion of the Public >> Policy Meeting to make decisions about the draft policies that had >> been >> presented. The AC revised the draft. The draft policy is now limited >> to >> removing the IPv6 routing requirement from current policy. It does not >> change the initial IPv6 allocation criteria. However, the AC stated >> they >> intend to continue to work on that issue. >> >> Feedback is encouraged during this last call period. All comments >> should >> be provided to the Public Policy Mailing List. This last call will >> expire on 13 November 2009. After last call the AC will conduct their >> last call review. >> >> The draft policy text is below and available at: >> https://www.arin.net/policy/proposals/ >> >> The ARIN Policy Development Process is available at: >> https://www.arin.net/policy/pdp.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy 2009-7 >> Open Access To IPv6 >> >> Version/Date: 28 October 2009 >> >> Policy statement: >> >> Remove "by advertising that connectivity through its single aggregated >> address allocation" from article 3 of section 6.5.1.1 >> >> Rationale: >> >> Removing the requirement for a single aggregate announcement benefits >> the NRPM itself, as it has been decided by the community that it >> should >> not contain routing advice. >> >> Timetable for implementation: immediately upon BoT ratification >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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. > _______________________________________________ > 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. > > > This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From jmaimon at chl.com Thu Oct 29 14:21:15 2009 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 29 Oct 2009 14:21:15 -0400 Subject: [arin-ppml] v4 to v6 obstacles In-Reply-To: <4AE9CBEC.6030805@matthew.at> References: <8aeeaff60910262225x5a48b0adne4faafcc891b7009@mail.gmail.com> <4AE6F275.7060006@chl.com> <395061.64110.qm@web63302.mail.re1.yahoo.com> <4AE89CE2.3020907@Dilkie.com> <4AE8AA60.6090001@chl.com> <443de7ad0910281450i67f9f06fg962749062bd46169@mail.gmail.com> <4AE8D2E4.8080200@dilkie.com> <8E7E63F5-87DC-4CCA-BAEC-102120EB8E89@delong.com> <4AE91EF5.6030201@matthew.at> <705270.55338.qm@web63304.mail.re1.yahoo.com> <4AE92995.40107@matthew.at> <74793.47478.qm@web63303.mail.re1.yahoo.com> <4AE9CBEC.6030805@matthew.at> Message-ID: <4AE9DD1B.8020407@chl.com> Matthew Kaufman wrote: > Agreed, assuming that enough IPv4 addresses can't be found via transfer > "after runout". I think the real answer is that it becomes needed after > the *real* runout, which is after holders of IPv4 who don't really need > it (see all the companies with legacy class A and class B space for > their internal nets who NAT all of them to the outside world anyway) > sell it to people who can use it more effectively. You dont have to pick on the legacy holders. Any provider of residential style access service can probably switch 80%+ of their userbase to rfc1918 and charge for the rest. Any large organization who has a history of being generous before depletion will have plenty available after the beancounters step in. It wont be these organizations who need transfers. From Wesley.E.George at sprint.com Thu Oct 29 14:32:53 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 29 Oct 2009 13:32:53 -0500 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call In-Reply-To: <1582DCBFF968F044A9A910C0AB177C90461467@cliff.cdi.local> References: <4AE89034.8040301@arin.net> <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> <443de7ad0910290934gf3397c3tdeb70653aedce016@mail.gmail.com> <1582DCBFF968F044A9A910C0AB177C90461467@cliff.cdi.local> Message-ID: -----Original Message----- From: Jim Weyand [mailto:jweyand at computerdata.com] Sent: Thursday, October 29, 2009 2:14 PM To: Chris Grundemann; George, Wes E [NTK] Cc: Owen DeLong; Member Services; arin-ppml at arin.net Subject: RE: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call So then you are proposing that just because an ISP is small today, it should always and forever be stuck with the same upstream provider in an IPv6 world? [weg] I'm not saying that at all. At its core, we're trying to modify the definition of what an ISP is, at least as it relates to whether they should get PI space. I'm simply saying that a small ISP should either be a) multihomed or b) large enough to have a credible plan to support 200+ customers over 5 years in order to justify PI space. Which provider(s) you choose to use and how often you change them is not really my concern. I'm not saying renumbering is not a barrier, but by definition we're talking about a network with less than 200 (or 100) end sites, meaning that it's less of an impact. That makes it tough to negotiate better terms with that provider. Or, even worse, if that provider pulls a Northpoint and pulls out of region or goes out of business the ISP has an even bigger problem. [weg] Those both sound like a fantastic justification for not being single-homed, not for getting PI space. You're still in a world of hurt if your *only* ISP goes TU. Having PI space just means that you have an address block to route when you find another provider. Even at the risk of allocating a /32 to Jason's basement (and remember, at some point, Jason still has to pay his ARIN fees so he probably is not doing this just for grins) this seems very anti-competitive. For these business reasons I oppose adding a requirement for multi-homing. Jim Weyand This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From alh-ietf at tndh.net Thu Oct 29 14:04:36 2009 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 29 Oct 2009 11:04:36 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: <0f1a01ca58c2$46dbf380$d493da80$@net> Chris, Check out RFC 4864, as it specifically discusses the objectives people have for using nat beyond address conservation, and provides IPv6 alternatives that don't mangle the header. I agree with your premise that people will want to continue doing what they do today, because they are busy and don't really want to figure out a new approach to solving an old problem. The point of 4864 is to present the alternatives and remove the need for repetitive searching for a solution. While the authors spent most of the time trying to collect all the uses people believe they need a nat for, there is no assumption that this is a complete list. If you have use cases that are not covered, please say so, and we will work on an update to be more comprehensive. Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Engel > Sent: Wednesday, October 28, 2009 1:06 PM > To: 'Paul G. Timmins'; Joe Maimon; Chris Grundemann > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > Paul, > > > Respectfully, that is because for the vast majority of Network/System > Admins IPv6 and the details of it's implementation are barely a blip on > the radar screen....if that. > > I can attest that NAT is a tool which see's extensive use among said > Admins...and NOT simply because one cannot obtain enough public IP > addresses. As I believe I have illustrated...it has a variety of useful > functionality for us. I can assure you that if something in IPv6 does > not offer the equivalent functionality to that which NAT currently > provides for IPV4 and in a similarly convenient manner.....you are > going to hear a VERY loud wailing and gnashing of teeth from this > population. > > I'm sure that is a sound that will resonate with equipment vendors. > However without some confidence that some sort of NAT66 solution will > be provided (or nearly identical functionality can be > achieved).....your going to see alot of resistance in this population > to IPv6 adoption. > > If you want people to actually be SUPPORTIVE of that adoption rather > then RESISTANT then you have to provide some assurance that the tools > they are used to working with to solve real problems will be available > in some form.....or at the very least a substitute that achieves > equivalent functionality and is easily translatable. > > > > > > > "Taking this to its logical conclusion, it's not necessary for > community consensus to implement NAT66. If people demand it, and > equipment vendors want to implement it, they will, and then will > standardize it after the fact, much like many other current standards > have been done. > > The fact that no such standard exists and no platform I'm aware of > implements NAT66 is pretty telling in and of itself. > > -Paul" > _______________________________________________ > 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 bill at herrin.us Thu Oct 29 14:40:18 2009 From: bill at herrin.us (William Herrin) Date: Thu, 29 Oct 2009 14:40:18 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE9D572.6080608@Dilkie.com> References: <4AE9D572.6080608@Dilkie.com> Message-ID: <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> On Thu, Oct 29, 2009 at 1:48 PM, Lee Dilkie wrote: > And yes, while you'll still be running v4 inside and using some small v4 > public address block, you'll very likely run dual stack on your public > internet-facing servers to allow the new "v6 only" customers to see your > wares. Lee, What would possibly motivate me to do such a thing to my smoothly running servers? The non-existent IPv6 only users I'm ignoring? The entertainment value in trying to chase down multihomable addresses that all the ISPs route? The rewarding experience when the IPv6-enabled applications on my and other dual-stacked systems try and fail to communicate with IPv6 even though a perfectly good IPv4 path is available? The warm fuzzy feeling I get for having done a good deed by slitting my corporate throat? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Wesley.E.George at sprint.com Thu Oct 29 14:51:41 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 29 Oct 2009 13:51:41 -0500 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call In-Reply-To: <20091029170554.GE18310@shell02.cell.sv2.tellme.com> References: <4AE89034.8040301@arin.net> <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> <20091029170554.GE18310@shell02.cell.sv2.tellme.com> Message-ID: -----Original Message----- From: David Williamson [mailto:dlw+arin at tellme.com] Sent: Thursday, October 29, 2009 1:06 PM To: George, Wes E [NTK] Cc: Jim Weyand; Owen DeLong; Member Services; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call There are, however, non-transit service providers(like my employer) that have legitimate need for our own address space. We simply cannot use reassigned PA space. [weg] I would expect that you would qualify under 6.5.8 (previously discussed issues with 6.5.8.1.b notwithstanding). This policy is specific to 6.5.1, which is for LIRs. It's possible that multihoming needs to be referenced both places, I don't know. And I disagree with your assertion that renumbering is easy. It can be, but many enterprises have substantial VPN infrastructures, and changing the configs of your portners devices to accomodate a renumbering is a manpower expense that trivially justifies the ongoing cost of your own space. Furthermore, we simply do not qualify as an LIR, and we don't have any transit customers, which makes the 200 number seem very large indeed. [weg] Again, ARIN has a separate section for non-LIR allocations. I'm not saying renumbering is easy. I'm saying that I've done it on a network larger than this 200 end-site requirement, and it's workable, and in my mind it's not a good enough justification on its own for waiving the requirement in order for small networks to get PI space. If it is, then no one should ever get PD space, hence my comments later in my message. It's always going to be a line in the sand, but I'd bet that even if we set it at 100, someone's going to complain because they have to renumber their 99-site network, and that's too hard. ;-) > Section 6 of the NRPM has no references at all to multihoming. Perhaps that's a problem, given its prevalence in the sections on IPv4. On this, I entirely concur. If you are going to be singlehomed, please don't use a routing slot, and please just use PA. > I would be in support of something that adds a reference to being multihomed in the criteria as justification for PI space, rather than a reduction in the number of end sites. IPv6 address space is mindbogglingly big, so I know that talk about trying to be prudent in our use of it will largely be shouted down, but I'll say it anyway. This maybe goes a bit too far. Makes sense to me. But the original discussion is really about LIRs, which won't be getting PI space anyway. [weg] I'm not following you. Did you mean PD? -David This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From cengel at sponsordirect.com Thu Oct 29 14:56:19 2009 From: cengel at sponsordirect.com (Chris Engel) Date: Thu, 29 Oct 2009 14:56:19 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <4AE9D572.6080608@Dilkie.com> Message-ID: Lee, I'm not sure it's that simple. If the corporate network admins don't role out some sort IPv6 stack internaly (and probably some software upgrades too) then how would thier end users reach any IPv6 only site? If IPv6 isn't bound to the end users NIC cards....how are they going to get to an IPv6 only site? I assume that means there has to be some sort of IPv6 network created internaly....even if it's not really used for much else. Furthermore....knowing what I do about the speed of adoption of client software and OS in the corporate world....I am assuming that there will likely be some need for upgrades of certain client software in order to work with an IPv6 address as a destination. Furthermore, if there is alot of resistence to such implementations.... who, on the other side of the equation is going to want an IPv6 address....if it means that alot of people aren't reaching it? I can't see many businesses on the other side of the equation jumping through hoops to impliment an IPv6 address if they think a good chunk of people won't be able to access it. Frankly I'd see them more likely jumping through hoops to make thier existing IPv4 addresses work....or find a way to obtain more in some sort of after market. Maybe if you get some important early adopters willing to take the risk to go IPv6 address only (which is going to be a tall order in itself)...you can force the hands of the rest of us to come along and put in support for it localy, probably kicking and screaming.... but it's going to be an UGLY, UGLY scene.... if there aren't some serious efforts to address the legitimate concerns raised. Christopher Engel -----Original Message----- From: Lee Dilkie [mailto:Lee at Dilkie.com] Sent: Thursday, October 29, 2009 12:49 PM To: Chris Engel Cc: 'arin-ppml at arin.net' Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern Sorry for top-posting but it's not important to answer your concerns on a point by point basis. I've heard this from a lot of IT admins and even from my own company's IT admins. But the fact is, you are not the problem. Companies, like yours, do not use all that many v4 addresses today. They have nice, profitable, v4 address blocks from an ISP and are well managed entities. You can stay with v4 for a very long time. No, I think what we're after is getting the major consumers, ISP's for public consumption, to move dual then eventually v6 only. And for that, all we need is to get a good number of the servers they connect to, to go dual stack. And yes, while you'll still be running v4 inside and using some small v4 public address block, you'll very likely run dual stack on your public internet-facing servers to allow the new "v6 only" customers to see your wares. And that effort is a *lot* easier and cheaper than rolling out v6 in your entire enterprise. -lee Chris Engel wrote: > I'm going to be very upfront with you guys. Without confidence that > something very similar to NAT will be available for IPv6.... I'm going > to eschew any adoption of IPv6 on the networks I'm responsible for. I > guess that would also entail...grabbing, hoarding and stockpiling as > many IPv4 addresses as possible that might be required for future use. > > If you think my reaction is atypical for the Network/System/IT admins > on corporate side end user networks.... I think you are going to be in > for a rude awakening. You are going to start seeing alot more of this > type behavior as awareness of the details of IPv6 increases in that > population. > > > The number one way to INSURE resistance to the adoption of a new > technology is to REMOVE FUNCTIONALITY that people already enjoy under > their existing functionality. I believe that is the exact opposite > reaction toward IPv6 that most people on this list would like to see > occur. > > It is pretty much IRRELEVANT that some people find NAT problematic or > unusefull. Those of us who do rely on it...and there are > many...obviously find it useful. > > On the other hand....the best way to promote the adoption of a new > technology is to make transition to it as SEAMLESS as > possible....meaning the absolute MINIMUM number of changes in end user > behavior or functionality required to make it work. > > IPv6 has ZERO utility for me other then the possibility of allowing a > few more public addresses if I need them. Changing the abstraction of > my internal network would actually be a significant NEGATIVE. Changing > fundamentally the design architecture on my internal network and the > operating procedures necessary to manage it would be a significant > NEGATIVE. There would already a HUGE amount of work and cost involved > in just setting up the ability for end users to connect to IPv6 > addresses....for frankly NEGLIGIBLE benefit (at least initially). > > There is already a fairly strong chance that the initial adopters of > IPv6 only addresses are going to be balkanized from many existing > (IPv4) sites due the cost/benefit ratio of implementing IPv6 for many > organizations. Placing more hurdles and disincentives then are > necessary for Network Admins to support interoperability with IPv6 > sites on thier networks is NOT going to help that. > > > That's all I'm saying. Whether ARIN's role or policies would effect > that equation.... I would have no clue. Certainly anything policy wise > that would bar or preclude some sort of IPv6 NAT adoption would be > detrimental.... and certainly being aware of such issues/concerns in > it's planning in regard to IPv6 would be helpful...I would think. > > > > Christopher Engel _______________________________________________ > 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 owen at delong.com Thu Oct 29 14:56:25 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Oct 2009 11:56:25 -0700 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call In-Reply-To: References: <4AE89034.8040301@arin.net> <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> <443de7ad0910290934gf3397c3tdeb70653aedce016@mail.gmail.com> <1582DCBFF968F044A9A910C0AB177C90461467@cliff.cdi.local> Message-ID: On Oct 29, 2009, at 11:32 AM, George, Wes E [NTK] wrote: > > -----Original Message----- > From: Jim Weyand [mailto:jweyand at computerdata.com] > Sent: Thursday, October 29, 2009 2:14 PM > To: Chris Grundemann; George, Wes E [NTK] > Cc: Owen DeLong; Member Services; arin-ppml at arin.net > Subject: RE: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - > Last Call > > So then you are proposing that just because an ISP is small today, > it should always and forever be stuck with the same upstream > provider in an IPv6 world? > > [weg] I'm not saying that at all. At its core, we're trying to > modify the definition of what an ISP is, at least as it relates to > whether they should get PI space. I'm simply saying that a small ISP > should either be a) multihomed or b) large enough to have a credible > plan to support 200+ customers over 5 years in order to justify PI > space. Which provider(s) you choose to use and how often you change > them is not really my concern. I'm not saying renumbering is not a > barrier, but by definition we're talking about a network with less > than 200 (or 100) end sites, meaning that it's less of an impact. > > That makes it tough to negotiate better terms with that provider. > Or, even worse, if that provider pulls a Northpoint and pulls out of > region or goes out of business the ISP has an even bigger problem. > > [weg] Those both sound like a fantastic justification for not being > single-homed, not for getting PI space. You're still in a world of > hurt if your *only* ISP goes TU. Having PI space just means that you > have an address block to route when you find another provider. > That's a pretty major advantage when you have 7 days notice or less that you need to migrate your entire AS to some other connectivity. (which has historical precedent) Owen From lar at mwtcorp.net Thu Oct 29 14:33:12 2009 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Thu, 29 Oct 2009 12:33:12 -0600 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: I've tried to be quiet but I can't any more. Sorry > > I'm going to be very upfront with you guys. Without confidence that >something very similar to NAT will be available for IPv6.... I'm going to >eschew any adoption of IPv6 on the networks I'm responsible for. I guess >that would also entail...grabbing, hoarding and stockpiling as many IPv4 >addresses as possible that might be required for future use. > > If you think my reaction is atypical for the Network/System/IT admins on >corporate side end user networks.... I think you are going to be in for a >rude awakening. You are going to start seeing alot more of this type >behavior as awareness of the details of IPv6 increases in that population. > > > The number one way to INSURE resistance to the adoption of a new >technology is to REMOVE FUNCTIONALITY that people already enjoy under their >existing functionality. I believe that is the exact opposite reaction >toward IPv6 that most people on this list would like to see occur. > > It is pretty much IRRELEVANT that some people find NAT problematic or >unusefull. Those of us who do rely on it...and there are many...obviously >find it useful. I hate to say this but I'm exactly on the opposite side. NAsTy has been so broken with so many different implementations many of which cause great harm that the end of NAsTy is the greatest single advantage I see in IPV6. Those of you that are proud of your NAsTy implementation don't sit in the seat of those of us that have to spend valuable time and resources trying to keep things working. If IPV6 is to have NAsTy then the engineers need to lock it down so that applications can tell what and how many NAsTy boxes were in the path and demand that they leave the payload be AND their should be a place where those of us that have to deal with the effects of it can bill those of you that love it for our time and trouble. OR everyone could just use the methods that have been engineered into IPV6 to make IPV4 type NAsTy unnecessary. I wonder if we don't have a bit of a "I won't buy a car until they make a place to hook my horse onto it" thing going on here. A lot of very big names have servers behind NAT that causes customer problems and they don't even know it because the customer call's their ISP and complains instead of calling MR.BIGGUY. > > On the other hand....the best way to promote the adoption of a new >technology is to make transition to it as SEAMLESS as possible....meaning >the absolute MINIMUM number of changes in end user behavior or >functionality required to make it work. > > IPv6 has ZERO utility for me other then the possibility of allowing a few >more public addresses if I need them. Changing the abstraction of my >internal network would actually be a significant NEGATIVE. Changing >fundamentally the design architecture on my internal network and the >operating procedures necessary to manage it would be a significant >NEGATIVE. There would already a HUGE amount of work and cost involved in >just setting up the ability for end users to connect to IPv6 >addresses....for frankly NEGLIGIBLE benefit (at least initially). > > There is already a fairly strong chance that the initial adopters of IPv6 >only addresses are going to be balkanized from many existing (IPv4) sites >due the cost/benefit ratio of implementing IPv6 for many organizations. >Placing more hurdles and disincentives then are necessary for Network >Admins to support interoperability with IPv6 sites on thier networks is NOT >going to help that. > > > That's all I'm saying. Whether ARIN's role or policies would effect that >equation.... I would have no clue. Certainly anything policy wise that >would bar or preclude some sort of IPv6 NAT adoption would be >detrimental.... and certainly being aware of such issues/concerns in it's >planning in regard to IPv6 would be helpful...I would think. > > > > Christopher Engel > _______________________________________________ > 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. Larry Ash Network Administrator Mountain West Telephone 400 East 1st St. Casper, WY 82601 Office 307 233-8387 From scottleibrand at gmail.com Thu Oct 29 18:49:36 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 29 Oct 2009 15:49:36 -0700 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <3c3e3fca0910221525v546aa3c9l461c5469c3ab5aa3@mail.gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> <3c3e3fca0910221503y115d6d8du5f0a4a41d6ff7f16@mail.gmail.com> <4AE0D906.60105@gmail.com> <3c3e3fca0910221525v546aa3c9l461c5469c3ab5aa3@mail.gmail.com> Message-ID: <4AEA1C00.30408@gmail.com> William Herrin wrote: > On Thu, Oct 22, 2009 at 6:13 PM, Scott Leibrand wrote: > >> William Herrin wrote: >> >>> 1. If I request a /16 and you tell me you only have a /18, what's to >>> stop me from saying "Okay, give me the /18" and then two days later >>> saying, "Okay, put me on the wait list for a /16." >>> >> The policy attempts to address that, in a deliberately vague statement that >> "Repeated requests, in a manner that would >> circumvent 4.1.6, are not allowed." The idea, of course, is to give ARIN >> staff leeway to use their excellent fraud detection skills, combined with >> operational procedures that can be adjusted as needed. >> > > Staff will be making such decisions under intense scrutiny. Any > judgment they're forced to exercise will tend to be the most lenient > the policy allows. Which is to say: no restriction on repeat requests > at all. > > Giving staff discretion can be a good thing if done with appropriate > checks, but you also have to give them a policy vehicle that validates > and reinforces that discretion. In other words, it's better to say, > "You can have 1 a day but staff can waive the requirement" than "you > can have as many as you want but staff can limit you to 1 a day." > Understood. Do you have any specific suggestions as to how we could modify proposal 97 to codify a restriction, while still giving staff leeway to make exception for anyone who is clearly not trying to bend any rules? > >>> 2. How is giving me the /18 fair to the guy who is on the waiting list >>> for a /17? There's no guidance in the policy as to how ARIN is >>> supposed to build up enough addresses to satisfy that /17 request. >>> >> My take on this is similar to what Warren just posted. Basically, if the >> /17 holder will settle for a /18, he can change his request to be for the >> smaller size, and he'll be in the list before you. If he wants to hold out >> for that /17 to be returned, he's welcome to. But more than likely, he'll >> go find his own /17 on the transfer market before that. >> > > Most likely he'll take the /18 and then go find a bunch of /24's on > the transfer market. Which defeats the purpose both of having a > waiting list and of trying to build to aggregation. That's why it > concerns me. I don't believe that finding a bunch of /24s on the transfer market will be allowed. We'll find out more details soon when ARIN staff releases their implementation plan, but the policy says that the recipient of transferred space must "demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies." Does that address your concern? -Scott From bill at herrin.us Thu Oct 29 19:17:37 2009 From: bill at herrin.us (William Herrin) Date: Thu, 29 Oct 2009 19:17:37 -0400 Subject: [arin-ppml] Post-exhaustion IPv4 policy In-Reply-To: <4AEA1C00.30408@gmail.com> References: <4AE0B4DE.7070607@chl.com> <3c3e3fca0910221426v12759399k9bb9885c12a8455c@mail.gmail.com> <4AE0D048.7080608@gmail.com> <3c3e3fca0910221503y115d6d8du5f0a4a41d6ff7f16@mail.gmail.com> <4AE0D906.60105@gmail.com> <3c3e3fca0910221525v546aa3c9l461c5469c3ab5aa3@mail.gmail.com> <4AEA1C00.30408@gmail.com> Message-ID: <3c3e3fca0910291617p1e135dadoa0480203bbbf702a@mail.gmail.com> On Thu, Oct 29, 2009 at 6:49 PM, Scott Leibrand wrote: > William Herrin wrote: >> >> On Thu, Oct 22, 2009 at 6:13 PM, Scott Leibrand >> wrote: >>> "Repeated requests, in a manner that would >>> circumvent 4.1.6, are not allowed." ?The idea, of course, is to give ARIN >>> staff leeway to use their excellent fraud detection skills, combined with >>> operational procedures that can be adjusted as needed. >>> >> >> Staff will be making such decisions under intense scrutiny. Any >> judgment they're forced to exercise will tend to be the most lenient >> the policy allows. Which is to say: no restriction on repeat requests >> at all. >> >> Giving staff discretion can be a good thing if done with appropriate >> checks, but you also have to give them a policy vehicle that validates >> and reinforces that discretion. In other words, it's better to say, >> "You can have 1 a day but staff can waive the requirement" than "you >> can have as many as you want but staff can limit you to 1 a day." >> > > Understood. ?Do you have any specific suggestions as to how we could modify > proposal 97 to codify a restriction, while still giving staff leeway to make > exception for anyone who is clearly not trying to bend any rules? Hi Scott, Tough question. How about something like a 1-year waiting period between requests but the BoT is empowered to waive the waiting period by majority vote for any individual requests they deem meritorious by whatever criteria. Of course waiving the waiting period doesn't grant the request; it just means that staff can consider it before the waiting period expires. > I don't believe that finding a bunch of /24s on the transfer market will be > allowed. ?We'll find out more details soon when ARIN staff releases their > implementation plan, but the policy says that the recipient of transferred > space must "demonstrate the need for such resources, as a single aggregate, > in the exact amount which they can justify under current ARIN policies." > > Does that address your concern? If I have 1000 computers, I can justify a /24 today, another /24 tomorrow and a /23 the day after that. It depends only on how many hosts my multiply revised plans each put behind a NAT or define as "not connected full-time." I'm not all that strongly concerned about this one. If we start to see abuse, the character of the abuse should also provide the solution before terribly much disaggregation occurs. May want to think about publishing information about transfers in a way that helps identify the bad actors, kind of like the CIDR report does overall for BGP. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Thu Oct 29 20:26:39 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 29 Oct 2009 18:26:39 -0600 Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6 - Last Call In-Reply-To: <20091029170554.GE18310@shell02.cell.sv2.tellme.com> References: <4AE89034.8040301@arin.net> <1582DCBFF968F044A9A910C0AB177C90461459@cliff.cdi.local> <20091029170554.GE18310@shell02.cell.sv2.tellme.com> Message-ID: <443de7ad0910291726w5844f3edre9dd1e52eac8997a@mail.gmail.com> On Thu, Oct 29, 2009 at 11:05, David Williamson wrote: > On Thu, Oct 29, 2009 at 10:05:09AM -0500, George, Wes E [NTK] wrote: >> I'm struggling with Owen's recommended change a bit. I wasn't in favor of it at the meeting, but I'm trying to keep an open mind. I believe that the general spirit of the recommended changes is to remove as many barriers as possible to deployment of IPv6 by making it very easy to qualify for IPv6 space. I support that in principle. However, I don't understand why direct PI allocations are a requirement for networks of this size vs. simply getting PD space from an upstream. We're talking about networks which do not believe they can put together a plan that passes the red-face test that they will have 200 customers within 5 years. What drives the need for PI space in this case? Having had to personally renumber hundreds of end sites when we deprecated 6bone, I don't view having to renumber if you change providers as a barrier in a network this small (sorry). So that leaves multihoming... > > The NRPM spends a bunch of text defining terms in section 6.2, but > nowhere does it define "customer". ?There's some allusions to users, > but I think the common reading of it in this context is persons or > organizations who buy transit services from the LIR/ISP. ?That > definition is why there's a need for the PI policy, and why there > is a need to look at the arbitrary 200 customer number. > > I agree with most of your above statements in the context of small to > large transit ISPs. ?There are, however, non-transit service providers > (like my employer) that have legitimate need for our own address > space. ?We simply cannot use reassigned PA space. ?And I disagree with > your assertion that renumbering is easy. ?It can be, but many > enterprises have substantial VPN infrastructures, and changing the > configs of your portners devices to accomodate a renumbering is a > manpower expense that trivially justifies the ongoing cost of your own > space. ?Furthermore, we simply do not qualify as an LIR, and we don't > have any transit customers, which makes the 200 number seem very large > indeed. If you do not have any transit customers, would you need to be assigning space as an LIR? If the answer is no, then you should be looking at section 6.5.8. Direct assignments from ARIN to end-user organizations and not this 200 customer restriction which is in section 6.5.1.1. Initial allocation criteria which also specifically states that you are an LIR (it also states that you are an ISP, not just an SP). Maybe I am wrong but my impression is that a lot of the folks who want the 200 customer limit removed are not LIRs at all and should really be looking at the requirements for end-user assignments. I am sure I will be corrected if this impression is mistaken. > >> Section 6 of the NRPM has no references at all to multihoming. Perhaps that's a problem, given its prevalence in the sections on IPv4. > > On this, I entirely concur. ?If you are going to be singlehomed, please > don't use a routing slot, and please just use PA. > >> I would be in support of something that adds a reference to being multihomed in the criteria as justification for PI space, rather than a reduction in the number of end sites. IPv6 address space is mindbogglingly big, so I know that talk about trying to be prudent in our use of it will largely be shouted down, but I'll say it anyway. This maybe goes a bit too far. > > Makes sense to me. ?But the original discussion is really about LIRs, > which won't be getting PI space anyway. > >> To ask a related question - why would big ISPs need huge blocks (/32-29 or larger) if nearly all of their downstreams can qualify for a PI block either as an end user or an LIR? If we really want nearly everyone to be able to qualify for space directly from ARIN, perhaps we should be looking to move away from the PD model entirely, and leave ISPs to allocate only infrastructure blocks and dynamic end hosts (mobile devices, homes, etc)? I'm not trying to start a discussion about routing table explosion here, so let's leave that on the sidelines for now. I'm simply asking because that's the general direction I see this going if we continue to make it easier for direct allocations from ARIN. Is that the aim? > > 'cause not every org needs to be multihomed. :-) ?(See my comment above.) > > The hard problem here is where to set the arbitrary customer number. > We don't want to create a swamp. ?(Really, I just don't want Jason's > basement to have it's own /32.) ?On the other hand, we don't want to > discourage adoption. ?The 200 number seems a tad high, but that's just > gut instinct, and not backed by any data. ?I think I'd be in favor of a > new PP that changes the number to 100. ?I would prefer to detach that > from the draft as it is currently written, though. When we say that 200 customers is a tad high, let's not forget that a /32 contains over 65 thousand /48s. Not to mention the fact that despite ARIN policy setting usage requirements based on a /48, a /56 is probably adequate for many (if not most) end-users. Having a need for 200 out of 65 thousand does not seem like a stretch to me as a decent justification - however arbitrary it is. Also, we are not talking about 200 customers today - it says "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." Which means (to me at least) that if you are already an IPv4 LIR, you don't need to worry about the customer requirement at all and if you start up a new ISP you have to plan to take on 200 customers _over five years_ - I have worked at start-up ISPs in the past and our plans were always much higher than that, even in quite remote rural areas (and they all exceeded that number as well). All that being said - I am not totally against dropping the limit to 100, I just think that it should be discussed further as a separate policy (I am willing to be convinced but am not there yet). I also think that adding a multihoming section for IPv6 allocations, as Wes suggested, makes much better sense. ~Chris > > -David > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From mksmith at adhost.com Thu Oct 29 23:48:20 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Thu, 29 Oct 2009 20:48:20 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: Message-ID: Chris: You obviously have very strong opinions about +NAT, as many have strong opinions about -NAT. This is not the right venue to jump on that particular soap box. Might I suggest you take your arguments to the IETF? That's where these decisions are being made. In my opinion, ARIN is not going to be able to change your opinion about the usability of IPv6 in its present state based upon any updates to the NRPM. The v6ops group might be a good place to start. See http://www.ietf.org/dyn/wg/charter/v6ops-charter.html. Regards, Mike On 10/29/09 11:56 AM, "Chris Engel" wrote: > Lee, > > I'm not sure it's that simple. If the corporate network admins don't role out > some sort IPv6 stack internaly (and probably some software upgrades too) then > how would thier end users reach any IPv6 only site? If IPv6 isn't bound to > the end users NIC cards....how are they going to get to an IPv6 only site? > > I assume that means there has to be some sort of IPv6 network created > internaly....even if it's not really used for much else. > Furthermore....knowing what I do about the speed of adoption of client > software and OS in the corporate world....I am assuming that there will likely > be some need for upgrades of certain client software in order to work with an > IPv6 address as a destination. > > Furthermore, if there is alot of resistence to such implementations.... who, > on the other side of the equation is going to want an IPv6 address....if it > means that alot of people aren't reaching it? > > I can't see many businesses on the other side of the equation jumping through > hoops to impliment an IPv6 address if they think a good chunk of people won't > be able to access it. Frankly I'd see them more likely jumping through hoops > to make thier existing IPv4 addresses work....or find a way to obtain more in > some sort of after market. > > Maybe if you get some important early adopters willing to take the risk to go > IPv6 address only (which is going to be a tall order in itself)...you can > force the hands of the rest of us to come along and put in support for it > localy, probably kicking and screaming.... but it's going to be an UGLY, UGLY > scene.... if there aren't some serious efforts to address the legitimate > concerns raised. > > > > > > > > > > Christopher Engel > > -----Original Message----- > From: Lee Dilkie [mailto:Lee at Dilkie.com] > Sent: Thursday, October 29, 2009 12:49 PM > To: Chris Engel > Cc: 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > > Sorry for top-posting but it's not important to answer your concerns on a > point by point basis. > > I've heard this from a lot of IT admins and even from my own company's IT > admins. > > But the fact is, you are not the problem. Companies, like yours, do not use > all that many v4 addresses today. They have nice, profitable, v4 address > blocks from an ISP and are well managed entities. You can stay with v4 for a > very long time. > > No, I think what we're after is getting the major consumers, ISP's for public > consumption, to move dual then eventually v6 only. And for that, all we need > is to get a good number of the servers they connect to, to go dual stack. > > And yes, while you'll still be running v4 inside and using some small v4 > public address block, you'll very likely run dual stack on your public > internet-facing servers to allow the new "v6 only" customers to see your > wares. And that effort is a *lot* easier and cheaper than rolling out v6 in > your entire enterprise. > > -lee > > Chris Engel wrote: >> I'm going to be very upfront with you guys. Without confidence that >> something very similar to NAT will be available for IPv6.... I'm going >> to eschew any adoption of IPv6 on the networks I'm responsible for. I >> guess that would also entail...grabbing, hoarding and stockpiling as >> many IPv4 addresses as possible that might be required for future use. >> >> If you think my reaction is atypical for the Network/System/IT admins >> on corporate side end user networks.... I think you are going to be in >> for a rude awakening. You are going to start seeing alot more of this >> type behavior as awareness of the details of IPv6 increases in that >> population. >> >> >> The number one way to INSURE resistance to the adoption of a new >> technology is to REMOVE FUNCTIONALITY that people already enjoy under >> their existing functionality. I believe that is the exact opposite >> reaction toward IPv6 that most people on this list would like to see >> occur. >> >> It is pretty much IRRELEVANT that some people find NAT problematic or >> unusefull. Those of us who do rely on it...and there are >> many...obviously find it useful. >> >> On the other hand....the best way to promote the adoption of a new >> technology is to make transition to it as SEAMLESS as >> possible....meaning the absolute MINIMUM number of changes in end user >> behavior or functionality required to make it work. >> >> IPv6 has ZERO utility for me other then the possibility of allowing a >> few more public addresses if I need them. Changing the abstraction of >> my internal network would actually be a significant NEGATIVE. Changing >> fundamentally the design architecture on my internal network and the >> operating procedures necessary to manage it would be a significant >> NEGATIVE. There would already a HUGE amount of work and cost involved >> in just setting up the ability for end users to connect to IPv6 >> addresses....for frankly NEGLIGIBLE benefit (at least initially). >> >> There is already a fairly strong chance that the initial adopters of >> IPv6 only addresses are going to be balkanized from many existing >> (IPv4) sites due the cost/benefit ratio of implementing IPv6 for many >> organizations. Placing more hurdles and disincentives then are >> necessary for Network Admins to support interoperability with IPv6 >> sites on thier networks is NOT going to help that. >> >> >> That's all I'm saying. Whether ARIN's role or policies would effect >> that equation.... I would have no clue. Certainly anything policy wise >> that would bar or preclude some sort of IPv6 NAT adoption would be >> detrimental.... and certainly being aware of such issues/concerns in >> it's planning in regard to IPv6 would be helpful...I would think. >> >> >> >> Christopher Engel _______________________________________________ >> 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. >> > _______________________________________________ > 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 spiffnolee at yahoo.com Fri Oct 30 10:29:43 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 30 Oct 2009 07:29:43 -0700 (PDT) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> Message-ID: <139257.98318.qm@web63306.mail.re1.yahoo.com> [re: dual-stacking public-facing servers] > What would possibly motivate me to do such a thing to my smoothly > running servers? There's an interesting issue here between ISPs, who really need IPv6, and content providers. Presumably, you care about eyeballs reaching your site. Bearing in mind address consumers like mobile devices, smartgrid, and video devices: How long will IPv4 space be available by any means. How well will multiple layers of NAT44... work for your site? Supporting IPv6 on public servers may be as easy as adding an IPv6 VIP to your load balancer, a new entry in your firewall, and a AAAA record in your DNS. There are very few places where adding IPv6 might break something. There are some tough business decisions to be made, and if it turns into a game of chicken between ISPs and content providers, the transition will be ugly. I ask you, then: what would motivate you to provide IPv6 support on your servers? Lee From Jason.Weil at cox.com Fri Oct 30 10:22:17 2009 From: Jason.Weil at cox.com (Jason.Weil at cox.com) Date: Fri, 30 Oct 2009 10:22:17 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: References: Message-ID: I agree with Mike. As Tony Hain has already pointed out RFC4864's details for Local Network Protection is a great start. If Address Autonomy feature of 4864 does not solve the problem which is what is sounds like some in the enterprise space claim is needed then look at Address Independence as being specified in draft-mrw-behave-nat66-02. This IMO at least is a much better way to offer provider independence in the enterprise than what is done today with NAT44. Just for the record I firmly believe that NAT needs to be removed from the home network. RFC4864 in addition to GUA space when connected to a service provider offers a much richer solution in this environment. Jason -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. Smith Sent: Thursday, October 29, 2009 11:48 PM To: Chris Engel; 'Lee Dilkie' Cc: 'arin-ppml at arin.net' Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern Chris: You obviously have very strong opinions about +NAT, as many have strong opinions about -NAT. This is not the right venue to jump on that particular soap box. Might I suggest you take your arguments to the IETF? That's where these decisions are being made. In my opinion, ARIN is not going to be able to change your opinion about the usability of IPv6 in its present state based upon any updates to the NRPM. The v6ops group might be a good place to start. See http://www.ietf.org/dyn/wg/charter/v6ops-charter.html. Regards, Mike On 10/29/09 11:56 AM, "Chris Engel" wrote: > Lee, > > I'm not sure it's that simple. If the corporate network admins don't role out > some sort IPv6 stack internaly (and probably some software upgrades too) then > how would thier end users reach any IPv6 only site? If IPv6 isn't bound to > the end users NIC cards....how are they going to get to an IPv6 only site? > > I assume that means there has to be some sort of IPv6 network created > internaly....even if it's not really used for much else. > Furthermore....knowing what I do about the speed of adoption of client > software and OS in the corporate world....I am assuming that there will likely > be some need for upgrades of certain client software in order to work with an > IPv6 address as a destination. > > Furthermore, if there is alot of resistence to such implementations.... who, > on the other side of the equation is going to want an IPv6 address....if it > means that alot of people aren't reaching it? > > I can't see many businesses on the other side of the equation jumping through > hoops to impliment an IPv6 address if they think a good chunk of people won't > be able to access it. Frankly I'd see them more likely jumping through hoops > to make thier existing IPv4 addresses work....or find a way to obtain more in > some sort of after market. > > Maybe if you get some important early adopters willing to take the risk to go > IPv6 address only (which is going to be a tall order in itself)...you can > force the hands of the rest of us to come along and put in support for it > localy, probably kicking and screaming.... but it's going to be an UGLY, UGLY > scene.... if there aren't some serious efforts to address the legitimate > concerns raised. > > > > > > > > > > Christopher Engel > > -----Original Message----- > From: Lee Dilkie [mailto:Lee at Dilkie.com] > Sent: Thursday, October 29, 2009 12:49 PM > To: Chris Engel > Cc: 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > > Sorry for top-posting but it's not important to answer your concerns on a > point by point basis. > > I've heard this from a lot of IT admins and even from my own company's IT > admins. > > But the fact is, you are not the problem. Companies, like yours, do not use > all that many v4 addresses today. They have nice, profitable, v4 address > blocks from an ISP and are well managed entities. You can stay with v4 for a > very long time. > > No, I think what we're after is getting the major consumers, ISP's for public > consumption, to move dual then eventually v6 only. And for that, all we need > is to get a good number of the servers they connect to, to go dual stack. > > And yes, while you'll still be running v4 inside and using some small v4 > public address block, you'll very likely run dual stack on your public > internet-facing servers to allow the new "v6 only" customers to see your > wares. And that effort is a *lot* easier and cheaper than rolling out v6 in > your entire enterprise. > > -lee > > Chris Engel wrote: >> I'm going to be very upfront with you guys. Without confidence that >> something very similar to NAT will be available for IPv6.... I'm going >> to eschew any adoption of IPv6 on the networks I'm responsible for. I >> guess that would also entail...grabbing, hoarding and stockpiling as >> many IPv4 addresses as possible that might be required for future use. >> >> If you think my reaction is atypical for the Network/System/IT admins >> on corporate side end user networks.... I think you are going to be in >> for a rude awakening. You are going to start seeing alot more of this >> type behavior as awareness of the details of IPv6 increases in that >> population. >> >> >> The number one way to INSURE resistance to the adoption of a new >> technology is to REMOVE FUNCTIONALITY that people already enjoy under >> their existing functionality. I believe that is the exact opposite >> reaction toward IPv6 that most people on this list would like to see >> occur. >> >> It is pretty much IRRELEVANT that some people find NAT problematic or >> unusefull. Those of us who do rely on it...and there are >> many...obviously find it useful. >> >> On the other hand....the best way to promote the adoption of a new >> technology is to make transition to it as SEAMLESS as >> possible....meaning the absolute MINIMUM number of changes in end user >> behavior or functionality required to make it work. >> >> IPv6 has ZERO utility for me other then the possibility of allowing a >> few more public addresses if I need them. Changing the abstraction of >> my internal network would actually be a significant NEGATIVE. Changing >> fundamentally the design architecture on my internal network and the >> operating procedures necessary to manage it would be a significant >> NEGATIVE. There would already a HUGE amount of work and cost involved >> in just setting up the ability for end users to connect to IPv6 >> addresses....for frankly NEGLIGIBLE benefit (at least initially). >> >> There is already a fairly strong chance that the initial adopters of >> IPv6 only addresses are going to be balkanized from many existing >> (IPv4) sites due the cost/benefit ratio of implementing IPv6 for many >> organizations. Placing more hurdles and disincentives then are >> necessary for Network Admins to support interoperability with IPv6 >> sites on thier networks is NOT going to help that. >> >> >> That's all I'm saying. Whether ARIN's role or policies would effect >> that equation.... I would have no clue. Certainly anything policy wise >> that would bar or preclude some sort of IPv6 NAT adoption would be >> detrimental.... and certainly being aware of such issues/concerns in >> it's planning in regard to IPv6 would be helpful...I would think. >> >> >> >> Christopher Engel _______________________________________________ >> 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. >> > _______________________________________________ > 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. _______________________________________________ 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 bill at herrin.us Fri Oct 30 11:31:11 2009 From: bill at herrin.us (William Herrin) Date: Fri, 30 Oct 2009 11:31:11 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <139257.98318.qm@web63306.mail.re1.yahoo.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> Message-ID: <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> On Fri, Oct 30, 2009 at 10:29 AM, Lee Howard wrote: >?There are very few places > where adding IPv6 might break something. Lee, I'm not sure how you figure that. The moment I publish a AAAA record for my web site, your web browser on your IPv4/IPv6 dual-stacked machine will attempt to connect to that AAAA record in preference to any A records I've published, will it not? So if I'm using an ARIN /48 and you're using Verizon, your attempt to access my web server is going to hang with a retransmitting TCP SYN for a while before it falls back to looking up the A records. Same if I'm on one side of the IPv6 transit-free peering divide and you're on the other. The divide they've been talking about over on NANOG where just about everybody can get to HE but quite a few folks who can get to HE can't get to each other. Same if you happen to have been tinkering with 6to4, whose donated public relays are not especially well meshed with the IPv6 Internet backbone. Same if either of us is multihomed with IPv4 but only single-homed with IPv6 and the link that does IPv6 is malfunctioning. Same if IPv6 growing pains are causing a connectivity glitch at the moment. Same if the IPv6 deployment on your LAN is in an intermediate state where the machines have global-scope IPv6 addresses but don't yet have IPv6 connectivity to the world. They've been discussing the rogue RA problem over on NANOG too. With IPv6 turned on, I have to really depend on applications doing a smart job falling back to IPv4 when historically applications tend to do a poor job falling back to any second choice. And God help you if the first choice gave a wrong answer instead of failing to respond. Maybe it's just my COOP mindset, but it seems to me there are a lot of ways that adding IPv6 to my servers can disrupt their IPv4 operation. > I ask you, then: what would motivate you to provide IPv6 support > on your servers? Changes to all the software so that by default a dual stack system tries IPv4 first. That way I can adequately mitigate any risk from offering IPv6 as an initially second-class service. Or, of course, if a substantial enough deployment of IPv6-only users goes forward despite my own reluctance. But I'm easy to motivate: I'll invest vast amounts of time on systems of no immediate use merely because they interest me. Other people expect (gasp) a prompt ROI. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Fri Oct 30 11:42:46 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Oct 2009 08:42:46 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> Message-ID: <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> On Oct 30, 2009, at 8:31 AM, William Herrin wrote: > On Fri, Oct 30, 2009 at 10:29 AM, Lee Howard > wrote: >> There are very few places >> where adding IPv6 might break something. > > Lee, > > I'm not sure how you figure that. The moment I publish a AAAA record > for my web site, your web browser on your IPv4/IPv6 dual-stacked > machine will attempt to connect to that AAAA record in preference to > any A records I've published, will it not? > > So if I'm using an ARIN /48 and you're using Verizon, your attempt to > access my web server is going to hang with a retransmitting TCP SYN > for a while before it falls back to looking up the A records. Same if Not exactly... It will have already looked up the A records, but, when the connect() call returns ETIMEOUT, the loop will continue to iterate until connect() succeeds. Yes, the successive calls to connect() should use the IPv6 address first. Anyone on Verizon can resolve this by adding a free tunnel to HE. Additionally, HE is trying to work with Verizon to address an interim and more long term solutions to this issue. > I'm on one side of the IPv6 transit-free peering divide and you're on > the other. The divide they've been talking about over on NANOG where > just about everybody can get to HE but quite a few folks who can get > to HE can't get to each other. Same if you happen to have been > tinkering with 6to4, whose donated public relays are not especially > well meshed with the IPv6 Internet backbone. Same if either of us is That's actually gotten mostly better of late. Same with Teredo. > multihomed with IPv4 but only single-homed with IPv6 and the link that > does IPv6 is malfunctioning. Same if IPv6 growing pains are causing a > connectivity glitch at the moment. Same if the IPv6 deployment on your > LAN is in an intermediate state where the machines have global-scope > IPv6 addresses but don't yet have IPv6 connectivity to the world. > They've been discussing the rogue RA problem over on NANOG too. > This is one of the places that RA falls short. RA says "The router is up, it must be good for default." Would be nice if there was a way to get a router that can't actually get out to stop advertising an IPv6 default route in the RA. > With IPv6 turned on, I have to really depend on applications doing a > smart job falling back to IPv4 when historically applications tend to > do a poor job falling back to any second choice. And God help you if > the first choice gave a wrong answer instead of failing to respond. > The same is true if you have an IPv4 application hosted on multiple addresses and the first one is not working at the moment. > Maybe it's just my COOP mindset, but it seems to me there are a lot of > ways that adding IPv6 to my servers can disrupt their IPv4 operation. > There are a few, but, in reality, it's usually not a meaningful problem, and, as more and more things become dual-stacked, it will be less and less of a problem. I've been running dual-stack for several months now, and, frankly, have not noticed a significant number of degraded events. > >> I ask you, then: what would motivate you to provide IPv6 support >> on your servers? > > Changes to all the software so that by default a dual stack system > tries IPv4 first. That way I can adequately mitigate any risk from > offering IPv6 as an initially second-class service. > Actually, if you want to do that, for the most part, you only need to modify the getaddrinfo() library on your system. Most applications just iterate through the return from getaddrinfo() in the order of what it provided. > Or, of course, if a substantial enough deployment of IPv6-only users > goes forward despite my own reluctance. > That is inevitable. > Owen From spiffnolee at yahoo.com Fri Oct 30 12:23:19 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Fri, 30 Oct 2009 09:23:19 -0700 (PDT) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> Message-ID: <857357.57887.qm@web63306.mail.re1.yahoo.com> > The moment I publish a AAAA record > for my web site, your web browser on your IPv4/IPv6 dual-stacked > machine will attempt to connect to that AAAA record in preference to > any A records I've published, will it not? Yes. It seems to me that requesting AAAA records over IPv4 is a bad idea; at least one popular name server now has a now that when set, will only return AAAA to queries from IPv6 addresses. > So if I'm using an ARIN /48 and you're using Verizon, your attempt to > access my web server is going to hang with a retransmitting TCP SYN > for a while before it falls back to looking up the A records. Yes, if a host is dual-stacked but does not have IPv6 connectivity, then IPv6 access will fail. Under what conditions does this happen? > Same if > I'm on one side of the IPv6 transit-free peering divide and you're on > the other. The divide they've been talking about over on NANOG where > just about everybody can get to HE but quite a few folks who can get > to HE can't get to each other. Right. If you don't have IPv6 connectivity, then you can't connect via IPv6. This is not unique to IPv6. I should have included a Step 0: get good IPv6 transit. > Same if you happen to have been > tinkering with 6to4, whose donated public relays are not especially > well meshed with the IPv6 Internet backbone. I agree, 6to4 is in many cases poorly implemented, as are many of the other tunnel solutions. Google's response is to return AAAAs only if they have pretty high confidence that the client will have native IPv6. > Same if either of us is > multihomed with IPv4 but only single-homed with IPv6 and the link that > does IPv6 is malfunctioning. Same if IPv6 growing pains are causing a > connectivity glitch at the moment. Yes, if you don't have IPv6 connectivity, you can't connect over IPv6. > Same if the IPv6 deployment on your > LAN is in an intermediate state where the machines have global-scope > IPv6 addresses but don't yet have IPv6 connectivity to the world. Yes, if you don't have IPv6 connectivity, you can't connect over IPv6. That's a careless LAN administrator. > Maybe it's just my COOP mindset, but it seems to me there are a lot of > ways that adding IPv6 to my servers can disrupt their IPv4 operation. Nothing you've said describes interference with the operation of your servers. You've described several ways IPv6 connectivity may fail, none of which are inherent to IPv6. Step 0: Get good IPv6 connectivity. I'll work on my side if you'll work on your side. Actually, I'll work on my side anyway. > > I ask you, then: what would motivate you to provide IPv6 support > > on your servers? > > Changes to all the software so that by default a dual stack system > tries IPv4 first. That way I can adequately mitigate any risk from > offering IPv6 as an initially second-class service. As I'm sure you know, the conventional wisdom is that by preferring IPv6, traffic counters will provide compelling evidence to people like you that IPv6 support is required. And then those who assign addresses, when they see that 100% of traffic is IPv6, can silently stop assigning IPv4 addresses, and the Internet will have gracefully migrated. > Or, of course, if a substantial enough deployment of IPv6-only users > goes forward despite my own reluctance. Or maybe if your servers run an app that doesn't like multiple layers of NAT? > But I'm easy to motivate: I'll invest vast amounts of time on systems > of no immediate use merely because they interest me. Other people > expect (gasp) a prompt ROI. Fortunately, dual-stacking public-facing servers is pretty cheap and easy. There are parts of the Internet where dual-stacking will not be fast, and a prompt ROI will be impossible. Lee From info at arin.net Fri Oct 30 12:34:09 2009 From: info at arin.net (Member Services) Date: Fri, 30 Oct 2009 12:34:09 -0400 Subject: [arin-ppml] Policy Proposal 101: Multihomed initial allocation criteria Message-ID: <4AEB1581.8090607@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 101: Multihomed initial allocation criteria Proposal Originator: Chris Grundemann Proposal Version: 1 Date: 30 October 2009 Proposal type: modify Policy term: permanent Policy statement: Modify item number 4 under section 6.5.1.1. Initial allocation criteria to the following: 4. be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years or, if multihomed, demonstrate the efficient utilization of a minimum contiguous or noncontiguous /44 (sixteen /48s) from an upstream. Rationale: The bar for obtaining initial IPv4 allocations is lower for those ISPs which are multi-homed, it stands to reason that it also be lower in IPv6. Since efficient utilization is based on the use of /48s, this policy would effectively allow any ISP with 15 active customers (with one /48 each and one /48 for the ISPs own network) to receive an initial allocation of an IPv6 /32 from ARIN. I think this is a better approach than removing or lowering the end-site assignment requirement for _all_ ISPs while still providing more open access to IPv6. Timetable for implementation: immediate From JOHN at egh.com Fri Oct 30 12:47:47 2009 From: JOHN at egh.com (John Santos) Date: Fri, 30 Oct 2009 12:47:47 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern Message-ID: <1091030123109.40467B-100000@Ives.egh.com> On 30 Oct 2009 spiffnolee at yahoo.com wrote: > > > for my web site, your web browser on your IPv4/IPv6 dual-stacked > > machine will attempt to connect to that AAAA record in preference to > > any A records I've published, will it not? > > Yes. It seems to me that requesting AAAA records over IPv4 is > a bad idea; at least one popular name server now has a now that when > set, will only return AAAA to queries from IPv6 addresses. > > > So if I'm using an ARIN /48 and you're using Verizon, your attempt to > > access my web server is going to hang with a retransmitting TCP SYN > > for a while before it falls back to looking up the A records. > > Yes, if a host is dual-stacked but does not have IPv6 connectivity, then > IPv6 access will fail. Under what conditions does this happen? > > > Same if > > I'm on one side of the IPv6 transit-free peering divide and you're on > > the other. The divide they've been talking about over on NANOG where > > just about everybody can get to HE but quite a few folks who can get > > to HE can't get to each other. > > Right. If you don't have IPv6 connectivity, then you can't connect via > IPv6. This is not unique to IPv6. I should have included a Step 0: get > good IPv6 transit. > > > Same if you happen to have been > > tinkering with 6to4, whose donated public relays are not especially > > well meshed with the IPv6 Internet backbone. > > I agree, 6to4 is in many cases poorly implemented, as are many of the > other tunnel solutions. Google's response is to return AAAAs only if > they have pretty high confidence that the client will have native IPv6. > > > Same if either of us is > > multihomed with IPv4 but only single-homed with IPv6 and the link that > > does IPv6 is malfunctioning. Same if IPv6 growing pains are causing a > > connectivity glitch at the moment. > > Yes, if you don't have IPv6 connectivity, you can't connect over IPv6. > > > Same if the IPv6 deployment on your > > LAN is in an intermediate state where the machines have global-scope > > IPv6 addresses but don't yet have IPv6 connectivity to the world. > > Yes, if you don't have IPv6 connectivity, you can't connect over IPv6. > That's a careless LAN administrator. Why are you libeling me? You say I'm a careless if I turn on IPv6 on my LAN before my ISP offers IPv6 connectivity, so how the hell am I supposed to test whether our applications work with IPv6, as some of my customers are demanding? (By "our applications", I mean applications that we write for our customers. How are our programmers supposed to write network- agnostic applications without ever seeing an actual IPv6 network?) > > > Maybe it's just my COOP mindset, but it seems to me there are a lot of > > ways that adding IPv6 to my servers can disrupt their IPv4 operation. > > Nothing you've said describes interference with the operation of your > servers. You've described several ways IPv6 connectivity may fail, > none of which are inherent to IPv6. > > Step 0: Get good IPv6 connectivity. I'll work on my side if you'll > work on your side. Actually, I'll work on my side anyway. > I can't work on my side until my ISP offers IPv6, according to you. > > > I ask you, then: what would motivate you to provide IPv6 support > > > on your servers? > > > > Changes to all the software so that by default a dual stack system > > tries IPv4 first. That way I can adequately mitigate any risk from > > offering IPv6 as an initially second-class service. > > As I'm sure you know, the conventional wisdom is that by preferring > IPv6, traffic counters will provide compelling evidence to people like > you that IPv6 support is required. And then those who assign > addresses, when they see that 100% of traffic is IPv6, can silently > stop assigning IPv4 addresses, and the Internet will have gracefully > migrated. > > > Or, of course, if a substantial enough deployment of IPv6-only users > > goes forward despite my own reluctance. > > Or maybe if your servers run an app that doesn't like multiple layers > of NAT? > > > But I'm easy to motivate: I'll invest vast amounts of time on systems > > of no immediate use merely because they interest me. Other people > > expect (gasp) a prompt ROI. > > Fortunately, dual-stacking public-facing servers is pretty cheap and > easy. There are parts of the Internet where dual-stacking will not > be fast, and a prompt ROI will be impossible. > > Lee -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From michael.dillon at bt.com Fri Oct 30 13:39:31 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 30 Oct 2009 17:39:31 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <139257.98318.qm@web63306.mail.re1.yahoo.com> Message-ID: <28E139F46D45AF49A31950F88C49745803D867CA@E03MVZ2-UKDY.domain1.systemhost.net> > I ask you, then: what would motivate you to provide IPv6 > support on your servers? A nice packaged set of software that could be installed on a V4-V6 gateway box, or used to isolate a V4 virtual server within a V6 virtual machine shell. Both are possible today, but the people who are doing these things just haven't packaged it in a way that you can buy an x86 rackmount box, download an .ISO and install. Sure it would be nicer and neater if the IETF creates a replacement for NAT-PT, but that is basically a gateway box upgrade consideration. --Michael Dillon From michael.dillon at bt.com Fri Oct 30 13:50:34 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 30 Oct 2009 17:50:34 -0000 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> Message-ID: <28E139F46D45AF49A31950F88C49745803D867DA@E03MVZ2-UKDY.domain1.systemhost.net> > Maybe it's just my COOP mindset, but it seems to me there are > a lot of ways that adding IPv6 to my servers can disrupt > their IPv4 operation. You are right. Don't add IPv6 to an IPv4 server. Instead, create a translation layer so that IPv6 hosts can access it through the translation layer. Part of such a translation layer would be a different hostname, for instance use ipv6.example.com instead of www.example.com. One translation layer gateway can front for many IPv4 servers. And there is a veritable smorgasbord of tools that can be used to make translation gateways from web proxies for purely http servers, to 6to4 relays for miscellaneous IP traffic. The important thing is to implement something, and tell people about the problems that you run into, as well as your successes. The more open discussion there is, the quicker problems will be fixed. --Michael Dillon From bill at herrin.us Fri Oct 30 14:07:32 2009 From: bill at herrin.us (William Herrin) Date: Fri, 30 Oct 2009 14:07:32 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> Message-ID: <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> On Fri, Oct 30, 2009 at 12:23 PM, Lee Howard wrote: > I agree, 6to4 is in many cases poorly implemented, as are many of the > other tunnel solutions. Google's response is to return AAAAs only if > they have pretty high confidence that the client will have native IPv6. Hi Lee, That's an option I look forward to seeing in the bind9 documentation. But while that helps me, it does little for the plethora of server operators who don't host their own DNS and have only weak control over the folks who do. > Right. If you don't have IPv6 connectivity, then you can't connect via > IPv6. This is not unique to IPv6. I should have included a Step 0: get > good IPv6 transit. Rhetorical question: is it presently possible to get "good" IPv6 transit for the same standard of "good" as is available for IPv4 transit? The answer, of course, is no. Should IPv6 transport quality ever reach parity with IPv4 transit quality then naturally my objections would fade. But declaring it "as good" doesn't make it so and right now it isn't even close enough for the difference to be subtle. >> Maybe it's just my COOP mindset, but it seems to me there are a lot of >> ways that adding IPv6 to my servers can disrupt their IPv4 operation. > > Nothing you've said describes interference with the operation of your > servers. You've described several ways IPv6 connectivity may fail, > none of which are inherent to IPv6. They describe commonly experienced failure modes that impact the operation of applications otherwise capable of connecting with IPv4 as an inescapable result of deploying dual stack. I try to minimize the probability of my servers encountering any failure modes and today that means no IPv6. > As I'm sure you know, the conventional wisdom is that by preferring > IPv6, traffic counters will provide compelling evidence to people like > you that IPv6 support is required. And then those who assign > addresses, when they see that 100% of traffic is IPv6, can silently > stop assigning IPv4 addresses, and the Internet will have gracefully > migrated. The "conventional wisdom" for IPv6 has failed us in so many ways we should probably start appending a "[sic]" when we say it. This particular error in judgment is no exception: trouble bringing IPv4 to a close is a "nice problem to have" versus the difficulty in getting IPv6 to a point where we can seriously consider IPv4's end. At any rate, I'm not trying to argue with you. I'm just explaining some of the reasons why I stopped my IPv6 deployment work after the "experimental, figure out how this thing actually works and take it for a test drive" phase. >> Or, of course, if a substantial enough deployment of IPv6-only users >> goes forward despite my own reluctance. > > Or maybe if your servers run an app that doesn't like multiple layers > of NAT? My services are NAT-tolerant. Long since passed the point where systems that don't play well with NAT can be considered reliable. On Fri, Oct 30, 2009 at 1:50 PM, wrote: >> Maybe it's just my COOP mindset, but it seems to me there are >> a lot of ways that adding IPv6 to my servers can disrupt >> their IPv4 operation. > > You are right. Don't add IPv6 to an IPv4 server. Instead, create > a translation layer so that IPv6 hosts can access it through the > translation layer. Part of such a translation layer would be > a different hostname, for instance use ipv6.example.com instead > of www.example.com. Which is, no doubt, the first form of IPv6 deployment that I will do. But then what? Assuming I can clear enough obstacles to move to that stage, how does that movement encourage or empower anyone else to move to the stage beyond? On Fri, Oct 30, 2009 at 11:42 AM, Owen DeLong wrote: > Not exactly... It will have already looked up the A records, but, when > the connect() call returns ETIMEOUT, the loop will continue to iterate > until connect() succeeds. ?Yes, the successive calls to connect() > should use the IPv6 address first. Owen, Connect generally doesn't return ETIMEOUT for at least two minutes and sometimes as long as 15. For a web browser, that might as well be forever. Application developers can do non-blocking connects that time out sooner but they generally don't. > The same is true if you have an IPv4 application hosted on multiple > addresses and the first one is not working at the moment. Hence the reason I *don't have* IPv4 applications hosted on multiple addresses. > I've been running dual-stack for several months now, and, frankly, have > not noticed a significant number of degraded events. Why would you see problems? The servers you're contacting are either intentionally IPv6 (ipv6.google.com) or offer no AAAA records to distract you (www.google.com). You don't see problems because people like me have declined to deploy IPv6 on their servers. > Actually, if you want to do that, for the most part, you only need to modify > the getaddrinfo() library on your system. Great. Let's get modifying and get those modifications deployed so that the possibility of IPv6 on my production servers can enter my comfort zone. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Wesley.E.George at sprint.com Fri Oct 30 14:28:00 2009 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 30 Oct 2009 13:28:00 -0500 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <857357.57887.qm@web63306.mail.re1.yahoo.com> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lee Howard Sent: Friday, October 30, 2009 12:23 PM To: William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > The moment I publish a AAAA record > for my web site, your web browser on your IPv4/IPv6 dual-stacked > machine will attempt to connect to that AAAA record in preference to > any A records I've published, will it not? Yes. It seems to me that requesting AAAA records over IPv4 is a bad idea; at least one popular name server now has a now that when set, will only return AAAA to queries from IPv6 addresses. [weg] I've been trying to stay out of this discussion, as I think it's not really an ARIN policy-related one anymore (no matter how interesting and animated), but had to respond to this. As an IPv6-enabled XP user, I beg to differ. I actually think that refusing to respond to IPv4 AAAA queries is a bad idea, unless you can convince MS to release a patch to make AAAA queries via IPv6. Yes, it can lead to problems, but I think there are other ways around it. In terms of the IPv6 transition, it's much easier to install XP's (limited) IPv6 support than it is to get all users to upgrade to a new OS. It would drive individual SPs to need to stand up a proxy DNS server that listens for IPv4 AAAA reqs and does the recursion in IPv6, or risk breaking IPv6 for a large group of customers that would otherwise be capable of supporting it. Was chatting with some folks during Dearborn about methods to roll out IPv6 that are somewhat more mainstream than building a separate http://ipv6.site.com, but less risky than simply responding with a AAAA for www.site.com, and the same methods that are used to probe for IPv6 capability (loading zero-pixel gifs embedded in the page that call different addresses using an IPv4 server, an IPv6 address and a AAAA record-enabled DNS entry) could be used to determine that the user has "good enough" IPv6 connectivity, and then offer them an IPv6-capable version of the page via a banner that appears for them to click (eg "click to test our site in IPv6"). Depending on the specific implementation, it could be done automatically, done as an opt-in, with our without a cookie to remember status, etc. But either way, it would possibly be a good intermediate step when we're comfortable with our implementation of IPv6, but not sure how well end to end IPv6 connectivity is working and don't necessarily have cycles to whitelist known IPv6-capable networks. I don't have the programming skills, but I'm hoping one of the folks I was talking with will post it as a freely-available script that others can use. $0.02 Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From tedm at ipinc.net Fri Oct 30 14:50:21 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 30 Oct 2009 11:50:21 -0700 Subject: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs In-Reply-To: References: <443de7ad0910271036w4e72cda1rd757a389bd182b97@mail.gmail.com> Message-ID: <4AEB356D.7060704@ipinc.net> George, Wes E [NTK] wrote: > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann > Sent: Tuesday, October 27, 2009 1:37 PM > Subject: Re: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs > > On Tue, Oct 27, 2009 at 09:29, Bill Darte wrote: >> Reservations expressed by myself at the time of acceptance was that the >> proposal seemed overly complex with thresholds and tiggers that rely >> upon 1/ ARIN's ability to accurately assess the remaining free pool in >> small, single digit percentages; 2/ the ability of ARIN to react to >> changes in status of the free pool based upon these thresholds and >> announce the changes to the public; and 3/ most importantly, that all >> these thresholds and all the remaining FP might be eliminated with a >> single justified large allocation rendering the policy's incremental >> process mute. > > I agree. With regard to this PP and other PP and DP which deal with > IPv4-free-pool-run-out / soft-landing strategies: I am beginning to > wonder if it isn't better to do away with all of the staggered > triggers and accompanying complexity for a much simpler approach. > > In this case specifically, if the community believes that lowering the > minimum allocation may help as we approach and pass IPv4 free-pool > exhaustion, why not just lower it now? Forget the triggers all > together. > Hi George, That is actually my preference, the reason I added the triggers is to make the proposal more palatable to those who have concerns that lowering the minimum too early might increase the DFZ unnecessairly. The minimums in that section exist today explicitly to prevent such fragmentation. As an ISP admin I share those concerns as well. However, my feeling is also that the ISP business is maturing to where other factors are limiting the fragmentation of routes in the DFZ. Forcing small ISP's to go to LIR's made really a huge amount of sense in 1995-2000 when anybody could get an extra couple phone lines, put some 28.8k modems on a router, and a 56K circuit to an ISP and hang up their ISP shingle. With the advent of 56k it raised the bar somewhat, but products like the Ascend MAX allowed even small operators to supply 56k dialup over BRI's - but we saw the beginnings of the weeding-out process where people who wern't serious about making a business out of Internet access left the market. Then when DSL came in and dialup started declining, and moving to the outsourcers, it did a lot more weeding, and made conditions such that smaller ISP's couldn't get started anyway. ISP's were either forced to get big or go away. With the advent of cheap wireless gear it's kind of leaving an opening for the small access providers to get started again - but I think it's pretty severely restricted to rural areas, and I don't know that we would have that many applicants from startup small ISPs. I think the primary producer of applicants for /24's under part 4.2.2.1.1 are going to be "niche" small ISPs (particularly WISPs) who for years have operated with upstream LIR assignments, and have a single upstream feed, (and won't be getting more) and are afraid that as the squeeze is put on IPv4 in the future, that they could get knocked offline. I don't think it's going to be garage operators who have never been ISP's before, wanting to get into the "ISP land rush". It's not like it was 10 years ago, in this business. Thus, I don't feel that we are going to see that explosive growth of DFZ BGP advertisements from orgs getting /24's under section 4.2.2.1.1 If anything, the growth is going to come from the inability of the RIR's to assign adjacent IPv4 blocks to new requesters. It is going to be a challenge for a lot of those smaller ISPs anyway even if they get an IPv4 block they can advertise, because now they will have to advertise it to their upstream, whereas before their upstream took care of all of that for them. Ted From spiffnolee at yahoo.com Sat Oct 31 10:54:28 2009 From: spiffnolee at yahoo.com (Lee Howard) Date: Sat, 31 Oct 2009 07:54:28 -0700 (PDT) Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> Message-ID: <332596.31946.qm@web63301.mail.re1.yahoo.com> ----- Original Message ---- > From: William Herrin > To: "arin-ppml at arin.net" > Sent: Fri, October 30, 2009 2:07:32 PM > Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern > > On Fri, Oct 30, 2009 at 12:23 PM, Lee Howard wrote: > > I agree, 6to4 is in many cases poorly implemented, as are many of the > > other tunnel solutions. Google's response is to return AAAAs only if > > they have pretty high confidence that the client will have native IPv6. > > Hi Lee, > > That's an option I look forward to seeing in the bind9 documentation. > But while that helps me, it does little for the plethora of server > operators who don't host their own DNS and have only weak control over > the folks who do. Many of them also don't host their own web servers, so the hosting company will handle the migration. > > Right. If you don't have IPv6 connectivity, then you can't connect via > > IPv6. This is not unique to IPv6. I should have included a Step 0: get > > good IPv6 transit. > > Rhetorical question: is it presently possible to get "good" IPv6 > transit for the same standard of "good" as is available for IPv4 > transit? The answer, of course, is no. > > Should IPv6 transport quality ever reach parity with IPv4 transit > quality then naturally my objections would fade. But declaring it "as > good" doesn't make it so and right now it isn't even close enough for > the difference to be subtle. Sounds like there may be some dollars to be waived under the noses of some transit providers. "Give me production-grade IPv6 transit or my IPv6 bits go elsewhere." > At any rate, I'm not trying to argue with you. I'm just explaining > some of the reasons why I stopped my IPv6 deployment work after the > "experimental, figure out how this thing actually works and take it > for a test drive" phase. You know, if you have plans for how to implement IPv6 when you think it's safe, that's pretty good. I wish you would help with the things that cause you concern (talk to your transit providers, and use the AAAA-for-IPv6-only feature). Maybe in six months, conditions will have changed enough for you not to worry. > >> Or, of course, if a substantial enough deployment of IPv6-only users > >> goes forward despite my own reluctance. > > > > Or maybe if your servers run an app that doesn't like multiple layers > > of NAT? > > My services are NAT-tolerant. Long since passed the point where > systems that don't play well with NAT can be considered reliable. Sure, everything can hack around home gateway NAT, but some of those hacks assume only a single layer. Question born of ignorance: can you track unique web views if thousands of users are behind a single IPv4 address? It might not be an issue for your servers, but many websites use that as their primary metric for selling ads, don't they? Lee From bill at herrin.us Sat Oct 31 13:24:26 2009 From: bill at herrin.us (William Herrin) Date: Sat, 31 Oct 2009 13:24:26 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <332596.31946.qm@web63301.mail.re1.yahoo.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> Message-ID: <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> On Sat, Oct 31, 2009 at 10:54 AM, Lee Howard wrote: >> Rhetorical question: is it presently possible to get "good" IPv6 >> transit for the same standard of "good" as is available for IPv4 >> transit? The answer, of course, is no. > > Sounds like there may be some dollars to be waived under the noses > of some transit providers. ?"Give me production-grade IPv6 transit > or my IPv6 bits go elsewhere." Lee, I assure you it only sounds that way. The investment is a cumulative effect measured not just in terms of my transit connection but simultaneously in terms of yous and the transit for every other individual who would use IPv6 to talk to me. I could wave Bill Gates' fortune at the transit providers and it would still be years before the IPv4 and IPv6 DFZs' standard of quality reached parity. > Maybe in six months, > conditions will have changed enough for you not to worry. Not possible. Not even in 3 years. Best example of a systemic technology being deployed first-class from day one is the 1.6 gallon flush. That was only possible because the predecessor technology was literally outlawed. Maybe in 6 years but can't really start the countdown clock for IPv6 success until the insanity of trying to treat it as a first class protocol up front is dealt with. > Question born of ignorance: > can you track unique web views if thousands of users are behind a > single IPv4 address? ?It might not be an issue for your servers, but > many websites use that as their primary metric for selling ads, don't > they? Depends on your methodology. comScore, for example, offers prizes to induce folks to sit on a panel, by which they mean install software on their PCs that reports their web use and answer surveys about their interests and demographics. Scale those results versus a carefully randomized control group and you get a statistically valid idea what's going on. You also have to understand that the metrics folks aren't interested in use by machine so much as use by *person*. Users have demographics and areas of interest. Machines are mostly just machines. NAT or no NAT, tell me how you separate Mom, Dad and Child on the family PC evaluating only the packets. At the point when I left comScore no IPv6 measurement was being done. I got the impression that had I stayed it might have been humored as "Bill's pet project." Targeted advertising is a whole other ballgame than site metrics and demographics. I don't have a lot of experience there but AFAIK it's mostly based on cookies rather than source address. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Sat Oct 31 13:35:22 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 31 Oct 2009 10:35:22 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <332596.31946.qm@web63301.mail.re1.yahoo.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> Message-ID: <4AEC755A.2080404@ipinc.net> Lee Howard wrote: > ----- Original Message ---- > >> From: William Herrin >> To: "arin-ppml at arin.net" >> Sent: Fri, October 30, 2009 2:07:32 PM >> Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern >> >> On Fri, Oct 30, 2009 at 12:23 PM, Lee Howard wrote: >>> I agree, 6to4 is in many cases poorly implemented, as are many of the >>> other tunnel solutions. Google's response is to return AAAAs only if >>> they have pretty high confidence that the client will have native IPv6. >> Hi Lee, >> >> That's an option I look forward to seeing in the bind9 documentation. >> But while that helps me, it does little for the plethora of server >> operators who don't host their own DNS and have only weak control over >> the folks who do. > > Many of them also don't host their own web servers, so the hosting company > will handle the migration. > >>> Right. If you don't have IPv6 connectivity, then you can't connect via >>> IPv6. This is not unique to IPv6. I should have included a Step 0: get >>> good IPv6 transit. >> Rhetorical question: is it presently possible to get "good" IPv6 >> transit for the same standard of "good" as is available for IPv4 >> transit? The answer, of course, is no. >> >> Should IPv6 transport quality ever reach parity with IPv4 transit >> quality then naturally my objections would fade. But declaring it "as >> good" doesn't make it so and right now it isn't even close enough for >> the difference to be subtle. > > Sounds like there may be some dollars to be waived under the noses > of some transit providers. "Give me production-grade IPv6 transit > or my IPv6 bits go elsewhere." > > >> At any rate, I'm not trying to argue with you. I'm just explaining >> some of the reasons why I stopped my IPv6 deployment work after the >> "experimental, figure out how this thing actually works and take it >> for a test drive" phase. > > You know, if you have plans for how to implement IPv6 when you > think it's safe, that's pretty good. I wish you would help with the > things that cause you concern (talk to your transit providers, and > use the AAAA-for-IPv6-only feature). Maybe in six months, > conditions will have changed enough for you not to worry. > >>>> Or, of course, if a substantial enough deployment of IPv6-only users >>>> goes forward despite my own reluctance. >>> Or maybe if your servers run an app that doesn't like multiple layers >>> of NAT? >> My services are NAT-tolerant. Long since passed the point where >> systems that don't play well with NAT can be considered reliable. > > Sure, everything can hack around home gateway NAT, but some of > those hacks assume only a single layer. Question born of ignorance: > can you track unique web views if thousands of users are behind a > single IPv4 address? It might not be an issue for your servers, but > many websites use that as their primary metric for selling ads, don't > they? > You can't. It's also difficult to impossible to discover click fraud from small operators or from organized crime that create trojan programs that infect computers - the typical scenario is spurious redirects to a web browser on an infected computer so the user of the web browser is generating the clicks. But, it doesn't matter much since the actual advertisers don't generally contract with the web hosters - they contract with advertiser networks (Google AdWords, etc.) who do the actual contracting with the websites, and who also determine if the clicks are valid or not. The advertiser networks consider their logic for detecting click validity to be proprietary, so at this point its basically impossible to know if they are counting multiple clicks behind the same NAT device as separate clicks or not. In my experience, though, click-counts are mainly used by advertisers as a way of attempting to beat the price down for advertising, no serious advertiser pays a lot of attention to them. Advertisers look at their own revenue stream and if they spend money with an advertising network like Google Adwords and they don't see a revenue increase, they stop buying advertising. Advertisers who want body counts use promotion codes or printable coupons to get that. Typically, the majority of advertisers will see an increase once they start paying for advertising, and that's all the advertising networks care about anyway. Ted From tedm at ipinc.net Sat Oct 31 13:41:05 2009 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 31 Oct 2009 10:41:05 -0700 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> Message-ID: <4AEC76B1.1050908@ipinc.net> William Herrin wrote: > > Not possible. Not even in 3 years. Best example of a systemic > technology being deployed first-class from day one is the 1.6 gallon > flush. That was only possible because the predecessor technology was > literally outlawed. You obviously have never been shopping for or installed your own commodes, or you wouldn't say that. There's wide variation in the quality of the implementation of the 1.6 gallon flush. Ted From mueller at syr.edu Sat Oct 31 13:50:52 2009 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 31 Oct 2009 13:50:52 -0400 Subject: [arin-ppml] IPv4 Depletion as an ARIN policy concern In-Reply-To: <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> References: <4AE9D572.6080608@Dilkie.com> <3c3e3fca0910291140s1a4ea9b6l51776fa6f1ae56b6@mail.gmail.com> <139257.98318.qm@web63306.mail.re1.yahoo.com> <3c3e3fca0910300831q5e130dd8xd94c99797f737fd9@mail.gmail.com> <6652861E-150B-4E95-9298-D6CC048E5E5B@delong.com> <3c3e3fca0910301107i1699a390q6c52f81b5f2bd17b@mail.gmail.com> <332596.31946.qm@web63301.mail.re1.yahoo.com> <3c3e3fca0910311024x7ef383ddp810a6b199c49fb6b@mail.gmail.com> Message-ID: <75822E125BCB994F8446858C4B19F0D78FF6051F@SUEX07-MBX-04.ad.syr.edu> > > Question born of ignorance: > > can you track unique web views if thousands of users are behind a > > single IPv4 address? ?It might not be an issue for your servers, but > > many websites use that as their primary metric for selling ads, don't > > they? Ever heard of cookies?