From jbates at brightok.net Wed Dec 1 09:07:28 2010 From: jbates at brightok.net (Jack Bates) Date: Wed, 01 Dec 2010 08:07:28 -0600 Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121) In-Reply-To: <4CE400D0.4000103@arin.net> References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net> Message-ID: <4CF656A0.8020004@brightok.net> Still support. On 11/17/2010 10:20 AM, ARIN wrote: >> 6.5.2.2 Qualifications > >> An organization qualifies for an allocation under this policy if > >> they meet any of the following criteria: > >> (a) Have a previously justified IPv4 ISP allocation from ARIN > >> or one of its predecessor registries or can qualify for an IPv4 >> ISP > >> allocation under current criteria. > >> (b) Are currently multihomed for IPv6 or will immediately > >> become multihomed for IPv6 using a valid assigned global AS >> number. > >> (c) Provide ARIN a reasonable technical justification, > >> indicating why an allocation is necessary, including the intended > >> purposes for the allocation, and describing the network >> infrastructure > >> the allocation will be used to support. Justification must include >> a > >> plan detailing assignments to other organizations or customers for >> one, > >> two and five year periods, with a minimum of 50 assignments within >> 5 > >> years. I have a concern that NRPM 4.2.2 IPv4 has a huge criteria for defining what an ISP is, where this section is extremely small. In particular, section b allows any multi-homed customer to be considered an ISP, which seems to override end-user assignment criteria. Is this really what we want? Would it not be simpler to define a minimum number of end sites which will be assigned to constitute an ISP? Any sized service provider could easily qualify under 6.5.5.2c if I'm reading it right, but end-users could quickly qualify under 6.5.5.2b so long as they are multihomed. I'm a strong believer of allowing even the smallest ISPs to become an ISP with v6 (ie, supporting their right for a /32, /36 even from another ISP). I disagree with allowing a single site hosting a few private servers which are multihomed to be added to the ISP criteria (blocklist operators, spammers, and many others will fall under this criteria). Jack From owen at delong.com Wed Dec 1 09:55:04 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 1 Dec 2010 06:55:04 -0800 Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121) In-Reply-To: <4CF656A0.8020004@brightok.net> References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net> <4CF656A0.8020004@brightok.net> Message-ID: <27E7D5A5-81EB-4DED-A3F0-6B57FA1A4897@delong.com> On Dec 1, 2010, at 6:07 AM, Jack Bates wrote: > Still support. > > On 11/17/2010 10:20 AM, ARIN wrote: >>> 6.5.2.2 Qualifications >> >>> An organization qualifies for an allocation under this policy if >> >>> they meet any of the following criteria: >> >>> (a) Have a previously justified IPv4 ISP allocation from ARIN >> >>> or one of its predecessor registries or can qualify for an IPv4 >>> ISP >> >>> allocation under current criteria. >> >>> (b) Are currently multihomed for IPv6 or will immediately >> >>> become multihomed for IPv6 using a valid assigned global AS >>> number. >> >>> (c) Provide ARIN a reasonable technical justification, >> >>> indicating why an allocation is necessary, including the intended >> >>> purposes for the allocation, and describing the network >>> infrastructure >> >>> the allocation will be used to support. Justification must include >>> a >> >>> plan detailing assignments to other organizations or customers for >>> one, >> >>> two and five year periods, with a minimum of 50 assignments within >>> 5 >> >>> years. > > > I have a concern that NRPM 4.2.2 IPv4 has a huge criteria for defining what an ISP is, where this section is extremely small. In particular, section b allows any multi-homed customer to be considered an ISP, which seems to override end-user assignment criteria. Is this really what we want? Would it not be simpler to define a minimum number of end sites which will be assigned to constitute an ISP? Any sized service provider could easily qualify under 6.5.5.2c if I'm reading it right, but end-users could quickly qualify under 6.5.5.2b so long as they are multihomed. > Not at all... An organization which meets both criteria can choose whether they prefer to apply as an ISP or as an end user. An end-user organization cannot make any reassignments. Any organization which is making reassignments to customers is an ISP (or LIR). > > I'm a strong believer of allowing even the smallest ISPs to become an ISP with v6 (ie, supporting their right for a /32, /36 even from another ISP). I disagree with allowing a single site hosting a few private servers which are multihomed to be added to the ISP criteria (blocklist operators, spammers, and many others will fall under this criteria). > In reality, why would they want to be? There's no advantage to being an ISP vs. an end-user organization. All it does is raise your fees. Owen From jbates at brightok.net Wed Dec 1 10:32:28 2010 From: jbates at brightok.net (Jack Bates) Date: Wed, 01 Dec 2010 09:32:28 -0600 Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121) In-Reply-To: <27E7D5A5-81EB-4DED-A3F0-6B57FA1A4897@delong.com> References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net> <4CF656A0.8020004@brightok.net> <27E7D5A5-81EB-4DED-A3F0-6B57FA1A4897@delong.com> Message-ID: <4CF66A8C.3080600@brightok.net> On 12/1/2010 8:55 AM, Owen DeLong wrote: > Not at all... An organization which meets both criteria can choose whether they prefer to apply as an ISP or as an end user. > An end-user organization cannot make any reassignments. Any organization which is making reassignments to customers > is an ISP (or LIR). > I agree, though I believe that an organization reassigning space should be a mandatory condition. Not that it can be enforced, but it is good policy anyways. > In reality, why would they want to be? There's no advantage to being an ISP vs. an end-user organization. All it does is raise your fees. > The /32 minimum allocations. Though perhaps it's not a big deal, as spammers will either lie or utilize IPv4 status to get the /32 anyways. My thought is not so much about the fact that people will game the system or that it won't be enforced, but that it is just good policy to define an ISP as what it is, not to arbitrarily categorize an organization which does BGP as an ISP. Jack From owen at delong.com Wed Dec 1 17:44:19 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 1 Dec 2010 14:44:19 -0800 Subject: [arin-ppml] Sensible IP Allocations Revision 0.9 Message-ID: Here is the revised text of proposal 121. Changes in this version: 1. Wordsmithing 2. Improved definition of ISP/LIR to close loophole for multihomed organizatios. This is version 0.9 of the proposal: Amend section 2 as follows: Delete section 2.9 (Obsolete) Replace section 2.10 with the following: 2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location). Add the following: 2.12 The term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof. 2.13 The term provider assignment unit shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48). 2.14 The term utilized shall have the following definitions: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site. (ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) Replace sections 6.5.1 through 6.5.3 with the following: 6.5.1 Terminology (a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. (b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) 6.5.2 Initial Allocations to LIRs 6.5.2.1 Size (a) All allocations shall be made on nibble boundaries. (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. (c) The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses. This calculation can be summarized as /N where N = 48-(X+Y) and X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site. (d) For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy. (e) For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. (f) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled. 6.5.2.2 Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: (a) Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. (b) Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number and will be making reassignments to other organizations. (c) Provide ARIN a reasonable technical justification, indicating why an allocation is necessary, including the intended purposes for the allocation, and describing the network infrastructure the allocation will be used to support. Justification must include a plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. 6.5.3 Subsequent Allocations to LIRs (a) Where possible ARIN will make subsequent allocations by expanding the existing allocation. (b) An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be entitled to a subsequent allocation. (c) If ARIN can not expand one or more existing allocations, ARIN shall make a new allocation based on the initial allocation criteria above. The LIR is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use. Replace section 6.5.4 with the following 6.5.4 Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Add the following to 6.5.7 LIRs which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return. From woody at pch.net Wed Dec 1 17:54:41 2010 From: woody at pch.net (Bill Woodcock) Date: Wed, 1 Dec 2010 14:54:41 -0800 Subject: [arin-ppml] Sensible IP Allocations Revision 0.9 In-Reply-To: References: Message-ID: <2AEB8029-C6C8-4742-9D7D-81A82FF133B4@pch.net> On Dec 1, 2010, at 2:44 PM, Owen DeLong wrote: > Here is the revised text of proposal 121. Changes in this version: > > 1. Wordsmithing > 2. Improved definition of ISP/LIR Out of curiousity, why use the acronym "LIR" at all? It doesn't have any meaning in our region. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From marty at akamai.com Wed Dec 1 21:48:38 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 1 Dec 2010 21:48:38 -0500 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: <4CF58BC6.3060005@umn.edu> Message-ID: On 11/30/10 6:41 PM, "David Farmer" wrote: > On 11/30/10 15:54 CST, Owen DeLong wrote: >> >> On Nov 30, 2010, at 1:39 PM, Hannigan, Martin wrote: >>> On 11/30/10 2:09 PM, "David Farmer" wrote: >>>> On 11/30/10 09:44 CST, Hannigan, Martin wrote: >>>> ... [ snip ] > > But, on the other side what do you perceive the harm would be to of > allowing 4.10 to be implemented as it is? Or, will be if we fail to > come to a consensus to fix it. What's the harm in not calling an ambulance for a heart attack victim because no-one can agree which ambulance service to call? [ clip ] > I would like to see a clear and significant (more than just the usual > suspects) consensus that the community both supports these policies and > more importantly that the community supports the use of the emergency > policy process regarding these policies. It needs to be clear to any > third-party who reviews PPML at some future date, maybe as few as a > couple months from now what the communities consensus was. The sound of crickets on ppml should not be the sound of inaction by the AC. Many policies are met with crickets on PPML and pass resoundingly at the policy meeting. If the AC is going to be followers then I suggest that you all stop writing and pushing your own proposals. Best, -M< From owen at delong.com Wed Dec 1 22:05:47 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 1 Dec 2010 19:05:47 -0800 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: References: Message-ID: On Dec 1, 2010, at 6:48 PM, Hannigan, Martin wrote: > > > > On 11/30/10 6:41 PM, "David Farmer" wrote: > >> On 11/30/10 15:54 CST, Owen DeLong wrote: >>> >>> On Nov 30, 2010, at 1:39 PM, Hannigan, Martin wrote: >>>> On 11/30/10 2:09 PM, "David Farmer" wrote: >>>>> On 11/30/10 09:44 CST, Hannigan, Martin wrote: >>>>> ... > > > [ snip ] > >> >> But, on the other side what do you perceive the harm would be to of >> allowing 4.10 to be implemented as it is? Or, will be if we fail to >> come to a consensus to fix it. > > What's the harm in not calling an ambulance for a heart attack victim > because no-one can agree which ambulance service to call? > Ah, the joys of FUD. I don't think you even have agreement that the patient is diaphoretic, let alone suffering chest pain, an impaired pulse, blood pressure abnormalities, or any of the other key symptoms of a heart attack. We can probably all agree that the patient is not in perfect health, but, the current state is somewhere between a case of the sniffles and a stroke, depending on your point of view. An equally important question is what is the harm in calling an ambulance for a case of the sniffles. The answer is that it prevents the ambulance from responding to the heart attack down the street, _AND_ it is expensive for the person with the sniffles. > > [ clip ] > > >> I would like to see a clear and significant (more than just the usual >> suspects) consensus that the community both supports these policies and >> more importantly that the community supports the use of the emergency >> policy process regarding these policies. It needs to be clear to any >> third-party who reviews PPML at some future date, maybe as few as a >> couple months from now what the communities consensus was. > > > The sound of crickets on ppml should not be the sound of inaction by the AC. Ah, something we can actually agree on. (sort of) > Many policies are met with crickets on PPML and pass resoundingly at the > policy meeting. If the AC is going to be followers then I suggest that you > all stop writing and pushing your own proposals. > And I will be very interested to see what level of support these proposals receive at the meeting. Refusing to take emergency action without a clear need or a mandate from the community is not followship. It's prudent leadership. The AC is not a dictatorial body. We are a collection of subject matter experts that have a clear mandate to include community consensus as an aspect of our decisions to enact policy. For a policy that isn't being discussed in any public forum other than PPML, the sound of crickets on PPML establishes a lack of consensus. As to whether the AC should be writing policies, I think you are sadly misguided there. In my experience, we don't simply push policies based on our own perceptions or needs. We spend a great deal of time talking to community members and soliciting information from them on areas where current policy is proving to be problematic, then we write proposals to correct those issues. Owen From farmer at umn.edu Wed Dec 1 23:10:10 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 01 Dec 2010 22:10:10 -0600 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: References: Message-ID: <4CF71C22.3000404@umn.edu> On 12/1/10 20:48 CST, Hannigan, Martin wrote: > On 11/30/10 6:41 PM, "David Farmer" wrote: ... >> But, on the other side what do you perceive the harm would be to of >> allowing 4.10 to be implemented as it is? Or, will be if we fail to >> come to a consensus to fix it. > > What's the harm in not calling an ambulance for a heart attack victim > because no-one can agree which ambulance service to call? Why the hyperbole? I'm simply want the record to contain a discussion of why this is an emergency. People will be looking over our shoulders soon. I would like them to find a community that make well reasoned decisions following an open bottom up process. >> I would like to see a clear and significant (more than just the usual >> suspects) consensus that the community both supports these policies and >> more importantly that the community supports the use of the emergency >> policy process regarding these policies. It needs to be clear to any >> third-party who reviews PPML at some future date, maybe as few as a >> couple months from now what the communities consensus was. > > The sound of crickets on ppml should not be the sound of inaction by the AC. > Many policies are met with crickets on PPML and pass resoundingly at the > policy meeting. If the AC is going to be followers then I suggest that you > all stop writing and pushing your own proposals. I'm fine with crickets on PPML when we are following the normal policy process, but you are suggesting this policy should follow the emergency policy process. In that case I don't think crickets on PPML is a good thing. It is not my intent to follow, I'm trying be a leader by facilitate a conversation and attempting to cajole members of the community to express their opinions on an important issue. It is my understanding this is something that AC members are suppose to do, it is one of the many ways that AC members fulfill their leadership role within the community. Do you see the AC's role differently? -- =============================================== 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 Dec 2 00:13:57 2010 From: bill at herrin.us (William Herrin) Date: Thu, 2 Dec 2010 00:13:57 -0500 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: <4CF71C22.3000404@umn.edu> References: <4CF71C22.3000404@umn.edu> Message-ID: On Wed, Dec 1, 2010 at 11:10 PM, David Farmer wrote: > I'm fine with crickets on PPML when we are following the normal policy > process, but you are suggesting this policy should follow the emergency > policy process. In that case I don't think crickets on PPML is a good thing. Hi David, For what it's worth, my opinion is that 122 and 123 should be adopted as draft policies and put through the normal process, at least until the last /8 is actually allocated. However, the AC should plan to meet within 48 hours of that allocation to determine whether to recommend that the board adopt them under emergency rules and I would hope the board would arrange to be able to quickly respond as well. Yeah, we'll end up having to make a decision before the next meeting, but there's no real harm in continuing the discussion until the last minute as long as we have a pretty good idea what we're going to do when it gets here. When the last minute arrives, I would favor 122 and 123 as emergency policies. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From BillD at cait.wustl.edu Thu Dec 2 08:26:28 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 2 Dec 2010 07:26:28 -0600 Subject: [arin-ppml] Sensible IP Allocations Revision 0.9 References: <2AEB8029-C6C8-4742-9D7D-81A82FF133B4@pch.net> Message-ID: I think the only utility is to roughly equate the two from the perspective of those outside our region reading ARIN policy. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Bill Woodcock Sent: Wed 12/1/2010 4:54 PM To: Owen DeLong Cc: ppml at arin.net PPML Subject: Re: [arin-ppml] Sensible IP Allocations Revision 0.9 On Dec 1, 2010, at 2:44 PM, Owen DeLong wrote: > Here is the revised text of proposal 121. Changes in this version: > > 1. Wordsmithing > 2. Improved definition of ISP/LIR Out of curiousity, why use the acronym "LIR" at all? It doesn't have any meaning in our region. -Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Thu Dec 2 10:49:07 2010 From: info at arin.net (ARIN) Date: Thu, 02 Dec 2010 10:49:07 -0500 Subject: [arin-ppml] Policy Proposal 121: Sensible IPv6 Allocation for ISPs - revised Message-ID: <4CF7BFF3.2030106@arin.net> The proposal originator submitted revised text. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 121: Sensible IPv6 Allocation for ISPs Proposal Version: .9 Date: 2 December 2010 Policy statement: > Amend section 2 as follows: > > Delete section 2.9 (Obsolete) > Replace section 2.10 with the following: > 2.10 The term End Site shall mean a single structure or service delivery > address, or, in the case of a multi-tenant structure, a single tenant > within said structure (a single customer location). > Add the following: > 2.12 The term serving site shall mean a location where an ISP terminates > or aggregates customer connections, including, but, not limited to > Points of Presence (POPs), Datacenters, Central or Local switching > office or regional or local combinations thereof. > 2.13 The term provider assignment unit shall mean the prefix of the > smallest block a given ISP assigns to end sites (recommended /48). > 2.14 The term utilized shall have the following definitions: > (i) A provider assignment unit shall be considered fully utilized when > it is assigned to an end-site. > (ii) Larger blocks shall have their utilization defined by dividing the > number of provider assignment units assigned from the > containing block by the total number of provider assignment > units. This ratio will often be expressed as a percentage > (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) > > Replace sections 6.5.1 through 6.5.3 with the following: > 6.5.1 Terminology > (a) The terms ISP and LIR are used interchangeably in this document and > any use of either term shall be construed to include both meanings. > (b) The term nibble boundary shall mean a network mask which aligns > on a 4-bit boundary (in slash notation, /n, where n is evenly divisible > by 4, allowing unit quantities of X such that 2^n=X where n is > evenly divisible by 4, such as 16, 256, 4096, etc.) > > 6.5.2 Initial Allocations to LIRs > 6.5.2.1 Size > (a) All allocations shall be made on nibble boundaries. > (b) In no case shall an LIR receive smaller than a /32 > unless they specifically request a /36. > (c) The maximum allowable allocation shall be the smallest > nibble-boundary aligned block that can provide an equally > sized nibble-boundary aligned block to each of the > requesters serving sites large enough to satisfy the needs > of the requesters largest single serving site using no more > than 75% of the available addresses. > > This calculation can be summarized as /N where > N = 48-(X+Y) and X is a multiple of 4 greater > than 4/3*serving sites and Y is a multiple of 4 > greater than 4/3*end sites served by largest serving site. > > (d) For purposes of the calculation in (c), an end site which > can justify more than a /48 under the end-user assignment > criteria in 6.5.8 shall count as the appropriate number of /48s > that would be assigned under that policy. > (e) For purposes of the calculation in (c), an LIR which has > subordinate LIRs shall make such allocations according > to the same policies and criteria as ARIN. In such a case, > the prefixes necessary for such an allocation should be treated > as fully utilized in determining the block sizing for the parent LIR. > (f) An LIR is not required to design or deploy their network > according to this structure. It is strictly a mechanism to > determine the largest IP address block to which the LIR > is entitled. > 6.5.2.2 Qualifications > An organization qualifies for an allocation under this policy if > they meet any of the following criteria: > (a) Have a previously justified IPv4 ISP allocation from ARIN > or one of its predecessor registries or can qualify for > an IPv4 ISP allocation under current criteria. > (b) Are currently multihomed for IPv6 or will immediately > become multihomed for IPv6 using a valid assigned > global AS number and will be making reassignments > to other organizations. > (c) Provide ARIN a reasonable technical justification, > indicating why an allocation is necessary, including > the intended purposes for the allocation, and describing > the network infrastructure the allocation will be used to > support. Justification must include a plan detailing assignments > to other organizations or customers for one, two and five year > periods, with a minimum of 50 assignments within 5 years. > 6.5.3 Subsequent Allocations to LIRs > (a) Where possible ARIN will make subsequent allocations by > expanding the existing allocation. > (b) An LIR which can show utilization of 75% or more of their > total address space, or more than 90% of any serving site > shall be entitled to a subsequent allocation. > (c) If ARIN can not expand one or more existing allocations, > ARIN shall make a new allocation based on the initial > allocation criteria above. The LIR is encouraged, but not > required to renumber into the new allocation over time > and return any allocations no longer in use. > Replace section 6.5.4 with the following > 6.5.4 Assignments to end users shall be governed by the same > practices adopted by the community in section 6.5.8 except > that the requirements in 6.5.8.1 do not apply. > > Add the following to 6.5.7 > LIRs which received an allocation under previous policies which is > smaller than what they are entitled to under this policy may receive > a new initial allocation under this policy provided that they agree to > renumber into that new allocation and return their prior allocation(s) > within 5 years. If possible, ARIN will simply expand their existing > allocation rather than requiring renumber and return. From info at arin.net Thu Dec 2 14:02:35 2010 From: info at arin.net (ARIN) Date: Thu, 02 Dec 2010 14:02:35 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 Message-ID: <4CF7ED4B.6080105@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (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. 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, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 124: Clarification of Section 4.2.4.4 Proposal Originator: Martin Hannigan and Chris Grundemann Proposal Version: 1.0 Date: 2 December 2010 Proposal type: Modify, complete replacement of 4.2.4.4 Policy term: Permanent Policy statement: 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, that organization may choose to request up to a 12 month supply of IP addresses. On the date that ARIN receives its last /8 as a result of the IANA executing section 10.4.2.2 of the NRPM and in accordance with the Global Policy for the Allocation of the Remaining IPv4 Address Space, the length of supply that any organization may request from ARIN from that moment forward will be reduced to three months. Any pending request submitted prior to that moment will continue to be eligible for a twelve month supply of addresses as long as need is established within thirty days of that moment. Rationale: ARIN's pending operational practice is that if an organization has a request in the ARIN hostmaster queue for IPv4 resources when the IANA declares the exhaustion phase (10.4.2.2), their request will be automatically truncated from a twelve month supply to a three month supply since policy in effect at the time of exhaustion will apply. 8.3 and 4.2.4.4 are currently "in effect". Example: If an entity is asking for 4 x /24 for a 12 month period and IANA exhaustion occurs, a requester will receive, if justified, 1 x /24. If an entity is asking for 120 x /24 at the time that exhaustion occurs, they would only receive 30 x /24 if justified. If ARIN determines that this same entity would only qualify for 90 of the 120 x /24 requested, then that entity would only receive 22 x /24. ARIN has the equivalent of almost a /8 in at least one reserve, has recently received 2 /8's, received ~391 x /16's as a result of the distribution of "various registries" from the IANA and is guaranteed to receive at least one additional /8 (aggregate of about 92 million individual IPv4 addresses) as a result of the execution of 10.4.2.2 by the IANA. Considering the size of the supply, it would seem prudent to provide for all members needs in a fair and consistent manner as long as possible in order to support the continued orderly transition of the Internet to IPv6. The ARIN AC should review and determine what action if any should be taken at their next available opportunity, or sooner if they deem warranted. From owen at delong.com Thu Dec 2 15:16:35 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 2 Dec 2010 12:16:35 -0800 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <4CF7ED4B.6080105@arin.net> References: <4CF7ED4B.6080105@arin.net> Message-ID: <5D61DFAA-93B5-4491-9586-8F2CA7EACCA5@delong.com> I don't believe this proposal makes enough difference to warrant treating it as an emergency. The event in question will occur prior to the completion of the normal policy cycle. (likely less than a month from now). As such, I oppose this policy in that I believe it will be rendered moot before it could be reasonably applied. Owen On Dec 2, 2010, at 11:02 AM, ARIN wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (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. > > 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, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 124: Clarification of Section 4.2.4.4 > > Proposal Originator: Martin Hannigan and Chris Grundemann > > Proposal Version: 1.0 > > Date: 2 December 2010 > > Proposal type: Modify, complete replacement of 4.2.4.4 > > Policy term: Permanent > > Policy statement: > > 4.2.4.4. Subscriber Members After One Year > > After an organization has been a subscriber member of ARIN for one year, > that organization may choose to request up to a 12 month supply of IP > addresses. > > On the date that ARIN receives its last /8 as a result of the IANA > executing section 10.4.2.2 of the NRPM and in accordance with the Global > Policy for the Allocation of the Remaining IPv4 Address Space, the > length of supply that any organization may request from ARIN from that > moment forward will be reduced to three months. Any pending request > submitted prior to that moment will continue to be eligible for a twelve > month supply of addresses as long as need is established within thirty > days of that moment. > > Rationale: > > ARIN's pending operational practice is that if an organization has a > request in the ARIN hostmaster queue for IPv4 resources when the IANA > declares the exhaustion phase (10.4.2.2), their request will be > automatically truncated from a twelve month supply to a three month > supply since policy in effect at the time of exhaustion will apply. 8.3 > and 4.2.4.4 are currently "in effect". > > Example: If an entity is asking for 4 x /24 for a 12 month period and > IANA exhaustion occurs, a requester will receive, if justified, 1 x /24. > If an entity is asking for 120 x /24 at the time that exhaustion occurs, > they would only receive 30 x /24 if justified. If ARIN determines that > this same entity would only qualify for 90 of the 120 x /24 requested, > then that entity would only receive 22 x /24. > > ARIN has the equivalent of almost a /8 in at least one reserve, has > recently received 2 /8's, received ~391 x /16's as a result of the > distribution of "various registries" from the IANA and is guaranteed to > receive at least one additional /8 (aggregate of about 92 million > individual IPv4 addresses) as a result of the execution of 10.4.2.2 by > the IANA. Considering the size of the supply, it would seem prudent to > provide for all members needs in a fair and consistent manner as long as > possible in order to support the continued orderly transition of the > Internet to IPv6. > > The ARIN AC should review and determine what action if any should be > taken at their next available opportunity, or sooner if they deem warranted. > > > _______________________________________________ > 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 marty at akamai.com Fri Dec 3 08:54:03 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 3 Dec 2010 08:54:03 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <4CF7ED4B.6080105@arin.net> Message-ID: On 12/2/10 2:02 PM, "ARIN" wrote: > Rationale: > [ snip ] > ARIN has the equivalent of almost a /8 in at least one reserve, has > recently received 2 /8's, received ~391 x /16's as a result of the > distribution of "various registries" from the IANA and is guaranteed to > receive at least one additional /8 (aggregate of about 92 million > individual IPv4 addresses) as a result of the execution of 10.4.2.2 by > the IANA. Considering the size of the supply, it would seem prudent to > provide for all members needs in a fair and consistent manner as long as > possible in order to support the continued orderly transition of the > Internet to IPv6. > A more accurate description of "Various Registries": http://www.icann.org/en/correspondence/pawlik-to-vegoda-gerich-23nov10-en.pd f Best, -M< From info at arin.net Fri Dec 3 10:28:18 2010 From: info at arin.net (ARIN) Date: Fri, 03 Dec 2010 10:28:18 -0500 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack Message-ID: <4CF90C92.8070109@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (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. 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, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller Proposal Version: 1 Date: 3 December 2010 Proposal type: modify Policy term: permanent Policy Statement: * Add the following sections to section 4.1: 4.1.2. Efficient Utilization IPv4 addresses are a finite resource and as such are required to be efficiently utilized by resource holders in order to maximize their benefit to the community. 4.1.3. Dual-Stack Dual-stack refers to configuring both an IPv4 and an IPv6 address or network together on the same network infrastructure. All new IPv4 addresses assigned, allocated or transfered to an organization must be deployed on dual-stacked interfaces along with IPv6 addresses. 4.1.4. IPv6 Deployment When addresses are used to provide an Internet facing service, the service must be fully IPv6 accessible (if you deploy an A record, you must also have a AAAA record, and both must answer). * Add the following sentance to the end of sections 4.2.1.6, 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: In accordance with section 4.1.3 and 4.1.4, all new addresses must be deployed on dual-stacked interfaces and all Internet facing services provided by new addresses must be fully IPv6 accessible. * Re-write section 4.2.3.4.1. to: Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria, the dual-stack criteria and must be available via SWIP / RWhois prior to your issuing them additional space. * Add the following section to section 4.2.4: 4.2.4.5. IPv6 Deployment In order to receive additional space ISPs must provide detailed documentation demonstrating that: - for every IPv4 address requested, at least one pre-existing interface is dual stacked, up to 80% of all interfaces and - for every down stream customer site where the new addresses will be deployed, at least one pre-existing down stream customer site is IPv6 enabled, up to 80% of the total customer base. * Add the following to section 4.3.6: 4.3.6.3. IPv6 Deployment In order to receive additional space end-users must provide detailed documentation demonstrating that at least 80% of their existing IPv4 addresses are deployed on dual-stacked interfaces in accordance with section 4.1.3. Rational: In this period of available IPv4 address scarcity and transition to IPv6, IPv4 addresses that are not deployed along with IPv6 are simply not being efficiently utilized. Although we have likely failed to deploy dual-stack in a meaningful way in time to avoid transition problems, we can still choose the correct path for future assignments, allocations and transfers. This proposal has three objectives: -1- Encourage IPv6 deployment prior to and post depletion -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change was to this line]# -3- Improve the utilization of IP addresses It accomplishes these goals by enforcing three basic ideals: -1- ARIN will only make allocations and assignments for networks that have already deployed production IPv6 -2- Any new IPv4 addresses received, must be deployed along side of IPv6 (dual-stacked) -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks The specific requirements to be enforced can be summed up in this way: ~ New addresses must be deployed on dual-stacked interfaces plus one additional pre-existing IPv4-only interface must be dual-stacked per new address, up to 80% of all interfaces. ~ For each down stream customer site where these addresses are deployed, another pre-existing IPv4 only down stream site must also be IPv6 enabled, up to 80% of the total customer base. ~ All end-sites must dual-stack before getting new space. ~ Internet facing services that new IPv4 addresses are used to provide must be fully IPv6 accessible. From scottleibrand at gmail.com Fri Dec 3 10:43:18 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 3 Dec 2010 07:43:18 -0800 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4CF90C92.8070109@arin.net> References: <4CF90C92.8070109@arin.net> Message-ID: <3B43E81D-67BB-4812-80A7-73C4A2070792@gmail.com> What do people feel would be the likely impact of requiring IPv6 deployment in order to receive address transfers under NRPM section 8? It seems likely to me that such a requirement would simply result in many such transfers being pushed outside the RIR system... I think requiring dual-stack deployment to receive addresses directly from ARIN would be a good idea, bit I'm skeptical on requiring them for transfers. Scott On Dec 3, 2010, at 7:28 AM, ARIN wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (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. > > 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, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack > > Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller > > Proposal Version: 1 > > Date: 3 December 2010 > > Proposal type: modify > > Policy term: permanent > > Policy Statement: > > * Add the following sections to section 4.1: > > 4.1.2. Efficient Utilization > > IPv4 addresses are a finite resource and as such are required to be > efficiently utilized by resource holders in order to maximize their > benefit to the community. > > 4.1.3. Dual-Stack > > Dual-stack refers to configuring both an IPv4 and an IPv6 address or > network together on the same network infrastructure. > > All new IPv4 addresses assigned, allocated or transfered to an > organization must be deployed on dual-stacked interfaces along with > IPv6 addresses. > > 4.1.4. IPv6 Deployment > > When addresses are used to provide an Internet facing service, the > service must be fully IPv6 accessible (if you deploy an A record, you > must also have a AAAA record, and both must answer). > > * Add the following sentance to the end of sections 4.2.1.6, > 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: > > In accordance with section 4.1.3 and 4.1.4, all new addresses must be > deployed on dual-stacked interfaces and all Internet facing services > provided by new addresses must be fully IPv6 accessible. > > * Re-write section 4.2.3.4.1. to: > > Reassignment information for prior allocations must show that each > customer meets the 80% utilization criteria, the dual-stack criteria > and must be available via SWIP / RWhois prior to your issuing them > additional space. > > * Add the following section to section 4.2.4: > > 4.2.4.5. IPv6 Deployment > > In order to receive additional space ISPs must provide detailed > documentation demonstrating that: > - for every IPv4 address requested, at least one pre-existing > interface is dual stacked, up to 80% of all interfaces and > - for every down stream customer site where the new addresses will be > deployed, at least one pre-existing down stream customer site is IPv6 > enabled, up to 80% of the total customer base. > > * Add the following to section 4.3.6: > > 4.3.6.3. IPv6 Deployment > > In order to receive additional space end-users must provide detailed > documentation demonstrating that at least 80% of their existing IPv4 > addresses are deployed on dual-stacked interfaces in accordance with > section 4.1.3. > > Rational: > > In this period of available IPv4 address scarcity and transition to > IPv6, IPv4 addresses that are not deployed along with IPv6 are simply > not being efficiently utilized. Although we have likely failed to > deploy dual-stack in a meaningful way in time to avoid transition > problems, we can still choose the correct path for future assignments, > allocations and transfers. > > This proposal has three objectives: > -1- Encourage IPv6 deployment prior to and post depletion > -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change > was to this line]# > -3- Improve the utilization of IP addresses > > It accomplishes these goals by enforcing three basic ideals: > -1- ARIN will only make allocations and assignments for networks that > have already deployed production IPv6 > -2- Any new IPv4 addresses received, must be deployed along side of > IPv6 (dual-stacked) > -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks > > The specific requirements to be enforced can be summed up in this way: > ~ New addresses must be deployed on dual-stacked interfaces plus one > additional pre-existing IPv4-only interface must be dual-stacked per > new address, up to 80% of all interfaces. > ~ For each down stream customer site where these addresses are > deployed, another pre-existing IPv4 only down stream site must also be > IPv6 enabled, up to 80% of the total customer base. > ~ All end-sites must dual-stack before getting new space. > ~ Internet facing services that new IPv4 addresses are used to provide > must be fully IPv6 accessible. > > > > _______________________________________________ > 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 BillD at cait.wustl.edu Fri Dec 3 11:00:26 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 3 Dec 2010 10:00:26 -0600 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4Requires Dual-Stack In-Reply-To: <3B43E81D-67BB-4812-80A7-73C4A2070792@gmail.com> References: <4CF90C92.8070109@arin.net> <3B43E81D-67BB-4812-80A7-73C4A2070792@gmail.com> Message-ID: I've always been reluctant to support policy that dictates configuration or business practice associated with address allocation. After all, we have been very reluctant to even speak about routing policy related to allocation policy. This seems similar to me. I also did not believe that this would stand up to legal challenge...but, I believe that, given the unusual circumstances of runout, that ARIN believes that more stringent and collateral requirements may be fovorably argued. That said, I am concerned for the length and multifaceted nature of this proposal which begs for many separate opportunities for the community to disagree and therefore not achieve overall consensus. Bill Darte > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Friday, December 03, 2010 9:43 AM > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 125: Efficient > Utilization of IPv4Requires Dual-Stack > > What do people feel would be the likely impact of requiring > IPv6 deployment in order to receive address transfers under > NRPM section 8? It seems likely to me that such a requirement > would simply result in many such transfers being pushed > outside the RIR system... > > I think requiring dual-stack deployment to receive addresses > directly from ARIN would be a good idea, bit I'm skeptical on > requiring them for transfers. > > Scott > > On Dec 3, 2010, at 7:28 AM, ARIN wrote: > > > ARIN received the following policy proposal and is posting > it to the > > Public Policy Mailing List (PPML) in accordance with the Policy > > Development Process. > > > > The ARIN Advisory Council (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. > > > > 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, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Policy Proposal 125: Efficient Utilization of IPv4 Requires > Dual-Stack > > > > Proposal Originator: Chris Grundemann, Martin Hannigan, > Jason Schiller > > > > Proposal Version: 1 > > > > Date: 3 December 2010 > > > > Proposal type: modify > > > > Policy term: permanent > > > > Policy Statement: > > > > * Add the following sections to section 4.1: > > > > 4.1.2. Efficient Utilization > > > > IPv4 addresses are a finite resource and as such are required to be > > efficiently utilized by resource holders in order to maximize their > > benefit to the community. > > > > 4.1.3. Dual-Stack > > > > Dual-stack refers to configuring both an IPv4 and an IPv6 > address or > > network together on the same network infrastructure. > > > > All new IPv4 addresses assigned, allocated or transfered to an > > organization must be deployed on dual-stacked interfaces along with > > IPv6 addresses. > > > > 4.1.4. IPv6 Deployment > > > > When addresses are used to provide an Internet facing service, the > > service must be fully IPv6 accessible (if you deploy an A > record, you > > must also have a AAAA record, and both must answer). > > > > * Add the following sentance to the end of sections 4.2.1.6, > > 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: > > > > In accordance with section 4.1.3 and 4.1.4, all new > addresses must be > > deployed on dual-stacked interfaces and all Internet facing > services > > provided by new addresses must be fully IPv6 accessible. > > > > * Re-write section 4.2.3.4.1. to: > > > > Reassignment information for prior allocations must show that each > > customer meets the 80% utilization criteria, the dual-stack > criteria > > and must be available via SWIP / RWhois prior to your issuing them > > additional space. > > > > * Add the following section to section 4.2.4: > > > > 4.2.4.5. IPv6 Deployment > > > > In order to receive additional space ISPs must provide detailed > > documentation demonstrating that: > > - for every IPv4 address requested, at least one pre-existing > > interface is dual stacked, up to 80% of all interfaces and > > - for every down stream customer site where the new > addresses will be > > deployed, at least one pre-existing down stream customer > site is IPv6 > > enabled, up to 80% of the total customer base. > > > > * Add the following to section 4.3.6: > > > > 4.3.6.3. IPv6 Deployment > > > > In order to receive additional space end-users must provide > detailed > > documentation demonstrating that at least 80% of their > existing IPv4 > > addresses are deployed on dual-stacked interfaces in > accordance with > > section 4.1.3. > > > > Rational: > > > > In this period of available IPv4 address scarcity and transition to > > IPv6, IPv4 addresses that are not deployed along with IPv6 > are simply > > not being efficiently utilized. Although we have likely failed to > > deploy dual-stack in a meaningful way in time to avoid transition > > problems, we can still choose the correct path for future > assignments, > > allocations and transfers. > > > > This proposal has three objectives: > > -1- Encourage IPv6 deployment prior to and post depletion > > -2- Enable growth of IPv4 to accelerate IPv6 transition > #[only change > > was to this line]# > > -3- Improve the utilization of IP addresses > > > > It accomplishes these goals by enforcing three basic ideals: > > -1- ARIN will only make allocations and assignments for > networks that > > have already deployed production IPv6 > > -2- Any new IPv4 addresses received, must be deployed along side of > > IPv6 (dual-stacked) > > -3- Firmly encourages deployment of IPv6 in existing IPv4-only > > networks > > > > The specific requirements to be enforced can be summed up > in this way: > > ~ New addresses must be deployed on dual-stacked interfaces > plus one > > additional pre-existing IPv4-only interface must be > dual-stacked per > > new address, up to 80% of all interfaces. > > ~ For each down stream customer site where these addresses are > > deployed, another pre-existing IPv4 only down stream site > must also be > > IPv6 enabled, up to 80% of the total customer base. > > ~ All end-sites must dual-stack before getting new space. > > ~ Internet facing services that new IPv4 addresses are used > to provide > > must be fully IPv6 accessible. > > > > > > > > _______________________________________________ > > 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 Dec 3 11:00:21 2010 From: bill at herrin.us (William Herrin) Date: Fri, 3 Dec 2010 11:00:21 -0500 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4CF90C92.8070109@arin.net> References: <4CF90C92.8070109@arin.net> Message-ID: On Fri, Dec 3, 2010 at 10:28 AM, ARIN wrote: > Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack Too much at once. Way too big a step from current policy. Start small: efficient IPv4 utilization justified by BGP-routed allocations requires that you have received and routed an IPv6 allocation. You don't have to have done anything more with it. Yet. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Fri Dec 3 11:10:22 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 3 Dec 2010 08:10:22 -0800 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4CF90C92.8070109@arin.net> References: <4CF90C92.8070109@arin.net> Message-ID: <20101203161022.GA77297@ussenterprise.ufp.org> In a message written on Fri, Dec 03, 2010 at 10:28:18AM -0500, ARIN wrote: > When addresses are used to provide an Internet facing service, the > service must be fully IPv6 accessible (if you deploy an A record, you > must also have a AAAA record, and both must answer). There's a rather large loophole here. If I don't do DNS for the service I deploy, I don't have to dual stack. No A, no AAAA. I would expect, for instance, that many end-user providers might chose to not do any DNS for a residential user if it got them out of providing IPv6. There is also the problem that some folks may prefer to deploy www.foo.com (A record) and ipv6.foo.com (AAAA record) for now, even if fully dual stacked at L3. This policy would seem to penalize those fully dual stacked folks, simply becaue they use two DNS labels. In short, ARIN doesn't play in DNS, and it's one step removed from the issue at hand. This policy needs to be written to insure the L3 network is dual stacked, not that those addresses appear in a service like DNS. > In order to receive additional space end-users must provide detailed > documentation demonstrating that at least 80% of their existing IPv4 > addresses are deployed on dual-stacked interfaces in accordance with > section 4.1.3. Here's where you may be on to something. In a theoretical sense I like the concept that you have to show 80% of your IPv4 layer 3 things are dual stacked with IPv6 layer 3 things on the same interfaces. The problem is, when we move out of the theoretical, I don't understand how this has any meaningful effect. We can't use such a rule to prohibit assigning IPv6 space or we put people in a Catch 22. We can use it to deny more IPv4 space, of which we'll be out of the free pool before this policy can be implemented. Thus the only result of this policy is to prevent people from buying IPv4 space in the market (paid transfers, whatever) unless they are dual stacked. Except I thought the entire point of the market was to give folks you couldn't/wouldn't/shouldn't dual stack a way out, if perhaps an expensive one. This would have been an excellent idea 5 years ago, with a phased in dual-stack rate (20% the first year, 40% the second year, etc) to encourage people to get dual-stacked before run out. Now that we are at run-out it doesn't seem to do anything useful to me, and may undermine the primary purpose of the market. -- 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 Fri Dec 3 13:42:57 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 3 Dec 2010 11:42:57 -0700 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: References: <4CF71C22.3000404@umn.edu> Message-ID: On Wed, Dec 1, 2010 at 22:13, William Herrin wrote: > ...the AC should plan to meet > within 48 hours of that allocation to determine whether to recommend > that the board adopt them under emergency rules and I would hope the > board would arrange to be able to quickly respond as well. I second Bill's suggestion that the AC hold a meeting at the moment of IANA runout but would expand the suggestion so that all policy changes proposed at that time be considered for emergency action. ~Chris > > -- > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From marty at akamai.com Fri Dec 3 13:44:27 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 3 Dec 2010 13:44:27 -0500 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: Message-ID: On 12/3/10 1:42 PM, "Chris Grundemann" wrote: > On Wed, Dec 1, 2010 at 22:13, William Herrin wrote: > >> ...the AC should plan to meet >> within 48 hours of that allocation to determine whether to recommend >> that the board adopt them under emergency rules and I would hope the >> board would arrange to be able to quickly respond as well. > > I second Bill's suggestion that the AC hold a meeting at the moment of > IANA runout but would expand the suggestion so that all policy changes > proposed at that time be considered for emergency action. > Seems perfectly reasonable considering that they have to actual meet to determine if something is or isn't critical. +1 -M< From tony at lava.net Fri Dec 3 14:34:51 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 3 Dec 2010 09:34:51 -1000 (HST) Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: References: <4CF71C22.3000404@umn.edu> Message-ID: On Fri, 3 Dec 2010, Chris Grundemann wrote: > On Wed, Dec 1, 2010 at 22:13, William Herrin wrote: > >> ...the AC should plan to meet >> within 48 hours of that allocation to determine whether to recommend >> that the board adopt them under emergency rules and I would hope the >> board would arrange to be able to quickly respond as well. > > I second Bill's suggestion that the AC hold a meeting at the moment of > IANA runout but would expand the suggestion so that all policy changes > proposed at that time be considered for emergency action. Haste makes waste. Emergency meetings do have a purpose but I'm wondering about this one. What will you know then that you don't know now that would significantly change any actions that could be better planned now rather than then? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jbates at brightok.net Fri Dec 3 14:48:03 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 03 Dec 2010 13:48:03 -0600 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: References: <4CF71C22.3000404@umn.edu> Message-ID: <4CF94973.2070603@brightok.net> On 12/3/2010 1:34 PM, Antonio Querubin wrote: > Haste makes waste. Emergency meetings do have a purpose but I'm > wondering about this one. What will you know then that you don't know > now that would significantly change any actions that could be better > planned now rather than then? I think the concern is that policies are being worked on, but if they wait for the regular scheduled meetings, it may be to late to activate any of the policies. This is a suggestion that the AC meet when criteria is met, so that such policies can at least be processed and possibly (still not guaranteed) acted upon. The final assignment from IANA seems like a perfect time for every RIR to analyze where they stand and what policies need to be adopted for their remaining address space. For ARIN, this means the AC must meet. Jack From Wesley.E.George at sprint.com Fri Dec 3 14:54:41 2010 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 3 Dec 2010 19:54:41 +0000 Subject: [arin-ppml] Emergency PDP process In-Reply-To: References: <4CF71C22.3000404@umn.edu> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E039B61@PLSWM12A.ad.sprint.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Friday, December 03, 2010 1:43 PM > To: William Herrin > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Props. 122 + 123 process? > > I second Bill's suggestion that the AC hold a meeting at the moment of > IANA runout but would expand the suggestion so that all policy changes > proposed at that time be considered for emergency action. > Good suggestion. However, prior to that, we have a problem. I think that this whole discussion throws into sharp relief the absence of implementation details around how to determine a legitimate emergency based on the current text in 7.1 of the PDP. Perhaps the AC, board, PDP committee and ARIN legal counsel should put their heads together on this ASAP and bring out a draft recommendation for a series of tests that can be used to justify any emergency policy. These would be either questions that must be answered, objective standards to define a problem, etc. Put it before the community for comment. Even if it's not formally added to the PDP, or not added in time for this round of emergencies, it would really help to have some of that rigor. Chances are quite good that every policy recommendation that might be considered an emergency will be equally polarizing within the community, and it would be helpful to not have to rely solely on (charged, emotional) rhetoric on the part of those for and against the issue to determine whether something is actually an emergency. "I'll know it when I see it" isn't good enough in this case I don't think... Put another way - AC members: assume that you have to make a recommendation to the board tomorrow on these two emergency policies. I assume that this would take the form of 2 votes: First, should prop X be treated as an emergency or deferred to the next PP Meeting? Follow-on, if the underlying issue prop X regards is an emergency, then should prop X be implemented? What questions do you ask of the authors, of yourselves, of your fellow members, and of the community to make your decision as to whether they're emergencies? Note that I'm thinking in general terms here on how you would answer question #1, using these policies as an example, not looking for questions specific to should you/should you not implement. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6793 bytes Desc: not available URL: From owen at delong.com Fri Dec 3 16:07:27 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Dec 2010 13:07:27 -0800 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: <4CF94973.2070603@brightok.net> References: <4CF71C22.3000404@umn.edu> <4CF94973.2070603@brightok.net> Message-ID: <3F809F6C-C4C6-4B7F-AD6C-72EBB8A89DF3@delong.com> The next regularly scheduled AC meeting is 12/16. I suspect this will be reasonably close to the IANA runout date one way or another. I suspect this issue can be addressed appropriately at that meeting. Owen (Speaking only for myself and not on behalf of the AC) On Dec 3, 2010, at 11:48 AM, Jack Bates wrote: > On 12/3/2010 1:34 PM, Antonio Querubin wrote: >> Haste makes waste. Emergency meetings do have a purpose but I'm wondering about this one. What will you know then that you don't know now that would significantly change any actions that could be better planned now rather than then? > > I think the concern is that policies are being worked on, but if they wait for the regular scheduled meetings, it may be to late to activate any of the policies. This is a suggestion that the AC meet when criteria is met, so that such policies can at least be processed and possibly (still not guaranteed) acted upon. The final assignment from IANA seems like a perfect time for every RIR to analyze where they stand and what policies need to be adopted for their remaining address space. For ARIN, this means the AC must meet. > > > Jack > > > > _______________________________________________ > 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 BillD at cait.wustl.edu Fri Dec 3 16:26:12 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 3 Dec 2010 15:26:12 -0600 Subject: [arin-ppml] Emergency PDP process References: <4CF71C22.3000404@umn.edu> <54E900DC635DAB4DB7A6D799B3C4CD8E039B61@PLSWM12A.ad.sprint.com> Message-ID: I believe that this is a fine set of questions which should be answered and I think the timeframe is overdue. It should have been accomplished after the first use of the emergency powers of the Board. I understand from subsequent statements that they plan to be more deliberate next time....but whether there will be 'tests' as you say, I am not aware. Personally thought, I think that at IANA run out, there will be time to consider all these measures and proposals. John Curran, at an event last evening stated that he expects 6 mos. or more until ARIN run out. I believe emergency constitutes...MUST do something NOW or else OBVIOUS and CERTAIN burdens will be sustained and that those burdens will be of SUBSTANTIAL magnitude without reasonable alternatives. Perhaps that's an arguable start. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of George, Wes E [NTK] Sent: Fri 12/3/2010 1:54 PM To: Chris Grundemann; William Herrin Cc: arin-ppml at arin.net Subject: [arin-ppml] Emergency PDP process I think that this whole discussion throws into sharp relief the absence of implementation details around how to determine a legitimate emergency based on the current text in 7.1 of the PDP. Perhaps the AC, board, PDP committee and ARIN legal counsel should put their heads together on this ASAP and bring out a draft recommendation for a series of tests that can be used to justify any emergency policy. These would be either questions that must be answered, objective standards to define a problem, etc. Put it before the community for comment. Even if it's not formally added to the PDP, or not added in time for this round of emergencies, it would really help to have some of that rigor. Chances are quite good that every policy recommendation that might be considered an emergency will be equally polarizing within the community, and it would be helpful to not have to rely solely on (charged, emotional) rhetoric on the part of those for and against the issue to determine whether something is actually an emergency. "I'll know it when I see it" isn't good enough in this case I don't think... Put another way - AC members: assume that you have to make a recommendation to the board tomorrow on these two emergency policies. I assume that this would take the form of 2 votes: First, should prop X be treated as an emergency or deferred to the next PP Meeting? Follow-on, if the underlying issue prop X regards is an emergency, then should prop X be implemented? What questions do you ask of the authors, of yourselves, of your fellow members, and of the community to make your decision as to whether they're emergencies? Note that I'm thinking in general terms here on how you would answer question #1, using these policies as an example, not looking for questions specific to should you/should you not implement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Fri Dec 3 16:25:04 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 3 Dec 2010 16:25:04 -0500 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: <4CF94973.2070603@brightok.net> Message-ID: On 12/3/10 2:48 PM, "Jack Bates" wrote: > On 12/3/2010 1:34 PM, Antonio Querubin wrote: >> Haste makes waste. Emergency meetings do have a purpose but I'm >> wondering about this one. What will you know then that you don't know >> now that would significantly change any actions that could be better >> planned now rather than then? > > I think the concern is that policies are being worked on, but if they > wait for the regular scheduled meetings, it may be to late to activate > any of the policies. This is a suggestion that the AC meet when criteria > is met, so that such policies can at least be processed and possibly > (still not guaranteed) acted upon. The final assignment from IANA seems > like a perfect time for every RIR to analyze where they stand and what > policies need to be adopted for their remaining address space. For ARIN, > this means the AC must meet. It would seem to me that such a meeting ought to be held in anticipation of the IANA runout since we know that it's going to happen and we know that it will happen sooner than later. Trying to reverse things post implementation is harder than stopping them beforehand, IMHO. It also leaves a huge gap of uncertainty if we wait until the actual event transpires. Best, -M< From marty at akamai.com Fri Dec 3 16:28:50 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 3 Dec 2010 16:28:50 -0500 Subject: [arin-ppml] Emergency PDP process In-Reply-To: Message-ID: On 12/3/10 4:26 PM, "Bill Darte" wrote: [ clip ] > > Personally thought, I think that at IANA run out, there will be time to > consider all these measures and proposals. John Curran, at an event last > evening stated that he expects 6 mos. or more until ARIN run out. > Proposal 124 directly challenges that assertion and I think that it would be a disservice to the entities in the request queue at the time of exhaustion and implementation to leave them hanging in the air of uncertainty. http://lists.arin.net/pipermail/arin-ppml/2010-December/018936.html Best, -M< From john.sweeting at twcable.com Fri Dec 3 16:30:52 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Fri, 3 Dec 2010 16:30:52 -0500 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: Message-ID: Marty, I am really interested in hearing what the uncertainty is that you reference below. The next scheduled meeting for the AC is Dec 16 and I do not think that IANA run out will happen before that. More and more I am interested in your exact agenda, care to share with all of us? Thanks, John ++ On 12/3/10 4:25 PM, "Hannigan, Martin" wrote: On 12/3/10 2:48 PM, "Jack Bates" wrote: > On 12/3/2010 1:34 PM, Antonio Querubin wrote: >> Haste makes waste. Emergency meetings do have a purpose but I'm >> wondering about this one. What will you know then that you don't know >> now that would significantly change any actions that could be better >> planned now rather than then? > > I think the concern is that policies are being worked on, but if they > wait for the regular scheduled meetings, it may be to late to activate > any of the policies. This is a suggestion that the AC meet when criteria > is met, so that such policies can at least be processed and possibly > (still not guaranteed) acted upon. The final assignment from IANA seems > like a perfect time for every RIR to analyze where they stand and what > policies need to be adopted for their remaining address space. For ARIN, > this means the AC must meet. It would seem to me that such a meeting ought to be held in anticipation of the IANA runout since we know that it's going to happen and we know that it will happen sooner than later. Trying to reverse things post implementation is harder than stopping them beforehand, IMHO. It also leaves a huge gap of uncertainty if we wait until the actual event transpires. Best, -M< _______________________________________________ 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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From john.sweeting at twcable.com Fri Dec 3 16:32:35 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Fri, 3 Dec 2010 16:32:35 -0500 Subject: [arin-ppml] Emergency PDP process In-Reply-To: Message-ID: There is no uncertainty, the policy is what it is. On 12/3/10 4:28 PM, "Hannigan, Martin" wrote: On 12/3/10 4:26 PM, "Bill Darte" wrote: [ clip ] > > Personally thought, I think that at IANA run out, there will be time to > consider all these measures and proposals. John Curran, at an event last > evening stated that he expects 6 mos. or more until ARIN run out. > Proposal 124 directly challenges that assertion and I think that it would be a disservice to the entities in the request queue at the time of exhaustion and implementation to leave them hanging in the air of uncertainty. http://lists.arin.net/pipermail/arin-ppml/2010-December/018936.html Best, -M< _______________________________________________ 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 john.sweeting at twcable.com Fri Dec 3 16:34:14 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Fri, 3 Dec 2010 16:34:14 -0500 Subject: [arin-ppml] Emergency PDP process In-Reply-To: Message-ID: And there was community consensus for that policy IMHO. Thanks. ++ On 12/3/10 4:32 PM, "John Sweeting" wrote: There is no uncertainty, the policy is what it is. On 12/3/10 4:28 PM, "Hannigan, Martin" wrote: On 12/3/10 4:26 PM, "Bill Darte" wrote: [ clip ] > > Personally thought, I think that at IANA run out, there will be time to > consider all these measures and proposals. John Curran, at an event last > evening stated that he expects 6 mos. or more until ARIN run out. > Proposal 124 directly challenges that assertion and I think that it would be a disservice to the entities in the request queue at the time of exhaustion and implementation to leave them hanging in the air of uncertainty. http://lists.arin.net/pipermail/arin-ppml/2010-December/018936.html Best, -M< _______________________________________________ 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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jbates at brightok.net Fri Dec 3 16:35:00 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 03 Dec 2010 15:35:00 -0600 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: <3F809F6C-C4C6-4B7F-AD6C-72EBB8A89DF3@delong.com> References: <4CF71C22.3000404@umn.edu> <4CF94973.2070603@brightok.net> <3F809F6C-C4C6-4B7F-AD6C-72EBB8A89DF3@delong.com> Message-ID: <4CF96284.6000406@brightok.net> On 12/3/2010 3:07 PM, Owen DeLong wrote: > The next regularly scheduled AC meeting is 12/16. I suspect this will be reasonably close to the IANA runout date one way or another. > > I suspect this issue can be addressed appropriately at that meeting. > I guess I should have checked. I thought the next meeting was around April. 12/16 would definitely be close enough to determine emergency measures and if another session would be necessary in the near future. Jack From marty at akamai.com Fri Dec 3 16:35:21 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 3 Dec 2010 16:35:21 -0500 Subject: [arin-ppml] Emergency PDP process In-Reply-To: Message-ID: John, If we use the same method of gauging consensus that we use for others, one would be able to say that there's consensus for everything in the queue. Best, -M< On 12/3/10 4:34 PM, "Sweeting, John" wrote: > And there was community consensus for that policy IMHO. Thanks. > > ++ > > > On 12/3/10 4:32 PM, "John Sweeting" wrote: > > There is no uncertainty, the policy is what it is. > > > On 12/3/10 4:28 PM, "Hannigan, Martin" wrote: > > > > > > On 12/3/10 4:26 PM, "Bill Darte" wrote: > > > [ clip ] > >> >> Personally thought, I think that at IANA run out, there will be time to >> consider all these measures and proposals. John Curran, at an event last >> evening stated that he expects 6 mos. or more until ARIN run out. >> > > > Proposal 124 directly challenges that assertion and I think that it would be > a disservice to the entities in the request queue at the time of exhaustion > and implementation to leave them hanging in the air of uncertainty. > > http://lists.arin.net/pipermail/arin-ppml/2010-December/018936.html > > > Best, > > -M< > > > > _______________________________________________ > 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 and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. From john.sweeting at twcable.com Fri Dec 3 16:39:14 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Fri, 3 Dec 2010 16:39:14 -0500 Subject: [arin-ppml] Emergency PDP process In-Reply-To: Message-ID: Marty, I think your viewpoints will change considerably over the next few months, once you have the opportunity to be involved in the AC portion of the policy process. Looking forward to having you as part of the team. On 12/3/10 4:35 PM, "Hannigan, Martin" wrote: John, If we use the same method of gauging consensus that we use for others, one would be able to say that there's consensus for everything in the queue. Best, -M< On 12/3/10 4:34 PM, "Sweeting, John" wrote: > And there was community consensus for that policy IMHO. Thanks. > > ++ > > > On 12/3/10 4:32 PM, "John Sweeting" wrote: > > There is no uncertainty, the policy is what it is. > > > On 12/3/10 4:28 PM, "Hannigan, Martin" wrote: > > > > > > On 12/3/10 4:26 PM, "Bill Darte" wrote: > > > [ clip ] > >> >> Personally thought, I think that at IANA run out, there will be time to >> consider all these measures and proposals. John Curran, at an event last >> evening stated that he expects 6 mos. or more until ARIN run out. >> > > > Proposal 124 directly challenges that assertion and I think that it would be > a disservice to the entities in the request queue at the time of exhaustion > and implementation to leave them hanging in the air of uncertainty. > > http://lists.arin.net/pipermail/arin-ppml/2010-December/018936.html > > > Best, > > -M< > > > > _______________________________________________ > 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 and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From john.sweeting at twcable.com Fri Dec 3 16:40:59 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Fri, 3 Dec 2010 16:40:59 -0500 Subject: [arin-ppml] Props. 122 + 123 process? In-Reply-To: <4CF96284.6000406@brightok.net> Message-ID: Jack, that would be the next ARIN meeting but the AC actually meets the 3rd Thursday of every month and more often if necessary. You can always ping any of the AC members to include myself if you have any questions. Thanks. On 12/3/10 4:35 PM, "Jack Bates" wrote: On 12/3/2010 3:07 PM, Owen DeLong wrote: > The next regularly scheduled AC meeting is 12/16. I suspect this will be reasonably close to the IANA runout date one way or another. > > I suspect this issue can be addressed appropriately at that meeting. > I guess I should have checked. I thought the next meeting was around April. 12/16 would definitely be close enough to determine emergency measures and if another session would be necessary in the near future. Jack _______________________________________________ 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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From owen at delong.com Fri Dec 3 16:45:31 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Dec 2010 13:45:31 -0800 Subject: [arin-ppml] Emergency PDP process In-Reply-To: References: Message-ID: <62255E3B-4779-4983-B147-8670C7C75952@delong.com> I strongly disagree with that assertion. Owen On Dec 3, 2010, at 1:35 PM, Hannigan, Martin wrote: > > > John, > > If we use the same method of gauging consensus that we use for others, one > would be able to say that there's consensus for everything in the queue. > > Best, > > -M< > > > > > > On 12/3/10 4:34 PM, "Sweeting, John" wrote: > >> And there was community consensus for that policy IMHO. Thanks. >> >> ++ >> >> >> On 12/3/10 4:32 PM, "John Sweeting" wrote: >> >> There is no uncertainty, the policy is what it is. >> >> >> On 12/3/10 4:28 PM, "Hannigan, Martin" wrote: >> >> >> >> >> >> On 12/3/10 4:26 PM, "Bill Darte" wrote: >> >> >> [ clip ] >> >>> >>> Personally thought, I think that at IANA run out, there will be time to >>> consider all these measures and proposals. John Curran, at an event last >>> evening stated that he expects 6 mos. or more until ARIN run out. >>> >> >> >> Proposal 124 directly challenges that assertion and I think that it would be >> a disservice to the entities in the request queue at the time of exhaustion >> and implementation to leave them hanging in the air of uncertainty. >> >> http://lists.arin.net/pipermail/arin-ppml/2010-December/018936.html >> >> >> Best, >> >> -M< >> >> >> >> _______________________________________________ >> 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 and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject to >> copyright belonging to Time Warner Cable. This E-mail is intended solely for >> the use of the individual or entity to which it is addressed. If you are not >> the intended recipient of this E-mail, you are hereby notified that any >> dissemination, distribution, copying, or action taken in relation to the >> contents of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify the sender >> immediately and permanently delete the original and any copy of this E-mail >> and any printout. > > _______________________________________________ > 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 marty at akamai.com Fri Dec 3 17:03:46 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 3 Dec 2010 17:03:46 -0500 Subject: [arin-ppml] Emergency PDP process In-Reply-To: Message-ID: John, My motivation, besides wanting the Internet to be able to successfully transition to IPv6, is that I think that AC members should be seen more than they should be heard with respect to policy writing and intend to follow that doctrine. Hence, 122, 123 and 124 now. I also consider them to require urgency since they deal with specific issues related to IANA exhaustion and ARIN depletion. Nothing surprising here. If 12/16 is good enough for you, it's good enough for me. I never made a suggestion that you should do anything other than insure that these get air time prior to IANA exhaustion and implementation of policy that was, in Internet time, written a long while ago. As you noted, things changes on a bi-monthly basis. So do opinions. Best, -M< On 12/3/10 4:39 PM, "Sweeting, John" wrote: > Marty, > > I think your viewpoints will change considerably over the next few months, > once you have the opportunity to be involved in the AC portion of the policy > process. Looking forward to having you as part of the team. > > > > > On 12/3/10 4:35 PM, "Hannigan, Martin" wrote: > > > > > John, > > If we use the same method of gauging consensus that we use for others, one > would be able to say that there's consensus for everything in the queue. > > Best, > > -M< > > > > > > On 12/3/10 4:34 PM, "Sweeting, John" wrote: > >> And there was community consensus for that policy IMHO. Thanks. >> >> ++ >> >> >> On 12/3/10 4:32 PM, "John Sweeting" wrote: >> >> There is no uncertainty, the policy is what it is. >> >> >> On 12/3/10 4:28 PM, "Hannigan, Martin" wrote: >> >> >> >> >> >> On 12/3/10 4:26 PM, "Bill Darte" wrote: >> >> >> [ clip ] >> >>> >>> Personally thought, I think that at IANA run out, there will be time to >>> consider all these measures and proposals. John Curran, at an event last >>> evening stated that he expects 6 mos. or more until ARIN run out. >>> >> >> >> Proposal 124 directly challenges that assertion and I think that it would be >> a disservice to the entities in the request queue at the time of exhaustion >> and implementation to leave them hanging in the air of uncertainty. >> >> http://lists.arin.net/pipermail/arin-ppml/2010-December/018936.html >> >> >> Best, >> >> -M< >> >> >> >> _______________________________________________ >> 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 and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject to >> copyright belonging to Time Warner Cable. This E-mail is intended solely for >> the use of the individual or entity to which it is addressed. If you are not >> the intended recipient of this E-mail, you are hereby notified that any >> dissemination, distribution, copying, or action taken in relation to the >> contents of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify the sender >> immediately and permanently delete the original and any copy of this E-mail >> and any printout. > > > > ________________________________ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. From jcurran at arin.net Fri Dec 3 17:26:31 2010 From: jcurran at arin.net (John Curran) Date: Fri, 3 Dec 2010 22:26:31 +0000 Subject: [arin-ppml] Emergency PDP process In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E039B61@PLSWM12A.ad.sprint.com> References: <4CF71C22.3000404@umn.edu> <54E900DC635DAB4DB7A6D799B3C4CD8E039B61@PLSWM12A.ad.sprint.com> Message-ID: <6C0566ED-4C37-414C-ABD4-E74BB6006F34@corp.arin.net> On Dec 3, 2010, at 2:54 PM, George, Wes E [NTK] wrote: > I think that this whole discussion throws into sharp relief the absence of > implementation details around how to determine a legitimate emergency based > on the current text in 7.1 of the PDP. The lack of a definitive test for an "emergency" should not be surprising: I believe that the emergency policy mechanism exists to handle imminent catastrophe situations which would otherwise prevent ARIN from performing its mission of technical coordination and management of Internet number resources, or cause ARIN's performance of its mission to be contrary to the principle of stewardship. > Perhaps the AC, board, PDP committee and ARIN legal counsel should put their > heads together on this ASAP and bring out a draft recommendation for a series > of tests that can be used to justify any emergency policy. These would be either > questions that must be answered, objective standards to define a problem, etc. > Put it before the community for comment. Even if it's not formally added to > the PDP, or not added in time for this round of emergencies, it would really > help to have some of that rigor. Chances are quite good that every policy > recommendation that might be considered an emergency will be equally > polarizing within the community, and it would be helpful to not have to rely > solely on (charged, emotional) rhetoric on the part of those for and against > the issue to determine whether something is actually an emergency. "I'll > know it when I see it" isn't good enough in this case I don't think... ARIN performing allocations according to community-developed policy is the status quo. As CEO, I know would recommend to the Board for the adoption of emergency policy under circumstances where the existing policy could no longer be followed (e.g. in response to unforeseen legal developments, or due to an action at IETF/IANA/ICANN which prevented ARIN following our policies). I also might be swayed to recommend emergency policy if the implementation of a policy turned out to be directly contrary to apparent intent of the community or placed the organization at grave risk as a result. That doesn't mean that there aren't other circumstances which might also warrant emergency policy, only that it's extremely difficult to establish the criteria in advance. The ARIN Board has not discussed specific criteria by which it would judge emergency policy, so I cannot not provide any additional guidance, but I hope my particular examples prove helpful. Respectfully, /John John Curran President and CEO ARIN p.s. I'll note that there is also a specific section of the PDP (7.2) to allow for policy suspension if following an already adopted policy will cause "significant problems", and this appears to be to be a lower barrier (but again without specific criteria for evaluation) From john.sweeting at twcable.com Fri Dec 3 17:53:37 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Fri, 3 Dec 2010 17:53:37 -0500 Subject: [arin-ppml] Emergency PDP process Message-ID: <448EDFBA-56EB-4EB7-9B03-E94FBD1FEFD5@twcable.com> Thanks for the clarification, good to see we are on the same page. I was not sure what you wanted done. Enjoy the weekend. ----- Reply message ----- From: "Hannigan, Martin" Date: Fri, Dec 3, 2010 5:03 pm Subject: [arin-ppml] Emergency PDP process To: "Sweeting, John" , "Bill Darte" , "George, Wes E [NTK]" , "Chris Grundemann" , "William Herrin" Cc: "arin-ppml at arin.net" John, My motivation, besides wanting the Internet to be able to successfully transition to IPv6, is that I think that AC members should be seen more than they should be heard with respect to policy writing and intend to follow that doctrine. Hence, 122, 123 and 124 now. I also consider them to require urgency since they deal with specific issues related to IANA exhaustion and ARIN depletion. Nothing surprising here. If 12/16 is good enough for you, it's good enough for me. I never made a suggestion that you should do anything other than insure that these get air time prior to IANA exhaustion and implementation of policy that was, in Internet time, written a long while ago. As you noted, things changes on a bi-monthly basis. So do opinions. Best, -M< On 12/3/10 4:39 PM, "Sweeting, John" wrote: > Marty, > > I think your viewpoints will change considerably over the next few months, > once you have the opportunity to be involved in the AC portion of the policy > process. Looking forward to having you as part of the team. > > > > > On 12/3/10 4:35 PM, "Hannigan, Martin" wrote: > > > > > John, > > If we use the same method of gauging consensus that we use for others, one > would be able to say that there's consensus for everything in the queue. > > Best, > > -M< > > > > > > On 12/3/10 4:34 PM, "Sweeting, John" wrote: > >> And there was community consensus for that policy IMHO. Thanks. >> >> ++ >> >> >> On 12/3/10 4:32 PM, "John Sweeting" wrote: >> >> There is no uncertainty, the policy is what it is. >> >> >> On 12/3/10 4:28 PM, "Hannigan, Martin" wrote: >> >> >> >> >> >> On 12/3/10 4:26 PM, "Bill Darte" wrote: >> >> >> [ clip ] >> >>> >>> Personally thought, I think that at IANA run out, there will be time to >>> consider all these measures and proposals. John Curran, at an event last >>> evening stated that he expects 6 mos. or more until ARIN run out. >>> >> >> >> Proposal 124 directly challenges that assertion and I think that it would be >> a disservice to the entities in the request queue at the time of exhaustion >> and implementation to leave them hanging in the air of uncertainty. >> >> http://lists.arin.net/pipermail/arin-ppml/2010-December/018936.html >> >> >> Best, >> >> -M< >> >> >> >> _______________________________________________ >> 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 and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or subject to >> copyright belonging to Time Warner Cable. This E-mail is intended solely for >> the use of the individual or entity to which it is addressed. If you are not >> the intended recipient of this E-mail, you are hereby notified that any >> dissemination, distribution, copying, or action taken in relation to the >> contents of and attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify the sender >> immediately and permanently delete the original and any copy of this E-mail >> and any printout. > > > > ________________________________ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jcurran at arin.net Fri Dec 3 18:03:01 2010 From: jcurran at arin.net (John Curran) Date: Fri, 3 Dec 2010 23:03:01 +0000 Subject: [arin-ppml] Processing existing requests in queue, policy changes & events (re: Policy Proposal 124: Clarification of Section 4.2.4.4) In-Reply-To: <4CF7ED4B.6080105@arin.net> References: <4CF7ED4B.6080105@arin.net> Message-ID: For sake of clarity: ARIN considers number resource requests based on the adopted Network Resource Policy Manual (NRPM) at the time of the request submission. This means that we have, as necessary, grandfathered those existing requests currently in process when number resource policy becomes more stringent due to new policy adoption. The language in NRPM 4.2.4.4 is from policy 2009-8, which was adopted in 13 January 2010. Any ISP additional requests submitted after 13 Jan 2010 are subject to the entire policy language contained therein, including the language limiting request size as appropriate both before and after the final /8 allocation. Upon ARIN receiving its final "/8", we will no longer consider requests for 12-month supply to be valid and hence would not allow them to complete (although will obviously work with these organizations to promptly recast their request for 3-month supply instead.) We do protect those requests in the queue from policy changes, but this is not a policy change but clearly foreseeable event in number resource management which is already specified in policy 2009-8, as adopted in the NRPM of 13 January 2010. If the community wishes suspend that aspect of adopted policy 2009-8 for those requests in process at the time, it would indeed take a specific recommendation of the ARIN Advisory Council for this to be brought to the ARIN Board for action. /John John Curran President and CEO ARIN From andrew.koch at gawul.net Fri Dec 3 22:56:15 2010 From: andrew.koch at gawul.net (Andrew Koch) Date: Fri, 3 Dec 2010 21:56:15 -0600 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4CF90C92.8070109@arin.net> References: <4CF90C92.8070109@arin.net> Message-ID: While I like the encouragement intent of this policy, I see this may be problematic for those folks that decide that deploying parallel systems to implement IPv6 is better for their situation. For example, I might choose to leave my existing IPv4 server farm as-is (possibly depreciating them as IPv4 eventually fades away) and deploy a second set of servers specifically dedicated to IPv6. While I end up providing service both to v4 and v6 addresses, this policy will penalize me for deciding to use this method of deployment. Andrew Koch From frnkblk at iname.com Sat Dec 4 16:39:34 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 4 Dec 2010 15:39:34 -0600 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4CF90C92.8070109@arin.net> Message-ID: Rather than emphasize the dual-stack, perhaps real-world usage of IPv6 on hosts instead? Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Koch Sent: Friday, December 03, 2010 9:56 PM To: ARIN-PPML at arin.net Subject: Re: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack While I like the encouragement intent of this policy, I see this may be problematic for those folks that decide that deploying parallel systems to implement IPv6 is better for their situation. For example, I might choose to leave my existing IPv4 server farm as-is (possibly depreciating them as IPv4 eventually fades away) and deploy a second set of servers specifically dedicated to IPv6. While I end up providing service both to v4 and v6 addresses, this policy will penalize me for deciding to use this method of deployment. Andrew Koch _______________________________________________ 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 frnkblk at iname.com Sat Dec 4 16:43:48 2010 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 4 Dec 2010 15:43:48 -0600 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4CF90C92.8070109@arin.net> Message-ID: I understand your concerns, but why should requestor have an unencumbered right to the last crumbs of IPv4 if they haven't made an effort to build out some level of IPv4? Rather than seeing it as punishment for those who haven't deployed IPv6, one could see it as a reward for those who have been hard at work. And if others want to share in that "goldmine", they can if they put out some effort. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Friday, December 03, 2010 10:00 AM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack On Fri, Dec 3, 2010 at 10:28 AM, ARIN wrote: > Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack Too much at once. Way too big a step from current policy. Start small: efficient IPv4 utilization justified by BGP-routed allocations requires that you have received and routed an IPv6 allocation. You don't have to have done anything more with it. Yet. -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 Wesley.E.George at sprint.com Mon Dec 6 12:35:00 2010 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Mon, 6 Dec 2010 17:35:00 +0000 Subject: [arin-ppml] Emergency PDP process In-Reply-To: <6C0566ED-4C37-414C-ABD4-E74BB6006F34@corp.arin.net> References: <4CF71C22.3000404@umn.edu> <54E900DC635DAB4DB7A6D799B3C4CD8E039B61@PLSWM12A.ad.sprint.com> <6C0566ED-4C37-414C-ABD4-E74BB6006F34@corp.arin.net> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E03ABED@PLSWM12A.ad.sprint.com> John - thanks for your reply - some comments below inline. > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Friday, December 03, 2010 5:27 PM > To: George, Wes E [NTK] > Cc: arin-ppml at arin.net List > Subject: Re: [arin-ppml] Emergency PDP process > I believe that the emergency policy mechanism exists to handle imminent > catastrophe situations which would otherwise prevent ARIN from > performing > its mission of technical coordination and management of Internet number > resources, or cause ARIN's performance of its mission to be contrary to > the principle of stewardship. [WES] This is actually a pretty good start on a set of definitive tests, and exactly the type of discussion I was hoping to generate. I think it needs to be documented so that our process is as open and understandable as possible, even when we're using the emergency process. > > ARIN performing allocations according to community-developed policy is > the > status quo. As CEO, I know would recommend to the Board for the > adoption > of emergency policy under circumstances where the existing policy could > no > longer be followed (e.g. in response to unforeseen legal developments, > or > due to an action at IETF/IANA/ICANN which prevented ARIN following our > policies). [WES] Ok, this is also a helpful framework with which to evaluate emergencies. So the main thing that is open to interpretation is if you view IANA exhaustion as an "action ... which prevented ARIN from following our policies." In my view, it's not, because we have seen this coming for quite some time. We may not have known the exact date, but it was still close enough that a lot of the flurry of recent policies could have been written and adopted in enough time to manage a change in policy prior to runout. The fact that runout exists does not, in and of itself, create an emergency situation. It may be that the only way to trigger/justify emergency policies based on runout is to actually let it happen and *then* realize that there are some unintended side-effects that we need to correct ASAP. > That doesn't mean that there aren't other circumstances which > might also warrant emergency policy, only that it's extremely difficult > to establish the criteria in advance. The ARIN Board has not discussed > specific criteria by which it would judge emergency policy, so I cannot > not provide any additional guidance, but I hope my particular examples > prove helpful. [WES] Agreed, and your examples are helpful. I wasn't trying to say that there should be one rigid set of guidelines for which no exceptions can be made. However, I disagree with the idea that you can't establish at least some of the criteria in advance. We as a community and ARIN as an organization have a much more defensible position against second-guessing and other miscellaneous cries of "foul!" regarding our handling of IPv4 resource allocation/runout if we're a bit clearer on the framework for evaluating policy changes that don't follow the standard PDP. There are some things that will fall into the "know it when you see it" category, but we also know enough about the way the world works here to have some predefined criteria. I would still strongly recommend the AC and board having this discussion amongst themselves and the community prior to taking any emergency action on any of the policies currently on the table. Thanks Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6793 bytes Desc: not available URL: From farmer at umn.edu Mon Dec 6 13:23:48 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 06 Dec 2010 12:23:48 -0600 Subject: [arin-ppml] Emergency PDP process In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E03ABED@PLSWM12A.ad.sprint.com> References: <4CF71C22.3000404@umn.edu> <54E900DC635DAB4DB7A6D799B3C4CD8E039B61@PLSWM12A.ad.sprint.com> <6C0566ED-4C37-414C-ABD4-E74BB6006F34@corp.arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E03ABED@PLSWM12A.ad.sprint.com> Message-ID: <4CFD2A34.9000907@umn.edu> On 12/6/10 11:35 CST, George, Wes E [NTK] wrote: ... > I would still strongly recommend the AC and board having this discussion > amongst themselves and the community prior to taking any emergency action on > any of the policies currently on the table. I'm confident that the AC and the Board will discuss these issues. However, do you have any suggestions for the "and the community" part above. Did you intend something more than PPML for this? Something more than PPML would be really nice, but I'm not sure what it can or should be. If anyone has good ideas regarding this I would love to here them. -- =============================================== 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 Wesley.E.George at sprint.com Mon Dec 6 14:22:28 2010 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Mon, 6 Dec 2010 19:22:28 +0000 Subject: [arin-ppml] Emergency PDP process In-Reply-To: <4CFD2A34.9000907@umn.edu> References: <4CF71C22.3000404@umn.edu> <54E900DC635DAB4DB7A6D799B3C4CD8E039B61@PLSWM12A.ad.sprint.com> <6C0566ED-4C37-414C-ABD4-E74BB6006F34@corp.arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E03ABED@PLSWM12A.ad.sprint.com> <4CFD2A34.9000907@umn.edu> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E03ADAB@PLSWM12A.ad.sprint.com> > -----Original Message----- > From: David Farmer [mailto:farmer at umn.edu] > Sent: Monday, December 06, 2010 1:24 PM > To: George, Wes E [NTK] > Cc: John Curran; arin-ppml at arin.net List > Subject: Re: [arin-ppml] Emergency PDP process > However, do you have any suggestions for the "and the community" part > above. Did you intend something more than PPML for this? Something > more than PPML would be really nice, but I'm not sure what it can or > should be. If anyone has good ideas regarding this I would love to > here > them. [WES] Short term, I think that other than involving the PDP committee as much as possible, PPML is the right place for this discussion to happen. Given that several proposals are being considered for emergency action, I think that this is as good as we're going to get in terms of evaluating them as potential emergency action before the next meeting. I do expect that this will eventually morph into a recommended change to the PDP to be discussed at the next meeting, but the urgency is to get something out as soon as possible both to generate discussion and gauge consensus. My hope was that this thread would lead to additional folks providing issues to consider, potential tests, etc in order to give the AC and board ideas, and then once they have had a chance to discuss, they come back to PPML with some results that can be further refined and discussed. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6793 bytes Desc: not available URL: From scottleibrand at gmail.com Mon Dec 6 19:35:30 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 6 Dec 2010 16:35:30 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? Message-ID: We've gotten some good feedback from a few folks on this in the "122 + 123 process" thread, so I wanted to summarize where we're at and see if anyone else has any more feedback to the AC in preparation for next week's AC call. On that call we'll likely discuss whether to put this proposal on the AC's docket, if so whether to also designate it as a draft policy for adoption discussion, and most likely also whether to recommend that the Board invoke the Emergency PDP on this issue. Do you feel that Proposal 123 meets an emergency need, and that the Emergency PDP should be activated? A few comments we've received so far are: "122 and 123 should be adopted as draft policies and put through the normal process, at least until the last /8 is actually allocated." ... "When the last minute arrives, I would favor 122 and 123 as emergency policies." (Bill Herrin) "we ought to:" ... "establish via emergency procedures a separate /16 (I would fully support a /10) for CI as described in Proposal 123" because "b) the sizes of these two pools are small enough in the grand scheme of things that it is better to be safe than sorry. c) having two pools rather than one will prevent a run-out of all remaining addresses for just one of the two purposes, something that might occur if there was just one pool", and "we need some space for CI in situations where even our best planning didn't anticipate a certain need." (Frank Bulk) "Emergency? No. That is not to claim that there cannot possibly be some future action or event that could cause an emergency, just that I do not see one now." (Gary Buhrmaster) Additional feedback would be much appreciated. Thanks, Scott On Tue, Nov 23, 2010 at 7:01 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 123: Reserved Pool for Critical Infrastructure > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 23 Nov 2010 > > Proposal type: Modify > > Policy term: 36 Months following implementation > > Policy statement: > > Upon receipt of the last /8 that the IANA will allocate to ARIN per the > Global Policy for the Allocation of the Remaining IPv4 Address Space, > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure. If at the end of the policy term > there is unused address space remaining in this pool, ARIN staff is > authorized to utilize this space in a manner consistent with community > expectations. > > Rationale: > > Section 4.10 of the NRPM is insufficient with respect to insuring the > continued operation of critical infrastructure. This proposal, if > adopted, will protect those resources with a reasonable amount of > reserved v4 address space and prevent an overrun of CI needs by NRPM > Section 4.10 or any successor. The intent is to separate CI needs and > make a distinct pool available to insure the continuity of CI > allocations per NRPM Section 4.4 for at least 36 months. > > This proposal should be considered an emergency proposal. IANA > exhaustion is likely to occur prior to the next ARIN meeting. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From frnkblk at iname.com Mon Dec 6 23:45:18 2010 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 6 Dec 2010 22:45:18 -0600 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: Message-ID: Typically we work to avoid emergencies, yet some are suggesting that we wait till the date has arrived then start the emergency process. Let's plan the best we can now, before IANA hands out the last 5 /8's. Let's look like we're cognizant of the impending address outage and making reasonable plans to set aside space for transition (Proposal 122) and the future unknown (Proposal 123). Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Monday, December 06, 2010 6:36 PM To: ARIN-PPML List Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? We've gotten some good feedback from a few folks on this in the "122 + 123 process" thread, so I wanted to summarize where we're at and see if anyone else has any more feedback to the AC in preparation for next week's AC call. On that call we'll likely discuss whether to put this proposal on the AC's docket, if so whether to also designate it as a draft policy for adoption discussion, and most likely also whether to recommend that the Board invoke the Emergency PDP on this issue. Do you feel that Proposal 123 meets an emergency need, and that the Emergency PDP should be activated? A few comments we've received so far are: "122 and 123 should be adopted as draft policies and put through the normal process, at least until the last /8 is actually allocated." ... "When the last minute arrives, I would favor 122 and 123 as emergency policies." (Bill Herrin) "we ought to:" ... "establish via emergency procedures a separate /16 (I would fully support a /10) for CI as described in Proposal 123" because "b) the sizes of these two pools are small enough in the grand scheme of things that it is better to be safe than sorry. c) having two pools rather than one will prevent a run-out of all remaining addresses for just one of the two purposes, something that might occur if there was just one pool", and "we need some space for CI in situations where even our best planning didn't anticipate a certain need." (Frank Bulk) "Emergency? No. That is not to claim that there cannot possibly be some future action or event that could cause an emergency, just that I do not see one now." (Gary Buhrmaster) Additional feedback would be much appreciated. Thanks, Scott On Tue, Nov 23, 2010 at 7:01 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 123: Reserved Pool for Critical Infrastructure > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 23 Nov 2010 > > Proposal type: Modify > > Policy term: 36 Months following implementation > > Policy statement: > > Upon receipt of the last /8 that the IANA will allocate to ARIN per the > Global Policy for the Allocation of the Remaining IPv4 Address Space, > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure. If at the end of the policy term > there is unused address space remaining in this pool, ARIN staff is > authorized to utilize this space in a manner consistent with community > expectations. > > Rationale: > > Section 4.10 of the NRPM is insufficient with respect to insuring the > continued operation of critical infrastructure. This proposal, if > adopted, will protect those resources with a reasonable amount of > reserved v4 address space and prevent an overrun of CI needs by NRPM > Section 4.10 or any successor. The intent is to separate CI needs and > make a distinct pool available to insure the continuity of CI > allocations per NRPM Section 4.4 for at least 36 months. > > This proposal should be considered an emergency proposal. IANA > exhaustion is likely to occur prior to the next ARIN meeting. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ 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 BillD at cait.wustl.edu Tue Dec 7 00:16:12 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 6 Dec 2010 23:16:12 -0600 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? References: Message-ID: There are over 1000 /24 sized, non-aggregateable blocks in the ARIN free pool and only a few hundreds of CI assignments in the past since policy inception. Does this mean that there exists sufficient resources to continue to handle CI interests for the near future? Could that space or part of it be reserved for that use? Does it even need to be? bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Scott Leibrand Sent: Mon 12/6/2010 6:35 PM To: ARIN-PPML List Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? We've gotten some good feedback from a few folks on this in the "122 + 123 process" thread, so I wanted to summarize where we're at and see if anyone else has any more feedback to the AC in preparation for next week's AC call. On that call we'll likely discuss whether to put this proposal on the AC's docket, if so whether to also designate it as a draft policy for adoption discussion, and most likely also whether to recommend that the Board invoke the Emergency PDP on this issue. Do you feel that Proposal 123 meets an emergency need, and that the Emergency PDP should be activated? A few comments we've received so far are: "122 and 123 should be adopted as draft policies and put through the normal process, at least until the last /8 is actually allocated." ... "When the last minute arrives, I would favor 122 and 123 as emergency policies." (Bill Herrin) "we ought to:" ... "establish via emergency procedures a separate /16 (I would fully support a /10) for CI as described in Proposal 123" because "b) the sizes of these two pools are small enough in the grand scheme of things that it is better to be safe than sorry. c) having two pools rather than one will prevent a run-out of all remaining addresses for just one of the two purposes, something that might occur if there was just one pool", and "we need some space for CI in situations where even our best planning didn't anticipate a certain need." (Frank Bulk) "Emergency? No. That is not to claim that there cannot possibly be some future action or event that could cause an emergency, just that I do not see one now." (Gary Buhrmaster) Additional feedback would be much appreciated. Thanks, Scott On Tue, Nov 23, 2010 at 7:01 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 123: Reserved Pool for Critical Infrastructure > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 23 Nov 2010 > > Proposal type: Modify > > Policy term: 36 Months following implementation > > Policy statement: > > Upon receipt of the last /8 that the IANA will allocate to ARIN per the > Global Policy for the Allocation of the Remaining IPv4 Address Space, > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure. If at the end of the policy term > there is unused address space remaining in this pool, ARIN staff is > authorized to utilize this space in a manner consistent with community > expectations. > > Rationale: > > Section 4.10 of the NRPM is insufficient with respect to insuring the > continued operation of critical infrastructure. This proposal, if > adopted, will protect those resources with a reasonable amount of > reserved v4 address space and prevent an overrun of CI needs by NRPM > Section 4.10 or any successor. The intent is to separate CI needs and > make a distinct pool available to insure the continuity of CI > allocations per NRPM Section 4.4 for at least 36 months. > > This proposal should be considered an emergency proposal. IANA > exhaustion is likely to occur prior to the next ARIN meeting. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ 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 scottleibrand at gmail.com Tue Dec 7 00:30:52 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 6 Dec 2010 21:30:52 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: Message-ID: As written this policy would require ARIN to "place an equivalent of a /16 of IPv4 address space in a reserve" for this purpose. They could reserve a number of small blocks, perhaps to match the historical size distribution of CI space. Or they could even just put a rule into their allocation scripts that says "stop when you get to a /16 worth of space left", and let the CI space be whatever's left over at that point. -Scott On Mon, Dec 6, 2010 at 9:16 PM, Bill Darte wrote: > There are over 1000 /24 sized, non-aggregateable blocks in the ARIN free > pool and only a few hundreds of CI assignments in the past since policy > inception. Does this mean that there exists sufficient resources to continue > to handle CI interests for the near future? > Could that space or part of it be reserved for that use?? Does it even need > to be? > > bd > > > -----Original Message----- > From: arin-ppml-bounces at arin.net on behalf of Scott Leibrand > Sent: Mon 12/6/2010 6:35 PM > To: ARIN-PPML List > Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: > Reserved Pool for Critical Infrastructure? > > We've gotten some good feedback from a few folks on this in the "122 + > 123 process" thread, so I wanted to summarize where we're at and see > if anyone else has any more feedback to the AC in preparation for next > week's AC call.? On that call we'll likely discuss whether to put this > proposal on the AC's docket, if so whether to also designate it as a > draft policy for adoption discussion, and most likely also whether to > recommend that the Board invoke the Emergency PDP on this issue. > > Do you feel that Proposal 123 meets an emergency need, and that the > Emergency PDP should be activated? > > A few comments we've received so far are: > > "122 and 123 should be adopted as draft policies and put through the > normal process, at least until > the last /8 is actually allocated." ... "When the last minute arrives, > I would favor 122 and 123 as emergency policies." (Bill Herrin) > > "we ought to:" ... "establish via emergency procedures a separate /16 > (I would fully support > a /10) for CI as described in Proposal 123" because "b) the sizes of > these two pools are small enough in the grand scheme of things that it > is better to be safe than sorry. c) having two pools rather than one > will prevent a run-out of all remaining addresses for just one of the > two purposes, something that might occur if there was just one pool", > and "we need some space for CI > in situations where even our best planning didn't anticipate a certain > need."? (Frank Bulk) > > "Emergency?? No.? That is not to claim that there cannot possibly be > some future action or event that could cause an emergency, just that I > do not see one now." (Gary Buhrmaster) > > Additional feedback would be much appreciated. > > Thanks, > Scott > > On Tue, Nov 23, 2010 at 7:01 AM, ARIN wrote: >> The proposal originator submitted revised text. >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal 123: Reserved Pool for Critical Infrastructure >> >> Proposal Originator: Martin Hannigan >> >> Proposal Version: 3.0 >> >> Date: 23 Nov 2010 >> >> Proposal type: Modify >> >> Policy term: 36 Months following implementation >> >> Policy statement: >> >> Upon receipt of the last /8 that the IANA will allocate to ARIN per the >> Global Policy for the Allocation of the Remaining IPv4 Address Space, >> ARIN will place an equivalent of a /16 of IPv4 address space in a >> reserve for Critical Infrastructure. If at the end of the policy term >> there is unused address space remaining in this pool, ARIN staff is >> authorized to utilize this space in a manner consistent with community >> expectations. >> >> Rationale: >> >> Section 4.10 of the NRPM is insufficient with respect to insuring the >> continued operation of critical infrastructure. This proposal, if >> adopted, will protect those resources with a reasonable amount of >> reserved v4 address space and prevent an overrun of CI needs by NRPM >> Section 4.10 or any successor. The intent is to separate CI needs and >> make a distinct pool available to insure the continuity of CI >> allocations per NRPM Section 4.4 for at least 36 months. >> >> This proposal should be considered an emergency proposal. IANA >> exhaustion is likely to occur prior to the next ARIN meeting. >> >> Timetable for implementation: Immediate >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > 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 Tue Dec 7 01:18:51 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 7 Dec 2010 00:18:51 -0600 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: Message-ID: On Mon, Dec 6, 2010 at 10:45 PM, Frank Bulk wrote: > Let's plan the best we can now, before IANA hands out the last 5 /8's. > Let's look like we're cognizant of the impending address outage and making > reasonable plans to set aside space for transition (Proposal 122) and the > future unknown (Proposal 123). It seems a perfectly benign use case for an Emergency PDP, if the sole effect is to reserve a final single /16. Providing there aren't other policy changes, allocation is effected only if the anticipated emergency actually arises. I agree plan now... with the date of the next public policy meeting in April; it appears clear that the final /8 will most likely have been allocated to ARIN by then. The "last minute" as it were is not the 4 months from now, that would be required to bring the item to the public meeting under the normal PDP. It is also possible, that applications for IP addresses will force that /8 to be drawn down under current policy, before any action is possible under the normal PDP. Use of emergency PDP would seem to be called for, if the /16 reservation is needed to ensure that all space is not allocated, so that there is no space to allocate from to address any critical infrastructure needs. If we think the final /8 will be used up before the next policy meeting, and we are wrong, if the final /8 has not even been allocated by that time, or the final /8 has more than a /16 left, when the policy would be reconsidered at the public policy meeting and possibly annulled, then the emergency PDP had no "effect", since the final /16 to be reserved had not been requested to be allocated. It would only have an "effect" if we were right, and a final /16 needed to be stopped from being allocated. > Frank -- -JH From marty at akamai.com Tue Dec 7 08:55:02 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 7 Dec 2010 08:55:02 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: Message-ID: On 12/7/10 12:16 AM, "Bill Darte" wrote: > There are over 1000 /24 sized, non-aggregateable blocks in the ARIN free pool > and only a few hundreds of CI assignments in the past since policy inception. > Does this mean that there exists sufficient resources to continue to handle CI > interests for the near future? > Could that space or part of it be reserved for that use? Does it even need to > be? > > bd I think that one of the main points of 123 is that a guarantee is better than a guess. Best, -M< From bicknell at ufp.org Tue Dec 7 09:10:49 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 7 Dec 2010 06:10:49 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: Message-ID: <20101207141049.GA95209@ussenterprise.ufp.org> I am not a big fan of using the "emergency" provisions of the PDP. I found the Board's action to use the emergency PDP back in March of 2009 inappropriate, and complained at the time. I believe that in general, extraordinary efforts should be made to use the normal PDP process before going to the emergency PDP. Emergency really should mean there are absolutely no other viable options left. That said, 122 and 123 might pass the bar. We have a triggered event, handling out the last 5 /8's, which is now out of ARIN's hands. That's not a theoretical might happen, it's a will happen. While we can't predict the date with 100% accuracy, we can bound it pretty tightly. There seems to be strong consensus that it will be triggered before the next meeting (April 10-13), and even stronger that it would be triggered before the normal policy process could happen (requiring at least one AC and Board meeting post the April meeting). In short, if the AC concludes 122 or 123 has strong community support I believe that necessitates the use of the emergency PDP in order to get them done before external events make them impossible. I do believe the AC should do exactly the sort of thing that is going on here, and make it quite clear the Emergency PDP may be used in this case, request comments, and respond to feedback. When using the Emergency PDP we should stay as close as possible to "normal" process, the fact that we have to use it doesn't mean we throw everything out. -- 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 Wesley.E.George at sprint.com Tue Dec 7 09:30:38 2010 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 7 Dec 2010 14:30:38 +0000 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E03BA55@PLSWM12A.ad.sprint.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Hannigan, Martin > Sent: Tuesday, December 07, 2010 8:55 AM > Subject: Re: [arin-ppml] Is Emergency action warranted for Policy > Proposal 123: Reserved Pool for Critical Infrastructure? > > On 12/7/10 12:16 AM, "Bill Darte" wrote: > > > There are over 1000 /24 sized, non-aggregateable blocks in the ARIN > free pool > > and only a few hundreds of CI assignments in the past since policy > inception. > > > I think that one of the main points of 123 is that a guarantee is > better > than a guess. > > -M< I'm in support of policy 123 in general. I'm not completely in support of using emergency action to implement it because I'm not convinced that it's an emergency, and I think it's important to have a clearer idea of what actually does constitute an emergency before "breaking the glass" as I have said in another thread. Yes, with minimum allocation size at /24, we now have a use for these little pieces as standard allocations, but I'm skeptical that this becomes such a problem in the next 4 months as to not put it in front of the community in the standard way. Even if it is done as an emergency, this needs full community discussion on-list, and you're not going to get a representative sample response on-list ~2 weeks before Christmas, therefore the timing of the official Emergency PDP comment period will be important. If you look at the responders in the threads on this proposal (and 122) the amount of folks who aren't either affiliated with ARIN, the AC (incoming or outgoing), and/or an author is a handful at best. My hunch is that you'll suddenly get a lot of interest in ARIN policy soon after the first of the year, however. ;-) Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6793 bytes Desc: not available URL: From gbonser at seven.com Tue Dec 7 11:46:02 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 7 Dec 2010 08:46:02 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E03BA55@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E03BA55@PLSWM12A.ad.sprint.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CD92@RWC-EX1.corp.seven.com> > My hunch is that you'll suddenly get a lot of > interest in ARIN policy soon after the first of the year, however. > ;-) > > Wes George Yup. As soon as "Company with lots of full time lawyers on staff" tries to get an allocation and can't, it is going to be hell. People don't understand the notion these days that "the cupboard is bare". We need these, lets move forward with them. George From farmer at umn.edu Tue Dec 7 12:21:40 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 07 Dec 2010 11:21:40 -0600 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <4CF7ED4B.6080105@arin.net> References: <4CF7ED4B.6080105@arin.net> Message-ID: <4CFE6D24.3090601@umn.edu> On 12/2/10 13:02 CST, ARIN wrote: ... > Policy Proposal 124: Clarification of Section 4.2.4.4 > > Proposal Originator: Martin Hannigan and Chris Grundemann > > Proposal Version: 1.0 > > Date: 2 December 2010 > > Proposal type: Modify, complete replacement of 4.2.4.4 > > Policy term: Permanent > > Policy statement: > > 4.2.4.4. Subscriber Members After One Year > > After an organization has been a subscriber member of ARIN for one year, > that organization may choose to request up to a 12 month supply of IP > addresses. > > On the date that ARIN receives its last /8 as a result of the IANA > executing section 10.4.2.2 of the NRPM and in accordance with the Global > Policy for the Allocation of the Remaining IPv4 Address Space, the > length of supply that any organization may request from ARIN from that > moment forward will be reduced to three months. Any pending request > submitted prior to that moment will continue to be eligible for a twelve > month supply of addresses as long as need is established within thirty > days of that moment. > > Rationale: > > ARIN's pending operational practice is that if an organization has a > request in the ARIN hostmaster queue for IPv4 resources when the IANA > declares the exhaustion phase (10.4.2.2), their request will be > automatically truncated from a twelve month supply to a three month > supply since policy in effect at the time of exhaustion will apply. 8.3 > and 4.2.4.4 are currently "in effect". > > Example: If an entity is asking for 4 x /24 for a 12 month period and > IANA exhaustion occurs, a requester will receive, if justified, 1 x /24. > If an entity is asking for 120 x /24 at the time that exhaustion occurs, > they would only receive 30 x /24 if justified. If ARIN determines that > this same entity would only qualify for 90 of the 120 x /24 requested, > then that entity would only receive 22 x /24. > > ARIN has the equivalent of almost a /8 in at least one reserve, has > recently received 2 /8's, received ~391 x /16's as a result of the > distribution of "various registries" from the IANA and is guaranteed to > receive at least one additional /8 (aggregate of about 92 million > individual IPv4 addresses) as a result of the execution of 10.4.2.2 by > the IANA. Considering the size of the supply, it would seem prudent to > provide for all members needs in a fair and consistent manner as long as > possible in order to support the continued orderly transition of the > Internet to IPv6. > > The ARIN AC should review and determine what action if any should be > taken at their next available opportunity, or sooner if they deem > warranted. Was the the third paragraph of the current policy intentionally remove? That paragraph was intended to allow transfers via section 8.3 to continue to receive a 12 month supply and not restricted to 3 month like allocations from the ARIN pool. I believe it is important to retain this. Since I did not see this change explicitly addressed in the Rationale, I'll assume that it was not intentional. If that is incorrect, would you please explain why you think it is a good idea to restrict these transfers to a 3 month supply, and that should be more prominent in the rationale. Also, I don't believe this policy effects the minimum allocation size, so I think there are issues with the first example you provide in the rational. I'm not exactly sure how it would be applied for your examples, but the minimum allocation size is /20 (16 X /24) and therefore you would get a /20 as a minimum allocation, or possibly a /22 for multihomed allocations. I went back and reviewed the record for 2009-8 which is the Draft Policy that put the current language in place. I don't see where anyone brought up the issue of how those currently in queue at the time of triggering event should be handled. I will note that the original Draft Policy had this ratcheting down over time, while fundamentally the same issue existed, the multiple steps down would have lessened the impact of this issue. So, thank you for bringing up this issue, while it was never directly discussed, I don't think it was ever anyone's intent to impact those in queue, only new requests. Given that there was never any direction to the contrary in the Rationale or the Policy itself, I believe staff's plan for implementing seems consistent with the way other policies are implemented. However, I wonder if this could be accomplished without actually changing the policy and simply by have the AC request the implementation of 2009-8 be accomplished by applying the triggered change in policy only to new requests when the triggering event occurs. I don't think this is inconsistent with the policy as currently written. This is an implementation detail, an important one I'll grant you, but I'm not sure it needs to be escalated to the policy itself. Furthermore, if such a suggestion would have been Included in the Rational of the original 2009-8 I believe Staff would have implemented the policy as desired. So I guess I have a question for John Curran; Would it be in order and sufficient for the AC to recommend to the Board that policy 2009-8 now section 4.2.4.4 of the NRPM have the triggering clause be implemented for new requests that are received after the triggering event, and that requests received before the trigger be grandfathered? If that is possible, then we wouldn't need new policy and wouldn't need to implement the emergency PDP in this case. It would simply require timely action, within the normal scope of activity, by the AC, the Board, and Staff, which I think is still possible at this point. I'm not opposed to this policy, but I don't believe it is necessary to change the policy in order to achieve the desired result, assuming the only desired result is to grandfather those in queue with the 12 month supply. Do others on PPML support this interpretation of section 4.2.4.4? Is this a reasonable course of action? Thanks. -- =============================================== 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 jcurran at arin.net Tue Dec 7 12:24:45 2010 From: jcurran at arin.net (John Curran) Date: Tue, 7 Dec 2010 17:24:45 +0000 Subject: [arin-ppml] Regarding interesting times ahead... In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14CD92@RWC-EX1.corp.seven.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E03BA55@PLSWM12A.ad.sprint.com> <5A6D953473350C4B9995546AFE9939EE0B14CD92@RWC-EX1.corp.seven.com> Message-ID: On Dec 7, 2010, at 11:46 AM, George Bonser wrote: > Yup. As soon as "Company with lots of full time lawyers on staff" tries > to get an allocation and can't, it is going to be hell. Indeed, it's going to be quite an interesting time. I believe it will be important for us to be clear that not all hope is lost, i.e. under current resource policy firms will still be able to qualify for up to 3 months of space and then can either wait to see if such returned space comes available to them via the waiting list, or they can find someone who has space that could be potentially freed up & work with them to receive a specified transfer (of up to 12 months space per documented need) under NRPM 8.3. This may not satisfy a lot of companies, but is slightly more palatable than having no chance at all of obtaining address space. Whatever policy we end up with post-depletion, I do expect that we'll be explaining those options to many, many organizations in the near future and I'm hopeful that the participants of this mailing list will become advocates getting the full message disseminated throughout the region. That may not keep all the lawyers at bay, but it certainly will help... /John John Curran President and CEO ARIN From marty at akamai.com Tue Dec 7 12:51:59 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 7 Dec 2010 12:51:59 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <4CFE6D24.3090601@umn.edu> Message-ID: On 12/7/10 12:21 PM, "David Farmer" wrote: > On 12/2/10 13:02 CST, ARIN wrote: > ... >> >> The ARIN AC should review and determine what action if any should be >> taken at their next available opportunity, or sooner if they deem >> warranted. > > Was the the third paragraph of the current policy intentionally remove? > That paragraph was intended to allow transfers via section 8.3 to > continue to receive a 12 month supply and not restricted to 3 month like > allocations from the ARIN pool. I believe it is important to retain this. The proposal itself as published by ARIN said: Proposal type: Modify, complete replacement of 4.2.4.4 [ clip ] > I'm not opposed to this policy, but I don't believe it is necessary to > change the policy in order to achieve the desired result, assuming the > only desired result is to grandfather those in queue with the 12 month > supply. Do others on PPML support this interpretation of section > 4.2.4.4? Is this a reasonable course of action? > Best, -M< From marty at akamai.com Tue Dec 7 12:54:26 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 7 Dec 2010 12:54:26 -0500 Subject: [arin-ppml] Policy Proposal 121: Sensible IPv6 Allocation for ISPs - revised In-Reply-To: <4CF7BFF3.2030106@arin.net> Message-ID: Not in favor.... Best, -M< On 12/2/10 10:49 AM, "ARIN" wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 121: Sensible IPv6 Allocation for ISPs > > Proposal Version: .9 > > Date: 2 December 2010 > > Policy statement: > >> Amend section 2 as follows: >> >> Delete section 2.9 (Obsolete) >> Replace section 2.10 with the following: >> 2.10 The term End Site shall mean a single structure or service delivery >> address, or, in the case of a multi-tenant structure, a single tenant >> within said structure (a single customer location). >> Add the following: >> 2.12 The term serving site shall mean a location where an ISP terminates >> or aggregates customer connections, including, but, not limited to >> Points of Presence (POPs), Datacenters, Central or Local switching >> office or regional or local combinations thereof. >> 2.13 The term provider assignment unit shall mean the prefix of the >> smallest block a given ISP assigns to end sites (recommended /48). >> 2.14 The term utilized shall have the following definitions: >> (i) A provider assignment unit shall be considered fully utilized when >> it is assigned to an end-site. >> (ii) Larger blocks shall have their utilization defined by dividing the >> number of provider assignment units assigned from the >> containing block by the total number of provider assignment >> units. This ratio will often be expressed as a percentage >> (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) >> >> Replace sections 6.5.1 through 6.5.3 with the following: >> 6.5.1 Terminology >> (a) The terms ISP and LIR are used interchangeably in this document and >> any use of either term shall be construed to include both meanings. >> (b) The term nibble boundary shall mean a network mask which aligns >> on a 4-bit boundary (in slash notation, /n, where n is evenly divisible >> by 4, allowing unit quantities of X such that 2^n=X where n is >> evenly divisible by 4, such as 16, 256, 4096, etc.) >> >> 6.5.2 Initial Allocations to LIRs >> 6.5.2.1 Size >> (a) All allocations shall be made on nibble boundaries. >> (b) In no case shall an LIR receive smaller than a /32 >> unless they specifically request a /36. >> (c) The maximum allowable allocation shall be the smallest >> nibble-boundary aligned block that can provide an equally >> sized nibble-boundary aligned block to each of the >> requesters serving sites large enough to satisfy the needs >> of the requesters largest single serving site using no more >> than 75% of the available addresses. >> >> This calculation can be summarized as /N where >> N = 48-(X+Y) and X is a multiple of 4 greater >> than 4/3*serving sites and Y is a multiple of 4 >> greater than 4/3*end sites served by largest serving site. >> >> (d) For purposes of the calculation in (c), an end site which >> can justify more than a /48 under the end-user assignment >> criteria in 6.5.8 shall count as the appropriate number of /48s >> that would be assigned under that policy. >> (e) For purposes of the calculation in (c), an LIR which has >> subordinate LIRs shall make such allocations according >> to the same policies and criteria as ARIN. In such a case, >> the prefixes necessary for such an allocation should be treated >> as fully utilized in determining the block sizing for the parent LIR. >> (f) An LIR is not required to design or deploy their network >> according to this structure. It is strictly a mechanism to >> determine the largest IP address block to which the LIR >> is entitled. >> 6.5.2.2 Qualifications >> An organization qualifies for an allocation under this policy if >> they meet any of the following criteria: >> (a) Have a previously justified IPv4 ISP allocation from ARIN >> or one of its predecessor registries or can qualify for >> an IPv4 ISP allocation under current criteria. >> (b) Are currently multihomed for IPv6 or will immediately >> become multihomed for IPv6 using a valid assigned >> global AS number and will be making reassignments >> to other organizations. >> (c) Provide ARIN a reasonable technical justification, >> indicating why an allocation is necessary, including >> the intended purposes for the allocation, and describing >> the network infrastructure the allocation will be used to >> support. Justification must include a plan detailing assignments >> to other organizations or customers for one, two and five year >> periods, with a minimum of 50 assignments within 5 years. >> 6.5.3 Subsequent Allocations to LIRs >> (a) Where possible ARIN will make subsequent allocations by >> expanding the existing allocation. >> (b) An LIR which can show utilization of 75% or more of their >> total address space, or more than 90% of any serving site >> shall be entitled to a subsequent allocation. >> (c) If ARIN can not expand one or more existing allocations, >> ARIN shall make a new allocation based on the initial >> allocation criteria above. The LIR is encouraged, but not >> required to renumber into the new allocation over time >> and return any allocations no longer in use. >> Replace section 6.5.4 with the following >> 6.5.4 Assignments to end users shall be governed by the same >> practices adopted by the community in section 6.5.8 except >> that the requirements in 6.5.8.1 do not apply. >> >> Add the following to 6.5.7 >> LIRs which received an allocation under previous policies which is >> smaller than what they are entitled to under this policy may receive >> a new initial allocation under this policy provided that they agree to >> renumber into that new allocation and return their prior allocation(s) >> within 5 years. If possible, ARIN will simply expand their existing >> allocation rather than requiring renumber and return. > > > > _______________________________________________ > 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 Tue Dec 7 13:03:13 2010 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 7 Dec 2010 18:03:13 +0000 Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4CF90C92.8070109@arin.net> References: <4CF90C92.8070109@arin.net> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E03CD9D@PLSWM12A.ad.sprint.com> I like the idea, but I'm not in support of this policy as written, because I don't agree with the execution. Specifically, I think that enforcement/implementation is going to be a major problem due to the potential for abuse, justifiable loopholes, and the timeline to reach consensus and implement something that is both complex and polarizing. By the time this works its way through the process, we're going to be past IANA exhaust and likely well on our way to ARIN exhaust, so the challenge is to make this palatable before it's too late for it to be helpful. I don't want us to implement something that it has no teeth, but I also don't want us to make it impossible for businesses to execute on existing plans because they didn't do it fast enough for our tastes. Exhaustion will be enough of a problem without us making it harder to make the transition by changing the rules at the last minute. I suggest two alternatives to outright denying new IPv4 allocations that would still accomplish what I think is the spirit of the policy (to apply the cluebrick that IPv6 is not optional and the status quo is not going to be acceptable). 1) Change in fee schedule - if you are a current ARIN resource holder and you request new IPv4 space without an IPv6 allocation and a deployment plan, you will pay an additional fee until you show that you have deployed IPv6. Either it can be a non-trivially increased flat rate (say, 3x existing fees), or it can be tied to the amount of address space that ARIN has remaining, indexed monthly. I realize that the second option would create significant variability in the fees that would be hard to plan for, so we'd probably need a published maximum fee. Either way, I would recommend that it be tied to the current fees the requestor is paying, so that it's not regressive - that is, if you're a size Small, you pay less than an X-large. Then, as soon as you get IPv6 deployed, you go back to the normal fee schedule. That would create an incentive to rapidly deploy IPv6, and would complement the existing waiver of IPv6 fees nicely - perhaps even allowing us to extend it! n.b. I originally suggested this here: http://lists.arin.net/pipermail/arin-ppml/2010-October/018385.html if you want to read for details. I don't know why it requires so much side scrolling, sorry about that. 2) Similar to the executive certification that the records are accurate which is required when you request new space, ARIN could require executive certification that the company is in the process of deploying IPv6, with some specific data to justify this, timelines, address plan, an allocation, etc. Some specific comments on the text: The policy authors need to revise this to clarify if they want this to apply to just new allocations or just transfers, or both. It has limited teeth if it's just for new allocations, but that can't be left open for interpretation. Regarding validation: As others have said, not everyone does DNS for their deployments, which removes that as a definitive validation point. An alternative method of validation might be to verify that IPv6 is being routed and that at least some of the addresses are reachable. However, this creates a problem for networks that have no intention of making their IPv6 hosts publicly reachable, and it can also be pretty toothless - I can add one line of config to make my V6 block visible in the table even if I'm not actually using it for much yet. I like the idea of documentation better, but it also only works in certain cases, and the language regarding justification is pretty unclear. Most average ISPs have little or no control over the take rate for IPv6 for their customers - even less if the customer owns the CPE. So how would they justify new IPv4 space? Is it ok if they simply allocate an address knowing that it's not getting used by the end customer? Sounds good, but how do you verify that the requestor has actually done that, not just on paper? If it's just about documentation, wouldn't simply showing an IPv6 addressing plan be enough? If so, why not just require that they *get* an IPv6 allocation? As has been said before when we talked about pre-emptive allocations, not all of the ASNs in the table even have an IPv6 allocation yet... If you're going to require a hard and fast percentage of the network to be dual-stacked, it's not realistic to request that it be 1:1 to the amount of IPv4 addresses being requested up to 80% of hosts. IP requests are based on projection of use over a year's time period, and it may not be possible to meet that test depending on where you are in your IPv6 deployment. 50% is probably more realistic, but still a challenge in some cases. It's also not realistic to require 80% of current interfaces be dual-stacked. In many cases, there is a very serious installed-base problem that completely precludes dual-stacking existing stuff, and cap and grow is the only way to deploy IPv6. Additional public IPv4 addresses may be necessary even if the SP is deploying something like NAT444 in order to extend the density of their IPv4 usage. Thanks, Wes George > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Friday, December 03, 2010 10:28 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4 > Requires Dual-Stack > > > Policy Proposal 125: Efficient Utilization of IPv4 Requires Dual-Stack > > Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller > > Proposal Version: 1 > > Date: 3 December 2010 > > Proposal type: modify > > Policy term: permanent > > Policy Statement: > > * Add the following sections to section 4.1: > > 4.1.2. Efficient Utilization > > IPv4 addresses are a finite resource and as such are required to be > efficiently utilized by resource holders in order to maximize their > benefit to the community. > > 4.1.3. Dual-Stack > > Dual-stack refers to configuring both an IPv4 and an IPv6 address or > network together on the same network infrastructure. > > All new IPv4 addresses assigned, allocated or transfered to an > organization must be deployed on dual-stacked interfaces along with > IPv6 addresses. > > 4.1.4. IPv6 Deployment > > When addresses are used to provide an Internet facing service, the > service must be fully IPv6 accessible (if you deploy an A record, you > must also have a AAAA record, and both must answer). > > * Add the following sentance to the end of sections 4.2.1.6, > 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: > > In accordance with section 4.1.3 and 4.1.4, all new addresses must be > deployed on dual-stacked interfaces and all Internet facing services > provided by new addresses must be fully IPv6 accessible. > > * Re-write section 4.2.3.4.1. to: > > Reassignment information for prior allocations must show that each > customer meets the 80% utilization criteria, the dual-stack criteria > and must be available via SWIP / RWhois prior to your issuing them > additional space. > > * Add the following section to section 4.2.4: > > 4.2.4.5. IPv6 Deployment > > In order to receive additional space ISPs must provide detailed > documentation demonstrating that: > - for every IPv4 address requested, at least one pre-existing > interface is dual stacked, up to 80% of all interfaces and > - for every down stream customer site where the new addresses will be > deployed, at least one pre-existing down stream customer site is IPv6 > enabled, up to 80% of the total customer base. > > * Add the following to section 4.3.6: > > 4.3.6.3. IPv6 Deployment > > In order to receive additional space end-users must provide detailed > documentation demonstrating that at least 80% of their existing IPv4 > addresses are deployed on dual-stacked interfaces in accordance with > section 4.1.3. > > Rational: > > In this period of available IPv4 address scarcity and transition to > IPv6, IPv4 addresses that are not deployed along with IPv6 are simply > not being efficiently utilized. Although we have likely failed to > deploy dual-stack in a meaningful way in time to avoid transition > problems, we can still choose the correct path for future assignments, > allocations and transfers. > > This proposal has three objectives: > -1- Encourage IPv6 deployment prior to and post depletion > -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change > was to this line]# > -3- Improve the utilization of IP addresses > > It accomplishes these goals by enforcing three basic ideals: > -1- ARIN will only make allocations and assignments for networks that > have already deployed production IPv6 > -2- Any new IPv4 addresses received, must be deployed along side of > IPv6 (dual-stacked) > -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks > > The specific requirements to be enforced can be summed up in this way: > ~ New addresses must be deployed on dual-stacked interfaces plus one > additional pre-existing IPv4-only interface must be dual-stacked per > new address, up to 80% of all interfaces. > ~ For each down stream customer site where these addresses are > deployed, another pre-existing IPv4 only down stream site must also be > IPv6 enabled, up to 80% of the total customer base. > ~ All end-sites must dual-stack before getting new space. > ~ Internet facing services that new IPv4 addresses are used to provide > must be fully IPv6 accessible. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6793 bytes Desc: not available URL: From mueller at syr.edu Tue Dec 7 13:28:27 2010 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 7 Dec 2010 13:28:27 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: Message-ID: <75822E125BCB994F8446858C4B19F0D70AC125B42F@SUEX07-MBX-04.ad.syr.edu> Is the definition of "critical infrastructure" sufficiently clear such that it can be applied unambiguously? Only definition I can find is NPRM 6.10.1. Do we have a precise definition or understanding of what is a "public exchange point" and a "core DNS service provider"? In a world of 5,000 TLDs, do all g and cc TLDs have the same status? > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Monday, December 06, 2010 7:36 PM > To: ARIN-PPML List > Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: > Reserved Pool for Critical Infrastructure? > > We've gotten some good feedback from a few folks on this in the "122 + > 123 process" thread, so I wanted to summarize where we're at and see > if anyone else has any more feedback to the AC in preparation for next > week's AC call. On that call we'll likely discuss whether to put this > proposal on the AC's docket, if so whether to also designate it as a > draft policy for adoption discussion, and most likely also whether to > recommend that the Board invoke the Emergency PDP on this issue. > > Do you feel that Proposal 123 meets an emergency need, and that the > Emergency PDP should be activated? > > A few comments we've received so far are: > > "122 and 123 should be adopted as draft policies and put through the > normal process, at least until > the last /8 is actually allocated." ... "When the last minute arrives, > I would favor 122 and 123 as emergency policies." (Bill Herrin) > > "we ought to:" ... "establish via emergency procedures a separate /16 > (I would fully support > a /10) for CI as described in Proposal 123" because "b) the sizes of > these two pools are small enough in the grand scheme of things that it > is better to be safe than sorry. c) having two pools rather than one > will prevent a run-out of all remaining addresses for just one of the > two purposes, something that might occur if there was just one pool", > and "we need some space for CI > in situations where even our best planning didn't anticipate a certain > need." (Frank Bulk) > > "Emergency? No. That is not to claim that there cannot possibly be > some future action or event that could cause an emergency, just that I > do not see one now." (Gary Buhrmaster) > > Additional feedback would be much appreciated. > > Thanks, > Scott > > On Tue, Nov 23, 2010 at 7:01 AM, ARIN wrote: > > The proposal originator submitted revised text. > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Policy Proposal 123: Reserved Pool for Critical Infrastructure > > > > Proposal Originator: Martin Hannigan > > > > Proposal Version: 3.0 > > > > Date: 23 Nov 2010 > > > > Proposal type: Modify > > > > Policy term: 36 Months following implementation > > > > Policy statement: > > > > Upon receipt of the last /8 that the IANA will allocate to ARIN per the > > Global Policy for the Allocation of the Remaining IPv4 Address Space, > > ARIN will place an equivalent of a /16 of IPv4 address space in a > > reserve for Critical Infrastructure. If at the end of the policy term > > there is unused address space remaining in this pool, ARIN staff is > > authorized to utilize this space in a manner consistent with community > > expectations. > > > > Rationale: > > > > Section 4.10 of the NRPM is insufficient with respect to insuring the > > continued operation of critical infrastructure. This proposal, if > > adopted, will protect those resources with a reasonable amount of > > reserved v4 address space and prevent an overrun of CI needs by NRPM > > Section 4.10 or any successor. The intent is to separate CI needs and > > make a distinct pool available to insure the continuity of CI > > allocations per NRPM Section 4.4 for at least 36 months. > > > > This proposal should be considered an emergency proposal. IANA > > exhaustion is likely to occur prior to the next ARIN meeting. > > > > Timetable for implementation: Immediate > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > 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 marty at akamai.com Tue Dec 7 13:38:20 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 7 Dec 2010 13:38:20 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B42F@SUEX07-MBX-04.ad.syr.edu> Message-ID: Milton, NRPM Section 4.4 is the scope for this proposal and it is clearly defined. In fact, I specifically narrowed the intent to support 4.4 to limit "interpretations". Best, -M< On 12/7/10 1:28 PM, "Milton L Mueller" wrote: > Is the definition of "critical infrastructure" sufficiently clear such that it > can be applied unambiguously? > Only definition I can find is NPRM 6.10.1. Do we have a precise definition or > understanding of what is a "public exchange point" and a "core DNS service > provider"? In a world of 5,000 TLDs, do all g and cc TLDs have the same > status? > two purposes, something that might occur if there was just one pool", From bicknell at ufp.org Tue Dec 7 13:41:01 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 7 Dec 2010 10:41:01 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B42F@SUEX07-MBX-04.ad.syr.edu> References: <75822E125BCB994F8446858C4B19F0D70AC125B42F@SUEX07-MBX-04.ad.syr.edu> Message-ID: <20101207184101.GA18314@ussenterprise.ufp.org> In a message written on Tue, Dec 07, 2010 at 01:28:27PM -0500, Milton L Mueller wrote: > Only definition I can find is NPRM 6.10.1. Do we have a precise definition or understanding of what is a "public exchange point" and a "core DNS service provider"? In a world of 5,000 TLDs, do all g and cc TLDs have the same status? Section 4.4: ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. [...] Note that the root and ccTLD's are very slow changing. Countries don't come and go that quickly. :) I could potentially see a little concern in the gTLD space. ICANN could add 5 every decade, or could add 200k next year. I think the latter is unlikely, and thus the policy/defintion as it exists gives me no pause. I have no hard data on exchange point groth rates, but my gut tells me that's a pretty darn low rate of growth as well. -- 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 farmer at umn.edu Tue Dec 7 13:53:51 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 07 Dec 2010 12:53:51 -0600 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: Message-ID: <4CFE82BF.3090805@umn.edu> On 12/7/10 11:51 CST, Hannigan, Martin wrote: > > On 12/7/10 12:21 PM, "David Farmer" wrote: > >> On 12/2/10 13:02 CST, ARIN wrote: >> ... > >>> >>> The ARIN AC should review and determine what action if any should be >>> taken at their next available opportunity, or sooner if they deem >>> warranted. >> >> Was the the third paragraph of the current policy intentionally remove? >> That paragraph was intended to allow transfers via section 8.3 to >> continue to receive a 12 month supply and not restricted to 3 month like >> allocations from the ARIN pool. I believe it is important to retain this. > > > The proposal itself as published by ARIN said: > > Proposal type: Modify, complete replacement of 4.2.4.4 > > > [ clip ] > >> I'm not opposed to this policy, but I don't believe it is necessary to >> change the policy in order to achieve the desired result, assuming the >> only desired result is to grandfather those in queue with the 12 month >> supply. Do others on PPML support this interpretation of section >> 4.2.4.4? Is this a reasonable course of action? I did ask "If that is incorrect, would you please explain why you think it is a good idea to restrict these transfers to a 3 month supply, and that should be more prominent in the rationale." Well then, I guess I do oppose the policy as written, at least until I receive a better rationale for why to restrict transfers to a 3 month supply is a good idea. This issue was discussed as part of 2009-8. So, I cannot support removing it without a clear and convincing rationale for why it should be removed. Furthermore, I would be very skeptical removing it through the use of the emergency PDP, since it was relatively recently added through the normal PDP. I'm not opposed to grandfathering those in the queue at the time of the change, and as I said I believe that can be accomplished without changing the policy and without the use of the emergency PDP. -- =============================================== 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 heather.skanks at gmail.com Tue Dec 7 14:03:50 2010 From: heather.skanks at gmail.com (Heather Schiller) Date: Tue, 7 Dec 2010 14:03:50 -0500 Subject: [arin-ppml] Regarding interesting times ahead... In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E03BA55@PLSWM12A.ad.sprint.com> <5A6D953473350C4B9995546AFE9939EE0B14CD92@RWC-EX1.corp.seven.com> Message-ID: On Tue, Dec 7, 2010 at 12:24 PM, John Curran wrote: > On Dec 7, 2010, at 11:46 AM, George Bonser wrote: > >> Yup. ?As soon as "Company with lots of full time lawyers on staff" tries >> to get an allocation and can't, it is going to be hell. > > Indeed, it's going to be quite an interesting time. ?I believe it will be > important for us to be clear that not all hope is lost, i.e. under current > resource ?policy firms will still be able to qualify for up to 3 months of > space and then can either wait to see if such returned space comes available > to them via the waiting list, or they can find someone who has space that > could be potentially freed up & work with them to receive a specified transfer > (of up to 12 months space per documented need) under NRPM 8.3. > 12 months under 8.3 transfer post IANA exhaust? I understood it as 3 months: "8.3. Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient. Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies." At the time of IANA depletion, ARIN drops to a 3 month allocation window -- which would be the 'current ARIN policy' in question. Well, if 12months is the case, that certainly is interesting, and I'm not sure it is what the community intended... Certainly makes it more enticing for folks to go out and try to scare up an 8.3 transfer and put off deploying v6 a bit :( Can you clarify/verify? > This may not satisfy a lot of companies, but is slightly more palatable > than having no chance at all of obtaining address space. > > Whatever policy we end up with post-depletion, I do expect that we'll be > explaining those options to many, many organizations in the near future > and I'm hopeful that the participants of this mailing list will become > advocates getting the full message disseminated throughout the region. > That may not keep all the lawyers at bay, but it certainly will help... > > /John > > John Curran > President and CEO > ARIN > > > _______________________________________________ > 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 farmer at umn.edu Tue Dec 7 14:07:48 2010 From: farmer at umn.edu (David Farmer) Date: Tue, 07 Dec 2010 13:07:48 -0600 Subject: [arin-ppml] Regarding interesting times ahead... In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E03BA55@PLSWM12A.ad.sprint.com> <5A6D953473350C4B9995546AFE9939EE0B14CD92@RWC-EX1.corp.seven.com> Message-ID: <4CFE8604.9040707@umn.edu> On 12/7/10 13:03 CST, Heather Schiller wrote: > On Tue, Dec 7, 2010 at 12:24 PM, John Curran wrote: >> On Dec 7, 2010, at 11:46 AM, George Bonser wrote: >> >>> Yup. As soon as "Company with lots of full time lawyers on staff" tries >>> to get an allocation and can't, it is going to be hell. >> >> Indeed, it's going to be quite an interesting time. I believe it will be >> important for us to be clear that not all hope is lost, i.e. under current >> resource policy firms will still be able to qualify for up to 3 months of >> space and then can either wait to see if such returned space comes available >> to them via the waiting list, or they can find someone who has space that >> could be potentially freed up& work with them to receive a specified transfer >> (of up to 12 months space per documented need) under NRPM 8.3. >> > > 12 months under 8.3 transfer post IANA exhaust? I understood it as 3 months: > > "8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources > within the ARIN region may be released to ARIN by the authorized > resource holder, in whole or in part, for transfer to another > specified organizational recipient. Such transferred number resources > may only be received under RSA by organizations that are within the > ARIN region and can demonstrate the need for such resources, as a > single aggregate, in the exact amount which they can justify under > current ARIN policies." > > At the time of IANA depletion, ARIN drops to a 3 month allocation > window -- which would be the 'current ARIN policy' in question. > Well, if 12months is the case, that certainly is interesting, and I'm > not sure it is what the community intended... Certainly makes it more > enticing for folks to go out and try to scare up an 8.3 transfer and > put off deploying v6 a bit :( > > Can you clarify/verify? The current NRPN says; ---- 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12-month supply of IP addresses. When ARIN receives its last /8, by IANA implementing section 10.4.2.2, the length of supply that an organization may request will be reduced. An organization may choose to request up to a 3-month supply of IP addresses. This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses. ---- It is this last paragraph that comes into play, this is what Marty and I were just discussing in regards to PP#124, which would remove this. -- =============================================== 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 owen at delong.com Tue Dec 7 14:46:43 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 7 Dec 2010 11:46:43 -0800 Subject: [arin-ppml] Regarding interesting times ahead... In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E03BA55@PLSWM12A.ad.sprint.com> <5A6D953473350C4B9995546AFE9939EE0B14CD92@RWC-EX1.corp.seven.com> Message-ID: On Dec 7, 2010, at 11:03 AM, Heather Schiller wrote: > On Tue, Dec 7, 2010 at 12:24 PM, John Curran wrote: >> On Dec 7, 2010, at 11:46 AM, George Bonser wrote: >> >>> Yup. As soon as "Company with lots of full time lawyers on staff" tries >>> to get an allocation and can't, it is going to be hell. >> >> Indeed, it's going to be quite an interesting time. I believe it will be >> important for us to be clear that not all hope is lost, i.e. under current >> resource policy firms will still be able to qualify for up to 3 months of >> space and then can either wait to see if such returned space comes available >> to them via the waiting list, or they can find someone who has space that >> could be potentially freed up & work with them to receive a specified transfer >> (of up to 12 months space per documented need) under NRPM 8.3. >> > > 12 months under 8.3 transfer post IANA exhaust? I understood it as 3 months: > > "8.3. Transfers to Specified Recipients > > In addition to transfers under section 8.2, IPv4 number resources > within the ARIN region may be released to ARIN by the authorized > resource holder, in whole or in part, for transfer to another > specified organizational recipient. Such transferred number resources > may only be received under RSA by organizations that are within the > ARIN region and can demonstrate the need for such resources, as a > single aggregate, in the exact amount which they can justify under > current ARIN policies." > > At the time of IANA depletion, ARIN drops to a 3 month allocation > window -- which would be the 'current ARIN policy' in question. > Well, if 12months is the case, that certainly is interesting, and I'm > not sure it is what the community intended... Certainly makes it more > enticing for folks to go out and try to scare up an 8.3 transfer and > put off deploying v6 a bit :( > > Can you clarify/verify? > Given that the policy which reached consensus specifically included the 8.3 exemption, why would you think it comes as a surprise to the community or that the community would not expect it? Owen From jcurran at arin.net Tue Dec 7 19:28:07 2010 From: jcurran at arin.net (John Curran) Date: Wed, 8 Dec 2010 00:28:07 +0000 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <4CFE6D24.3090601@umn.edu> References: <4CF7ED4B.6080105@arin.net> <4CFE6D24.3090601@umn.edu> Message-ID: <1E983072-CE57-42BC-A7ED-5252A8F10A9D@arin.net> On Dec 7, 2010, at 12:21 PM, David Farmer wrote: > > So I guess I have a question for John Curran; Would it be in order and sufficient for the AC to recommend to the Board that policy 2009-8 now section 4.2.4.4 of the NRPM have the triggering clause be implemented for new requests that are received after the triggering event, and that requests received before the trigger be grandfathered? If the AC believes that the policy should be implemented differently, it simply needs to inform the President and that will be reviewed. ARIN is not infallible, and the AC is an important check to make sure we're correctly implementing policy. I will review it with the senior staff and make sure that we're handling the policy implementation in a consistent manner. Depending on the results of the review, we would either revise or sustain the current implementation processes. The more certain path to having a policy implemented via a specific process, and that would be the adoption of specific language to that effect in the policy. This avoids any chance of staff misinterpretation, but does needs the full policy process since there may have been others in the community who only supported the policy based on their thoughts on on its likely implementation and need to have an opportunity to speak for/against the new language and resulting implementation change. I will note that in the case of this particular language, any ISP who only receives a 3 month allocation can come back (after 3 months with 2010-1 implemented) and qualify for additional space if they still need additional resources and such are available. Given that the purpose of 2009-8 was to provide for equitable distribution post IANA depletion, suppressing the 3 month limit for allocations actually made after IANA runout simply because they are already the queue is likely to only encourage submissions today of not-quite-complete "placeholder" additional space requests to the queue, and similar attempts at gaming of the system. This should not dissuade the ARIN AC for considering a policy change if they feel the current policy is flawed; it is only provided as insight into a implementation concern that arises from changing the process for existing requests in the queue at runout. /John John Curran President and CEO ARIN From tedm at ipinc.net Wed Dec 8 04:02:38 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 08 Dec 2010 01:02:38 -0800 Subject: [arin-ppml] Regarding interesting times ahead... In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E03BA55@PLSWM12A.ad.sprint.com> <5A6D953473350C4B9995546AFE9939EE0B14CD92@RWC-EX1.corp.seven.com> Message-ID: <4CFF49AE.4000502@ipinc.net> On 12/7/2010 9:24 AM, John Curran wrote: > On Dec 7, 2010, at 11:46 AM, George Bonser wrote: > >> Yup. As soon as "Company with lots of full time lawyers on staff" tries >> to get an allocation and can't, it is going to be hell. > > Indeed, it's going to be quite an interesting time. I don't actually think it's going to be that interesting for a while yet. Lawyers are pretty pragmatic and the first question the lawyers are going to ask is "what are other people doing" The answer of course is "using non-portable numbers from some upstream along with a lot of NAT" Then the next thing the lawyers are going to say is "it's going to be a lot cheaper for you to do the same thing" I tend to believe the impassioned arguments from system administrators about how it would be so much trouble for them to work around these drawbacks will be pretty much ignored by the lawyers. It's not going to be until they just aren't available at all, even for money, that the lawyers are going to get involved - and by the time the courts figure anything out, IPv6 will be in full force. Ted I believe it will be > important for us to be clear that not all hope is lost, i.e. under current > resource policy firms will still be able to qualify for up to 3 months of > space and then can either wait to see if such returned space comes available > to them via the waiting list, or they can find someone who has space that > could be potentially freed up& work with them to receive a specified transfer > (of up to 12 months space per documented need) under NRPM 8.3. > > This may not satisfy a lot of companies, but is slightly more palatable > than having no chance at all of obtaining address space. > > Whatever policy we end up with post-depletion, I do expect that we'll be > explaining those options to many, many organizations in the near future > and I'm hopeful that the participants of this mailing list will become > advocates getting the full message disseminated throughout the region. > That may not keep all the lawyers at bay, but it certainly will help... > > /John > > John Curran > President and CEO > ARIN > > > _______________________________________________ > 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 marty at akamai.com Wed Dec 8 12:02:36 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 8 Dec 2010 12:02:36 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <1E983072-CE57-42BC-A7ED-5252A8F10A9D@arin.net> Message-ID: On 12/7/10 7:28 PM, "John Curran" wrote: [ snip ] > > I will note that in the case of this particular language, any ISP who > only receives a 3 month allocation can come back (after 3 months with > 2010-1 implemented) and qualify for additional space if they still > need additional resources and such are available. Given that the > purpose of 2009-8 was to provide for equitable distribution post IANA > depletion, suppressing the 3 month limit for allocations actually made > after IANA runout simply because they are already the queue is likely > to only encourage submissions today of not-quite-complete "placeholder" > additional space requests to the queue, and similar attempts at gaming > of the system. This should not dissuade the ARIN AC for considering > a policy change if they feel the current policy is flawed; it is only > provided as insight into a implementation concern that arises from > changing the process for existing requests in the queue at runout. The proposal has "some" language to address placeholders: " Any pending request submitted prior to that moment will continue to be eligible for a twelve month supply of addresses as long as need is established within thirty days of that moment." The language around need could be improved to tighten that up further if warranted. The time extension is to provide for staff questions and applicant responses such as requesting additional justification related specifically to what was provided and not for time to develop need. I do see a problem with an entity sending ARIN an incomplete application. The intent of the proposal is to apply it to bona-fide resource applications only. Best, -M< From charles at office.tcsn.net Wed Dec 8 14:17:32 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 08 Dec 2010 11:17:32 -0800 Subject: [arin-ppml] Policy Proposal 121: Sensible IPv6 Allocation for ISPs - revised In-Reply-To: <4CF7BFF3.2030106@arin.net> References: <4CF7BFF3.2030106@arin.net> Message-ID: <4CFFD9CC.8020501@office.tcsn.net> We strong support this policy proposal. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net On 12/2/10 7:49 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 121: Sensible IPv6 Allocation for ISPs > > Proposal Version: .9 > > Date: 2 December 2010 > > Policy statement: > >> Amend section 2 as follows: >> >> Delete section 2.9 (Obsolete) >> Replace section 2.10 with the following: >> 2.10 The term End Site shall mean a single structure or service delivery >> address, or, in the case of a multi-tenant structure, a single tenant >> within said structure (a single customer location). >> Add the following: >> 2.12 The term serving site shall mean a location where an ISP terminates >> or aggregates customer connections, including, but, not limited to >> Points of Presence (POPs), Datacenters, Central or Local switching >> office or regional or local combinations thereof. >> 2.13 The term provider assignment unit shall mean the prefix of the >> smallest block a given ISP assigns to end sites (recommended /48). >> 2.14 The term utilized shall have the following definitions: >> (i) A provider assignment unit shall be considered fully utilized when >> it is assigned to an end-site. >> (ii) Larger blocks shall have their utilization defined by dividing the >> number of provider assignment units assigned from the >> containing block by the total number of provider assignment >> units. This ratio will often be expressed as a percentage >> (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) >> >> Replace sections 6.5.1 through 6.5.3 with the following: >> 6.5.1 Terminology >> (a) The terms ISP and LIR are used interchangeably in this document and >> any use of either term shall be construed to include both meanings. >> (b) The term nibble boundary shall mean a network mask which aligns >> on a 4-bit boundary (in slash notation, /n, where n is evenly divisible >> by 4, allowing unit quantities of X such that 2^n=X where n is >> evenly divisible by 4, such as 16, 256, 4096, etc.) >> >> 6.5.2 Initial Allocations to LIRs >> 6.5.2.1 Size >> (a) All allocations shall be made on nibble boundaries. >> (b) In no case shall an LIR receive smaller than a /32 >> unless they specifically request a /36. >> (c) The maximum allowable allocation shall be the smallest >> nibble-boundary aligned block that can provide an equally >> sized nibble-boundary aligned block to each of the >> requesters serving sites large enough to satisfy the needs >> of the requesters largest single serving site using no more >> than 75% of the available addresses. >> >> This calculation can be summarized as /N where >> N = 48-(X+Y) and X is a multiple of 4 greater >> than 4/3*serving sites and Y is a multiple of 4 >> greater than 4/3*end sites served by largest serving site. >> >> (d) For purposes of the calculation in (c), an end site which >> can justify more than a /48 under the end-user assignment >> criteria in 6.5.8 shall count as the appropriate number of /48s >> that would be assigned under that policy. >> (e) For purposes of the calculation in (c), an LIR which has >> subordinate LIRs shall make such allocations according >> to the same policies and criteria as ARIN. In such a case, >> the prefixes necessary for such an allocation should be treated >> as fully utilized in determining the block sizing for the parent LIR. >> (f) An LIR is not required to design or deploy their network >> according to this structure. It is strictly a mechanism to >> determine the largest IP address block to which the LIR >> is entitled. >> 6.5.2.2 Qualifications >> An organization qualifies for an allocation under this policy if >> they meet any of the following criteria: >> (a) Have a previously justified IPv4 ISP allocation from ARIN >> or one of its predecessor registries or can qualify for >> an IPv4 ISP allocation under current criteria. >> (b) Are currently multihomed for IPv6 or will immediately >> become multihomed for IPv6 using a valid assigned >> global AS number and will be making reassignments >> to other organizations. >> (c) Provide ARIN a reasonable technical justification, >> indicating why an allocation is necessary, including >> the intended purposes for the allocation, and describing >> the network infrastructure the allocation will be used to >> support. Justification must include a plan detailing assignments >> to other organizations or customers for one, two and five year >> periods, with a minimum of 50 assignments within 5 years. >> 6.5.3 Subsequent Allocations to LIRs >> (a) Where possible ARIN will make subsequent allocations by >> expanding the existing allocation. >> (b) An LIR which can show utilization of 75% or more of their >> total address space, or more than 90% of any serving site >> shall be entitled to a subsequent allocation. >> (c) If ARIN can not expand one or more existing allocations, >> ARIN shall make a new allocation based on the initial >> allocation criteria above. The LIR is encouraged, but not >> required to renumber into the new allocation over time >> and return any allocations no longer in use. >> Replace section 6.5.4 with the following >> 6.5.4 Assignments to end users shall be governed by the same >> practices adopted by the community in section 6.5.8 except >> that the requirements in 6.5.8.1 do not apply. >> >> Add the following to 6.5.7 >> LIRs which received an allocation under previous policies which is >> smaller than what they are entitled to under this policy may receive >> a new initial allocation under this policy provided that they agree to >> renumber into that new allocation and return their prior allocation(s) >> within 5 years. If possible, ARIN will simply expand their existing >> allocation rather than requiring renumber and return. > > > > _______________________________________________ > 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. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From owen at delong.com Wed Dec 8 20:04:06 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Dec 2010 17:04:06 -0800 Subject: [arin-ppml] Why should we do Proposal 121 Message-ID: I've been asked by a fellow AC member to spend some more effort documenting reasons we should enact proposal 121. 1. Current IPv6 policy is being interpreted to the detriment of ISPs that have subordinate ISPs. Subordinate ISPs should be able to get PA space from their upstreams equivalent to what they would be able to get directly from ARIN. Currently, ARIN is not allowing for the possibility that an ISP would reallocate /32s (or larger) to their subordinate ISPs. 2. HD Ratio is confusing to people and of dubious value vs. basing utilization on simple ratios. 3. A large number of historic outages have been the direct result of people being generally bad at bitmath. By moving allocations to nibble boundaries, we can reduce the likelihood of these errors by removing complex bitmath from most network deployments. 4. The current complexity of getting allocations larger than /32 from ARIN is resulting in many providers choosing, instead, to shrink the size of assignments they give to end sites to less than /48. If this practice becomes wide spread, it will likely reduce possible innovations in the SOHO realm because vendors will generally implement to the lowest common denominator. We have already seen this with various consumer electronics that assume that there is no way to reach the device from the global internet and either depend on rendezvous/relay solutions or simply don't provide features that take advantage of global reachability. IPv6 allows us to restore the end-to-end model to the internet so that these and other capabilities become realistic. It would be unfortunate to artificially limit the potential for innovation by reducing the number of bits available to do so unnecessarily. Further, a concern was raised that we would potentially blow through address space too rapidly. The particular AC member in question works for one of the largest (potentially the largest) eyeball ISPs in existence. He stated that under the proposed policy, his network might qualify for as much as a /12. There are probably no more than 16 organizations of comparable size (I estimate 10 or fewer) worldwide. Let's assume we burned through twice that number of /12s (>80% of IPv4 allocations in ARIN have been to the 24 X-Large organizations). Even if we assume the absolute maximum possible... 5 RIRs x 24 X-Large organizations = 120 /12 allocations. So, 120 /12s would be 80% of the total IPv6 we would need to issue, 120/0.8 = 150 total /12s consumed world wide, if every RIR were to implement this proposal. That's roughly 23.5% of the first 1/8th of IPv6 address space. That means we still leave 97% of all IPv6 space on the shelf for the foreseeable future. The potential consumption from this policy simply isn't an issue. I expect that our total consumption will be far less than the worst case I show above. In fact, if we get through 20 /12s in the next 5 years, I'd support reviewing the policy and consideration of whether we should reduce allocation sizes. Owen From jcurran at arin.net Thu Dec 9 08:38:55 2010 From: jcurran at arin.net (John Curran) Date: Thu, 9 Dec 2010 13:38:55 +0000 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: Message-ID: <622A14FD-EFEE-4EBC-B09C-58648DD627EA@arin.net> On Dec 8, 2010, at 8:04 PM, Owen DeLong wrote: > I've been asked by a fellow AC member to spend some more effort documenting > reasons we should enact proposal 121. Thanks Owen! > 1. Current IPv6 policy is being interpreted to the detriment of ISPs that > have subordinate ISPs. Subordinate ISPs should be able to get PA > space from their upstreams equivalent to what they would be able > to get directly from ARIN. Currently, ARIN is not allowing for the > possibility that an ISP would reallocate /32s (or larger) to their > subordinate ISPs. > ... It would be good to get additional community discussion on this point and implications, i.e. when an ISP states it will be serving subordinate ISPs as part of its need justification, what assumptions are considered valid about such subordinate ISPs? Do any of the subordinate ISPs themselves need allocations that allow them to serve subordinate ISPs as well, or require allocations for transition purposes? Existing practice generally is that ISPs (regardless of size) come to ARIN for their own IPv6 allocation, and while this is not required, the current policy does not provide adequate guidance for allowing larger allocations for ISPs that wish to have numerous ISP customers and serve as the registry for each. Hence, the need for additional community discussion regarding the issues involved. Thank you! /John John Curran President and CEO ARIN From bill at herrin.us Thu Dec 9 09:15:25 2010 From: bill at herrin.us (William Herrin) Date: Thu, 9 Dec 2010 09:15:25 -0500 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: Message-ID: On Wed, Dec 8, 2010 at 8:04 PM, Owen DeLong wrote: > 1. ? ? ?Current IPv6 policy is being interpreted to the detriment of ISPs that > ? ? ? ?have subordinate ISPs. Subordinate ISPs should be able to get PA > ? ? ? ?space from their upstreams equivalent to what they would be able > ? ? ? ?to get directly from ARIN. Currently, ARIN is not allowing for the > ? ? ? ?possibility that an ISP would reallocate /32s (or larger) to their > ? ? ? ?subordinate ISPs. Hi Owen, Can you suggest a scenario in which a a subordinate /32 allocation is unambiguously appropriate on the technical merits versus the same ARIN allocation directly to the subordinate ISP? It seems to me like you might have to make some unwarranted assumptions to get there. > 2. ? ? ?HD Ratio is confusing to people and of dubious value vs. basing > ? ? ? ?utilization on simple ratios. Agree 100%. In addition to being cryptic, ARIN's HD ratio is a misapplication of the relevant research. The math has been modified in a way inconsistent with what little empirical data supports the original observations. It should go away. > 3. ? ? ?A large number of historic outages have been the direct result > ? ? ? ?of people being generally bad at bitmath. By moving allocations > ? ? ? ?to nibble boundaries, we can reduce the likelihood of these > ? ? ? ?errors by removing complex bitmath from most network deployments. Agree 100%. There are many good reasons for limiting the bit boundaries on which allocations are made and the nibble is a natural boundary for IPv6. > 4. ? ? ?The current complexity of getting allocations larger than /32 from > ? ? ? ?ARIN is resulting in many providers choosing, instead, to shrink > ? ? ? ?the size of assignments they give to end sites to less than /48. > ? ? ? ?If this practice becomes wide spread, it will likely reduce possible > ? ? ? ?innovations in the SOHO realm because vendors will generally > ? ? ? ?implement to the lowest common denominator. I don't personally find a reduction from /48 a compelling argument. If anything, a more reasonable recommendation than /48 would tend to help folks avoid foolish mistakes like /64... which actually could create the lowest-common-denominator effect you fear. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Thu Dec 9 10:55:25 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 09 Dec 2010 09:55:25 -0600 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: Message-ID: <4D00FBED.3070700@brightok.net> On 12/9/2010 8:15 AM, William Herrin wrote: > On Wed, Dec 8, 2010 at 8:04 PM, Owen DeLong wrote: >> 1. Current IPv6 policy is being interpreted to the detriment of ISPs that >> have subordinate ISPs. Subordinate ISPs should be able to get PA >> space from their upstreams equivalent to what they would be able >> to get directly from ARIN. Currently, ARIN is not allowing for the >> possibility that an ISP would reallocate /32s (or larger) to their >> subordinate ISPs. > > Hi Owen, > > Can you suggest a scenario in which a a subordinate /32 allocation is > unambiguously appropriate on the technical merits versus the same ARIN > allocation directly to the subordinate ISP? It seems to me like you > might have to make some unwarranted assumptions to get there. > > I can. I manage an ISP; except in my case, I have no end user customers. What I have is a company that pools resources for 12 ILEC ISPs. I am their LIR, I manage servers for them. I even manage their routers and address assignments for most of them. Even the multihomed ones have their ASN through me, not ARIN. By current policy, each can go to ARIN and ask for a /32 minimum and pay their fees. However, that has never been our practice. In practice, I go to ARIN, pay a single fee (which is smaller than the total of individual fees) and in many cases, when the ILEC isn't multihomed actively, I announce them as part of my aggregate only. ARIN stated the /32 minimum for an ISP was added on IETF recommendation. I propose that the IETF was thinking of any ISP, including subordinate ISPs. The /32 minimum keeps smaller/medium ISPs from growing in small block increments which could lead to fragementation. For example, current ARIN policy is to allocate on exact usage (HD-Ratio doesn't apply to initial allocation, only subsequent due to a policy error). If I accept an exact usage from ARIN for my 12 ILECs combined, then as any of them grows, I have to assign a separate non-contiguous block to them. This, in turn means an additional route in the routing table. As ARIN assigned based on exact counts, I have no reserves for contiguous space. I can't renumber networks as ARIN finally decides to give me HD-Ratio. Compare this to getting a /27 (by pricing standards, I really don't want to exceed that anyways), and I assigned 14 /32 to the 12 ILECs (a couple of them also have downstream ISPs), of which there will be 4 route announcements (aggregate + 3 multihomed ILEC aggregates) This is current, not counting Owen's proposal. Owen's proposal is about fixing this problem. The additional bonus on the nibble boundary analysis is that it grows the network out even more in some cases, allowing even better assignment schemes with room for reservations to deal with known growing networks; which in turn can reduce routing table bloat. If the pricing structure adjusts to match, I'd be thrilled with a /24 vs the /27 I'm going for today, which would allow me a lot of room to handle assignments to my subordinate ISPs and if they exceed their /32, grow them into a /28. Since I can handle 16 /28's, my network would forever announce 1 aggregate in my foreseeable future except for the few multihomed ILECs (who would also be protected and safe of having to announce more routes due to fragmentation). > I don't personally find a reduction from /48 a compelling argument. If > anything, a more reasonable recommendation than /48 would tend to help > folks avoid foolish mistakes like /64... which actually could create > the lowest-common-denominator effect you fear. > I think his concern is limiting the bits that can work with the childish implementations that will be used in automatically handling DHCPv6-PD through multiple end-user routers. The problem is that the standard doesn't support better dynamic allocation, and the thought is that it probably won't ever reach a perfected model, so routers will have to do a divide and conquer method of reassigning networks automatically. The size of the network directly effects the width and depth that such an assignment scheme can support. Jack From owen at delong.com Thu Dec 9 11:21:50 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Dec 2010 08:21:50 -0800 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: Message-ID: <15497EB7-AF9A-42EE-ADCD-29D799C29F8A@delong.com> On Dec 9, 2010, at 6:15 AM, William Herrin wrote: > On Wed, Dec 8, 2010 at 8:04 PM, Owen DeLong wrote: >> 1. Current IPv6 policy is being interpreted to the detriment of ISPs that >> have subordinate ISPs. Subordinate ISPs should be able to get PA >> space from their upstreams equivalent to what they would be able >> to get directly from ARIN. Currently, ARIN is not allowing for the >> possibility that an ISP would reallocate /32s (or larger) to their >> subordinate ISPs. > > Hi Owen, > > Can you suggest a scenario in which a a subordinate /32 allocation is > unambiguously appropriate on the technical merits versus the same ARIN > allocation directly to the subordinate ISP? It seems to me like you > might have to make some unwarranted assumptions to get there. > I'm not sure I understand the question. It is my opinion that the policy for space that an ISP can reallocate to a subordinate ISP should be identical to the policy governing what space ARIN can allocate to that same ISP. Either the policy is good stewardship of the address space or it is not. If it is not good policy, then, we should change the ARIN policy. If it is good policy, then the ISP should be able to make the reallocation if that is where the other ISP prefers to get their space. > >> 2. HD Ratio is confusing to people and of dubious value vs. basing >> utilization on simple ratios. > > Agree 100%. In addition to being cryptic, ARIN's HD ratio is a > misapplication of the relevant research. The math has been modified in > a way inconsistent with what little empirical data supports the > original observations. It should go away. > > >> 3. A large number of historic outages have been the direct result >> of people being generally bad at bitmath. By moving allocations >> to nibble boundaries, we can reduce the likelihood of these >> errors by removing complex bitmath from most network deployments. > > Agree 100%. There are many good reasons for limiting the bit > boundaries on which allocations are made and the nibble is a natural > boundary for IPv6. > > >> 4. The current complexity of getting allocations larger than /32 from >> ARIN is resulting in many providers choosing, instead, to shrink >> the size of assignments they give to end sites to less than /48. >> If this practice becomes wide spread, it will likely reduce possible >> innovations in the SOHO realm because vendors will generally >> implement to the lowest common denominator. > > I don't personally find a reduction from /48 a compelling argument. If > anything, a more reasonable recommendation than /48 would tend to help > folks avoid foolish mistakes like /64... which actually could create > the lowest-common-denominator effect you fear. > Personally, I don't think that /48 is unreasonable. However, I will point out that proposal 121 does not prevent ISPs from choosing to give out less than a /48, it merely sets an upper bound at /48 and makes it easy for the ISP to get sufficient space to allow for /48s if they choose. Is there a reason you think /48s are "unreasonable"? Personally, I think they are quite reasonable. Owen From jbates at brightok.net Thu Dec 9 11:44:29 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 09 Dec 2010 10:44:29 -0600 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: Message-ID: <4D01076D.4090208@brightok.net> On 12/8/2010 7:04 PM, Owen DeLong wrote: > 1. Current IPv6 policy is being interpreted to the detriment of ISPs that > have subordinate ISPs. Subordinate ISPs should be able to get PA > space from their upstreams equivalent to what they would be able > to get directly from ARIN. Currently, ARIN is not allowing for the > possibility that an ISP would reallocate /32s (or larger) to their > subordinate ISPs. As a side note, community participation would be nice on this point as I've asked ARIN to decide how it will interpret the current policy regarding subordinate ISPs (policy lacks any wording). While it's uncertain how much role community comments would play in such an interpretation, I doubt they would be ignored. Owen, being better with his words than me, said it best in another email: > Either the policy is good stewardship of the address space or it is not. If > it is not good policy, then, we should change the ARIN policy. If it is good > policy, then the ISP should be able to make the reallocation if that is > where the other ISP prefers to get their space. Jack From gary.buhrmaster at gmail.com Thu Dec 9 12:00:07 2010 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 9 Dec 2010 09:00:07 -0800 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: Message-ID: On Wed, Dec 8, 2010 at 17:04, Owen DeLong wrote: > I've been asked by a fellow AC member to spend some more effort documenting > reasons we should enact proposal 121. Thanks. > > 1. ? ? ?Current IPv6 policy is being interpreted to the detriment of ISPs that > ? ? ? ?have subordinate ISPs. Subordinate ISPs should be able to get PA > ? ? ? ?space from their upstreams equivalent to what they would be able > ? ? ? ?to get directly from ARIN. Currently, ARIN is not allowing for the > ? ? ? ?possibility that an ISP would reallocate /32s (or larger) to their > ? ? ? ?subordinate ISPs. I would agree that I see no reasons that any ISP should not be able to support their customers with legitimate requirements, even if that customer is considered a subordinate ISP and even if it ends up needing a /12. Stepping back a bit, my question would be why these subordinate ISPs are not going directly to ARIN for numbers. Is it because of pricing (they are "small", and do not want to pay for a /32)? Is it because of the ARIN paperwork (which I have never found especially difficult, but my tolerances may be different)? Is it because of a historical arrangement with their upstream which has, essentially, provided the LIR function for them? Is it a question of requiring subordinates to use PA space? Is it simply that one or more of the ISPs is using an IPv4 mindset regarding how space will/should be used? Is this about insuring end sites get a /48? Is there something else at play here? I just want to be sure that this proposal will address the (perceived or real) issues, which I am sure I do not fully understand at this point. Gary From marty at akamai.com Thu Dec 9 14:10:28 2010 From: marty at akamai.com (Hannigan, Martin) Date: Thu, 9 Dec 2010 14:10:28 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <4CFE82BF.3090805@umn.edu> Message-ID: On 12/7/10 1:53 PM, "David Farmer" wrote: > On 12/7/10 11:51 CST, Hannigan, Martin wrote: >> >> On 12/7/10 12:21 PM, "David Farmer" wrote: >> >>> On 12/2/10 13:02 CST, ARIN wrote: >>> ... >> >>>> >>>> The ARIN AC should review and determine what action if any should be >>>> taken at their next available opportunity, or sooner if they deem >>>> warranted. >>> >>> Was the the third paragraph of the current policy intentionally remove? >>> That paragraph was intended to allow transfers via section 8.3 to >>> continue to receive a 12 month supply and not restricted to 3 month like >>> allocations from the ARIN pool. I believe it is important to retain this. >> >> >> The proposal itself as published by ARIN said: >> >> Proposal type: Modify, complete replacement of 4.2.4.4 >> >> >> [ clip ] >> >>> I'm not opposed to this policy, but I don't believe it is necessary to >>> change the policy in order to achieve the desired result, assuming the >>> only desired result is to grandfather those in queue with the 12 month >>> supply. Do others on PPML support this interpretation of section >>> 4.2.4.4? Is this a reasonable course of action? > > I did ask "If that is incorrect, would you please explain why you think > it is a good idea to restrict these transfers to a 3 month supply, and > that should be more prominent in the rationale." David, First, I apologize that I wasn't able to completely answer your email in the first round. It's an extremely busy time of year and I addressed what I saw as the most relevant portion of your email. Restricting transfers is akin to using austerity measures that we are going to implement post exhaustion except that now it's inverse as applied to the STLS. It would seem to me that it would discourage some abuses of the transfer system and discourage abuses related to "address funding" of transfers. It also gives us some time to come up to speed on the issues. I'd hate to see someone grab large swaths of legacy space only to find out that we've created a mess that will deprive others the opportunity to acquire transition addresses if they have to. Finally, how many transition addresses does one need? On 11/29, Scott Liebrand suggested that non-profits operating CI be forced to the STLS. It's important to get it right. Can you think of a reason not to implement a cap on the STLS, at least to start out? > Well then, I guess I do oppose the policy as written, at least until I > receive a better rationale for why to restrict transfers to a 3 month > supply is a good idea. This issue was discussed as part of 2009-8. > So, I cannot support removing it without a clear and convincing > rationale for why it should be removed. Furthermore, I would be very > skeptical removing it through the use of the emergency PDP, since it was > relatively recently added through the normal PDP. > > I'm not opposed to grandfathering those in the queue at the time of the That's good news. In reviewing John Curran's comment, I'm confident that there is a compatible way to reduce the likelihood of frivolous applications. We won't totally eliminate them with either interpretation of this policy and proposal, but should be able to make the issue moot. The intent is to allow people in the queue that have legitimate need and have submitted legitimate and complete applications to receive address space and clean up the queue in a more responsible manner than the original proposal has allowed for. > change, and as I said I believe that can be accomplished without > changing the policy and without the use of the emergency PDP. > I'm ok with that, but as John noted if we want to be sure that we are having policy interpreted properly, it should be written as such. I think we need to pass something to be 100% sure and that includes the STLS cap. Best, -M< From jcurran at arin.net Thu Dec 9 14:19:32 2010 From: jcurran at arin.net (John Curran) Date: Thu, 9 Dec 2010 19:19:32 +0000 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: Message-ID: <273A4E58-3AFE-4998-A3B6-6B14F07F6390@corp.arin.net> On Dec 9, 2010, at 2:10 PM, Hannigan, Martin wrote: > Restricting transfers is akin to using austerity measures that we are going > to implement post exhaustion except that now it's inverse as applied to the > STLS. It would seem to me that it would discourage some abuses of the > transfer system and discourage abuses related to "address funding" of > transfers. It also gives us some time to come up to speed on the issues. I'd > hate to see someone grab large swaths of legacy space only to find out that > we've created a mess that will deprive others the opportunity to acquire > transition addresses if they have to. Finally, how many transition addresses > does one need? On 11/29, Scott Liebrand suggested that non-profits operating > CI be forced to the STLS. It's important to get it right. Can you think of a > reason not to implement a cap on the STLS, at least to start out? > ... Its likely that everyone understood what you meant, but just for clarity... I believe that most your references in the above should be to NRPM 8.3, the Specified Transfer policy. The STLS (Specified Transfer Listing Service) is completely separate, and is simply one way parties might find each other. For more details on STLS, see Regardless of how parties find one another, they may transfer space via ARIN if they qualify under NRPM 8.3. FYI, /John John Curran President and CEO ARIN From marty at akamai.com Thu Dec 9 14:28:42 2010 From: marty at akamai.com (Hannigan, Martin) Date: Thu, 9 Dec 2010 14:28:42 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <273A4E58-3AFE-4998-A3B6-6B14F07F6390@corp.arin.net> Message-ID: On 12/9/10 2:19 PM, "John Curran" wrote: > On Dec 9, 2010, at 2:10 PM, Hannigan, Martin wrote: > >> Restricting transfers is akin to using austerity measures that we are going >> to implement post exhaustion except that now it's inverse as applied to the >> STLS. It would seem to me that it would discourage some abuses of the >> transfer system and discourage abuses related to "address funding" of >> transfers. It also gives us some time to come up to speed on the issues. I'd >> hate to see someone grab large swaths of legacy space only to find out that >> we've created a mess that will deprive others the opportunity to acquire >> transition addresses if they have to. Finally, how many transition addresses >> does one need? On 11/29, Scott Liebrand suggested that non-profits operating >> CI be forced to the STLS. It's important to get it right. Can you think of a >> reason not to implement a cap on the STLS, at least to start out? >> ... > > Its likely that everyone understood what you meant, but just for clarity... > I believe that most your references in the above should be to NRPM 8.3, > the Specified Transfer policy. The STLS (Specified Transfer Listing Service) > is completely separate, and is simply one way parties might find each other. > For more details on STLS, see > > Regardless of how parties find one another, they may transfer space via ARIN > if they qualify under NRPM 8.3 Yes, and thanks. To be perfectly clear, I have proposed as a part of PP 124 to remove the following from the policy statement in 4.2.4.4: "This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses." The effect would be that transfers would also be subject to a three-month window of need. Best, -M< From charles at office.tcsn.net Thu Dec 9 14:33:36 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Thu, 09 Dec 2010 11:33:36 -0800 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: Message-ID: <4D012F10.6090800@office.tcsn.net> While I do support Proposal 121, I do have a concern/questions about Owen's first point. On 12/8/10 5:04 PM, Owen DeLong wrote: > I've been asked by a fellow AC member to spend some more effort documenting > reasons we should enact proposal 121. > > 1. Current IPv6 policy is being interpreted to the detriment of ISPs that > have subordinate ISPs. Subordinate ISPs should be able to get PA > space from their upstreams equivalent to what they would be able > to get directly from ARIN. Currently, ARIN is not allowing for the > possibility that an ISP would reallocate /32s (or larger) to their > subordinate ISPs. I think it is important to be careful here about two things. 1) While removing any obstacles or discouragement from subordinate ISPs receiving PA space is a good thing, we should take care that we don't end up discouraging the same ISPs from obtaining PI space instead. I do not believe the current wording does this, but I think it is important to keep the point in mind for future edits. 2) After the SWIP topics of this last year on the PPML list, I have this impression that record keeping across the ARIN region is a bit inconsistent and lacks automation. I hate to bring up what seems to be a dead-horse topic, but should SWIP policy be modified in regards to any difference between subordinate ISPs and large end users? Should there be a policy about SWIP auditing? Does a multi-homed subordinate ISP, which qualifies for a /32 of PI from ARIN, qualify to get a /32 PA from each of its providers? Given the size of v6 are we even concerned if they do so? And what would that do to global routing table growth? and a personal ignorance question: Does a subordinate ISP with X aggregate allocations advertised through Y direct upstream ISPs end up adding X x Y routes to the global tables? > -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From jbates at brightok.net Thu Dec 9 15:47:24 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 09 Dec 2010 14:47:24 -0600 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: <4D012F10.6090800@office.tcsn.net> References: <4D012F10.6090800@office.tcsn.net> Message-ID: <4D01405C.1020500@brightok.net> On 12/9/2010 1:33 PM, Charles O'Hern wrote: > and a personal ignorance question: Does a subordinate ISP with X > aggregate allocations advertised through Y direct upstream ISPs end > up adding X x Y routes to the global tables? > I believe that justification is still in order. If an ISP requests PA space from another ISP, their current (if any) space would also be taken into account. It is also important that any ISP giving space to another ISP must show to ARIN the justification of that ISP (just as if the ISP had gone to ARIN direct). One could even push it a step further and require contracts to be shown to ARIN (similar to contracts used to prove multihoming for ASN, but just to prove ISP1 is a customer of ISP2). Even in v4, if I ask one of my ISP's for a /20, they will give it to me if I show justification, but my justification to them is identical to my justification to ARIN (includes all allocations from ARIN or other ISPs to include my address space as a whole). This is, hopefully, checked against the BGP permission lists/justifications done by the ISP as well. The current v4 model has many loopholes which allow for fraud, and the v6 model follows suit. If contracts are required in justification to ARIN, we could utilize the corporate entity itself which is assigned a single org-id to prohibit duplication. I'm not sure if ARIN would accept this, as it means (just like it does with it's own org-ids) that ARIN must verify each corporate entity. Only org-id's which are assigned as such and classified as an ISP can be assigned space from ARIN or from another ISP. This would require more overhead on assigning the ISP org-id, but then ARIN would have less work to do in allocations, as ISPs would be handling that part. In short, if you want to lower fraud, create the ISP classification for an org-id, and only org-id's with that classification can receive allocations; all other org-ids can only receive assignments. Jack From jbates at brightok.net Thu Dec 9 16:45:57 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 09 Dec 2010 15:45:57 -0600 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: <15497EB7-AF9A-42EE-ADCD-29D799C29F8A@delong.com> References: <15497EB7-AF9A-42EE-ADCD-29D799C29F8A@delong.com> Message-ID: <4D014E15.6050006@brightok.net> I still believe ISP->ISP is appropriate, but I do believe that the policy should perhaps add the justification for being an ISP (ie, method of ARIN validating that an ISP is receiving the appropriate space). The common methods as I mentioned on ppml are to show corporate documents (as is done with ARIN when first getting an ORG-ID; and is designed to try and keep an entity from cloning itself and having space assigned to multiple org-ids from different entities) and/or contract copies as we do in proving multihoming for ASN. I'm not sure how much of this is policy worthy and how much is implementation specific. Also, I'm not sure that nibble assignments are necessary or appropriate for ISP -> ISP transactions? Contiguous space is important within the scope of a single ISP, but subtending ISPs (especially when multihomed) don't require this (if they went to ARIN, they wouldn't be contiguous with their upstream, so assigning a /32 do a downstream's downstream ISP wouldn't need to be contiguous). I'm also not sure on nibble allocation sizes in this type of scenario; though not completely against it. Jack On 12/9/2010 10:21 AM, Owen DeLong wrote: > Either the policy is good stewardship of the address space or it is not. If > it is not good policy, then, we should change the ARIN policy. If it is good > policy, then the ISP should be able to make the reallocation if that is > where the other ISP prefers to get their space. From jbates at brightok.net Thu Dec 9 16:47:02 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 09 Dec 2010 15:47:02 -0600 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: <4D014E15.6050006@brightok.net> References: <15497EB7-AF9A-42EE-ADCD-29D799C29F8A@delong.com> <4D014E15.6050006@brightok.net> Message-ID: <4D014E56.4090204@brightok.net> Oops. Wrong button. Was supposed to be private, which is why it rehashes a lot of my other emails onlist. Jack On 12/9/2010 3:45 PM, Jack Bates wrote: > I still believe ISP->ISP is appropriate, but I do believe that the > policy should perhaps add the justification for being an ISP (ie, method > of ARIN validating that an ISP is receiving the appropriate space). The > common methods as I mentioned on ppml are to show corporate documents > (as is done with ARIN when first getting an ORG-ID; and is designed to > try and keep an entity from cloning itself and having space assigned to > multiple org-ids from different entities) and/or contract copies as we > do in proving multihoming for ASN. > > I'm not sure how much of this is policy worthy and how much is > implementation specific. > > Also, I'm not sure that nibble assignments are necessary or appropriate > for ISP -> ISP transactions? Contiguous space is important within the > scope of a single ISP, but subtending ISPs (especially when multihomed) > don't require this (if they went to ARIN, they wouldn't be contiguous > with their upstream, so assigning a /32 do a downstream's downstream ISP > wouldn't need to be contiguous). I'm also not sure on nibble allocation > sizes in this type of scenario; though not completely against it. > > > Jack > > On 12/9/2010 10:21 AM, Owen DeLong wrote: >> Either the policy is good stewardship of the address space or it is >> not. If >> it is not good policy, then, we should change the ARIN policy. If it >> is good >> policy, then the ISP should be able to make the reallocation if that is >> where the other ISP prefers to get their space. > _______________________________________________ > 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 Dec 9 21:58:49 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Dec 2010 18:58:49 -0800 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: Message-ID: On Dec 9, 2010, at 9:00 AM, Gary Buhrmaster wrote: > On Wed, Dec 8, 2010 at 17:04, Owen DeLong wrote: >> I've been asked by a fellow AC member to spend some more effort documenting >> reasons we should enact proposal 121. > > Thanks. > >> >> 1. Current IPv6 policy is being interpreted to the detriment of ISPs that >> have subordinate ISPs. Subordinate ISPs should be able to get PA >> space from their upstreams equivalent to what they would be able >> to get directly from ARIN. Currently, ARIN is not allowing for the >> possibility that an ISP would reallocate /32s (or larger) to their >> subordinate ISPs. > > I would agree that I see no reasons that any ISP should not be > able to support their customers with legitimate requirements, > even if that customer is considered a subordinate ISP and even > if it ends up needing a /12. > > Stepping back a bit, my question would be why these subordinate > ISPs are not going directly to ARIN for numbers. Is it because > of pricing (they are "small", and do not want to pay for a /32)? Could be any number of reasons. Could be pricing. Could be that since they are single-homed to the upstream ISP, they prefer to preserve aggregation by using PA space. Could be the nature of the business relationship they have with the upstream ISP. Bottom line, it is not for ARIN to define these relationships. They should be up to the ISPs. > Is it because of the ARIN paperwork (which I have never found > especially difficult, but my tolerances may be different)? Is it > because of a historical arrangement with their upstream which > has, essentially, provided the LIR function for them? Is it a > question of requiring subordinates to use PA space? Is it > simply that one or more of the ISPs is using an IPv4 mindset > regarding how space will/should be used? Is this about > insuring end sites get a /48? Is there something else at > play here? > It could be any one or any combination of these or other factors. Is it actually relevant? > I just want to be sure that this proposal will address the > (perceived or real) issues, which I am sure I do not > fully understand at this point. > At the very least, this proposal creates a single consistent policy for ISPs and also makes the subordinate end user policy identical to ARIN end user policy. I think this is desirable and improves on the current situation. We can always make changes to the consistent policy if we find that it needs further tweaking, but, at least making things consistent at this point is worth while. Owen From scottleibrand at gmail.com Thu Dec 9 22:04:59 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 9 Dec 2010 19:04:59 -0800 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: <273A4E58-3AFE-4998-A3B6-6B14F07F6390@corp.arin.net> Message-ID: On Thu, Dec 9, 2010 at 11:28 AM, Hannigan, Martin wrote: > To be perfectly clear, I have proposed as a part of PP 124 > to remove the following from the policy statement in 4.2.4.4: > > "This ?reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to ?request > up to a 12-month supply of IP addresses." > > > The effect would be that transfers would also be subject to a three-month > window of need. IMO this would have a substantial negative effect on the number of routes in the IPv4 routing table. The reason for keeping the 8.3 supply at 12 months was because we expect that a large fraction of 8.3 transfers will result in deaggregation of a larger block into multiple smaller blocks. If transfer recipients are required to get a new transfer every 3 months instead of every 12, we can expect 4 times as much demand for deaggregation in such situations. -Scott From owen at delong.com Thu Dec 9 22:20:31 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 9 Dec 2010 19:20:31 -0800 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: <4D012F10.6090800@office.tcsn.net> References: <4D012F10.6090800@office.tcsn.net> Message-ID: <918D8C04-41E7-43E9-A488-99E538A85CF7@delong.com> On Dec 9, 2010, at 11:33 AM, Charles O'Hern wrote: > While I do support Proposal 121, I do have a concern/questions about Owen's first point. > > On 12/8/10 5:04 PM, Owen DeLong wrote: >> I've been asked by a fellow AC member to spend some more effort documenting >> reasons we should enact proposal 121. >> >> 1. Current IPv6 policy is being interpreted to the detriment of ISPs that >> have subordinate ISPs. Subordinate ISPs should be able to get PA >> space from their upstreams equivalent to what they would be able >> to get directly from ARIN. Currently, ARIN is not allowing for the >> possibility that an ISP would reallocate /32s (or larger) to their >> subordinate ISPs. > > I think it is important to be careful here about two things. > 1) While removing any obstacles or discouragement from subordinate ISPs receiving PA space is a good thing, we should take care that we don't end up discouraging the same ISPs from > obtaining PI space instead. I do not believe the current wording does this, but I think it is important to keep the point in mind for future edits. > I completely agree. > 2) After the SWIP topics of this last year on the PPML list, I have this impression that record keeping across the ARIN region is a bit inconsistent and lacks automation. I hate > to bring up what seems to be a dead-horse topic, but should SWIP policy be modified in regards to any difference between subordinate ISPs and large end users? Should there be a > policy about SWIP auditing? Does a multi-homed subordinate ISP, which qualifies for a /32 of PI from ARIN, qualify to get a /32 PA from each of its providers? Given the size of > v6 are we even concerned if they do so? And what would that do to global routing table growth? > There are several questions there. I'll attempt to answer them in order. 1. Perhaps, but, I think that is out of scope for this particular proposal. I do not believe this proposal makes the situation any worse than current. I would be happy to work with anyone who wants to write policy to address that issue. 2. Same answer as the first question. 3. I don't see any meaningful way to prevent this, but, I also do not see any advantage to the subordinate ISP from doing so. Their end-sites can each only count as utilization in one of the blocks. 4. I suspect not especially. 5. Nothing more than the single PI block from ARIN since the PA blocks would still be aggregates. > and a personal ignorance question: Does a subordinate ISP with X aggregate allocations advertised through Y direct upstream ISPs end up adding X x Y routes to the global tables? > No.. They end up adding X routes and X*Y Paths to the global tables. However, paths are not the issue, prefixes are. Also, the belief that they add X routes is based on the assumption that none of those X routes are handled by an upstream providers aggregate advertisement. Owen From mysidia at gmail.com Thu Dec 9 22:37:15 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 9 Dec 2010 21:37:15 -0600 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: <273A4E58-3AFE-4998-A3B6-6B14F07F6390@corp.arin.net> Message-ID: On Thu, Dec 9, 2010 at 1:28 PM, Hannigan, Martin wrote: > Yes, and thanks. To be perfectly clear, I have proposed as a part of PP 124 > to remove the following from the policy statement in 4.2.4.4: > > "This ?reduction does not apply to resources received via section 8.3. An > organization receiving a transfer under section 8.3 may continue to ?request > up to a 12-month supply of IP addresses." > > > The effect would be that transfers would also be subject to a three-month > window of need. I oppose PP124 on this basis. Lack of benefit for S8.3 transfers to be restricted. And the significant negative effects that could be anticipated, in regards to routing table fragmentation. Which happens if you have organizations needing to come back and re-apply for address space every 3 months. If there are simply no more addresses left to allocate, until a sufficient quantity can be found to be made through transfer, then there are fewer problems. -- -JH From marty at akamai.com Thu Dec 9 23:02:15 2010 From: marty at akamai.com (Hannigan, Martin) Date: Thu, 9 Dec 2010 23:02:15 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: Message-ID: On 12/9/10 10:04 PM, "Scott Leibrand" wrote: > On Thu, Dec 9, 2010 at 11:28 AM, Hannigan, Martin wrote: >> To be perfectly clear, I have proposed as a part of PP 124 >> to remove the following from the policy statement in 4.2.4.4: >> >> "This ?reduction does not apply to resources received via section 8.3. An >> organization receiving a transfer under section 8.3 may continue to ?request >> up to a 12-month supply of IP addresses." >> >> >> The effect would be that transfers would also be subject to a three-month >> window of need. > > IMO this would have a substantial negative effect on the number of > routes in the IPv4 routing table. The reason for keeping the 8.3 Along with all of the other disaggregation? > supply at 12 months was because we expect that a large fraction of 8.3 > transfers will result in deaggregation of a larger block into multiple > smaller blocks. I'm not sure why anyone is going to want to spend that far into the future with respect to the cost and lack of visibility into the state of transition. This is a great way to undermine the STLS. >If transfer recipients are required to get a new > transfer every 3 months instead of every 12, we can expect 4 times as > much demand for deaggregation in such situations. That would be a guess. You don't know what the cost of addresses will be. That will directly impact demand. Be careful about being too excited about markets. They will be necessary, but it won't be something to be happy about. The cost of an address in a market using STLS will dwarf the costs we have now. Best, -M< From scottleibrand at gmail.com Fri Dec 10 01:08:41 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 9 Dec 2010 22:08:41 -0800 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: Message-ID: On Thu, Dec 9, 2010 at 8:02 PM, Hannigan, Martin wrote: > > On 12/9/10 10:04 PM, "Scott Leibrand" wrote: > >> On Thu, Dec 9, 2010 at 11:28 AM, Hannigan, Martin wrote: >>> To be perfectly clear, I have proposed as a part of PP 124 >>> to remove the following from the policy statement in 4.2.4.4: >>> >>> "This ?reduction does not apply to resources received via section 8.3. An >>> organization receiving a transfer under section 8.3 may continue to ?request >>> up to a 12-month supply of IP addresses." >>> >>> >>> The effect would be that transfers would also be subject to a three-month >>> window of need. >> >> IMO this would have a substantial negative effect on the number of >> routes in the IPv4 routing table. ?The reason for keeping the 8.3 > > Along with all of the other disaggregation? I suspect most of the ARIN free pool will be given out as one block per org per time period, similarly to how it's been given out historically. Draft policy 2010-1: Waiting List for Unmet IPv4 Requests, which was approved by the Board and is awaiting implementation, directs ARIN to "fulfill the request with the largest single block available that fulfills the request", and stipulates that "an organization may only receive one allocation, assignment, or transfer every 3 months". Given that the free pool will be exhausted over a relatively short timeframe (at least until we get down to legacy class C swamp space), I don't think there'll be much impact on the rate of growth in the routing table from the 3-month window of need for getting space from ARIN. However, I expect 8.3 transfers to be the only practical way to get space for a lot more than 3 months, so I think it's reasonable to leave that window at something longer. >> supply at 12 months was because we expect that a large fraction of 8.3 >> transfers will result in deaggregation of a larger block into multiple >> smaller blocks. > > I'm not sure why anyone is going to want to spend that far into the future > with respect to the cost and lack of visibility into the state of > transition. This is a great way to undermine the STLS. As detailed above, any organization can get up to 12 months' worth of space, and can return to the transfer market for more space after 3 months if they need more. I believe that restricting organizations' flexibility by limiting them to 3 months' of space (particularly while preventing them from coming back for more space for 3 months after that), as this proposal does, would actually undermine the transfer market. >>If transfer recipients are required to get a new >> transfer every 3 months instead of every 12, we can expect 4 times as >> much demand for deaggregation in such situations. > > That would be a guess. You don't know what the cost of addresses will be. > That will directly impact demand. Be careful about being too excited about > markets. They will be necessary, but it won't be something to be happy > about. The cost of an address in a market using STLS will dwarf the costs we > have now. Yeah, there will be some organizations that prefer to get the bare minimum (3 months' worth) of space. If that's the predominant behavior, then removing the 12-month option would be a no-op for those organizations. However, I know there are organizations that will want to try to secure enough space that they're not constantly having to go back to the market and deal with the volatility there. Removing the option to get 12 months worth of space would eliminate those organizations' flexibility to do so. I don't see a benefit to the community of doing that. -Scott From jbates at brightok.net Fri Dec 10 09:06:59 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 10 Dec 2010 08:06:59 -0600 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: Message-ID: <4D023403.6070602@brightok.net> On 12/10/2010 12:08 AM, Scott Leibrand wrote: > However, I know there are organizations that will want > to try to secure enough space that they're not constantly having to go > back to the market and deal with the volatility there. Speaking for myself, I try my hardest not to deal with ARIN more than once a year; STLS I'd like to hopefully avoid all together. Jack From marty at akamai.com Fri Dec 10 09:33:41 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 10 Dec 2010 09:33:41 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: Message-ID: On 12/10/10 1:08 AM, "Scott Leibrand" wrote: > On Thu, Dec 9, 2010 at 8:02 PM, Hannigan, Martin wrote: [ clip ] > However, I expect 8.3 transfers to be the only practical way to > get space for a lot more than 3 months, so I think it's reasonable to > leave that window at something longer. There are strategies emerging via multiple sources that address this problem head-on. You don't need the STLS to guarantee your need, you only need it to legitimize your use per current ARIN policy. It will be cheaper to only push exactly what you need through the STLS and on quarterly boundaries to maximize expense control. You can guarantee your price outside of STLS. Best, -M< From owen at delong.com Fri Dec 10 09:53:08 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Dec 2010 06:53:08 -0800 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: Message-ID: <5C36D020-DB08-4622-912B-CD7E29174C45@delong.com> I oppose this proposal. It departs from good stewardship of the address space. Owen On Dec 10, 2010, at 6:33 AM, Hannigan, Martin wrote: > > > > On 12/10/10 1:08 AM, "Scott Leibrand" wrote: > >> On Thu, Dec 9, 2010 at 8:02 PM, Hannigan, Martin wrote: > [ clip ] > > > >> However, I expect 8.3 transfers to be the only practical way to >> get space for a lot more than 3 months, so I think it's reasonable to >> leave that window at something longer. > > There are strategies emerging via multiple sources that address this problem > head-on. You don't need the STLS to guarantee your need, you only need it to > legitimize your use per current ARIN policy. It will be cheaper to only push > exactly what you need through the STLS and on quarterly boundaries to > maximize expense control. You can guarantee your price outside of STLS. > > > Best, > > -M< > > _______________________________________________ > 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 marty at akamai.com Fri Dec 10 10:29:54 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 10 Dec 2010 10:29:54 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <5C36D020-DB08-4622-912B-CD7E29174C45@delong.com> Message-ID: On 12/10/10 9:53 AM, "Owen DeLong" wrote: > > On Dec 10, 2010, at 6:33 AM, Hannigan, Martin wrote: > >> >> >> >> On 12/10/10 1:08 AM, "Scott Leibrand" wrote: >> >>> On Thu, Dec 9, 2010 at 8:02 PM, Hannigan, Martin wrote: >> [ clip ] >> >> >> >>> However, I expect 8.3 transfers to be the only practical way to >>> get space for a lot more than 3 months, so I think it's reasonable to >>> leave that window at something longer. >> >> There are strategies emerging via multiple sources that address this problem >> head-on. You don't need the STLS to guarantee your need, you only need it to >> legitimize your use per current ARIN policy. It will be cheaper to only push >> exactly what you need through the STLS and on quarterly boundaries to >> maximize expense control. You can guarantee your price outside of STLS. > > I oppose this proposal. It departs from good stewardship of the address space. > > Owen If you voted for 8.3 you voted for this kind of activity. You seem to want to have your cake and eat it too. You proposed an end-game policy that squeezed out large networks and you're opposing a group working together to try and address that inequity through the adaptation of an improved NRPM 4.10 that focuses more squarely on transition. Let me mention again that Scott Liebrand proposed pushing CI non-profits to markets. You are both confused about stewardship. It would be extremely beneficial for that group to get together and to engage in a "call option" like activity if we aren't able to guarantee their need. The unfortunate negative is that speculators may engage in "call option" like behavior. It seems inevitable though and highly unlikely to be able to regulate. It could turn out to be beneficial since it could solidify and underline the business case for v6, hence...no need for long term transfers. Anyhow, YMMV. Best, -M< From marty at akamai.com Fri Dec 10 11:10:21 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 10 Dec 2010 11:10:21 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 Message-ID: On 12/10/10 10:51 AM, "Owen DeLong" wrote: [ snip ] >> > First, no, this activity is quite different from 8.3 and it is the > modification to > 8.3 that I am primarily objecting to. How is this in opposition to good stewardship? To be clear, NRPM 8.3 is not being modified. The overshadowing language of NRPM 4.2.4.4 is being modified. In fact, it may be better to have no language and let the staff interpret the intent of the community with respect to the transfer policy in a similar to fashion as the globally coordinated transfer proposal may be interpreted. Regardless, and re-reading the discussion, I'm happy to leave the NRPM 8.3. impacting language alone as a chotski for the support. Best, -M< From owen at delong.com Fri Dec 10 12:24:09 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Dec 2010 09:24:09 -0800 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: Message-ID: On Dec 10, 2010, at 8:10 AM, Hannigan, Martin wrote: > > > > On 12/10/10 10:51 AM, "Owen DeLong" wrote: > > > [ snip ] > >>> >> First, no, this activity is quite different from 8.3 and it is the >> modification to >> 8.3 that I am primarily objecting to. > > How is this in opposition to good stewardship? To be clear, NRPM 8.3 is not > being modified. The overshadowing language of NRPM 4.2.4.4 is being > modified. In fact, it may be better to have no language and let the staff > interpret the intent of the community with respect to the transfer policy in > a similar to fashion as the globally coordinated transfer proposal may be > interpreted. > The overshadowing language in 4.2.4.4 had strong community consensus and is, I believe the intent of the community. Removing it is not, in my opinion beneficial. If you reduce your proposal to simply removing the adding this: Any pending request submitted prior to that moment will continue to be eligible for a twelve month supply of addresses as long as need is established within thirty days of that moment. to 4.2.4.4, yes, I could support that. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Dec 10 13:03:29 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 10 Dec 2010 10:03:29 -0800 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: References: Message-ID: <43264CD9-DB44-4FD5-8641-25D914F982A8@delong.com> On Dec 10, 2010, at 9:24 AM, Owen DeLong wrote: > > On Dec 10, 2010, at 8:10 AM, Hannigan, Martin wrote: > >> >> >> >> On 12/10/10 10:51 AM, "Owen DeLong" wrote: >> >> >> [ snip ] >> >>>> >>> First, no, this activity is quite different from 8.3 and it is the >>> modification to >>> 8.3 that I am primarily objecting to. >> >> How is this in opposition to good stewardship? To be clear, NRPM 8.3 is not >> being modified. The overshadowing language of NRPM 4.2.4.4 is being >> modified. In fact, it may be better to have no language and let the staff >> interpret the intent of the community with respect to the transfer policy in >> a similar to fashion as the globally coordinated transfer proposal may be >> interpreted. >> > The overshadowing language in 4.2.4.4 had strong community consensus > and is, I believe the intent of the community. Removing it is not, in my > opinion beneficial. > > If you reduce your proposal to simply removing the adding this: > Sorry... That should have read: If you reduce your proposal to simply adding this: > Any pending request submitted prior to that moment will continue to be eligible for a twelve month supply of addresses as long as need is established within thirty days of that moment. > > to 4.2.4.4, yes, I could support that. > > 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 -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Fri Dec 10 14:02:40 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 10 Dec 2010 14:02:40 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <43264CD9-DB44-4FD5-8641-25D914F982A8@delong.com> Message-ID: On 12/10/10 1:03 PM, "Owen DeLong" wrote: > > On Dec 10, 2010, at 9:24 AM, Owen DeLong wrote: > >> >> On Dec 10, 2010, at 8:10 AM, Hannigan, Martin wrote: >> >>> >>> >>> >>> On 12/10/10 10:51 AM, "Owen DeLong" wrote: >>> >>> >>> [ snip ] >>> >>>>> >>>> First, no, this activity is quite different from 8.3 and it is the >>>> modification to >>>> 8.3 that I am primarily objecting to. >>> >>> How is this in opposition to good stewardship? To be clear, NRPM 8.3 is not >>> being modified. The overshadowing language of NRPM 4.2.4.4 is being >>> modified. In fact, it may be better to have no language and let the staff >>> interpret the intent of the community with respect to the transfer policy in >>> a similar to fashion as the globally coordinated transfer proposal may be >>> interpreted. >>> >> The overshadowing language in 4.2.4.4 had strong community consensus >> and is, I believe the intent of the community. Removing it is not, in my >> opinion beneficial. Define strong community consensus and show me where in the conversation it was made clear that the effect was going to be that anything in the queue was going to get squashed as a result? It really isn't clear and this is an effect of having policy proposals that overly complex with relation to other sections in the NRPM. >> >> If you reduce your proposal to simply removing the adding this: >> > Sorry... That should have read: > > If you reduce your proposal to simply adding this: > >> Any pending request submitted prior to that moment will continue to be >> eligible for a twelve month supply of addresses as long as need is >> established within thirty days of that moment. >> >> to 4.2.4.4, yes, I could support that. I'm simply going to add back the paragraph with respect to the reference to NRPM 8.3 and probably tighten up the time frame from 30 days to fifteen and add some language that lets staff deal with frivolous applications. From marty at akamai.com Fri Dec 10 20:28:56 2010 From: marty at akamai.com (Hannigan, Martin) Date: Fri, 10 Dec 2010 20:28:56 -0500 Subject: [arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4 In-Reply-To: <43264CD9-DB44-4FD5-8641-25D914F982A8@delong.com> Message-ID: On 12/10/10 1:03 PM, "Owen DeLong" wrote: [ clip ] >> >> If you reduce your proposal to simply removing the adding this: >> > Sorry... That should have read: > > If you reduce your proposal to simply adding this: > >> Any pending request submitted prior to that moment will continue to be >> eligible for a twelve month supply of addresses as long as need is >> established within thirty days of that moment. >> >> to 4.2.4.4, yes, I could support that. This is what I plan to submit for the update. It allows the staff for more discretion with respect to the veracity of the final applications and restores your concern, but with more clear language. That exemption *should* have been written into 8.3 FWIW. With respect to demonstrating reasonable need, this does not mean that ARIN has no further questions. It means that they've received something that has a reasonable change of succeeding and that they should continue to process it to a closure, either approved or rejected. 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, that organization may choose to request up to a 12 month supply of IP addresses. On the date that ARIN receives its last /8 as a result of the IANA executing section 10.4.2.2 of the NRPM and in accordance with the Global Policy for the Allocation of the Remaining IPv4 Address Space, the length of supply that any organization may request from ARIN from that moment forward will be reduced to three months. Any request submitted prior to that moment will continue to be eligible for a twelve month supply of IPv4 addresses as long as need has been reasonably demonstrated and the application is not deemed frivolous. This reduction does not apply to resources received via section 8.3. An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses. From bill at herrin.us Fri Dec 10 22:46:54 2010 From: bill at herrin.us (William Herrin) Date: Fri, 10 Dec 2010 22:46:54 -0500 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: <4D00FBED.3070700@brightok.net> References: <4D00FBED.3070700@brightok.net> Message-ID: On Thu, Dec 9, 2010 at 10:55 AM, Jack Bates wrote: > On 12/9/2010 8:15 AM, William Herrin wrote: >> Can you suggest a scenario in which a a subordinate /32 allocation is >> unambiguously appropriate on the technical merits versus the same ARIN >> allocation directly to the subordinate ISP? > > I can. I manage an ISP; except in my case, I have no end user customers. > What I have is a company that pools resources for 12 ILEC ISPs. I am their > LIR, I manage servers for them. I even manage their routers and address > assignments for most of them. Even the multihomed ones have their ASN > through me, not ARIN. Thanks Jack, I appreciate your insight here. Let me ask a couple follow up questions: When you say "manage resources for them," do you mean number resources, as in you stay on top of the registry and IP address issues so that they don't have to? Or do you provide a smorgasbord of ISP-related resources in bulk, branded email services and so forth, basically a deal where they managed the sales operation and whatever technical components they find advantageous and buy the rest from you? You kind of focused your comments on the price benefit to pooling requests to ARIN. The fee for a /28 split 12 ways is a good bit less than the 12 times the fee for a /32. I assume there's also a financial benefit to needing only one ARIN policy specialist who can manage the ARIN interactions versus each of the 12 needing to have one of their guys fully up to speed and presumably ARIN gains efficiencies from dealing with one expert instead of 12 amateurs. Do you experience any purely technical benefits from pooling the ISPs' requests, or are they all these sort of process benefits? By technical benefit, I mean something like aggregated prefixes in the routing table. If so, can you tell us a little more about it? Thanks, 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 Mon Dec 13 02:14:21 2010 From: warren at wholesaleinternet.com (Warren Johnson) Date: Mon, 13 Dec 2010 01:14:21 -0600 Subject: [arin-ppml] Research Award Message-ID: <280b01cb9a95$5ef88120$1ce98360$@com> This was posted August or September 2009. I did a little digging and couldn't find anything else about it since then. Any idea what come of it? > -----Original Message----- > Subject: FW: [arin-announce] ARIN Awards Research Opportunity > > > The research opportunity, announced by the American Registry for > Internet Numbers on Friday, August 7, 2009, has been awarded to Ben > Edelman. Mr. Edelman is an assistant professor at the Harvard Business > School in the Negotiation, Organizations & Markets unit. > > Mr. Edelman will be conducting research analysis and providing a > report on potential market pricing for IPv4 address space in > increments commonly allocated by the RIRs (/22, /21, /20.../ 16..). > The research analysis and report will focus on the period near and > through IPv4 exhaustion when competitive conditions may result in > maximum prices that bidders are willing to offer for IPv4 address space. > > The full text of the research request is available at: > https://www.arin.net/announcements/2009/20090807.html > > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > From jcurran at arin.net Mon Dec 13 03:04:06 2010 From: jcurran at arin.net (John Curran) Date: Mon, 13 Dec 2010 08:04:06 +0000 Subject: [arin-ppml] Research Award In-Reply-To: <280b01cb9a95$5ef88120$1ce98360$@com> References: <280b01cb9a95$5ef88120$1ce98360$@com> Message-ID: <3F58435B-5217-4A21-813D-538DD4937F17@corp.arin.net> On Dec 13, 2010, at 2:14 AM, Warren Johnson wrote: > This was posted August or September 2009. I did a little digging and > couldn't find anything else about it since then. Any idea what come of it? It was announced on Tuesday, 22 September 2009, and the resulting report was briefed to the Board on 19 April 2010. I'll look into whether a copy can be made publicly available. Thanks! /John John Curran President and CEO ARIN From info at arin.net Mon Dec 13 10:22:44 2010 From: info at arin.net (ARIN) Date: Mon, 13 Dec 2010 10:22:44 -0500 Subject: [arin-ppml] ARIN-prop-124: Clarification of Section 4.2.4.4 - revised Message-ID: <4D063A44.3040407@arin.net> The proposal originator submitted revised text. Note the new nomenclature for proposals, "ARIN-prop-nnn". "ARIN" will also be added to draft policies. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal ARIN-prop-124 Clarification of Section 4.2.4.4 Proposal Originator: Martin Hannigan, Chris Grundemann Proposal Version: 2 Date: 13 December 2010 Proposal type: Modify, complete replacement of 4.2.4.4 Policy term: Permanent Policy statement: 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, that organization may choose to request up to a 12 month supply of IP addresses. On the date that ARIN receives its last /8 as a result of the IANA executing section 10.4.2.2 of the NRPM and in accordance with the Global Policy for the Allocation of the Remaining IPv4 Address Space, the length of supply that any organization may request from ARIN from that moment forward will be reduced to three months. Any request submitted prior to that moment will continue to be eligible for a twelve month supply of IPv4 addresses as long as need has been reasonably demonstrated and the application is not deemed frivolous. This reduction does not apply to resources received through the utilization of NRPM Section 8.3 of the NRPM. An organization receiving a transfer under NRPM Section 8.3 may continue to request up to a 12-month supply of IP addresses. Rationale: ARIN's pending operational practice is that if an organization has a request in the ARIN hostmaster queue for IPv4 resources when the IANA declares the exhaustion phase (10.4.2.2), their request will be automatically truncated from a twelve month supply to a three month supply since policy in effect at the time of exhaustion will apply. 8.3 and 4.2.4.4 are currently "in effect". Example: If an entity is asking for 4 x /24 for a 12 month period and IANA exhaustion occurs, a requester will receive, if justified, 1 x /24. If an entity is asking for 120 x /24 at the time that exhaustion occurs, they would only receive 30 x /24 if justified. If ARIN determines that this same entity would only qualify for 90 of the 120 x /24 requested, then that entity would only receive 22 x /24. ARIN has the equivalent of almost a /8 in at least one reserve, has recently received 2 /8's, received ~391 x /16's as a result of the distribution of "various registries" from the IANA and is guaranteed to receive at least one additional /8 (aggregate of about 92 million individual IPv4 addresses) as a result of the execution of 10.4.2.2 by the IANA. Considering the size of the supply, it would seem prudent to provide for all members needs in a fair and consistent manner as long as possible in order to support the continued orderly transition of the Internet to IPv6. The intention of this proposal is simple. To allow resource requests in the application queue that have provided an application that has a reasonable chance of success the opportunity to complete the process and receive transition addresses. The ARIN AC should review and determine what action if any should be taken at their next available opportunity, or sooner if they deem warranted. From owen at delong.com Mon Dec 13 10:32:15 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 13 Dec 2010 07:32:15 -0800 Subject: [arin-ppml] ARIN-prop-124: Clarification of Section 4.2.4.4 - revised In-Reply-To: <4D063A44.3040407@arin.net> References: <4D063A44.3040407@arin.net> Message-ID: <4F3BD66C-AAC7-4600-9A05-2E473A09C7D2@delong.com> THe first sentence in the last paragraph is redundant. The last sentence alone is better worded and expresses the complete intent of the policy. Owen On Dec 13, 2010, at 7:22 AM, ARIN wrote: > The proposal originator submitted revised text. > > Note the new nomenclature for proposals, "ARIN-prop-nnn". "ARIN" will > also be added to draft policies. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Policy Proposal ARIN-prop-124 > Clarification of Section 4.2.4.4 > > Proposal Originator: Martin Hannigan, Chris Grundemann > > Proposal Version: 2 > > Date: 13 December 2010 > > Proposal type: Modify, complete replacement of 4.2.4.4 > > Policy term: Permanent > > Policy statement: > > 4.2.4.4. Subscriber Members After One Year > > After an organization has been a subscriber member of ARIN for one year, > that organization may choose to request up to a 12 month supply of IP > addresses. > > On the date that ARIN receives its last /8 as a result of the IANA > executing section 10.4.2.2 of the NRPM and in accordance with the Global > Policy for the Allocation of the Remaining IPv4 Address Space, the > length of supply that any organization may request from ARIN from that > moment forward will be reduced to three months. Any request submitted > prior to that moment will continue to be eligible for a twelve month > supply of IPv4 addresses as long as need has been reasonably > demonstrated and the application is not deemed frivolous. > > This reduction does not apply to resources received through the > utilization of NRPM Section 8.3 of the NRPM. An organization receiving a > transfer under NRPM Section 8.3 may continue to request up to a 12-month > supply of IP addresses. > > Rationale: > > ARIN's pending operational practice is that if an organization has a > request in the ARIN hostmaster queue for IPv4 resources when the IANA > declares the exhaustion phase (10.4.2.2), their request will be > automatically truncated from a twelve month supply to a three month > supply since policy in effect at the time of exhaustion will apply. 8.3 > and 4.2.4.4 are currently "in effect". > > Example: If an entity is asking for 4 x /24 for a 12 month period and > IANA exhaustion occurs, a requester will receive, if justified, 1 x /24. > If an entity is asking for 120 x /24 at the time that exhaustion occurs, > they would only receive 30 x /24 if justified. If ARIN determines that > this same entity would only qualify for 90 of the 120 x /24 requested, > then that entity would only receive 22 x /24. > > ARIN has the equivalent of almost a /8 in at least one reserve, has > recently received 2 /8's, received ~391 x /16's as a result of the > distribution of "various registries" from the IANA and is guaranteed to > receive at least one additional /8 (aggregate of about 92 million > individual IPv4 addresses) as a result of the execution of 10.4.2.2 by > the IANA. Considering the size of the supply, it would seem prudent to > provide for all members needs in a fair and consistent manner as long as > possible in order to support the continued orderly transition of the > Internet to IPv6. > > The intention of this proposal is simple. To allow resource requests in > the application queue that have provided an application that has a > reasonable chance of success the opportunity to complete the process and > receive transition addresses. > > The ARIN AC should review and determine what action if any should be > taken at their next available opportunity, or sooner if they deem warranted. > > > _______________________________________________ > 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 marty at akamai.com Mon Dec 13 10:38:29 2010 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 13 Dec 2010 10:38:29 -0500 Subject: [arin-ppml] ARIN-prop-124: Clarification of Section 4.2.4.4 - revised In-Reply-To: <4F3BD66C-AAC7-4600-9A05-2E473A09C7D2@delong.com> Message-ID: On 12/13/10 10:32 AM, "Owen DeLong" wrote: > THe first sentence in the last paragraph is redundant. The last sentence > alone is better worded and expresses the complete intent of the policy. > Support or not? -M< From jbates at brightok.net Mon Dec 13 10:50:27 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 13 Dec 2010 09:50:27 -0600 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: <4D00FBED.3070700@brightok.net> Message-ID: <4D0640C3.6000508@brightok.net> On 12/10/2010 9:46 PM, William Herrin wrote: > When you say "manage resources for them," do you mean number > resources, as in you stay on top of the registry and IP address issues > so that they don't have to? Or do you provide a smorgasbord of > ISP-related resources in bulk, branded email services and so forth, > basically a deal where they managed the sales operation and whatever > technical components they find advantageous and buy the rest from you? While there is some amount of branding, unfortunately, way back in the day, many of them ended up branding to us, instead of themselves. It makes it really fun when you decide to split things up and brand them individually when there is already a bunch of users thinking of it the other way. We manage 99% of the servers for them (a few have inhouse stuff), account maintenance app, and share configuration duties for their routers and equipment they buy. So the ILEC owns all their hardware, customers, etc, and we own the central servers and routers which bring them together (core) to interlink to various NSP. For them, cost savings come in time and personnel, with perhaps some savings in bandwidth (we pass costs on at no profit, though it's a curve of losing money to making money to balance out the losses, as we go from one upgrade to the next). Most of our profit is in the servers and helpdesk they use, which also provides them with an on-call engineer 24/7 to handle any issues (including their corp firewalls or advice on in-house networking needs). > You kind of focused your comments on the price benefit to pooling > requests to ARIN. The fee for a /28 split 12 ways is a good bit less > than the 12 times the fee for a /32. I assume there's also a financial > benefit to needing only one ARIN policy specialist who can manage the > ARIN interactions versus each of the 12 needing to have one of their > guys fully up to speed and presumably ARIN gains efficiencies from > dealing with one expert instead of 12 amateurs. > This is my viewpoint. Most of the ILECs haven't a clue who ARIN is or how IP allocations work. In IPv4, I monitor when they are close to exhaustion and allocate more addresses to them. If they have a new project (such as upgrading the cell systems to 3g), we discuss what the needs of the project are, and I make the necessary allocation. In fact, it is such a way, that even if I did go to ARIN for each /32, I'd have to make the request myself 12 times! :( > Do you experience any purely technical benefits from pooling the ISPs' > requests, or are they all these sort of process benefits? By technical > benefit, I mean something like aggregated prefixes in the routing > table. If so, can you tell us a little more about it? > Obviously, when a customer multihomes, I have to deaggregate the space they are using. This is one reason I've pushed for the ability to give them /32, else I'll end up having to assign multiple prefixes to them (in v4, it's not unusual for even the small one's to have 3x /23 due to growth over time). While 2-3 prefixes isn't excessive, I'm small scale so my contribution to table growth is also small, but equally unacceptable. At all times, I advertise our aggregates as received from ARIN. I may advertise an overlaying smaller route in the case of a multihomed ILEC or for load balancing purposes if necessary (generally I can get away with not needing the load balancing due to other BGP customers who request direct from ARIN and are actually customers of my ILEC customers). tldr; We use much less routes due to aggregation as suspected and when multihoming hope to issue the /32 minimum to keep from doubling or tripling the routes sent for that ILEC. Jack From scottleibrand at gmail.com Mon Dec 13 12:39:51 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 13 Dec 2010 09:39:51 -0800 Subject: [arin-ppml] ARIN-prop-124: Clarification of Section 4.2.4.4 - revised In-Reply-To: <4D063A44.3040407@arin.net> References: <4D063A44.3040407@arin.net> Message-ID: <924C1429-8C06-42CA-9490-66E5399B5A88@gmail.com> I have no problem with this revised text. Thanks, Scott On Dec 13, 2010, at 7:22 AM, ARIN wrote: > The proposal originator submitted revised text. > > Note the new nomenclature for proposals, "ARIN-prop-nnn". "ARIN" will > also be added to draft policies. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Policy Proposal ARIN-prop-124 > Clarification of Section 4.2.4.4 > > Proposal Originator: Martin Hannigan, Chris Grundemann > > Proposal Version: 2 > > Date: 13 December 2010 > > Proposal type: Modify, complete replacement of 4.2.4.4 > > Policy term: Permanent > > Policy statement: > > 4.2.4.4. Subscriber Members After One Year > > After an organization has been a subscriber member of ARIN for one year, > that organization may choose to request up to a 12 month supply of IP > addresses. > > On the date that ARIN receives its last /8 as a result of the IANA > executing section 10.4.2.2 of the NRPM and in accordance with the Global > Policy for the Allocation of the Remaining IPv4 Address Space, the > length of supply that any organization may request from ARIN from that > moment forward will be reduced to three months. Any request submitted > prior to that moment will continue to be eligible for a twelve month > supply of IPv4 addresses as long as need has been reasonably > demonstrated and the application is not deemed frivolous. > > This reduction does not apply to resources received through the > utilization of NRPM Section 8.3 of the NRPM. An organization receiving a > transfer under NRPM Section 8.3 may continue to request up to a 12-month > supply of IP addresses. > > Rationale: > > ARIN's pending operational practice is that if an organization has a > request in the ARIN hostmaster queue for IPv4 resources when the IANA > declares the exhaustion phase (10.4.2.2), their request will be > automatically truncated from a twelve month supply to a three month > supply since policy in effect at the time of exhaustion will apply. 8.3 > and 4.2.4.4 are currently "in effect". > > Example: If an entity is asking for 4 x /24 for a 12 month period and > IANA exhaustion occurs, a requester will receive, if justified, 1 x /24. > If an entity is asking for 120 x /24 at the time that exhaustion occurs, > they would only receive 30 x /24 if justified. If ARIN determines that > this same entity would only qualify for 90 of the 120 x /24 requested, > then that entity would only receive 22 x /24. > > ARIN has the equivalent of almost a /8 in at least one reserve, has > recently received 2 /8's, received ~391 x /16's as a result of the > distribution of "various registries" from the IANA and is guaranteed to > receive at least one additional /8 (aggregate of about 92 million > individual IPv4 addresses) as a result of the execution of 10.4.2.2 by > the IANA. Considering the size of the supply, it would seem prudent to > provide for all members needs in a fair and consistent manner as long as > possible in order to support the continued orderly transition of the > Internet to IPv6. > > The intention of this proposal is simple. To allow resource requests in > the application queue that have provided an application that has a > reasonable chance of success the opportunity to complete the process and > receive transition addresses. > > The ARIN AC should review and determine what action if any should be > taken at their next available opportunity, or sooner if they deem warranted. > > > _______________________________________________ > 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 marty at akamai.com Mon Dec 13 12:52:16 2010 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 13 Dec 2010 12:52:16 -0500 Subject: [arin-ppml] ARIN-prop-124: Clarification of Section 4.2.4.4 - revised In-Reply-To: <924C1429-8C06-42CA-9490-66E5399B5A88@gmail.com> Message-ID: On 12/13/10 12:39 PM, "Scott Leibrand" wrote: > I have no problem with this revised text. > Scott, Is that support or not? Best, -M< From scottleibrand at gmail.com Mon Dec 13 13:05:09 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 13 Dec 2010 10:05:09 -0800 Subject: [arin-ppml] ARIN-prop-124: Clarification of Section 4.2.4.4 - revised In-Reply-To: References: Message-ID: <1CA77075-C3CD-41FC-BA6F-604B023BE4E3@gmail.com> On Dec 13, 2010, at 9:52 AM, "Hannigan, Martin" wrote: > > On 12/13/10 12:39 PM, "Scott Leibrand" wrote: > >> I have no problem with this revised text. >> > > > Scott, > > Is that support or not? Not sure yet. I will probably support a recommendation to ARIN staff that they interpret existing policy in a manner consistent with this clarification. I'm not sure if I would support an emergency PDP recommendation, but at the moment I have no reason to oppose it. I'm still hoping to hear some additional input from folks that haven't posted yet, which could persuade me one way or the other. Scott From bill at herrin.us Mon Dec 13 15:42:09 2010 From: bill at herrin.us (William Herrin) Date: Mon, 13 Dec 2010 15:42:09 -0500 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: <4D0640C3.6000508@brightok.net> References: <4D00FBED.3070700@brightok.net> <4D0640C3.6000508@brightok.net> Message-ID: On Mon, Dec 13, 2010 at 10:50 AM, Jack Bates wrote: > On 12/10/2010 9:46 PM, William Herrin wrote: >> When you say "manage resources for them," do you mean number >> resources, as in you stay on top of the registry and IP address issues >> so that they don't have to? Or do you provide a smorgasbord of >> ISP-related resources in bulk, branded email services and so forth, >> basically a deal where they managed the sales operation and whatever >> technical components they find advantageous and buy the rest from you? > > While there is some amount of branding, unfortunately, way back in the day, > many of them ended up branding to us, instead of themselves. It makes it > really fun when you decide to split things up and brand them individually > when there is already a bunch of users thinking of it the other way. > > We manage 99% of the servers for them (a few have inhouse stuff), account > maintenance app, and share configuration duties for their routers and > equipment they buy. So the ILEC owns all their hardware, customers, etc, and > we own the central servers and routers which bring them together (core) to > interlink to various NSP. Hi Jack, You have basically the same situation I had back in the day at CrossLink. We had some resellers who were just sales folk and some who bought in bulk and manged the customer. We also had two special resellers: one who owned hardware, customers and POP sites but we bought and managed the pipes and one who managed the entire last mile process. The latter reseller/partner expected us to provide upstream connectivity, servers (except web) and management/configuration of the equipment. We managed the IP addresses at the top level and in the large it was one ISP, not three. Like my situation, it doesn't sound to me like you have 12 subordinate ISPs, it sounds to me like you have 12 reseller/partners. I hate to tell you, but I frankly don't think it would be appropriate for you to try to reserve space for sparse /32 allocations at the LIR level any more than it would have been appropriate for such a dramatic reservation scheme with IPv4 back at CrossLink. I've been through the bit math in this forum before. There are barely enough bits for three layers of sparse allocation: RIR, ISP and customer. There really aren't enough for another layer of sparse. On the other hand, I think your story points out one flaw in the IPv6 process that I'd like to see get further attention: Multiple Discrete Networks. Where your networks are geographically diverse, you can request a /32 for each under the MDN policy. However, you still get a contiguous larger allocation. As those discrete networks grow, this inherently results in undesirable discontiguous announcements. Perhaps policy should be adjusted so that a registrant (you) can request discontiguous addresses when justified under the MDN policy. That way if you know your discrete networks will grow independently rather than growing together you can get appropriate allocations that can grow by enlarging the netmask while the unallocated space for sparse-allocation continues to be held by ARIN instead of by you and you continue to pay for space in aggregate instead of separately. How far would that go towards solving your problem? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Mon Dec 13 16:33:06 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 13 Dec 2010 15:33:06 -0600 Subject: [arin-ppml] Why should we do Proposal 121 In-Reply-To: References: <4D00FBED.3070700@brightok.net> <4D0640C3.6000508@brightok.net> Message-ID: <4D069112.2080105@brightok.net> On 12/13/2010 2:42 PM, William Herrin wrote: > I hate to tell you, but I frankly don't think it would be appropriate > for you to try to reserve space for sparse /32 allocations at the LIR > level any more than it would have been appropriate for such a dramatic > reservation scheme with IPv4 back at CrossLink. I've been through the > bit math in this forum before. There are barely enough bits for three > layers of sparse allocation: RIR, ISP and customer. There really > aren't enough for another layer of sparse. > Except we are referring to the same thing. I'm not asking for sparse allocations as an ISP providing for another ISP. I'm asking for the appropriate space and right to give the ISP a /32. Keep in mind, some of these are multihomed. I'm just a consultant in many ways. Even if the pricing model changed, there's nothing wrong with me receiving a /24 to handle a large number of ISPs; though honestly I'm happy with a /27 which meets my requirements. The community benefit, is that by current network topology, I'll be advertising a /27, /30, and 2x /32 networks (my aggregate plus a medium and 2 small ISP customers deaggregated due to multihoming). Compare this to the fact that each can go to ARIN and request a separate /32 for each ISP and even their subtending ISP customers. This could be done by the same technical person (me), but then we end up with over 12 /32 routes added to the table. > Perhaps policy should be adjusted so that a registrant (you) can > request discontiguous addresses when justified under the MDN policy. > That way if you know your discrete networks will grow independently > rather than growing together you can get appropriate allocations that > can grow by enlarging the netmask while the unallocated space for > sparse-allocation continues to be held by ARIN instead of by you and > you continue to pay for space in aggregate instead of separately. > > How far would that go towards solving your problem? > It doesn't really solve my problem, as currently ARIN is not supporting /32 assignments to my subtended ISP customers. This means they aren't allowed any growth room under the space which is being allocated to me (currently debating a /30 total). In most of these cases, a /32 supports plenty of room for growth and so discontiguous space is not a current fear (unless I accept the /30 and assign the bare minimums to each subtending ISP, which guarantees discontiguous space and given that my smallest networks which are most likely to need additional space are multihomed, it means that will show in the BGP routing tables). You stipulate using different sparse allocations, but that still jumps me from 4 prefixes up to over 12; which is worse than my current IPv4 routes. Even if I treat them by ASN, I just had 2 of my smallest ISP customers jump from singlehomed to multihomed and advertised multiple /23 IPv4 routes(2 today, and an additional 3 /23 in a few weeks when the other transitions). :( I have 4 ASNs, and with a /27, I could easily handle 4 prefixes advertised. This is much less than if I go to ARIN direct for each ISP. I know someone is doing math and curious about the /27 vs the /28, and this is due to there being subtending ISPs off my subtending ISPs which are multihomed (we only care about contiguous within the ASN itself). Owen has done the math and informs me that it's not a problem to have ISPs grown this way, 1) looking at the rarity of the tree, 2) the price associated if it grows too large and 3) there is a crap load of IPv6 space. Here's where it gets funny. Under current policy, if initial allocation supported HD-Ratio adjusted allocation (like the new policy), I'd still qualify for a /27 (current policy doesn't support this, but only the bare minimum to renumber). By the new policy, I qualify for a /24. In all cases, I can still assign the /32 or shorter prefixes for each of the subtending ISPs. Yet by current policy, I was offered a /30. No room to grow, and guaranteed to advertise multiple routes (/32 ISP minimum allows for ISP growth in smaller ISPs and was probably why it was recommended originally). Jack (wordy as always, but think I covered it all) From john.sweeting at twcable.com Tue Dec 14 15:34:13 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Tue, 14 Dec 2010 15:34:13 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: Message-ID: To All Subscribers of PPML, Please take time to provide your thoughts on the Proposals that have recently been submitted and may need immediate action in order to really do any good. The only current method to put a Policy Proposal in place immediately is through the "Emergency PDP" and as everyone should be aware, the ARIN Board of Trustees is the only body enabled to use the Emergency PDP. The preferred course of action would be to have the community as well as the AC strongly advocate the use of the Emergency PDP by the BoT for any of these proposals that the community feels warrants immediate enactment. The list of current Policy Proposals that the AC will be considering at its next meeting (Thursday, Dec 16th) is: * ARIN-prop-125. Efficient Utilization of IPv4 Requires Dual-Stack * ARIN-prop-124. Clarification of Section 4.2.4.4 * ARIN-prop-123. Reserved Pool for Critical Infrastructure * ARIN-prop-122. Reserved Pool for Future Policy Development * ARIN-prop-121. Sensible IPv6 Allocation for ISPs * ARIN-prop-120. Protecting Number Resources * ARIN-prop-119. Globally Coordinated Transfer Policy It would be of great help if members of the community would take the time to once again share their thoughts on the following: Which of these proposals should the BoT consider under the Emergency PDP? And what is the criteria you used to come to this conclusion. The AC may recommend that the Board consider 1, some or none of the above proposals for the Emergency PDP but it would greatly help if the community at large weighed in as well. I cannot emphasize enough that STRONG community support would go a long way in helping to convince the Board that immediate action is required and that use of the Emergency PDP is fully supported. Thanks, John +++ On 12/6/10 5:35 PM, "Scott Leibrand" wrote: We've gotten some good feedback from a few folks on this in the "122 + 123 process" thread, so I wanted to summarize where we're at and see if anyone else has any more feedback to the AC in preparation for next week's AC call. On that call we'll likely discuss whether to put this proposal on the AC's docket, if so whether to also designate it as a draft policy for adoption discussion, and most likely also whether to recommend that the Board invoke the Emergency PDP on this issue. Do you feel that Proposal 123 meets an emergency need, and that the Emergency PDP should be activated? A few comments we've received so far are: "122 and 123 should be adopted as draft policies and put through the normal process, at least until the last /8 is actually allocated." ... "When the last minute arrives, I would favor 122 and 123 as emergency policies." (Bill Herrin) "we ought to:" ... "establish via emergency procedures a separate /16 (I would fully support a /10) for CI as described in Proposal 123" because "b) the sizes of these two pools are small enough in the grand scheme of things that it is better to be safe than sorry. c) having two pools rather than one will prevent a run-out of all remaining addresses for just one of the two purposes, something that might occur if there was just one pool", and "we need some space for CI in situations where even our best planning didn't anticipate a certain need." (Frank Bulk) "Emergency? No. That is not to claim that there cannot possibly be some future action or event that could cause an emergency, just that I do not see one now." (Gary Buhrmaster) Additional feedback would be much appreciated. Thanks, Scott On Tue, Nov 23, 2010 at 7:01 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 123: Reserved Pool for Critical Infrastructure > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 23 Nov 2010 > > Proposal type: Modify > > Policy term: 36 Months following implementation > > Policy statement: > > Upon receipt of the last /8 that the IANA will allocate to ARIN per the > Global Policy for the Allocation of the Remaining IPv4 Address Space, > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure. If at the end of the policy term > there is unused address space remaining in this pool, ARIN staff is > authorized to utilize this space in a manner consistent with community > expectations. > > Rationale: > > Section 4.10 of the NRPM is insufficient with respect to insuring the > continued operation of critical infrastructure. This proposal, if > adopted, will protect those resources with a reasonable amount of > reserved v4 address space and prevent an overrun of CI needs by NRPM > Section 4.10 or any successor. The intent is to separate CI needs and > make a distinct pool available to insure the continuity of CI > allocations per NRPM Section 4.4 for at least 36 months. > > This proposal should be considered an emergency proposal. IANA > exhaustion is likely to occur prior to the next ARIN meeting. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ 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 and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From cgrundemann at gmail.com Tue Dec 14 15:51:16 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 14 Dec 2010 13:51:16 -0700 Subject: [arin-ppml] ARIN-prop-124: Clarification of Section 4.2.4.4 - revised In-Reply-To: <1CA77075-C3CD-41FC-BA6F-604B023BE4E3@gmail.com> References: <1CA77075-C3CD-41FC-BA6F-604B023BE4E3@gmail.com> Message-ID: On Mon, Dec 13, 2010 at 11:05, Scott Leibrand wrote: > On Dec 13, 2010, at 9:52 AM, "Hannigan, Martin" wrote: > >> >> On 12/13/10 12:39 PM, "Scott Leibrand" wrote: >> >>> I have no problem with this revised text. >>> >> >> >> Scott, >> >> Is that support or not? > > Not sure yet. I will probably support a recommendation to ARIN staff that they interpret existing policy in a manner consistent with this clarification. I'm not sure if I would support an emergency PDP recommendation, but at the moment I have no reason to oppose it. > > I'm still hoping to hear some additional input from folks that haven't posted yet, which could persuade me one way or the other. Not sure that it will persuade you, but my support for this proposal boils down to a few things: 1) Predictability as we run out has been professed over and over again, for the most part I agree. Having a request cut to 25% mid-process is the opposite of predictable. This proposal fixes that by clearly saying "if you apply before IANA runout the current rules apply, if you apply after IANA runout the new rules apply." Rather than the current "who knows what rules will apply by the time you are approved." 2) It has come to pass that ARIN will actually have a fairly significant amount of IPv4 addresses available at IANA exhaustion. Specifically, ARIN will have the remnants of two /8s received in November, the "final" /8 and additionally will have their share of the "various" registries (about 1.5 /8s). This should be more than enough to facilitate any legitimate requests in queue at the moment of IANA exhaustion and still have more to spread using the 3-month window. 3) Directly related to point #1, above; it seems to me that this proposal, by increasing fairness to those organizations who submit legitimate requests prior to IANA exhaustion, puts ARIN in a better place wrt angering the mob (ie they will be slightly less angry and thus slightly less prone to attack). $0.02 ~Chris > > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.com www.coisoc.org From jbates at brightok.net Tue Dec 14 16:16:08 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 14 Dec 2010 15:16:08 -0600 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: Message-ID: <4D07DE98.3030600@brightok.net> On 12/14/2010 2:34 PM, Sweeting, John wrote: > To All Subscribers of PPML, > > * ARIN-prop-125. Efficient Utilization of IPv4 Requires > Dual-Stack > Oppose 125, Documentation and proof of following the policy is near impossible. It is very specific in how things should be which doesn't match all topology types; especially pool related requirements in eyeball networks. It also misses the fact that many IPv4 requests may often be due to legacy equipment which cannot handle IPv6 yet and may be in transitional periods. There are also uses for v4 where there is no need to dual stack and renumbering mpls infrastructure or cpe management to rfc1918 should not be a requirement. > * ARIN-prop-124. Clarification of Section > 4.2.4.4 oppose 124. While I believe strongly that the policy at the time of the request should be the ruling policy, there is a great fear that there will be a last minute rush just prior to the 10.4.2.2 taking effect. This rush could cause a severe backup in the queue to the degree that the remaining space is fully allocated before the queue is clear. I would support any request which was submitted at a time frame prior to the actual execution of 10.4.2.2 (ie, 1-3 weeks prior or in an escalated state). > * ARIN-prop-123. Reserved Pool for Critical > Infrastructure > support prop 123, though I'd feel better if Critical Infrastructure has a test mechanism that ARIN could use to qualify who will receive space from the reserved pool. > * ARIN-prop-122. Reserved Pool for Future Policy > Development support prop 122. It allows time for ARIN to decide what is appropriate for the space at a later time when a better understanding is available. I do believe it needs a monthly review of possible uses. > > > * ARIN-prop-121. Sensible IPv6 Allocation for > ISPs > Support prop 121. It is much more sensible than what we have. It may need some review in areas, but it is a good start and will fix some serious issues that currently exist in v6 adoption. This is not an emergency proposal. > > * ARIN-prop-120. Protecting Number > Resources support the concept of prop 120, though I believe it needs more wording and guidelines to appropriate fit better. I also don't classify it as emergency. > * ARIN-prop-119. Globally Coordinated Transfer > Policy > > Support concept of prop 119, though I believe it needs more wording, and a better understanding of how transfers between RIR would take place or how such could be managed given our current hierarchical model. This is especially important, given the IANA assignment table. > > Which of these proposals should the BoT consider under the Emergency > PDP? And what is the criteria you used to come to this conclusion. > 122 and 123 for sure. They are not harmful policies, and even if enacted on emergency, they can be released or utilized at a later time if necessary. They are precautionary policies which are only useful if enacted quickly. Though I oppose its current state, 124. I prefer limitations or wording to avoid the "It's about to happen, everyone email in a request tonight to get the 24 months." Other than that, it's only useful if applied as an emergency action. I don't see any other proposals which justify emergency evaluation. Arguably 125, but I do not believe that 125 should be allowed to be implemented on emergency basis. It needs serious evaluation and community input. Jack From owen at delong.com Thu Dec 16 20:56:24 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 16 Dec 2010 17:56:24 -0800 Subject: [arin-ppml] Fwd: Policy Proposal 121: Better IPv6 Allocations for ISPs - revised References: <4CF7BFF3.2030106@arin.net> Message-ID: <7CCED376-BCD5-492D-9B6F-D8090B371146@delong.com> There are two changes in this policy revision: 1. Version incremented to 1.0 2. It has been brought to my attention that some are offended or insulted by the use of the word Sensible in the title. As a result I have removed the offending word and renamed the proposal. There are no changes to the content of the policy as none have been suggested since the last revision. I apologize to anyone who felt offended by my use of the word sensible in the title. It was not my intent to imply that the current system is not sensible or to in any way impugn or insult current policy or people who disagree with this proposal. I used the word to describe that I felt the allocations issued under this policy were not grotesquely large or non-sensical, but, sensible in the context of the need for improved route aggregation and the vastness of available IPv6 number resources. Owen Policy Proposal 121: Better IPv6 Allocations for ISPs Proposal Version: 1.0 Date: 16 December 2010 Policy statement: Amend section 2 as follows: Delete section 2.9 (Obsolete) Replace section 2.10 with the following: 2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location). Add the following: 2.12 The term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof. 2.13 The term provider assignment unit shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48). 2.14 The term utilized shall have the following definitions: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site. (ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) Replace sections 6.5.1 through 6.5.3 with the following: 6.5.1 Terminology (a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. (b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) 6.5.2 Initial Allocations to LIRs 6.5.2.1 Size (a) All allocations shall be made on nibble boundaries. (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. (c) The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses. This calculation can be summarized as /N where N = 48-(X+Y) and X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site. (d) For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy. (e) For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. (f) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled. 6.5.2.2 Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: (a) Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. (b) Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number and will be making reassignments to other organizations. (c) Provide ARIN a reasonable technical justification, indicating why an allocation is necessary, including the intended purposes for the allocation, and describing the network infrastructure the allocation will be used to support. Justification must include a plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. 6.5.3 Subsequent Allocations to LIRs (a) Where possible ARIN will make subsequent allocations by expanding the existing allocation. (b) An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be entitled to a subsequent allocation. (c) If ARIN can not expand one or more existing allocations, ARIN shall make a new allocation based on the initial allocation criteria above. The LIR is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use. Replace section 6.5.4 with the following 6.5.4 Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Add the following to 6.5.7 LIRs which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From info at arin.net Tue Dec 21 12:14:40 2010 From: info at arin.net (ARIN) Date: Tue, 21 Dec 2010 12:14:40 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - December 2010 Message-ID: <4D10E080.8080408@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) held a meeting on 16 December 2010 and made decisions about several draft policies and proposals. After last call the AC recommended that the ARIN Board of Trustees adopt the following draft policy: ARIN-2010-8 Rework of IPv6 assignment criteria The AC moved the following draft policy to last call (it will be posted separately to last call): ARIN-2010-14 Standardize IP Reassignment Registration Requirements The AC accepted the following proposals on to the AC's docket for development and evaluation: ARIN-prop-121 Better IPv6 Allocation for ISPs ARIN-prop-123 Reserved Pool for Critical Infrastructure The AC abandoned the following proposals: ARIN-prop-122 Reserved Pool for Future Policy Development ARIN-prop-124 Clarification of Section 4.2.4.4 ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack "The AC did not feel that emergency action was warranted for proposal 122, and given that the IANA IPv4 pool is expected to exhaust before the April Public Policy Meeting, did not feel that it would be useful to put this proposal on the AC's docket. The AC would encourage anyone with policy proposals for improving NRPM section 4.10 to submit them immediately, so they can be considered in time for the April meeting." "After discussion of proposal 124, the AC did not feel that emergency action was warranted. Normally there are few requests in queue and any moment, as a result the expected overall impact of this issue should be small. Furthermore, it is possible this proposal could increase the motivation to submit incomplete or fraudulent proposals at the last moment, it was felt this should not be encouraged. As the trigger event in NRPM Section 4.2.4.4 is almost assuredly to have occurred before the April Public Policy Meeting, this proposal would be irrelevant by the time it could be presented at that meeting. Therefore, the AC voted to abandon the proposal now." And regarding ARIN-prop-125 the AC stated, "The initial interpretation was that while ARIN's role is to manage and administer Internet number resources, this proposal strays too far from management towards a mandate. This proposal may benefit the deployment of IPv6, but it would do so by forcing companies to deploy IPv6 where it may not be immediately needed and could have unintended consequences on IPv4 transfers." The PDP states, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal.? The abandonment of proposals 122, 124 and 125 may be petitioned to try to change them into draft policies for discussion on the Public Policy Mailing List and at the April Public Policy Meeting (this is the Discussion Petition). The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Policy Proposal texts 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, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Dec 21 12:15:14 2010 From: info at arin.net (ARIN) Date: Tue, 21 Dec 2010 12:15:14 -0500 Subject: [arin-ppml] Draft Policy ARIN-2010-14: Standardize IP Reassignment Registration Requirements - Last Call Message-ID: <4D10E0A2.8050705@arin.net> The ARIN Advisory Council (AC) met on 16 December 2010 and decided to send the following draft policy to last call: ARIN-2010-14: Standardize IP Reassignment Registration Requirements On 11 October 2010 on PPML Chris Grundemann stated "There were two changes made: 1) The text in section 4.2.3.7.3.1. "Residential Market Area" was replaced with a direct copy of the current "Cable Address Space Policy" to avoid any perceived change of intent. The only changes to this text are it's placement in the NRPM and that it now applies to all residential access networks, not just cable networks. 2) The "Residential Market Area" section has been stricken from the IPv6 policy. It is not needed due to the application of the HD ratio to IPv6 allocations." Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2010-14 will expire on 12 January 2011. 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, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2010-14 Standardize IP Reassignment Registration Requirements Version/Date: 11 October 2010 Proposal type: New Policy term: Permanent Policy statement: Definitions - Add: 2.3. Organizational Information When required, organization Information must include at a minimum: Legal name, street address, city, state, zip code equivalent and at least one valid technical and one valid abuse POC. Each POC shall be designated by the organization and must include at least a verifiable email address and phone number. 2.12. Residential Customer End-users who are individual persons and not organizations and who receive service at a place of residence for personal use only are considered residential customers. IPv4 - Rename 4.2.3.7. "Reassignment information" to "Registration" and add text: ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. - Rename 4.2.3.7.1. "Customer organization information" to "Reassignment Information" and replace text with: Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5. - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments visible within 7 days" and replace text with: All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with: 4.2.3.7.3. Residential Subscribers 4.2.3.7.3.1. Residential Market Area In most cases, ISPs that have residential subscribers assign address space to their access infrastructure to which their customers connect rather than to individual subscribers. This assignment information regarding each market area holding an address block should be entered via SWIP (or by using RWhois) with the network name used to identify each market area. Initial allocations are based on total number of homes that could purchase the service in a given market area. Using SWIP or RWhois, residential access ISPs must show that they have reassigned at least 80% of their current address space, with a 50 to 80% utilization rate, in order to request additional addresses. Each assignment to a specific end-user (if holding /29 and larger blocks) requires the submission of a SWIP or use of an RWhois server. Requesters will also be asked to provide detailed plans for use of the newly requested space. 4.2.3.7.3.2. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /29 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS directory record for that block. - Strike section 4.2.6. "Cable Address Space Policy" IPv6 - Replace Section 6.5.5. with: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. Resource Review - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert the following: c. whenever ARIN has reason to believe that an organization is not complying with reassignment policies, or Rationale: #Short Rationale: This proposal intends to do several things: 1) Bring IPv4 and IPv6 policy more in line with each other to make the NRPM easier to understand and comply with - at least as it relates to reassignment information. 2) Specifically define what organizational information is required to be added to WHOIS when reassignments are made to client organizations. 3) To specifically state that a client organization may designate the POC of their choice for any/all WHOIS entries in policy. This includes designating an upstream POC as their own preferred POC (which allows for simple reassignments). 4) Expands the privileges previously reserved solely for IPv4 cable ISPs to all ISPs/LIRs with residential/dhcp-type subscribers. 5) Specifically define the term "residential customer." 6) Allow ARIN to conduct resource reviews based on failure to comply with registration / reassignment policies. #Expanded Rationale: 1) This policy restructures the reassignment and registration sections of the IPv4 and IPv6 policies. a) The IPv4 section is renamed "registration." b) The IPv4 policy is shortened and rewritten for clarity. c) The IPv6 policy is totally rewritten in a format that matches the IPv4 policy. * These structural changes are meant to make it easier to compare the two sections. I believe that having the IPv6 and IPv4 policies written in completely different formats and structures (as they are in many cases now) confuses the issues and makes it very hard to understand what is different and what is the same across the two sections. Bringing them into a similar format should help ease the migration to IPv6 as folks can quickly and easily understand the differences and the similarities. d) The IPv6 policy is altered from a /56 minimum needing to be registered to a /64. A /64 is a single IPv6 subnet where as a /56 contains many subnets (that should all be recorded in the WHOIS directory if handed out to other organizations). 2) This policy adds a definition of "organizational information" which is used in the existing policy but not currently defined anywhere in the NRPM. a) The definition states that legal name and physical address are required for client organizations. b) The definition states that POCs are required but can be designated by the client organization - it spells out that the client org can choose to use their upstream as a POC. c) The definition requires that each POC have a valid email address and phone number. 3) This policy takes the privileges granted specifically to IPv4 cable operators in section 4.2.6. "Cable Address Space Policy" and grants them to all ISPs who serve residential areas. a) It allows all ISPs with residential coverage to register/swip/rwhois an entire market area. b) It retains the existing residential customer privacy policy for all customers with larger IP blocks. * This change removes the need for any ISP to enter residential customers into whois at all. 4) This policy also extends the >50% utilization rate, currently granted only to IPv4 cable operators, to all ISPs with a residential footprint. * This change offsets the ability to register/swip/rwhois market areas. For all other allocation types, efficient utilization is based on SWIPs, not on actual utilization. When an organization is able to SWIP an entire market area, this must be checked against actual utilization. This policy maintains the current line set at >50%. **The 50% mark on the most recent allocation is because you can quickly distribute most of your address space across your provisioning footprint, leaving nothing left for growth while the lease count of the provisioned customers catches up to the blocks allocated. (Dan Alexander's words) 5) Current policy references "residential customers" but there is no current definition of residential customers in the NRPM. This has reportedly been an on-going problem for ARIN and it?s customers. 6) Not properly registering reassignment information could be a sign of other improper or illicit behavior and should justify a resource review (audit) by ARIN when necessary, regardless of when the last review took place. Timetable for implementation: Immediate From ebw at abenaki.wabanaki.net Tue Dec 21 19:55:36 2010 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Tue, 21 Dec 2010 19:55:36 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? Message-ID: <4D114C88.8090906@abenaki.wabanaki.net> Colleagues, I'd like this proposal to be approved. I've discussed it with Marty at the Cartegena ICANN meeting two weeks ago. My concern is that new registry proposants who meet the criteria for assistance under the current JAS WG Milestone [1], or future work product of the JAS WG, are, under the current ICANN Draft Applicant Guidebook, required to be v6 capable. This is a cost that can be deferred, if 123 becomes ARIN policy, at least for the ARIN region, and if imitated by the other RIR's, more broadly. The v6 capability is independent of the regional addressing infrastructure availability local to the registry infrastructure, registrars, or registrants. The case for exempting applicants meeting the Milestone et seq. criteria for assistance, or any larger class of new, or new and existing, registry operators, from a near-term v6 capability requirement could be supported by the existence of a critical infrastructure address pool, allowing transition over a multi-quarter period, with address recovery for subsequent transitional allocation. Professor Meuller, with whom I find little ever in common agreement, including the polarity of gravity, observes, for whatever reason, "In a world of 5,000 TLDs, do all g and cc TLDs have the same status?" It is profoundly unlikely that each of the registry operators will be facilities-based operations, and not implemented as a tenant registry of a registry services provider, and assuming the 1k/yr gate asserted by the Root Scaling Study authors, on a three year transition, after 5 years the number of independent, outstanding transitional allocations would be significantly less than 5k. Eric Brunner-Williams member, JAS WG [1] http://icann.org/en/public-comment/#jas-milestone-report From scottleibrand at gmail.com Tue Dec 21 20:20:41 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Dec 2010 17:20:41 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D114C88.8090906@abenaki.wabanaki.net> References: <4D114C88.8090906@abenaki.wabanaki.net> Message-ID: Eric, Do I understand correctly that you believe proposal 123 should allow TLD operators to delay IPv6 deployment? I'm not following why that would be the case, or if it were, why it would be beneficial for the community... As I understand it, the main driver for requiring new TLD operators to be v6 capable is to ensure that new Internet users, who will have IPv6 as their primary connectivity, will be able to access the TLD nameservers over IPv6. I believe it beneficial to the community to have such a requirement, and that meeting it should not be expensive for new TLDs. However, it is likely that TLD operators, and other providers of Critical Infrastructure, will continue to need to provide IPv4 service alongside IPv6 (dual stack) for a considerable time, and therefore new TLD operators will continue to require new IPv4 microallocations during that transition period. That, I believe, is where 123 may be able to help. Thanks, Scott On Tue, Dec 21, 2010 at 4:55 PM, Eric Brunner-Williams wrote: > Colleagues, > > I'd like this proposal to be approved. I've discussed it with Marty at the > Cartegena ICANN meeting two weeks ago. > > My concern is that new registry proposants who meet the criteria for > assistance under the current JAS WG Milestone [1], or future work product of > the JAS WG, are, under the current ICANN Draft Applicant Guidebook, required > to be v6 capable. This is a cost that can be deferred, if 123 becomes ARIN > policy, at least for the ARIN region, and if imitated by the other RIR's, > more broadly. > > The v6 capability is independent of the regional addressing infrastructure > availability local to the registry infrastructure, registrars, or > registrants. > > The case for exempting applicants meeting the Milestone et seq. criteria for > assistance, or any larger class of new, or new and existing, registry > operators, from a near-term v6 capability requirement could be supported by > the existence of a critical infrastructure address pool, allowing transition > over a multi-quarter period, with address recovery for subsequent > transitional allocation. > > Professor Meuller, with whom I find little ever in common agreement, > including the polarity of gravity, observes, for whatever reason, "In a > world of 5,000 TLDs, do all g and cc TLDs have the same status?" > > It is profoundly unlikely that each of the registry operators will be > facilities-based operations, and not implemented as a tenant registry of a > registry services provider, and assuming the 1k/yr gate asserted by the Root > Scaling Study authors, on a three year transition, after 5 years the number > of independent, outstanding transitional allocations would be significantly > less than 5k. > > Eric Brunner-Williams > member, JAS WG > > [1] http://icann.org/en/public-comment/#jas-milestone-report > _______________________________________________ > 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 Tue Dec 21 20:17:23 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Dec 2010 17:17:23 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D114C88.8090906@abenaki.wabanaki.net> References: <4D114C88.8090906@abenaki.wabanaki.net> Message-ID: <46A45A51-8406-4680-9D26-261D3E80C90E@delong.com> On Dec 21, 2010, at 4:55 PM, Eric Brunner-Williams wrote: > Colleagues, > > I'd like this proposal to be approved. I've discussed it with Marty at the Cartegena ICANN meeting two weeks ago. > > My concern is that new registry proposants who meet the criteria for assistance under the current JAS WG Milestone [1], or future work product of the JAS WG, are, under the current ICANN Draft Applicant Guidebook, required to be v6 capable. This is a cost that can be deferred, if 123 becomes ARIN policy, at least for the ARIN region, and if imitated by the other RIR's, more broadly. > I don't see any relationship between this policy and deferring IPv6 capability. > The v6 capability is independent of the regional addressing infrastructure availability local to the registry infrastructure, registrars, or registrants. > Makes sense. As it should be. > The case for exempting applicants meeting the Milestone et seq. criteria for assistance, or any larger class of new, or new and existing, registry operators, from a near-term v6 capability requirement could be supported by the existence of a critical infrastructure address pool, allowing transition over a multi-quarter period, with address recovery for subsequent transitional allocation. > I think that would be a very good reason NOT to approve such a policy. Owen From ebw at abenaki.wabanaki.net Tue Dec 21 23:27:49 2010 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Tue, 21 Dec 2010 23:27:49 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: <4D114C88.8090906@abenaki.wabanaki.net> Message-ID: <4D117E45.2010605@abenaki.wabanaki.net> Scott, You ask "[do I] believe proposal 123 should allow TLD operators to delay IPv6 deployment?" If 123 is adopted, and if a similar policy is adopted in RIRs that provide allocations to "developing economies", then the existence of the policy provides a basis to argue that v6 capacity may be deferred from no later than the transition to delegation period to some point in time subsequent. Whether the deferral is for one year or three is not as important as making the policy choice that applicants will fail if, at transition to delegation, they do not have v6 capacity. To grasp the full import, assume 1k applications, with between 60% and 80% survival to "transition to delegation", in the 2011 cohort reaching this state in 2012 and compelled to complete the transition in a fixed period. To make it worse, bear in mind that all of the 1k applicants need to have committed, when submitting their applications, in late 2010 or early 2011, their v6 capabilities. If half do not use existing legacy platforms, VGRS etc., than on the order of a third of all applicant-operators are at risk of administrative failure, or of operational failure, for lack or, or lack of experience with a single point of failure, v6 capacity. The naive v6 requirement, like several others, but this one is the only one which raises an ASO, hence an NRO, hence an ARIN policy issue, is likely to have the effect of channeling applicants to the existing legacy legacy platforms. It "raises the bar" for competition to the existing legacy legacy platforms, or the need for competencies for which existing registry operators have no contractual obligation to meet. As your question goes to my beliefs, I believe that existing data centers are not going to cease servicing requests for data from v4 addresses. I also believe that existing data centers are not going to be as immediately, or as critically, affected by v4 exhaustion as are access network operators. I suggest that the overwhelming majority of addresses used by domain registrants will be, during the same period that new registries are experiencing their first operational year(s) in the 2011 round of new gTLDs, v4 addresses. As to your beliefs, with respect, if "the main driver for requiring new TLD operators to be v6 capable is to ensure that new Internet users, who will have IPv6 as their primary connectivity, will be able to access the TLD nameservers over IPv6", then we, as two policy development communities, are indifferent to the interests of new Internet users in existing resources made available through a name to address mapping mechanism, and we are indifferent to the interests of existing Internet users in the organization of existing resources through a name to address mapping mechanism. Existing resources currently used in rural North America can be named in a new rural North American namespace without necessarily being renumbered and existing resources currently used in Africa can also be named in a new african namespace, also without necessarily being renumbered. Thank you for your thoughtful question, and also John Sweeting, who suggested that all subscribers to PPML provide their thoughts on the proposals and the the criteria each used to come to their conclusions. Eric From owen at delong.com Wed Dec 22 00:15:01 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Dec 2010 21:15:01 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D117E45.2010605@abenaki.wabanaki.net> References: <4D114C88.8090906@abenaki.wabanaki.net> <4D117E45.2010605@abenaki.wabanaki.net> Message-ID: <5A6BF451-63F1-478E-B060-DA4CC4B2DB4E@delong.com> On Dec 21, 2010, at 8:27 PM, Eric Brunner-Williams wrote: > Scott, > > You ask "[do I] believe proposal 123 should allow TLD operators to delay IPv6 deployment?" > > If 123 is adopted, and if a similar policy is adopted in RIRs that provide allocations to "developing economies", then the existence of the policy provides a basis to argue that v6 capacity may be deferred from no later than the transition to delegation period to some point in time subsequent. Whether the deferral is for one year or three is not as important as making the policy choice that applicants will fail if, at transition to delegation, they do not have v6 capacity. > > To grasp the full import, assume 1k applications, with between 60% and 80% survival to "transition to delegation", in the 2011 cohort reaching this state in 2012 and compelled to complete the transition in a fixed period. To make it worse, bear in mind that all of the 1k applicants need to have committed, when submitting their applications, in late 2010 or early 2011, their v6 capabilities. > You say that like it would be a bad thing. > If half do not use existing legacy platforms, VGRS etc., than on the order of a third of all applicant-operators are at risk of administrative failure, or of operational failure, for lack or, or lack of experience with a single point of failure, v6 capacity. > It is absurd to think that people who don't have IPv6 capabilities today should be allowed to run TLDs. > The naive v6 requirement, like several others, but this one is the only one which raises an ASO, hence an NRO, hence an ARIN policy issue, is likely to have the effect of channeling applicants to the existing legacy legacy platforms. It "raises the bar" for competition to the existing legacy legacy platforms, or the need for competencies for which existing registry operators have no contractual obligation to meet. > I disagree. Most NS platforms and many non-legacy registry/registrar service bureaus are IPv6 capable now. I think it is far more likely that this requirement will drive the others to develop their IPv6 capabilities or perish. Again, I'm not seeing a problem here. > As your question goes to my beliefs, I believe that existing data centers are not going to cease servicing requests for data from v4 addresses. I also believe that existing data centers are not going to be as immediately, or as critically, affected by v4 exhaustion as are access network operators. > True. > I suggest that the overwhelming majority of addresses used by domain registrants will be, during the same period that new registries are experiencing their first operational year(s) in the 2011 round of new gTLDs, v4 addresses. > I think that's a poor way of stating the situation. I suggest that the majority of addresses used by registrants will be IPv4, but, that the majority of new registrants public facing services in the 2011 round of gTLDs will also have IPv6 capabilities either immediately in 2011, or, not later than 2013. > As to your beliefs, with respect, if "the main driver for requiring new TLD operators to be v6 capable is to ensure that new Internet users, who will have IPv6 as their primary connectivity, will be able to access the TLD nameservers over IPv6", then we, as two policy development communities, are indifferent to the interests of new Internet users in existing resources made available through a name to address mapping mechanism, and we are indifferent to the interests of existing Internet users in the organization of existing resources through a name to address mapping mechanism. > That statement doesn't parse for me. It's almost as if you are claiming that requiring IPv6 somehow prohibits IPv4. Nothing could be further from the truth. Requiring IPv6 requires TLD operators to support IPv6. It makes no statement one way or the other about their support or lack of support for IPv4. I think it is unlikely any business would succeed without IPv4 in this area for several years. As such, I don't think requiring IPv4 is particularly necessary. I do think that failing to require IPv6 would show indifference. Not the other way around. > Existing resources currently used in rural North America can be named in a new rural North American namespace without necessarily being renumbered and existing resources currently used in Africa can also be named in a new african namespace, also without necessarily being renumbered. > Sure. However, new registrants will just as likely want to provide services to both IPv4 and IPv6 either immediately or in the very near future. It is unfortunate that we cannot require the existing TLD operators and registrars to support IPv6 so easily, but, exempting new TLDs from this requirement seems absurd to me at this time. Owen From mysidia at gmail.com Wed Dec 22 00:35:14 2010 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 21 Dec 2010 23:35:14 -0600 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D117E45.2010605@abenaki.wabanaki.net> References: <4D114C88.8090906@abenaki.wabanaki.net> <4D117E45.2010605@abenaki.wabanaki.net> Message-ID: On Tue, Dec 21, 2010 at 10:27 PM, Eric Brunner-Williams wrote: > To grasp the full import, assume 1k applications, with between 60% and 80% > survival to "transition to delegation", in the 2011 cohort reaching this > state in 2012 and compelled to complete the transition in a fixed period. To > make it worse, bear in mind that all of the 1k applicants need to have Viewing the purpose for reserving space for critical infrastructure, as to provide for continuity and additional allocations required to continue smooth operation of the legacy IPv4 services, and to assist with transition to IPv6. Deploying brand new IPv4 services such as new gTLDs that are not for IPv6 transition does not seem like 'critical infrastructure'. I would suggest the definition of critical infrastructure be annotated in some way and specifically defined in policy to restrict non-root DNS TLD usage to "ccTLDs, legacy gTLDs, and infrastructure for IPv6 transition or continuing to provide a service that existed prior to IP exhaustion"; "new TLDs" can be considered critical IPv6 infrastructure. If anything: I see the idea the policy will "defer deployment" as a reason to oppose or seek changes to the proposal, if it is true. First of all, the concept of having 1k more gTLDs is really bad, for a variety of reasons that have little to do with IP addressing, and it is not up to the addressing authority to try to give competitive or cost advantages to new gTLDs at the expense of the community. Critical infrastructure are the services that will be absolutely required for IPv6 users; it is not great stewardship to seek to promote deployment of new critical infrastructure services with no IPv6 plan, when we know IPv4 address availability will be a big problem soon. And it is most beneficial for critical infrastructure operators to be pressured to deploy for IPv6 as strongly as possible, otherwise IPv6-only users will not have good access to the critical infrastructure. Perhaps the policy proposal could be revised to require all critical infrastructure applicants justifying and applying for reserved space, be required to show plans for parallel IPv6 deployment of new infrastructure? -- -JH From marty at akamai.com Wed Dec 22 14:04:39 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 22 Dec 2010 14:04:39 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D117E45.2010605@abenaki.wabanaki.net> Message-ID: On 12/21/10 11:27 PM, "Eric Brunner-Williams" wrote: > Scott, > > You ask "[do I] believe proposal 123 should allow TLD operators to > delay IPv6 deployment?" > > If 123 is adopted, and if a similar policy is adopted in RIRs that > provide allocations to "developing economies", then the existence of > the policy provides a basis to argue that v6 capacity may be deferred > from no later than the transition to delegation period to some point > in time subsequent. Whether the deferral is for one year or three is > not as important as making the policy choice that applicants will fail > if, at transition to delegation, they do not have v6 capacity. > > To grasp the full import, assume 1k applications, with between 60% and > 80% survival to "transition to delegation", in the 2011 cohort > reaching this state in 2012 and compelled to complete the transition > in a fixed period. To make it worse, bear in mind that all of the 1k > applicants need to have committed, when submitting their applications, > in late 2010 or early 2011, their v6 capabilities. > > If half do not use existing legacy platforms, VGRS etc., than on the > order of a third of all applicant-operators are at risk of > administrative failure, or of operational failure, for lack or, or > lack of experience with a single point of failure, v6 capacity. > I'm not sure that the discussion regarding v6 use for future applications is relevant to what I perceive as your need and this proposal. There is ample IPv6 and if we needed to create something specific for these types of needs it is probably easily done. Am I missing the point? Effectively, this proposal seeks to guarantee access to IPv4 resources for a reasonably short period of time. It will enable critical infrastructure "CI" to be able to receive a small amount of IPv4 addresses so that they can provide a full and robust service to the Internet. The reason why we shouldn't (as Scott Liebrand has and continues to advocate) simply push these needs to "markets" is because these entities have little choice but to serve two internets for some time and it is unreasonable to challenge new entities building CI with the massively increased cost in order to be able to do so. The benefits of new CI, such as TLD's, outweigh the benefit of not carving out a small chunk of address space. Without transition addresses for the entities that you describe new TLD's are likely to be a failure even if they are able to navigate the processes required in order to be granted a TLD by ICANN. If you can't reach it, what good is it? They'll need v4/v6 for some time to come in order to fully address and participate in transition. Hope that helps and, best, -M< From bicknell at ufp.org Wed Dec 22 14:31:05 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 22 Dec 2010 11:31:05 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D114C88.8090906@abenaki.wabanaki.net> References: <4D114C88.8090906@abenaki.wabanaki.net> Message-ID: <20101222193105.GA45138@ussenterprise.ufp.org> It look me a while to parse all of this, because much of the original mail looked like greek to me. I'm afraid that may be the case for many others on the list. Let me try and connect some dots at a really high level. ICANN continues to look at new gTLD's in a process way to detailed to get into in this forum. Point is, think .bank, .Coke, or .XXX, or any other new non-country code TLD. A subgroup, the "JAS Working Group" is looking at part of the problem, it's charter is at http://gnso.icann.org/drafts/draft-jas-wg-charter-12may10-en.htm. If I am parsing it correctly the idea is to identify people who ICANN thinks should have a gTLD, but who may not be able to "make a gTLD happen" all on their own. This is a wide ranging task, inlcuding things like folks who should have a gTLD but can't afford the fees (and thus, fee wavers) to folks who don't really have the technical expertise to run a gTLD, and may need help from ICANN to make it happen in a technically correct way. The most recent milestone report outlining all of this is here: http://icann.org/en/topics/new-gtlds/jas-milestone-report-11nov10-en.pdf I think page 15 is where things get relevant to this list, everything I've written above and before that in the report is simply background for this partciular issue. The working group said there is full concensus that "The following kinds of technical support are identified for those applicants that meet the criteria established for support: ... Infrastructure for providing support for IPv6 compatible solutions, e.g. hardware and networks as needed;" Now, back to the original comment... In a message written on Tue, Dec 21, 2010 at 07:55:36PM -0500, Eric Brunner-Williams wrote: > My concern is that new registry proposants who meet the criteria for > assistance under the current JAS WG Milestone [1], or future work > product of the JAS WG, are, under the current ICANN Draft Applicant > Guidebook, required to be v6 capable. This is a cost that can be > deferred, if 123 becomes ARIN policy, at least for the ARIN region, > and if imitated by the other RIR's, more broadly. This is where I get lost. Policy proposal 123, as written, would allow folks deploying gTLD's to get IPv4 number resources from a reserved pool. It in fact says nothing about IPv6 resources, they are available today and will continue to be available in the future on the exact same terms. If the ICANN and/or the JAS WG has a requirement for IPv6 services than Proposal 123 is totally unrelated as it deals with IPv4 resources. If the concern is that some new gTLD's will try and use the resources available under Proposal 123 to deploy IPv4 _only_ support for gTLD's that is an administrative matter for ICANN and the JAS WG. Indeed, even without this pool gTLD's could obtain IPv4 resources from their upstream, via hosting companies, or even via the transfer market. This Proposal 123 may make it a bit easier for them, but in no way is IPv4 impossible without it. More to the point. If a new gTLD operator comes online during the transition I think it is in the best interest of the gTLD operator, ICANN, ARIN, and the Internet at large that they have an IPv4 presense. One cannot consider deploying an IPv6 only gTLD until a substantial number of users have IPv6 services otherwise it would be crippled. Which leaves me utterly confused by the original comments. I can't see how this hurts ICANN, the gTLD process, or the JAS WG in any way, in fact it appears to me this proposal should make it easier and operationally better to roll out new gTLD's. -- 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 ebw at abenaki.wabanaki.net Wed Dec 22 15:03:12 2010 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Wed, 22 Dec 2010 15:03:12 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <20101222193105.GA45138@ussenterprise.ufp.org> References: <4D114C88.8090906@abenaki.wabanaki.net> <20101222193105.GA45138@ussenterprise.ufp.org> Message-ID: <4D125980.8030005@abenaki.wabanaki.net> On 12/22/10 2:31 PM, Leo Bicknell wrote: > > It look me a while to parse all of this, because much of the original > mail looked like greek to me. I'm afraid that may be the case for > many others on the list. Let me try and connect some dots at a > really high level. > > ICANN continues to look at new gTLD's in a process way to detailed > to get into in this forum. Point is, think .bank, .Coke, or .XXX, > or any other new non-country code TLD. > > A subgroup, the "JAS Working Group" is looking at part of the problem, > it's charter is at > http://gnso.icann.org/drafts/draft-jas-wg-charter-12may10-en.htm. > > If I am parsing it correctly the idea is to identify people who > ICANN thinks should have a gTLD, but who may not be able to "make > a gTLD happen" all on their own. This is a wide ranging task, > inlcuding things like folks who should have a gTLD but can't afford > the fees (and thus, fee wavers) to folks who don't really have the > technical expertise to run a gTLD, and may need help from ICANN to > make it happen in a technically correct way. I'd nuance that last bit. The skill set for DNSSEC are still fairly closely held, and some people haven't seen more of v6 than ::1 in their part of the globe. For reasons that I personally don't endorse, the SLA levels for start-ups in 2010 would preclude most of the 2005 and all but two of the 2001 start-ups in the gTLD registry business. > The most recent milestone report outlining all of this is here: > http://icann.org/en/topics/new-gtlds/jas-milestone-report-11nov10-en.pdf > > I think page 15 is where things get relevant to this list, everything > I've written above and before that in the report is simply background > for this partciular issue. The working group said there is full > concensus that > > "The following kinds of technical support are identified for those > applicants that meet the criteria established for support: > > ... > > Infrastructure for providing support for IPv6 compatible solutions, > e.g. hardware and networks as needed;" > > Now, back to the original comment... Thanks for reading the report Leo! > In a message written on Tue, Dec 21, 2010 at 07:55:36PM -0500, Eric Brunner-Williams wrote: >> My concern is that new registry proposants who meet the criteria for >> assistance under the current JAS WG Milestone [1], or future work >> product of the JAS WG, are, under the current ICANN Draft Applicant >> Guidebook, required to be v6 capable. This is a cost that can be >> deferred, if 123 becomes ARIN policy, at least for the ARIN region, >> and if imitated by the other RIR's, more broadly. > > This is where I get lost. Policy proposal 123, as written, would > allow folks deploying gTLD's to get IPv4 number resources from a > reserved pool. It in fact says nothing about IPv6 resources, they > are available today and will continue to be available in the future > on the exact same terms. I would like to ensure that new registry applicants have access to v4 resources, and that they are not forced to "transition" to v6, or simply start v6-only, for v4 scarcity and cost reasons. If 123 exists, then it is reasonable to point to this as a means to reduce the impulse to require new registry operators to have v6 skills and plumbing in place ab initio. > If the ICANN and/or the JAS WG has a requirement for IPv6 services than > Proposal 123 is totally unrelated as it deals with IPv4 resources. See above. > If the concern is that some new gTLD's will try and use the resources > available under Proposal 123 to deploy IPv4 _only_ support for > gTLD's that is an administrative matter for ICANN and the JAS WG. > Indeed, even without this pool gTLD's could obtain IPv4 resources > from their upstream, via hosting companies, or even via the transfer > market. This Proposal 123 may make it a bit easier for them, but > in no way is IPv4 impossible without it. 123 may make it a bit easier for them, and it offers terms at least as good as the transfer market or being forced to be tenants of their competitors. > More to the point. If a new gTLD operator comes online during the > transition I think it is in the best interest of the gTLD operator, > ICANN, ARIN, and the Internet at large that they have an IPv4 presense. > One cannot consider deploying an IPv6 only gTLD until a substantial > number of users have IPv6 services otherwise it would be crippled. > > Which leaves me utterly confused by the original comments. I can't > see how this hurts ICANN, the gTLD process, or the JAS WG in any > way, in fact it appears to me this proposal should make it easier > and operationally better to roll out new gTLD's. Agree. Hence my expression, however greek, of support for it. Eric From ebw at abenaki.wabanaki.net Wed Dec 22 15:05:23 2010 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Wed, 22 Dec 2010 15:05:23 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: Message-ID: <4D125A03.5040408@abenaki.wabanaki.net> Marty, By "capacity" I refer to the applicant's capitalization and skills, its capacity to meet the current contractual obligation, still not determined, but somewhere between close-of-application window and transition-to-delegation. Fairly banal stuff. The JAS WG is, in principle, attempting to lower the barriers to entry for applicants outside of the early adopter and highly capitalized incumbents and "participants that engage in ICANN's processes to a greater extent than Internet users generally". The question is pretty simple -- have costs been imposed in the 2010 round that were not present in the 2005 or 2001 rounds, and how can they be managed to least adversely affect applications that meet the geographic, economic, and related diversity goals for new registry operators? Either v6 adoption is, or isn't, a manageable cost, and 123 offers a temporal tool, re-usable v4 blocks, that may move the cost of v6 adoption off of the applicant-operator's debit finance and onto its revenue finance books. I'm going to stop here. Eric From cgrundemann at gmail.com Wed Dec 22 15:10:58 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 22 Dec 2010 13:10:58 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Message-ID: The AC should not have abandoned ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack. I petition to move the following text forward for discussion on the list and at the next Public Policy Meeting. Please support moving this proposal forward now by posting statements in support of the petition to this list. ### Policy Statement: * Add the following sections to section 4.1: 4.1.2. Efficient Utilization IPv4 addresses are a finite resource and as such are required to be efficiently utilized by resource holders in order to maximize their benefit to the community. 4.1.3. Dual-Stack Dual-stack refers to configuring both an IPv4 and an IPv6 address or network together on the same network infrastructure. All new IPv4 addresses assigned, allocated or transfered to an organization must be deployed on dual-stacked interfaces along with IPv6 addresses. 4.1.4. IPv6 Deployment When addresses are used to provide an Internet facing service, the service must be fully IPv6 accessible (if you deploy an A record, you must also have a AAAA record, and both must answer). * Add the following sentance to the end of sections 4.2.1.6, 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: In accordance with section 4.1.3 and 4.1.4, all new addresses must be deployed on dual-stacked interfaces and all Internet facing services provided by new addresses must be fully IPv6 accessible. * Re-write section 4.2.3.4.1. to: Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria, the dual-stack criteria and must be available via SWIP / RWhois prior to your issuing them additional space. * Add the following section to section 4.2.4: 4.2.4.5. IPv6 Deployment In order to receive additional space ISPs must provide detailed documentation demonstrating that: - for every IPv4 address requested, at least one pre-existing interface is dual stacked, up to 80% of all interfaces and - for every down stream customer site where the new addresses will be deployed, at least one pre-existing down stream customer site is IPv6 enabled, up to 80% of the total customer base. * Add the following to section 4.3.6: 4.3.6.3. IPv6 Deployment In order to receive additional space end-users must provide detailed documentation demonstrating that at least 80% of their existing IPv4 addresses are deployed on dual-stacked interfaces in accordance with section 4.1.3. Rational: In this period of available IPv4 address scarcity and transition to IPv6, IPv4 addresses that are not deployed along with IPv6 are simply not being efficiently utilized. Although we have likely failed to deploy dual-stack in a meaningful way in time to avoid transition problems, we can still choose the correct path for future assignments, allocations and transfers. This proposal has three objectives: -1- Encourage IPv6 deployment prior to and post depletion -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change was to this line]# -3- Improve the utilization of IP addresses It accomplishes these goals by enforcing three basic ideals: -1- ARIN will only make allocations and assignments for networks that have already deployed production IPv6 -2- Any new IPv4 addresses received, must be deployed along side of IPv6 (dual-stacked) -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks The specific requirements to be enforced can be summed up in this way: ~ New addresses must be deployed on dual-stacked interfaces plus one additional pre-existing IPv4-only interface must be dual-stacked per new address, up to 80% of all interfaces. ~ For each down stream customer site where these addresses are deployed, another pre-existing IPv4 only down stream site must also be IPv6 enabled, up to 80% of the total customer base. ~ All end-sites must dual-stack before getting new space. ~ Internet facing services that new IPv4 addresses are used to provide must be fully IPv6 accessible. ### Chris Grundemann www.theIPv6experts.net chris at theIPv6experts.net From info at arin.net Wed Dec 22 15:29:34 2010 From: info at arin.net (ARIN) Date: Wed, 22 Dec 2010 15:29:34 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Message-ID: <4D125FAE.3050307@arin.net> The message below started a petition regarding the ARIN Advisory Council's decision to abandon "ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack". The AC's decision was posted by ARIN staff to PPML on 21 December 2010. If successful, this petition will change ARIN-prop-125 into a Draft Policy which will be published for adoption discussion on the PPML and at the Public Policy Meeting in April. If the petition fails, the proposal will be closed. For this petition to be successful, the petition needs statements of support from at least 10 different people from 10 different organizations. If you wish to support this petition, post a statement of support to PPML on this thread. The duration of the petition is until five business days after the AC's draft meeting minutes are published. ARIN staff will post the result of the petition to PPML. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The proposal text is below and 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, Communications and Member Services American Registry for Internet Numbers (ARIN) ##### > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Wednesday, December 22, 2010 3:11 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient > Utilization of IPv4 Requires Dual-Stack > > The AC should not have abandoned ARIN-prop-125 Efficient Utilization > of IPv4 Requires Dual-Stack. I petition to move the following text > forward for discussion on the list and at the next Public Policy > Meeting. Please support moving this proposal forward now by posting > statements in support of the petition to this list. > > ### > > Policy Statement: > > * Add the following sections to section 4.1: > > 4.1.2. Efficient Utilization > > IPv4 addresses are a finite resource and as such are required to be > efficiently utilized by resource holders in order to maximize their > benefit to the community. > > 4.1.3. Dual-Stack > > Dual-stack refers to configuring both an IPv4 and an IPv6 address or > network together on the same network infrastructure. > > All new IPv4 addresses assigned, allocated or transfered to an > organization must be deployed on dual-stacked interfaces along with > IPv6 addresses. > > 4.1.4. IPv6 Deployment > > When addresses are used to provide an Internet facing service, the > service must be fully IPv6 accessible (if you deploy an A record, you > must also have a AAAA record, and both must answer). > > * Add the following sentance to the end of sections 4.2.1.6, > 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: > > In accordance with section 4.1.3 and 4.1.4, all new addresses must be > deployed on dual-stacked interfaces and all Internet facing services > provided by new addresses must be fully IPv6 accessible. > > * Re-write section 4.2.3.4.1. to: > > Reassignment information for prior allocations must show that each > customer meets the 80% utilization criteria, the dual-stack criteria > and must be available via SWIP / RWhois prior to your issuing them > additional space. > > * Add the following section to section 4.2.4: > > 4.2.4.5. IPv6 Deployment > > In order to receive additional space ISPs must provide detailed > documentation demonstrating that: > - for every IPv4 address requested, at least one pre-existing > interface is dual stacked, up to 80% of all interfaces and > - for every down stream customer site where the new addresses will be > deployed, at least one pre-existing down stream customer site is IPv6 > enabled, up to 80% of the total customer base. > > * Add the following to section 4.3.6: > > 4.3.6.3. IPv6 Deployment > > In order to receive additional space end-users must provide detailed > documentation demonstrating that at least 80% of their existing IPv4 > addresses are deployed on dual-stacked interfaces in accordance with > section 4.1.3. > > Rational: > > In this period of available IPv4 address scarcity and transition to > IPv6, IPv4 addresses that are not deployed along with IPv6 are simply > not being efficiently utilized. Although we have likely failed to > deploy dual-stack in a meaningful way in time to avoid transition > problems, we can still choose the correct path for future assignments, > allocations and transfers. > > This proposal has three objectives: > -1- Encourage IPv6 deployment prior to and post depletion > -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change > was to this line]# > -3- Improve the utilization of IP addresses > > It accomplishes these goals by enforcing three basic ideals: > -1- ARIN will only make allocations and assignments for networks that > have already deployed production IPv6 > -2- Any new IPv4 addresses received, must be deployed along side of > IPv6 (dual-stacked) > -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks > > The specific requirements to be enforced can be summed up in this way: > ~ New addresses must be deployed on dual-stacked interfaces plus one > additional pre-existing IPv4-only interface must be dual-stacked per > new address, up to 80% of all interfaces. > ~ For each down stream customer site where these addresses are > deployed, another pre-existing IPv4 only down stream site must also be > IPv6 enabled, up to 80% of the total customer base. > ~ All end-sites must dual-stack before getting new space. > ~ Internet facing services that new IPv4 addresses are used to provide > must be fully IPv6 accessible. > > ### > > Chris Grundemann > www.theIPv6experts.net > chris at theIPv6experts.net > _______________________________________________ > 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 scottleibrand at gmail.com Wed Dec 22 15:43:03 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 22 Dec 2010 12:43:03 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D125980.8030005@abenaki.wabanaki.net> References: <4D114C88.8090906@abenaki.wabanaki.net> <20101222193105.GA45138@ussenterprise.ufp.org> <4D125980.8030005@abenaki.wabanaki.net> Message-ID: Thanks to both Leo and Eric for the clarifications here, most of which I've elided for brevity. On Wed, Dec 22, 2010 at 12:03 PM, Eric Brunner-Williams wrote: > On 12/22/10 2:31 PM, Leo Bicknell wrote: >> In a message written on Tue, Dec 21, 2010 at 07:55:36PM -0500, Eric >> Brunner-Williams wrote: >>> >>> My concern is that new registry proposants who meet the criteria for >>> assistance under the current JAS WG Milestone [1], or future work >>> product of the JAS WG, are, under the current ICANN Draft Applicant >>> Guidebook, required to be v6 capable. This is a cost that can be >>> deferred, if 123 becomes ARIN policy, at least for the ARIN region, >>> and if imitated by the other RIR's, more broadly. >> >> This is where I get lost. ?Policy proposal 123, as written, would >> allow folks deploying gTLD's to get IPv4 number resources from a >> reserved pool. ?It in fact says nothing about IPv6 resources, they >> are available today and will continue to be available in the future >> on the exact same terms. > > > I would like to ensure that new registry applicants have access to v4 > resources, and that they are not forced to "transition" to v6, or simply > start v6-only, for v4 scarcity and cost reasons. If 123 exists, then it is > reasonable to point to this as a means to reduce the impulse to require new > registry operators to have v6 skills and plumbing in place ab initio. I agree that new TLDs should not be forced into v6-only services due to lack of availability of IPv4. I don't believe that changes the need for them to do IPv6 as well, but in any event ICANN's IPv6 requirement is orthogonal to this proposal, and outside of the scope of ARIN policy. >> If the concern is that some new gTLD's will try and use the resources >> available under Proposal 123 to deploy IPv4 _only_ support for >> gTLD's that is an administrative matter for ICANN and the JAS WG. >> Indeed, even without this pool gTLD's could obtain IPv4 resources >> from their upstream, via hosting companies, or even via the transfer >> market. ?This Proposal 123 may make it a bit easier for them, but >> in no way is IPv4 impossible without it. > > 123 may make it a bit easier for them, and it offers terms at least as good > as the transfer market or being forced to be tenants of their competitors. I definitely agree that 123 will be beneficial for new TLD operators. If the community sees that as being beneficial for everyone (due to the nature of CI services), then I think 123 should be adopted on that basis. If, however, 123 is primarily perceived as a benefit to a particular class of organizations and not to the community as a whole, I think there are other acceptable avenues to accomplish that, without special policy treatment. >> it appears to me this proposal should make it easier >> and operationally better to roll out new gTLD's. > > Agree. Hence my expression, however greek, of support for it. Thanks for speaking up, and working with us to understand your comments. Outside perspectives are particularly useful, and I hope you (and others) will continue to contribute to the policy process. -Scott From scottleibrand at gmail.com Wed Dec 22 15:52:57 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 22 Dec 2010 12:52:57 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: References: <4D117E45.2010605@abenaki.wabanaki.net> Message-ID: On Wed, Dec 22, 2010 at 11:04 AM, Hannigan, Martin wrote: > > > > Effectively, this proposal seeks to guarantee access to IPv4 resources for a > reasonably short period of time. It will enable critical infrastructure "CI" > to be able to receive a small amount of IPv4 addresses so that they can > provide a full and robust service to the Internet. The reason why we > shouldn't (as Scott Liebrand has and continues to advocate) simply push > these needs to "markets" is because these entities have little choice but to > serve two internets for some time and it is unreasonable to challenge new > entities building CI with the massively increased cost in order to be able > to do so. The benefits of new CI, such as TLD's, outweigh the benefit of not > carving out a small chunk of address space. I am sympathetic to this perspective, and voted to accept policy proposal 123 onto the AC's docket. I believe it is worthy of discussion at the April Public Policy Meeting, and if after the discussion there the community feels that the benefits of new CI networks are a benefit to the entire community, then I believe this policy proposal is worth approving on that basis. If, however, the benefit would primarily accrue directly to the organizations receiving the space, and not to the community as a whole, then I would argue that such organizations, given the small amount of IPv4 space needed, are in a better position than other IPv4 users to acquire that space directly, without special policy treatment. (IOW, the costs would be a lot less massive for a CI provider needing a /24 than for a new ISP needing a /16.) -Scott P.S. My last name is spelled Leibrand, and pronounced Lye-brand. (It's German.) From marty at akamai.com Wed Dec 22 16:21:56 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 22 Dec 2010 16:21:56 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D125FAE.3050307@arin.net> Message-ID: I support this petition. Best, -M< On 12/22/10 3:29 PM, "ARIN" wrote: > The message below started a petition regarding the ARIN Advisory > Council's decision to abandon "ARIN-prop-125 Efficient Utilization of > IPv4 Requires Dual-Stack". The AC's decision was posted by ARIN staff to > PPML on 21 December 2010. > > If successful, this petition will change ARIN-prop-125 into a Draft > Policy which will be published for adoption discussion on the PPML and > at the Public Policy Meeting in April. If the petition fails, the > proposal will be closed. > > For this petition to be successful, the petition needs statements of > support from at least 10 different people from 10 different > organizations. If you wish to support this petition, post a statement of > support to PPML on this thread. > > The duration of the petition is until five business days after the AC's > draft meeting minutes are published. ARIN staff will post the result of > the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ##### > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Chris Grundemann >> Sent: Wednesday, December 22, 2010 3:11 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient >> Utilization of IPv4 Requires Dual-Stack >> >> The AC should not have abandoned ARIN-prop-125 Efficient Utilization >> of IPv4 Requires Dual-Stack. I petition to move the following text >> forward for discussion on the list and at the next Public Policy >> Meeting. Please support moving this proposal forward now by posting >> statements in support of the petition to this list. >> >> ### >> >> Policy Statement: >> >> * Add the following sections to section 4.1: >> >> 4.1.2. Efficient Utilization >> >> IPv4 addresses are a finite resource and as such are required to be >> efficiently utilized by resource holders in order to maximize their >> benefit to the community. >> >> 4.1.3. Dual-Stack >> >> Dual-stack refers to configuring both an IPv4 and an IPv6 address or >> network together on the same network infrastructure. >> >> All new IPv4 addresses assigned, allocated or transfered to an >> organization must be deployed on dual-stacked interfaces along with >> IPv6 addresses. >> >> 4.1.4. IPv6 Deployment >> >> When addresses are used to provide an Internet facing service, the >> service must be fully IPv6 accessible (if you deploy an A record, you >> must also have a AAAA record, and both must answer). >> >> * Add the following sentance to the end of sections 4.2.1.6, >> 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: >> >> In accordance with section 4.1.3 and 4.1.4, all new addresses must be >> deployed on dual-stacked interfaces and all Internet facing services >> provided by new addresses must be fully IPv6 accessible. >> >> * Re-write section 4.2.3.4.1. to: >> >> Reassignment information for prior allocations must show that each >> customer meets the 80% utilization criteria, the dual-stack criteria >> and must be available via SWIP / RWhois prior to your issuing them >> additional space. >> >> * Add the following section to section 4.2.4: >> >> 4.2.4.5. IPv6 Deployment >> >> In order to receive additional space ISPs must provide detailed >> documentation demonstrating that: >> - for every IPv4 address requested, at least one pre-existing >> interface is dual stacked, up to 80% of all interfaces and >> - for every down stream customer site where the new addresses will be >> deployed, at least one pre-existing down stream customer site is IPv6 >> enabled, up to 80% of the total customer base. >> >> * Add the following to section 4.3.6: >> >> 4.3.6.3. IPv6 Deployment >> >> In order to receive additional space end-users must provide detailed >> documentation demonstrating that at least 80% of their existing IPv4 >> addresses are deployed on dual-stacked interfaces in accordance with >> section 4.1.3. >> >> Rational: >> >> In this period of available IPv4 address scarcity and transition to >> IPv6, IPv4 addresses that are not deployed along with IPv6 are simply >> not being efficiently utilized. Although we have likely failed to >> deploy dual-stack in a meaningful way in time to avoid transition >> problems, we can still choose the correct path for future assignments, >> allocations and transfers. >> >> This proposal has three objectives: >> -1- Encourage IPv6 deployment prior to and post depletion >> -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change >> was to this line]# >> -3- Improve the utilization of IP addresses >> >> It accomplishes these goals by enforcing three basic ideals: >> -1- ARIN will only make allocations and assignments for networks that >> have already deployed production IPv6 >> -2- Any new IPv4 addresses received, must be deployed along side of >> IPv6 (dual-stacked) >> -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks >> >> The specific requirements to be enforced can be summed up in this way: >> ~ New addresses must be deployed on dual-stacked interfaces plus one >> additional pre-existing IPv4-only interface must be dual-stacked per >> new address, up to 80% of all interfaces. >> ~ For each down stream customer site where these addresses are >> deployed, another pre-existing IPv4 only down stream site must also be >> IPv6 enabled, up to 80% of the total customer base. >> ~ All end-sites must dual-stack before getting new space. >> ~ Internet facing services that new IPv4 addresses are used to provide >> must be fully IPv6 accessible. >> >> ### >> >> Chris Grundemann >> www.theIPv6experts.net >> chris at theIPv6experts.net >> _______________________________________________ >> 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 bicknell at ufp.org Wed Dec 22 17:21:46 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 22 Dec 2010 14:21:46 -0800 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D125A03.5040408@abenaki.wabanaki.net> References: <4D125A03.5040408@abenaki.wabanaki.net> Message-ID: <20101222222146.GA57535@ussenterprise.ufp.org> In a message written on Wed, Dec 22, 2010 at 03:05:23PM -0500, Eric Brunner-Williams wrote: > Either v6 adoption is, or isn't, a manageable cost, and 123 offers a > temporal tool, re-usable v4 blocks, that may move the cost of v6 > adoption off of the applicant-operator's debit finance and onto its > revenue finance books. I highly doubt the cost of IPv6 to a new gTLD are significant. The folks who have come forward with significant costs to deploy IPv6 are folks with a huge legacy equipment provider. DSLAMs that must be forklifted. 10 million CPE's that must be swapped. If you're setting up some servers in a colo to serve a TLD any equipment you're likely to select already supports it. Sure there is a small amount of staff time to configure it, and perhaps depending on your situation, things like additional RIR fees, but they are all very small dollars. If the cost of doing IPv6 is too much for a new gTLD operator than I would say ICANN awared the gTLD to someone who is not competent to run it. However, there's a reason I stay out of that part of the Internet process... -- 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 jordi.palet at consulintel.es Wed Dec 22 17:14:52 2010 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 22 Dec 2010 23:14:52 +0100 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: Message-ID: I also support this petition. Regards, Jordi -----Mensaje original----- De: "Hannigan, Martin" Responder a: "Hannigan, Martin" Fecha: Wed, 22 Dec 2010 16:21:56 -0500 Para: "arin-ppml at arin.net" Asunto: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack > > >I support this petition. > >Best, > >-M< > > >On 12/22/10 3:29 PM, "ARIN" wrote: > >> The message below started a petition regarding the ARIN Advisory >> Council's decision to abandon "ARIN-prop-125 Efficient Utilization of >> IPv4 Requires Dual-Stack". The AC's decision was posted by ARIN staff to >> PPML on 21 December 2010. >> >> If successful, this petition will change ARIN-prop-125 into a Draft >> Policy which will be published for adoption discussion on the PPML and >> at the Public Policy Meeting in April. If the petition fails, the >> proposal will be closed. >> >> For this petition to be successful, the petition needs statements of >> support from at least 10 different people from 10 different >> organizations. If you wish to support this petition, post a statement of >> support to PPML on this thread. >> >> The duration of the petition is until five business days after the AC's >> draft meeting minutes are published. ARIN staff will post the result of >> the petition to PPML. >> >> For more information on starting and participating in petitions, see PDP >> Petitions at: >> https://www.arin.net/policy/pdp_petitions.html >> >> The proposal text is below and 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, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ##### >> >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >>> Behalf Of Chris Grundemann >>> Sent: Wednesday, December 22, 2010 3:11 PM >>> To: arin-ppml at arin.net >>> Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient >>> Utilization of IPv4 Requires Dual-Stack >>> >>> The AC should not have abandoned ARIN-prop-125 Efficient Utilization >>> of IPv4 Requires Dual-Stack. I petition to move the following text >>> forward for discussion on the list and at the next Public Policy >>> Meeting. Please support moving this proposal forward now by posting >>> statements in support of the petition to this list. >>> >>> ### >>> >>> Policy Statement: >>> >>> * Add the following sections to section 4.1: >>> >>> 4.1.2. Efficient Utilization >>> >>> IPv4 addresses are a finite resource and as such are required to be >>> efficiently utilized by resource holders in order to maximize their >>> benefit to the community. >>> >>> 4.1.3. Dual-Stack >>> >>> Dual-stack refers to configuring both an IPv4 and an IPv6 address or >>> network together on the same network infrastructure. >>> >>> All new IPv4 addresses assigned, allocated or transfered to an >>> organization must be deployed on dual-stacked interfaces along with >>> IPv6 addresses. >>> >>> 4.1.4. IPv6 Deployment >>> >>> When addresses are used to provide an Internet facing service, the >>> service must be fully IPv6 accessible (if you deploy an A record, you >>> must also have a AAAA record, and both must answer). >>> >>> * Add the following sentance to the end of sections 4.2.1.6, >>> 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: >>> >>> In accordance with section 4.1.3 and 4.1.4, all new addresses must be >>> deployed on dual-stacked interfaces and all Internet facing services >>> provided by new addresses must be fully IPv6 accessible. >>> >>> * Re-write section 4.2.3.4.1. to: >>> >>> Reassignment information for prior allocations must show that each >>> customer meets the 80% utilization criteria, the dual-stack criteria >>> and must be available via SWIP / RWhois prior to your issuing them >>> additional space. >>> >>> * Add the following section to section 4.2.4: >>> >>> 4.2.4.5. IPv6 Deployment >>> >>> In order to receive additional space ISPs must provide detailed >>> documentation demonstrating that: >>> - for every IPv4 address requested, at least one pre-existing >>> interface is dual stacked, up to 80% of all interfaces and >>> - for every down stream customer site where the new addresses will be >>> deployed, at least one pre-existing down stream customer site is IPv6 >>> enabled, up to 80% of the total customer base. >>> >>> * Add the following to section 4.3.6: >>> >>> 4.3.6.3. IPv6 Deployment >>> >>> In order to receive additional space end-users must provide detailed >>> documentation demonstrating that at least 80% of their existing IPv4 >>> addresses are deployed on dual-stacked interfaces in accordance with >>> section 4.1.3. >>> >>> Rational: >>> >>> In this period of available IPv4 address scarcity and transition to >>> IPv6, IPv4 addresses that are not deployed along with IPv6 are simply >>> not being efficiently utilized. Although we have likely failed to >>> deploy dual-stack in a meaningful way in time to avoid transition >>> problems, we can still choose the correct path for future assignments, >>> allocations and transfers. >>> >>> This proposal has three objectives: >>> -1- Encourage IPv6 deployment prior to and post depletion >>> -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change >>> was to this line]# >>> -3- Improve the utilization of IP addresses >>> >>> It accomplishes these goals by enforcing three basic ideals: >>> -1- ARIN will only make allocations and assignments for networks that >>> have already deployed production IPv6 >>> -2- Any new IPv4 addresses received, must be deployed along side of >>> IPv6 (dual-stacked) >>> -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks >>> >>> The specific requirements to be enforced can be summed up in this way: >>> ~ New addresses must be deployed on dual-stacked interfaces plus one >>> additional pre-existing IPv4-only interface must be dual-stacked per >>> new address, up to 80% of all interfaces. >>> ~ For each down stream customer site where these addresses are >>> deployed, another pre-existing IPv4 only down stream site must also be >>> IPv6 enabled, up to 80% of the total customer base. >>> ~ All end-sites must dual-stack before getting new space. >>> ~ Internet facing services that new IPv4 addresses are used to provide >>> must be fully IPv6 accessible. >>> >>> ### >>> >>> Chris Grundemann >>> www.theIPv6experts.net >>> chris at theIPv6experts.net >>> _______________________________________________ >>> 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. ********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From alh-ietf at tndh.net Wed Dec 22 18:35:18 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 22 Dec 2010 15:35:18 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: <0b2201cba230$ec372d00$c4a58700$@net> I do not support this petition. While I am all for IPv6 deployment asap, the continued attitude that 'you must deploy your network the way we say' is absolutely the wrong direction. ARIN should provide all the hints they can about the long term value of IPv6 deployment, but at the end of the day if people want to take a short sighted view, it is their loss when the market moves on. IPv4 is dead. ARIN policy development needs to stop worrying about micromanagement of the last few crumbs. In particular, any existing member should stop caring and get on with IPv6 deployment. Rearranging the deck chairs after the Titanic has sunk is all this petition amounts to. Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Wednesday, December 22, 2010 12:11 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient > Utilization of IPv4 Requires Dual-Stack > > The AC should not have abandoned ARIN-prop-125 Efficient Utilization > of IPv4 Requires Dual-Stack. I petition to move the following text > forward for discussion on the list and at the next Public Policy > Meeting. Please support moving this proposal forward now by posting > statements in support of the petition to this list. > > ### > > Policy Statement: > > * Add the following sections to section 4.1: > > 4.1.2. Efficient Utilization > > IPv4 addresses are a finite resource and as such are required to be > efficiently utilized by resource holders in order to maximize their > benefit to the community. > > 4.1.3. Dual-Stack > > Dual-stack refers to configuring both an IPv4 and an IPv6 address or > network together on the same network infrastructure. > > All new IPv4 addresses assigned, allocated or transfered to an > organization must be deployed on dual-stacked interfaces along with > IPv6 addresses. > > 4.1.4. IPv6 Deployment > > When addresses are used to provide an Internet facing service, the > service must be fully IPv6 accessible (if you deploy an A record, you > must also have a AAAA record, and both must answer). > > * Add the following sentance to the end of sections 4.2.1.6, > 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: > > In accordance with section 4.1.3 and 4.1.4, all new addresses must be > deployed on dual-stacked interfaces and all Internet facing services > provided by new addresses must be fully IPv6 accessible. > > * Re-write section 4.2.3.4.1. to: > > Reassignment information for prior allocations must show that each > customer meets the 80% utilization criteria, the dual-stack criteria > and must be available via SWIP / RWhois prior to your issuing them > additional space. > > * Add the following section to section 4.2.4: > > 4.2.4.5. IPv6 Deployment > > In order to receive additional space ISPs must provide detailed > documentation demonstrating that: > - for every IPv4 address requested, at least one pre-existing > interface is dual stacked, up to 80% of all interfaces and > - for every down stream customer site where the new addresses will be > deployed, at least one pre-existing down stream customer site is IPv6 > enabled, up to 80% of the total customer base. > > * Add the following to section 4.3.6: > > 4.3.6.3. IPv6 Deployment > > In order to receive additional space end-users must provide detailed > documentation demonstrating that at least 80% of their existing IPv4 > addresses are deployed on dual-stacked interfaces in accordance with > section 4.1.3. > > Rational: > > In this period of available IPv4 address scarcity and transition to > IPv6, IPv4 addresses that are not deployed along with IPv6 are simply > not being efficiently utilized. Although we have likely failed to > deploy dual-stack in a meaningful way in time to avoid transition > problems, we can still choose the correct path for future assignments, > allocations and transfers. > > This proposal has three objectives: > -1- Encourage IPv6 deployment prior to and post depletion > -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change > was to this line]# > -3- Improve the utilization of IP addresses > > It accomplishes these goals by enforcing three basic ideals: > -1- ARIN will only make allocations and assignments for networks that > have already deployed production IPv6 > -2- Any new IPv4 addresses received, must be deployed along side of > IPv6 (dual-stacked) > -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks > > The specific requirements to be enforced can be summed up in this way: > ~ New addresses must be deployed on dual-stacked interfaces plus one > additional pre-existing IPv4-only interface must be dual-stacked per > new address, up to 80% of all interfaces. > ~ For each down stream customer site where these addresses are > deployed, another pre-existing IPv4 only down stream site must also be > IPv6 enabled, up to 80% of the total customer base. > ~ All end-sites must dual-stack before getting new space. > ~ Internet facing services that new IPv4 addresses are used to provide > must be fully IPv6 accessible. > > ### > > Chris Grundemann > www.theIPv6experts.net > chris at theIPv6experts.net > _______________________________________________ > 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 Dec 22 18:55:01 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 22 Dec 2010 16:55:01 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <0b2201cba230$ec372d00$c4a58700$@net> References: <0b2201cba230$ec372d00$c4a58700$@net> Message-ID: On Wed, Dec 22, 2010 at 16:35, Tony Hain wrote: > I do not support this petition. > > While I am all for IPv6 deployment asap, the continued attitude that 'you > must deploy your network the way we say' is absolutely the wrong direction. > ARIN should provide all the hints they can about the long term value of IPv6 > deployment, but at the end of the day if people want to take a short sighted > view, it is their loss when the market moves on. > > IPv4 is dead. ARIN policy development needs to stop worrying about > micromanagement of the last few crumbs. In particular, any existing member > should stop caring and get on with IPv6 deployment. Rearranging the deck > chairs after the Titanic has sunk is all this petition amounts to. The "deck chairs" analogy is becoming a go-to for anything that mentions IPv4 these days. The problem as I see it is that there are still some members of the community who have not come to the same realization that you and I have (IPv4 is dead, IPv6 is table stakes). So... What happens if a few large/important enough organizations are able to spend the money required to buy the rights to IPv4 addresses (or companies which possess the rights to IPv4 addresses) in large enough quantities to defer their own IPv6 deployment long enough to make others reconsider their own transition strategy (and the expense of implementing it)? I don't believe that they could ever kill IPv6 long term but they may very well be able to deepen and prolong everyone else's transition pain. The bottom line at this point is that deploying new IPv4 addresses (beyond those you already have in reserve) without also deploying IPv6 is at this point a waste of those IPv4 addresses and has the potential to harm the other members of this community. Justified need policy has ALWAYS had a 'you must deploy your network the way we say' attitude, it says that you are not allowed to deploy your network in a way that wastes IP addresses. This policy proposal simply updates what it means to waste addresses. Stewardship does not always allow one to look the other way, especially when someone else's short-sightedness will harm the greater community. Cheers, ~Chris > > Tony > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Chris Grundemann >> Sent: Wednesday, December 22, 2010 12:11 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient >> Utilization of IPv4 Requires Dual-Stack >> >> The AC should not have abandoned ARIN-prop-125 Efficient Utilization >> of IPv4 Requires Dual-Stack. I petition to move the following text >> forward for discussion on the list and at the next Public Policy >> Meeting. Please support moving this proposal forward now by posting >> statements in support of the petition to this list. >> >> ### >> >> Policy Statement: >> >> * Add the following sections to section 4.1: >> >> 4.1.2. Efficient Utilization >> >> IPv4 addresses are a finite resource and as such are required to be >> efficiently utilized by resource holders in order to maximize their >> benefit to the community. >> >> 4.1.3. Dual-Stack >> >> Dual-stack refers to configuring both an IPv4 and an IPv6 address or >> network together on the same network infrastructure. >> >> All new IPv4 addresses assigned, allocated or transfered to an >> organization must be deployed on dual-stacked interfaces along with >> IPv6 addresses. >> >> 4.1.4. IPv6 Deployment >> >> When addresses are used to provide an Internet facing service, the >> service must be fully IPv6 accessible (if you deploy an A record, you >> must also have a AAAA record, and both must answer). >> >> * Add the following sentance to the end of sections 4.2.1.6, >> 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: >> >> In accordance with section 4.1.3 and 4.1.4, all new addresses must be >> deployed on dual-stacked interfaces and all Internet facing services >> provided by new addresses must be fully IPv6 accessible. >> >> * Re-write section 4.2.3.4.1. to: >> >> Reassignment information for prior allocations must show that each >> customer meets the 80% utilization criteria, the dual-stack criteria >> and must be available via SWIP / RWhois prior to your issuing them >> additional space. >> >> * Add the following section to section 4.2.4: >> >> 4.2.4.5. IPv6 Deployment >> >> In order to receive additional space ISPs must provide detailed >> documentation demonstrating that: >> ? - for every IPv4 address requested, at least one pre-existing >> interface is dual stacked, up to 80% of all interfaces and >> ? - for every down stream customer site where the new addresses will be >> deployed, at least one pre-existing down stream customer site is IPv6 >> enabled, up to 80% of the total customer base. >> >> * Add the following to section 4.3.6: >> >> 4.3.6.3. IPv6 Deployment >> >> In order to receive additional space end-users must provide detailed >> documentation demonstrating that at least 80% of their existing IPv4 >> addresses are deployed on dual-stacked interfaces in accordance with >> section 4.1.3. >> >> Rational: >> >> In this period of available IPv4 address scarcity and transition to >> IPv6, IPv4 addresses that are not deployed along with IPv6 are simply >> not being efficiently utilized. Although we have likely failed to >> deploy dual-stack in a meaningful way in time to avoid transition >> problems, we can still choose the correct path for future assignments, >> allocations and transfers. >> >> This proposal has three objectives: >> -1- Encourage IPv6 deployment prior to and post depletion >> -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change >> was to this line]# >> -3- Improve the utilization of IP addresses >> >> It accomplishes these goals by enforcing three basic ideals: >> -1- ARIN will only make allocations and assignments for networks that >> have already deployed production IPv6 >> -2- Any new IPv4 addresses received, must be deployed along side of >> IPv6 (dual-stacked) >> -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks >> >> The specific requirements to be enforced can be summed up in this way: >> ~ New addresses must be deployed on dual-stacked interfaces plus one >> additional pre-existing IPv4-only interface must be dual-stacked per >> new address, up to 80% of all interfaces. >> ~ For each down stream customer site where these addresses are >> deployed, another pre-existing IPv4 only down stream site must also be >> IPv6 enabled, up to 80% of the total customer base. >> ~ All end-sites must dual-stack before getting new space. >> ~ Internet facing services that new IPv4 addresses are used to provide >> must be fully IPv6 accessible. >> >> ### >> >> Chris Grundemann >> www.theIPv6experts.net >> chris at theIPv6experts.net >> _______________________________________________ >> 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.theIPv6experts.com www.coisoc.org From farmer at umn.edu Wed Dec 22 19:14:50 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 22 Dec 2010 18:14:50 -0600 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D114C88.8090906@abenaki.wabanaki.net> References: <4D114C88.8090906@abenaki.wabanaki.net> Message-ID: <4D12947A.7040505@umn.edu> As several others have already done, I want to thank you for bringing your perspective to this discussion. I have a few comments and questions in-line below. On 12/21/10 18:55 CST, Eric Brunner-Williams wrote: > Colleagues, > > I'd like this proposal to be approved. I've discussed it with Marty at > the Cartegena ICANN meeting two weeks ago. I take your comments as supporting the policy proposal in general, and note that the AC accepted this proposal on to its docket and I expect we will follow ARIN's normal policy development process and have a draft policy for discussion at the April Public Policy Meeting in San Juan. However the subject line for your email "Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure?" could suggest you support emergency action beyond this. So, my question is do you believe emergency actions is necessary for this proposal? If so, what and why? > My concern is that new registry proposants who meet the criteria for > assistance under the current JAS WG Milestone [1], or future work > product of the JAS WG, are, under the current ICANN Draft Applicant > Guidebook, required to be v6 capable. This is a cost that can be > deferred, if 123 becomes ARIN policy, at least for the ARIN region, and > if imitated by the other RIR's, more broadly. The issue of post run-out CI has come up on some of other RIR's policy mailing lists and I would like to suggest that those discussion could equally benefit from your perspective. So, I encourage you to participate those discussion or raise the issue within the other RIR's policy processes and mailing lists too. > The v6 capability is independent of the regional addressing > infrastructure availability local to the registry infrastructure, > registrars, or registrants. > > The case for exempting applicants meeting the Milestone et seq. criteria > for assistance, or any larger class of new, or new and existing, > registry operators, from a near-term v6 capability requirement could be > supported by the existence of a critical infrastructure address pool, > allowing transition over a multi-quarter period, with address recovery > for subsequent transitional allocation. As others have commented, I don't think IPv6 is that much of an additional technical burden for a CI deployment, and should be fairly easy. However, I have experience with IPv6 and little if any experience with CI deployments. Also, I imagine there are many other things that such a new registry would probably need/want to focus on before IPv6. Therefore, I wouldn't want to ICANN to eliminate any IPv6 requirements, but maybe they shouldn't be primary decision factors either. > Professor Meuller, with whom I find little ever in common agreement, > including the polarity of gravity, observes, for whatever reason, "In a > world of 5,000 TLDs, do all g and cc TLDs have the same status?" > > It is profoundly unlikely that each of the registry operators will be > facilities-based operations, and not implemented as a tenant registry of > a registry services provider, and assuming the 1k/yr gate asserted by > the Root Scaling Study authors, on a three year transition, after 5 > years the number of independent, outstanding transitional allocations > would be significantly less than 5k. > > Eric Brunner-Williams > member, JAS WG > > [1] http://icann.org/en/public-comment/#jas-milestone-report -- =============================================== 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 ebw at abenaki.wabanaki.net Wed Dec 22 19:33:35 2010 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Wed, 22 Dec 2010 19:33:35 -0500 Subject: [arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure? In-Reply-To: <4D12947A.7040505@umn.edu> References: <4D114C88.8090906@abenaki.wabanaki.net> <4D12947A.7040505@umn.edu> Message-ID: <4D1298DF.7050909@abenaki.wabanaki.net> On 12/22/10 7:14 PM, David Farmer wrote: > As several others have already done, I want to thank you for bringing > your perspective to this discussion. I have a few comments and > questions in-line below. > > On 12/21/10 18:55 CST, Eric Brunner-Williams wrote: >> Colleagues, >> >> I'd like this proposal to be approved. I've discussed it with Marty at >> the Cartegena ICANN meeting two weeks ago. > > I take your comments as supporting the policy proposal in general, and > note that the AC accepted this proposal on to its docket and I expect > we will follow ARIN's normal policy development process and have a > draft policy for discussion at the April Public Policy Meeting in San > Juan. However the subject line for your email "Is Emergency action > warranted for Policy Proposal 123: Reserved Pool for Critical > Infrastructure?" could suggest you support emergency action beyond > this. So, my question is do you believe emergency actions is necessary > for this proposal? If so, what and why? I should have made my comments prior to the 16th. The subject line was simply the subject line that existed prior to the 16th. My comments are supporting the policy proposal in general, and are intended only to inform the AC of a use case for which 123 meets a specific "new", but apparently recurring, CI need. >> My concern is that new registry proposants who meet the criteria for >> assistance under the current JAS WG Milestone [1], or future work >> product of the JAS WG, are, under the current ICANN Draft Applicant >> Guidebook, required to be v6 capable. This is a cost that can be >> deferred, if 123 becomes ARIN policy, at least for the ARIN region, and >> if imitated by the other RIR's, more broadly. > > The issue of post run-out CI has come up on some of other RIR's policy > mailing lists and I would like to suggest that those discussion could > equally benefit from your perspective. So, I encourage you to > participate those discussion or raise the issue within the other RIR's > policy processes and mailing lists too. Thank you. >> The v6 capability is independent of the regional addressing >> infrastructure availability local to the registry infrastructure, >> registrars, or registrants. >> >> The case for exempting applicants meeting the Milestone et seq. >> criteria >> for assistance, or any larger class of new, or new and existing, >> registry operators, from a near-term v6 capability requirement could be >> supported by the existence of a critical infrastructure address pool, >> allowing transition over a multi-quarter period, with address recovery >> for subsequent transitional allocation. > > As others have commented, I don't think IPv6 is that much of an > additional technical burden for a CI deployment, and should be fairly > easy. However, I have experience with IPv6 and little if any > experience with CI deployments. Also, I imagine there are many other > things that such a new registry would probably need/want to focus on > before IPv6. Therefore, I wouldn't want to ICANN to eliminate any IPv6 > requirements, but maybe they shouldn't be primary decision factors > either. There are more important issues for new registry operators, yet all of the laundry list of issues, as contractual compliance issues, are, at the moment, of equal value, and no rational applicant could afford to act on operational issue priority before acting on contractual compliance issues. There are several "requirements" in the current Draft Applicant Guidebook that may be made less restrictive, or more restrictive, through the public comments process. This is only one, and not the most onerous, but it is one in which the merits of the requirement are a policy issue of a distinct policy making body. Eric Brunner-Williams member, JAS WG From hannigan at gmail.com Thu Dec 23 14:16:59 2010 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 23 Dec 2010 14:16:59 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - December 2010 In-Reply-To: <4D10E080.8080408@arin.net> References: <4D10E080.8080408@arin.net> Message-ID: To insure that there are no surprises, I want to let folks know that I am going to petition PP124. If there isn't already a method to insure tracking of requests in the resource request queue that would be impacted by 124, something would be warranted just in case 124 succeeds. Best, -M< Sent from my iPad On Dec 21, 2010, at 12:14 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) held a meeting on 16 December 2010 and made > decisions about several draft policies and proposals. > > After last call the AC recommended that the ARIN Board of Trustees adopt > the following draft policy: > > ARIN-2010-8 Rework of IPv6 assignment criteria > > The AC moved the following draft policy to last call (it will be posted > separately to last call): > > ARIN-2010-14 Standardize IP Reassignment Registration Requirements > > The AC accepted the following proposals on to the AC's docket for > development and evaluation: > > ARIN-prop-121 Better IPv6 Allocation for ISPs > ARIN-prop-123 Reserved Pool for Critical Infrastructure > > The AC abandoned the following proposals: > > ARIN-prop-122 Reserved Pool for Future Policy Development > ARIN-prop-124 Clarification of Section 4.2.4.4 > ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack > > "The AC did not feel that emergency action was warranted for proposal > 122, and given that the IANA IPv4 pool is expected to exhaust before the > April Public Policy Meeting, did not feel that it would be useful to put > this proposal on the AC's docket. The AC would encourage anyone with > policy proposals for improving NRPM section 4.10 to submit them > immediately, so they can be considered in time for the April meeting." > > "After discussion of proposal 124, the AC did not feel that emergency > action was warranted. Normally there are few requests in queue and any > moment, as a result the expected overall impact of this issue should be > small. Furthermore, it is possible this proposal could increase the > motivation to submit incomplete or fraudulent proposals at the last > moment, it was felt this should not be encouraged. As the trigger event > in NRPM Section 4.2.4.4 is almost assuredly to have occurred before the > April Public Policy Meeting, this proposal would be irrelevant by the > time it could be presented at that meeting. Therefore, the AC voted to > abandon the proposal now." > > And regarding ARIN-prop-125 the AC stated, "The initial interpretation > was that while ARIN's role is to manage and administer Internet number > resources, this proposal strays too far from management towards a > mandate. This proposal may benefit the deployment of IPv6, but it would > do so by forcing companies to deploy IPv6 where it may not be > immediately needed and could have unintended consequences on IPv4 > transfers." > > The PDP states, ?Any member of the community, including a proposal > originator, may initiate a Discussion Petition if they are dissatisfied > with the action taken by the Advisory Council regarding any specific > policy proposal.? The abandonment of proposals 122, 124 and 125 may be > petitioned to try to change them into draft policies for discussion on > the Public Policy Mailing List and at the April Public Policy Meeting > (this is the Discussion Petition). The deadline to begin a petition > will be five business days after the AC's draft meeting minutes are > published. For more information on starting and participating in > petitions, see PDP Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Policy Proposal texts 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, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > > > > > > > _______________________________________________ > 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 oberman at es.net Sun Dec 26 22:28:43 2010 From: oberman at es.net (Kevin Oberman) Date: Sun, 26 Dec 2010 19:28:43 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: Your message of "Wed, 22 Dec 2010 15:29:34 EST." <4D125FAE.3050307@arin.net> Message-ID: <20101227032843.B02F51CC16@ptavv.es.net> Is Dec. 24 a business day? I believe it was a bank holiday and was a US federal government holiday, but I think most businesses were open. Does ARIN have a formal definition of "business day"? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Date: Wed, 22 Dec 2010 15:29:34 -0500 > From: ARIN > Sender: arin-ppml-bounces at arin.net > > The message below started a petition regarding the ARIN Advisory > Council's decision to abandon "ARIN-prop-125 Efficient Utilization of > IPv4 Requires Dual-Stack". The AC's decision was posted by ARIN staff to > PPML on 21 December 2010. > > If successful, this petition will change ARIN-prop-125 into a Draft > Policy which will be published for adoption discussion on the PPML and > at the Public Policy Meeting in April. If the petition fails, the > proposal will be closed. > > For this petition to be successful, the petition needs statements of > support from at least 10 different people from 10 different > organizations. If you wish to support this petition, post a statement of > support to PPML on this thread. > > The duration of the petition is until five business days after the AC's > draft meeting minutes are published. ARIN staff will post the result of > the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) From susanh at arin.net Mon Dec 27 08:19:14 2010 From: susanh at arin.net (Susan Hamlin) Date: Mon, 27 Dec 2010 13:19:14 +0000 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <20101227032843.B02F51CC16@ptavv.es.net> References: Your message of "Wed, 22 Dec 2010 15:29:34 EST." <4D125FAE.3050307@arin.net> <20101227032843.B02F51CC16@ptavv.es.net> Message-ID: <7BB4AF66EBB221449CDCDFC02C09D777645E73@CHAXCH01.corp.arin.net> Hello Kevin, December 24 was not a business day for ARIN. The offices were closed Dec. 24 and 25. The holiday calendar for 2010 is available here: https://www.arin.net/announcements/closing.html. We will be posting the 2011 calendar by the end of this week. Regards, Susan Hamlin Director, Communications and Member Services American Registry for Internet Numbers (ARIN) 1.703.227.9851 -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Oberman Sent: Sunday, December 26, 2010 10:29 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Is Dec. 24 a business day? I believe it was a bank holiday and was a US federal government holiday, but I think most businesses were open. Does ARIN have a formal definition of "business day"? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Date: Wed, 22 Dec 2010 15:29:34 -0500 > From: ARIN > Sender: arin-ppml-bounces at arin.net > > The message below started a petition regarding the ARIN Advisory > Council's decision to abandon "ARIN-prop-125 Efficient Utilization of > IPv4 Requires Dual-Stack". The AC's decision was posted by ARIN staff to > PPML on 21 December 2010. > > If successful, this petition will change ARIN-prop-125 into a Draft > Policy which will be published for adoption discussion on the PPML and > at the Public Policy Meeting in April. If the petition fails, the > proposal will be closed. > > For this petition to be successful, the petition needs statements of > support from at least 10 different people from 10 different > organizations. If you wish to support this petition, post a statement of > support to PPML on this thread. > > The duration of the petition is until five business days after the AC's > draft meeting minutes are published. ARIN staff will post the result of > the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) _______________________________________________ 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 Mon Dec 27 09:17:34 2010 From: bill at herrin.us (William Herrin) Date: Mon, 27 Dec 2010 09:17:34 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: On Wed, Dec 22, 2010 at 3:10 PM, Chris Grundemann wrote: >4.1.4. IPv6 Deployment > >When addresses are used to provide an Internet facing service, the >service must be fully IPv6 accessible (if you deploy an A record, you >must also have a AAAA record, and both must answer). I DO NOT SUPPORT the petition to move proposal 125 forward. Although I support the concept of requiring IPv6 deployment in order to continue consuming IPv4 addresses, this particular proposal is gratuitously heavy-handed. If a comparable proposal were brought forward which does not attempt to micro-manage an organization's IPv6 deployment process, I would support it and, if necessary support a petition to move it forward. 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 Mon Dec 27 11:13:18 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 27 Dec 2010 09:13:18 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: Hi Bill, Supporting the petition to move this proposal forward could allow precisely that discussion to take place. Cheers ~Chris My Android sent this message. On Dec 27, 2010 7:17 AM, "William Herrin" wrote: On Wed, Dec 22, 2010 at 3:10 PM, Chris Grundemann wrote: >4.1.4. IPv6 Deploy... I DO NOT SUPPORT the petition to move proposal 125 forward. Although I support the concept of requiring IPv6 deployment in order to continue consuming IPv4 addresses, this particular proposal is gratuitously heavy-handed. If a comparable proposal were brought forward which does not attempt to micro-manage an organization's IPv6 deployment process, I would support it and, if necessary support a petition to move it forward. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From schiller at uu.net Mon Dec 27 11:34:58 2010 From: schiller at uu.net (Jason Schiller) Date: Mon, 27 Dec 2010 11:34:58 -0500 (EST) Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: Bill, I get the impression that you support the concept of requiring IPv6 deployment for those organizations that continue to need additional IPv4 addresses. If that is the case, I would be interested to hear what particular portion of the text you are comfortable with, and what portion of the text you are uncomfortable with. What suggestions would you have for re-writes? I know that a small group of us discussed at length how to strike the right balance. It is possible that in our consideration of that balance we missed something, so your, and the rest of the community's input on this would certainly be welcomed. I think that this is an important topic that needs discussion, even if this petition is not sucessful. For the record I support this petition. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Mon, 27 Dec 2010, William Herrin wrote: |Date: Mon, 27 Dec 2010 09:17:34 -0500 |From: William Herrin |To: Chris Grundemann |Cc: arin-ppml at arin.net |Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient | Utilization of IPv4 Requires Dual-Stack | |On Wed, Dec 22, 2010 at 3:10 PM, Chris Grundemann wrote: |>4.1.4. IPv6 Deployment |> |>When addresses are used to provide an Internet facing service, the |>service must be fully IPv6 accessible (if you deploy an A record, you |>must also have a AAAA record, and both must answer). | |I DO NOT SUPPORT the petition to move proposal 125 forward. Although I |support the concept of requiring IPv6 deployment in order to continue |consuming IPv4 addresses, this particular proposal is gratuitously |heavy-handed. | |If a comparable proposal were brought forward which does not attempt |to micro-manage an organization's IPv6 deployment process, I would |support it and, if necessary support a petition to move it forward. | |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 Mon Dec 27 11:35:21 2010 From: bill at herrin.us (William Herrin) Date: Mon, 27 Dec 2010 11:35:21 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: On Mon, Dec 27, 2010 at 11:13 AM, Chris Grundemann wrote: > Supporting the petition to move this proposal forward could allow precisely > that discussion to take place. Chris, So could submitting a more modest proposal along the lines of: Organizations shall be ineligible to receive new IPv4 address allocations, assignments and transfers from ARIN unless: 1. The organization has previously received an IPv6 allocation or assignment from ARIN or another RIR, or 2. The organization demonstrates that it has deployed an IPv6 network continuously connected to the Internet. Try something along these lines and if the AC still drops the ball, I'll support your petition. Baby steps. Attempt the less intrusive approaches before considering the more intrusive ones. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Mon Dec 27 11:43:47 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 27 Dec 2010 08:43:47 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: <20101227164347.GA70716@ussenterprise.ufp.org> In a message written on Wed, Dec 22, 2010 at 01:10:58PM -0700, Chris Grundemann wrote: > 4.1.3. Dual-Stack > > Dual-stack refers to configuring both an IPv4 and an IPv6 address or > network together on the same network infrastructure. > > All new IPv4 addresses assigned, allocated or transfered to an > organization must be deployed on dual-stacked interfaces along with > IPv6 addresses. I strongly object to this petition for the same reason I objected to the original proposal, the dual stack requirement. I know there are folks who have deployed IPv6 enabled services by having all IPv4 stuff in one data center, and all IPv6 stuff in a second datacenter. Different servers, differennt load balancers, etc. These folks are good actors, as they are "fully IPv6 enabled" when accessing them over the Internet. This policy would punish them though for failing to deliver the service on the same "interface". I think a more generic proposal that required some level of IPv6 deployment without specific technologies (dual-stack) in it might win my support, but as-is, no way. -- 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 schiller at uu.net Mon Dec 27 12:16:01 2010 From: schiller at uu.net (Jason Schiller) Date: Mon, 27 Dec 2010 12:16:01 -0500 (EST) Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <20101227164347.GA70716@ussenterprise.ufp.org> References: <20101227164347.GA70716@ussenterprise.ufp.org> Message-ID: On Mon, 27 Dec 2010, Leo Bicknell wrote: |I strongly object to this petition for the same reason I objected |to the original proposal, the dual stack requirement. | |I know there are folks who have deployed IPv6 enabled services by |having all IPv4 stuff in one data center, and all IPv6 stuff in a |second datacenter. Different servers, differennt load balancers, |etc. These folks are good actors, as they are "fully IPv6 enabled" |when accessing them over the Internet. This policy would punish |them though for failing to deliver the service on the same "interface". Leo. This was certainly not my intention. I think the scenerio you describe is acceptable, but difficult to monitor for abuse. Assuming there were two data centers with a one for one corrolation between servers and services offered, but one data center was IPv4-only and one was IPv6-only, then I would support the position that an organization could get additional IPv4 addresses to continue to build-out their IPv4 data center (say for new customers) so long as they have parrellel growth (they also built-out and provisioned those same new customers) in the IPv6 data-center. This is why section 4.1.4 says "When addresses are used to provide an Internet facing service, the service must be fully IPv6 accessible (if you deploy an A record, you must also have a AAAA record, and both must answer)." I think we were envisioning 3 types of IP address uses for an organization: 1. For growth of your organization's network 2. For transit customers 3. For growth of an Internet facing server for your organization or customers of your organization The dual stacking requirement was intended to apply to the first two, to insure if your network's need for IPv4 continues to grow, or if your need for IPv4 adresses for transit customers continues to grow, that you actively deploy new customers with IPv4 and IPv6 capabilities, and begin moving IPv4-only customers to have IPv6 capabilities. I assumed it would be too costly to continue to have two seperate networks for IPv4 and IPv6 in the case of the first two, but after consideration of your email, it maybe should be something we make a provision for. __Jason | |I think a more generic proposal that required some level of IPv6 |deployment without specific technologies (dual-stack) in it might |win my support, but as-is, no way. | |-- | Leo Bicknell - bicknell at ufp.org - CCIE 3440 | PGP keys at http://www.ufp.org/~bicknell/ | From ppml at rs.seastrom.com Mon Dec 27 12:43:13 2010 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 27 Dec 2010 12:43:13 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: (William Herrin's message of "Mon, 27 Dec 2010 11:35:21 -0500") References: Message-ID: <8639pjkt72.fsf@seastrom.com> William Herrin writes: > So could submitting a more modest proposal along the lines of: > > Organizations shall be ineligible to receive new IPv4 address > allocations, assignments and transfers from ARIN unless: > > 1. The organization has previously received an IPv6 allocation or > assignment from ARIN or another RIR, or > 2. The organization demonstrates that it has deployed an IPv6 network > continuously connected to the Internet. It would appear that deploying an Apple Airport Extreme and ticking the 6to4 box would satisfy requirement #2. What is it exactly that you are trying to accomplish? > Try something along these lines and if the AC still drops the ball, > I'll support your petition. I must take issue with your suggestion that the AC "dropped the ball". The AC voted overwhelmingly to decline to accept a policy proposal onto the docket because (among other things) it artificially puts constraints on network architecture and deployment schedules (something ARIN never does), while representing a late and gratuitous change to IPv4 allocation policies. This is a matter of the Policy Development Process working exactly as designed. "Dropping the ball" suggests abrogation of responsibility or negligence, neither of which are exhibited here. I encourage you to continue working towards a concise and balanced proposal regarding v6 deployment as a prerequisite for v4 address space if you believe such a thing is necessary to accomplish some goal (which should be well-stated in the "rationale" section. In the same vein, I also encourage you to consider that the whole concept, while well-intentioned, is simply "made of fail" when it comes time to actually implement it. > Baby steps. Attempt the less intrusive approaches before considering > the more intrusive ones. Agree wholeheartedly. -r From frnkblk at iname.com Mon Dec 27 12:47:38 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 27 Dec 2010 11:47:38 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Message-ID: I would support a proposal that, as Leo described, "required some level of IPv6 deployment without specific technologies." One approach I considered would be apply to a significant surcharge (i.e. 1000%) for all those that didn't have IPv6 implemented. By applying a surcharge, fee schedules would not need to be adjusted. The problem with that is some companies might find the surcharge cheaper than actually deploying IPv6. The CFO might not like paying more, but if the cost of implementing IPv6 is more, they might grudgingly pay it. And there are also those companies where money is no real object but the drive to implement IPv6 is low if not non-existent. So I come full-circle back to the original proposal, which is "don't provide them IPv4 address space at all". For non-dualstacked shops, D-Day is just a few months earlier than everyone else. While that may appear punitive, why should someone else's lack of preparation result in my inability to obtain IPv4 address space? Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell Sent: Monday, December 27, 2010 10:44 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In a message written on Wed, Dec 22, 2010 at 01:10:58PM -0700, Chris Grundemann wrote: > 4.1.3. Dual-Stack > > Dual-stack refers to configuring both an IPv4 and an IPv6 address or > network together on the same network infrastructure. > > All new IPv4 addresses assigned, allocated or transfered to an > organization must be deployed on dual-stacked interfaces along with > IPv6 addresses. I strongly object to this petition for the same reason I objected to the original proposal, the dual stack requirement. I know there are folks who have deployed IPv6 enabled services by having all IPv4 stuff in one data center, and all IPv6 stuff in a second datacenter. Different servers, differennt load balancers, etc. These folks are good actors, as they are "fully IPv6 enabled" when accessing them over the Internet. This policy would punish them though for failing to deliver the service on the same "interface". I think a more generic proposal that required some level of IPv6 deployment without specific technologies (dual-stack) in it might win my support, but as-is, no way. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From bill at herrin.us Mon Dec 27 13:13:07 2010 From: bill at herrin.us (William Herrin) Date: Mon, 27 Dec 2010 13:13:07 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8639pjkt72.fsf@seastrom.com> References: <8639pjkt72.fsf@seastrom.com> Message-ID: On Mon, Dec 27, 2010 at 12:43 PM, Robert E. Seastrom wrote: > William Herrin writes: >> So could submitting a more modest proposal along the lines of: >> >> Organizations shall be ineligible to receive new IPv4 address >> allocations, assignments and transfers from ARIN unless: >> >> 1. The organization has previously received an IPv6 allocation or >> assignment from ARIN or another RIR, or >> 2. The organization demonstrates that it has deployed an IPv6 network >> continuously connected to the Internet. > > It would appear that deploying an Apple Airport Extreme and ticking > the 6to4 box would satisfy requirement #2. ?What is it exactly that > you are trying to accomplish? 2. The organization demonstrates that it has deployed a SUBSTANTIVE IPv6 network connected to the Internet. Better? >> Try something along these lines and if the AC still drops the ball, >> I'll support your petition. > > I must take issue with your suggestion that the AC "dropped the ball". Allow me to rephrase: IF the AC dumps even a modest proposal to tie continued eligibility for IPv4 to deployment of IPv6 THEN I would consider the AC to have dropped the ball and would therefore support a petition to override the AC's judgment. As it stands, I think the AC made the right call on proposal 125, hence I do not support the petition to move it forward to formal discussion. > In the same vein, I also encourage you to consider that the whole > concept, while well-intentioned, is simply "made of fail" when it > comes time to actually implement it. Maybe. My working assumption is that its a PIA to -get started- working with IPv6. Once started, enough folks will follow through to build up the critical mass needed to make it all happen. If that assumption is valid, then a proposal that merely requires folks to get started with their IPv6 deployment will get the job done. If that assumption proves wrong, then we might consider more forceful policy... but what do we lose trying the lighter hand first? 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 Mon Dec 27 14:40:39 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Dec 2010 11:40:39 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: <0BDC1AAC-6275-45B0-BA99-685C57C3113F@delong.com> The discussion can take place with or without moving this proposal forward. Owen On Dec 27, 2010, at 8:13 AM, Chris Grundemann wrote: > Hi Bill, > > Supporting the petition to move this proposal forward could allow precisely that discussion to take place. > > Cheers > ~Chris > > My Android sent this message. > > >> On Dec 27, 2010 7:17 AM, "William Herrin" wrote: >> >> On Wed, Dec 22, 2010 at 3:10 PM, Chris Grundemann wrote: >4.1.4. IPv6 Deploy... >> >> I DO NOT SUPPORT the petition to move proposal 125 forward. Although I >> support the concept of requiring IPv6 deployment in order to continue >> consuming IPv4 addresses, this particular proposal is gratuitously >> heavy-handed. >> >> If a comparable proposal were brought forward which does not attempt >> to micro-manage an organization's IPv6 deployment process, I would >> support it and, if necessary support a petition to move it forward. >> >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Dec 27 14:46:03 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Dec 2010 11:46:03 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: <8E6B6E57-A54C-4F36-A4D4-B2B2BC81640D@delong.com> On Dec 27, 2010, at 8:35 AM, William Herrin wrote: > On Mon, Dec 27, 2010 at 11:13 AM, Chris Grundemann > wrote: >> Supporting the petition to move this proposal forward could allow precisely >> that discussion to take place. > > Chris, > > So could submitting a more modest proposal along the lines of: > > Organizations shall be ineligible to receive new IPv4 address > allocations, assignments and transfers from ARIN unless: > s/and/or/ s/from ARIN// > 1. The organization has previously received an IPv6 allocation or > assignment from ARIN or another RIR, or > 2. The organization demonstrates that it has deployed an IPv6 network > continuously connected to the Internet. > Delete paragraph 1. What is the point of allowing one to bypass the requirement by merely acquiring a block of IPv6 addresses? > > Try something along these lines and if the AC still drops the ball, > I'll support your petition. > As an AC member who voted to abandon 125 and a very big supporter of IPv6 in general (as I believe most people are aware), I still do not believe on principle that ARIN should be attempting to force migration in this way and would not support such a proposal during the discussion, but, I would vote to bring it to the meeting. Further, if there were strong community consensus on the mailing list and/or at the meeting, I would vote for adoption. I would not be able to do so for 125 as I believe it is way too invasive. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppml at rs.seastrom.com Mon Dec 27 17:29:40 2010 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 27 Dec 2010 17:29:40 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: (William Herrin's message of "Mon, 27 Dec 2010 13:13:07 -0500") References: <8639pjkt72.fsf@seastrom.com> Message-ID: <86r5d2g88b.fsf@seastrom.com> William Herrin writes: >> I must take issue with your suggestion that the AC "dropped the ball". > > Allow me to rephrase: IF the AC dumps even a modest proposal to tie > continued eligibility for IPv4 to deployment of IPv6 THEN I would > consider the AC to have dropped the ball and would therefore support a > petition to override the AC's judgment. I don't think that phrase ("dropped the ball") means what you think it does. "Does the AC agree with Bill Herrin" is a question orthogonal to "Is the AC following the PDP". > As it stands, I think the AC > made the right call on proposal 125, hence I do not support the > petition to move it forward to formal discussion. Well, it's open for discussion as long as the community wants to discuss it. It's just not on the AC's docket. >> In the same vein, I also encourage you to consider that the whole >> concept, while well-intentioned, is simply "made of fail" when it >> comes time to actually implement it. > > Maybe. My working assumption is that its a PIA to -get started- > working with IPv6. Once started, enough folks will follow through to > build up the critical mass needed to make it all happen. If that > assumption is valid, then a proposal that merely requires folks to get > started with their IPv6 deployment will get the job done. If that > assumption proves wrong, then we might consider more forceful > policy... but what do we lose trying the lighter hand first? I do not believe this problem will be solved with policy. I believe that the economics of the transfer market vs. the equipment market will make the proper course of action crystal clear at the CxO level over the next couple of years and does not require policy action. -r From BillD at cait.wustl.edu Mon Dec 27 17:52:53 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 27 Dec 2010 16:52:53 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 EfficientUtilization of IPv4 Requires Dual-Stack References: <8639pjkt72.fsf@seastrom.com> <86r5d2g88b.fsf@seastrom.com> Message-ID: +1 -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Robert E. Seastrom Sent: Mon 12/27/2010 4:29 PM To: William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 EfficientUtilization of IPv4 Requires Dual-Stack William Herrin writes: > Maybe. My working assumption is that its a PIA to -get started- > working with IPv6. Once started, enough folks will follow through to > build up the critical mass needed to make it all happen. If that > assumption is valid, then a proposal that merely requires folks to get > started with their IPv6 deployment will get the job done. If that > assumption proves wrong, then we might consider more forceful > policy... but what do we lose trying the lighter hand first? I do not believe this problem will be solved with policy. I believe that the economics of the transfer market vs. the equipment market will make the proper course of action crystal clear at the CxO level over the next couple of years and does not require policy action. -r _______________________________________________ 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 frnkblk at iname.com Mon Dec 27 17:45:12 2010 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 27 Dec 2010 16:45:12 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <86r5d2g88b.fsf@seastrom.com> References: <8639pjkt72.fsf@seastrom.com> <86r5d2g88b.fsf@seastrom.com> Message-ID: It may not be _solved_ with policy, but at least those who meet whatever-definition-we-agree-on for "deployed IPv6" will get dibs on the remaining IPv4 address space. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert E. Seastrom Sent: Monday, December 27, 2010 4:30 PM To: William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack I do not believe this problem will be solved with policy. I believe that the economics of the transfer market vs. the equipment market will make the proper course of action crystal clear at the CxO level over the next couple of years and does not require policy action. -r _______________________________________________ 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 Mon Dec 27 18:06:42 2010 From: bill at herrin.us (William Herrin) Date: Mon, 27 Dec 2010 18:06:42 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <86y67ag89h.fsf@seastrom.com> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> Message-ID: On Mon, Dec 27, 2010 at 5:28 PM, Robert E. Seastrom wrote: > William Herrin writes: >>> I must take issue with your suggestion that the AC "dropped the ball". >> >> Allow me to rephrase: IF the AC dumps even a modest proposal to tie >> continued eligibility for IPv4 to deployment of IPv6 THEN I would >> consider the AC to have dropped the ball and would therefore support a >> petition to override the AC's judgment. > > I don't think that phrase ("dropped the ball") means what you think it > does. ?"Does the AC agree with Bill Herrin" is a question orthogonal > to "Is the AC following the PDP". Robert, You suggest that if the AC is in letter-compliance with the PDP then it automatically means that they're properly following through on policy proposals of interest to the community? Or do you just offer the ad-hominem argument that I can't distinguish between my personal opinion on a particular policy proposal versus the propriety of the AC's follow-though as it evaluates the degree of interest expressed by those participants who are not AC? In this particular case, I think the AC got it right on both counts: a strong policy-level linkage between IPv4 and IPv6 use is unhealthy (my opinion) AND few in the community have expressed a desire to see anything close to that heavy-handed a linkage between IPv4 and IPv6 implemented in ARIN policy. Shall we leave it there or do you really want to pick a fight? >I do not believe this problem will be solved with policy. I believe >that the economics of the transfer market vs. the equipment market >will make the proper course of action crystal clear at the CxO level >over the next couple of years and does not require policy action. I wouldn't bet money against that viewpoint. But for better or for worse I have observed a growing amount of community interest in some form of linking continued IPv4 availability to IPv6 use. If you're paying attention, you've noticed it too. Regards, Bill -- 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 Tue Dec 28 13:27:13 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 28 Dec 2010 10:27:13 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> Message-ID: <307B41E6-0611-4B24-9894-22143081A355@delong.com> > > >> I do not believe this problem will be solved with policy. I believe >> that the economics of the transfer market vs. the equipment market >> will make the proper course of action crystal clear at the CxO level >> over the next couple of years and does not require policy action. > > I wouldn't bet money against that viewpoint. But for better or for > worse I have observed a growing amount of community interest in some > form of linking continued IPv4 availability to IPv6 use. If you're > paying attention, you've noticed it too. In times of impending crisis, there is often community interest in all manner of bad actions motivated by a combination of steps in the grief process: fear, denial, anger, etc. Among these, the worst is fear and there is no shortage of fear in this situation. However, good leadership requires sifting through and moving beyond those factors to what is actually good policy. Limiting the last bread crumbs of IPv4 to those who have implemented (for some arbitrary definition of implemented) IPv6 is the policy equivalent of rearranging the deck chairs. It doesn't really do anything to help the community but it might keep some people occupied for a while so that they don't notice the water temperature until it reaches their necks. Owen From mysidia at gmail.com Tue Dec 28 14:02:45 2010 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 28 Dec 2010 13:02:45 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <20101227164347.GA70716@ussenterprise.ufp.org> References: <20101227164347.GA70716@ussenterprise.ufp.org> Message-ID: On Mon, Dec 27, 2010 at 10:43 AM, Leo Bicknell wrote: [snip] > I strongly object to this petition for the same reason I objected > to the original proposal, the dual stack requirement. This should be discussed further. It seems a fair criticism of the proposal as written at least. I would suggest the NRPM does not need to directly intervene and force a specific kind of network implementation; this is really nothing ARIN should be intervening in. The proposal could have referred to "dual stack services" or hosts instead of interfaces. There should not be an assumption that one interface equals one service or equals one hostname. Policy should not dictate that network technology using IPv6 addressing be deployed to the same scale or type as the IPv4 technology, because it is not always appropriate. IPv6 network deployments may be structured differently and require fewer V6 interfaces than interfaces on the V4 network. ARIN should not dictate that more IPv6 addresses or more IPv6 interfaces be used than required to match IPv4 service levels. e.g. There should not be "forced overbuild", in the name of promoting IPv6. Organizations can and should perform their own capacity planning. ARIN does not need to intervene directly, the org will do what is most suitable for themselves. For example, if a large org needs 500 web servers to answer billions of daily IPv4 queries, they don't need to be forced to get 500 dual stack or 500 extra IPv6 web servers to answer the 10 IPv6-based queries per day that are actually sent to them. Because that is expensive, inefficient, and a waste of addressing resources (addresses required by unneeded equipment). In that example, the organization should be able to have 2 IPv6 addresses to 500 IPv4 addresses in that case. I would suggest - for every 100 IPv4 addresses requested, at least one pre-existing interface is dual stacked, OR the IPv4 address' purpose is to provide at least one network service that is identical in purpose and content to a service available over IPv6. -- -JH From bill at herrin.us Tue Dec 28 14:10:42 2010 From: bill at herrin.us (William Herrin) Date: Tue, 28 Dec 2010 14:10:42 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <307B41E6-0611-4B24-9894-22143081A355@delong.com> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: On Mon, Dec 27, 2010 at 2:46 PM, Owen DeLong wrote: > On Dec 27, 2010, at 8:35 AM, William Herrin wrote: >> 1. The organization has previously received an IPv6 allocation or >> assignment from ARIN or another RIR, or > > Delete paragraph 1. What is the point of allowing one to bypass the > requirement by merely acquiring a block of IPv6 addresses? Hi Owen, IIRC, ARIN staff presented some numbers in Atlanta to the effect that only about a quarter of the folks using IPv4 addresses under an ARIN RSA had actually requested IPv6 addresses. I can think of a number of possible explanations but they largely imply the same thing: most of the key orgs on the Internet haven't taken the first step in their respective IPv6 deployments. The point of paragraph 1 is to get folks started. If folks get started and then choose to stop, that's another problem. But my thought is: let's try a solution to the problem we know for sure we have before we worry about the downstream problems we might have. > However, good leadership requires sifting through and moving beyond > those factors to what is actually good policy. Limiting the last bread > crumbs of IPv4 to those who have implemented (for some arbitrary > definition of implemented) IPv6 is the policy equivalent of rearranging > the deck chairs. It doesn't really do anything to help the community > but it might keep some people occupied for a while so that they don't > notice the water temperature until it reaches their necks. That's really a fundamental question here, isn't it? Do we want ARIN to lead or follow? If we want ARIN to -lead- towards the IPv6 solution that we, as engineers, consider technically superior to carrier NAT then it's past time to start gently nudging folks in that direction with our policy choices. It's no different than when the folks of their day said hey, CIDR's the new ball game, get used to it. If we want ARIN to -follow- then we should, as Robert says, let "the economics of the transfer market vs. the equipment market make the proper course of action crystal clear." Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Tue Dec 28 14:15:33 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 28 Dec 2010 11:15:33 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: <4D1A3755.5090909@rollernet.us> On 12/28/2010 11:10, William Herrin wrote: > On Mon, Dec 27, 2010 at 2:46 PM, Owen DeLong wrote: >> On Dec 27, 2010, at 8:35 AM, William Herrin wrote: >>> 1. The organization has previously received an IPv6 allocation or >>> assignment from ARIN or another RIR, or >> >> Delete paragraph 1. What is the point of allowing one to bypass the >> requirement by merely acquiring a block of IPv6 addresses? > > Hi Owen, > > IIRC, ARIN staff presented some numbers in Atlanta to the effect that > only about a quarter of the folks using IPv4 addresses under an ARIN > RSA had actually requested IPv6 addresses. I can think of a number of > possible explanations but they largely imply the same thing: most of > the key orgs on the Internet haven't taken the first step in their > respective IPv6 deployments. > I honestly don't think that most of those that haven't deployed or are actively working on IPv6 by now will will not bother until their next IPv4 request is denied due to runout (ISP) or they find themselves unable to access things on the internet they deem important (end user). ~Seth From lsawyer at gci.com Tue Dec 28 14:14:26 2010 From: lsawyer at gci.com (Leif Sawyer) Date: Tue, 28 Dec 2010 10:14:26 -0900 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <20101227164347.GA70716@ussenterprise.ufp.org> Message-ID: <18B2C6E38A3A324986B392B2D18ABC51F266DDD6@fnb1mbx01.gci.com> Jimmy Hess wrote: > in response to Leo Bicknell whom wrote: > [snip] >> I strongly object to this petition for the same reason I >> objected to the original proposal, the dual stack requirement. > > This should be discussed further. [snip] > IPv6 network deployments may be structured differently and > require fewer V6 interfaces than interfaces on the V4 network. [snip] > - for every 100 IPv4 addresses requested, at least one > pre-existing interface is dual stacked, OR the IPv4 address' > purpose is to provide at least one network service that is > identical in purpose and content to a service available over IPv6. This is an interesting quandry, and yet it does nothing to help service providors whom are at the mercy of vendors that have done nothing to support IPv6 within their equipement. "Buy new equipment" you say. Certainly, for a handful of routers, this is not an insurmountable task. But again, for service providors, what is the drawn line for replacing cablemodems or DSL modems? 10,000? 100,000? 1,000,000? And what about your mobile phone? Are you going to march down to AT&T, T-Mobile, Sprint, or any other carrier and demand that they hand over a shiny IPv6-capable phone? Can you find any within the US? I'd love for my Nexus One to support IPv6 (sure, the kernel -could-, but the rest of the stack doesn't) And what then of the Ericksson GSM stack? Do you expect them to forklift upgrade every GGSN, SSGN, and the rest of the infrastructure? If anything, it would be best served to have the condition be graceful and hopeful: At a minimum: IPv6 address space assigned and deployed to the core infrastructure, with either public facing services or test-only services active. From sethm at rollernet.us Tue Dec 28 15:03:22 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 28 Dec 2010 12:03:22 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC51F266DDD6@fnb1mbx01.gci.com> References: <20101227164347.GA70716@ussenterprise.ufp.org> <18B2C6E38A3A324986B392B2D18ABC51F266DDD6@fnb1mbx01.gci.com> Message-ID: <4D1A428A.4010501@rollernet.us> On 12/28/2010 11:14, Leif Sawyer wrote: > > And what about your mobile phone? Are you going to march down to > AT&T, T-Mobile, Sprint, or any other carrier and demand that they hand > over a shiny IPv6-capable phone? Can you find any within the US? > I'd love for my Nexus One to support IPv6 (sure, the kernel -could-, > but the rest of the stack doesn't) > Actually, for T-Mobile (beta) and Verizon LTE the answer is "yes" per a recent thread over on NANOG. ~Seth From ppml at rs.seastrom.com Tue Dec 28 16:32:15 2010 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Tue, 28 Dec 2010 16:32:15 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: (William Herrin's message of "Tue, 28 Dec 2010 14:10:42 -0500") References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: <8639phfusg.fsf@seastrom.com> William Herrin writes: > That's really a fundamental question here, isn't it? Do we want ARIN > to lead or follow? ARIN has been leading on IPv6 promotion for years, through outreach, fee abatement, and policies that make getting a v6 allocation only slightly more difficult than filling one's gas tank. Motion (of which there is an abundance in PP-125) should not be confused with progress. I expect to see plenty more proposals coming from various quarters regarding how to divvy up the last crumbs of IPv4 address space. I don't want to dissuade anyone from working on them, since this is an important exercise and a good proposal might come out of it, but I'm not sanguine about the prospects. Owen mentioned the deck chairs on the Titanic, an expression which is going to get used to the point of being a stock cliche in our community if it hasn't already. Let me offer another: the Dopeler Effect - bad ideas sound better when they come at you quickly. :-) I continue to be opposed to PP-125. -r From kkargel at polartel.com Tue Dec 28 16:40:26 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 28 Dec 2010 15:40:26 -0600 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8639phfusg.fsf@seastrom.com> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8639phfusg.fsf@seastrom.com> Message-ID: <8695009A81378E48879980039EEDAD288C048C42@MAIL1.polartel.local> I will join the fray as opposed to Prop 125. To my mind it is way to deep into mandating network operations. A registrar has no business defining network operations. ARIN is a registrar, not a standards body. Kevin Kargel From owen at delong.com Tue Dec 28 18:11:52 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 28 Dec 2010 15:11:52 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: On Dec 28, 2010, at 11:10 AM, William Herrin wrote: > On Mon, Dec 27, 2010 at 2:46 PM, Owen DeLong wrote: >> On Dec 27, 2010, at 8:35 AM, William Herrin wrote: >>> 1. The organization has previously received an IPv6 allocation or >>> assignment from ARIN or another RIR, or >> >> Delete paragraph 1. What is the point of allowing one to bypass the >> requirement by merely acquiring a block of IPv6 addresses? > > Hi Owen, > > IIRC, ARIN staff presented some numbers in Atlanta to the effect that > only about a quarter of the folks using IPv4 addresses under an ARIN > RSA had actually requested IPv6 addresses. I can think of a number of > possible explanations but they largely imply the same thing: most of > the key orgs on the Internet haven't taken the first step in their > respective IPv6 deployments. > > The point of paragraph 1 is to get folks started. If folks get > started and then choose to stop, that's another problem. But my > thought is: let's try a solution to the problem we know for sure we > have before we worry about the downstream problems we might have. > I don't believe merely requiring them to request IPv6 addresses will in any way motivate them to actually use them. I don't like these kinds of indirect attempts in law and I certainly don't want to start down that road in ARIN policy. If we want to require them to use IPv6, then, let's require them to use IPv6. > >> However, good leadership requires sifting through and moving beyond >> those factors to what is actually good policy. Limiting the last bread >> crumbs of IPv4 to those who have implemented (for some arbitrary >> definition of implemented) IPv6 is the policy equivalent of rearranging >> the deck chairs. It doesn't really do anything to help the community >> but it might keep some people occupied for a while so that they don't >> notice the water temperature until it reaches their necks. > > That's really a fundamental question here, isn't it? Do we want ARIN > to lead or follow? > I think ARIN has done a pretty good job of leading so far. However, perhaps it is important to consider the difference between leadership and management. ARIN is leading. ARIN should not be attempting to manage. Leadership is bringing the horse to water, which ARIN has most certainly done. Management is forcing him to drink, which generally tends not to end well. Proposal 125 sought to manage. > If we want ARIN to -lead- towards the IPv6 solution that we, as > engineers, consider technically superior to carrier NAT then it's past > time to start gently nudging folks in that direction with our policy > choices. It's no different than when the folks of their day said hey, > CIDR's the new ball game, get used to it. > I believe ARIN has been and continues to lead towards IPv6. > If we want ARIN to -follow- then we should, as Robert says, let "the > economics of the transfer market vs. the equipment market make the > proper course of action crystal clear." > First, I don't buy into your concept that "lead or follow" is somehow a binary choice. Good leadership operates at the consent of the people lead. I see nothing to indicate consent or consensus for ARIN to start trying to strong-arm IPv6. I believe external forces will drive that soon enough. People that have been paying attention are already moving on IPv6. Those that are not will not deploy it just because we hold the last few IPv4 addresses hostage for them obtaining an IPv6 allocation/assignment. That's like those "did you really mean to..." dialogues everyone just dismisses without reading on their computers. Owen From kkargel at polartel.com Tue Dec 28 18:47:06 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 28 Dec 2010 17:47:06 -0600 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> > > Good leadership operates at the consent of the people lead. I see > nothing to indicate consent or consensus for ARIN to start trying > to strong-arm IPv6. I believe external forces will drive that soon > enough. People that have been paying attention are already > moving on IPv6. Those that are not will not deploy it just because > we hold the last few IPv4 addresses hostage for them obtaining > an IPv6 allocation/assignment. That's like those "did you > really mean to..." dialogues everyone just dismisses without > reading on their computers. > > Owen > I must concur with Owen on all points. I have an IPv6 allocation, and I am fighting hard to get native IPv6 routing from my upstream(s). The only reason I can see to support 125 would be a completely selfish one in that I have predominantly met the requirements and that it would make the remaining pool more accessible to me because of the number of entities that would be disqualified from accessing it because they have not worked toward meeting the IPv6 requirements. I am not willing to put my selfish concerns ahead of the community. If it is desired to force one protocol by requiring another protocol as a pre-requisite, then there are more appropriate standards bodies to accomplish that than a registrar. (IETF? IEEE?) I suspect such an attempt within the standards bodies would be rejected out of hand as it should be here. Can you imagine any of the standards organizations accepting a proposal that says interfaces without an IPv6 address must not have an IPv4 address? Kevin From hannigan at gmail.com Tue Dec 28 19:35:34 2010 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 28 Dec 2010 19:35:34 -0500 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> Message-ID: On Tue, Dec 28, 2010 at 6:47 PM, Kevin Kargel wrote: >> [ snip ] > > Can you imagine any of the standards organizations accepting a proposal that says interfaces without an IPv6 address must not have an IPv4 address? > ARIN is not a standards body. Best, -M< From mysidia at gmail.com Tue Dec 28 20:20:45 2010 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 28 Dec 2010 19:20:45 -0600 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> Message-ID: On Tue, Dec 28, 2010 at 5:47 PM, Kevin Kargel wrote: > I must concur with Owen on all points. ?I have an IPv6 allocation, and I am fighting hard to get native IPv6 routing from my upstream(s). ?The only reason I can see to support 125 would be a completely selfish one in that I have predominantly met the requirements and that it would make the remaining pool more accessible to me because of the number of entities that would be disqualified from accessing it because they have not worked toward meeting the IPv6 requirements. They would be immediately working those requirements if they could see very clearly that at a future date they would be unable to get IP addresses due to not meeting those requirements. However.... ARIN should not necessarily dictate IPv6, only "something like IPv6". Any plan that acts like "IPv6 deployment" and reduces the need for future IPv4 addresses will do. Perhaps a proposal more along the lines of: "Obtain a delegation of IPv6 address space and utilize it on your network OR present an alternative plan to eliminate or reduce the need for future allocations of IPv4 address space on your network, and sign a commitment to return at least 50% of the newly allocated IPv4 allocation to ARIN within 5 years." -- -JH From tedm at ipinc.net Tue Dec 28 20:34:59 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 28 Dec 2010 17:34:59 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: <4D1A9043.4010801@ipinc.net> On 12/28/2010 3:11 PM, Owen DeLong wrote: > > > Good leadership operates at the consent of the people lead. I see > nothing to indicate consent or consensus for ARIN to start trying > to strong-arm IPv6. Hold on folks, this is getting out of hand. If ARIN wants to hand-out IPv6 along with an IPv4 request, who the hell cares? Requiring an org to spend a few moments estimating their future use of IPv6 when they request IPv4 is not going to take the skin off anyone's nose. It is by no means the same as requiring the org to actually USE the IPv6 We have enough IPv6 to hand out IPv6 to people who we are 95% sure will NEVER use it for the next century so this argument that we shouldn't just go ahead and assign the IPv6 even when an org doesn't want it is rubbish. Assign it! Sometime in the next 30 years they will need it and then hey, the assignment work will be done and they won't have to bug the RIR a second time and go through the whole justification process again. This is like when you go through the drive-through at McDonalds and they throw 4 ketchup packets in every bag that they hand out. Your like the guy who wants to make a federal case about the fact that you don't like ketchup so the 4 ketchup packets are going to go to waste because the drive through girl didn't take the time to ask you if you wanted ketchup or not. So your going to make the girl spend an extra 30 seconds ascertaining this to save a few ketchup packets for everyone who goes through the drive through, but there are 10 cars in line so the guy at the end is going to get his food 5 minutes late, and cold - just so you can pat yourself on the back and say you saved 5 ounces of IPv6 ketchup!!! Ted From mpetach at netflight.com Tue Dec 28 20:45:50 2010 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 28 Dec 2010 17:45:50 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: On Wed, Dec 22, 2010 at 12:10 PM, Chris Grundemann wrote: > The AC should not have abandoned ARIN-prop-125 Efficient Utilization > of IPv4 Requires Dual-Stack. I petition to move the following text > forward for discussion on the list and at the next Public Policy > Meeting. Please support moving this proposal forward now by posting > statements in support of the petition to this list. I do NOT support the proposal as worded; I do not think it is appropriate for the word MUST to be used in a policy such as this. You state that the intention of the policy is to "encourage IPv6 deployment" -- yet this is not encouragement, this is enforced compliance; this is not a guideline, this is an edict. I strongly recommend considering carefully the use of words such as "SHOULD" when writing proposals designed to encourage a behaviour, and reserve the use of "MUST" for cases only where absolutely needed; by using the word "MUST", you preclude any option for the ARIN staff to exercise judgment about the particulars of any request, and encourage entities to take half-baked measures to meet the rules, rather than taken a more measured and well-considered approach to deploying IPv6. I would rather an organization take an extra six months to roll v6 out correctly, than have them feel coerced to just throw a half-backed implementation up to get just enough ports pingable via v6 to meet the requirements which will then take them six more months to back out before they can move along towards a more reasonable implementation; ultimately, if the ISP has a bad experience trying to rush v6 out to meet a requirement like this, they're *less* likely to be willing to embrace it wholeheartedly in the future. Encouraging is good; dictating should be reserved only for those situations in which it is truly justified. Matt From dwhite at olp.net Tue Dec 28 22:32:21 2010 From: dwhite at olp.net (Dan White) Date: Tue, 28 Dec 2010 21:32:21 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: <20101229033221.GA29184@dan.olp.net> On 28/12/10?15:11?-0800, Owen DeLong wrote: >On Dec 28, 2010, at 11:10 AM, William Herrin wrote: >> On Mon, Dec 27, 2010 at 2:46 PM, Owen DeLong wrote: >>> On Dec 27, 2010, at 8:35 AM, William Herrin wrote: >>> However, good leadership requires sifting through and moving beyond >>> those factors to what is actually good policy. Limiting the last bread >>> crumbs of IPv4 to those who have implemented (for some arbitrary >>> definition of implemented) IPv6 is the policy equivalent of rearranging >>> the deck chairs. It doesn't really do anything to help the community >>> but it might keep some people occupied for a while so that they don't >>> notice the water temperature until it reaches their necks. >> >> That's really a fundamental question here, isn't it? Do we want ARIN >> to lead or follow? >> >I think ARIN has done a pretty good job of leading so far. However, >perhaps it is important to consider the difference between leadership >and management. ARIN is leading. ARIN should not be attempting >to manage. Leadership is bringing the horse to water, which ARIN >has most certainly done. Management is forcing him to drink, which >generally tends not to end well. Proposal 125 sought to manage. > >> If we want ARIN to -lead- towards the IPv6 solution that we, as >> engineers, consider technically superior to carrier NAT then it's past >> time to start gently nudging folks in that direction with our policy >> choices. It's no different than when the folks of their day said hey, >> CIDR's the new ball game, get used to it. >> >I believe ARIN has been and continues to lead towards IPv6. > >> If we want ARIN to -follow- then we should, as Robert says, let "the >> economics of the transfer market vs. the equipment market make the >> proper course of action crystal clear." >> >First, I don't buy into your concept that "lead or follow" is somehow >a binary choice. > >Good leadership operates at the consent of the people lead. I see >nothing to indicate consent or consensus for ARIN to start trying >to strong-arm IPv6. I believe external forces will drive that soon >enough. People that have been paying attention are already >moving on IPv6. Those that are not will not deploy it just because >we hold the last few IPv4 addresses hostage for them obtaining >an IPv6 allocation/assignment. That's like those "did you >really mean to..." dialogues everyone just dismisses without >reading on their computers. I agree with Owen, and in the context of ARIN leadership for IPv6 adoption, this model fits much better: A leader is best when people barely know that he exists. Less good when they obey and acclaim him. Worse when they fear and despise him. Fail to honor people, and they fail to honor you. But of a good leader, when his work is done, his aim fulfilled, they will say, "We did this ourselves." -Lao-Tzu *Good* IPv6 adoption will come from the bottom up, starting with engineers and techs in our respective organizations who see opportunity in crisis, and who are armed with the knowledge and tools to accomplish it. Top down enforcement from an external entity (ARIN) will tend toward poor implementations. -- Dan White From oberman at es.net Tue Dec 28 22:38:20 2010 From: oberman at es.net (Kevin Oberman) Date: Tue, 28 Dec 2010 19:38:20 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: Your message of "Tue, 28 Dec 2010 16:32:15 EST." <8639phfusg.fsf@seastrom.com> Message-ID: <20101229033820.275ED1CC16@ptavv.es.net> > From: "Robert E. Seastrom" > Date: Tue, 28 Dec 2010 16:32:15 -0500 > Sender: arin-ppml-bounces at arin.net > > > William Herrin writes: > > > That's really a fundamental question here, isn't it? Do we want ARIN > > to lead or follow? > > ARIN has been leading on IPv6 promotion for years, through outreach, > fee abatement, and policies that make getting a v6 allocation only > slightly more difficult than filling one's gas tank. > > Motion (of which there is an abundance in PP-125) should not be > confused with progress. > > I expect to see plenty more proposals coming from various quarters > regarding how to divvy up the last crumbs of IPv4 address space. I > don't want to dissuade anyone from working on them, since this is an > important exercise and a good proposal might come out of it, but I'm > not sanguine about the prospects. > > Owen mentioned the deck chairs on the Titanic, an expression which is > going to get used to the point of being a stock cliche in our > community if it hasn't already. Let me offer another: the Dopeler > Effect - bad ideas sound better when they come at you quickly. :-) > > I continue to be opposed to PP-125. Like several people on this list who have been long-time proponents of IPv6, I am opposed to PP-125, but I think this discussion is valuable. I have been working with IPv6 for well over a decade starting with the first IPv6 code from Sun and Digital and am really annoyed that so many have ignored it for too long, but PP-125 and similar proposals are really not likely to do any real good. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bill at herrin.us Tue Dec 28 22:39:39 2010 From: bill at herrin.us (William Herrin) Date: Tue, 28 Dec 2010 22:39:39 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: On Tue, Dec 28, 2010 at 6:11 PM, Owen DeLong wrote: > On Dec 28, 2010, at 11:10 AM, William Herrin wrote: >> That's really a fundamental question here, isn't it? Do we want ARIN >> to lead or follow? >> > I think ARIN has done a pretty good job of leading so far. However, > perhaps it is important to consider the difference between leadership > and management. ARIN is leading. ARIN should not be attempting > to manage. Leadership is bringing the horse to water, which ARIN > has most certainly done. Management is forcing him to drink, which > generally tends not to end well. Proposal 125 sought to manage. Owen, Leadership is not giving a motivational speech and then following the crowd to a pub, it's giving the speech and then drawing the crowd to one of the better pubs. Despite the name, a cheerleader is at best a cross between a dancer and a gymnast. Rah rah IPv6. At the core, ARIN is a resource manager. I have no problem with it taking a following role, moving where the market leads. Frankly, that strikes me as wise. But don't mistake it for leadership. If you want ARIN to show leadership with respect to IPv6 then however much they may have missed on the particulars, the prop 125 guys are on the right track. They just need to come back at it with an approach that's less poorly-conceived bullying and more firmly nudging people to take that next baby step in a healthy direction. > Good leadership operates at the consent of the people lead. I see > nothing to indicate consent or consensus for ARIN to start trying > to strong-arm IPv6. Building a consensus is leadership. Following the consensus is something else. Personally, it still doesn't make sense to me why we don't want the IPv4 form to have a checkbox which says, "give me my first minimum sized IPv6 block at no extra cost." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Tue Dec 28 22:43:50 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 28 Dec 2010 21:43:50 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Message-ID: Except there are willing engineers/tech that are unable to create movement within their organization towards IPv6. Like it or not, there are times when it's easier to wave a piece of paper (or an e-mail in this case) and tell ones' boss that we have to because the paper said, than try to make the case oneself. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dan White Sent: Tuesday, December 28, 2010 9:32 PM To: Owen DeLong; t at olp.net Cc: arin-ppml at arin.net; Robert E. Seastrom Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack *Good* IPv6 adoption will come from the bottom up, starting with engineers and techs in our respective organizations who see opportunity in crisis, and who are armed with the knowledge and tools to accomplish it. Top down enforcement from an external entity (ARIN) will tend toward poor implementations. -- Dan White _______________________________________________ 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 frnkblk at iname.com Tue Dec 28 22:49:09 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 28 Dec 2010 21:49:09 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Message-ID: If we set aside the carrot versus stick discussion that we're having, and the point that ARIN should stay out operational details, I still believe there's value in looking at it from a resource allocation perspective. ARIN makes, based on community-created policy, assessments about how much space is handed out and on what basis (i.e. HD factors). Why can't the level of IPv6 deployment play into the policy of the IPv4 assignment process? Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert E. Seastrom Sent: Tuesday, December 28, 2010 3:32 PM To: William Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack William Herrin writes: > That's really a fundamental question here, isn't it? Do we want ARIN > to lead or follow? ARIN has been leading on IPv6 promotion for years, through outreach, fee abatement, and policies that make getting a v6 allocation only slightly more difficult than filling one's gas tank. Motion (of which there is an abundance in PP-125) should not be confused with progress. I expect to see plenty more proposals coming from various quarters regarding how to divvy up the last crumbs of IPv4 address space. I don't want to dissuade anyone from working on them, since this is an important exercise and a good proposal might come out of it, but I'm not sanguine about the prospects. Owen mentioned the deck chairs on the Titanic, an expression which is going to get used to the point of being a stock cliche in our community if it hasn't already. Let me offer another: the Dopeler Effect - bad ideas sound better when they come at you quickly. :-) I continue to be opposed to PP-125. -r _______________________________________________ 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 dwhite at olp.net Tue Dec 28 23:11:07 2010 From: dwhite at olp.net (Dan White) Date: Tue, 28 Dec 2010 22:11:07 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: <20101229041107.GA29508@dan.olp.net> On 28/12/10?21:43?-0600, Frank Bulk - iName.com wrote: >Except there are willing engineers/tech that are unable to create movement >within their organization towards IPv6. Like it or not, there are times >when it's easier to wave a piece of paper (or an e-mail in this case) and >tell ones' boss that we have to because the paper said, than try to make the >case oneself. I guess I'm quite fortunate to be working for a company that doesn't operate like that. In an environment where internet technologies are dominating the traditional ILEC service provider landscape, management here seems to be quite eager to find out what kind of technical horizons we're going to have to deal with, and dealing with them sooner rather than later. It certainly helps to have good technical information to present to management - and the letter ARIN send out a while back was a great move. I still think that an organization is going to be better off by making grounded decisions in reality - and of course I'd like to think the tech folks have their ears closest to the tracks - than by ARIN telling organizations, via their tech folks, that they have to do it. -- Dan White From owen at delong.com Wed Dec 29 04:09:27 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Dec 2010 01:09:27 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D1A9043.4010801@ipinc.net> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <4D1A9043.4010801@ipinc.net> Message-ID: On Dec 28, 2010, at 5:34 PM, Ted Mittelstaedt wrote: > On 12/28/2010 3:11 PM, Owen DeLong wrote: >> >> >> Good leadership operates at the consent of the people lead. I see >> nothing to indicate consent or consensus for ARIN to start trying >> to strong-arm IPv6. > > Hold on folks, this is getting out of hand. > > If ARIN wants to hand-out IPv6 along with an IPv4 request, who the > hell cares? Requiring an org to spend a few moments estimating their > future use of IPv6 when they request IPv4 is not going to take the > skin off anyone's nose. It is by no means the same as requiring the > org to actually USE the IPv6 > > We have enough IPv6 to hand out IPv6 to people who we are 95% sure > will NEVER use it for the next century so this argument that we > shouldn't just go ahead and assign the IPv6 even when an org doesn't > want it is rubbish. Assign it! Sometime in the next 30 years they > will need it and then hey, the assignment work will be done and they > won't have to bug the RIR a second time and go through the whole > justification process again. > I disagree. It's simply not good resource management to hand resources out to people who don't want them and haven't expressed a need for them. It's very hard for us to claim we have needs based policy if we start allocating for reasons other than need. > This is like when you go through the drive-through at McDonalds and > they throw 4 ketchup packets in every bag that they hand out. Your Most of the McDonalds here have stopped doing that and now give you ketchup on request. > like the guy who wants to make a federal case about the fact that > you don't like ketchup so the 4 ketchup packets are going to go to > waste because the drive through girl didn't take the time to ask you > if you wanted ketchup or not. So your going to make the girl spend 1. I don't think it takes 30 seconds to ask "Ketchup?" and listen for a yes or no. It doesn't even take 30 seconds when I ask for bar-b-q sauce (which I like more than ketchup) when I go through the drive through. 2. IPv6 blocks are not ketchup packets. Nobody maintains any sort of registration data on ketchup packets. > an extra 30 seconds ascertaining this to save a few ketchup packets > for everyone who goes through the drive through, but there are 10 > cars in line so the guy at the end is going to get his food 5 minutes > late, and cold - just so you can pat yourself on the back and say > you saved 5 ounces of IPv6 ketchup!!! > It's more like 10 seconds or less, so, the guy 10 cars back loses by just over 1.5 minutes later than he might have otherwise. Most of this 10 seconds can be eliminated from relevance if the question takes place at the time of order or payment rather than after passing the food through the window. So... First, your statement is hyperbole even for the original subject. Second, it doesn't apply at all well to registered resources. The internet is not a happy meal and IPv6 blocks should not be the toy surprise in the IPv4 box. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Dec 29 04:17:16 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Dec 2010 01:17:16 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: <90EBBBF1-4AFA-4DB8-9593-B327EF5BE7A3@delong.com> On Dec 28, 2010, at 7:39 PM, William Herrin wrote: > On Tue, Dec 28, 2010 at 6:11 PM, Owen DeLong wrote: >> On Dec 28, 2010, at 11:10 AM, William Herrin wrote: >>> That's really a fundamental question here, isn't it? Do we want ARIN >>> to lead or follow? >>> >> I think ARIN has done a pretty good job of leading so far. However, >> perhaps it is important to consider the difference between leadership >> and management. ARIN is leading. ARIN should not be attempting >> to manage. Leadership is bringing the horse to water, which ARIN >> has most certainly done. Management is forcing him to drink, which >> generally tends not to end well. Proposal 125 sought to manage. > > Owen, > > Leadership is not giving a motivational speech and then following the > crowd to a pub, it's giving the speech and then drawing the crowd to > one of the better pubs. Despite the name, a cheerleader is at best a > cross between a dancer and a gymnast. Rah rah IPv6. > Agreed. Key is drawing them to the better pub, not tying them up, tossing them in the back of a truck and unloading them into the single pub of your choosing. > At the core, ARIN is a resource manager. I have no problem with it > taking a following role, moving where the market leads. Frankly, that > strikes me as wise. But don't mistake it for leadership. > I was more referring to AC leadership in the policy process rather than ARIN leadership in IPv6 originally. However... > If you want ARIN to show leadership with respect to IPv6 then however > much they may have missed on the particulars, the prop 125 guys are on > the right track. They just need to come back at it with an approach > that's less poorly-conceived bullying and more firmly nudging people > to take that next baby step in a healthy direction. > Perhaps. I'd need to see that policy proposal before I would comment on it. > >> Good leadership operates at the consent of the people lead. I see >> nothing to indicate consent or consensus for ARIN to start trying >> to strong-arm IPv6. > > Building a consensus is leadership. Following the consensus is something else. > Consent is not consensus. > > Personally, it still doesn't make sense to me why we don't want the > IPv4 form to have a checkbox which says, "give me my first minimum > sized IPv6 block at no extra cost." > May I suggest that you move to the APNIC region where you can, essentially, do just that or that you propose such a policy in the ARIN region. I don't have a problem with simplifying the request process. I do have a problem with the "Give them address space they didn't ask for" approach being advocated by some. Owen From ppml at rs.seastrom.com Wed Dec 29 07:12:06 2010 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Wed, 29 Dec 2010 07:12:06 -0500 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <20101229041107.GA29508@dan.olp.net> (Dan White's message of "Tue, 28 Dec 2010 22:11:07 -0600") References: <20101229041107.GA29508@dan.olp.net> Message-ID: <86hbdwkcbt.fsf@seastrom.com> Dan White writes: > It certainly helps to have good technical information to present to > management - and the letter ARIN send out a while back was a great move. I > still think that an organization is going to be better off by making > grounded decisions in reality - and of course I'd like to think the tech > folks have their ears closest to the tracks - than by ARIN telling > organizations, via their tech folks, that they have to do it. Since you found the original letter helpful, what would be your thoughts on an additional round of letters on the occasion of free pool runout? The costs are not trivial if they are sent to people at the corporate officer level not people in the database as org or resource contacts (in the former case there is a need to verify, via D&B or whoever, that you're sending to the right folks)... but would this be worthwhile? -r From frnkblk at iname.com Wed Dec 29 09:14:27 2010 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 29 Dec 2010 08:14:27 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <86hbdwkcbt.fsf@seastrom.com> References: <20101229041107.GA29508@dan.olp.net> <86hbdwkcbt.fsf@seastrom.com> Message-ID: A second round of communication could only be beneficial. I'm not sure it has to be targeted to the CxO level -- if it's sent to the tech, a nameless version written for CxO's could be included, for the tech to forward internally to the appropriate CxO. Frank -----Original Message----- From: Robert E. Seastrom [mailto:rs at seastrom.com] On Behalf Of Robert E. Seastrom Sent: Wednesday, December 29, 2010 6:12 AM To: Dan White Cc: Frank Bulk - iName.com; arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Dan White writes: > It certainly helps to have good technical information to present to > management - and the letter ARIN send out a while back was a great move. I > still think that an organization is going to be better off by making > grounded decisions in reality - and of course I'd like to think the tech > folks have their ears closest to the tracks - than by ARIN telling > organizations, via their tech folks, that they have to do it. Since you found the original letter helpful, what would be your thoughts on an additional round of letters on the occasion of free pool runout? The costs are not trivial if they are sent to people at the corporate officer level not people in the database as org or resource contacts (in the former case there is a need to verify, via D&B or whoever, that you're sending to the right folks)... but would this be worthwhile? -r From bicknell at ufp.org Wed Dec 29 10:37:41 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 29 Dec 2010 07:37:41 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> Message-ID: <20101229153741.GA27989@ussenterprise.ufp.org> In a message written on Tue, Dec 28, 2010 at 10:39:39PM -0500, William Herrin wrote: > If you want ARIN to show leadership with respect to IPv6 then however > much they may have missed on the particulars, the prop 125 guys are on > the right track. They just need to come back at it with an approach > that's less poorly-conceived bullying and more firmly nudging people > to take that next baby step in a healthy direction. Even if Prop125 is tweaked to be "perfect" there is still a timing issue. Given where we are in the timeline even if it passes the emergency process and is implemented fairly quickly by ARIN it will be in place for well under 12 months of normal IPv4 allocations, and quite likely less than 6 months. Rather than provide an incentive to the entire industry to do something useful it's going to have maximum impact on a small group of people who happen to be (un)lucky enough to request more IPv4 space during that time. Some might argue that it will "live on" with the transfer market, but that really makes no sense to me. One of the largest arguments in favor of the transfer market was to provide an out to people who couldn't do IPv6 for some reason. Maybe some org would find it cheaper to throw a million dollars at IPv4 than do IPv6, and the transfer market both gave them a way to do that and a way for us to show the rest of the community IPv4 now cost a million dollars. If Prop125 applies to the transfer market we're throwing IPv6 at the people we've already self selected that can't do it. I have a lot of trouble with that logic. -- 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 Wed Dec 29 12:09:16 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Dec 2010 09:09:16 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: <6593C02B-E3E9-4076-B2EB-0DA28E819554@delong.com> Because there isn't enough IPv4 left to do so meaningfully by the time such a policy came to consensus. If we had come to consensus on something of this nature a year ago, we might have been able to do something useful. At this point, we're past that point. Whatever policy we make will only increase the pain for some random subset of organizations while making a very slight reduction in it for other organizations. Last year and the year before, the community made pretty clear conscious decisions not to do so. We decided to ride current IPv4 policy into the end zone. Changing course now is like trying to turn a jet inside a narrow canyon because we can see the end and we can't out climb it. We might be able to change where we hit the wall, but, we can't avoid the wall. Owen On Dec 28, 2010, at 7:49 PM, Frank Bulk - iName.com wrote: > If we set aside the carrot versus stick discussion that we're having, and > the point that ARIN should stay out operational details, I still believe > there's value in looking at it from a resource allocation perspective. ARIN > makes, based on community-created policy, assessments about how much space > is handed out and on what basis (i.e. HD factors). Why can't the level of > IPv6 deployment play into the policy of the IPv4 assignment process? > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Robert E. Seastrom > Sent: Tuesday, December 28, 2010 3:32 PM > To: William Herrin > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient > Utilization of IPv4 Requires Dual-Stack > > > William Herrin writes: > >> That's really a fundamental question here, isn't it? Do we want ARIN >> to lead or follow? > > ARIN has been leading on IPv6 promotion for years, through outreach, > fee abatement, and policies that make getting a v6 allocation only > slightly more difficult than filling one's gas tank. > > Motion (of which there is an abundance in PP-125) should not be > confused with progress. > > I expect to see plenty more proposals coming from various quarters > regarding how to divvy up the last crumbs of IPv4 address space. I > don't want to dissuade anyone from working on them, since this is an > important exercise and a good proposal might come out of it, but I'm > not sanguine about the prospects. > > Owen mentioned the deck chairs on the Titanic, an expression which is > going to get used to the point of being a stock cliche in our > community if it hasn't already. Let me offer another: the Dopeler > Effect - bad ideas sound better when they come at you quickly. :-) > > I continue to be opposed to PP-125. > > -r > > _______________________________________________ > 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 cgrundemann at gmail.com Wed Dec 29 12:15:47 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 29 Dec 2010 10:15:47 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D125FAE.3050307@arin.net> References: <4D125FAE.3050307@arin.net> Message-ID: I find it very interesting the tone and attitude that a couple of folks have taken wrt prop-125. Those folks seem to want us to believe that this policy somehow forces everyone (or anyone for that matter) to adopt IPv6. Statements such those immediatly below seem to illustrate the propegation of this misconception: "Top down enforcement from an external entity (ARIN) will tend toward poor implementations." "...dictating should be reserved only for those situations in which it is truly justified." "...tying them up,tossing them in the back of a truck and unloading them into the single pub of your choosing." While this proposal does reward those who have deployed IPv6, the simple fact is that even if we (the community) wanted it (I don't think we do), ARIN could never force anyone to adopt IPv6. As stated in the rational, this proposal has three objectives: To encourage IPv6 deployment prior to and post depletion, to enable growth of IPv4 to accelerate IPv6 transition and to improve the utilization of IP addresses. It appears to me that a few folks are focusing on (and exaggerating) the first without due consideration for the other two objectives. The reality of our situation is that the (vast) majority of ARIN resource registrants have already received their last free/normal allocation or assignment from ARIN. The IANA will hand out the remaining free pool v4/8s within weeks, if not sooner. ARIN will hand out it's remaining reserves in less than a year. All of this means that most organizations will never receive more IPv4 addresses directly from ARIN ever again and there is nothing we can do to change that (without fairly disastrous side effects). This leaves us in a situation where a relatively small number of organizations will be queuing up for an even smaller number of IPv4 addresses. Questions must be raised in situations like this, questions regarding need, efficient utilization and stewardship. Some of these questions are already being answered by ARIN staff. As we dive deeper into free pool exhaustion, resource reviews are getting stricter, it is becoming harder to justify new IPv4 addresses, audits are more common, etc. All of this is guided by community built policy and therefor I believe that we should ask ourselves some of these questions as well, rather than leaving it all on the shoulders of ARIN staff. We have tried to answer many of these questions with prop-125: We as a community and ARIN as an organization have been beating the IPv6 drum for years, why not reward the folks who answered our call and actually deployed IPv6? Why not ensure that the remaining IPv4 addresses are used to build truly sustainable infrastructure? Why allow scarce and valuable IPv4 addresses to be wasted on legacy equipment, in legacy networks? I think that too many people look at address policy (and many other things for that matter) very selfishly. Lots of folks are trying to find ways to meet their own needs and make their own lives easier. Many more only look at policy from their own singular perspective and thus only see trees. This policy attempts to zoom out, look at the forest and from this holistic perspective make decisions regarding what is best for the entire community and all of the industries and economies represented within it. When looking at the big picture it becomes clear that at this stage, IPv4 addresses that are not deployed alongside of IPv6 are being wasted. The only question that remains is if we can step up, look past our own personal difficulties and do the right thing for the Internet. Please make your voice heard and speak up in support of this policy! $0.02 ~Chris PS - There has been another argument, that not everyone will/should/can dual stack and that someone who deploys a parallel IPv6 network should not be left out of the rewards of deploying production IPv6. I completely agree. I am more than willing to help revise the text of this proposal to include that scenario once the petition succeeds, if not sooner. I think that these mechanical details will all be fairly trivial to work out once the petition succeeds. On Wed, Dec 22, 2010 at 13:29, ARIN wrote: > The message below started a petition regarding the ARIN Advisory > Council's decision to abandon "ARIN-prop-125 Efficient Utilization of > IPv4 Requires Dual-Stack". The AC's decision was posted by ARIN staff to > PPML on 21 December 2010. > > If successful, this petition will change ARIN-prop-125 into a Draft > Policy which will be published for adoption discussion on the PPML and > at the Public Policy Meeting in April. If the petition fails, the > proposal will be closed. > > For this petition to be successful, the petition needs statements of > support from at least 10 different people from 10 different > organizations. If you wish to support this petition, post a statement of > support to PPML on this thread. > > The duration of the petition is until five business days after the AC's > draft meeting minutes are published. ARIN staff will post the result of > the petition to PPML. > > For more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and 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, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ##### > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Chris Grundemann >> Sent: Wednesday, December 22, 2010 3:11 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient >> Utilization of IPv4 Requires Dual-Stack >> >> The AC should not have abandoned ARIN-prop-125 Efficient Utilization >> of IPv4 Requires Dual-Stack. I petition to move the following text >> forward for discussion on the list and at the next Public Policy >> Meeting. Please support moving this proposal forward now by posting >> statements in support of the petition to this list. >> >> ### >> >> Policy Statement: >> >> * Add the following sections to section 4.1: >> >> 4.1.2. Efficient Utilization >> >> IPv4 addresses are a finite resource and as such are required to be >> efficiently utilized by resource holders in order to maximize their >> benefit to the community. >> >> 4.1.3. Dual-Stack >> >> Dual-stack refers to configuring both an IPv4 and an IPv6 address or >> network together on the same network infrastructure. >> >> All new IPv4 addresses assigned, allocated or transfered to an >> organization must be deployed on dual-stacked interfaces along with >> IPv6 addresses. >> >> 4.1.4. IPv6 Deployment >> >> When addresses are used to provide an Internet facing service, the >> service must be fully IPv6 accessible (if you deploy an A record, you >> must also have a AAAA record, and both must answer). >> >> * Add the following sentance to the end of sections 4.2.1.6, >> 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4: >> >> In accordance with section 4.1.3 and 4.1.4, all new addresses must be >> deployed on dual-stacked interfaces and all Internet facing services >> provided by new addresses must be fully IPv6 accessible. >> >> * Re-write section 4.2.3.4.1. to: >> >> Reassignment information for prior allocations must show that each >> customer meets the 80% utilization criteria, the dual-stack criteria >> and must be available via SWIP / RWhois prior to your issuing them >> additional space. >> >> * Add the following section to section 4.2.4: >> >> 4.2.4.5. IPv6 Deployment >> >> In order to receive additional space ISPs must provide detailed >> documentation demonstrating that: >> ?- for every IPv4 address requested, at least one pre-existing >> interface is dual stacked, up to 80% of all interfaces and >> ?- for every down stream customer site where the new addresses will be >> deployed, at least one pre-existing down stream customer site is IPv6 >> enabled, up to 80% of the total customer base. >> >> * Add the following to section 4.3.6: >> >> 4.3.6.3. IPv6 Deployment >> >> In order to receive additional space end-users must provide detailed >> documentation demonstrating that at least 80% of their existing IPv4 >> addresses are deployed on dual-stacked interfaces in accordance with >> section 4.1.3. >> >> Rational: >> >> In this period of available IPv4 address scarcity and transition to >> IPv6, IPv4 addresses that are not deployed along with IPv6 are simply >> not being efficiently utilized. Although we have likely failed to >> deploy dual-stack in a meaningful way in time to avoid transition >> problems, we can still choose the correct path for future assignments, >> allocations and transfers. >> >> This proposal has three objectives: >> -1- Encourage IPv6 deployment prior to and post depletion >> -2- Enable growth of IPv4 to accelerate IPv6 transition #[only change >> was to this line]# >> -3- Improve the utilization of IP addresses >> >> It accomplishes these goals by enforcing three basic ideals: >> -1- ARIN will only make allocations and assignments for networks that >> have already deployed production IPv6 >> -2- Any new IPv4 addresses received, must be deployed along side of >> IPv6 (dual-stacked) >> -3- Firmly encourages deployment of IPv6 in existing IPv4-only networks >> >> The specific requirements to be enforced can be summed up in this way: >> ~ New addresses must be deployed on dual-stacked interfaces plus one >> additional pre-existing IPv4-only interface must be dual-stacked per >> new address, up to 80% of all interfaces. >> ~ For each down stream customer site where these addresses are >> deployed, another pre-existing IPv4 only down stream site must also be >> IPv6 enabled, up to 80% of the total customer base. >> ~ All end-sites must dual-stack before getting new space. >> ~ Internet facing services that new IPv4 addresses are used to provide >> must be fully IPv6 accessible. >> >> ### >> >> Chris Grundemann >> www.theIPv6experts.net >> chris at theIPv6experts.net > > _______________________________________________ > 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.theIPv6experts.com www.coisoc.org From bicknell at ufp.org Wed Dec 29 12:30:36 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 29 Dec 2010 09:30:36 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> Message-ID: <20101229173036.GA34707@ussenterprise.ufp.org> Your message articulates a fork in the road. The first path is the path that was argued back with the transfer policy. Some folks won't deploy IPv6 for various reasons, for instance their vendor is 6 months from giving them support on their platform, or their capital budget doesn't let them upgrade the hardware until the next fiscal year. The idea was to give these folks who had real impediments to IPv6 access to IPv4 so they were not dead in the water. The second path is the path you are arguing with PP125. Faced with decreasing IPv4 stocks we should choose to give them to the folks who are already fully IPv6 enabled and embracing the future, rewarding them for their early adoption and forward thinking. Those who can't do IPv4 should be left behind at this point, they missed the bus and it's no longer worth throwing good resources at people who just aren't going to make it. It also illustrates the problem I have with the policy. If we apply PP125 to the transfer market, I feel that we effectively nullify the potential usefulness of that market. While I was never in favor of transfers because I did not think they would do enough good to outweigh the harm, I do believe that those who argued for it were standing on a solid footing. In this case I think PP125 is just too late to the party, so I'm in favor of sticking with the status quo. That said, if we adopt PP125 I think it renders the transfer market nearly useless for it's intended goals, almost to the point where it is worth considering repealing specified transfers if PP125 were to pass. This policy needed to come up at the same time as the transfer proposal, so we could debate the two forks. However, we chose one with the transfer mess and have started down that road, to take the other fork now means to back up a significant distance and go in another direction. -- 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 Dec 29 13:04:56 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 29 Dec 2010 11:04:56 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <20101229173036.GA34707@ussenterprise.ufp.org> References: <4D125FAE.3050307@arin.net> <20101229173036.GA34707@ussenterprise.ufp.org> Message-ID: I generally agree with you, with a couple exceptions - noted in-line below. On Wed, Dec 29, 2010 at 10:30, Leo Bicknell wrote: > > Your message articulates a fork in the road. > > The first path is the path that was argued back with the transfer > policy. ?Some folks won't deploy IPv6 for various reasons, for > instance their vendor is 6 months from giving them support on their > platform, or their capital budget doesn't let them upgrade the > hardware until the next fiscal year. ?The idea was to give these > folks who had real impediments to IPv6 access to IPv4 so they were > not dead in the water. > > The second path is the path you are arguing with PP125. ?Faced with > decreasing IPv4 stocks we should choose to give them to the folks > who are already fully IPv6 enabled and embracing the future, rewarding > them for their early adoption and forward thinking. ?Those who can't > do IPv4 should be left behind at this point, they missed the bus > and it's no longer worth throwing good resources at people who just > aren't going to make it. prop-125 does not require an org to be fully IPv6 enabled. It allows an org to get an equivalent amount of IPv4 to the IPv6 that they have deployed. This means that any org that deploys IPv6 in even part of their network has access to new IPv4. Perhaps an org can dual-stack their backbone but not their DSLAMs, or their servers, (or only some servers/head-ends/etc.) that org can still get some IPv4 under this policy. > It also illustrates the problem I have with the policy. ?If we apply > PP125 to the transfer market, I feel that we effectively nullify > the potential usefulness of that market. ?While I was never in favor > of transfers because I did not think they would do enough good to > outweigh the harm, I do believe that those who argued for it were > standing on a solid footing. To avoid redundancy on the list, see this previous post for my general sentiment regarding applying this policy to transfers: http://lists.arin.net/pipermail/arin-ppml/2010-December/019061.html > In this case I think PP125 is just too late to the party, so I'm > in favor of sticking with the status quo. ?That said, if we adopt > PP125 I think it renders the transfer market nearly useless for > it's intended goals, almost to the point where it is worth considering > repealing specified transfers if PP125 were to pass. > > This policy needed to come up at the same time as the transfer proposal, > so we could debate the two forks. ?However, we chose one with the > transfer mess and have started down that road, to take the other fork > now means to back up a significant distance and go in another direction. While I agree that this policy would have been more ideally proposed (much) earlier, I think that skipping it now because no one thought of it (or how to do it) earlier is a misstep as well. ~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.theIPv6experts.com www.coisoc.org From matthew at matthew.at Wed Dec 29 13:07:43 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 29 Dec 2010 10:07:43 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> Message-ID: <4D1B78EF.9020402@matthew.at> On 12/29/2010 9:15 AM, Chris Grundemann wrote: > > We have tried to answer many of these questions with prop-125: > We as a community and ARIN as an organization have been beating the > IPv6 drum for years, why not reward the folks who answered our call > and actually deployed IPv6? That's a great idea, but a "reward" might be something like "reduced IPv4 fees" and not "you can get addresses at all". > Why not ensure that the remaining IPv4 addresses are used to build > truly sustainable infrastructure? It might be reasonable to reserve some of the remaining IPv4 addresses for this, but it isn't reasonable to prevent transfers that fulfill other needs and it might not be reasonable to reserve *all* of the remaining IPv4 addresses for this either. > Why allow scarce and valuable IPv4 addresses to be wasted on legacy > equipment, in legacy networks? Because when you say "wasted" you're making a very strong value judgment that isn't supported. Is it more valuable for your ISP to be able to add more SSL-protected porn sites than it is for my ISP to be able to add more river flood stage monitors for the local government? We don't know... and so we don't know that serving a small addition to a legacy equipment network that won't do IPv6 is "wasted" or not. Is my previous example of providing access to legacy computer hardware and operating systems for research a "waste" as well? We don't know that either. So we shouldn't presuppose it is. > > When looking at the big picture it becomes clear that at this stage, > IPv4 addresses that are not deployed alongside of IPv6 are being > wasted. No it isn't at all clear. *Some* IPv4 addresses that are not being deployed alongside of IPv6 are happening because people don't want to make the effort to switch their services to being able to serve the growing IPv6 Internet... and some IPv4 addresses that are not being deployed alongside of IPv6 are happening for *very good reasons*. And those will continue long past the point where ARIN runs out. Should we reserve some addresses for infrastructure needed to support the transition? Probably, and I believe that's already been done. Should we change policies right at the end in order to reserve a whole lot more addresses for transition? Probably not. Should we make it impossible for people who need IPv4 and only IPv4 for very good reasons to obtain those via a transfer mechanism? Definitely not. > PS - There has been another argument, that not everyone > will/should/can dual stack and that someone who deploys a parallel > IPv6 network should not be left out of the rewards of deploying > production IPv6. I completely agree. I am more than willing to help > revise the text of this proposal to include that scenario once the > petition succeeds, if not sooner. I think that these mechanical > details will all be fairly trivial to work out once the petition > succeeds. This is a ridicuous requirement that again presupposes "what public IP addresses are for". Should my local flood control district be required to set up a big IPv6 network that they don't use just to impress you with their knowledge of IPv6? Perhaps we should just limit future IPv4 assignments and transfers to people who've got their "Commercial IPv6 Drivers License". Matthew Kaufman From matthew at matthew.at Wed Dec 29 12:55:48 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 29 Dec 2010 09:55:48 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <20101229173036.GA34707@ussenterprise.ufp.org> References: <4D125FAE.3050307@arin.net> <20101229173036.GA34707@ussenterprise.ufp.org> Message-ID: <4D1B7624.9040903@matthew.at> On 12/29/2010 9:30 AM, Leo Bicknell wrote: > > It also illustrates the problem I have with the policy. If we apply > PP125 to the transfer market, I feel that we effectively nullify > the potential usefulness of that market. While I was never in favor > of transfers because I did not think they would do enough good to > outweigh the harm, I do believe that those who argued for it were > standing on a solid footing. > > In this case I think PP125 is just too late to the party, so I'm > in favor of sticking with the status quo. That said, if we adopt > PP125 I think it renders the transfer market nearly useless for > it's intended goals,... > I agree completely with this analysis which captured exactly what I was about to point out. This proposal takes a very narrow view of "what additional public IP addresses are for", namely "adding public facing (web) servers" and "adding downstream customers". There's all sorts of networks which need public address space and for which *only* IPv4 is appropriate. Blocking them from getting IPv4 addresses from ARIN during the end-game is probably wrong, and blocking them from getting IPv4 addresses via a transfer mechanism is definitely wrong. As an extreme example, let us suppose the existence of the Distributed Legacy Computing Museum... a museum with dozens of facilities around the country in which computers and operating systems which never had and never will have IPv6 capabilities are on display and in operation and perhaps even reachable from the outside over IPv4 for interested researchers. What do they do when they acquire 100 additional surplus machines they wish to place on the network? (Answer: Get more IPv4 space from a transfer market or even a transfer in the form of a donation, perhaps. Or if they plan ahead, why not get them from ARIN next month?) If every IPv4 address they have now has a historical machine plugged in and operating associated with it, why wouldn't that be "efficient utilization"? Similar cases exist for sensor networks that are in operation that want to add another hundred identical IPv4-only sensors over the next 10 years and after the 10 years have a plan to switch to newer IPv6-capable sensors, etc. Matthew Kaufman From hannigan at gmail.com Wed Dec 29 13:52:48 2010 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 29 Dec 2010 13:52:48 -0500 Subject: [arin-ppml] PP 124 Preliminary Info Was: Re: Advisory Council Meeting Results - December 2010 Message-ID: Folks, I'm preparing the petition for PP 124 and wanted to post a reminder and the revised text for 124 prior to the petition. I'd like to request that the ARIN staff please provide an accurate condition of current inventory including all address space, reserves, holds, etc. Best, Martin ### snarf ### Policy Proposal ARIN-prop-124 Clarification of Section 4.2.4.4 Proposal Originator: Martin Hannigan, Chris Grundemann Proposal Version: 2 Date: 13 December 2010 Proposal type: Modify, complete replacement of 4.2.4.4 Policy term: Permanent Policy statement: 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, that organization may choose to request up to a 12 month supply of IP addresses. On the date that ARIN receives its last /8 as a result of the IANA executing section 10.4.2.2 of the NRPM and in accordance with the Global Policy for the Allocation of the Remaining IPv4 Address Space, the length of supply that any organization may request from ARIN from that moment forward will be reduced to three months. Any request submitted prior to that moment will continue to be eligible for a twelve month supply of IPv4 addresses as long as need has been reasonably demonstrated and the application is not deemed frivolous. This reduction does not apply to resources received through the utilization of NRPM Section 8.3 of the NRPM. An organization receiving a transfer under NRPM Section 8.3 may continue to request up to a 12-month supply of IP addresses. Rationale: ARIN's pending operational practice is that if an organization has a request in the ARIN hostmaster queue for IPv4 resources when the IANA declares the exhaustion phase (10.4.2.2), their request will be automatically truncated from a twelve month supply to a three month supply since policy in effect at the time of exhaustion will apply. 8.3 and 4.2.4.4 are currently "in effect". Example: If an entity is asking for 4 x /24 for a 12 month period and IANA exhaustion occurs, a requester will receive, if justified, 1 x /24. If an entity is asking for 120 x /24 at the time that exhaustion occurs, they would only receive 30 x /24 if justified. If ARIN determines that this same entity would only qualify for 90 of the 120 x /24 requested, then that entity would only receive 22 x /24. ARIN has the equivalent of almost a /8 in at least one reserve, has recently received 2 /8's, received ~391 x /16's as a result of the distribution of "various registries" from the IANA and is guaranteed to receive at least one additional /8 (aggregate of about 92 million individual IPv4 addresses) as a result of the execution of 10.4.2.2 by the IANA. Considering the size of the supply, it would seem prudent to provide for all members needs in a fair and consistent manner as long as possible in order to support the continued orderly transition of the Internet to IPv6. The intention of this proposal is simple. To allow resource requests in the application queue that have provided an application that has a reasonable chance of success the opportunity to complete the process and receive transition addresses. The ARIN AC should review and determine what action if any should be taken at their next available opportunity, or sooner if they deem warranted. On Thu, Dec 23, 2010 at 2:16 PM, Martin Hannigan wrote: > > To insure that there are no surprises, I want to let folks know that I am going to petition PP124. > > If there isn't already a method to insure tracking of requests in the resource request queue that would be impacted by 124, something would be warranted just in case 124 succeeds. > > > Best, > > -M< > > Sent from my iPad > > On Dec 21, 2010, at 12:14 PM, ARIN wrote: > >> In accordance with the ARIN Policy Development Process (PDP), the ARIN >> Advisory Council (AC) held a meeting on 16 December 2010 and made >> decisions about several draft policies and proposals. >> >> After last call the AC recommended that the ARIN Board of Trustees adopt >> the following draft policy: >> >> ?ARIN-2010-8 Rework of IPv6 assignment criteria >> >> The AC moved the following draft policy to last call (it will be posted >> separately to last call): >> >> ?ARIN-2010-14 Standardize IP Reassignment Registration Requirements >> >> The AC accepted the following proposals on to the AC's docket for >> development and evaluation: >> >> ?ARIN-prop-121 Better IPv6 Allocation for ISPs >> ?ARIN-prop-123 Reserved Pool for Critical Infrastructure >> >> The AC abandoned the following proposals: >> >> ?ARIN-prop-122 Reserved Pool for Future Policy Development >> ?ARIN-prop-124 Clarification of Section 4.2.4.4 >> ?ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack >> >> "The AC did not feel that emergency action was warranted for proposal >> 122, and given that the IANA IPv4 pool is expected to exhaust before the >> April Public Policy Meeting, did not feel that it would be useful to put >> this proposal on the AC's docket. The AC would encourage anyone with >> policy proposals for improving NRPM section 4.10 to submit them >> immediately, so they can be considered in time for the April meeting." >> >> "After discussion of proposal 124, the AC did not feel that emergency >> action was warranted. Normally there are few requests in queue and any >> moment, as a result the expected overall impact of this issue should be >> small. Furthermore, it is possible this proposal could increase the >> motivation to submit incomplete or fraudulent proposals at the last >> moment, it was felt this should not be encouraged. ?As the trigger event >> in NRPM Section 4.2.4.4 is almost assuredly to have occurred before the >> April Public Policy Meeting, this proposal would be irrelevant by the >> time it could be presented at that meeting. Therefore, the AC voted to >> abandon the proposal now." >> >> And regarding ARIN-prop-125 the AC stated, "The initial interpretation >> was that while ARIN's role is to manage and administer Internet number >> resources, this proposal strays too far from management towards a >> mandate. This proposal may benefit the deployment of IPv6, but it would >> do so by forcing companies to deploy IPv6 where it may not be >> immediately needed and could have unintended consequences on IPv4 >> transfers." >> >> The PDP states, ?Any member of the community, including a proposal >> originator, may initiate a Discussion Petition if they are dissatisfied >> with the action taken by the Advisory Council regarding any specific >> policy proposal.? The abandonment of proposals 122, 124 and 125 may be >> petitioned to try to change them into draft policies for discussion on >> the Public Policy Mailing List and at the April Public Policy Meeting >> (this is the Discussion ?Petition). The deadline to begin a petition >> will be five business days after the AC's draft meeting minutes are >> published. For more information on starting and participating in >> petitions, see PDP Petitions at: >> https://www.arin.net/policy/pdp_petitions.html >> >> Draft Policy and Policy Proposal texts 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, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 gary.buhrmaster at gmail.com Wed Dec 29 15:04:56 2010 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 29 Dec 2010 20:04:56 +0000 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: Message-ID: I do not support the petition to move PP-125 forward. While I can understand the goal to insure that those receiving IPv4 addresses have an IPv6 plan, I do not believe ARIN should be taking a position of requiring specific implementations or business plans (even if *I* think that they had better have an IPv6 plan). And, as others have said, at this point, by the time consensus is likely to happen on a revised version of this proposal, it will just be too late. Gary From schiller at uu.net Wed Dec 29 15:46:24 2010 From: schiller at uu.net (Jason Schiller) Date: Wed, 29 Dec 2010 15:46:24 -0500 (EST) Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> Message-ID: On Tue, 28 Dec 2010, Kevin Kargel wrote: |I must concur with Owen on all points. I have an IPv6 allocation, and I |am fighting hard to get native IPv6 routing from my upstream(s). The |only reason I can see to support 125 would be a completely selfish one in |that I have predominantly met the requirements and that it would make the |remaining pool more accessible to me because of the number of entities |that would be disqualified from accessing it because they have not worked |toward meeting the IPv6 requirements. | |I am not willing to put my selfish concerns ahead of the community. If |it is desired to force one protocol by requiring another protocol as a |pre-requisite, then there are more appropriate standards bodies to |accomplish that than a registrar. (IETF? IEEE?) I suspect such an |attempt within the standards bodies would be rejected out of hand as it |should be here. | |Can you imagine any of the standards organizations accepting a proposal |that says interfaces without an IPv6 address must not have an IPv4 |address? So over a decade ago IETF decided to make IPv4 and IPv6 incompatible on the wire. This was by design. This leaves an obvious transition problem, how to allow IPv4-only systems to talk to IPv6-only systems. The IETF supported solution was dual-stack, with the expectation that all IPv4-only systems that need to talk to the entire Internet will go dual-stack. Thus as the Internet continues to grow, and that growth gets fulfilled by creating IPv6-only networks and hosts, that these pre-existing systems will already be dual-stacked and there will not be a transition / translation issue. Unfortunately this has not occurred. I suspect this it primarily due to economic factors. Since there is real cost in deploying IPv6, and no new revenue or services, I suspect organizations are deferring the costs for as long as possible. Hopefully people have already done all the analysis, have guessed correctly when the industry depletion date is, have correctly estimated the cost and time required for such a deployment, have started their work in time, and will be ready to embrace IPv6 in a real way when the first organizations begin to be forced to fulfill their new growth through IPv6-only. This date is shortly after the frist RIR depletion, possibly 6 months. If however this does not happen, then the gap between the IPv4 Internet and IPv6 Internet may remain large (as it is now). As such many of the new IPv6-only networks will be unable to reach large portions of the Internet. That gap may take a substantial amount of time to close. If that is the case then we will all be forced to use transition technologies like NAT 64 & DNS64 or NAT 46 and DNS46, or lots of layers of CGN NAT4444. As the Comcast trial suggests, these technologies have substantial performance degradation that customers do complain about. If a small handful of large providers make a determination that they can defer their IPv6 deployment for a few years because they can continue to get IPv4 addresses, then this would certainly draw out the transition period and increase pain for everyone. This would also likely force their competition to seriously consider getting additional IPv4 addresses so that they are not at a competitive disadvantage (e.g. their customers can only get to the 5% of content on the Internet that is dual stacked). If the majority of a content provider's customer base is IPv4, then much of the incentive to move to dual-stack is removed. New content, or growth of existing sites, would require IPv4 addresses as the majority of traffic would be IPv4. I suggest it is good for the community at large to move to providing connectivity to both protocols (IPv4 and IPv6) prior to organizations being forced to deploy IPv6-only hosts and networks in order to minimize the transition pain. This means all Internet facing content needs to be reachable over both protocols, and any product or service for which the need for IP addresses continues to grow needs to go IPv6. Furthermore future content may be deployed as IPv6-only, and as such all pre-existing IPv4 networks need to plan to support IPv6 as that content emerges. Ensureing that all growth going forward supports both protocols sends a clear signal that the Internet is ready to embrace IPv6 and is prepaired to transition future growth to IPv6-only when necessary. This is exactly the demand the content providers and application developers need to justify their investments in IPv6. It also gives people the time to work out any issues they have with IPv6, and removes the penelty of being among the first providers to be forced into IPv6-only world. Some have suggested that the pricing of the IPv4 market will solve this problem. The problem with that approach is those that have calculated that they plan to purchase IPv4 addresses will still have a long lag time to implement IPv6 once they realize that IPv4 addresses are priced above the cost of IPv6 deployment, or entirely out of thier reach. The end result is still a long and painful transition / translation period for all, and the possibility of slowing or stalling IPv6 adoption. __Jason From owen at delong.com Wed Dec 29 17:10:07 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Dec 2010 14:10:07 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> Message-ID: <8F90EE2D-00EC-40D1-AEC6-EE691D8268A5@delong.com> On Dec 29, 2010, at 12:46 PM, Jason Schiller wrote: > On Tue, 28 Dec 2010, Kevin Kargel wrote: > > |I must concur with Owen on all points. I have an IPv6 allocation, and I > |am fighting hard to get native IPv6 routing from my upstream(s). The > |only reason I can see to support 125 would be a completely selfish one in > |that I have predominantly met the requirements and that it would make the > |remaining pool more accessible to me because of the number of entities > |that would be disqualified from accessing it because they have not worked > |toward meeting the IPv6 requirements. > | > |I am not willing to put my selfish concerns ahead of the community. If > |it is desired to force one protocol by requiring another protocol as a > |pre-requisite, then there are more appropriate standards bodies to > |accomplish that than a registrar. (IETF? IEEE?) I suspect such an > |attempt within the standards bodies would be rejected out of hand as it > |should be here. > | > |Can you imagine any of the standards organizations accepting a proposal > |that says interfaces without an IPv6 address must not have an IPv4 > |address? > > So over a decade ago IETF decided to make IPv4 and IPv6 incompatible on > the wire. This was by design. This leaves an obvious transition problem, > how to allow IPv4-only systems to talk to IPv6-only systems. > People keep saying decided as if there was a choice. The reality is that we needed more bits for addressing. It's very hard to put 128 bits into a 32 bit field. IETF decided this was too hard and any efforts to do so had proven unsuccessful and cumbersomely complicated. It's really not much of a decision so much as a reality. > The IETF supported solution was dual-stack, with the expectation that all > IPv4-only systems that need to talk to the entire Internet will go > dual-stack. Thus as the Internet continues to grow, and that growth gets > fulfilled by creating IPv6-only networks and hosts, that these > pre-existing systems will already be dual-stacked and there will not be a > transition / translation issue. > Which was and is a perfectly reasonable design. > Unfortunately this has not occurred. I suspect this it primarily due to > economic factors. Since there is real cost in deploying IPv6, and no new > revenue or services, I suspect organizations are deferring the costs for > as long as possible. > Partially economic factors, partially the 10-Q based culture we have evolved in the US and that the rest of the world has followed our lead on. (10-Q is quarterly SEC filing, basically a publicly traded companies quarterly report). As such, since IPv6 hasn't been needed next quarter yet, few have put it on the priority list for this quarter. > Hopefully people have already done all the analysis, have guessed > correctly when the industry depletion date is, have correctly estimated > the cost and time required for such a deployment, have started their work > in time, and will be ready to embrace IPv6 in a real way when the first > organizations begin to be forced to fulfill their new growth through > IPv6-only. This date is shortly after the frist RIR depletion, possibly 6 > months. > If they had, we would have a much larger number of organizations much further along in their IPv6 deployment process and there would be no such thing as a product that still sells without IPv6 support. > If however this does not happen, then the gap between the IPv4 Internet > and IPv6 Internet may remain large (as it is now). As such many of the > new IPv6-only networks will be unable to reach large portions of the > Internet. That gap may take a substantial amount of time to close. If > that is the case then we will all be forced to use transition technologies > like NAT 64 & DNS64 or NAT 46 and DNS46, or lots of layers of CGN NAT4444. > As the Comcast trial suggests, these technologies have substantial > performance degradation that customers do complain about. > Yep. > If a small handful of large providers make a determination that they can > defer their IPv6 deployment for a few years because they can continue to > get IPv4 addresses, then this would certainly draw out the transition > period and increase pain for everyone. This would also likely force their > competition to seriously consider getting additional IPv4 addresses so > that they are not at a competitive disadvantage (e.g. their customers can > only get to the 5% of content on the Internet that is dual stacked). If > the majority of a content provider's customer base is IPv4, then much of > the incentive to move to dual-stack is removed. New content, or growth of > existing sites, would require IPv4 addresses as the majority of traffic > would be IPv4. > No matter how you slice it, that model cannot be sustained much longer. New IPv4 addresses for content cannot continue as long as some people seem to think may be possible. > I suggest it is good for the community at large to move to providing > connectivity to both protocols (IPv4 and IPv6) prior to organizations > being forced to deploy IPv6-only hosts and networks in order to minimize > the transition pain. This means all Internet facing content needs to > be reachable over both protocols, and any product or service for which the > need for IP addresses continues to grow needs to go IPv6. Furthermore > future content may be deployed as IPv6-only, and as such all pre-existing > IPv4 networks need to plan to support IPv6 as that content emerges. > I agree with you that such a move is good for the community. > Ensureing that all growth going forward supports both protocols sends a > clear signal that the Internet is ready to embrace IPv6 and is prepaired > to transition future growth to IPv6-only when necessary. This is exactly > the demand the content providers and application developers need to > justify their investments in IPv6. It also gives people the time to work > out any issues they have with IPv6, and removes the penelty of being among > the first providers to be forced into IPv6-only world. > While this is a true statement, I don't think this will be any clearer a signal than the letters that were already sent to resource holders, the public outreach that has been done, the front-page article on CNN.COM, and various other signals that have been sent. I'm not seeing how this requirement accomplishes any of the other things you say beyond sending a signal. > Some have suggested that the pricing of the IPv4 market will solve this > problem. The problem with that approach is those that have calculated > that they plan to purchase IPv4 addresses will still have a long lag time > to implement IPv6 once they realize that IPv4 addresses are priced above > the cost of IPv6 deployment, or entirely out of thier reach. The end > result is still a long and painful transition / translation period for > all, and the possibility of slowing or stalling IPv6 adoption. > A somewhat long and very painful transition is, at this point, inevitable. As I have said, we're too far up the canyon. There is no room to turn the plane. Our remaining choices are to make the best landing we can relatively straight ahead, or, attempt a radical maneuver which will end in one of the following ways: 1. Plane strikes cliff with a direction of travel perpendicular to the cliff wall. (small impact site, wreckage relatively contained) 2. Plane stalls and hits bottom of canyon in near vertical attitude (small impact site at bottom of canyon, wreckage relatively contained) 3. Plane strikes canyon in a wing-low attitude closer to parallel to the canyon wall, likely cartwheeling and breaking up on impact. (wreckage widely scattered, large impact zone) While none of these are good options and the desire to make a radical maneuver becomes nearly unavoidable reflex as the canyon wall approaches, landing straight ahead offers the highest survival rate. We are about a year past the point for making any such radical turn with any hope of success. Owen > __Jason > _______________________________________________ > 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 Dec 29 17:59:33 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 29 Dec 2010 15:59:33 -0700 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8F90EE2D-00EC-40D1-AEC6-EE691D8268A5@delong.com> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> <8F90EE2D-00EC-40D1-AEC6-EE691D8268A5@delong.com> Message-ID: On Wed, Dec 29, 2010 at 15:10, Owen DeLong wrote: > A somewhat long and very painful transition is, at this point, inevitable. > As I have said, we're too far up the canyon. There is no room to turn > the plane. Our remaining choices are to make the best landing we can > relatively straight ahead, or, attempt a radical maneuver which will > end in one of the following ways: > ? ? ? ?1. ? ? ?Plane strikes cliff with a direction of travel perpendicular to > ? ? ? ? ? ? ? ?the cliff wall. (small impact site, wreckage relatively contained) > ? ? ? ?2. ? ? ?Plane stalls and hits bottom of canyon in near vertical attitude > ? ? ? ? ? ? ? ?(small impact site at bottom of canyon, wreckage relatively > ? ? ? ? ? ? ? ?contained) > ? ? ? ?3. ? ? ?Plane strikes canyon in a wing-low attitude closer to > ? ? ? ? ? ? ? ?parallel to the canyon wall, likely cartwheeling and > ? ? ? ? ? ? ? ?breaking up on impact. (wreckage widely scattered, > ? ? ? ? ? ? ? ?large impact zone) > > While none of these are good options and the desire to make a > radical maneuver becomes nearly unavoidable reflex as the canyon > wall approaches, landing straight ahead offers the highest > survival rate. > > We are about a year past the point for making any such radical > turn with any hope of success. I think that when you are faced with hitting a wall, you're best option is actually to bail out. In this case jumping out of the crashing plane will allow us to parachute to/with IPv6. So I for one am not trying to stop or turn the plane (we can't), rather I would like to give the remaining provisions to those on board with parachutes - and thus the best chance of surviving the impact. ~Chris > > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.com www.coisoc.org From scottleibrand at gmail.com Wed Dec 29 18:20:22 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 29 Dec 2010 17:20:22 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> <8F90EE2D-00EC-40D1-AEC6-EE691D8268A5@delong.com> Message-ID: <321DF96D-FCDB-4D81-80D7-2409CDA28098@gmail.com> I'm not sure analogies help us here... What I'm seeing/hearing is a couple things: - Restricting transfers based on v6 deployment would be a bad idea. - Restricting new allocations based on v6 deployment would have to be done much more carefully, to avoid dictating network architecture. Personally, I'd rather see a new, more modest proposal that simply restricts new free pool allocations to orgs with a solid plan for providing service to v6-only clients. That will usually mean having already received a v6 allocation and having a plan to use it, but we shouldn't dictate how the org plans to do so, just that they've thought about it and have a plan. I'd be happy to work with anyone on new text after I get back, to submit as a new policy proposal by the end of next week. Thoughts? Scott On Dec 29, 2010, at 4:59 PM, Chris Grundemann wrote: > On Wed, Dec 29, 2010 at 15:10, Owen DeLong wrote: >> A somewhat long and very painful transition is, at this point, inevitable. >> As I have said, we're too far up the canyon. There is no room to turn >> the plane. Our remaining choices are to make the best landing we can >> relatively straight ahead, or, attempt a radical maneuver which will >> end in one of the following ways: >> 1. Plane strikes cliff with a direction of travel perpendicular to >> the cliff wall. (small impact site, wreckage relatively contained) >> 2. Plane stalls and hits bottom of canyon in near vertical attitude >> (small impact site at bottom of canyon, wreckage relatively >> contained) >> 3. Plane strikes canyon in a wing-low attitude closer to >> parallel to the canyon wall, likely cartwheeling and >> breaking up on impact. (wreckage widely scattered, >> large impact zone) >> >> While none of these are good options and the desire to make a >> radical maneuver becomes nearly unavoidable reflex as the canyon >> wall approaches, landing straight ahead offers the highest >> survival rate. >> >> We are about a year past the point for making any such radical >> turn with any hope of success. > > I think that when you are faced with hitting a wall, you're best > option is actually to bail out. In this case jumping out of the > crashing plane will allow us to parachute to/with IPv6. So I for one > am not trying to stop or turn the plane (we can't), rather I would > like to give the remaining provisions to those on board with > parachutes - and thus the best chance of surviving the impact. > > ~Chris > >> >> 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. >> > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.com > www.coisoc.org > _______________________________________________ > 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 Dec 29 18:51:56 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Dec 2010 15:51:56 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> <8F90EE2D-00EC-40D1-AEC6-EE691D8268A5@delong.com> Message-ID: <16D3A731-908B-4AD1-AF94-B7FC69A5AF2E@delong.com> On Dec 29, 2010, at 2:59 PM, Chris Grundemann wrote: > On Wed, Dec 29, 2010 at 15:10, Owen DeLong wrote: >> A somewhat long and very painful transition is, at this point, inevitable. >> As I have said, we're too far up the canyon. There is no room to turn >> the plane. Our remaining choices are to make the best landing we can >> relatively straight ahead, or, attempt a radical maneuver which will >> end in one of the following ways: >> 1. Plane strikes cliff with a direction of travel perpendicular to >> the cliff wall. (small impact site, wreckage relatively contained) >> 2. Plane stalls and hits bottom of canyon in near vertical attitude >> (small impact site at bottom of canyon, wreckage relatively >> contained) >> 3. Plane strikes canyon in a wing-low attitude closer to >> parallel to the canyon wall, likely cartwheeling and >> breaking up on impact. (wreckage widely scattered, >> large impact zone) >> >> While none of these are good options and the desire to make a >> radical maneuver becomes nearly unavoidable reflex as the canyon >> wall approaches, landing straight ahead offers the highest >> survival rate. >> >> We are about a year past the point for making any such radical >> turn with any hope of success. > > I think that when you are faced with hitting a wall, you're best > option is actually to bail out. In this case jumping out of the > crashing plane will allow us to parachute to/with IPv6. So I for one > am not trying to stop or turn the plane (we can't), rather I would > like to give the remaining provisions to those on board with > parachutes - and thus the best chance of surviving the impact. > That's only true if there are parachutes on the plane. ARIN and IP Policy are not fighter jets. We are much more like commercial airliners. We don't make tight turns, can't climb vertically, and aren't carrying parachutes. Owen From AStiver at forumhealth.org Wed Dec 29 18:54:40 2010 From: AStiver at forumhealth.org (Alan Stiver) Date: Wed, 29 Dec 2010 18:54:40 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 66, Issue 44 (Out of Office Alert) Message-ID: I will be out of the office until Tuesday, Jan. 4, 2011. In my absence, you may contact Doug Wells (dwells at forumhealth.org) or Doug Milburn (dmilburn at forumhealth.org) for assistance. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, may contain information which is confidential or privileged. This information is intended to be for the sole use of the individual or entity named above. If you are not the intended recipient, please note that any unauthorized review, disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail or telephone and destroy all electronic and hard copies of the communication, including attachments. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, may contain information which is confidential or privileged. This information is intended to be for the sole use of the individual or entity named above. If you are not the intended recipient, please note that any unauthorized review, disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail or telephone and destroy all electronic and hard copies of the communication, including attachments. From tedm at ipinc.net Wed Dec 29 19:30:45 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 29 Dec 2010 16:30:45 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8F90EE2D-00EC-40D1-AEC6-EE691D8268A5@delong.com> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> <8F90EE2D-00EC-40D1-AEC6-EE691D8268A5@delong.com> Message-ID: <4D1BD2B5.6090302@ipinc.net> On 12/29/2010 2:10 PM, Owen DeLong wrote: > > On Dec 29, 2010, at 12:46 PM, Jason Schiller wrote: > >> On Tue, 28 Dec 2010, Kevin Kargel wrote: >> >> |I must concur with Owen on all points. I have an IPv6 allocation, and I >> |am fighting hard to get native IPv6 routing from my upstream(s). The >> |only reason I can see to support 125 would be a completely selfish one in >> |that I have predominantly met the requirements and that it would make the >> |remaining pool more accessible to me because of the number of entities >> |that would be disqualified from accessing it because they have not worked >> |toward meeting the IPv6 requirements. >> | >> |I am not willing to put my selfish concerns ahead of the community. If >> |it is desired to force one protocol by requiring another protocol as a >> |pre-requisite, then there are more appropriate standards bodies to >> |accomplish that than a registrar. (IETF? IEEE?) I suspect such an >> |attempt within the standards bodies would be rejected out of hand as it >> |should be here. >> | >> |Can you imagine any of the standards organizations accepting a proposal >> |that says interfaces without an IPv6 address must not have an IPv4 >> |address? >> >> So over a decade ago IETF decided to make IPv4 and IPv6 incompatible on >> the wire. This was by design. This leaves an obvious transition problem, >> how to allow IPv4-only systems to talk to IPv6-only systems. >> > People keep saying decided as if there was a choice. The reality is that > we needed more bits for addressing. It's very hard to put 128 bits into > a 32 bit field. IETF decided this was too hard and any efforts to do so > had proven unsuccessful and cumbersomely complicated. > > It's really not much of a decision so much as a reality. > >> The IETF supported solution was dual-stack, with the expectation that all >> IPv4-only systems that need to talk to the entire Internet will go >> dual-stack. Thus as the Internet continues to grow, and that growth gets >> fulfilled by creating IPv6-only networks and hosts, that these >> pre-existing systems will already be dual-stacked and there will not be a >> transition / translation issue. >> > Which was and is a perfectly reasonable design. > >> Unfortunately this has not occurred. I suspect this it primarily due to >> economic factors. Since there is real cost in deploying IPv6, and no new >> revenue or services, I suspect organizations are deferring the costs for >> as long as possible. >> > Partially economic factors, partially the 10-Q based culture we have > evolved in the US and that the rest of the world has followed our lead on. > (10-Q is quarterly SEC filing, basically a publicly traded companies > quarterly report). > > As such, since IPv6 hasn't been needed next quarter yet, few have put > it on the priority list for this quarter. > >> Hopefully people have already done all the analysis, have guessed >> correctly when the industry depletion date is, have correctly estimated >> the cost and time required for such a deployment, have started their work >> in time, and will be ready to embrace IPv6 in a real way when the first >> organizations begin to be forced to fulfill their new growth through >> IPv6-only. This date is shortly after the frist RIR depletion, possibly 6 >> months. >> > If they had, we would have a much larger number of organizations > much further along in their IPv6 deployment process and there would > be no such thing as a product that still sells without IPv6 support. > >> If however this does not happen, then the gap between the IPv4 Internet >> and IPv6 Internet may remain large (as it is now). As such many of the >> new IPv6-only networks will be unable to reach large portions of the >> Internet. That gap may take a substantial amount of time to close. If >> that is the case then we will all be forced to use transition technologies >> like NAT 64& DNS64 or NAT 46 and DNS46, or lots of layers of CGN NAT4444. >> As the Comcast trial suggests, these technologies have substantial >> performance degradation that customers do complain about. >> > Yep. > >> If a small handful of large providers make a determination that they can >> defer their IPv6 deployment for a few years because they can continue to >> get IPv4 addresses, then this would certainly draw out the transition >> period and increase pain for everyone. This would also likely force their >> competition to seriously consider getting additional IPv4 addresses so >> that they are not at a competitive disadvantage (e.g. their customers can >> only get to the 5% of content on the Internet that is dual stacked). If >> the majority of a content provider's customer base is IPv4, then much of >> the incentive to move to dual-stack is removed. New content, or growth of >> existing sites, would require IPv4 addresses as the majority of traffic >> would be IPv4. >> > No matter how you slice it, that model cannot be sustained much longer. > New IPv4 addresses for content cannot continue as long as some people > seem to think may be possible. > >> I suggest it is good for the community at large to move to providing >> connectivity to both protocols (IPv4 and IPv6) prior to organizations >> being forced to deploy IPv6-only hosts and networks in order to minimize >> the transition pain. This means all Internet facing content needs to >> be reachable over both protocols, and any product or service for which the >> need for IP addresses continues to grow needs to go IPv6. Furthermore >> future content may be deployed as IPv6-only, and as such all pre-existing >> IPv4 networks need to plan to support IPv6 as that content emerges. >> > I agree with you that such a move is good for the community. > >> Ensureing that all growth going forward supports both protocols sends a >> clear signal that the Internet is ready to embrace IPv6 and is prepaired >> to transition future growth to IPv6-only when necessary. This is exactly >> the demand the content providers and application developers need to >> justify their investments in IPv6. It also gives people the time to work >> out any issues they have with IPv6, and removes the penelty of being among >> the first providers to be forced into IPv6-only world. >> > While this is a true statement, I don't think this will be any clearer a signal > than the letters that were already sent to resource holders, the public outreach > that has been done, the front-page article on CNN.COM, and various > other signals that have been sent. > > I'm not seeing how this requirement accomplishes any of the other things > you say beyond sending a signal. > >> Some have suggested that the pricing of the IPv4 market will solve this >> problem. The problem with that approach is those that have calculated >> that they plan to purchase IPv4 addresses will still have a long lag time >> to implement IPv6 once they realize that IPv4 addresses are priced above >> the cost of IPv6 deployment, or entirely out of thier reach. The end >> result is still a long and painful transition / translation period for >> all, and the possibility of slowing or stalling IPv6 adoption. >> > A somewhat long and very painful transition is, at this point, inevitable. > As I have said, we're too far up the canyon. There is no room to turn > the plane. Our remaining choices are to make the best landing we can > relatively straight ahead, or, attempt a radical maneuver which will > end in one of the following ways: > 1. Plane strikes cliff with a direction of travel perpendicular to > the cliff wall. (small impact site, wreckage relatively contained) > 2. Plane stalls and hits bottom of canyon in near vertical attitude > (small impact site at bottom of canyon, wreckage relatively > contained) > 3. Plane strikes canyon in a wing-low attitude closer to > parallel to the canyon wall, likely cartwheeling and > breaking up on impact. (wreckage widely scattered, > large impact zone) > > While none of these are good options and the desire to make a > radical maneuver becomes nearly unavoidable reflex as the canyon > wall approaches, landing straight ahead offers the highest > survival rate. > And you didn't like the ketchup analogy?!?! ;-) > We are about a year past the point for making any such radical > turn with any hope of success. > If your going to hold to the airplane analogy then I'm going to clarify it. IPv4 started diving to that canyon when people started talking about forming RIR's to manage the spiral notebook that was being used to assign IPv4. It went solidly into the canyon when ARIN and the other RIR's came into existence, and the plane crashed and blew up in the canyon when people stopped viewing the RIR's as nothing more than a stopgap to a newer, better IP assignment solution about 9 years ago. The entire concept that a shortage should exist in network numbers in the first place is utter bullocks. That artificial shortage, caused by the creation of NAT and classless routing that extended the life of IPv4 by a decade, when it should have been dead and buried years ago, has gotten so ingrained into people's consciousness that they cannot think any other way now. If we got rid of the RIR's entirely and simply released a computer program that RANDOMLY assigned organizations IPv6 prefixes, and people used that and just started advertising prefixes that they pulled out of their hypothetical asses using that program, I would wager that collisions would occur less than 1/100th of the time. Probably much, much, less. Probably less than they occur now due to miskeys of entering router configurations and typographical errors. Ted From tedm at ipinc.net Wed Dec 29 20:00:53 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 29 Dec 2010 17:00:53 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> Message-ID: <4D1BD9C5.9050106@ipinc.net> On 12/29/2010 12:46 PM, Jason Schiller wrote: > On Tue, 28 Dec 2010, Kevin Kargel wrote: > > |I must concur with Owen on all points. I have an IPv6 allocation, and I > |am fighting hard to get native IPv6 routing from my upstream(s). The > |only reason I can see to support 125 would be a completely selfish one in > |that I have predominantly met the requirements and that it would make the > |remaining pool more accessible to me because of the number of entities > |that would be disqualified from accessing it because they have not worked > |toward meeting the IPv6 requirements. > | > |I am not willing to put my selfish concerns ahead of the community. If > |it is desired to force one protocol by requiring another protocol as a > |pre-requisite, then there are more appropriate standards bodies to > |accomplish that than a registrar. (IETF? IEEE?) I suspect such an > |attempt within the standards bodies would be rejected out of hand as it > |should be here. > | > |Can you imagine any of the standards organizations accepting a proposal > |that says interfaces without an IPv6 address must not have an IPv4 > |address? > > So over a decade ago IETF decided to make IPv4 and IPv6 incompatible on > the wire. This was by design. This leaves an obvious transition problem, > how to allow IPv4-only systems to talk to IPv6-only systems. > > The IETF supported solution was dual-stack, with the expectation that all > IPv4-only systems that need to talk to the entire Internet will go > dual-stack. Thus as the Internet continues to grow, and that growth gets > fulfilled by creating IPv6-only networks and hosts, that these > pre-existing systems will already be dual-stacked and there will not be a > transition / translation issue. > Application-level proxies are also "supported" and always have been. If you telnet from an IPv4 host to a IPv4/IPv6 host you can telnet from that host to an IPv6 host. Or you can run a web proxy like http://www.sixxs.net/tools/gateway/ does. Ted > Unfortunately this has not occurred. I suspect this it primarily due to > economic factors. Since there is real cost in deploying IPv6, and no new > revenue or services, I suspect organizations are deferring the costs for > as long as possible. > > Hopefully people have already done all the analysis, have guessed > correctly when the industry depletion date is, have correctly estimated > the cost and time required for such a deployment, have started their work > in time, and will be ready to embrace IPv6 in a real way when the first > organizations begin to be forced to fulfill their new growth through > IPv6-only. This date is shortly after the frist RIR depletion, possibly 6 > months. > > If however this does not happen, then the gap between the IPv4 Internet > and IPv6 Internet may remain large (as it is now). As such many of the > new IPv6-only networks will be unable to reach large portions of the > Internet. That gap may take a substantial amount of time to close. If > that is the case then we will all be forced to use transition technologies > like NAT 64& DNS64 or NAT 46 and DNS46, or lots of layers of CGN NAT4444. > As the Comcast trial suggests, these technologies have substantial > performance degradation that customers do complain about. > > If a small handful of large providers make a determination that they can > defer their IPv6 deployment for a few years because they can continue to > get IPv4 addresses, then this would certainly draw out the transition > period and increase pain for everyone. This would also likely force their > competition to seriously consider getting additional IPv4 addresses so > that they are not at a competitive disadvantage (e.g. their customers can > only get to the 5% of content on the Internet that is dual stacked). If > the majority of a content provider's customer base is IPv4, then much of > the incentive to move to dual-stack is removed. New content, or growth of > existing sites, would require IPv4 addresses as the majority of traffic > would be IPv4. > > I suggest it is good for the community at large to move to providing > connectivity to both protocols (IPv4 and IPv6) prior to organizations > being forced to deploy IPv6-only hosts and networks in order to minimize > the transition pain. This means all Internet facing content needs to > be reachable over both protocols, and any product or service for which the > need for IP addresses continues to grow needs to go IPv6. Furthermore > future content may be deployed as IPv6-only, and as such all pre-existing > IPv4 networks need to plan to support IPv6 as that content emerges. > > Ensureing that all growth going forward supports both protocols sends a > clear signal that the Internet is ready to embrace IPv6 and is prepaired > to transition future growth to IPv6-only when necessary. This is exactly > the demand the content providers and application developers need to > justify their investments in IPv6. It also gives people the time to work > out any issues they have with IPv6, and removes the penelty of being among > the first providers to be forced into IPv6-only world. > > Some have suggested that the pricing of the IPv4 market will solve this > problem. The problem with that approach is those that have calculated > that they plan to purchase IPv4 addresses will still have a long lag time > to implement IPv6 once they realize that IPv4 addresses are priced above > the cost of IPv6 deployment, or entirely out of thier reach. The end > result is still a long and painful transition / translation period for > all, and the possibility of slowing or stalling IPv6 adoption. > > __Jason > _______________________________________________ > 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 Thu Dec 30 10:52:21 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 30 Dec 2010 09:52:21 -0600 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> Message-ID: <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Wednesday, December 29, 2010 11:16 AM > To: arin-ppml at arin.net > Cc: chris at theipv6experts.net > Subject: *Spam?* Re: [arin-ppml] Discussion Petition of ARIN-prop-125 > Efficient Utilization of IPv4 Requires Dual-Stack > > I find it very interesting the tone and attitude that a couple of > folks have taken wrt prop-125. Those folks seem to want us to believe > that this policy somehow forces everyone (or anyone for that matter) > to adopt IPv6. > Umm, If you say that the only way I can have any IPv4 is if I have working IPv6 seems to be an attempt to force me to adopt IPv6. What are you going to do about the multitude of networks that have no access to native IPv6? Yes there are areas in the country where no backbone provider offers IPv6. Tunneling is not a good solution for production services. Kevin From cgrundemann at gmail.com Thu Dec 30 11:29:09 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 30 Dec 2010 09:29:09 -0700 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> Message-ID: On Thu, Dec 30, 2010 at 08:52, Kevin Kargel wrote: > Umm, If you say that the only way I can have any IPv4 is if I have working IPv6 seems to be an attempt to force me to adopt IPv6. Well, prop-125 states that if an org wants any *more/new* IPv4 addresses, they need to show that they are actively deploying production IPv6. The requirement is to use new IPv4 addresses in the most efficient way (the policy does not force anyone to request new IPv4, only to use it in the communities best interest if they do). > What are you going to do about the multitude of networks that have no access to native IPv6? What am I going to do personally? Well, for one, I work for a backbone provider that offers IPv6 throughout the US. For another, I am working to connect folks who need to deploy IPv6 with those who can help: http://www.theipv6experts.net. I am also supporting prop-125 which has the potential to encourage more access to native IPv6. > Yes there are areas in the country where no backbone provider offers IPv6. ?Tunneling is not a good solution for production services. Precisely why we need a policy such as this. As I tried to state in my lengthier message: The transition will not be without pain. The primary reason for this pain is that folks did not deploy IPv6 in time (which includes demanding that their upstreams, their vendors and maybe even their neighbors, support IPv6). No one who needs more IPv4 is going to get all that they need at this point. The question that remains is who should we reward with the crumbs: Those who did not act, who still have not acted _or_ the folks who listened and who did deploy (or at least are now deploying) IPv6? In both scenarios organizations will be hurt, perhaps even destroyed but that does not make the two choices equal. Leave the trees for a moment and do the right thing for the forest. Cheers, ~Chris > > Kevin > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.com www.coisoc.org From bret at getjive.com Thu Dec 30 11:59:22 2010 From: bret at getjive.com (Bret Palsson) Date: Thu, 30 Dec 2010 09:59:22 -0700 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> Message-ID: <24963EE0-A91F-4393-B5B1-5893A1D98A69@getjive.com> Chris: I think prop-125 is well intentioned, however after reading the prop, I feel that it will put companies like mine between a rock and hard place. We are working towards IPv6, however the re-tooling cost is extraordinary. Also many end devices for our SIP based phones, do not support IPv6 yet. Would prop-125 be of any help to our company? It sure would damage us financially, and be of almost no benefit since most SIP end-point devices, phones, intercoms, PAPs etc... are not yet IPv6 enabled. If you can force those companies to change and somehow come up with the 100s of thousands of dollars needed to upgrade our core routers, switches and pay our engineers to retool the software, we could jump on it now. However our current plan is to roll it out over the next few years. When there is actual support in the devices that we service. I personally believe that the adoption rate of IPv6 will pickup as soon as it becomes essential. Why force the market that way when it will naturally head that way? I'd rather people implement it correctly, and do the proper testing needed rather than being forced to change by an organization. The reality is 80% of US business are small and don't have the funds or education to be forced to change. Let the market work. It, by itself, will force them to change. -Bret On Dec 30, 2010, at 9:29 AM, Chris Grundemann wrote: > On Thu, Dec 30, 2010 at 08:52, Kevin Kargel wrote: >> Umm, If you say that the only way I can have any IPv4 is if I have working IPv6 seems to be an attempt to force me to adopt IPv6. > > Well, prop-125 states that if an org wants any *more/new* IPv4 > addresses, they need to show that they are actively deploying > production IPv6. The requirement is to use new IPv4 addresses in the > most efficient way (the policy does not force anyone to request new > IPv4, only to use it in the communities best interest if they do). > >> What are you going to do about the multitude of networks that have no access to native IPv6? > > What am I going to do personally? Well, for one, I work for a backbone > provider that offers IPv6 throughout the US. For another, I am working > to connect folks who need to deploy IPv6 with those who can help: > http://www.theipv6experts.net. I am also supporting prop-125 which has > the potential to encourage more access to native IPv6. > >> Yes there are areas in the country where no backbone provider offers IPv6. Tunneling is not a good solution for production services. > > Precisely why we need a policy such as this. > > As I tried to state in my lengthier message: The transition will not > be without pain. The primary reason for this pain is that folks did > not deploy IPv6 in time (which includes demanding that their > upstreams, their vendors and maybe even their neighbors, support > IPv6). No one who needs more IPv4 is going to get all that they need > at this point. The question that remains is who should we reward with > the crumbs: Those who did not act, who still have not acted _or_ the > folks who listened and who did deploy (or at least are now deploying) > IPv6? In both scenarios organizations will be hurt, perhaps even > destroyed but that does not make the two choices equal. Leave the > trees for a moment and do the right thing for the forest. > > Cheers, > ~Chris > >> >> Kevin >> >> > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.com > www.coisoc.org > _______________________________________________ > 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 Thu Dec 30 12:17:19 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 30 Dec 2010 09:17:19 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> Message-ID: <20101230171719.GA13816@ussenterprise.ufp.org> In a message written on Thu, Dec 30, 2010 at 09:52:21AM -0600, Kevin Kargel wrote: > What are you going to do about the multitude of networks that > have no access to native IPv6? Yes there are areas in the country > where no backbone provider offers IPv6. Tunneling is not a good > solution for production services. Perhaps this is a symptom of too much free time on a Thursday before a holiday...... Maybe a better method would be that if someone comes to ARIN for IPv4 addresses and attests that their upstream is unable to provide IPv6 services on their transit ports that the upstream ASN be prohibited from getting more IPv4 addresses until it has enabled IPv6 services to the customers. It almost sounds like a good idea, until I think about the tracking for ARIN and disputes that could arise. It would be a very interesting way to put pressure directly on the backbones that do not yet offer IPv6 to customers. -- 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 frnkblk at iname.com Thu Dec 30 13:46:33 2010 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 30 Dec 2010 12:46:33 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Message-ID: <001001cba851$e156f1a0$a404d4e0$@iname.com> Bret: Perhaps you misunderstand -- the prop isn't requiring IPv6 deployment, it's just saying you won't get any more IPv4 if you don't have a meaningful (we're not nearly in agreement what that means) IPv6 deployment. For those who have no IPv6 deployed, D-Day just came a few months earlier than those who have some measure of IPv6 deployed. It's possible that if prop 125 passed that the prices for transferred IPv4 space would go up earlier than if we waited for ARIN's free pool to evaporate. Those with IPv4 space to sell would price in the fact that IPv4-only shops can't get more IPv4 space from ARIN's free pool. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bret Palsson Sent: Thursday, December 30, 2010 10:59 AM To: Chris Grundemann Cc: chris at theipv6experts.net; arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Chris: I think prop-125 is well intentioned, however after reading the prop, I feel that it will put companies like mine between a rock and hard place. We are working towards IPv6, however the re-tooling cost is extraordinary. Also many end devices for our SIP based phones, do not support IPv6 yet. Would prop-125 be of any help to our company? It sure would damage us financially, and be of almost no benefit since most SIP end-point devices, phones, intercoms, PAPs etc... are not yet IPv6 enabled. If you can force those companies to change and somehow come up with the 100s of thousands of dollars needed to upgrade our core routers, switches and pay our engineers to retool the software, we could jump on it now. However our current plan is to roll it out over the next few years. When there is actual support in the devices that we service. I personally believe that the adoption rate of IPv6 will pickup as soon as it becomes essential. Why force the market that way when it will naturally head that way? I'd rather people implement it correctly, and do the proper testing needed rather than being forced to change by an organization. The reality is 80% of US business are small and don't have the funds or education to be forced to change. Let the market work. It, by itself, will force them to change. -Bret On Dec 30, 2010, at 9:29 AM, Chris Grundemann wrote: > On Thu, Dec 30, 2010 at 08:52, Kevin Kargel wrote: >> Umm, If you say that the only way I can have any IPv4 is if I have working IPv6 seems to be an attempt to force me to adopt IPv6. > > Well, prop-125 states that if an org wants any *more/new* IPv4 > addresses, they need to show that they are actively deploying > production IPv6. The requirement is to use new IPv4 addresses in the > most efficient way (the policy does not force anyone to request new > IPv4, only to use it in the communities best interest if they do). > >> What are you going to do about the multitude of networks that have no access to native IPv6? > > What am I going to do personally? Well, for one, I work for a backbone > provider that offers IPv6 throughout the US. For another, I am working > to connect folks who need to deploy IPv6 with those who can help: > http://www.theipv6experts.net. I am also supporting prop-125 which has > the potential to encourage more access to native IPv6. > >> Yes there are areas in the country where no backbone provider offers IPv6. Tunneling is not a good solution for production services. > > Precisely why we need a policy such as this. > > As I tried to state in my lengthier message: The transition will not > be without pain. The primary reason for this pain is that folks did > not deploy IPv6 in time (which includes demanding that their > upstreams, their vendors and maybe even their neighbors, support > IPv6). No one who needs more IPv4 is going to get all that they need > at this point. The question that remains is who should we reward with > the crumbs: Those who did not act, who still have not acted _or_ the > folks who listened and who did deploy (or at least are now deploying) > IPv6? In both scenarios organizations will be hurt, perhaps even > destroyed but that does not make the two choices equal. Leave the > trees for a moment and do the right thing for the forest. > > Cheers, > ~Chris > >> >> Kevin >> >> > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.com > www.coisoc.org > _______________________________________________ > 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 Thu Dec 30 13:47:10 2010 From: bill at herrin.us (William Herrin) Date: Thu, 30 Dec 2010 13:47:10 -0500 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> Message-ID: On Thu, Dec 30, 2010 at 11:29 AM, Chris Grundemann wrote: > Well, prop-125 states that if an org wants any *more/new* IPv4 > addresses, they need to show that they are actively deploying > production IPv6. The requirement is to use new IPv4 addresses in the > most efficient way (the policy does not force anyone to request new > IPv4, only to use it in the communities best interest if they do). Chris, If you're in the United States and you breath air, you're generally required to pay taxes on your income. Note that the law does not force anyone to breath fresh air, only to pay income tax if they do. Come on you air breather, of course the proposal is to force people to adopt IPv6. Embrace the concept and think about how to approach it with a lighter hand. What is the least disruptive, least harsh thing you can do which will still force folks a helpful distance down the IPv6 adoption path? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bret at getjive.com Thu Dec 30 13:48:34 2010 From: bret at getjive.com (Bret Palsson) Date: Thu, 30 Dec 2010 11:48:34 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <001001cba851$e156f1a0$a404d4e0$@iname.com> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> Message-ID: What is the exact intention of prop 125? People keep saying what the intention is not. What is the plain english goal of prop 125? -Bret On Dec 30, 2010, at 11:46 AM, Frank Bulk wrote: > Bret: > > Perhaps you misunderstand -- the prop isn't requiring IPv6 deployment, it's > just saying you won't get any more IPv4 if you don't have a meaningful > (we're not nearly in agreement what that means) IPv6 deployment. For those > who have no IPv6 deployed, D-Day just came a few months earlier than those > who have some measure of IPv6 deployed. > > It's possible that if prop 125 passed that the prices for transferred IPv4 > space would go up earlier than if we waited for ARIN's free pool to > evaporate. Those with IPv4 space to sell would price in the fact that > IPv4-only shops can't get more IPv4 space from ARIN's free pool. > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Bret Palsson > Sent: Thursday, December 30, 2010 10:59 AM > To: Chris Grundemann > Cc: chris at theipv6experts.net; arin-ppml at arin.net > Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient > Utilization of IPv4 Requires Dual-Stack > > Chris: > > I think prop-125 is well intentioned, however after reading the prop, I feel > that it will put companies like mine between a rock and hard place. We are > working towards IPv6, however the re-tooling cost is extraordinary. Also > many end devices for our SIP based phones, do not support IPv6 yet. > > Would prop-125 be of any help to our company? It sure would damage us > financially, and be of almost no benefit since most SIP end-point devices, > phones, intercoms, PAPs etc... are not yet IPv6 enabled. If you can force > those companies to change and somehow come up with the 100s of thousands of > dollars needed to upgrade our core routers, switches and pay our engineers > to retool the software, we could jump on it now. However our current plan is > to roll it out over the next few years. When there is actual support in the > devices that we service. > > I personally believe that the adoption rate of IPv6 will pickup as soon as > it becomes essential. Why force the market that way when it will naturally > head that way? I'd rather people implement it correctly, and do the proper > testing needed rather than being forced to change by an organization. The > reality is 80% of US business are small and don't have the funds or > education to be forced to change. Let the market work. It, by itself, will > force them to change. > > -Bret > > On Dec 30, 2010, at 9:29 AM, Chris Grundemann wrote: > >> On Thu, Dec 30, 2010 at 08:52, Kevin Kargel wrote: >>> Umm, If you say that the only way I can have any IPv4 is if I have > working IPv6 seems to be an attempt to force me to adopt IPv6. >> >> Well, prop-125 states that if an org wants any *more/new* IPv4 >> addresses, they need to show that they are actively deploying >> production IPv6. The requirement is to use new IPv4 addresses in the >> most efficient way (the policy does not force anyone to request new >> IPv4, only to use it in the communities best interest if they do). >> >>> What are you going to do about the multitude of networks that have no > access to native IPv6? >> >> What am I going to do personally? Well, for one, I work for a backbone >> provider that offers IPv6 throughout the US. For another, I am working >> to connect folks who need to deploy IPv6 with those who can help: >> http://www.theipv6experts.net. I am also supporting prop-125 which has >> the potential to encourage more access to native IPv6. >> >>> Yes there are areas in the country where no backbone provider offers > IPv6. Tunneling is not a good solution for production services. >> >> Precisely why we need a policy such as this. >> >> As I tried to state in my lengthier message: The transition will not >> be without pain. The primary reason for this pain is that folks did >> not deploy IPv6 in time (which includes demanding that their >> upstreams, their vendors and maybe even their neighbors, support >> IPv6). No one who needs more IPv4 is going to get all that they need >> at this point. The question that remains is who should we reward with >> the crumbs: Those who did not act, who still have not acted _or_ the >> folks who listened and who did deploy (or at least are now deploying) >> IPv6? In both scenarios organizations will be hurt, perhaps even >> destroyed but that does not make the two choices equal. Leave the >> trees for a moment and do the right thing for the forest. >> >> Cheers, >> ~Chris >> >>> >>> Kevin >>> >>> >> >> >> >> >> -- >> @ChrisGrundemann >> weblog.chrisgrundemann.com >> www.burningwiththebush.com >> www.theIPv6experts.com >> www.coisoc.org >> _______________________________________________ >> 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 mysidia at gmail.com Thu Dec 30 13:57:32 2010 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 30 Dec 2010 12:57:32 -0600 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> Message-ID: On Thu, Dec 30, 2010 at 12:47 PM, William Herrin wrote: > On Thu, Dec 30, 2010 at 11:29 AM, Chris Grundemann > Come on you air breather, of course the proposal is to force people to > adopt IPv6. Embrace the concept and think about how to approach it > with a lighter hand. What is the least disruptive, least harsh thing > you can do which will still force folks a helpful distance down the > IPv6 adoption path? The least harsh thing I can think of is to require that all further ISP applicants for IPv4 PA space either have IPv6 space from ARIN OR have at least one AS number, and at least one announced IPv6 with that AS number as ORIGIN. And all further end user applications for IPv4 PI space demonstrate that they have an IPv6 allocation from ARIN OR their ISP's SWIP or RWHOIS server indicates at least one existing IPv6 delegation, which they have to supply in their application. This is what I would suggest requiring, instead of anything in PP125. > > Regards, > Bill Herrin > -- -JH From cgrundemann at gmail.com Thu Dec 30 13:58:45 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 30 Dec 2010 11:58:45 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <001001cba851$e156f1a0$a404d4e0$@iname.com> Message-ID: On Thu, Dec 30, 2010 at 11:48, Bret Palsson wrote: > What is the exact intention of prop 125? > > People keep saying what the intention is not. What is the plain english goal of prop 125? As stated in the rational, this proposal has three objectives: To encourage IPv6 deployment prior to and post depletion, to enable growth of IPv4 to accelerate IPv6 transition and to improve the utilization of IP addresses. Also see the full rational here: http://lists.arin.net/pipermail/arin-ppml/2010-December/018939.html And my recent elaboration here: http://lists.arin.net/pipermail/arin-ppml/2010-December/019108.html HTH, Chris > > -Bret > > _______________________________________________ > 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.theIPv6experts.com www.coisoc.org From matthew at matthew.at Thu Dec 30 14:01:38 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 11:01:38 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> Message-ID: <4D1CD712.5050704@matthew.at> On 12/30/2010 8:29 AM, Chris Grundemann wrote: > On Thu, Dec 30, 2010 at 08:52, Kevin Kargel wrote: >> Umm, If you say that the only way I can have any IPv4 is if I have working IPv6 seems to be an attempt to force me to adopt IPv6. > Well, prop-125 states that if an org wants any *more/new* IPv4 > addresses, they need to show that they are actively deploying > production IPv6. Why? And why apply it to transfers? (Which I assume are "old, used IPv4 addresses") There are any number of reasons (including my hypothetical "legacy computing museum" example from yesterday) why one might have a legitimate need for IPv4 addresses and no need, reason, or even *way* of deploying production IPv6 for those same devices. > The requirement is to use new IPv4 addresses in the > most efficient way (the policy does not force anyone to request new > IPv4, only to use it in the communities best interest if they do). There is nothing other than your (somewhat suspect, see below) value judgment determining that deploying IPv4 addresses without parallel IPv6 addresses is somehow "inefficient". Why is putting 100 legacy machines on the public network of less value than putting 100 new machines on the public network? As I asked yesterday, who is to decide whether an SSL-protected porn site is more or less valuable than a publicly-reachable VAX running 4.3bsd or an original NeXTstation, or a sensor device that the local flood control district needs to reach and won't be replacing for 10 more years? It shouldn't be me, you, or ARIN. >> What are you going to do about the multitude of networks that have no access to native IPv6? > What am I going to do personally? Well, for one, I work for a backbone > provider that offers IPv6 throughout the US. Aha. So you have a financial interest in having quicker deployment of IPv6. > For another, I am working > to connect folks who need to deploy IPv6 with those who can help: > http://www.theipv6experts.net. And an interest in having people who don't need or understand IPv6 being forced to somehow show their IPv6 expertise. > I am also supporting prop-125 which has > the potential to encourage more access to native IPv6. After the first two reasons, this is no surprise then. > No one who needs more IPv4 is going to get all that they need > at this point. Agreed. There's a limited supply coming from ARIN, which I hope will continue to be available under policies that aren't continually shifting as misguided attempts to optimize the last few pieces such as this one change the policies repeatedly during a time when ARIN should be focused 100% on IPv6. And there's a transfer mechanism, which shouldn't be muddied up by ridiculous IPv6 requirements that make no sense. > The question that remains is who should we reward with > the crumbs: Those who did not act, who still have not acted _or_ the > folks who listened and who did deploy (or at least are now deploying) > IPv6? We shouldn't be "rewarding" either. They're both trying to get IPv4 addresses, which are running out. Not one of us knows which of those two groups has the more compelling reasons to get space. Yes, it does make sense to set aside *some* of the space for people who need IPv4 addresses *specifically* to operate their IPv6-IPv4 transition technologies, but that's it. Once you've set that aside there is nothing that makes any one need for IPv4 space more important than another unless you want to have a "homeowners association" that starts reviewing each application on its public-interest benefits and choice of web page background color. > In both scenarios organizations will be hurt, perhaps even > destroyed but that does not make the two choices equal. I disagree. With the sole exception of IPv4 space reserved for transition technologies, the choices *must* be equal in the eyes of ARIN. > Leave the > trees for a moment and do the right thing for the forest. Often the best thing for the forest is to *not meddle*. I say we leave IPv4 policy as-is and worry about the forest on the other continent. Matthew Kaufman From matthew at matthew.at Thu Dec 30 14:03:05 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 11:03:05 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <001001cba851$e156f1a0$a404d4e0$@iname.com> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> Message-ID: <4D1CD769.8030202@matthew.at> On 12/30/2010 10:46 AM, Frank Bulk wrote: > It's possible that if prop 125 passed that the prices for transferred IPv4 > space would go up earlier than if we waited for ARIN's free pool to > evaporate. Those with IPv4 space to sell would price in the fact that > IPv4-only shops can't get more IPv4 space from ARIN's free pool. The proposal as-is would also prevent transfers to entities that hadn't deployed IPv6. So there'd be *no* transfer market during this time... except a grey/black one. Matthew Kaufman From bret at getjive.com Thu Dec 30 14:04:18 2010 From: bret at getjive.com (Bret Palsson) Date: Thu, 30 Dec 2010 12:04:18 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <001001cba851$e156f1a0$a404d4e0$@iname.com> Message-ID: On Dec 30, 2010, at 11:58 AM, Chris Grundemann wrote: > On Thu, Dec 30, 2010 at 11:48, Bret Palsson wrote: >> What is the exact intention of prop 125? >> >> People keep saying what the intention is not. What is the plain english goal of prop 125? > > As stated in the rational, this proposal has three objectives: > > To encourage IPv6 deployment prior to and post depletion, I think this is already taken care of. No more IPv4? Better use IPv6. That seems to be motive enough. > to enable growth of IPv4 to accelerate IPv6 transition and How does this enable the growth of IPv4 exactly? By freeing up space when people move to IPv6? See above comment. It will happen naturally. > to improve the utilization of IP addresses. I don't see how this "improves the utilization of IP addresses". Do we really need policy for something that will happen naturally? > > Also see the full rational here: > http://lists.arin.net/pipermail/arin-ppml/2010-December/018939.html > And my recent elaboration here: > http://lists.arin.net/pipermail/arin-ppml/2010-December/019108.html > > HTH, > Chris > >> >> -Bret >> >> _______________________________________________ >> 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.theIPv6experts.com > www.coisoc.org From matthew at matthew.at Thu Dec 30 14:05:01 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 11:05:01 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> Message-ID: <4D1CD7DD.8020001@matthew.at> On 12/30/2010 10:47 AM, William Herrin wrote: > > Embrace the concept and think about how to approach it > with a lighter hand. What is the least disruptive, least harsh thing > you can do which will still force folks a helpful distance down the > IPv6 adoption path? Let IPv4 addresses run out for everyone at a predictable pace, without screwing around with the policies repeatedly in the last few months. Matthew Kaufman From matthew at matthew.at Thu Dec 30 14:06:07 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 11:06:07 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <001001cba851$e156f1a0$a404d4e0$@iname.com> Message-ID: <4D1CD81F.8040208@matthew.at> On 12/30/2010 10:58 AM, Chris Grundemann wrote: > On Thu, Dec 30, 2010 at 11:48, Bret Palsson wrote: >> What is the exact intention of prop 125? >> >> People keep saying what the intention is not. What is the plain english goal of prop 125? > As stated in the rational, this proposal has three objectives: > > To encourage IPv6 deployment prior to and post depletion, It does that, certainly. > to enable growth of IPv4 to accelerate IPv6 transition and Might do that. > to improve the utilization of IP addresses. Value judgment about address utilization that so far hasn't been supported by any argument. Matthew Kaufman From bill at herrin.us Thu Dec 30 14:12:53 2010 From: bill at herrin.us (William Herrin) Date: Thu, 30 Dec 2010 14:12:53 -0500 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D1CD7DD.8020001@matthew.at> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD7DD.8020001@matthew.at> Message-ID: On Thu, Dec 30, 2010 at 2:05 PM, Matthew Kaufman wrote: > On 12/30/2010 10:47 AM, William Herrin wrote: >> ?Embrace the concept and think about how to approach it >> with a lighter hand. What is the least disruptive, least harsh thing >> you can do which will still force folks a helpful distance down the >> IPv6 adoption path? > > Let IPv4 addresses run out for everyone at a predictable pace, without > screwing around with the policies repeatedly in the last few months. Matthew, That might or might not be the best idea, but I fail to see how it "forces folks a helpful distance down the IPv6 adoption path." Can you, like Jimmy just did, set aside your objection to forcing IPv6 on people long enough to consider what the least harmful way to do so would be IF it was acceptable to do so at all? Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Thu Dec 30 14:18:01 2010 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 30 Dec 2010 13:18:01 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D1CD769.8030202@matthew.at> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> Message-ID: <001101cba856$46e22270$d4a66750$@iname.com> Which is why perhaps prop 125 should be modified to allow transfers sans IPv6. That might even kickstart the transfer market. Frank -----Original Message----- From: Matthew Kaufman [mailto:matthew at matthew.at] Sent: Thursday, December 30, 2010 1:03 PM To: frnkblk at iname.com Cc: 'Bret Palsson'; arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack On 12/30/2010 10:46 AM, Frank Bulk wrote: > It's possible that if prop 125 passed that the prices for transferred IPv4 > space would go up earlier than if we waited for ARIN's free pool to > evaporate. Those with IPv4 space to sell would price in the fact that > IPv4-only shops can't get more IPv4 space from ARIN's free pool. The proposal as-is would also prevent transfers to entities that hadn't deployed IPv6. So there'd be *no* transfer market during this time... except a grey/black one. Matthew Kaufman From matthew at matthew.at Thu Dec 30 14:21:29 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 11:21:29 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD7DD.8020001@matthew.at> Message-ID: <4D1CDBB9.20309@matthew.at> On 12/30/2010 11:12 AM, William Herrin wrote: > On Thu, Dec 30, 2010 at 2:05 PM, Matthew Kaufman wrote: >> On 12/30/2010 10:47 AM, William Herrin wrote: >>> Embrace the concept and think about how to approach it >>> with a lighter hand. What is the least disruptive, least harsh thing >>> you can do which will still force folks a helpful distance down the >>> IPv6 adoption path? >> Let IPv4 addresses run out for everyone at a predictable pace, without >> screwing around with the policies repeatedly in the last few months. > Matthew, > > That might or might not be the best idea, but I fail to see how it > "forces folks a helpful distance down the > IPv6 adoption path." Can you, like Jimmy just did, set aside your > objection to forcing IPv6 on people long enough to consider what the > least harmful way to do so would be IF it was acceptable to do so at > all? Around here we call what happens if you do nothing "natural consequences". The thing is, there isn't enough time between now and runout to force hardly anyone to do anything. Between now and runout, what percentage of the orgs that have ARIN IPv4 space will actually come back for more IPv4 space? Those are the *only* ones you have any hope of impacting with this policy. Many of the ones which are taking huge chunks of space at a time (e.g., Comcast) are already working on their IPv6 deployment, so you won't be doing anything to help them either. So we're wasting a whole lot of time debating a policy which impacts a small percentage of a small percentage. And then of the tiny fraction of the population it does impact, it isn't at all clear that "forcing IPv6 on people" is appropriate in all cases. I've given several examples where it is clear that all "forcing IPv6 on people" does is cause them to set up a few boxes in a parallel network that is simply a waste of time and money... jumping through yet another hoop to get the IPv4 space they need. As for transfers, either this policy will be modified to not affect transfers (as it should) or it will just force more of the transfers onto the gray and/or black market instead of going through ARIN and keeping the records straight (as was the whole point of a transfer policy). Matthew Kaufman From mpetach at netflight.com Thu Dec 30 14:26:45 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 30 Dec 2010 11:26:45 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <001101cba856$46e22270$d4a66750$@iname.com> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> <001101cba856$46e22270$d4a66750$@iname.com> Message-ID: On Thu, Dec 30, 2010 at 11:18 AM, Frank Bulk wrote: > Which is why perhaps prop 125 should be modified to allow transfers sans > IPv6. ?That might even kickstart the transfer market. > > Frank That would seem to be an interesting modification to the proposal--adjust the language so that *new* allocations from ARIN should be matched by a corresponding IPv6 deployment, but that v4 transfers are not likewise encumbered. Given that transfers are likely to cost real $$s, that provides the more gentle encouragement for companies; if you want it for cheap from ARIN, pony up with some v6; otherwise, pay market rates for recycled space. Depending on the wording, I might be able to support a modified proposal along those lines. Matt > -----Original Message----- > From: Matthew Kaufman [mailto:matthew at matthew.at] > Sent: Thursday, December 30, 2010 1:03 PM > To: frnkblk at iname.com > Cc: 'Bret Palsson'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient > Utilization of IPv4 Requires Dual-Stack > > On 12/30/2010 10:46 AM, Frank Bulk wrote: >> It's possible that if prop 125 passed that the prices for transferred IPv4 >> space would go up earlier than if we waited for ARIN's free pool to >> evaporate. ?Those with IPv4 space to sell would price in the fact that >> IPv4-only shops can't get more IPv4 space from ARIN's free pool. > The proposal as-is would also prevent transfers to entities that hadn't > deployed IPv6. So there'd be *no* transfer market during this time... > except a grey/black one. > > Matthew Kaufman > > _______________________________________________ > 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 Dec 30 14:36:58 2010 From: bill at herrin.us (William Herrin) Date: Thu, 30 Dec 2010 14:36:58 -0500 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D1CDBB9.20309@matthew.at> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD7DD.8020001@matthew.at> <4D1CDBB9.20309@matthew.at> Message-ID: On Thu, Dec 30, 2010 at 2:21 PM, Matthew Kaufman wrote: > On 12/30/2010 11:12 AM, William Herrin wrote: >> Can you, like Jimmy just did, set aside your >> objection to forcing IPv6 on people long enough to consider what the >> least harmful way to do so would be IF it was acceptable to do so at >> all? > > it isn't at > all clear that "forcing IPv6 on people" is appropriate Then your answer is no, you're not capable of working the problem one piece at a time? You can't help the prop 125 guys come up with the least harmful force-IPv6-adoption proposal and THEN consider whether the resulting proposal is still inappropriate? Come on Matthew, tell me your better than that. Let's help the prop 125 guys find the least objectionable version of their proposal and put off the talk about adoption or rejection of the general concept until later. Regards, Bill -- 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 Thu Dec 30 15:04:02 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 12:04:02 -0800 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD7DD.8020001@matthew.at> <4D1CDBB9.20309@matthew.at> Message-ID: <4D1CE5B2.9070000@matthew.at> On 12/30/2010 11:36 AM, William Herrin wrote: > > Then your answer is no, you're not capable of working the problem one > piece at a time? You can't help the prop 125 guys come up with the > least harmful force-IPv6-adoption proposal and THEN consider whether > the resulting proposal is still inappropriate? > > Come on Matthew, tell me your better than that. Let's help the prop > 125 guys find the least objectionable version of their proposal and > put off the talk about adoption or rejection of the general concept > until later. When I was young and naive, I signed all ballot proposition petitions that were stuck in front of me, figuring "every idea should be allowed to come to a vote, no matter how flawed". I've since learned that there's a whole lot of things that get the popular vote that aren't actually good. So no, I'm not interested in helping them make this bad idea more palatable to the masses. It is a bad idea. I've pointed out why it is a bad idea. As I've pointed out it is an *especially* bad idea if applied to transfers... but I don't want them to take transfers out of the proposal either, because doing so will make it *more likely* that it will pass. And there's already a great way to force everyone to adopt IPv6, really, and this isn't it. The only force that will make people put IPv6 on servers is when there are eyeballs that have IPv6-only service... and the only force that will make eyeballs demand IPv6 is when there are services they want to reach which are only available on the IPv6 Internet. And none of that happens by giving out IPv4 addresses to people who are deploying IPv6. In fact, giving them IPv4 addresses *delays* the inevitable. The sooner runout happens, the better. That means that delaying IPv4 runout by forcing people to jump through more hoops is a *bad* thing. So... you want a policy to "force IPv6 adoption"? Stop giving out *any* IPv4 addresses. The only way for ARIN to do that is for ARIN to not have any more, as I doubt we could get a "reserve all the rest, immediately" policy through soon enough to matter, and this policy is the opposite. Matthew Kaufman From schiller at uu.net Thu Dec 30 15:14:29 2010 From: schiller at uu.net (Jason Schiller) Date: Thu, 30 Dec 2010 15:14:29 -0500 (EST) Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D1CD769.8030202@matthew.at> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> Message-ID: On Thu, 30 Dec 2010, Matthew Kaufman wrote: |The proposal as-is would also prevent transfers to entities that hadn't |deployed IPv6. So there'd be *no* transfer market during this time... except a |grey/black one. | |Matthew Kaufman Yes i agree theer would be *no* transfer market during this time... except a grey/black one... but I am not sure what your point is with this comment. Right now all IPv4 transferes require justified need. As ARIN does still fulfill requests with justified need, there should be *no* transfer market. The only people who are attempting to transfer space on the grey/black market are those who can't actually meet ARIN's requirements for justified need. Are you argueing that we should have a liberal transfer market (no justified need) like the APNIC region? Or are you trying to make some other point? __Jason From spiffnolee at yahoo.com Thu Dec 30 15:18:48 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 30 Dec 2010 12:18:48 -0800 (PST) Subject: [arin-ppml] Internet means IPv6 (was: some other long subject line) In-Reply-To: <4D1CD712.5050704@matthew.at> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD712.5050704@matthew.at> Message-ID: <556265.23574.qm@web63301.mail.re1.yahoo.com> > From: Matthew Kaufman > Sent: Thu, December 30, 2010 2:01:38 PM > Subject: Re: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 > Efficient Utilization of IPv4 Requires Dual-Stack > Why is putting 100 legacy machines on the public network of less value than > putting 100 new machines on the public network? What public network? If you want to provide a bridge for a PC with arcnet and netx.com, so it can ping your token-ring OS/2 machine, or get finger'd by your ATM Irix box, use rfc1918. If you want "Internet access," (with a capital I) that term will soon mean IPv6. In 2012, there will be no expectation of connectivity over IPv4; if devices are unavailable over IPv6, it will be the responsibility of the laggard to upgrade. > it does make sense to set aside > *some* of the space for people who need IPv4 addresses *specifically* to >operate > > their IPv6-IPv4 transition technologies, but that's it. Once you've set that > aside there is nothing that makes any one need for IPv4 space more important > than another unless you want to have a "homeowners association" that starts > reviewing each application on its public-interest benefits and choice of web > page background color. What is the value of "some," and how is in inarbitrary? Or does it make sense for ARIN's analysts to be able to apply a set of objective criteria for evaluating requests? That has been ARIN's practice. Lee From matthew at matthew.at Thu Dec 30 15:31:03 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 12:31:03 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> Message-ID: <4D1CEC07.9090406@matthew.at> On 12/30/2010 12:14 PM, Jason Schiller wrote: > On Thu, 30 Dec 2010, Matthew Kaufman wrote: > > |The proposal as-is would also prevent transfers to entities that hadn't > |deployed IPv6. So there'd be *no* transfer market during this time... except a > |grey/black one. > | > |Matthew Kaufman > > Yes i agree theer would be *no* transfer market during this time... > except a grey/black one... > > but I am not sure what your point is with this comment. I was replying to Frank Bulk saying "It's possible that if prop 125 passed that the prices for transferred IPv4 space would go up earlier than if we waited for ARIN's free pool to evaporate. Those with IPv4 space to sell would price in the fact that IPv4-only shops can't get more IPv4 space from ARIN's free pool" I was simply noting that if there was a transfer market at this time, this proposal negatively impacts it rather than accelerating it. > Right now all IPv4 transferes require justified need. As ARIN does still > fulfill requests with justified need, there should be *no* transfer > market. Agreed. > The only people who are attempting to transfer space on the grey/black > market are those who can't actually meet ARIN's requirements for justified > need. One would think. Though if this proposal were to pass as-is, it would become harder for an IPv4-only entity to meet those requirements. I would guess that the number of grey/black market transfers would go up in such a situation. > > Are you argueing that we should have a liberal transfer market (no > justified need) like the APNIC region? I wasn't arguing either way. > Or are you trying to make some > other point? I was simply trying to reply to the situation supposed by Frank. Matthew Kaufman From spiffnolee at yahoo.com Thu Dec 30 15:31:55 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 30 Dec 2010 12:31:55 -0800 (PST) Subject: [arin-ppml] IPv4 runout happens when the first ISP deploys CGN+IPv6* In-Reply-To: References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> Message-ID: <122471.15470.qm@web63307.mail.re1.yahoo.com> I agree with you, but want to extend the context. ----- Original Message ---- > From: Jason Schiller > IPv6-only. This date is shortly after the frist RIR depletion, possibly 6 > months. > > we will all be forced to use transition technologies > like NAT 64 & DNS64 or NAT 46 and DNS46, or lots of layers of CGN NAT4444. > New content, or growth of > existing sites, would require IPv4 addresses as the majority of traffic > would be IPv4. Content does not only live on "servers." Once ISPs can't get new IPv4 addresses, they may pay for transfers for hosted servers, but access customers will get CGN and hopefully IPv6. If one of those customers is a p2p seeder, or is your online gaming buddy (through any game console), he is unreachable via IPv4. In other words, your flag day is not the day you run out of IPv4. *Your runout date is the date your customers want to reach a user at an ISP using CGN+IPv6. > Some have suggested that the pricing of the IPv4 market will solve this > problem. The problem with that approach is those that have calculated > that they plan to purchase IPv4 addresses will still have a long lag time > to implement IPv6 once they realize that IPv4 addresses are priced above > the cost of IPv6 deployment, or entirely out of thier reach. Yes. Efficient market pricing means you don't know you can't afford it until you can't afford it, which may be two years too late to start your IPv6 deployment. Lee From matthew at matthew.at Thu Dec 30 15:40:33 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 12:40:33 -0800 Subject: [arin-ppml] Internet means IPv6 In-Reply-To: <556265.23574.qm@web63301.mail.re1.yahoo.com> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD712.5050704@matthew.at> <556265.23574.qm@web63301.mail.re1.yahoo.com> Message-ID: <4D1CEE41.2020406@matthew.at> On 12/30/2010 12:18 PM, Lee Howard wrote: > >> From: Matthew Kaufman >> Sent: Thu, December 30, 2010 2:01:38 PM >> Subject: Re: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 >> Efficient Utilization of IPv4 Requires Dual-Stack >> Why is putting 100 legacy machines on the public network of less value than >> putting 100 new machines on the public network? > What public network? The public IPv4 network that will continue to exist for years, perhaps decades. But certainly for another 5-10 years. > If you want to provide a bridge for a PC with arcnet and netx.com, so it can > ping your token-ring OS/2 machine, or get finger'd by your ATM Irix box, > use rfc1918. If you want "Internet access," (with a capital I) that term will > soon mean IPv6. Actually, it will soon mean "IPv4 and IPv6"... too bad it hasn't meant that for the last couple of years. If I come to an ISP in 2013 with an AS number and my own IPv4 addresses, I expect they'll be able to route them and provide significant connectivity to a large and still extant network. > In 2012, there will be no expectation of connectivity over > IPv4; if devices are unavailable over IPv6, it will be the responsibility of the > > laggard to upgrade. Only if they need those to be reachable by IPv6 endpoints. In 2012 there will still be lots of IPv4 endpoints talking to lots of other IPv4 endpoints, and neither end will need to upgrade. If an organization gets another /24 worth of IPv4 space via transfer in 2012, they'll be able to announce it and hook up another 250 endpoints and talk to and from all those other IPv4 endpoints. And this will probably be true in 2013, and 2014, and maybe even in 2024. >> it does make sense to set aside >> *some* of the space for people who need IPv4 addresses *specifically* to >> operate >> >> their IPv6-IPv4 transition technologies, but that's it. Once you've set that >> aside there is nothing that makes any one need for IPv4 space more important >> than another unless you want to have a "homeowners association" that starts >> reviewing each application on its public-interest benefits and choice of web >> page background color. > What is the value of "some," and how is in inarbitrary? Apparently the value of "some" is "a single /10". I'm referring to 2008-5. If that's not enough, lets see a proposal to reserve some more. > Or does it make sense for ARIN's analysts to be able to apply a set of > objective criteria for evaluating requests? That has been ARIN's practice. That *does* make sense. What doesn't make sense is having "applicant has figured out how to deploy enough IPv6 to impress the analyst" as a criteria for whether IPv4 space is needed. Matthew Kaufman From matthew at matthew.at Thu Dec 30 15:44:09 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 30 Dec 2010 12:44:09 -0800 Subject: [arin-ppml] IPv4 runout happens when the first ISP deploys CGN+IPv6* In-Reply-To: <122471.15470.qm@web63307.mail.re1.yahoo.com> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> <122471.15470.qm@web63307.mail.re1.yahoo.com> Message-ID: <4D1CEF19.6050006@matthew.at> On 12/30/2010 12:31 PM, Lee Howard wrote: > > Content does not only live on "servers." > > Once ISPs can't get new IPv4 addresses, they may pay for transfers for > hosted servers, but access customers will get CGN and hopefully IPv6. > If one of those customers is a p2p seeder, or is your online gaming buddy > (through any game console), he is unreachable via IPv4. Only for peer-to-peer protocols that can't traverse a CGN. Matthew Kaufman From bill at herrin.us Thu Dec 30 15:54:49 2010 From: bill at herrin.us (William Herrin) Date: Thu, 30 Dec 2010 15:54:49 -0500 Subject: [arin-ppml] IPv4 runout happens when the first ISP deploys CGN+IPv6* In-Reply-To: <122471.15470.qm@web63307.mail.re1.yahoo.com> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> <122471.15470.qm@web63307.mail.re1.yahoo.com> Message-ID: On Thu, Dec 30, 2010 at 3:31 PM, Lee Howard wrote: > Once ISPs can't get new IPv4 addresses, they may pay for transfers for > hosted servers, but access customers will get CGN and hopefully IPv6. > If one of those customers is a p2p seeder, or is your online gaming buddy > (through any game console), he is unreachable via IPv4. Lee, For about 6 months until some clever fellow decides to sell a gaming service the crux of which is projecting listening ports out to a shared server via a VPN from the game host behind his NAT. Give it another two months before one ISP decides it can trump its main competitor by buying this cheap tech and advertising its inclusion with the service. And give it one cycle of game software before the developers start building with the assumption that box may be in the picture. Less than that for the P2P software to catch up. On Thu, Dec 30, 2010 at 3:44 PM, Matthew Kaufman wrote: > Only for peer-to-peer protocols that can't traverse a CGN. Which right now is all of them. The NAT traversal hacks for P2P boil down to two approaches: 1. Have a third party coordinate a connection in the opposite direction (only one side is behind a NAT) 2. Rely on the typical preservation of the source and destination UDP port numbers to trick the connection open on both ends (not valid with CGNs which often won't be able to preserve port numbers and probably won't try to). Neither strategy is a winner when both sides of a P2P find themselves behind a Carrier NAT. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From spiffnolee at yahoo.com Thu Dec 30 15:57:40 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 30 Dec 2010 12:57:40 -0800 (PST) Subject: [arin-ppml] IPv4 runout happens when the first ISP deploys CGN+IPv6* In-Reply-To: <4D1CEF19.6050006@matthew.at> References: <8639pjkt72.fsf@seastrom.com> <86y67ag89h.fsf@seastrom.com> <307B41E6-0611-4B24-9894-22143081A355@delong.com> <8695009A81378E48879980039EEDAD288C048C45@MAIL1.polartel.local> <122471.15470.qm@web63307.mail.re1.yahoo.com> <4D1CEF19.6050006@matthew.at> Message-ID: <950854.79874.qm@web63305.mail.re1.yahoo.com> ----- Original Message ---- > From: Matthew Kaufman > To: Lee Howard > Cc: Jason Schiller ; Kevin Kargel ; >"arin-ppml at arin.net" > Sent: Thu, December 30, 2010 3:44:09 PM > Subject: Re: [arin-ppml] IPv4 runout happens when the first ISP deploys >CGN+IPv6* > > On 12/30/2010 12:31 PM, Lee Howard wrote: > > > > Content does not only live on "servers." > > > > Once ISPs can't get new IPv4 addresses, they may pay for transfers for > > hosted servers, but access customers will get CGN and hopefully IPv6. > > If one of those customers is a p2p seeder, or is your online gaming buddy > > (through any game console), he is unreachable via IPv4. > Only for peer-to-peer protocols that can't traverse a CGN. If the *seeder* is on a home gateway, behind a CGN, there's no workaround. It has an rfc1918 address, and maybe it's used ICE/TURN/STUN or uPNP or other magic to get through the local gateway, so it tells the tracker it's "outside" address, which is the address of the home gateway. But the tracker is outside the CGN, so it provides the ISP's private address to the client. I've only lab tested this, but I've never gotten it to work. This is also true of gaming consoles. The online server that brokers the connection uses the source address of each console, which may be the outside of the CGN. But the CGN doesn't have a mapping for client to client, only client to server, so the game setup fails. I've lab tested this too, and it fails slightly differently for different game consoles. See http://tools.ietf.org/html/draft-donley-nat444-impacts-01 My points are: * NOT that we need better NAT traversal, but that we need better IPv6 support. * IPv4 only "continues to work" in some contexts. Lee From schiller at uu.net Thu Dec 30 16:14:08 2010 From: schiller at uu.net (Jason Schiller) Date: Thu, 30 Dec 2010 16:14:08 -0500 (EST) Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D1CE5B2.9070000@matthew.at> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD7DD.8020001@matthew.at> <4D1CDBB9.20309@matthew.at> <4D1CE5B2.9070000@matthew.at> Message-ID: On Thu, 30 Dec 2010, Matthew Kaufman wrote: |And there's already a great way to force everyone to adopt IPv6, really, and |this isn't it. The only force that will make people put IPv6 on servers is when |there are eyeballs that have IPv6-only service... and the only force that will |make eyeballs demand IPv6 is when there are services they want to reach which |are only available on the IPv6 Internet. And none of that happens by giving out |IPv4 addresses to people who are deploying IPv6. In fact, giving them IPv4 |addresses *delays* the inevitable. The only force that will drive eyeball networks to IPv6 is continued customer growth and no more available IPv4 addresses. If a few large eyeball networks decide that they can continue to operate in an IPv4-only world by purchasing IPv4 addresses or doing more CGN / NAT4444 then they can defer their IPv6 deployments. This will remove much of the incentive for content providers to adopt IPv6. IPv6 adoption stalls due to lack of IPv6 enabled content. The IPv4 /IPv6 Internet gap remains wide, and all of the networks that are doing the right by deploying IPv6 get panelized as they deplete their existing IPv4 reserves, and transition their growth to IPv6-only, as those IPv6-only customers will not be able to reach a large portion of the Internet, or can only reach the majority of the Internet through sub-optimal and poorly performing transition / translation mechanisms. |The sooner runout happens, the better. That means that delaying IPv4 runout by |forcing people to jump through more hoops is a *bad* thing. This proposal makes run-out happen sooner for those who are not deploying IPv6 in a real way. This proposal does make runout happen later for those who are deployng IPv6 in a real way... but I don't care about that if all the "things" they are using these addresses for are reachable over IPv6, and it helps them to move their pre-existing IPv4-only stuff to be IPv6 reachable. Starting to make all new deployments reachable over IPv6 while we still have IPv4 addresses left is a good thing. This builds better justification for pre-existing IPv4-only content providers, and application developers to support IPv6. Encouraging existing IPv4-only deployment to be reachable over IPv6 is a good thing. This builds better justification for pre-existing IPv4-only content providers, and application developers to support IPv6. Having more of the Internet also reachable over IPv6 is a good thing. This means when the first IPv6-only deployments are forced due to depletion, there will be a small gap between the IPv4-only Internet and the IPv6-only Internet. This will minamize the pain of transition or translation technologies which Comcast and others have suggested provide poor performance. On Thu, 30 Dec 2010, Matthew Kaufman wrote: |Value judgment about address utilization that so far hasn't been supported |by any argument. | Sustained growth depending on IPv4, a very limited resource, with out a plan to transition to IPv6 is irresponsible. Sustained growth depending on IPv4, with a plan to embrace IPv6 only when your IPv4 stores are depleted is detrimental to portion of the community who runs out before you. This behavior reflected in the community is detrimental to you if you are not among the minority of organizations to be depleted last. The behavior is beneficial if your IPv4 reserves can out last your competition. This problem is complicated by uncertainty surrounding the various depletion dates (IANA, first RIR, all the RIRs you do business with, the last RIR, your own personal depleting date) and changing run rates, long deployment cycles, fluctuating market prices, and how deep your pockets are as compaired to your competition. This whole problem goes away if the whole Internet (or at least the parts that matter) has good reachablility via IPv6 prior to the first organization running out of IPv4 addresses. To the extent that we come close to the whole Internet having good reachablility via IPv6 while the number of users forced to IPv6-only deployments is very small, will determine the level of pain involved. __Jason From spiffnolee at yahoo.com Thu Dec 30 16:14:10 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 30 Dec 2010 13:14:10 -0800 (PST) Subject: [arin-ppml] Internet means IPv6 In-Reply-To: <4D1CEE41.2020406@matthew.at> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD712.5050704@matthew.at> <556265.23574.qm@web63301.mail.re1.yahoo.com> <4D1CEE41.2020406@matthew.at> Message-ID: <966415.93789.qm@web63305.mail.re1.yahoo.com> > >> Why is putting 100 legacy machines on the public network of less value than > >> putting 100 new machines on the public network? > > What public network? > The public IPv4 network that will continue to exist for years, perhaps >decades. But certainly for another 5-10 years. It's not a public network. It's a large set of private networks that agree to interconnect using standard protocols. The conditions for use of one of those protocols is changing, and interoperability will be limited to the extent network operators disagree on protocol implementation. In other words, run your network your way, but don't assume you can connect to the other guy. > > > If you want to provide a bridge for a PC with arcnet and netx.com, so it can > > ping your token-ring OS/2 machine, or get finger'd by your ATM Irix box, > > use rfc1918. If you want "Internet access," (with a capital I) that term >will > > soon mean IPv6. > Actually, it will soon mean "IPv4 and IPv6"... too bad it hasn't meant that >for the last couple of years. > > If I come to an ISP in 2013 with an AS number and my own IPv4 addresses, I >expect they'll be able to route them and provide significant connectivity to a >large and still extant network. "Significant" is a huge step down from where we are now. It may be acceptable for your needs. > > > In 2012, there will be no expectation of connectivity over > > IPv4; if devices are unavailable over IPv6, it will be the responsibility of >the > > laggard to upgrade. > Only if they need those to be reachable by IPv6 endpoints. In 2012 there will >still be lots > > of IPv4 endpoints talking to lots of other IPv4 endpoints, and neither end will >need to upgrade. Sure--if you control both endpoints and a significant portion of the connections between them (enough to preclude CGN), then you can use IPv4 or whatever protocol you want. But you should not assume you will have the same breadth of connectivity you do now. Maybe that's fine--you know what your hosts do. > > If an organization gets another /24 worth of IPv4 space via transfer in 2012, >they'll be > > able to announce it and hook up another 250 endpoints and talk to and from all >those > > other IPv4 endpoints. And this will probably be true in 2013, and 2014, and >maybe > > even in 2024. Sure, if you only need to talk to/from IPv4 endpoints. And if you don't rely on IP geolocation for advertising services. And you log source address, port, and NTP timestamp on your server logs, so you can provide those to law enforcement when you're attacked. > > Or does it make sense for ARIN's analysts to be able to apply a set of > > objective criteria for evaluating requests? That has been ARIN's practice. > That *does* make sense. What doesn't make sense is having "applicant has >figured > > out how to deploy enough IPv6 to impress the analyst" as a criteria for >whether IPv4 > > space is needed. Are you arguing about the definition of "enough"? Would it make more sense for the application to say, "I've considered all of the use cases, and I don't need connectivity to and from IPv6 hosts, just IPv4." Lee > Matthew Kaufman From schiller at uu.net Thu Dec 30 16:14:22 2010 From: schiller at uu.net (Jason Schiller) Date: Thu, 30 Dec 2010 16:14:22 -0500 (EST) Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <001101cba856$46e22270$d4a66750$@iname.com> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> <001101cba856$46e22270$d4a66750$@iname.com> Message-ID: Frank, Would you be in favor of supporting the petetion... A: As written? B: As written with a different defination for "real deployment of IPv6" which may or may not be dual stack? C: As written, but not applying to specified transfers? D: As written with a different defination for "real deployment of IPv6" which may or may not be dual stack, and not applying to specified transfers? __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Thu, 30 Dec 2010, Frank Bulk wrote: |Date: Thu, 30 Dec 2010 13:18:01 -0600 |From: Frank Bulk |To: matthew at matthew.at |Cc: arin-ppml at arin.net |Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient | Utilization of IPv4 Requires Dual-Stack | |Which is why perhaps prop 125 should be modified to allow transfers sans |IPv6. That might even kickstart the transfer market. | |Frank | |-----Original Message----- |From: Matthew Kaufman [mailto:matthew at matthew.at] |Sent: Thursday, December 30, 2010 1:03 PM |To: frnkblk at iname.com |Cc: 'Bret Palsson'; arin-ppml at arin.net |Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient |Utilization of IPv4 Requires Dual-Stack | |On 12/30/2010 10:46 AM, Frank Bulk wrote: |> It's possible that if prop 125 passed that the prices for transferred IPv4 |> space would go up earlier than if we waited for ARIN's free pool to |> evaporate. Those with IPv4 space to sell would price in the fact that |> IPv4-only shops can't get more IPv4 space from ARIN's free pool. |The proposal as-is would also prevent transfers to entities that hadn't |deployed IPv6. So there'd be *no* transfer market during this time... |except a grey/black one. | |Matthew Kaufman | |_______________________________________________ |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 Dec 30 16:19:15 2010 From: bill at herrin.us (William Herrin) Date: Thu, 30 Dec 2010 16:19:15 -0500 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <4D1CE5B2.9070000@matthew.at> References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD7DD.8020001@matthew.at> <4D1CDBB9.20309@matthew.at> <4D1CE5B2.9070000@matthew.at> Message-ID: On Thu, Dec 30, 2010 at 3:04 PM, Matthew Kaufman wrote: > On 12/30/2010 11:36 AM, William Herrin wrote: >> Come on Matthew, tell me your better than that. Let's help the prop >> 125 guys find the least objectionable version of their proposal and >> put off the talk about adoption or rejection of the general concept >> until later. > > I'm not interested in helping them make this bad idea more palatable > to the masses. Then why should the prop 125 guys listen to anything you have to say? The prop 125 guys will need to listen to the folks who might be convinced to join a consensus with the right set of changes. You're a firmly declared "no" vote. The only knowledge you offer them is a list arguments to be rebutted. What's more, should they fail to achieve a consensus on defects in the proposal rather than the concept, it doesn't close the question... the matter remains open for the next guy to and try again. And again. If you're against the concept and want it to go away, help the prop 125 guys build the best proposal possible, and THEN seek consensus that even the best constructed version of the concept is unacceptable. And let the best ideas win. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Thu Dec 30 16:36:05 2010 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 30 Dec 2010 15:36:05 -0600 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> <001101cba856$46e22270$d4a66750$@iname.com> Message-ID: <001701cba869$900e2670$b02a7350$@iname.com> Jason: Owen made some compelling arguments that have given me food for thought. That said, at this time the petition would: a) need to adjust the definition of "real deployment for IPv6" to accommodate for content, eyeball, and any other kind of network. While the devil is in the details, I currently can't think of any requestor that could say they would never need IPv6 anywhere in their network. If getting IPv4 space is important, they'll find some way to make IPv6 happen in their network. If they can't justify it, then they'll make other accomodations. b) not apply to transfers. To apply this requirement would very likely result in black/gray market transfers and I'd rather avoid that. At that point, market forces will more directly drive business decisions in relation to IPv6. c) apply to whatever space ARIN holds back from the free pool (i.e. CI, transition, etc.) Frank -----Original Message----- From: Jason Schiller [mailto:schiller at uu.net] Sent: Thursday, December 30, 2010 3:14 PM To: Frank Bulk Cc: matthew at matthew.at; arin-ppml at arin.net Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack Frank, Would you be in favor of supporting the petetion... A: As written? B: As written with a different defination for "real deployment of IPv6" which may or may not be dual stack? C: As written, but not applying to specified transfers? D: As written with a different defination for "real deployment of IPv6" which may or may not be dual stack, and not applying to specified transfers? __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Thu, 30 Dec 2010, Frank Bulk wrote: |Date: Thu, 30 Dec 2010 13:18:01 -0600 |From: Frank Bulk |To: matthew at matthew.at |Cc: arin-ppml at arin.net |Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient | Utilization of IPv4 Requires Dual-Stack | |Which is why perhaps prop 125 should be modified to allow transfers sans |IPv6. That might even kickstart the transfer market. | |Frank | |-----Original Message----- |From: Matthew Kaufman [mailto:matthew at matthew.at] |Sent: Thursday, December 30, 2010 1:03 PM |To: frnkblk at iname.com |Cc: 'Bret Palsson'; arin-ppml at arin.net |Subject: Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient |Utilization of IPv4 Requires Dual-Stack | |On 12/30/2010 10:46 AM, Frank Bulk wrote: |> It's possible that if prop 125 passed that the prices for transferred IPv4 |> space would go up earlier than if we waited for ARIN's free pool to |> evaporate. Those with IPv4 space to sell would price in the fact that |> IPv4-only shops can't get more IPv4 space from ARIN's free pool. |The proposal as-is would also prevent transfers to entities that hadn't |deployed IPv6. So there'd be *no* transfer market during this time... |except a grey/black one. | |Matthew Kaufman | |_______________________________________________ |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 Thu Dec 30 16:44:39 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 30 Dec 2010 15:44:39 -0600 Subject: [arin-ppml] *Spam?* Re: *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <4D125FAE.3050307@arin.net> <8695009A81378E48879980039EEDAD288C048C46@MAIL1.polartel.local> <4D1CD7DD.8020001@matthew.at> <4D1CDBB9.20309@matthew.at> <4D1CE5B2.9070000@matthew.at> Message-ID: <8695009A81378E48879980039EEDAD288C048C4E@MAIL1.polartel.local> Absolutely wrong. If a bad idea is a bad idea then call it a bad idea. The fence riders and uninformed need to know it is a bad idea. If you want to hit me with clubs I am not going to help you figure out how to make it more palatable. I am going to tell you not to hit me at all. Why would we want to spend our time working on a bad idea? ARIN is a registrar and has no business telling me what addresses I must put on my router interfaces. Arin's job is to dole out IP addresses and keep track of who they were given to. As has been brought up here multiple times, there is no public internet. There is a cooperative association of private networks communicating for fun and profit. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Thursday, December 30, 2010 3:19 PM > To: matthew at matthew.at > Cc: arin-ppml at arin.net > Subject: *Spam?* Re: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN- > prop-125 Efficient Utilization of IPv4 Requires Dual-Stack > > On Thu, Dec 30, 2010 at 3:04 PM, Matthew Kaufman > wrote: > > On 12/30/2010 11:36 AM, William Herrin wrote: > >> Come on Matthew, tell me your better than that. Let's help the prop > >> 125 guys find the least objectionable version of their proposal and > >> put off the talk about adoption or rejection of the general concept > >> until later. > > > > I'm not interested in helping them make this bad idea more palatable > > to the masses. > > Then why should the prop 125 guys listen to anything you have to say? > The prop 125 guys will need to listen to the folks who might be > convinced to join a consensus with the right set of changes. You're a > firmly declared "no" vote. The only knowledge you offer them is a list > arguments to be rebutted. > > What's more, should they fail to achieve a consensus on defects in the > proposal rather than the concept, it doesn't close the question... the > matter remains open for the next guy to and try again. And again. > > If you're against the concept and want it to go away, help the prop > 125 guys build the best proposal possible, and THEN seek consensus > that even the best constructed version of the concept is unacceptable. > And let the best ideas win. > > > 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 kkargel at polartel.com Thu Dec 30 16:50:06 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 30 Dec 2010 15:50:06 -0600 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <001701cba869$900e2670$b02a7350$@iname.com> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> <001101cba856$46e22270$d4a66750$@iname.com> <001701cba869$900e2670$b02a7350$@iname.com> Message-ID: <8695009A81378E48879980039EEDAD288C048C4F@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Frank Bulk > Sent: Thursday, December 30, 2010 3:36 PM > To: 'Jason Schiller' > Cc: arin-ppml at arin.net > Subject: *Spam?* Re: [arin-ppml] Discussion Petition of ARIN-prop-125 > Efficient Utilization of IPv4 Requires Dual-Stack > > Jason: > > Owen made some compelling arguments that have given me food for thought. > > That said, at this time the petition would: > a) need to adjust the definition of "real deployment for IPv6" to > accommodate for content, eyeball, and any other kind of network. While > the > devil is in the details, I currently can't think of any requestor that > could > say they would never need IPv6 anywhere in their network. If getting IPv4 > space is important, they'll find some way to make IPv6 happen in their > network. If they can't justify it, then they'll make other accomodations. What about the networks for whom in the near future at least IPv6 is unobtainable? Are you just going to throw them to the wolves because they are geographically in the third world portion of the United States? From frnkblk at iname.com Thu Dec 30 16:51:54 2010 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 30 Dec 2010 15:51:54 -0600 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <8695009A81378E48879980039EEDAD288C048C4F@MAIL1.polartel.local> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> <001101cba856$46e22270$d4a66750$@iname.com> <001701cba869$900e2670$b02a7350$@iname.com> <8695009A81378E48879980039EEDAD288C048C4F@MAIL1.polartel.local> Message-ID: <001801cba86b$c5e3d180$51ab7480$@iname.com> You mean like me? That's why we have a tunnel to HE. =( That's not throwing them to the wolves, that's providing them extra incentive to talk to their IP packet suppliers. Frank -----Original Message----- From: Kevin Kargel [mailto:kkargel at polartel.com] Sent: Thursday, December 30, 2010 3:50 PM To: 'frnkblk at iname.com'; 'Jason Schiller' Cc: arin-ppml at arin.net Subject: RE: *Spam?* Re: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Frank Bulk > Sent: Thursday, December 30, 2010 3:36 PM > To: 'Jason Schiller' > Cc: arin-ppml at arin.net > Subject: *Spam?* Re: [arin-ppml] Discussion Petition of ARIN-prop-125 > Efficient Utilization of IPv4 Requires Dual-Stack > > Jason: > > Owen made some compelling arguments that have given me food for thought. > > That said, at this time the petition would: > a) need to adjust the definition of "real deployment for IPv6" to > accommodate for content, eyeball, and any other kind of network. While > the > devil is in the details, I currently can't think of any requestor that > could > say they would never need IPv6 anywhere in their network. If getting IPv4 > space is important, they'll find some way to make IPv6 happen in their > network. If they can't justify it, then they'll make other accomodations. What about the networks for whom in the near future at least IPv6 is unobtainable? Are you just going to throw them to the wolves because they are geographically in the third world portion of the United States? From mpetach at netflight.com Thu Dec 30 17:00:30 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 30 Dec 2010 14:00:30 -0800 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <001701cba869$900e2670$b02a7350$@iname.com> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> <001101cba856$46e22270$d4a66750$@iname.com> <001701cba869$900e2670$b02a7350$@iname.com> Message-ID: On Thu, Dec 30, 2010 at 1:36 PM, Frank Bulk wrote: > Jason: > > Owen made some compelling arguments that have given me food for thought. > > That said, at this time the petition would: > a) need to adjust the definition of "real deployment for IPv6" to > accommodate for content, eyeball, and any other kind of network. ?While the > devil is in the details, I currently can't think of any requestor that could > say they would never need IPv6 anywhere in their network. ?If getting IPv4 > space is important, they'll find some way to make IPv6 happen in their > network. ?If they can't justify it, then they'll make other accomodations. I would also ditch the 80% requirement; in fact, I'd suggest avoiding any hard-and-fast number, as it's likely to be completely orthogonal to the intent of the proposal. Note that at least one company that I'm aware of is making their content available via IPv6 by making use of v4-to-v6 proxy boxes; thus, the number of dual-stacked ports is a tiny fraction of the overall network, but it nonetheless provides IPv6 reachability to the rest of the internet6 for that content. Surely that would suffice to meet the underlying desire of the proposal, that we provide encouragement for further deployment of IPv6? Matt From cgrundemann at gmail.com Thu Dec 30 17:09:39 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 30 Dec 2010 15:09:39 -0700 Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> <001101cba856$46e22270$d4a66750$@iname.com> <001701cba869$900e2670$b02a7350$@iname.com> Message-ID: On Thu, Dec 30, 2010 at 15:00, Matthew Petach wrote: > > I would also ditch the 80% requirement; in fact, I'd suggest avoiding > any hard-and-fast number, as it's likely to be completely orthogonal > to the intent of the proposal. FWIW, the 80% in the proposal is an upper limit. It basically says once at least 80% of your production network/services are IPv6 enabled, we will consider you fully IPv6 enabled. The number may need to be tweaked, but to omit that upper bound completely would result in folks needing to enable 100% of their network/services. ~Chris > > Note that at least one company that I'm aware of is making their content > available via IPv6 by making use of v4-to-v6 proxy boxes; thus, the number > of dual-stacked ports is a tiny fraction of the overall network, but > it nonetheless > provides IPv6 reachability to the rest of the internet6 for that > content. ?Surely > that would suffice to meet the underlying desire of the proposal, that > we provide > encouragement for further deployment of IPv6? > > Matt > _______________________________________________ > 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.theIPv6experts.com www.coisoc.org From kkargel at polartel.com Thu Dec 30 17:51:21 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 30 Dec 2010 16:51:21 -0600 Subject: [arin-ppml] *Spam?* Re: Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack In-Reply-To: <001801cba86b$c5e3d180$51ab7480$@iname.com> References: <001001cba851$e156f1a0$a404d4e0$@iname.com> <4D1CD769.8030202@matthew.at> <001101cba856$46e22270$d4a66750$@iname.com> <001701cba869$900e2670$b02a7350$@iname.com> <8695009A81378E48879980039EEDAD288C048C4F@MAIL1.polartel.local> <001801cba86b$c5e3d180$51ab7480$@iname.com> Message-ID: <8695009A81378E48879980039EEDAD288C048C50@MAIL1.polartel.local> A tunnel is really not a good idea for commercial traffic. I agree on the tunnel, but we recently disconnected our tunnel because of issues raised with the production network. You can have all the incentive you want to talk to the packet suppliers, but if they won't sell it to you then you can't buy it. I would really hate to see ARIN get in to the arena of endorsing preferred providers. That's a whole other can of worms. If ARIN starts giving preferential treatment to some areas of the country over others I am sure things will get exciting. This is a definite item to put before counsel. When you start to say that ISP's in New York and California have a greater priority for IP's than those in the central states where IPv6 is not so available will certainly get congressmen playing in the arena, and I doubt that they will play the game you want them to play. This could be a short cut to government control. Kevin > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Thursday, December 30, 2010 3:52 PM > To: Kevin Kargel; 'Jason Schiller' > Cc: > Subject: RE: *Spam?* Re: [arin-ppml] Discussion Petition of ARIN-prop-125 > Efficient Utilization of IPv4 Requires Dual-Stack > > You mean like me? That's why we have a tunnel to HE. =( > > That's not throwing them to the wolves, that's providing them extra > incentive to talk to their IP packet suppliers. > > Frank > > -----Original Message----- > From: Kevin Kargel [mailto:kkargel at polartel.com] > Sent: Thursday, December 30, 2010 3:50 PM > To: 'frnkblk at iname.com'; 'Jason Schiller' > Cc: arin-ppml at arin.net > Subject: RE: *Spam?* Re: [arin-ppml] Discussion Petition of ARIN-prop-125 > Efficient Utilization of IPv4 Requires Dual-Stack > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > Behalf Of Frank Bulk > > Sent: Thursday, December 30, 2010 3:36 PM > > To: 'Jason Schiller' > > Cc: arin-ppml at arin.net > > Subject: *Spam?* Re: [arin-ppml] Discussion Petition of ARIN-prop-125 > > Efficient Utilization of IPv4 Requires Dual-Stack > > > > Jason: > > > > Owen made some compelling arguments that have given me food for thought. > > > > That said, at this time the petition would: > > a) need to adjust the definition of "real deployment for IPv6" to > > accommodate for content, eyeball, and any other kind of network. While > > the > > devil is in the details, I currently can't think of any requestor that > > could > > say they would never need IPv6 anywhere in their network. If getting > IPv4 > > space is important, they'll find some way to make IPv6 happen in their > > network. If they can't justify it, then they'll make other > accomodations. > > What about the networks for whom in the near future at least IPv6 is > unobtainable? Are you just going to throw them to the wolves because they > are geographically in the third world portion of the United States? > From jcurran at arin.net Thu Dec 30 19:48:33 2010 From: jcurran at arin.net (John Curran) Date: Fri, 31 Dec 2010 00:48:33 +0000 Subject: [arin-ppml] ARIN IPv4 Number Resource Inventory (was: PP 124 Preliminary Info) In-Reply-To: References: Message-ID: <007BFE18-2C89-42AE-8C1B-EBEE0401397B@corp.arin.net> On Dec 29, 2010, at 1:52 PM, Martin Hannigan wrote: > > I'd like to request that the ARIN staff please provide an accurate > condition of current inventory including all address space, reserves, > holds, etc. As of today, ARIN's total IPv4 address inventory consists of the following number resources: At present, there are currently 3.32 /8s that are available for ARIN to issue out of. Note that ARIN no longer makes internal reservations of adjacent IPv4 space to facilitate aggregation future requests, and existing reservations of that type have been released back into the available pool and is accounted for in the 3.32 /8s listed above. Additionally, there are currently 0.07 /8s of IPv4 address space that are in revoked/returned/reclaimed status which will become available for ARIN to assign from over the next 6 months as their release dates come up. Additionally, there are approximately 1.53 /8s of legacy IPv4 address space (formerly designated as the "various registry" space on the IANA registry page) that are about to become available ARIN to issue from. These address blocks had been held for several years pending final agreement amongst the 5 RIRs, but the list has been finalized and the space is becoming available for issue momentarily. The sum total of the about IPv4 space that should be considered available going forward for resource requests is 4.92 /8s of IPv4 address space. Note also that ARIN is also holding space (254 of 256 from one /8) which was returned by INTEROP. Per our existing practices, this space was placed in temporary holddown before reuse, and it to be released from its 6 month hold status on May 22, 2011. As it is quite possible that this space will be returned to the IANA, it has not been counted as part of ARIN's available inventory for issue in the numbers above. I hope this information provides clarity regarding ARIN's IPv4 number resource inventory; it is our plans to have this information maintained online and current starting in early 2011. Happy Holidays! /John John Curran President and CEO ARIN From bill at telnetcommunications.com Thu Dec 30 19:50:52 2010 From: bill at telnetcommunications.com (Bill Sandiford) Date: Thu, 30 Dec 2010 19:50:52 -0500 Subject: [arin-ppml] ARIN IPv4 Number Resource Inventory (was: PP 124 Preliminary Info) In-Reply-To: <007BFE18-2C89-42AE-8C1B-EBEE0401397B@corp.arin.net> References: <007BFE18-2C89-42AE-8C1B-EBEE0401397B@corp.arin.net> Message-ID: John: Do we know what ARIN's current IPv4 issue rate is? Bill > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of John Curran > Sent: Thursday, December 30, 2010 7:49 PM > To: Martin Hannigan > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] ARIN IPv4 Number Resource Inventory (was: PP > 124 Preliminary Info) > > On Dec 29, 2010, at 1:52 PM, Martin Hannigan wrote: > > > > I'd like to request that the ARIN staff please provide an accurate > > condition of current inventory including all address space, reserves, > > holds, etc. > > As of today, ARIN's total IPv4 address inventory consists of the > following number resources: > > At present, there are currently 3.32 /8s that are available for ARIN > to issue out of. Note that ARIN no longer makes internal reservations > of adjacent IPv4 space to facilitate aggregation future requests, and > existing reservations of that type have been released back into the > available pool and is accounted for in the 3.32 /8s listed above. > > Additionally, there are currently 0.07 /8s of IPv4 address space that > are in revoked/returned/reclaimed status which will become available > for ARIN to assign from over the next 6 months as their release dates > come up. > > Additionally, there are approximately 1.53 /8s of legacy IPv4 address > space (formerly designated as the "various registry" space on the > IANA > registry page) that are about to become available ARIN to issue from. > These address blocks had been held for several years pending final > agreement amongst the 5 RIRs, but the list has been finalized and the > space is becoming available for issue momentarily. > > The sum total of the about IPv4 space that should be considered > available > going forward for resource requests is 4.92 /8s of IPv4 address space. > > Note also that ARIN is also holding space (254 of 256 from one /8) > which > was returned by INTEROP. Per our existing practices, this space was > placed in temporary holddown before reuse, and it to be released from > its 6 month hold status on May 22, 2011. As it is quite possible that > this space will be returned to the IANA, it has not been counted as > part of ARIN's available inventory for issue in the numbers above. > > I hope this information provides clarity regarding ARIN's IPv4 number > resource inventory; it is our plans to have this information maintained > online and current starting in early 2011. > > Happy Holidays! > /John > > John Curran > President and CEO > ARIN > > > _______________________________________________ > 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 jcurran at arin.net Thu Dec 30 20:43:33 2010 From: jcurran at arin.net (John Curran) Date: Fri, 31 Dec 2010 01:43:33 +0000 Subject: [arin-ppml] ARIN IPv4 Number Resource Inventory (was: PP 124 Preliminary Info) In-Reply-To: References: <007BFE18-2C89-42AE-8C1B-EBEE0401397B@corp.arin.net> Message-ID: <90D44311-09FC-404C-960D-2C99B269AADC@arin.net> On Dec 30, 2010, at 7:50 PM, Bill Sandiford wrote: > John: > > Do we know what ARIN's current IPv4 issue rate is? Bill - You'll get very different answers depending on the time period you pick to rate average. The IPv4 issue rate over the last few years for ARIN has been on or under 2 /8's per year (data through '09 is here: 64K /24's = /8, ) If you want to consider the rate over CY 2010, it's been lower but increasingly rapidly towards the end of the year Note that there are quite a few factors that make the "current rate" a horrible predictor: it does not take seasonality of requests into account, nor does it show the human factors impact of various policies passing (until well after the fact when they show up in the actual allocations made.) FYI - For those who really want some raw data, it is all available via the ARIN-issued mailing list (also listed on that web page.) Feel free to run the actual daily allocations into whatever model you feel most appropriate... If you'd like an estimate based on my own judgement of the most recent activity, the current "instantaneous" issue rate is probably closer to one /8 every two to three months (which implies about 9 months from IANA depletion to ARIN depletion.) I hesitate to state even that much publicly, since a handful of requests can dramatically impact that outlook in *either* direction. Going into 2012, any parties that want to continue grow their Internet business should be serious looking into IPv6 and (if needed) the limited options that will exist for IPv4 address transfer. This is not drill: we are going to fully deplete the available IPv4 address pool in the very near future. Best wishes, /John John Curran President and CEO ARIN From bill at telnetcommunications.com Thu Dec 30 21:53:48 2010 From: bill at telnetcommunications.com (Bill Sandiford) Date: Thu, 30 Dec 2010 21:53:48 -0500 Subject: [arin-ppml] ARIN IPv4 Number Resource Inventory (was: PP 124 Preliminary Info) In-Reply-To: <90D44311-09FC-404C-960D-2C99B269AADC@arin.net> References: <007BFE18-2C89-42AE-8C1B-EBEE0401397B@corp.arin.net> <90D44311-09FC-404C-960D-2C99B269AADC@arin.net> Message-ID: Thanks John: I knew it was a tough question that didn't have a simple answer. The answer given is much appreciated. Regards, Bill > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Thursday, December 30, 2010 8:44 PM > To: Bill Sandiford > Cc: arin ppml > Subject: Re: [arin-ppml] ARIN IPv4 Number Resource Inventory (was: PP > 124 Preliminary Info) > > On Dec 30, 2010, at 7:50 PM, Bill Sandiford wrote: > > > John: > > > > Do we know what ARIN's current IPv4 issue rate is? > > Bill - > > You'll get very different answers depending on the time > period you pick to rate average. The IPv4 issue rate over > the last few years for ARIN has been on or under 2 /8's > per year (data through '09 is here: 64K /24's = /8, > ) If you > want to consider the rate over CY 2010, it's been lower > but increasingly rapidly towards the end of the year > > Note that there are quite a few factors that make the > "current rate" a horrible predictor: it does not take > seasonality of requests into account, nor does it show > the human factors impact of various policies passing > (until well after the fact when they show up in the > actual allocations made.) > > FYI - For those who really want some raw data, it is all > available via the ARIN-issued mailing list (also listed > on that web page.) Feel free to run the actual daily > allocations into whatever model you feel most appropriate... > > If you'd like an estimate based on my own judgement of > the most recent activity, the current "instantaneous" > issue rate is probably closer to one /8 every two to > three months (which implies about 9 months from IANA > depletion to ARIN depletion.) I hesitate to state even > that much publicly, since a handful of requests can > dramatically impact that outlook in *either* direction. > Going into 2012, any parties that want to continue grow > their Internet business should be serious looking into > IPv6 and (if needed) the limited options that will exist > for IPv4 address transfer. This is not drill: we are > going to fully deplete the available IPv4 address pool > in the very near future. > > Best wishes, > /John > > John Curran > President and CEO > ARIN > >