From Bill.Smith at paypal.com Tue Jun 1 22:05:37 2010 From: Bill.Smith at paypal.com (Smith, Bill) Date: Tue, 1 Jun 2010 20:05:37 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - May 2010 In-Reply-To: References: <4BFC042B.1080600@arin.net> <4BFD11C4.3030301@chl.com> <4BFD207C.1060706@gmail.com> <4BFE8628.8080001@chl.com> <4BFFD4D8.4040001@chl.com> <28E139F46D45AF49A31950F88C497458062FE617@E03MVZ2-UKDY.domain1.systemhost.net> <39BF0C2785E4044E81A4D55B333D510661602E2DE9@DEN-MEXMS-001.corp.ebay.com> <5BA22FB3-B6C2-4EB7-83CA-7D591AB1B20A@delong.com> Message-ID: <51C46CB6-2093-43F4-90BE-294993923A11@paypal.com> On May 29, 2010, at 5:12 AM, William Herrin wrote: On Sat, May 29, 2010 at 3:31 AM, Owen DeLong > wrote: In this circumstance, given the number of different inputs to the process and the ambiguity of much of the input received, it is not always as easy as you might think for the AC to determine consensus, but, yes, usually it is. Owen, If you're not sure whether you have consensus then you don't. It only gets complicated when you really want there to be consensus even though there isn't. That's my point exactly. The PDP is quite clear that the AC is charged with determining consensus of the community. In my experience, it is relatively easy to determine if consensus exists. Achieving consensus may be monumentally difficult and time consuming but the determination of its existence is straightforward. As I understand the PDP, the AC is charged with the simpler task. The AC is charged with determining several things, consensus being but one of them. The AC is also effectively charged with making an independent recommendation to the board as to whether a policy proposal would improve ARIN. For any given proposal, it get's three chances to do this within the process, only the first of which also functions to discourage public participation. >From the PDP, section 2 Draft Policy: "The Advisory Council evaluates policy proposals and develops them into technically sound and useful draft policies that, if adopted, will make a positive contribution to the Number Resource Policy Manual." And from section 1The Policy Proposal "Only policy proposals that are developed into draft policies by the Advisory Council, or successfully petitioned, will be discussed for adoption on the PPML and at the public policy meeting." Here's the process as dictated by the two sentences above from the PDP: The AC evaluates a submitted policy proposal. It makes some determination based on that evaluation. If it is determined that a policy proposal should be discussed on PPML, it is developed into a sound, useful, and beneficial *draft policy*. ( I don't believe the PDP dictates how the AC performs this development, it simply requires that it do so.) Only then is that draft policy discussed on PPML and at F2F meetings - unless the policy proposal was petitioned. Once a draft policy is out for discussion, changes can be suggested. Those suggestions should be evaluated for soundness, utility, and positive impact and only those that improve the draft policy should be accepted. The draft proposal goes back to the AC and it again presumably looks at soundness, utility, and benefit. It also determines consensus. With a good definition of consensus, even other than the default unanimity, it really is rare for a group to disagree on whether consensus has been reached on an issue, at least in my experience. There can be considerable disagreement on utility, technical soundness, and positive impact - and if those disagreements are significant, sustained, widespread, or otherwise recognized as not indicative of consensus, than consensus doesn't exist. (Of course those holding such opinions should be allowed to state that they do not object to consensus being declared.) What is ARIN's definition of consensus? Is there a way forward when consensus doesn't exist? From rudi.daniel at gmail.com Tue Jun 1 23:39:49 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Tue, 1 Jun 2010 23:39:49 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 59, Issue 35 In-Reply-To: References: Message-ID: Just wanted to mention that I was called to a meeting today by my Government's Ministry relating to v4 to v6 transition and Internet exchanges. It became obvious that this was as a direct result of a visit from John Curran to a closed public sector meeting here in the Caribbean. Our Honorable Minister was obviously impressed with the outreach work by ARIN, to have called a stakeholders meeting so quickly after the briefing. His own team was fired up and anxious to know what they should be doing internally in the wake of runout. It was also good to know that my conversations with the said Minister over the last two years received support.Although I observed that our main network provider sat on the fence to some degree when asked what their plans were with reference to v4/v6 transition. I offered the following view: *Government agencies should provide IPv6-enabled content and services, encourage IPv6 deployment in their countries, and purchase IPv6-compliant hardware and software.* **Users and Govs alike should request IPv6 services from their ISPs and IT vendors.* So Govs, needs to do a little homework on their *content and services platforms* and *hardware and software*....In my estimation this is not about pulling teeth. Most, if not all software and software manufacturers will tell you, if asked, where you are compliant and where you are not compliant. Then you you install the fixes, and or provision for the procurement of compliant hardware/software where you need to. Then you an proclaim that you are "IPv6 ready" or at least decide that you want to be v6 compliant within a certain timescale and so detail a programme for doing so with some kind of budget. Once you have done the analysis of what you have and whats in the pipeline, you can make a good guess as to budget requirements...It could very well be mostly time related costs. You can also take this up with the Regional Management Office if there are plans in the pipeline for OECS wide content and hardware/software platforms. I am sure that Mr xxxx has a view on this. All Your providers (eg xxxx) should also be made aware that your *"policy"* is to be IPv6 compliant and request a time scale from them as to when they will offer "FULL IPv6 services" on their networks to their corporate and Gov. customers. The reality is that the adoption of v6 has been plagued with a wait and see attitude within the big networks industry. Of course, it is not in your interest to say: We will become compliant when our providers start offering "FULL IPv6 network services because they will likely be time phasing this in, and you can move towards compliance even if your network providers are not quite there yet. This way also, your technical staff will get a basic understanding of the V4 verses v6 addressing system which is never a bad thing. I hope the above will assist you. Ref: ICT advisory forum/ Civil society RD > Bill, > > Let me clarify: I think ARIN's informative outreach programs are > satisfactory. The people you want to reach are by and large receiving > your information. In fact, I think your information is reaching more > or less everyone who is interested. > > It's the participatory outreach that is falling flat with the AC's > collective behavior as the proximate cause. You're doing a poor job of > drawing people into the process and you're unnecessarily frustrating, > even driving away the ones who are already here. > > That's why my comments speak to enabling and encouraging participation > by the folks you've already reached but don't speak to reaching wider > audiences. I'm interested in fixing the part that's actually broken. > > Regards, > Bill Herrin > > > On Fri, May 28, 2010 at 9:48 PM, Bill Darte wrote: > > William, (as different from me) > > > > Your earlier emails talked about broader participation.? I thought you > meant > > more than those that currently review policy proposal. > > Everything below talks to the process of evaluating, not a broader group > of > > eyes. > > > > bd > > > > > > Bill, > > > > Conceptually the answer seems obvious enough: when all the informative > > efforts finally convince someone to step up and attempt to > > participate, DON'T SHUT THEM DOWN. > > > > As a member of the AC, some specific things you can personally do > > towards that end include: > > > > 1. Remove evaluation of a policy's worth from the decision to accept a > > proposal as a draft policy. Focus on whether the proposal describes > > "actionable" policy, not whether the action is a good one. Focus on > > helping the author revise it into actionable policy if it isn't > > already and then accept it as a draft policy. After accepting it as a > > draft, try to help the author revise it into the closest thing to > > passable policy possible while still preserving the proposal's intent. > > > > Let the wide community evaluate the proposal's worth. The AC can add > > it's two cents when and if the draft garners the consensus to move to > > last call. > > > > Members of the AC can add their two cents any time. But hold the group > > recommendation until after the whole community has spoken. > > > > > > 2. Let the proposal's author (or authors if proposals get merged) > > guide the AC's changes, at least to the extent of not making changes > > where the author advises that, "No, that goes against what the > > proposal is trying to accomplish." The PDP gives the AC the authority > > to revise draft policy. It doesn't tell you how you have to use that > > authority. You have the leeway to use it in a way that includes the > > author instead of excluding him. > > > > Of course, you actually have to accept the proposal as a draft policy > > first. This idea of "we reject you but please try again" is > > exclusionary BS and there's no amount of informative outreach that's > > going to make it anything other than BS. If you want to "soften" a > > rejection, don't issue it in the first place. > > > > One of the architects of Ultima Online famously said, "We want to > > minimize the down side of being dead." What a stupid idea! You only > > need to minimize the down side of being dead if you've unbalanced the > > game against the players. > > > > > > 3. Delay proposing policy. Post a PPML message saying, "We're thinking > > about policy which does X. What do y'all think? Would anyone like to > > take a stab at policy text?" and then wait until any discussion dies > > out without anyone else proposing a policy before an AC member does. > > > > I hate the idea of #3. In the IRPEP model it wasn't necessary and > > surely AC members are well qualified to write good policy proposals. > > But in the PDP's structure, when an AC member jumps on top of a new > > policy idea, it tends to drive the public out of the formative process > > right away, reducing them to mere commenters on the AC's policy > > instead of partners in the policy's creation. > > > > ICANN has public comment. Even the FCC has public comment on its > > rulemaking. Do those organizations have any meaningful public > > participation in their rulemaking? Hell no. Do you really want ARIN to > > become the IP address version of the FCC? > > > > > > Fundamentally, though, this is a process problem. The PDP enables and > > encourages a decision making process that solicits public comment but > > doesn't really solicit public participation, especially for the AC > > members whose natural tendency is to work behind the scenes. Unlike > > the IRPEP, which had some annoying surface problems, I think the PDP > > is broken at the core. > > > > 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. > > > > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > ------------------------------ > > Message: 2 > Date: Sat, 29 May 2010 08:12:00 -0400 > From: William Herrin > To: Owen DeLong > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Advisory Council Meeting Results - May 2010 > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, May 29, 2010 at 3:31 AM, Owen DeLong wrote: > > In this circumstance, given the number of different inputs to the process > > and the ambiguity of much of the input received, it is not always as > > easy as you might think for the AC to determine consensus, but, yes, > > usually it is. > > Owen, > > If you're not sure whether you have consensus then you don't. It only > gets complicated when you really want there to be consensus even > though there isn't. > > > >> The PDP is quite clear that the AC is charged with determining consensus > of > >> the community. In my experience, it is relatively easy to determine if > >> consensus exists. Achieving consensus may be monumentally difficult and > time > >> consuming but the determination of its existence is straightforward. > >> > >> As I understand the PDP, the AC is charged with the simpler task. > > > > The AC is charged with determining several things, consensus being > > but one of them. > > The AC is also effectively charged with making an independent > recommendation to the board as to whether a policy proposal would > improve ARIN. For any given proposal, it get's three chances to do > this within the process, only the first of which also functions to > discourage public participation. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 59, Issue 35 > ***************************************** > -- Rudi Daniel ICT4Dev consulting 1784 497 8676 Http://csisvg.ning.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From BillD at cait.wustl.edu Wed Jun 2 10:23:54 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 2 Jun 2010 09:23:54 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - May 2010 In-Reply-To: <51C46CB6-2093-43F4-90BE-294993923A11@paypal.com> References: <4BFC042B.1080600@arin.net> <4BFD11C4.3030301@chl.com><4BFD207C.1060706@gmail.com> <4BFE8628.8080001@chl.com><4BFFD4D8.4040001@chl.com><28E139F46D45AF49A31950F88C497458062FE617@E03MVZ2-UKDY.domain1.systemhost.net><39BF0C2785E4044E81A4D55B333D510661602E2DE9@DEN-MEXMS-001.corp.ebay.com><5BA22FB3-B6C2-4EB7-83CA-7D591AB1B20A@delong.com> <51C46CB6-2093-43F4-90BE-294993923A11@paypal.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Smith, Bill > Sent: Tuesday, June 01, 2010 9:06 PM > To: William Herrin > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Advisory Council Meeting Results - May 2010 > > > On May 29, 2010, at 5:12 AM, William Herrin wrote: > > On Sat, May 29, 2010 at 3:31 AM, Owen DeLong > > wrote: > In this circumstance, given the number of different inputs to > the process and the ambiguity of much of the input received, > it is not always as easy as you might think for the AC to > determine consensus, but, yes, usually it is. > > Owen, > > If you're not sure whether you have consensus then you don't. > It only gets complicated when you really want there to be > consensus even though there isn't. > > That's my point exactly. > > > > The PDP is quite clear that the AC is charged with > determining consensus of the community. In my experience, it > is relatively easy to determine if consensus exists. > Achieving consensus may be monumentally difficult and time > consuming but the determination of its existence is straightforward. > > As I understand the PDP, the AC is charged with the simpler task. > > The AC is charged with determining several things, consensus > being but one of them. > > The AC is also effectively charged with making an independent > recommendation to the board as to whether a policy proposal > would improve ARIN. For any given proposal, it get's three > chances to do this within the process, only the first of > which also functions to discourage public participation. > > >From the PDP, section 2 Draft Policy: "The Advisory Council > evaluates policy proposals and develops them into technically > sound and useful draft policies that, if adopted, will make a > positive contribution to the Number Resource Policy Manual." > And from section 1The Policy Proposal "Only policy proposals > that are developed into draft policies by the Advisory > Council, or successfully petitioned, will be discussed for > adoption on the PPML and at the public policy meeting." > > Here's the process as dictated by the two sentences above > from the PDP: > > The AC evaluates a submitted policy proposal. It makes some > determination based on that evaluation. If it is determined > that a policy proposal should be discussed on PPML, it is > developed into a sound, useful, and beneficial *draft > policy*. ( I don't believe the PDP dictates how the AC > performs this development, it simply requires that it do so.) > Only then is that draft policy discussed on PPML and at F2F > meetings - unless the policy proposal was petitioned. > > Once a draft policy is out for discussion, changes can be > suggested. Those suggestions should be evaluated for > soundness, utility, and positive impact and only those that > improve the draft policy should be accepted. The draft > proposal goes back to the AC and it again presumably looks at > soundness, utility, and benefit. It also determines consensus. > > With a good definition of consensus, even other than the > default unanimity, it really is rare for a group to disagree > on whether consensus has been reached on an issue, at least > in my experience. There can be considerable disagreement on > utility, technical soundness, and positive impact - and if > those disagreements are significant, sustained, widespread, > or otherwise recognized as not indicative of consensus, than > consensus doesn't exist. (Of course those holding such > opinions should be allowed to state that they do not object > to consensus being declared.) > > What is ARIN's definition of consensus? Is there a way > forward when consensus doesn't exist? The AC is empowered to move a policy forward or abandon it regardless of consensus. In my personal estimation, this should be a very rare occurrence at most. Obvious safeguards through petition exist for such a situation. bd > > _______________________________________________ > 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 Wed Jun 2 13:26:14 2010 From: info at arin.net (Member Services) Date: Wed, 02 Jun 2010 13:26:14 -0400 Subject: [arin-ppml] Policy Development Process - Submit policy proposals at any time Message-ID: <4C069436.7070000@arin.net> The ARIN Policy Development Process (PDP) allows for policy proposals to be submitted at any time. Even though there is no deadline, the PDP contains several time requirements: ? Policy originators need time to think about and write policy proposals, ? ARIN staff needs time to conduct the Clarity and Understanding review, ? The AC needs time to make a decision and create draft policy, ? ARIN staff and legal counsel must be given time to perform staff assessments, ? Draft policies must be posted to PPML at least 35 days prior to an ARIN meeting to be considered for that meeting?s agenda. Therefore, if you are considering submitting a policy proposal for consideration for the October ARIN Public Policy Meeting, the sooner you turn it in, the better. For important dates regarding the ARIN XXVI meeting, see: https://www.arin.net/participate/meetings/ARIN-XXVI/index.html The Policy Development Process, as well as the Policy Proposal Template are available at: https://www.arin.net/policy/pdp.html Policy proposals and draft policies under discussion are available at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) From marty at akamai.com Wed Jun 2 19:32:33 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 02 Jun 2010 19:32:33 -0400 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA Post Exhaustion (Version 2) Message-ID: Hello PPML; This is version 2 of the draft global v4 policy text that was previously posted for comments. It has incorporated significant feedback from a variety of participants from multiple communities. Additional comments, public or private, are welcome. We're collecting additional feedback until June 8, 2010 and possibly beyond depending upon the feedback. Best, -M< ~~~~~~include draft text Global Policy for IPv4 Allocations by the IANA Post Exhaustion Rationale: This policy defines the process for the allocation of IPv4 addresses post "Exhaustion Phase"[1]. In order to fulfill the requirements of this policy, the IANA must set up a reclamation pool to hold addresses in and distribute from in compliance with this policy. This policy establishes the process by which IPv4 addresses can be returned to and re-issued from The IANA post Exhaustion Phase. The intent of this policy is as follows: * Includes all post Exhaustion Phase address space returned to the IANA. * Allows allocations by the IANA from the Reclamation Pool once the Exhaustion Phase has been completed. * Defines "need" as the basis for further IPv4 allocations by the IANA. * Does not differentiate any class of IPv4 address space unless defined by RFC 1918. * Encourages the return of IPv4 address space by making this re-allocation process available. * Disallows transfers in the absence of an IPV4 Global Transfer Policy to neutralize transfer process inequities across RIR regions. * Applies to legacy IPv4 Address Space initially allocated by the IANA to users excluding RIR's and the addresses that RIR's may return directly. * Includes any length of fragments currently held by the IANA now or in the future. 1. Reclamation Pool Upon adoption of this IPv4 address policy by the ICANN Board of Directors, the IANA shall establish a Reclamation Pool to be utilized post RIR IPv4 exhaustion as defined in Section 5. As soon as the first RIR exhausts their inventory of IP address space, this Reclamation Pool will be declared active. 2. Returning Address Space to the IANA The IANA will accept all eligible address space that is offered for return. Eligible address space includes legacy address space and address space returned by the RIR to which it is assigned. 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Aggregates in the Reclamation Pool may be divided on a CIDR boundary to the longest minimum allocation or assignment of any of the RIR's in order to complete these allocations. Addresses that are left over will be held in the Reclamation Pool until additional IP addresses are returned, or a minimum allocation unit is achieved that allows continued allocations from the pool. 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool, an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of the RIR's policy defined minimum allocation unit. Any RIR that is are formed after this policy has been adopted by the ICANN Board of Directors is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 5. Reporting Requirements The IANA shall publish on at least a weekly basis a report that is publicly available which at a minimum details all address space that has been received and that has been allocated. The IANA shall publish a Returned Address Space Report which indicates what resources were returned, by who and when. The IANA shall publish an Allocations Report on at least a weekly basis which at a minimum indicates what IPv4 address space has been allocated, which RIR received the allocation and when. The IANA shall publish a public report confirming RIR eligibility subsequent to Section 4. 6. No Transfer Rights Address space assigned from the Reclamation Pool is not subject to transfer outside of a globally adopted transfer policy. The definition of Global Transfer Policy for the purpose of this policy is a policy that has been processed in compliance with the MoU [2] and attachments as agreed to in October 2004 between ICANN and the RIR's. 7. Definitions IANA - Internet Assigned Numbers Authority or it's successor ICANN - Internet Corporation for Assigned Names and Numbers or it's successor RIR - Regional Internet Registry as recognized by ICANN MOU - Memorandum of Understanding between ICANN and the RIR's IPV4 - Internet Protocol Version Four, the target protocol of this Global Policy 8. References 1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm Global Policy for the Allocation of the Remaining IPv4 Address Space, IANA, Retrieved 27 April 2010 2. http://www.nro.net/documents/aso-mou.html ICANN Address Supporting Organization (ASO) MoU , Retrieved 27 May 2010. -- Martin Hannigan http://www.akamai.com Akamai Technologies, Inc. marty at akamai.com Cambridge, MA USA cell: +16178216079 ofc: +16174442535 From bill at herrin.us Wed Jun 2 19:56:41 2010 From: bill at herrin.us (William Herrin) Date: Wed, 2 Jun 2010 19:56:41 -0400 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA Post Exhaustion (Version 2) In-Reply-To: References: Message-ID: On Wed, Jun 2, 2010 at 7:32 PM, Hannigan, Martin wrote: > ?2. Returning Address Space to the IANA > > The IANA will accept all eligible address space that is offered for return. > Eligible address space includes legacy address space and address space > returned by the RIR to which it is assigned. Hi Martin, You're stepping on a land mine here. Suggest something more along the lines of: Eligible address space includes any IPv4 addresses between 0.0.0.0 and 223.255.255.255 except those addresses excluded by RFC where the RIR (or registrant of record where no RIR holds authority) explicitly returns the space to IANA. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marty at akamai.com Wed Jun 2 20:51:36 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 02 Jun 2010 20:51:36 -0400 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA Post Exhaustion (Version 2) In-Reply-To: Message-ID: > From: William Herrin > Date: Wed, 2 Jun 2010 19:56:41 -0400 > To: Martin Hannigan > Cc: > Subject: Re: [arin-ppml] Global Policy for IPv4 Allocations by the IANA Post > Exhaustion (Version 2) > > On Wed, Jun 2, 2010 at 7:32 PM, Hannigan, Martin wrote: >> ?2. Returning Address Space to the IANA >> >> The IANA will accept all eligible address space that is offered for return. >> Eligible address space includes legacy address space and address space >> returned by the RIR to which it is assigned. > > Hi Martin, > > You're stepping on a land mine here. Suggest something more along the lines > of: > > Eligible address space includes any IPv4 addresses between 0.0.0.0 and > 223.255.255.255 except those addresses excluded by RFC where the RIR > (or registrant of record where no RIR holds authority) explicitly > returns the space to IANA. > How about something like this? "The IANA will accept all eligible address space that is offered for return. Eligible address space includes legacy address space and address space returned by the RIR to which it is assigned and not previously designated for special use by an RFC published by the IETF." That would allow deprecation of relevant RFC's to occur without having to circle back around and change the policy again. Best, -M< From cgrundemann at gmail.com Wed Jun 2 23:05:57 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 2 Jun 2010 21:05:57 -0600 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA Post Exhaustion (Version 2) In-Reply-To: References: Message-ID: On Wed, Jun 2, 2010 at 18:51, Hannigan, Martin wrote: > >> From: William Herrin >> >> Eligible address space includes any IPv4 addresses between 0.0.0.0 and >> 223.255.255.255 except those addresses excluded by RFC where the RIR >> (or registrant of record where no RIR holds authority) explicitly >> returns the space to IANA. > > How about something like this? > > "The IANA will accept all eligible address space that is offered for return. > Eligible address space includes legacy address space and address space > returned by the RIR to which it is assigned and not previously designated > for special use by an RFC published by the IETF." > I like Bill's use of "registrant of record where no RIR holds authority" as a replacement for "legacy address space." I also just realized that the policy doesn't explicitly state that returned space goes into the Reclamation Pool. With that in mind, I suggest this wording: The IANA will accept into the Reclamation Pool all eligible IPv4 address space that is offered for return. Eligible address space includes any addresses not previously designated for special use by an IETF published RFC explicitly offered for return to the IANA by: a) The RIR to which the space is assigned, or b) The registrant of record where no RIR holds authority. $.02 ~Chris > > That would allow deprecation of relevant RFC's to occur without having to > circle back around and change the policy again. > > > 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. -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From steve at ipv6canada.com Thu Jun 3 20:45:11 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Thu, 03 Jun 2010 20:45:11 -0400 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA Post Exhaustion (Version 2) In-Reply-To: References: Message-ID: <4C084C97.3090806@ipv6canada.com> On 2010.06.02 23:05, Chris Grundemann wrote: > I like Bill's use of "registrant of record where no RIR holds > authority" as a replacement for "legacy address space." I also just > realized that the policy doesn't explicitly state that returned space > goes into the Reclamation Pool. With that in mind, I suggest this > wording: > > The IANA will accept into the Reclamation Pool all eligible IPv4 > address space that is offered for return. If we're going for global change anyways, does my following change to your sentence make sense? Although it's only four letters, there is no room for interpretation: The IANA *must* accept into the Reclamation Pool all eligible IPv4 address space that is offered for return. Steve From cgrundemann at gmail.com Thu Jun 3 21:30:33 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 3 Jun 2010 19:30:33 -0600 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA Post Exhaustion (Version 2) In-Reply-To: References: <4C084C97.3090806@ipv6canada.com> Message-ID: Yes, I prefer 'shall' to 'must' myself but I think you're right about making it more definitive. ~Chris My Android sent this message. On Jun 3, 2010 6:45 PM, "Steve Bertrand" wrote: On 2010.06.02 23:05, Chris Grundemann wrote: > I like Bill's use of "registrant of record where no ... If we're going for global change anyways, does my following change to your sentence make sense? Although it's only four letters, there is no room for interpretation: The IANA *must* accept into the Reclamation Pool all eligible IPv4 address space that is offered for return. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at ipv6canada.com Thu Jun 3 21:34:37 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Thu, 03 Jun 2010 21:34:37 -0400 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA Post Exhaustion (Version 2) In-Reply-To: References: <4C084C97.3090806@ipv6canada.com> Message-ID: <4C08582D.1070309@ipv6canada.com> On 2010.06.03 21:30, Chris Grundemann wrote: > Yes, I prefer 'shall' to 'must' myself but I think you're right about > making it more definitive. Per RFC 2119, I'm content with "SHALL" as opposed to 'MUST'. Thanks Chris, Steve From michael.dillon at bt.com Fri Jun 4 04:33:59 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 Jun 2010 09:33:59 +0100 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA PostExhaustion (Version 2) In-Reply-To: References: <4C084C97.3090806@ipv6canada.com> Message-ID: <28E139F46D45AF49A31950F88C497458063DF9D3@E03MVZ2-UKDY.domain1.systemhost.net> >The IANA *must* accept into the Reclamation Pool all eligible IPv4 >address space that is offered for return. > >Yes, I prefer 'shall' to 'must' myself but I think you're right about making it more definitive. IANA is a creature of IETF and will interpret these policies according to IETF language standards. RFC 2119 says this: MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. That means that this change is neither more nor less definitive. It means exactly the same thing. I believe that this policy is not even needed and that it is too late to be making policies that take effect when Ipv4 runout occurs. --Michael Dillon -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Fri Jun 4 05:21:21 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 4 Jun 2010 10:21:21 +0100 Subject: [arin-ppml] Global Policy for IPv4 Allocations by the IANA PostExhaustion (Version 2) In-Reply-To: <9F276BE7-0C95-4CA8-910E-5C2D7DC4635E@delong.com> References: <4C084C97.3090806@ipv6canada.com> <28E139F46D45AF49A31950F88C497458063DF9D3@E03MVZ2-UKDY.domain1.systemhost.net> <9F276BE7-0C95-4CA8-910E-5C2D7DC4635E@delong.com> Message-ID: <28E139F46D45AF49A31950F88C497458063DFAA3@E03MVZ2-UKDY.domain1.systemhost.net> > > I believe that this policy is not even needed and that it is too late to be making policies > > that take effect when Ipv4 runout occurs. > I disagree. Absent some form of policy, there is no procedure for any space returned to IANA > which is less than a complete /8 to be delegated to RIRs and it would sit unused. You are free to believe that IANA is brain dead. I prefer to believe that they would not act in a patently stupid way. Even if policy did not exist, it would only take a few well-worded requests to ICANN to sort out that kind of problem. If you really want to get a global policy through that will solve this issue, then it should be simple. 1. IANA shall accept any Ipv4 blocks of whatever size that the RIRs wish to return. 2. IANA shall allocate returned blocks of any size, to RIRs that can make use of that space. --Michael Dillon -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Mon Jun 7 11:15:48 2010 From: info at arin.net (Member Services) Date: Mon, 07 Jun 2010 11:15:48 -0400 Subject: [arin-ppml] =?windows-1252?q?NRPM_2010=2E2_=96_New_Policy_Impleme?= =?windows-1252?q?nted?= Message-ID: <4C0D0D24.8030607@arin.net> On 1 July 2009 the ARIN Board of Trustees, based on the recommendation of the Advisory Council and noting that the Policy Development Process had been followed, adopted the following number resource policy: 2008-7: Identify Invalid WHOIS POC?s A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2010.2 contains the implementation of 2008-7. The new policy text can be found in the NRPM in Section 3.6 Annual WHOIS POC Validation. For more information on POC validation, please see: https://www.arin.net/resources/services/poc_validation.html NRPM version 2010.2 is effective 7 June 2010 and supersedes the previous version. See the Change Log for information regarding revisions to the policy manual. The NRPM is available at: https://www.arin.net/policy/nrpm.html The Change Log is available at: https://www.arin.net/policy/nrpm_changelog.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The PDP is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Fri Jun 11 09:56:20 2010 From: info at arin.net (Member Services) Date: Fri, 11 Jun 2010 09:56:20 -0400 Subject: [arin-ppml] Policy Proposal 115: Global Policy for IPv4 Allocations by the IANA Post Exhaustion Message-ID: <4C124084.5010502@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. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 115: Global Policy for IPv4 Allocations by the IANA Post Exhaustion Proposal Originator: Martin Hannigan on behalf of authors for ASO AC/NRO NC Proposal Version: 1.0 Date: 11 June 2010 Proposal type: new Policy term: permanent Policy statement: 1. Reclamation Pool Upon adoption of this IPv4 address policy by the ICANN Board of Directors, the IANA shall establish a Reclamation Pool to be utilized post RIR IPv4 exhaustion as defined in Section 5. As soon as the first RIR exhausts its inventory of IP address space, this Reclamation Pool will be declared active. 2. Returning Address Space to the IANA The IANA will accept into the Reclamation Pool all eligible IPv4 address space that is offered for return. Eligible address space includes any addresses not previously designated for special use by an IETF published RFC explicitly offered for return to the IANA by the RIR to which the space is assigned or the registrant of record where no RIR holds authority. 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Aggregates in the Reclamation Pool may be divided on a CIDR boundary to the longest minimum allocation or assignment of any of the RIRs in order to complete these allocations. Addresses that are left over will be held in the Reclamation Pool until additional adjacent IP addresses can be returned to rejoin addresses on CIDR boundaries to meet minumum allocation requirements, or a minimum allocation unit is set that allows continued allocations from the pool. 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool, an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of the RIR's policy defined minimum allocation unit. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 5. Reporting Requirements The IANA shall publish on at least a weekly basis a report that is publicly available which at a minimum details all address space that has been received and that has been allocated. The IANA shall publish a Returned Address Space Report which indicates what resources were returned, by whom and when. The IANA shall publish an Allocations Report on at least a weekly basis which at a minimum indicates what IPv4 address space has been allocated, which RIR received the allocation and when. The IANA shall publish a public notice confirming RIR eligibility subsequent to Section 4. 6. No Transfer Rights Address space assigned from the Reclamation Pool may be transferred if there is an ICANN Board ratified Global Transfer Policy in force at the time of the implementation of this policy. In the absence of an ICANN Board ratified Global Transfer Policy, no transfers are allowed. The definition of Global Transfer Policy for the purpose of this policy is a Global Policy that has been processed in compliance with the Memorandum of Understanding "MoU"[2] and Attachments as agreed to in October 2004 by ICANN and the RIRs and ratified by the ICANN Board of Directors. 7. Definitions IANA - Internet Assigned Numbers Authority, or its successor ICANN - Internet Corporation for Assigned Names and Numbers, or its successor RIR - Regional Internet Registry as recognized by ICANN MOU - Memorandum of Understanding between ICANN and the RIRs IPv4 - Internet Protocol Version Four(4), the target protocol of this Global Policy Free Space Pool - IPv4 Addresses that are in inventory at any RIR, and/or the IANA 8. Contributors The following individuals donated their time, resources and effort to develop this proposal on behalf of the Internet Community: Steve Bertrand Chris Grundemann Martin Hannigan Aaron Hughes Louie Lee Matt Pounsett Jason Schiller 9. References 1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm Global Policy for the Allocation of the Remaining IPv4 Address Space, IANA, Retrieved 27 April 2010 2. http://aso.icann.org/documents/memorandum-of-understanding/index.html ICANN Address Supporting Organization (ASO) MoU, Retrieved 27 May 2010. Rationale: This policy defines the process for the allocation of IPv4 addresses post "Exhaustion Phase"[1]. In order to fulfill the requirements of this policy, the IANA must set up a reclamation pool to hold addresses in and distribute from in compliance with this policy. This policy establishes the process by which IPv4 addresses can be returned to and re-issued from the IANA post Exhaustion Phase. This document does not stipulate performance requirements in the provision of services by the IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. The intent of this policy is as follows: * To include all post Exhaustion Phase IPv4 address space returned to the IANA. * Allows allocations by the IANA from the Reclamation Pool once the Exhaustion Phase has been completed. * Defines "need" as the basis for further IPv4 allocations by the IANA. * Does not differentiate any class of IPv4 address space unless otherwise defined by an RFC. * Encourage the return of IPv4 address space by making this allocation process available. * Disallow transfers of addresses sourced from the Reclamation Pool in the absence of an IPv4 Global Transfer Policy to neutralize transfer process inequities across RIR regions. * Applies to legacy IPv4 Address Space initially allocated by the IANA to users including the allocations to RIRs. * Includes any length of fragments currently held by the IANA now or in the future. Timetable for implementation: Immediate From info at arin.net Fri Jun 11 13:33:53 2010 From: info at arin.net (Member Services) Date: Fri, 11 Jun 2010 13:33:53 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - May 2010 - Petition Deadline In-Reply-To: <4C123465.2020601@arin.net> References: <4C123465.2020601@arin.net> Message-ID: <4C127381.7010805@arin.net> The Advisory Council's meeting minutes have been published for their 20 May 2010 meeting and are available at: https://www.arin.net/about_us/ac/ac2010_0520.html Per the messages below the deadline for petitions regarding any of the AC actions taken at their meeting is 18 June 2010. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Regards, Member Services American Registry for Internet Numbers (ARIN) > All - > > The deadline for petitions regarding any of the AC actions taken at > the 20 May 2010 meeting shall be extended from 2 June 2010 to 5 > business days after the publication of the AC minutes from the > meeting, as this will provide for appropriate time to review all > relevant materials on these decisions. > > We will continue this practice for future petition deadlines and > update the PDP accordingly at the next convenient opportunity. > > Thank you, > /John > > John Curran > President and CEO > ARIN > > On May 25, 2010, at 1:08 PM, Member Services wrote: > > > In accordance with the ARIN Policy Development Process (PDP), the ARIN > > > Advisory Council (AC) held a meeting on 20 May 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 policies: > > > > > > 2010-4: Rework of IPv6 allocation criteria > > > 2010-6: Simplified M&A transfer policy > > > > > > After last call the following draft policy remains on the AC's docket, > > > because it did not receive the required number of votes to move to last > > > call (The AC established a standing rule in January that requires an > > > affirmative vote of the majority of the members of the full Advisory > > > Council regarding any final action on draft policies): > > > > > > 2010-2: /24 End User Minimum Assignment Unit > > > > > > The AC accepted the following proposal on to the AC's docket for > > > development and evaluation: > > > > > > 113. IPv6 for 6rd > > > > > > The AC tabled making a decision about adding the following proposal to > > > the AC's docket until their next meeting: > > > > > > 111. IPv4 Fragment Management policy proposal > > > > > > The following items remain on the AC's docket for further development > > > and evaluation: > > > > > > 2010-1: Waiting List for Unmet IPv4 Requests > > > 2010-8: Rework of IPv6 assignment criteria > > > 109. Standardize IP Reassignment Registration Requirements > > > > > > The AC abandoned the following proposals: > > > > > > 110. Preservation of minimal IPv4 Resources for New and Small > > > Organizations and for IPv6 Transition > > > 112. Utilization of 10.4.2 resources only via explicit policy > > > 114. RFC1918 as initial ISP multihomed criteria > > > > > > The ARIN AC abandoned Proposal 110 "Preservation of minimal IPv4 > > > Resources for New and Small Organizations and for IPv6 Transition" due > > > to a lack of support on PPML, and because they felt that the proposal > > > was overly complicated." > > > > > > The AC abandoned Proposal 112 "Utilization of 10.4.2 resources only via > > > explicit policy" due to the proposed added restrictions to be placed > > > upon the resource allocation process. Additionally, there was not much > > > support on the PPML. > > > > > > The AC abandoned Proposal 114 "RFC 1918 as Initial Multi-Homed > > > Criteria" in light of the author's stated intent to drop the proposal > > > and the observation that the proposal has not received much support > on PPML. > > > > > > 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.? 2010-2 may be petitioned to try to move it to the > > > Board for review (see "Board of Trustees Consideration Petition" in the > > > PDP). The abandonment of proposals 110, 112 and 114 may be > petitioned to > > > try to change them into draft policies for discussion on the Public > > > Policy Mailing List and at the October meeting (Discussion Petition). > > > The deadline to begin a petition is 2 June 2010. > > > > > > 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, > > > > > > 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. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience > any issues. > From jmaimon at chl.com Thu Jun 17 12:02:06 2010 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 17 Jun 2010 12:02:06 -0400 Subject: [arin-ppml] Petitioning the abandonment of Policy Proposals 110 and 112 Message-ID: <4C1A46FE.70302@chl.com> All, I have chosen to petition the AC's abandonment of policy proposals 110 and 112, each with its own post accompanying this one. I believe that there is just enough time to do something of value for unallocated IPv4 address space, with this PDP cycle possibly the last good opportunity to do so. I believe it to be rational and reasonable to set aside address space if the potential for urgent need for it at a later date exists. I believe that potential exists. I do not consider it wise to allow the last of the unallocated space to be run through at nearly the same rate of consumption that consumed the vast majority of the previously available resources. I believe it strategic and important to demonstrate prudence and far sightedness in this manner, that the potential payoff far exceeds the immediate cost. Policy Proposal 110 is my view of what best should be done along this vein. I have also offered up Policy Proposal 112 as a complimentary alternative that allows the community to simply decide not to run through the last of the free pool resources immediately. The AC has decided they do not support the objectives and goals of the proposals. They have also decided that there is little to none in the way of community support either for the proposals on their merits or for continuing discussion and consideration of them. There have been and continue to be proposals and draft policies that achieve similar end results, partially or wholly, namely, that small resource holders may continue to receive unallocated resources from ARIN while larger ones cannot. Many of those have received considerable discussion and/or support and some have even been adopted. However, none are as deterministic, complete, structured and explicit in accomplishing these goals as PP#110, which I initially wrote in May 09. While I respect the work, opinions and intentions of the AC and its members, I believe it is prudent to appeal to the community and offer them this opportunity to voice support for continued discussion of the proposals. I respect suggestions that I split PP#110 into separate portions, with the goal of improving the existing 4.10 pool of /10 of IPv4 for IPv6 migration pool. However, in my view, any potential importance for improvements to the existing 4.10 would mean things have gone very badly, resulting in little enthusiasm on my part for that project. I further hesitate to inundate this community with a multitude of piecemeal proposals, many of which may serve little purpose other than to consume your time and attention. I lay no claims to any of the ideas or terminology in those proposals, those who like any portion therein should feel free to take them as their own. I continue to have concerns that the abandonment of these proposals is a reflection of a course change and bias with regards to IPv4 proposals as per the recent posting and ensuing discussions of the AC's clarifying position regarding IPv4 proposals, which was anything but clear to me and to which I continue to have doubts as to its extent and correctness. I would like the decision on these proposals and the objectives they encompass to rest first and foremost on the will of community, expressed here on this list, and hopefully at the public policy meeting as well. As such, I am soliciting your support for the petitions I have posted for both or either of proposals 110 and 112 to be advanced to draft policy state for further consideration and discussion. I will respect your decision in this matter. Thank you for time and consideration. Best, Joe From jmaimon at chl.com Thu Jun 17 12:02:25 2010 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 17 Jun 2010 12:02:25 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status Message-ID: <4C1A4711.3030204@chl.com> All, Following the AC's abandonment of Policy Proposal #112, I formally petition to advance to draft policy status the proposal and for it to be discussed at an upcoming ARIN Public Policy meeting. Statements of support for this petition would be greatly appreciated. Full policy text available at http://lists.arin.net/pipermail/arin-ppml/2010-April/017410.html Thanks, Joe From jmaimon at chl.com Thu Jun 17 12:02:50 2010 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 17 Jun 2010 12:02:50 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #110 to Draft Policy status Message-ID: <4C1A472A.1080702@chl.com> All, Following the AC's abandonment of Policy Proposal #110, I formally petition to advance to draft policy status the proposal and for it to be discussed at an upcoming ARIN Public Policy meeting. Statements of support for this petition would be greatly appreciated. Full policy text available at http://lists.arin.net/pipermail/arin-ppml/2010-April/017321.html Thanks, Joe From marty at akamai.com Thu Jun 17 12:14:51 2010 From: marty at akamai.com (Martin Hannigan) Date: Thu, 17 Jun 2010 12:14:51 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: <4C1A4711.3030204@chl.com> Message-ID: I'm not planning on supporting this petition. A /10 has already been set aside. The author could've instead suggested that 10.4 be increased to a /8, for example which is explicit. Unless I'm missing something, this is overly vague and without some more explicit use, unnecessary (IMHO) and one of the time sinks with v4 policy that we have been discussing ways to avoid. Best Regards, -M< On 6/17/10 12:02 PM, "Joe Maimon" wrote: > All, > > Following the AC's abandonment of Policy Proposal #112, I formally > petition to advance to draft policy status the proposal and for it to be > discussed at an upcoming ARIN Public Policy meeting. > > Statements of support for this petition would be greatly appreciated. > > Full policy text available at > > http://lists.arin.net/pipermail/arin-ppml/2010-April/017410.html > > Thanks, > Joe > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bensons at queuefull.net Thu Jun 17 12:28:08 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 17 Jun 2010 11:28:08 -0500 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: References: Message-ID: I also do not support this proposal. Holding address space in reserve as described in this policy has no clear benefit, and in practice may be harmful to other community efforts. Cheers, -Benson On 17 Jun 10, at 11:14 AM, Martin Hannigan wrote: > > > I'm not planning on supporting this petition. A /10 has already been set > aside. The author could've instead suggested that 10.4 be increased to a /8, > for example which is explicit. > > Unless I'm missing something, this is overly vague and without some more > explicit use, unnecessary (IMHO) and one of the time sinks with v4 policy > that we have been discussing ways to avoid. > > > > Best Regards, > > -M< > > > > > > > On 6/17/10 12:02 PM, "Joe Maimon" wrote: > >> All, >> >> Following the AC's abandonment of Policy Proposal #112, I formally >> petition to advance to draft policy status the proposal and for it to be >> discussed at an upcoming ARIN Public Policy meeting. >> >> Statements of support for this petition would be greatly appreciated. >> >> Full policy text available at >> >> http://lists.arin.net/pipermail/arin-ppml/2010-April/017410.html >> >> Thanks, >> Joe >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > 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 Thu Jun 17 12:56:33 2010 From: marty at akamai.com (Martin Hannigan) Date: Thu, 17 Jun 2010 12:56:33 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #110 to Draft Policy status In-Reply-To: <4C1A472A.1080702@chl.com> Message-ID: I'm not planning on supporting this one either. I can appreciate the concepts of helping small organizations with v6 transition, but this is the most complex proposal that I have ever read and it's difficult to ascertain what the author is actually trying to accomplish for the end-game. It also has the longest rationale that I have ever read. The composition of the AC includes smaller organizations and it was still abandoned. I think I trust the AC on this one all considered. Here's what happened at the relevant AC meeting: "It was moved by OD, and seconded by RS, that: The ARIN Advisory Council, having reviewed the proposal entitled ?Preservation of Minimal IPv4 Resources for New and Small Organizations and for IPv6 Transition??, abandons it. The Council requests that the President advise the community of the availability of the Petition Process." [ discussion ] https://www.arin.net/about_us/ac/ac2010_0520.html "The motion carried unanimously via roll call." Best Regards, -M< On 6/17/10 12:02 PM, "Joe Maimon" wrote: > All, > > Following the AC's abandonment of Policy Proposal #110, I formally > petition to advance to draft policy status the proposal and for it to be > discussed at an upcoming ARIN Public Policy meeting. > > Statements of support for this petition would be greatly appreciated. > > Full policy text available at > > http://lists.arin.net/pipermail/arin-ppml/2010-April/017321.html > > Thanks, > Joe > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Thu Jun 17 13:03:56 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 17 Jun 2010 12:03:56 -0500 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: <4C1A4711.3030204@chl.com> References: <4C1A4711.3030204@chl.com> Message-ID: On Thu, Jun 17, 2010 at 11:02 AM, Joe Maimon wrote: > Following the AC's abandonment of Policy Proposal #112, I formally petition > to advance to draft policy status the proposal and for it to be discussed at > an upcoming ARIN Public Policy meeting. If ARIN did not intend to allocate that /8, then the IANA should take that last /8 back, and assign to another RIR, as (in that case) ARIN clearly had no justified need for applying for a /8 that it does not have a policy of allocating. I do not support this petition. I believe the rationale for this proposal is not satisfactory, and the AC is correct to abandon. If the author could include a compelling statement regarding how the last /8 is to be used, and a very good reason that usage isn't immediately to be put into policy as allowed, then, there might be a basis for the community to further consider the proposal. If you feel the /8 should be allocated in a different manner, or that it would be prudent to allocate new addresses in a different manner, then it would be more useful to have a proposal to that effect. ARIN's role is not to prevent free IP addresses in its pool from being properly allocated, just because it is about to run out. -- -JH From jmaimon at chl.com Thu Jun 17 13:45:36 2010 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 17 Jun 2010 13:45:36 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: References: <4C1A4711.3030204@chl.com> Message-ID: <4C1A5F40.1070103@chl.com> James Hess wrote: > On Thu, Jun 17, 2010 at 11:02 AM, Joe Maimon wrote: > > >> Following the AC's abandonment of Policy Proposal #112, I formally petition >> to advance to draft policy status the proposal and for it to be discussed at >> an upcoming ARIN Public Policy meeting. >> > If ARIN did not intend to allocate that /8, then the IANA should > take that last /8 back, and assign to another RIR, > as (in that case) ARIN clearly had no justified need for applying > for a /8 that it does not have a policy of allocating. > That last /8 is the one automatically given out upon depletion, not one given to ARIN due to application of need. From bill at herrin.us Thu Jun 17 14:22:37 2010 From: bill at herrin.us (William Herrin) Date: Thu, 17 Jun 2010 14:22:37 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: <4C1A4711.3030204@chl.com> References: <4C1A4711.3030204@chl.com> Message-ID: On Thu, Jun 17, 2010 at 12:02 PM, Joe Maimon wrote: > Following the AC's abandonment of Policy Proposal #112, I formally petition > to advance to draft policy status the proposal and for it to be discussed at > an upcoming ARIN Public Policy meeting. > > Statements of support for this petition would be greatly appreciated. > > Full policy text available at > http://lists.arin.net/pipermail/arin-ppml/2010-April/017410.html I SUPPORT the petition to advance proposal 112 to formal discussion on PPML and at the October meeting. William Herrin, speaking for myself. I SUPPORT the petition for two reasons: 1. This is an elegantly simple proposal. It would serve well as a proxy for whether *any* IPv4 reservation proposals are acceptable to the community. Independent of support for the proposal itself, the community should have the opportunity to offer clear guidance to ARIN regarding the general class of reservation proposals as a whole. Prior reservation proposals were too complex to clearly differentiate between the folks who disliked the concept of reservation and the folks who merely objected to the specifics. 2. My Verizon blackberry holds a globally routable IP address. As far as I know, no software I can get for it is incompatible with NAT. Nevertheless, in a known scarcity environment Verizon has deployed a globally routable IP address to my blackberry. Sloppiness? Maybe. But my opinion is that stashing addresses on cell phones is a convenient way to hoard IPv4 addresses while remaining in full compliance with current policy. 112's author has a point when he says, "No reason to blow the last /8 as quickly as all the others." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From info at arin.net Thu Jun 17 16:15:17 2010 From: info at arin.net (Member Services) Date: Thu, 17 Jun 2010 16:15:17 -0400 Subject: [arin-ppml] Petition Underway - Policy Proposal 110. Preservation of minimal IPv4 Resources for New and Small Organizations and for IPv6 Transition - Time Sensitive Message-ID: <4C1A8255.3070205@arin.net> With the message below a petition has started regarding the ARIN Advisory Council's decision to abandon Policy Proposal 110. Preservation of minimal IPv4 Resources for New and Small Organizations and for IPv6 Transition. ARIN staff posted on 25 May 2010 to PPML that the ARIN Advisory Council (AC) had decided to abandon the proposal. If successful, this petition will change Proposal 110 into a Draft Policy which will be published for discussion and review by the community on the PPML and at the Public Policy Meeting in October. 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. Point of contact information is required, either to the entire PPML or with a follow up post to petition at arin.net with full POC information (name, organization, street address, email, phone). The duration of the petition is five business days; it will end on 24 June 2010. 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, 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 Joe Maimon > Sent: Thursday, June 17, 2010 12:03 PM > To: ppml >> "ppml at arin.net" > Subject: [arin-ppml] Petition for advancement of Policy Proposal #110 > to Draft Policy status > > All, > > Following the AC's abandonment of Policy Proposal #110, I formally > petition to advance to draft policy status the proposal and for it to > be > discussed at an upcoming ARIN Public Policy meeting. > > Statements of support for this petition would be greatly appreciated. > > Full policy text available at > > http://lists.arin.net/pipermail/arin-ppml/2010-April/017321.html > > Thanks, > Joe > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From info at arin.net Thu Jun 17 16:15:44 2010 From: info at arin.net (Member Services) Date: Thu, 17 Jun 2010 16:15:44 -0400 Subject: [arin-ppml] Petition Underway - Policy Proposal 112. Utilization of 10.4.2 resources only via explicit policy - Time Sensitive Message-ID: <4C1A8270.2070102@arin.net> With the message below a petition has started regarding the ARIN Advisory Council's decision to abandon Policy Proposal 112. Utilization of 10.4.2 resources only via explicit policy. ARIN staff posted on 25 May 2010 to PPML that the ARIN Advisory Council (AC) had decided to abandon the proposal. If successful, this petition will change Proposal 112 into a Draft Policy which will be published for discussion and review by the community on the PPML and at the Public Policy Meeting in October. 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. Point of contact information is required, either to the entire PPML or with a follow up post to petition at arin.net with full POC information (name, organization, street address, email, phone). The duration of the petition is five business days; it will end on 24 June 2010. 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, 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 Joe Maimon > Sent: Thursday, June 17, 2010 12:02 PM > To: ppml at arin.net > Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 > to Draft Policy status > > All, > > Following the AC's abandonment of Policy Proposal #112, I formally > petition to advance to draft policy status the proposal and for it to > be > discussed at an upcoming ARIN Public Policy meeting. > > Statements of support for this petition would be greatly appreciated. > > Full policy text available at > > http://lists.arin.net/pipermail/arin-ppml/2010-April/017410.html > > Thanks, > Joe > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Thu Jun 17 17:38:22 2010 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 17 Jun 2010 17:38:22 -0400 Subject: [arin-ppml] Petitioning the abandonment of Policy Proposals 110 and 112 In-Reply-To: <4C1A46FE.70302@chl.com> References: <4C1A46FE.70302@chl.com> Message-ID: <75822E125BCB994F8446858C4B19F0D705B24FB0FD@SUEX07-MBX-04.ad.syr.edu> FYI Run on IPv4 addresses could exhaust supply by December Broadband, wireless adoption in Asia driving demand for unique IP addresses By Carolyn Duffy Marsan, Network World June 17, 2010 10:58 AM ET The remaining pool of unallocated IPv4 addresses could be depleted as early as December due to unprecedented levels of broadband and wireless adoption in the Asia Pacific region, experts say. http://www.networkworld.com/news/2010/061710-ipv4-addresses.html?fsrc=netflash-rss --MM ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Joe Maimon [jmaimon at chl.com] Sent: Thursday, June 17, 2010 12:02 PM To: ppml at arin.net Subject: [arin-ppml] Petitioning the abandonment of Policy Proposals 110 and 112 All, I have chosen to petition the AC's abandonment of policy proposals 110 and 112, each with its own post accompanying this one. I believe that there is just enough time to do something of value for unallocated IPv4 address space, with this PDP cycle possibly the last good opportunity to do so. I believe it to be rational and reasonable to set aside address space if the potential for urgent need for it at a later date exists. I believe that potential exists. I do not consider it wise to allow the last of the unallocated space to be run through at nearly the same rate of consumption that consumed the vast majority of the previously available resources. I believe it strategic and important to demonstrate prudence and far sightedness in this manner, that the potential payoff far exceeds the immediate cost. Policy Proposal 110 is my view of what best should be done along this vein. I have also offered up Policy Proposal 112 as a complimentary alternative that allows the community to simply decide not to run through the last of the free pool resources immediately. The AC has decided they do not support the objectives and goals of the proposals. They have also decided that there is little to none in the way of community support either for the proposals on their merits or for continuing discussion and consideration of them. There have been and continue to be proposals and draft policies that achieve similar end results, partially or wholly, namely, that small resource holders may continue to receive unallocated resources from ARIN while larger ones cannot. Many of those have received considerable discussion and/or support and some have even been adopted. However, none are as deterministic, complete, structured and explicit in accomplishing these goals as PP#110, which I initially wrote in May 09. While I respect the work, opinions and intentions of the AC and its members, I believe it is prudent to appeal to the community and offer them this opportunity to voice support for continued discussion of the proposals. I respect suggestions that I split PP#110 into separate portions, with the goal of improving the existing 4.10 pool of /10 of IPv4 for IPv6 migration pool. However, in my view, any potential importance for improvements to the existing 4.10 would mean things have gone very badly, resulting in little enthusiasm on my part for that project. I further hesitate to inundate this community with a multitude of piecemeal proposals, many of which may serve little purpose other than to consume your time and attention. I lay no claims to any of the ideas or terminology in those proposals, those who like any portion therein should feel free to take them as their own. I continue to have concerns that the abandonment of these proposals is a reflection of a course change and bias with regards to IPv4 proposals as per the recent posting and ensuing discussions of the AC's clarifying position regarding IPv4 proposals, which was anything but clear to me and to which I continue to have doubts as to its extent and correctness. I would like the decision on these proposals and the objectives they encompass to rest first and foremost on the will of community, expressed here on this list, and hopefully at the public policy meeting as well. As such, I am soliciting your support for the petitions I have posted for both or either of proposals 110 and 112 to be advanced to draft policy state for further consideration and discussion. I will respect your decision in this matter. Thank you for time and consideration. Best, Joe _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From john.sweeting at twcable.com Thu Jun 17 18:43:12 2010 From: john.sweeting at twcable.com (Sweeting, John) Date: Thu, 17 Jun 2010 18:43:12 -0400 Subject: [arin-ppml] Petitioning the abandonment of Policy Proposals 110 and 112 Message-ID: <6C245EFEC0ABBD4E8C810D9BAE4E269D543042A5@PRVPEXVS10.corp.twcable.com> Hi Milton, In respect to the petition are you supporting? Or no? Thanks. Thanks John +++ ----- Original Message ----- From: arin-ppml-bounces at arin.net To: Joe Maimon ; ppml at arin.net Sent: Thu Jun 17 17:38:22 2010 Subject: Re: [arin-ppml] Petitioning the abandonment of Policy Proposals 110 and 112 FYI Run on IPv4 addresses could exhaust supply by December Broadband, wireless adoption in Asia driving demand for unique IP addresses By Carolyn Duffy Marsan, Network World June 17, 2010 10:58 AM ET The remaining pool of unallocated IPv4 addresses could be depleted as early as December due to unprecedented levels of broadband and wireless adoption in the Asia Pacific region, experts say. http://www.networkworld.com/news/2010/061710-ipv4-addresses.html?fsrc=netflash-rss --MM ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Joe Maimon [jmaimon at chl.com] Sent: Thursday, June 17, 2010 12:02 PM To: ppml at arin.net Subject: [arin-ppml] Petitioning the abandonment of Policy Proposals 110 and 112 All, I have chosen to petition the AC's abandonment of policy proposals 110 and 112, each with its own post accompanying this one. I believe that there is just enough time to do something of value for unallocated IPv4 address space, with this PDP cycle possibly the last good opportunity to do so. I believe it to be rational and reasonable to set aside address space if the potential for urgent need for it at a later date exists. I believe that potential exists. I do not consider it wise to allow the last of the unallocated space to be run through at nearly the same rate of consumption that consumed the vast majority of the previously available resources. I believe it strategic and important to demonstrate prudence and far sightedness in this manner, that the potential payoff far exceeds the immediate cost. Policy Proposal 110 is my view of what best should be done along this vein. I have also offered up Policy Proposal 112 as a complimentary alternative that allows the community to simply decide not to run through the last of the free pool resources immediately. The AC has decided they do not support the objectives and goals of the proposals. They have also decided that there is little to none in the way of community support either for the proposals on their merits or for continuing discussion and consideration of them. There have been and continue to be proposals and draft policies that achieve similar end results, partially or wholly, namely, that small resource holders may continue to receive unallocated resources from ARIN while larger ones cannot. Many of those have received considerable discussion and/or support and some have even been adopted. However, none are as deterministic, complete, structured and explicit in accomplishing these goals as PP#110, which I initially wrote in May 09. While I respect the work, opinions and intentions of the AC and its members, I believe it is prudent to appeal to the community and offer them this opportunity to voice support for continued discussion of the proposals. I respect suggestions that I split PP#110 into separate portions, with the goal of improving the existing 4.10 pool of /10 of IPv4 for IPv6 migration pool. However, in my view, any potential importance for improvements to the existing 4.10 would mean things have gone very badly, resulting in little enthusiasm on my part for that project. I further hesitate to inundate this community with a multitude of piecemeal proposals, many of which may serve little purpose other than to consume your time and attention. I lay no claims to any of the ideas or terminology in those proposals, those who like any portion therein should feel free to take them as their own. I continue to have concerns that the abandonment of these proposals is a reflection of a course change and bias with regards to IPv4 proposals as per the recent posting and ensuing discussions of the AC's clarifying position regarding IPv4 proposals, which was anything but clear to me and to which I continue to have doubts as to its extent and correctness. I would like the decision on these proposals and the objectives they encompass to rest first and foremost on the will of community, expressed here on this list, and hopefully at the public policy meeting as well. As such, I am soliciting your support for the petitions I have posted for both or either of proposals 110 and 112 to be advanced to draft policy state for further consideration and discussion. I will respect your decision in this matter. Thank you for time and consideration. Best, Joe _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ 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 marty at akamai.com Thu Jun 17 18:55:23 2010 From: marty at akamai.com (Martin Hannigan) Date: Thu, 17 Jun 2010 18:55:23 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: Message-ID: On 6/17/10 2:22 PM, "William Herrin" wrote: > On Thu, Jun 17, 2010 at 12:02 PM, Joe Maimon wrote: >> Following the AC's abandonment of Policy Proposal #112, I formally petition >> to advance to draft policy status the proposal and for it to be discussed at >> an upcoming ARIN Public Policy meeting. >> >> Statements of support for this petition would be greatly appreciated. >> >> Full policy text available at >> http://lists.arin.net/pipermail/arin-ppml/2010-April/017410.html > > I SUPPORT the petition to advance proposal 112 to formal discussion on > PPML and at the October meeting. William Herrin, speaking for myself. > > I SUPPORT the petition for two reasons: > > 1. This is an elegantly simple proposal. It would serve well as a > proxy for whether *any* IPv4 reservation proposals are acceptable to > the community. Independent of support for the proposal itself, the > community should have the opportunity to offer clear guidance to ARIN > regarding the general class of reservation proposals as a whole. Prior > reservation proposals were too complex to clearly differentiate > between the folks who disliked the concept of reservation and the > folks who merely objected to the specifics. I thought that we already had a reservation proposal that had been accepted? 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment No? > > 2. My Verizon blackberry holds a globally routable IP address. As far > as I know, no software I can get for it is incompatible with NAT. > Nevertheless, in a known scarcity environment Verizon has deployed a > globally routable IP address to my blackberry. Sloppiness? Maybe. But > my opinion is that stashing addresses on cell phones is a convenient > way to hoard IPv4 addresses while remaining in full compliance with > current policy. I think that you are wrong about this. My Blackberry address is owned by RIM, not AT*T. OrgName: Research In Motion Limited OrgID: RIM-9 Address: 295 Phillip Street City: Waterloo StateProv: ON PostalCode: N2L-3W8 Country: CA NetRange: 216.9.240.0 - 216.9.255.255 CIDR: 216.9.240.0/20 NetName: RIM-NET-02 You can figure the rest out for yourself I suppose. Avoiding RFC 1918 collisions from on-net to off-net, etc. etc. etc. This doesn't seem like a well qualified reason to support a petition, IMHO. > 112's author has a point when he says, "No reason to > blow the last /8 as quickly as all the others." Sure, but what does the proposal say that the rest of us aren't already? Best Regards, -M< From jmaimon at chl.com Thu Jun 17 19:35:22 2010 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 17 Jun 2010 19:35:22 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: References: Message-ID: <4C1AB13A.4010906@chl.com> marty at akamai.com wrote: > > On 6/17/10 2:22 PM, "William Herrin" wrote: > >> 112's author has a point when he says, "No reason to >> blow the last /8 as quickly as all the others." > > Sure, but what does the proposal say that the rest of us aren't already? > > > Best Regards, > > -M< > Not to. Joe From bill at herrin.us Thu Jun 17 20:45:33 2010 From: bill at herrin.us (William Herrin) Date: Thu, 17 Jun 2010 20:45:33 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: References: Message-ID: On Thu, Jun 17, 2010 at 6:55 PM, Martin Hannigan wrote: > On 6/17/10 2:22 PM, "William Herrin" wrote: >> 1. This is an elegantly simple proposal. It would serve well as a >> proxy for whether *any* IPv4 reservation proposals are acceptable to >> the community. Independent of support for the proposal itself, the >> community should have the opportunity to offer clear guidance to ARIN >> regarding the general class of reservation proposals as a whole. Prior >> reservation proposals were too complex to clearly differentiate >> between the folks who disliked the concept of reservation and the >> folks who merely objected to the specifics. > > I thought that we already had a reservation proposal that had been accepted? > 4.10 ?Dedicated IPv4 block to facilitate IPv6 Deployment > No? Point taken. Though I don't know how much community guidance you can have received from a PPML discussion that primarily revolved around metric versus imperial units of measure. Did even 10 people outside of the board and AC offer germane comments let alone voice support or opposition? AFAICT, 2008-5 slid under the radar. > I think that you are wrong about this. My Blackberry address is owned ?by > RIM, not AT*T. And mine is owned by Verizon. From just one of their blocks, a /9. I do at least *try* to check my facts before posting them. whois 97.240.162.37 OrgName: Cellco Partnership DBA Verizon Wireless OrgID: CLLC Address: 180 Washington Valley Road City: Bedminster StateProv: NJ PostalCode: 07039 Country: US NetRange: 97.128.0.0 - 97.255.255.255 CIDR: 97.128.0.0/9 NetName: WIRELESSDATANETWORK RegDate: 2008-04-14 The blackberry claims it's also holding 206.51.26.162 from RIM but I can't independently verify that... Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marty at akamai.com Fri Jun 18 01:55:37 2010 From: marty at akamai.com (Martin Hannigan) Date: Fri, 18 Jun 2010 01:55:37 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: Message-ID: On 6/17/10 8:45 PM, "William Herrin" wrote: [ clip ] > > And mine is owned by Verizon. From just one of their blocks, a /9. I > do at least *try* to check my facts before posting them. > > whois 97.240.162.37 > > OrgName: Cellco Partnership DBA Verizon Wireless > OrgID: CLLC > Address: 180 Washington Valley Road > City: Bedminster > StateProv: NJ > PostalCode: 07039 > Country: US > > NetRange: 97.128.0.0 - 97.255.255.255 > CIDR: 97.128.0.0/9 > NetName: WIRELESSDATANETWORK > RegDate: 2008-04-14 > > The blackberry claims it's also holding 206.51.26.162 from RIM but I > can't independently verify that... > I think the larger point is that backseat driving while posting to PPML is dangerous. YMMV. Best, Marty From bill at herrin.us Fri Jun 18 02:27:10 2010 From: bill at herrin.us (William Herrin) Date: Fri, 18 Jun 2010 02:27:10 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #112 to Draft Policy status In-Reply-To: References: Message-ID: On Fri, Jun 18, 2010 at 1:55 AM, Martin Hannigan wrote: > On 6/17/10 8:45 PM, "William Herrin" wrote: >> And mine is owned by Verizon. From just one of their blocks, a /9. I >> do at least *try* to check my facts before posting them. >> >> whois 97.240.162.37 >> >> The blackberry claims it's also holding 206.51.26.162 from RIM but I >> can't independently verify that... > > > I think the larger point is that backseat driving while posting to PPML is > dangerous. YMMV. Marty, Is that not fundamentally what a reservation proposal is about? Determining that folks with conspicuously consumptive behavior should have limited access to a resource in short supply? Finding, as a community, that careless consumption by our members is not in our overall best interests? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From info at arin.net Fri Jun 18 10:21:40 2010 From: info at arin.net (Member Services) Date: Fri, 18 Jun 2010 10:21:40 -0400 Subject: [arin-ppml] Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10 Message-ID: <4C1B80F4.8050208@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. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10 Proposal Originator: Owen DeLong Proposal Version: 1 Date: 18 June 2010 Proposal type: modify Policy term: permanent Policy statement: Add the following to section 4.10 of the NRPM 6. No organization may receive more than 16 /24 equivalents under this section. Add the following to section 4 of the NRPM 4.11 Required utilization for subsequent allocation under section 4.10 No organization shall receive more than one allocation or assignment under section 4.10 unless all prior space issued under 4.10 meets the utilization requirements of this section. 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. 2. All utilization must be permitted under section 4.12 3. All prior 4.10 allocation/assignments must be at least 90% utilized. 4.12 Permitted uses of allocations or assignments under section 4.10 No organization shall use space received under section 4.10 for any purpose other than as specified in this section 1. To provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/AFTeR d. DNS64 or other transitional DNS enablers e. etc. 2. For other transitional technologies not envisioned at the time of this proposal, but, in no case for general IPv4 addressing provided to customers. Rationale: The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies. Timetable for implementation: immediate For reference, here is the current text of 4.10 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block. In order to receive an allocation or assignment under this policy: 1. the applicant may not have received resources under this policy in the preceding six months; 2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy; 3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments; 4. the applicant must demonstrate that no other allocations or assignments will meet this need; 5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations. From bill at herrin.us Fri Jun 18 11:14:33 2010 From: bill at herrin.us (William Herrin) Date: Fri, 18 Jun 2010 11:14:33 -0400 Subject: [arin-ppml] Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: <4C1B80F4.8050208@arin.net> References: <4C1B80F4.8050208@arin.net> Message-ID: On Fri, Jun 18, 2010 at 10:21 AM, Member Services wrote: > Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10 > > Add the following to section 4.10 of the NRPM > > 6. No organization may receive more than 16 /24 equivalents under this > section. Suggest something along the lines of "no organization or collection of affiliated organizations." ARIN won't have tools to evaluate "affiliated organizations" up front but it can be in a sense practiced in the breach, that is for revoking addresses when fraud is reported. Regards, Bill -- 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 Fri Jun 18 11:35:50 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 18 Jun 2010 09:35:50 -0600 Subject: [arin-ppml] Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: <4C1B80F4.8050208@arin.net> References: <4C1B80F4.8050208@arin.net> Message-ID: On Fri, Jun 18, 2010 at 08:21, Member Services wrote: > 4.11 Required utilization for subsequent allocation under section 4.10 ... > 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. > 2. All utilization must be permitted under section 4.12 > 3. All prior 4.10 allocation/assignments must be at least 90% utilized. I think a number four is needed: "4. All utilization details must be provided to ARIN." > 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment I think there is a bit of housekeeping needed in the existing text for this proposal to be sound: > In order to receive an allocation or assignment under this policy: Add: "1. It's proposed use must be permitted under section 4.12" > 1. the applicant may not have received resources... Make that 2. > 2. previous allocations/assignments under this policy must continue to > meet the justification requirements of this policy; Edit: "3. previous allocations/assignments under this policy must continue to meet the justification requirements of section 4.12;" > 3. previous allocations/assignments under this policy must meet the > utilization requirements of end user assignments; Edit: "4. previous allocations/assignments under this policy must meet the utilization requirements defined in section 4.11;" > 4. the applicant must demonstrate that no other... > 5. on subsequent allocation under this policy, ARIN staff... Bump those to 5. and 6. $0.02 ~Chris > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From owen at delong.com Fri Jun 18 13:05:23 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Jun 2010 10:05:23 -0700 Subject: [arin-ppml] Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: References: <4C1B80F4.8050208@arin.net> Message-ID: <9699BC7B-EBCB-4646-8695-37BF44F613CE@delong.com> On Jun 18, 2010, at 8:35 AM, Chris Grundemann wrote: > On Fri, Jun 18, 2010 at 08:21, Member Services wrote: >> 4.11 Required utilization for subsequent allocation under section 4.10 > ... >> 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. >> 2. All utilization must be permitted under section 4.12 >> 3. All prior 4.10 allocation/assignments must be at least 90% utilized. > > I think a number four is needed: "4. All utilization details must be > provided to ARIN." > I believe that is already required elsewhere in policy. > >> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment > > I think there is a bit of housekeeping needed in the existing text for > this proposal to be sound: > >> In order to receive an allocation or assignment under this policy: > > Add: "1. It's proposed use must be permitted under section 4.12" OK, I'll try and incorporate this (and the related changes) in the next version. >> 1. the applicant may not have received resources... > > Make that 2. > >> 2. previous allocations/assignments under this policy must continue to >> meet the justification requirements of this policy; > > Edit: "3. previous allocations/assignments under this policy must > continue to meet the justification requirements of section 4.12;" > >> 3. previous allocations/assignments under this policy must meet the >> utilization requirements of end user assignments; > > Edit: "4. previous allocations/assignments under this policy must meet > the utilization requirements defined in section 4.11;" > >> 4. the applicant must demonstrate that no other... >> 5. on subsequent allocation under this policy, ARIN staff... > > Bump those to 5. and 6. > > > $0.02 > ~Chris > >> _______________________________________________ >> 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 > _______________________________________________ > 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 Fri Jun 18 13:59:06 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 18 Jun 2010 11:59:06 -0600 Subject: [arin-ppml] Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: <9699BC7B-EBCB-4646-8695-37BF44F613CE@delong.com> References: <4C1B80F4.8050208@arin.net> <9699BC7B-EBCB-4646-8695-37BF44F613CE@delong.com> Message-ID: On Fri, Jun 18, 2010 at 11:05, Owen DeLong wrote: > > On Jun 18, 2010, at 8:35 AM, Chris Grundemann wrote: >> I think a number four is needed: "4. All utilization details must be >> provided to ARIN." >> > I believe that is already required elsewhere in policy. It is, but since you are writing new utilization requirements for this reserved block, I don't believe that this section would adopt requirements from (now unrelated) other sections of policy. >> Add: "1. It's proposed use must be permitted under section 4.12" > > OK, I'll try and incorporate this (and the related changes) in the next > version. Great! ~Chris >> _______________________________________________ >> 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 mueller at syr.edu Sat Jun 19 09:21:51 2010 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 19 Jun 2010 09:21:51 -0400 Subject: [arin-ppml] Petitioning the abandonment of Policy Proposals 110 and 112 In-Reply-To: <6C245EFEC0ABBD4E8C810D9BAE4E269D543042A5@PRVPEXVS10.corp.twcable.com> References: <6C245EFEC0ABBD4E8C810D9BAE4E269D543042A5@PRVPEXVS10.corp.twcable.com> Message-ID: <75822E125BCB994F8446858C4B19F0D705C7E16971@SUEX07-MBX-04.ad.syr.edu> Neither, sorry. It was an information point that I thought some might find relevant in making up their mind. > -----Original Message----- > > In respect to the petition are you supporting? Or no? Thanks. > > Thanks > John > From info at arin.net Mon Jun 21 08:39:29 2010 From: info at arin.net (Member Services) Date: Mon, 21 Jun 2010 08:39:29 -0400 Subject: [arin-ppml] Policy Proposal 117: Required Resource Reviews Message-ID: <4C1F5D81.8040305@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. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 117: Required Resource Reviews Proposal Originator: Owen DeLong Proposal Version: 1 Date: 21 June 2010 Proposal type: new Policy term: permanent Policy statement: Replace the text "under sections 4-6" in section 12, paragraph 7 with "under paragraphs 12.4 through 12.6" Add to section 12 the following text: 10. Except as provided below, resource reviews are conducted at the discretion of the ARIN staff. In any of the circumstances mentioned below, a resource review must be initiated by ARIN staff: a. Report or discovery of an acquisition, merger, transfer, trade or sale in which the infrastructure and customer base of a network move from one organization to another organization, but, the applicable IP resources are not transferred. In this case, the organization retaining the IP resources must be reviewed. The organization receiving the customers may also be reviewed at the discretion of the ARIN staff. b. Upon receipt by ARIN of one or more credible reports of fraud or abuse of an IP address block. The credibility of a report shall be determined by ARIN staff. If staff determines a report is not sufficiently credible, the reporter may appeal the decision to the ARIN CEO. In this case, the decision of the CEO shall be final. c.Upon receipt by ARIN of five or more reports from separate individuals representing at least three separate organizations of fraud or abuse for the same organization or the same IP address block. d. In the case where an organization wishes to act as recipient of resources pursuant to a transfer under section 8.3, unless otherwise prohibited by paragraph 12.2(c). e. An organization which submits a request for additional resources when more than 25% of their existing resources are obscured in SWIP or RWHOIS pursuant to section 4.2.3.7.6 (residential customer privacy). Rationale: The first change is a minor correction which improves clarity and consistency of the original policy without changing the meaning. The addition of 12.10 (a) through (e) serves to create a set of circumstances under which a resource review is required, rather than optional and entirely at ARIN staff discretion. The majority of early comments on this proposal focused on 12.10 (e). Mostly it was confusion about the exact ramifications. This section will cause ARIN to maintain greater scrutiny only in cases where a given ISP issues more than 25% of their total space to residential customers who wish to remain anonymous and receive network blocks of /29 or larger. To the best of my knowledge, there are not currently any ISPs which meet this criteria. Additionally, it would only apply that scrutiny to IPv4, and will not carry forward into IPv6 residential assignments. This should improve the compliance verification of ARIN policies and may result in the improved reclamation of under-utilized IP address space. It should also serve as a deterrent to certain address hoarding tactics which have come to light in recent history. Timetable for implementation: Immediately upon ratification by the Board From info at arin.net Mon Jun 21 08:39:43 2010 From: info at arin.net (Member Services) Date: Mon, 21 Jun 2010 08:39:43 -0400 Subject: [arin-ppml] Policy Proposal 118: IPv6 Subsequent Allocation Message-ID: <4C1F5D8F.20404@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. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 118: IPv6 Subsequent Allocation Proposal Originator: Marla Azinger, Alain Durand, Mark Townsley Proposal Version:1 Date: 21 June 2010 Proposal type:NEW Policy term:permanent Policy statement: Modify 6.5.2.1 Subsequent allocation criteria. ADD the following sentence: Subsequent allocations will also be considered for transitional technologies that cannot be accommodated by, nor were accounted for, under the initial allocation. Justification for the subsequent subnet size will be based on the plan and technology provided. Justification for these allocations will be reviewed every 3 years and reclaimed if it is not in use. Requester will be exempt from returning all or a portion of the address space if they can show justification for need of this allocation for other existing IPv6 addressing requirements be it Native V6 or some other V6 network technology. Rationale: Current organizations cannot get an allocation for a IPv6 transitional technology if they have already received their initial allocation of IPv6. The reason they cannot get an additional IPV6 allocation is because they don't meet the HD ratio for a subsequent allocation and they don't want to use their initial assignment because it is insufficient, mapped out for other long term plans, or already has portions in use. An alternative proposal to permit more allocations was submitted that supported 6rd but since then community members have come forward with concern that this should support not just one particular technology but any that enable v6 deployment. Justification Example: Below is an example of how the details for a technology and its subnet requirements could be provided as justification. This example is based of 6rd. 6rd is intended to be an incremental method for deploying IPv6 and bridge the gap for End Users to the IPv6 Internet. The method provides a native dual-stack service to a subscriber site by leveraging existing infrastructure. If an entity already has a /32 of IPv6 they can not use the same /32 for native IPv6 as they do for the 6rd routing and a separate minimum size of a /32 is required while a larger subnet like a /28 may be needed based on a non-contiguous IPv4 addressing plan. The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an IPv4 address and must be short enough so that a /56 or /60 can be given to subscribers. This example shows how the 6rd prefix is created based on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8: SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first octet (10) is excluded from the encoding) 6rd CE router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 This example shows how the 6rd prefix is created based on a /28 IPv6 prefix using one of several non-contiguous global address ranges: SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4 address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60 Timetable for implementation: Immediate From michael.dillon at bt.com Mon Jun 21 09:37:29 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 21 Jun 2010 14:37:29 +0100 Subject: [arin-ppml] Policy Proposal 117: Required Resource Reviews In-Reply-To: <4C1F5D81.8040305@arin.net> References: <4C1F5D81.8040305@arin.net> Message-ID: <28E139F46D45AF49A31950F88C4974580658D9DE@E03MVZ2-UKDY.domain1.systemhost.net> > 10. Except as provided below, resource reviews are conducted at the > discretion of the ARIN staff. In any of the circumstances mentioned > below, a resource review must be initiated by ARIN staff: > The credibility of a report shall be > determined by ARIN staff. Does this b. section really need to be there? If so, then perhaps a report should only be considered credible if at least one BOT member considers it so. Or one BOT member or the CEO. Otherwise, the two mentions of "staff" make it seem too recursive. > c.Upon receipt by ARIN of five or more reports from separate > individuals > representing at least three separate organizations of fraud or abuse > for > the same organization or the same IP address block. Here again, as in b. you are defining what is a credible report. Perhaps you could just be explicit and say that a report is considered credible if at least one of the following is true: i) at least one BoT member considers it credible, ii) the ARIN CEO considers it credible, iii) five or more separate individuals report substantially the same issue. > e. An organization which submits a request for additional resources > when > more than 25% of their existing resources are obscured in SWIP or > RWHOIS > pursuant to section 4.2.3.7.6 (residential customer privacy). Now that is a step too far. You are essentially discriminating against a class of ISPs that serve the residential market and forcing them to ALWAYS go through a review process that other ISPs are basically exempt from. Personally, I don't see the need for a policy that ORDERS staff to do these reviews. I feel that it would be better to be done at the discretion of the BOT who can also take into account resourcing issues and other work that the staff could be doing. That's why we trust the trustees to run the organization. --Michael Dillon From michael.dillon at bt.com Mon Jun 21 09:43:32 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 21 Jun 2010 14:43:32 +0100 Subject: [arin-ppml] Policy Proposal 118: IPv6 Subsequent Allocation In-Reply-To: <4C1F5D8F.20404@arin.net> References: <4C1F5D8F.20404@arin.net> Message-ID: <28E139F46D45AF49A31950F88C4974580658D9F0@E03MVZ2-UKDY.domain1.systemhost.net> > The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an > IPv4 address and must be short enough so that a /56 or /60 can be given > to subscribers. I'd rather see this kind of policy restricted to only 6RD unless someone can come up with a descriptive term that includes 6RD and similar IPv4 address mapping transition technologies so that the policy isn't wide open to any and all crazy schemes that someone dreams up. Basically tailor a policy to 6RD for temporary allocations that have to be returned when 6RD is no longer needed. Make the language general enough so that it also covers a plan that improves on 6RD but if the plan requires permanent allocations, then reject it because it ain't better. Similarly if the plan doesn't allow for returning the allocations at the same time 6RD users are returning theirs then it ain't better, reject it, and force the ISPs to use 6RD instead. This is not an area where we want or need to encourage too much creativity. This is an area where you want quick cheap belt and braces solutions that can be dismantled as soon as possible in favor of native v6. --Michael Dillon From marla.azinger at frontiercorp.com Mon Jun 21 11:45:36 2010 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 21 Jun 2010 11:45:36 -0400 Subject: [arin-ppml] Policy Proposal 118: IPv6 Subsequent Allocation In-Reply-To: <28E139F46D45AF49A31950F88C4974580658D9F0@E03MVZ2-UKDY.domain1.systemhost.net> References: <4C1F5D8F.20404@arin.net> <28E139F46D45AF49A31950F88C4974580658D9F0@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10488182A77C@ROCH-EXCH1.corp.pvt> Thank you Michael. This is the kind of feedback we're looking for. We've gotten responses in both directions so far and we decided it would be good to vet it out seperately to see which one the community really supports. Cheers Marla -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Monday, June 21, 2010 6:44 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 118: IPv6 Subsequent Allocation > The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an > IPv4 address and must be short enough so that a /56 or /60 can be given > to subscribers. I'd rather see this kind of policy restricted to only 6RD unless someone can come up with a descriptive term that includes 6RD and similar IPv4 address mapping transition technologies so that the policy isn't wide open to any and all crazy schemes that someone dreams up. Basically tailor a policy to 6RD for temporary allocations that have to be returned when 6RD is no longer needed. Make the language general enough so that it also covers a plan that improves on 6RD but if the plan requires permanent allocations, then reject it because it ain't better. Similarly if the plan doesn't allow for returning the allocations at the same time 6RD users are returning theirs then it ain't better, reject it, and force the ISPs to use 6RD instead. This is not an area where we want or need to encourage too much creativity. This is an area where you want quick cheap belt and braces solutions that can be dismantled as soon as possible in favor of native v6. --Michael Dillon _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bensons at queuefull.net Mon Jun 21 12:02:44 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 21 Jun 2010 11:02:44 -0500 Subject: [arin-ppml] Policy Proposal 117: Required Resource Reviews In-Reply-To: <4C1F5D81.8040305@arin.net> References: <4C1F5D81.8040305@arin.net> Message-ID: <047A60C1-8B07-4084-B3D8-C1F22F9E7641@queuefull.net> I'm opposed to this policy proposal. Overall, my opinion of this is expressed by Michael Dillon's comment: On 21 Jun 10, at 8:37 AM, wrote: > Personally, I don't see the need for a policy that ORDERS staff to > do these reviews. I feel that it would be better to be done at the > discretion of the BOT who can also take into account resourcing issues > and other work that the staff could be doing. That's why we trust > the trustees to run the organization. That being said, here are some additional more-specific thoughts: On 21 Jun 10, at 7:39 AM, Member Services wrote: > a. Report or discovery of an acquisition, merger, transfer, trade or > sale in which the infrastructure and customer base of a network move > from one organization to another organization, but, the applicable IP > resources are not transferred. In this case, the organization retaining > the IP resources must be reviewed. The organization receiving the > customers may also be reviewed at the discretion of the ARIN staff. It might be more reasonable to narrow the scope to M&A activity where the network infrastructure/customers IN WHOLE are transferred to a new controlling party while the address resources are not. The sale of any PART of a network , infrastructure, customer base, etc, shouldn't require an investigation unless ARIN staff believes there is an issue with one or more surviving party. > c.Upon receipt by ARIN of five or more reports from separate individuals > representing at least three separate organizations of fraud or abuse for > the same organization or the same IP address block. If there is good evidence of fraud or abuse from any individual, ARIN should investigate. But it should be at the discretion of the staff. Requiring ARIN to investigate any/all claims, simply because of the number and variety of complaints, could result in wasted resources. It also creates an environment that is easily manipulated, encouraging political gaming and potentially undermining the community. > e. An organization which submits a request for additional resources when > more than 25% of their existing resources are obscured in SWIP or RWHOIS > pursuant to section 4.2.3.7.6 (residential customer privacy). This is not only unfair to a class of ISPs serving residential users, but it also fails to address the issue directly. If the concern is regarding lack of visibility into address assignments and/or their legitimacy, then there should be a more general way to characterize it that covers more than just Customer Privacy scenarios. And, of course, it should leave the decision to investigate up to ARIN's discretion. Cheers, -Benson From bensons at queuefull.net Mon Jun 21 12:11:57 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 21 Jun 2010 11:11:57 -0500 Subject: [arin-ppml] Policy Proposal 118: IPv6 Subsequent Allocation In-Reply-To: <4C1F5D8F.20404@arin.net> References: <4C1F5D8F.20404@arin.net> Message-ID: <436C4FE8-531D-4068-ACD8-5DEF78BAAE85@queuefull.net> On 21 Jun 10, at 7:39 AM, Member Services wrote: > Modify 6.5.2.1 Subsequent allocation criteria. ADD the following > sentence: Subsequent allocations will also be considered for > transitional technologies that cannot be accommodated by, nor were > accounted for, under the initial allocation. > > Justification for the subsequent subnet size will be based on the plan > and technology provided. Justification for these allocations will be > reviewed every 3 years and reclaimed if it is not in use. Requester will > be exempt from returning all or a portion of the address space if they > can show justification for need of this allocation for other existing > IPv6 addressing requirements be it Native V6 or some other V6 network > technology. I support this policy. ARIN should accommodate the need for address resources supporting v6 transition. It would be inappropriate for ARIN to prescribe or limit the transition technologies used. Cheers, -Benson From steve at ipv6canada.com Mon Jun 21 19:35:02 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Mon, 21 Jun 2010 19:35:02 -0400 Subject: [arin-ppml] Policy Proposal 118: IPv6 Subsequent Allocation In-Reply-To: <28E139F46D45AF49A31950F88C4974580658D9F0@E03MVZ2-UKDY.domain1.systemhost.net> References: <4C1F5D8F.20404@arin.net> <28E139F46D45AF49A31950F88C4974580658D9F0@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4C1FF726.3010105@ipv6canada.com> On 2010.06.21 09:43, michael.dillon at bt.com wrote: >> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate > an >> IPv4 address and must be short enough so that a /56 or /60 can be > given >> to subscribers. > > I'd rather see this kind of policy restricted to only 6RD unless someone > can come up with a descriptive term that includes 6RD and similar > IPv4 address mapping transition technologies so that the policy isn't > wide open to any and all crazy schemes that someone dreams up. I've battled with this comment all day. After having time to think about it, I prefer the generalized approach. Perhaps I'm naive, but this is IPv6, not IPv4. I'm thinking that if anyone wants to increase ARIN's revenue by *wanting* another same-sized block for *any* transition mechanism, they should be allowed to do so. The three year limit should still stand as we are talking transition and not permanent, so let trickery and scheming happen...who knows what new ideas might come out of it, all the while benefiting ARIN financially. Steve From info at arin.net Tue Jun 22 13:28:27 2010 From: info at arin.net (Member Services) Date: Tue, 22 Jun 2010 13:28:27 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - June 2010 Message-ID: <4C20F2BB.8070009@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) held a meeting on 17 June 2010 and made decisions about several draft policies and proposals. The AC recommended that the ARIN Board of Trustees adopt the following draft policy: 2010-2: /24 End User Minimum Assignment Unit The AC moved the following draft policy to an extended last call (it will be posted separately to last call): 2010-1: Waiting List for Unmet IPv4 Requests The AC accepted the following proposal on to the AC's docket for development and evaluation: 115. Global Policy for IPv4 Allocations by the IANA Post Exhaustion The AC abandoned the following proposal: 111. IPv4 Fragment Management policy proposal The ARIN AC abandoned Proposal 111 because its intent was rendered moot by the sending of 2010-1 to last call. 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.? Proposal 111 may be petitioned to try to change it into a draft policy for discussion on the Public Policy Mailing List and at the October meeting (Discussion Petition). The deadline to begin a petition is 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 Jun 22 13:29:26 2010 From: info at arin.net (Member Services) Date: Tue, 22 Jun 2010 13:29:26 -0400 Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests - Last Call Message-ID: <4C20F2F6.7@arin.net> The ARIN Advisory Council (AC) met on 17 June 2010 and decided to send a revised version of the following draft policy to an extended last call of 20 days: Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests Feedback is encouraged during this last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 12 July 2010. 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 2010-1 Waiting List for Unmet IPv4 Requests Version/Date: 22 June 2010 Policy statement: Replace 4.1.6 with: 4.1.6. Aggregation In order to preserve aggregation, ARIN attempts to issue blocks of addresses on appropriate "CIDR-supported" bit boundaries. ARIN may reserve space to maximize aggregation possibilities until the implementation of section 10.4.2.2, at which time ARIN will make each allocation and assignment as a single continuous range of addresses. Add new section 4.1.8: 4.1.8 Unmet requests In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to specify the smallest block size they'd be willing to accept, equal to or larger than the applicable minimum size specified elsewhere in ARIN policy. If such a smaller block is available, ARIN will fulfill the request with the largest single block available that fulfills the request. If no such block is available, the organization will be provided the option to be placed on a waiting list of pre-qualified recipients, listing both the block size qualified for and the smallest block size acceptable. Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. 4.1.8.1 Waiting list The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. 4.1.8.2 Fulfilling unmet needs As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a timely re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. Rationale: ARIN will soon be unable to meet all approved requests for IPv4 address space. In the absence of a policy like this, it is unclear what ARIN should do with subsequent requests. This policy would allocate reclaimed address blocks (and the last of the ARIN free pool) on a first-come-first-served basis, while preserving aggregation to the degree possible. As the free pool shrinks, requests larger than the largest block left would be placed on a waiting list, while smaller requests would use up the rest of it, until all requests have to go on the waiting list. As additional reclaimed addresses become available, the requests that have been waiting the longest would be met first. If a requester gets the addresses they need via transfer, then they would be removed from the waiting list and would need to wait and submit a new request for additional address space, either directly or via transfer. FAQ: Q1: The effect of 2009-8, if implemented by the Board, is to allow transfers to be up to a 12 month supply of resources and up to a 3 month supply for resource from the ARIN free pool. Does that jive with your intent for this policy? A1: Correct. After we get to the last /8, you can request up to a 3-month supply from the free pool, but only every 3 months unless you can document an unforeseen change in circumstances since your last request. However, if you get the space via transfer, you can get a block big enough for 12 month's need, and if you end up using it up faster, you can submit another request after 3 months. Q2: If I were on the waiting list, and subsequently received a transfer via 8.3, would I be removed from the waiting list? A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer will be considered fulfilled and removed from the waiting list." Q3: Would receipt of an M&A transfer remove you from the waiting list, too? A3: I think that depends on how the M&A is justified. If you acquire a company that is already efficiently utilizing all its IP space, I don't think that would count toward fulfilling an outstanding need that you have a request on the waiting list for. However, if your justification for keeping the space held by the acquired company is that you plan to use it for new stuff, then that would meet an outstanding need, and a request for that same need would be considered fulfilled and removed from the waiting list. Q4: What about Multiple Discrete Networks? A4: Allocations and assignments to organizations using the Multiple Discrete Networks policy must still be made as a single continuous range of addresses. This preserves future aggregatability of the space, and ensures fairness between MDN and ordinary requests. Q5: What would constitute "an unforeseen change in circumstances since their last request" that would allow ARIN to waive the 3-month delay to receive a second block? A5: This would, of course, be a matter of discretion for ARIN, but the idea here is that the burden of proof is on the requester to document some change in circumstances, that could not have been reasonably foreseen at the time of the original request, that now justifies additional space. This is intended to be a rarely used safety valve. Q6: What if an organization goes out of business or no longer needs the space when they get to the top of the waiting list? A6: When a block becomes available to fulfill a request on the waiting list, ARIN will do "a re-validation of the original request". If the original requester cannot be contacted, or their original need is no longer justified, they will be removed from the waiting list, and ARIN will move on to the next qualified requester. Timetable for implementation: Immediate. From info at arin.net Fri Jun 25 10:03:24 2010 From: info at arin.net (Member Services) Date: Fri, 25 Jun 2010 10:03:24 -0400 Subject: [arin-ppml] Petitioned Proposals 110 and 112 Message-ID: <4C24B72C.5030406@arin.net> The following proposals were petitioned: Proposal 110. Preservation of minimal IPv4 Resources for New and Small Organizations and for IPv6 Transition - One message received in favor; 10 required to move forward. Proposal 112. Utilization of 10.4.2 resources only via explicit policy - Two messages received in favor; 10 required to move forward. The petitions did not receive the required number of statements of support. The proposals are closed. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From jmaimon at chl.com Fri Jun 25 10:27:04 2010 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 25 Jun 2010 10:27:04 -0400 Subject: [arin-ppml] Petitioned Proposals 110 and 112 In-Reply-To: <4C24B72C.5030406@arin.net> References: <4C24B72C.5030406@arin.net> Message-ID: <4C24BCB8.1040901@chl.com> Member Services wrote: > The following proposals were petitioned: > > Proposal 110. Preservation of minimal IPv4 Resources for New and Small > Organizations and for IPv6 Transition > - One message received in favor; 10 required to move forward. > > Proposal 112. Utilization of 10.4.2 resources only via explicit policy > - Two messages received in favor; 10 required to move forward. > > The petitions did not receive the required number of statements of > support. The proposals are closed. > > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) I would like to thank all who participated in the discussion and process for their time, attention and consideration. While the outcome of this exercise was not as I hoped, I am satisfied that I have applied myself properly to the objectives and that as a matter of record the communities apparent will is now clearly shown. Thank you to all. Joe From bicknell at ufp.org Fri Jun 25 14:57:34 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 25 Jun 2010 11:57:34 -0700 Subject: [arin-ppml] Use of "reserved" address space. Message-ID: <20100625185734.GA95305@ussenterprise.ufp.org> A year or two ago there was some discussion about "reserved" address space. Specifically, Class E space, but in a CIDR world one has to wonder why we can't use most of 0/8, 127/8, and 240/4 as regular unicast space. There were folks who were going off to discuss that at the IETF and with some vendors. That's potentially ~18 /8's worth of address space "left on the table". Early review suggested that most of this in several free operating systems could be enabled with simple "user interface" changes; that is there were some checks to make sure they weren't used improperly by tools that set addresses but if those were removed they would be forwarded and treated like unicast. That is the cost of implementation was low. I realize "everything in the middle" must be upgraded to support this, but considering the level of effort and cost that may go into transfers folks may in fact find using this space cheaper. I'm surprised there isn't more effort to look into this area. Is there something going on I'm just not seeing? -- 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 jmaimon at chl.com Fri Jun 25 15:20:10 2010 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 25 Jun 2010 15:20:10 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625185734.GA95305@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> Message-ID: <4C25016A.3010608@chl.com> Leo Bicknell wrote: > > A year or two ago there was some discussion about "reserved" address > space. Specifically, Class E space, but in a CIDR world one has > to wonder why we can't use most of 0/8, 127/8, and 240/4 as regular > unicast space. There were folks who were going off to discuss that > at the IETF and with some vendors. There are/were some Internet Drafts concerning some useful applications of this space. > > That's potentially ~18 /8's worth of address space "left on the > table". Early review suggested that most of this in several free > operating systems could be enabled with simple "user interface" > changes; that is there were some checks to make sure they weren't > used improperly by tools that set addresses but if those were removed > they would be forwarded and treated like unicast. That is the cost > of implementation was low. > > I realize "everything in the middle" must be upgraded to support this, > but considering the level of effort and cost that may go into transfers > folks may in fact find using this space cheaper. I'm surprised there > isn't more effort to look into this area. Is there something going on > I'm just not seeing? > I hope so, you and me both. Apparently all attempts at something logical for this space are met with "Its too late to do any good", which is a self fulfilling prophecy. Joe From farmer at umn.edu Fri Jun 25 15:46:55 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 25 Jun 2010 14:46:55 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C25016A.3010608@chl.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C25016A.3010608@chl.com> Message-ID: <4C2507AF.4080108@umn.edu> Joe Maimon wrote: > > > Leo Bicknell wrote: >> >> A year or two ago there was some discussion about "reserved" address >> space. Specifically, Class E space, but in a CIDR world one has >> to wonder why we can't use most of 0/8, 127/8, and 240/4 as regular >> unicast space. There were folks who were going off to discuss that >> at the IETF and with some vendors. > > There are/were some Internet Drafts concerning some useful applications > of this space. I wouldn't be opposed to this direction, especially the class E space, I'm a little skeptical of trying to do something with 0/8 and 127/8 personally. However, I don't believe this is really something that can be accomplished within the PDP, this needs a directive from IETF to IANA. Nor, do I believe that any ARIN policy is necessary for ARIN to assign class E space if IANA were to make it available to ARIN and the other RIRs. With policy as-is, if IANA made the space available ARIN would make these addresses available to the ARIN region. >> That's potentially ~18 /8's worth of address space "left on the >> table". Early review suggested that most of this in several free >> operating systems could be enabled with simple "user interface" >> changes; that is there were some checks to make sure they weren't >> used improperly by tools that set addresses but if those were removed >> they would be forwarded and treated like unicast. That is the cost >> of implementation was low. >> >> I realize "everything in the middle" must be upgraded to support this, >> but considering the level of effort and cost that may go into transfers >> folks may in fact find using this space cheaper. I'm surprised there >> isn't more effort to look into this area. Is there something going on >> I'm just not seeing? >> > > I hope so, you and me both. > > Apparently all attempts at something logical for this space are met with > "Its too late to do any good", which is a self fulfilling prophecy. > > Joe I guess my question to Leo and Joe is, what do you suggest should be done within the scope of the PDP or ARIN to make these addresses available? -- =============================================== 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 Fri Jun 25 15:48:51 2010 From: Wesley.E.George at sprint.com (George, Wes E IV [NTK]) Date: Fri, 25 Jun 2010 14:48:51 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625185734.GA95305@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> Message-ID: The latest drafts that I'm aware of to fix this unfortunately died in the IETF without a lot of support. General consensus was that it was nearly impossible to get a critical mass of changes in networking and end user gear to make this work reliably in the global internet fast enough to make this useful. There is some credence to that idea - do you really want to have to field the calls from a customer who can't reach a given website because the people on the other end are dumping the traffic since they didn't get the memo that RFC3330 had been updated? It would be roughly equivalent to what has to happen every time we de-bogonize a new block from IANA, but much worse because it's hard-coded, instead of simply being rules that have to be changed in route and packet filters. I voiced support for it in IETF because I think that it still could have had applications, especially in areas of the network where you had some ability to coordinate and ensure that your gear supported the change, but to no avail. It might have worked if we had proposed it in 2005 (or maybe it failed then too, that was before my time in IETF), but the closer we get to exhaustion, the less support there seems to be for this sort of thing. At this point, I too think we're more or less out of runway, but this is an example I cite whenever I see people defending "reserved for future use" in a spec from those who might try to use it for something useful, or worse, proposing new "TBD" reservations for scarce resources, "just in case..." My discussions with Vince Fuller, who wrote one of the drafts, indicated that he had filed bugs internally with his employer to implement this on all of their platforms, but I'm not sure where that went after the draft fizzled. http://tools.ietf.org/search/draft-fuller-240space-02 Here's another draft: http://tools.ietf.org/html/draft-wilson-class-e-02 This might be something you could go and implement on your own network assuming you have control of the devices inside of it, but that's probably the best we could hope for. Thanks, Wes George -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell Sent: Friday, June 25, 2010 2:58 PM To: arin-ppml at arin.net Subject: [arin-ppml] Use of "reserved" address space. A year or two ago there was some discussion about "reserved" address space. Specifically, Class E space, but in a CIDR world one has to wonder why we can't use most of 0/8, 127/8, and 240/4 as regular unicast space. There were folks who were going off to discuss that at the IETF and with some vendors. That's potentially ~18 /8's worth of address space "left on the table". Early review suggested that most of this in several free operating systems could be enabled with simple "user interface" changes; that is there were some checks to make sure they weren't used improperly by tools that set addresses but if those were removed they would be forwarded and treated like unicast. That is the cost of implementation was low. I realize "everything in the middle" must be upgraded to support this, but considering the level of effort and cost that may go into transfers folks may in fact find using this space cheaper. I'm surprised there isn't more effort to look into this area. Is there something going on I'm just not seeing? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From bicknell at ufp.org Fri Jun 25 15:51:31 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 25 Jun 2010 12:51:31 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C2507AF.4080108@umn.edu> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C25016A.3010608@chl.com> <4C2507AF.4080108@umn.edu> Message-ID: <20100625195131.GA98834@ussenterprise.ufp.org> In a message written on Fri, Jun 25, 2010 at 02:46:55PM -0500, David Farmer wrote: > I guess my question to Leo and Joe is, what do you suggest should be > done within the scope of the PDP or ARIN to make these addresses available? I would find it more useful for ARIN to spend their outreach dollars sending staff to IETF or to meet with Cisco and Juniper to persue this issue than going to ComicCon[1] to tell people to be IPv6 ready. 240/4 is marked "Reserved for Future Use" by the IANA. What else are we going to use it for, isn't the future now? [1] No, ARIN has not gone to ComicCon as far as I know, and no this does not mean I think all of their outreach efforts are bad. However, it does mean I think they are starting to scrape the bottom of the barrel in terms of looking for useful places to be. -- 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 bensons at queuefull.net Fri Jun 25 15:32:29 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Jun 2010 14:32:29 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625185734.GA95305@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> Message-ID: I think the impact on end hosts would be painful. Just because my Linux laptop doesn't mind (thanks to a kernel hack), it doesn't mean the world's web servers etc. are ok... Getting universal support for unicast use of Reserved space is roughly on-scale with the challenges of deploying IPv6. However, I've heard reasonable suggestions that reserved space might be useful for network infrastructure especially in the context of Locator / ID split proposals i.e as locator space. Cheers, -Benson On 2010-06-25, Leo Bicknell wrote: > > A year or two ago there was some discussion about "reserved" address > space. Specifically, Class E space, but in a CIDR world one has > to wonder why we can't use most of 0/8, 127/8, and 240/4 as regular > unicast space. There were folks who were going off to discuss that > at the IETF and with some vendors. > > That's potentially ~18 /8's worth of address space "left on the > table". Early review suggested that most of this in several free > operating systems could be enabled with simple "user interface" > changes; that is there were some checks to make sure they weren't > used improperly by tools that set addresses but if those were removed > they would be forwarded and treated like unicast. That is the cost > of implementation was low. > > I realize "everything in the middle" must be upgraded to support this, > but considering the level of effort and cost that may go into transfers > folks may in fact find using this space cheaper. I'm surprised there > isn't more effort to look into this area. Is there something going on > I'm just not seeing? > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > From bicknell at ufp.org Fri Jun 25 16:29:48 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 25 Jun 2010 13:29:48 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> Message-ID: <20100625202948.GA1492@ussenterprise.ufp.org> In a message written on Fri, Jun 25, 2010 at 02:32:29PM -0500, Benson Schliesser wrote: > I think the impact on end hosts would be painful. Just because my > Linux laptop doesn't mind (thanks to a kernel hack), it doesn't mean > the world's web servers etc. are ok... Getting universal support for > unicast use of Reserved space is roughly on-scale with the challenges > of deploying IPv6. I actually think you have that backwards. Most Microsoft and Apple products can be fixed via a software update mechanism already widely deployed. This would be just another minor patch to most folks going out in the regular cycle. I think upgrading all of the routers, including both backbone and more importantly home gateways is the larger challenge, they don't have that facility. But, everyone already has to upgrade those to support IPv6. Might as well get an image that gets you IPv6 + reserved space for the price of one upgrade. -- 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 tedm at ipinc.net Fri Jun 25 16:45:11 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Jun 2010 13:45:11 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625202948.GA1492@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> Message-ID: <4C251557.6060300@ipinc.net> On 6/25/2010 1:29 PM, Leo Bicknell wrote: > In a message written on Fri, Jun 25, 2010 at 02:32:29PM -0500, Benson Schliesser wrote: >> I think the impact on end hosts would be painful. Just because my >> Linux laptop doesn't mind (thanks to a kernel hack), it doesn't mean >> the world's web servers etc. are ok... Getting universal support for >> unicast use of Reserved space is roughly on-scale with the challenges >> of deploying IPv6. > > I actually think you have that backwards. > > Most Microsoft and Apple products can be fixed via a software update > mechanism already widely deployed. This would be just another minor > patch to most folks going out in the regular cycle. > > I think upgrading all of the routers, including both backbone and > more importantly home gateways is the larger challenge, they don't > have that facility. > > But, everyone already has to upgrade those to support IPv6. Might as > well get an image that gets you IPv6 + reserved space for the price of > one upgrade. > We already HAVE images that support IPv6 and they are running fine. Since certain router vendors seem to view any feature addition as a chance to sell you a lot of expensive new gear (since the xOS version won't run on the older gear that contains this needed feature) we wouldn't be too keen on seeing this implemented. Ted > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bensons at queuefull.net Fri Jun 25 16:47:08 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Jun 2010 15:47:08 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625202948.GA1492@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> Message-ID: <8AD8752D-9C60-4389-8E89-F70A6A21E37D@queuefull.net> On 25 Jun 10, at 3:29 PM, Leo Bicknell wrote: > Most Microsoft and Apple products can be fixed via a software update > mechanism already widely deployed. This would be just another minor > patch to most folks going out in the regular cycle. This seems like an optimistic view of the patching / update cycle. > I think upgrading all of the routers, including both backbone and > more importantly home gateways is the larger challenge, they don't > have that facility. I agree. Nor do the web servers, load balancers, firewalls, etc. I certainly didn't exclude these from the problem's scope. > But, everyone already has to upgrade those to support IPv6. Might as > well get an image that gets you IPv6 + reserved space for the price of > one upgrade. I agree. But, a key difference is that both the source and destination need to support IPv6 before it becomes useful. The presence of completely different behaviors on each end of a formerly-reserved unicast flow might be more disruptive than the migration to a dual-stack environment. Thus my suggestion, that it is a good idea to limit the scope i.e. to a Loc/ID backbone environment. Cheers, -Benson From leo.vegoda at icann.org Fri Jun 25 18:37:28 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 25 Jun 2010 15:37:28 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> Message-ID: On 25 Jun 2010, at 12:48, George, Wes E IV [NTK] wrote: > There is some credence to that idea - do you really want to have to field the calls from a customer who can't reach a given website because the people on the other end are dumping the traffic since they didn't get the memo that RFC3330 had been updated? It has been updated. It's now RFC 5735: http://tools.ietf.org/html/rfc5735 And it does have some changes in it, so it's worth a quick look if you are using RFC 3330 as a basis for various filters. Regards, Leo Vegoda From stephen at sprunk.org Fri Jun 25 22:53:11 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 25 Jun 2010 21:53:11 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625202948.GA1492@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> Message-ID: <4C256B97.70802@sprunk.org> On 25 Jun 2010 15:29, Leo Bicknell wrote: > In a message written on Fri, Jun 25, 2010 at 02:32:29PM -0500, Benson Schliesser wrote: > >> I think the impact on end hosts would be painful. Just because my >> Linux laptop doesn't mind (thanks to a kernel hack), it doesn't mean >> the world's web servers etc. are ok... Getting universal support for >> unicast use of Reserved space is roughly on-scale with the challenges >> of deploying IPv6. >> > I actually think you have that backwards. > > Most Microsoft and Apple products can be fixed via a software update > mechanism already widely deployed. This would be just another minor > patch to most folks going out in the regular cycle. > > I think upgrading all of the routers, including both backbone and > more importantly home gateways is the larger challenge, they don't > have that facility. > I'm not as worried about networking gear (which is, for the most part, run by reasonably competent professionals) as I am end systems. It took over ten years for Microsoft to ship an OS that fully supported IPv6, and there are still lots of folks out there running WinXP, not to mention Win95/98/Me/2k. Plus, there are all the assorted embedded devices (e.g. printers, toasters, phones, etc.) for which the manufacturers have no future software updates planned--if they're still in business. If it were even possible to get everything upgraded, it certainly wouldn't be done soon enough to matter. Maybe if we had started on this ten years ago it would make sense, but now it's far too late. IMHO, it's better to push manufacturers and network providers to IPv6 rather than distract them with yet another hack that will only keep IPv4 rolling along for another year or so. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From bill at herrin.us Sat Jun 26 00:23:48 2010 From: bill at herrin.us (William Herrin) Date: Sat, 26 Jun 2010 00:23:48 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625195131.GA98834@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C25016A.3010608@chl.com> <4C2507AF.4080108@umn.edu> <20100625195131.GA98834@ussenterprise.ufp.org> Message-ID: On Fri, Jun 25, 2010 at 3:51 PM, Leo Bicknell wrote: > 240/4 is marked "Reserved for Future Use" by the IANA. ?What else > are we going to use it for, isn't the future now? Hi Leo, Personally, the idea I liked the most was converting it into additional RFC1918 space. 16 more IPv4 /8's aren't likely to carry us over to a point where IPv6 adoption is sufficiently ubiquitous that we can begin to phase out IPv4... but they'd make a big difference to an ISP trying to avoid overlap and improve manageability in its internal carrier NAT system. 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 Sat Jun 26 01:51:34 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Jun 2010 22:51:34 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625185734.GA95305@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> Message-ID: <1D171CC2-FD59-4E99-A78D-90D85BE6A627@delong.com> I believe that in both cases, the costs almost always exceed the cost of IPv6 adoption. Owen On Jun 25, 2010, at 11:57 AM, Leo Bicknell wrote: > > A year or two ago there was some discussion about "reserved" address > space. Specifically, Class E space, but in a CIDR world one has > to wonder why we can't use most of 0/8, 127/8, and 240/4 as regular > unicast space. There were folks who were going off to discuss that > at the IETF and with some vendors. > > That's potentially ~18 /8's worth of address space "left on the > table". Early review suggested that most of this in several free > operating systems could be enabled with simple "user interface" > changes; that is there were some checks to make sure they weren't > used improperly by tools that set addresses but if those were removed > they would be forwarded and treated like unicast. That is the cost > of implementation was low. > > I realize "everything in the middle" must be upgraded to support this, > but considering the level of effort and cost that may go into transfers > folks may in fact find using this space cheaper. I'm surprised there > isn't more effort to look into this area. Is there something going on > I'm just not seeing? > > -- > 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. From owen at delong.com Sat Jun 26 02:01:02 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Jun 2010 23:01:02 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625195131.GA98834@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C25016A.3010608@chl.com> <4C2507AF.4080108@umn.edu> <20100625195131.GA98834@ussenterprise.ufp.org> Message-ID: <5A651447-9493-4F31-9B36-C84FE1885DD0@delong.com> On Jun 25, 2010, at 12:51 PM, Leo Bicknell wrote: > In a message written on Fri, Jun 25, 2010 at 02:46:55PM -0500, David Farmer wrote: >> I guess my question to Leo and Joe is, what do you suggest should be >> done within the scope of the PDP or ARIN to make these addresses available? > > I would find it more useful for ARIN to spend their outreach dollars > sending staff to IETF or to meet with Cisco and Juniper to persue this > issue than going to ComicCon[1] to tell people to be IPv6 ready. > Respectfully, I think ComicCon is a cheap and undeserved pot-shot as you yourself admit in your footnote. I challenge you to list the outreach locations which you think are ineffective. I would much rather see ARIN's outreach dollars focused on a clean long-term solution than spreading additional temporary chaos. It's going to be a rough road until everyone is IPv6 enabled. Making that journey longer makes about as much sense to me as installing a hammer above your head on a spring before driving down an uneven dirt road which takes a longer windier path than the paved road you are about to depart. Likely with similar results -- Much more pain than necessary for a much longer period of time. > 240/4 is marked "Reserved for Future Use" by the IANA. What else > are we going to use it for, isn't the future now? > We probably aren't going to use it, but, it's not part of the useful IPv4 unicast address space and open source operating systems that can be easily patched don't even constitute a simple majority of the devices that need to be changed for it to be useful, so, bringing them up is kind of pointless as a supporting argument in favor of this fools errand. Owen > [1] No, ARIN has not gone to ComicCon as far as I know, and no this does > not mean I think all of their outreach efforts are bad. However, it > does mean I think they are starting to scrape the bottom of the barrel > in terms of looking for useful places to be. > > -- > 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. From jmaimon at chl.com Sun Jun 27 00:21:10 2010 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 27 Jun 2010 00:21:10 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C256B97.70802@sprunk.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> <4C256B97.70802@sprunk.org> Message-ID: <4C26D1B6.8090508@chl.com> Stephen Sprunk wrote: > Maybe if we had > started on this ten years ago it would make sense, Agreed. However, the reason we hadnt started on this ten years ago is the exact one quoted above. > but now it's far too > late. I certainly hope so. Otherwise things have really hit the fan. So I would suggest we do so anyways, even as we assume that time proves it to be a pointless endeavor. I certainly dont want to be having this exact discussion ten years from now. > IMHO, it's better to push manufacturers and network providers to > IPv6 rather than distract them with yet another hack that will only keep > IPv4 rolling along for another year or so. > > S What is wrong with an approach of "All of the above"? Anyways, strong odds suggest that removing restrictions on reserved space is a much simpler code change than including another network stack, in any OS and in any firmware. Joe From mysidia at gmail.com Sun Jun 27 00:54:12 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 26 Jun 2010 23:54:12 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C26D1B6.8090508@chl.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> <4C256B97.70802@sprunk.org> <4C26D1B6.8090508@chl.com> Message-ID: On Sat, Jun 26, 2010 at 11:21 PM, Joe Maimon wrote: > What is wrong with an approach of "All of the above"? > Anyways, strong odds suggest that removing restrictions on reserved space is > a much simpler code change than including another network stack, in any OS > and in any firmware. This is definitely true. Removing an arbitrary restriction on some IPs is much simpler a change than adding an extra IP stack. And it should require at most a minor update to the standards, to adjust the reserved blocks to indicate host and router software should support unicast for all those blocks from now on. As far as I can tell , the internet is not on course for a well-implemented transition to IPv6. It is on a collision course with IP exhaustion, and the fallout of the crash is NAT hell. Even if a decision will not be immediately made to offer to allocate address space from those blocks. The availability of those currently reserved blocks could definitely be useful in the future, every effort should be made as soon as possible to encourage software being made now and in the future to support those IPs.... provisions should be made immediately, to require all internet hosts to be capable of receive and send packets, and be configured to use any parts of those special blocks that are not actually used and can be unreserved. You can implement IPv6 on your network, but you cannot force everyone you want to talk to to do so at this point. The cost of getting other people to use IPv6 would be very high. The cost of deploying IPv6 on your own network is irrelevent, once you have IPv6 networking, it's everyone else's network that matters. The cost of asking other networks to patch their routers to fix connectivity to formerly-reserved blocks is nil. You can even report to them "your equipment has this issue, bug, please do something about it".. Rather than having to say "We don't have IPv4 connectivity, will you please setup an IPv6 network, so we can talk to you?" Which is more likely to get "No" as a response than "Ok.. we'll see if we can fix that" The real cost of deploying IPv6 is not just a code change to equipment, it is the IP network re-design, planning, etc, required. When the planning and design required to have a V6 network has not been done, the less costly alternative to V6 is probably NAT hell. -- -JH From owen at delong.com Sun Jun 27 06:10:43 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Jun 2010 00:10:43 -1000 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C26D1B6.8090508@chl.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> <4C256B97.70802@sprunk.org> <4C26D1B6.8090508@chl.com> Message-ID: <403FEC1B-428B-4E3A-8FA4-082CFE63B7CB@delong.com> Sent from my iPad On Jun 26, 2010, at 6:21 PM, Joe Maimon wrote: > > > Stephen Sprunk wrote: > >> Maybe if we had >> started on this ten years ago it would make sense, > > Agreed. However, the reason we hadnt started on this ten years ago is the exact one quoted above. > >> but now it's far too >> late. > > I certainly hope so. Otherwise things have really hit the fan. So I would suggest we do so anyways, even as we assume that time proves it to be a pointless endeavor. I certainly dont want to be having this exact discussion ten years from now. > >> IMHO, it's better to push manufacturers and network providers to >> IPv6 rather than distract them with yet another hack that will only keep >> IPv4 rolling along for another year or so. >> >> S > > What is wrong with an approach of "All of the above"? > Lack of infinite human resources... Resources with clue can do the most good deploying ipv6. Resources without clue won't accomplish much on this task anyway. > Anyways, strong odds suggest that removing restrictions on reserved space is a much simpler code change than including another network stack, in any OS and in any firmware. > But the other network stack is already there in the vast majority of hardware and os. Additionally, that still has to happen anyway. Owen > Joe > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From lear at cisco.com Sun Jun 27 07:10:52 2010 From: lear at cisco.com (Eliot Lear) Date: Sun, 27 Jun 2010 13:10:52 +0200 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> Message-ID: <4C2731BC.6080300@cisco.com> Wes, You've covered a lot of the ground of the discussion. I presented this draft on behalf of our author group to the int-area, and got pushback from the room in the following forms: * It would take forever to fix printers, fridges, and other appliances, along with routers, firewalls, and other middle boxes. * /4 is a honking lot of private address space that would benefit few. * /4 really doesn't buy us much time in terms of staving off or easing a transition * *There are several v4/v6 transition protocols that base assumptions about private address space.* * Better to focus on v6 transition. That's my recollection. That forth one pretty much means you have to choose a path and go with it. And so the question is whether it would be worth removing filters to make that address space useful in some number of years, and there certainly wasn't overwhelming demand in the room to do that. Quite the opposite. Eliot On 6/25/10 9:48 PM, George, Wes E IV [NTK] wrote: > The latest drafts that I'm aware of to fix this unfortunately died in the IETF without a lot of support. General consensus was that it was nearly impossible to get a critical mass of changes in networking and end user gear to make this work reliably in the global internet fast enough to make this useful. There is some credence to that idea - do you really want to have to field the calls from a customer who can't reach a given website because the people on the other end are dumping the traffic since they didn't get the memo that RFC3330 had been updated? It would be roughly equivalent to what has to happen every time we de-bogonize a new block from IANA, but much worse because it's hard-coded, instead of simply being rules that have to be changed in route and packet filters. I voiced support for it in IETF because I think that it still could have had applications, especially in areas of the network where you had some ability to coordinate and ensure that your gear supported th > e change, but to no avail. > It might have worked if we had proposed it in 2005 (or maybe it failed then too, that was before my time in IETF), but the closer we get to exhaustion, the less support there seems to be for this sort of thing. At this point, I too think we're more or less out of runway, but this is an example I cite whenever I see people defending "reserved for future use" in a spec from those who might try to use it for something useful, or worse, proposing new "TBD" reservations for scarce resources, "just in case..." > > My discussions with Vince Fuller, who wrote one of the drafts, indicated that he had filed bugs internally with his employer to implement this on all of their platforms, but I'm not sure where that went after the draft fizzled. > http://tools.ietf.org/search/draft-fuller-240space-02 > > Here's another draft: > http://tools.ietf.org/html/draft-wilson-class-e-02 > This might be something you could go and implement on your own network assuming you have control of the devices inside of it, but that's probably the best we could hope for. > > > Thanks, > Wes George > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell > Sent: Friday, June 25, 2010 2:58 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Use of "reserved" address space. > > > A year or two ago there was some discussion about "reserved" address > space. Specifically, Class E space, but in a CIDR world one has > to wonder why we can't use most of 0/8, 127/8, and 240/4 as regular > unicast space. There were folks who were going off to discuss that > at the IETF and with some vendors. > > That's potentially ~18 /8's worth of address space "left on the > table". Early review suggested that most of this in several free > operating systems could be enabled with simple "user interface" > changes; that is there were some checks to make sure they weren't > used improperly by tools that set addresses but if those were removed > they would be forwarded and treated like unicast. That is the cost > of implementation was low. > > I realize "everything in the middle" must be upgraded to support this, > but considering the level of effort and cost that may go into transfers > folks may in fact find using this space cheaper. I'm surprised there > isn't more effort to look into this area. Is there something going on > I'm just not seeing? > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Jun 27 10:31:56 2010 From: bill at herrin.us (William Herrin) Date: Sun, 27 Jun 2010 10:31:56 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C2731BC.6080300@cisco.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> Message-ID: On Sun, Jun 27, 2010 at 7:10 AM, Eliot Lear wrote: > You've covered a lot of the ground of the discussion.? I presented this > draft on behalf of our author group to the int-area, and got pushback from > the room in the following forms: Hi Eliot, Thanks for the report. Some comments... > It would take forever to fix printers, fridges, and other appliances, along > with routers, firewalls, and other middle boxes. Part of my reason for preferring 240/4's use as private addresses is that you can reasonably hope to control what goes on inside your own network. Even with customers you can make a globally routable address available for an extra fee so that folks with non-supporting equipment don't have to ever see the private IP addresses. On the public Internet 240/4 is dead weight. No one is going back to fix Windows 98 and all the other legacy equipment that *will* be present in enough quantity to cause a problem. > /4 is a honking lot of private address space that would benefit few. We'll see. This depends on the degree to which ISPs implement IPv4 carrier NATs which, at this point, is on everyone's long-range radar. I also note ULA sets aside a larger percentage of IPv6's total address space (a /7) for private addressing than is set aside out of IPv4's. Perhaps it would be wise to carve out a /6 from 240/4 as "ISP-local" private addresses and then see what happens before determining the fate of the rest of the /4. No point making the same mistake as with 224/4. What isn't debatable is that we're approaching a dire shortage and right now 240/4 is a honking lot of address space that benefits exactly _nobody_. > There are several v4/v6 transition protocols that base > assumptions about private address space. Would you clarify this? You've emphasized it but I don't follow how the use of 240/4 as unicast addresses (especially private unicast addresses) disrupts any v6 protocols on the books. > Better to focus on v6 transition. Myopic. Unless another credible solution presents, IPv4 carrier NATs -ARE- the v6 transition. 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 Sun Jun 27 11:45:53 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 27 Jun 2010 08:45:53 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C2731BC.6080300@cisco.com> <4C256B97.70802@sprunk.org> <5A651447-9493-4F31-9B36-C84FE1885DD0@delong.com> References: <4C2731BC.6080300@cisco.com> <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> <4C256B97.70802@sprunk.org> <20100625185734.GA95305@ussenterprise.ufp.org> <4C25016A.3010608@chl.com> <4C2507AF.4080108@umn.edu> <20100625195131.GA98834@ussenterprise.ufp.org> <5A651447-9493-4F31-9B36-C84FE1885DD0@delong.com> Message-ID: <20100627154553.GA50485@ussenterprise.ufp.org> In a message written on Fri, Jun 25, 2010 at 11:01:02PM -0700, Owen DeLong wrote: > Respectfully, I think ComicCon is a cheap and undeserved pot-shot > as you yourself admit in your footnote. I challenge you to list the outreach > locations which you think are ineffective. Ineffective implies a binary choice which is not the case in this situation. Each outreach location comes at some cost (actual travel, staff time, and the opportunity cost of other things they could do) and some benefit via the folks you reach and the action that they take. ARIN has made this value judgement in a competent manor, they started with the most effective venues, and as they have added more have moved down the list in terms of value to add more locations. This is absolutely the right approch. The value though cannot be objectively measured. It is my opinion they have moved far enough down the list that there is no added benefit in going further down the list, and indeed I take a skeptical eye to one or two of the places they are going. That said, I fully expect someone else to make different value judgements, rating some conferences lower than I do, and some higher. In short, in my opinion this avenue is fully tapped. There is no more sigificant good to be done via this method, and indeed I think taking a hard look at who showed up at each location and re-evaluating priorities for next year would be an excellent thing for staff to do, and I'm sure they already are doing just that. My point, which you seem to have totally glossed over is that there are other avenues like putitng forth these issues as informational presentations at places like the IETF, or directly to vendors that I think might have a much greater chance of reaching the folks who could actually do something. In a message written on Fri, Jun 25, 2010 at 09:53:11PM -0500, Stephen Sprunk wrote: > I'm not as worried about networking gear (which is, for the most part, > run by reasonably competent professionals) as I am end systems. It took > over ten years for Microsoft to ship an OS that fully supported IPv6, > and there are still lots of folks out there running WinXP, not to > mention Win95/98/Me/2k. Plus, there are all the assorted embedded > devices (e.g. printers, toasters, phones, etc.) for which the > manufacturers have no future software updates planned--if they're still > in business. If it were even possible to get everything upgraded, it > certainly wouldn't be done soon enough to matter. Maybe if we had > started on this ten years ago it would make sense, but now it's far too > late. IMHO, it's better to push manufacturers and network providers to > IPv6 rather than distract them with yet another hack that will only keep > IPv4 rolling along for another year or so. Fortunately, you think in an end-to-end model, as we need more people to do that. However, in this case that is a detraction. For instance, my home connection today gets one public IP, and then sits behind NAT on RFC 1918 space. I believe this is amazingly typical. If I got a 240/4 space public address my home gateway needs to know how to use it, but none of my workstations, printers, phones, toasters or other devices will ever know, happily using 10/8 internally. Much like deploying IPv6 does not require a flag day or 100% device upgrade neither does using presently reserved space. In a message written on Sun, Jun 27, 2010 at 01:10:52PM +0200, Eliot Lear wrote: > You've covered a lot of the ground of the discussion. I presented this > draft on behalf of our author group to the int-area, and got pushback > from the room in the following forms: > * It would take forever to fix printers, fridges, and other > appliances, along with routers, firewalls, and other middle boxes. > * /4 is a honking lot of private address space that would benefit > few. > * /4 really doesn't buy us much time in terms of staving off or > easing a transition > * There are several v4/v6 transition protocols that base assumptions > about private address space. > * Better to focus on v6 transition. Point #1 is addressed by my answer to the previous poster. Point #2 and #3 are valid concerns, particularly if the proposal is to make it more RFC1918 like space. If it's public space, then the concern is quite silly, as a /4 could give us 2-3 more years, which I think is non-trival. Point #4 is the reason I am responding. I would like to know which transition protocols base assumptions on what is private address space. I must admit I am no deep expert on all the transition protocols, but I don't quickly see anything in the most popular ones that treat private address space as special in any way. Point #5 is a trueism, and says nothing about the actual landscape of what is happening. It's one thing to have an idealistic position, it's quite another to hold on to it when it no longer matches reality. If IP space "trading" becomes popular, and prices become expensive there will be real economic pressure to free up this space. It's the IP equivilant of $120 a barrel oil making people want to drill in ANWR. Sure, it's not the ideal space to get the resource, but at some economic point a lot of people see it as worth while. The worst case scenario here is pretty bad. IPv6 adoption is slower than we would like, IPv4 trading is wildly popular, the price spikes, and things like using reserved space are rushed through. That will be a real mess. -- 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 cra at WPI.EDU Sun Jun 27 12:12:19 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 27 Jun 2010 12:12:19 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100627154553.GA50485@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> <4C256B97.70802@sprunk.org> <20100625185734.GA95305@ussenterprise.ufp.org> <4C25016A.3010608@chl.com> <4C2507AF.4080108@umn.edu> <20100625195131.GA98834@ussenterprise.ufp.org> <5A651447-9493-4F31-9B36-C84FE1885DD0@delong.com> <20100627154553.GA50485@ussenterprise.ufp.org> Message-ID: <20100627161219.GA16164@angus.ind.WPI.EDU> On Sun, Jun 27, 2010 at 08:45:53AM -0700, Leo Bicknell wrote: > > * It would take forever to fix printers, fridges, and other > > appliances, along with routers, firewalls, and other middle boxes. > > * /4 is a honking lot of private address space that would benefit > > few. > > * /4 really doesn't buy us much time in terms of staving off or > > easing a transition > > * There are several v4/v6 transition protocols that base assumptions > > about private address space. > > * Better to focus on v6 transition. > > Point #2 and #3 are valid concerns, particularly if the proposal is to > make it more RFC1918 like space. If it's public space, then the concern > is quite silly, as a /4 could give us 2-3 more years, which I think is > non-trival. For public space, 16 more /8's at the current burn-rate of about one /8 per month[1] only gives us 1.25 - 1.5 years at most. I think that is a trivial amount of time that doesn't make it worth the pain to use 240/4 for public space. [1] http://ipv4depletion.com/?page_id=4 From owen at delong.com Sun Jun 27 14:09:24 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Jun 2010 11:09:24 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> Message-ID: <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> > >> /4 is a honking lot of private address space that would benefit few. > > We'll see. This depends on the degree to which ISPs implement IPv4 > carrier NATs which, at this point, is on everyone's long-range radar. > Not everyone's. I know of at least one ISP that has no intention of implementing any form of LSN. > > What isn't debatable is that we're approaching a dire shortage and > right now 240/4 is a honking lot of address space that benefits > exactly _nobody_. > But pulling resources off of IPv6 deployment to make this address space workable, even in the scenarios you suggest simply doesn't make sense. Taking resources away from a solution in order to propel a hack that will by all accounts take nearly as long as the solution in order to develop and deploy, especially when the solution already has momentum and is accelerating simply doesn't make sense to me. It seems sort of like deciding to pull the experts off the efforts to cap the well in the Gulf of Mexico in favor of having them build oil containment booms, since we don't have nearly enough of those. > > >> Better to focus on v6 transition. > > Myopic. Unless another credible solution presents, IPv4 carrier NATs > -ARE- the v6 transition. > IPv4 carrier NATs are the temporary hack to get around the incomplete nature of the transition at runout. The transition is to native dual stack or native IPv6. Owen From mysidia at gmail.com Sun Jun 27 14:58:16 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 27 Jun 2010 13:58:16 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C2731BC.6080300@cisco.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> Message-ID: On Sun, Jun 27, 2010 at 6:10 AM, Eliot Lear wrote: [snip] > It would take forever to fix printers, fridges, and other appliances, along > with routers, firewalls, and other middle boxes. If IP enabled fridges can no longer use the LAN, then so be it.. It may be hard to convince manufacturers of even new devices to 'fix' it, yes, but forever is a long time. And the time it takes is measured starting _from the time the block is no longer marked as special_. Currently deployed printers, fridges, and other appliances have not even been in service using IPv4 forever. Of course if 240/4's special future-use status is retained, this becomes a self-fulfilling prophesy. If it stays 'special', yes, many existing and future appliances will not become capable of using 240/4 IPs, ever. If the block were unreserved, it could take 20 years from now before 240/4 could become usable in practice for public addressing, and it would still be worth it, to withdraw 240/4's special status today, on that basis alone. 240/4 could still be extremely valuable, even if most of it were only available for private addressing. Regardless of any IPv6 transition attempts, IPv4 will still be in use 20 years from now, and address space is likely to still be scarce. > /4 is a honking lot of private address space that would benefit few. > /4 really doesn't buy us much time in terms of staving off or easing a transition It buys you something. And any reduction in V4 space utilization benefits all. "What it buys" us are speculations about the future, which are not agreed upon. It only makes sense to say that if you assume there will be a transition off V4, which is definitely not guaranteed. Because of the limitations of 240/4 space, 240/4 addresses would not likely to be used in the same way as the rest of the IPv4 space. For example, they might be useful for routers that only communicate directly with devices that support 240/4 address space, such as Point to Point links, where the addressing used at each end is not 240/4. In that case, the 240/4 space is beneficial, because it displaces some other use of V4 space, allowing (non-240/4) public address space to be freed up for end hosts. Large NAT deployments run into addressing difficulties, requiring complex configurations and multiple NATs. Availability of some 240/4 space for private use can reduce the complexity and increase the scalability of large NAT deployments. It's not necessary to immediately make a decision on whether 240/4's future use should be private IPs or public IPs. The exact usages could be determined at a later date, with testing and careful consideration, vendors of routers would no doubt need time to repair their IP4 implementations. I would suggest at least some small portions of 240/4 be allocated to an IP registry and get announced, for testing purposes. > There are several v4/v6 transition protocols that base assumptions about > private address space. > Better to focus on v6 transition. This is also not a technically sound justification for keeping 240/4 marked as non-unicast reserved special. None of the justifications provided show possible harm or reason to NOT allow removal of the future use designation of 240/4. All they seem to show is doubts regarding the eventual usefulness of doing so. Which are true -- we cannot be certain of the usefulness of removing the future use non-unicast designation of 240/4. However "we shouldn't even really try" is not a good answer. Especially when the doubts are just speculation. -- -J From bill at herrin.us Sun Jun 27 18:05:43 2010 From: bill at herrin.us (William Herrin) Date: Sun, 27 Jun 2010 18:05:43 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> Message-ID: On Sun, Jun 27, 2010 at 2:09 PM, Owen DeLong wrote: >> What isn't debatable is that we're approaching a dire shortage and >> right now 240/4 is a honking lot of address space that benefits >> exactly _nobody_. >> > But pulling resources off of IPv6 deployment to make this address space > workable, even in the scenarios you suggest simply doesn't make sense. > Taking resources away from a solution in order to propel a hack that will > by all accounts take nearly as long as the solution in order to develop > and deploy, especially when the solution already has momentum and > is accelerating simply doesn't make sense to me. Not a zero sum game. The likely resources mostly aren't working on IPv6 right now regardless. > It seems sort of like deciding to pull the experts off the efforts to cap the > well in the Gulf of Mexico in favor of having them build oil containment > booms, since we don't have nearly enough of those. More like ramping up the manufacturing of oil booms independent of the experts daily activities since the experts really aren't needed to explain how to manufacture a plain old oil boom. >>> Better to focus on v6 transition. >> >> Myopic. Unless another credible solution presents, IPv4 carrier NATs >> -ARE- the v6 transition. >> > IPv4 carrier NATs are the temporary hack to get around the incomplete > nature of the transition at runout. The transition is to native dual stack or > native IPv6. I hear exactly zero chatter in the ops forums about bypassing dual stack in favor of going direct to native v6. I know some work has been done on nat64 but are you aware of shipping COTS products designed for enabling large scale collections of native v6 clients to communicate with v4 servers? Unless something changes, the transition is to dual stack. Which requires an IPv4 address. From somewhere. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From trejrco at gmail.com Sun Jun 27 18:25:32 2010 From: trejrco at gmail.com (TJ) Date: Sun, 27 Jun 2010 18:25:32 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> Message-ID: (apologies for top-posting) There is atleast 1 ISP planning to deploy IPv6-only devices (handsets) in the near future, and they will rely on NAT64 for those devices to reach IPv4 destinations ... I personally suspect others will follow suit. /TJ On Jun 27, 2010 3:06 PM, "William Herrin" wrote: On Sun, Jun 27, 2010 at 2:09 PM, Owen DeLong wrote: >> What isn't debatable is tha... Not a zero sum game. The likely resources mostly aren't working on IPv6 right now regardless. > It seems sort of like deciding to pull the experts off the efforts to cap the > well in the Gulf ... More like ramping up the manufacturing of oil booms independent of the experts daily activities since the experts really aren't needed to explain how to manufacture a plain old oil boom. >>> Better to focus on v6 transition. >> >> Myopic. Unless another credible solution presents, IPv... I hear exactly zero chatter in the ops forums about bypassing dual stack in favor of going direct to native v6. I know some work has been done on nat64 but are you aware of shipping COTS products designed for enabling large scale collections of native v6 clients to communicate with v4 servers? Unless something changes, the transition is to dual stack. Which requires an IPv4 address. From somewhere. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3... PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing Lis... -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sun Jun 27 19:02:42 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Jun 2010 16:02:42 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> Message-ID: On Jun 27, 2010, at 3:05 PM, William Herrin wrote: > On Sun, Jun 27, 2010 at 2:09 PM, Owen DeLong wrote: >>> What isn't debatable is that we're approaching a dire shortage and >>> right now 240/4 is a honking lot of address space that benefits >>> exactly _nobody_. >>> >> But pulling resources off of IPv6 deployment to make this address space >> workable, even in the scenarios you suggest simply doesn't make sense. >> Taking resources away from a solution in order to propel a hack that will >> by all accounts take nearly as long as the solution in order to develop >> and deploy, especially when the solution already has momentum and >> is accelerating simply doesn't make sense to me. > > Not a zero sum game. The likely resources mostly aren't working on > IPv6 right now regardless. > We can agree to disagree about this. Even if the resources aren't working on IPv6 right now, they could be. Redirecting them to this sort of boondoggle instead is a zero sum game or worse. >> It seems sort of like deciding to pull the experts off the efforts to cap the >> well in the Gulf of Mexico in favor of having them build oil containment >> booms, since we don't have nearly enough of those. > > More like ramping up the manufacturing of oil booms independent of the > experts daily activities since the experts really aren't needed to > explain how to manufacture a plain old oil boom. > Except in this case, we don't have those multiple pools of resources. There is still lots of development work that needs to be done to bring IPv6 to fruition. Feature parity still isn't there in lots of things like load-balancers, firewalls, etc. > >>>> Better to focus on v6 transition. >>> >>> Myopic. Unless another credible solution presents, IPv4 carrier NATs >>> -ARE- the v6 transition. >>> >> IPv4 carrier NATs are the temporary hack to get around the incomplete >> nature of the transition at runout. The transition is to native dual stack or >> native IPv6. > > I hear exactly zero chatter in the ops forums about bypassing dual > stack in favor of going direct to native v6. I know some work has been > done on nat64 but are you aware of shipping COTS products designed for > enabling large scale collections of native v6 clients to communicate > with v4 servers? > Who said anything about bypassing dual-stack? We need to be dual-stacking the servers and the content as fast as possible to minimize the need for providing IPv4 solutions to clients that can't get IPv4 addresses, because, reality is there are NO GOOD solutions for that situation. LSN, nat64, and all the others all have their own different sets of pitfalls. However, if we can dual stack the majority of the content and/or services that end users care about prior to run out (and I believe this is actually possible), then, new end-users getting IPv6-only with hacks to reach a tiny subset of internet content that isn't IPv6-yet will be a lot less traumatic than the alternatives. > Unless something changes, the transition is to dual stack. Which > requires an IPv4 address. From somewhere. > The transition only needs to be to dual stack at one end of the equation. Dual-stacking the content and servers can still be done in time. Dual-stacking the eye-balls is a daunting task, and, as you point out, eye-ball growth will eventually preclude doing so because of a lack of IPv4 addresses with which to dual-stack. Owen From bicknell at ufp.org Sun Jun 27 19:23:33 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 27 Jun 2010 16:23:33 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> Message-ID: <20100627232333.GA76942@ussenterprise.ufp.org> In a message written on Sun, Jun 27, 2010 at 11:09:24AM -0700, Owen DeLong wrote: > But pulling resources off of IPv6 deployment to make this address space > workable, even in the scenarios you suggest simply doesn't make sense. > Taking resources away from a solution in order to propel a hack that will > by all accounts take nearly as long as the solution in order to develop > and deploy, especially when the solution already has momentum and > is accelerating simply doesn't make sense to me. The two are not mutually exclusive. For instance, some providers have decided to deploy IPv6 over MPLS because their core devices can't support IPv6 forwarding in hardware. However, you can't bring up MPLS without IPv4 addressing, as right now the various MPLS protocols are tied to IPv4 IGP's in interesting ways. So imagine a new entrant down the road. We've thought about these folks, wanting to set aside space for them to be able to enter the market; see a good part of the discussion on "the last /8". Imagine if they could turn up a core in 240/4, which would be relatively easy for them to insure all of their boxes supported, and then run IPv4 and IPv6 over MPLS. Even if their core was used natively for IPv4, devices "far away" that filtered it would have the same issues that today cores using 10/8 have; PMTU might break if the lower MTU is on a "filtered" block, your traceroute may look funny, but the packets get from A to B. In fact not all end points need to be upgraded to make 240/4 work. It could be used inside of ISP's to conserve other globally routeable space, or to allow a new entrant to bring up an IPv6 core, all by only having a single ISP make sure they are upgraded. This is one of those areas where I frankly don't understand the reluctance of most of my colleagues in this area. Change it from reserved to SHOULD be treated as Unicast (note, not must). Set a simple policy that the IANA can hand it out post run-out to the RIR's. The RIR's can hand it out with gigantic 72 point font multi-page disclaimers that it may not work on the global Internet. Cost to the standards and policy process, virtually zero. If a vendor makes it work on their hardware, and an ISP finds a way to use it, great, we helped someone make the Internet go. If no one uses it, oh well, at least people can't say we didn't try everything possible. Seriously, do you really think this will draw critical resources away from IPv6? -- 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 bill at herrin.us Sun Jun 27 22:10:44 2010 From: bill at herrin.us (William Herrin) Date: Sun, 27 Jun 2010 22:10:44 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100627232333.GA76942@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <20100627232333.GA76942@ussenterprise.ufp.org> Message-ID: On Sun, Jun 27, 2010 at 7:23 PM, Leo Bicknell wrote: > In a message written on Sun, Jun 27, 2010 at 11:09:24AM -0700, Owen DeLong wrote: >> But pulling resources off of IPv6 deployment to make this address space >> workable, even in the scenarios you suggest simply doesn't make sense. >> Taking resources away from a solution in order to propel a hack that will >> by all accounts take nearly as long as the solution in order to develop >> and deploy, especially when the solution already has momentum and >> is accelerating simply doesn't make sense to me. > > The two are not mutually exclusive. ?For instance, some providers > have decided to deploy IPv6 over MPLS because their core devices > can't support IPv6 forwarding in hardware. > > Seriously, do you really think this will draw critical resources away > from IPv6? Hi Leo, If it does, it will surely include some of the folks on this mailing list. So, if "YOU" believe that that "YOU" will spend less manpower that you currently spend implementing IPv6 as a result of allocating 240/4 for private IP address space, please speak up now or at least drop me a line privately so that we can either confirm the issue or lay it to rest. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at chl.com Sun Jun 27 23:01:06 2010 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 27 Jun 2010 23:01:06 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100627232333.GA76942@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <20100627232333.GA76942@ussenterprise.ufp.org> Message-ID: <4C281072.3060506@chl.com> Leo Bicknell wrote: > Seriously, do you really think this will draw critical resources > away from IPv6? > Yes, people do seem to have this fear, in one form or another. Either for the resources or the urgency and collective acceptance of our IPv6 fate. However, I believe that drawing in contribution and resources can produce a larger net positive sum for all objectives than discounting contributions and resources unfocused on a desired objective. To the extent that IPv6 odds of success are specifically dependent on the status quo, corresponding fail. Joe From mysidia at gmail.com Sun Jun 27 23:08:22 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 27 Jun 2010 22:08:22 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> Message-ID: On Sun, Jun 27, 2010 at 1:09 PM, Owen DeLong wrote: However, it's not possible to draw resources away from IPv6 deployment that are not even performing anything required to further IPv6 deployment in the first place. > It seems sort of like deciding to pull the experts off the efforts to cap the > well in the Gulf of Mexico in favor of having them build oil containment > booms, since we don't have nearly enough of those. That is an interesting analogy. But do you abandon all efforts to cap or contain, just to make sure no experts dare even think about anything other than drilling relief wells? The logical parallel for that analogy, being: temporary CAP = things like carrier grade NAT, freeing up 240/8, etc... relief wells = IPv6. IPv6 is eventually a solution to all the addressing shortage woes, however, implementation will take a long time, uptake and rate of adoption are extremely low, and hardly any networks have full V6 connectivity or will have full V6 connectivity anytime soon. For many appliances that don't have IPv6 support at this stage, it is unlikely that the manufacturer is even working on it. We don't really have a say in how companies choose to allocate their resources. The resources required to adjust the status of 240/4 ought to be a miniscule drop in the bucket. The resources required for V6 deployment are massive. -- -JH From michael.dillon at bt.com Mon Jun 28 04:16:18 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jun 2010 09:16:18 +0100 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> Message-ID: <28E139F46D45AF49A31950F88C49745806647402@E03MVZ2-UKDY.domain1.systemhost.net> > Part of my reason for preferring 240/4's use as private addresses is > that you can reasonably hope to control what goes on inside your own > network. Right. So use 126/8 inside your network. > What isn't debatable is that we're approaching a dire shortage and > right now 240/4 is a honking lot of address space that benefits > exactly _nobody_. Somebody calculated how long this would extend the IPv4 lifetime and it turned out to only be a few months. That is not a honking lot, but a drop in the bucket. And we are not approaching a dire shortage. We are approaching the land of plenty, but to get there we first have to cross the scorching desert. The clever folk crossed it in winter, but now it is summer and the laggards are suffering accordingly. But even for them, the land of plenty has room amongst its green meadows and shimmering lakes. > > Better to focus on v6 transition. > > Myopic. Unless another credible solution presents, IPv4 carrier NATs > -ARE- the v6 transition. It's not so simple. Carrier Grade NAT costs money. Some companies will dump low profit customers to recover addresses for more lucrative use. Some will forcefully move customers to new IPv6 services for the same reason. Economics will be the driver and different companies have very different internal economics. And let's not forget that companies are run by decision makers. These people may just ignore the problem and jump ship. This is a common practice amongst the next-quarter-focused MBA crowd. It may well drive a few companies into bankruptcy, and then the companies who have IPv6 services ready wil be able to grow their network fast enough to take on the sudden rush of new customers. We really cannot predict anything other than the fact that it is now too late for a smooth transition, and we are in for a couple of years of Internet operations chaos. --Michael Dillon From lear at cisco.com Mon Jun 28 04:18:55 2010 From: lear at cisco.com (Eliot Lear) Date: Mon, 28 Jun 2010 10:18:55 +0200 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> Message-ID: <4C285AEF.9020905@cisco.com> Hi James, Thanks for your note and that of others on this topic. As merely a member of the IETF community, I'm representing a broader set of views than my own, and I may be doing a poor job of it. Please ask others if you like on the int-area mailing list that can be found via www.ietf.org. On 6/27/10 8:58 PM, James Hess wrote: > On Sun, Jun 27, 2010 at 6:10 AM, Eliot Lear wrote: > [snip] >> It would take forever to fix printers, fridges, and other appliances, along >> with routers, firewalls, and other middle boxes. > If IP enabled fridges can no longer use the LAN, then so be it.. > > It may be hard to convince manufacturers of even new devices to 'fix' > it, yes, but > forever is a long time. And the time it takes is measured starting > _from the time the block is no longer marked as special_. Currently > deployed printers, fridges, and other appliances have not even been in > service using IPv4 forever. I would suggest you consider a Rogers Innovation Adoption Curve , and consider that for IPv6 alone, estimates for adoption are very very long periods of time (many decades) [Elmore08 <#Elmore08>][*], and IPv6 is considered a substantial improvement to the situation such that, absent a paradigm shift, we will not see need for larger addresses. Now consider something with considerably less draw, like 16 (really 15) /8 blocks, and the incentive to actually code changes for IPv4 would be limited at best. Taking this into account, as well as when we think the first use would be safe for those who would need it, one could conclude "forever" may very well be accurate in this case. One way we can test this is that I can tell you that to the best of my knowledge (and I was one of the authors proposing using 240/4) we received very little interest from customers who might benefit from this space being used, even after we put an idea forward. That's a pretty good indicator that we were on the wrong path. There may yet be a right path for 240/4 that we haven't considered. Some of your ideas, James, about specific applicable uses of that space may yet hold water, but would have to be compared against the costs and benefits of going to v6 at the microeconomics level, because it seems likely that v6 would be substitutable for many such cases. The reverse is assuredly not so. All of this having been said, we have what amounts to an image problem with that space, at least for now. The above analysis is a cursory summary, and even so is not easily digested. This leaves the community open to attacks by those who haven't seriously considered the problem and may wish to make hay of it. My only answer to that is that such open public discussions as the one we are engaged in are very VERY useful to assure there's not an angle we have missed. Eliot [Elmore08] Diffusion and Adoption of IPv6 in the ARIN Region, Elmore, H., Camp., LJ, Stephens, S, Workshop on the Economics of Information Security, June 2008. [*] The above paper was an early estimate with limited information. I would welcome additional work along the same lines with updated information. Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Mon Jun 28 04:37:36 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jun 2010 09:37:36 +0100 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> Message-ID: <28E139F46D45AF49A31950F88C4974580664744C@E03MVZ2-UKDY.domain1.systemhost.net> > Unless something changes, the transition is to dual stack. Which > requires an IPv4 address. From somewhere. Dual stack is not a transition, it is an addition. By adding IPv6 to your network you get closer to transition, but it does nothing to help a pure IPv6 client get access to IPv4 resources. Running an IPv6 Internet parallel to an IPv4 Internet was a good idea for transition 10 years ago when there was a chance for IPv4 traffic to just fade away, as IPv4-only devices became obsolete and were decommmissioned. But not today. Nowadays, in order to qualify as an IPv6 transition you have to have something (Teredo, 6to4 gateways, NAT-PT) which will help interconnect the IPv6 and IPv4 Internets. --Michael Dillon From michael.dillon at bt.com Mon Jun 28 04:42:20 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jun 2010 09:42:20 +0100 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org><4C2731BC.6080300@cisco.com><693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> Message-ID: <28E139F46D45AF49A31950F88C4974580664745C@E03MVZ2-UKDY.domain1.systemhost.net> > The transition only needs to be to dual stack at one end of the > equation. > Dual-stacking the content and servers can still be done in time. First, I think that this is an overly simplistic view of the Internet. Second, I think that transitioning the large centralised services over to IPv6 will not, for the most part, be done using dual-stack. More likely will be separate IPv6 server pools, and proxies which allow IPv6 clients to access IPv4 servers. And 6to4, of course. --Michael Dillon From owen at delong.com Mon Jun 28 06:24:17 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Jun 2010 03:24:17 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <28E139F46D45AF49A31950F88C4974580664744C@E03MVZ2-UKDY.domain1.systemhost.net> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <28E139F46D45AF49A31950F88C4974580664744C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <1AF6B07A-C951-4667-BBC4-5EF8DA933F8A@delong.com> On Jun 28, 2010, at 1:37 AM, wrote: >> Unless something changes, the transition is to dual stack. Which >> requires an IPv4 address. From somewhere. > > Dual stack is not a transition, it is an addition. By adding IPv6 to > your network you get closer to transition, but it does nothing to > help a pure IPv6 client get access to IPv4 resources. Running an > IPv6 Internet parallel to an IPv4 Internet was a good idea for > transition 10 years ago when there was a chance for IPv4 traffic > to just fade away, as IPv4-only devices became obsolete and > were decommmissioned. > > But not today. Nowadays, in order to qualify as an IPv6 transition > you have to have something (Teredo, 6to4 gateways, NAT-PT) which > will help interconnect the IPv6 and IPv4 Internets. > > --Michael Dillon You misunderstand what Teredo and 6to4 gateways do in the above description. They merely provide tunnels (automatically) to connect IPv6 islands across IPv4 infrastructure. NAT-PT connects IPv4 clients to IPv6 services or vice-versa. The other two do not. However, what is needed today, as was many years ago is to get as much content and services as possible to add IPv6 capabilities to their infrastructure and make their content and services available on both protocols. With a reasonably good accomplishment of that one relatively simple goal, the protocol used by the eyeballs becomes mostly irrelevant and IPv6-only eyeballs become a feasible service. The rest will take care of itself as we transition later to IPv6-only almost-everything. Owen From owen at delong.com Mon Jun 28 06:28:06 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Jun 2010 03:28:06 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <28E139F46D45AF49A31950F88C4974580664745C@E03MVZ2-UKDY.domain1.systemhost.net> References: <20100625185734.GA95305@ussenterprise.ufp.org><4C2731BC.6080300@cisco.com><693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <28E139F46D45AF49A31950F88C4974580664745C@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <24147CBD-35FF-48B8-92EE-0A029E38D36E@delong.com> On Jun 28, 2010, at 1:42 AM, wrote: > >> The transition only needs to be to dual stack at one end of the >> equation. >> Dual-stacking the content and servers can still be done in time. > > First, I think that this is an overly simplistic view of the Internet. > Second, I think that transitioning the large centralised services over > to IPv6 will not, for the most part, be done using dual-stack. > More likely will be separate IPv6 server pools, and proxies which > allow IPv6 clients to access IPv4 servers. And 6to4, of course. > > --Michael Dillon Well, the large ones that I know of that have done it already are using dual-stack. I started to name names, but, I don't know for sure which ones I am allowed to disclose at that level, so, I will not. I know that it is public that Google is doing IPv4 and IPv6 dual stack on the same infrastructure if your resolver is whitelisted. However, it really doesn't matter whether they use dual-stack or other mechanisms so long as an IPv6 client can reach the same content and services via IPv6 that are available via IPv4. My point is that the content and services need to be made available on both protocols. It was not my intent to dictate specific means of getting there. Finally, this word 6to4...It does not mean what you seem to think it means. Owen From Lee at dilkie.com Mon Jun 28 06:51:59 2010 From: Lee at dilkie.com (Lee Dilkie) Date: Mon, 28 Jun 2010 06:51:59 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <24147CBD-35FF-48B8-92EE-0A029E38D36E@delong.com> References: <20100625185734.GA95305@ussenterprise.ufp.org><4C2731BC.6080300@cisco.com><693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <28E139F46D45AF49A31950F88C4974580664745C@E03MVZ2-UKDY.domain1.systemhost.net> <24147CBD-35FF-48B8-92EE-0A029E38D36E@delong.com> Message-ID: <4C287ECF.2000509@dilkie.com> On 6/28/2010 6:28 AM, Owen DeLong wrote: > > Finally, this word 6to4...It does not mean what you seem to think it means. > > Inconceivable ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Mon Jun 28 07:20:53 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jun 2010 12:20:53 +0100 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <1AF6B07A-C951-4667-BBC4-5EF8DA933F8A@delong.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <28E139F46D45AF49A31950F88C4974580664744C@E03MVZ2-UKDY.domain1.systemhost.net> <1AF6B07A-C951-4667-BBC4-5EF8DA933F8A@delong.com> Message-ID: <28E139F46D45AF49A31950F88C49745806647614@E03MVZ2-UKDY.domain1.systemhost.net> > You misunderstand what Teredo and 6to4 gateways do in the above > description. Nope. > They merely provide tunnels (automatically) to connect IPv6 islands > across IPv4 infrastructure. IPv6 island A - IPv6 servers inside content provider's data center. IPv6 island B - laptop of end user whose ISP has not yet dual-stacked. If the content provider has a 6to4 gateway in their data centre, then island B can connect to island A. > NAT-PT connects IPv4 clients to IPv6 services or vice-versa. > The other two do not. Just a different flavor. There are no IPv6 transition magic bullets, just a bunch of pieces that all solve one part of the puzzle. > However, what is needed today, as was many years ago is to get as > much content and services as possible to add IPv6 capabilities to their > infrastructure and make their content and services available on both > protocols. Those are two different things. Adding IPv6 to their infrastructure is a much bigger task than making their services available on IPv6. For one thing, there is the issue of data center middlebox feature parity on things like load balancers and firewalls. You need to solve that in order to upgrade the infrastructure, but there are workarounds if your goal is only to get services available on v6. --Michael Dillon From michael.dillon at bt.com Mon Jun 28 07:42:22 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 28 Jun 2010 12:42:22 +0100 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <24147CBD-35FF-48B8-92EE-0A029E38D36E@delong.com> References: <20100625185734.GA95305@ussenterprise.ufp.org><4C2731BC.6080300@cisco.com><693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <28E139F46D45AF49A31950F88C4974580664745C@E03MVZ2-UKDY.domain1.systemhost.net> <24147CBD-35FF-48B8-92EE-0A029E38D36E@delong.com> Message-ID: <28E139F46D45AF49A31950F88C49745806647663@E03MVZ2-UKDY.domain1.systemhost.net> > My point is that the content and services need to be made available on > both protocols. It was not my intent to dictate specific means of > getting there. Then we agree. > Finally, this word 6to4...It does not mean what you seem to think it > means. Perhaps then I misunderstand this comment: Not quite correct. 6to4 does not require transiting a relay if the target is another 6to4 site. What this means is that a clueful content provider will put up a 6to4 router alongside whatever native service they provide, then populate the dns with both the native and 6to4 address. which can be found on ARIN's IPv6 wiki here That was really all that I was getting at. As for the intricacies of 6to4, I probably don't fully understand them. But it seems to me that a v6 client without v6 connectivity will try to use a 6to4 tunnel, and that there is benefit to content providers implementing 6to4 relays beside their servers. --Michael Dillon From bill at herrin.us Mon Jun 28 08:30:38 2010 From: bill at herrin.us (William Herrin) Date: Mon, 28 Jun 2010 08:30:38 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <28E139F46D45AF49A31950F88C49745806647663@E03MVZ2-UKDY.domain1.systemhost.net> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <28E139F46D45AF49A31950F88C4974580664745C@E03MVZ2-UKDY.domain1.systemhost.net> <24147CBD-35FF-48B8-92EE-0A029E38D36E@delong.com> <28E139F46D45AF49A31950F88C49745806647663@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Mon, Jun 28, 2010 at 7:42 AM, wrote: >> Finally, this word 6to4...It does not mean what you seem to think it >> means. > > Perhaps then I misunderstand this comment: > > ? Not quite correct. 6to4 does not require transiting a > relay if the target is another 6to4 site. What this means > is that a clueful content provider will put up a 6to4 > router alongside whatever native service they > provide, then populate the dns with both the native > and 6to4 address. You understood the comment. Unfortunately, the content's poster misunderstood both 6to4 and the DNS. DNS is not selective. It won't use the "best" entry, it'll use any entry. If you put in entries for both native IPv6 and a 6to4 address, you'll get as much cross-traffic transiting relays (native to 6to4 and vice versa) as you do 6to4 to 6to4 and native to native. The public relays are anycasted by volunteers and are generally quite slow. Suitable for testing and learning IPv6 but completely unsuitable for production use. You wouldn't want the 6to4 path preferred over your IPv4 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 jmaimon at chl.com Mon Jun 28 10:08:00 2010 From: jmaimon at chl.com (Joe Maimon) Date: Mon, 28 Jun 2010 10:08:00 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C285AEF.9020905@cisco.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <4C285AEF.9020905@cisco.com> Message-ID: <4C28ACC0.8000207@chl.com> Eliot Lear wrote: > Hi James, > > Thanks for your note and that of others on this topic. t so. > > All of this having been said, we have what amounts to an image problem > with that space, at least for now. The above analysis is a cursory > summary, and even so is not easily digested. This leaves the community > open to attacks by those who haven't seriously considered the problem > and may wish to make hay of it. My only answer to that is that such > open public discussions as the one we are engaged in are very VERY > useful to assure there's not an angle we have missed. > > Eliot > > [Elmore08] Diffusion and Adoption of IPv6 in the ARIN Region, Elmore, > H., Camp., LJ, Stephens, S, Workshop on the Economics of Information > Security, June 2008. > [*] The above paper was an early estimate with limited information. I > would welcome additional work along the same lines with updated information. > > Eliot Unfortunately there are a lot of grassy meadows that appear available to those who may wish to make hay. 240/4 is just one of them. Joe From Wesley.E.George at sprint.com Mon Jun 28 10:32:33 2010 From: Wesley.E.George at sprint.com (George, Wes E IV [NTK]) Date: Mon, 28 Jun 2010 09:32:33 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100625202948.GA1492@ussenterprise.ufp.org> References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell Sent: Friday, June 25, 2010 4:30 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Use of "reserved" address space. I think upgrading all of the routers, including both backbone and more importantly home gateways is the larger challenge, they don't have that facility. But, everyone already has to upgrade those to support IPv6. Might as well get an image that gets you IPv6 + reserved space for the price of one upgrade. [[WEG]] I don't know about you, but I haven't seen a lot of effort to back-port old SOHO routers (like my Linksys WRT350N) to support IPv6. Mostly, the vendors seem content to abandon these once they get a little beyond warranty (basically, they're cheap, and cheap = disposable). Case in point, my "draft N" device has not gotten an updated version of software that is truly compliant with the final 802.11n standard. Maybe they guessed right and no update was needed, but either way, the last software update was in 2008. Manufacturers are primarily assuming that if support for IPv6 becomes critical, either the upstream provider will simply give their customer a new box or require them to buy a new one, or that if the owner of said box is sufficiently savvy, they will use something like OpenWRT. The response I have been getting when I directly ask representatives of [company] about this is to hide behind support/development costs, device (planned) obsolescence, and hardware limits. So I agree that "while you have the hood open" is a valid point, but the problem is that no one is actually doing this for a significant subset of the consumer devices. They fall into the same chasm as the Win98/ME/2K boxes that are no longer technically supported and extremely unlikely to be updated, regardless of the need. Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From bill at herrin.us Mon Jun 28 10:48:13 2010 From: bill at herrin.us (William Herrin) Date: Mon, 28 Jun 2010 10:48:13 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <1AF6B07A-C951-4667-BBC4-5EF8DA933F8A@delong.com> References: <20100625185734.GA95305@ussenterprise.ufp.org> <4C2731BC.6080300@cisco.com> <693349FA-FEFB-4714-BFDB-9EC9258114EE@delong.com> <28E139F46D45AF49A31950F88C4974580664744C@E03MVZ2-UKDY.domain1.systemhost.net> <1AF6B07A-C951-4667-BBC4-5EF8DA933F8A@delong.com> Message-ID: On Mon, Jun 28, 2010 at 6:24 AM, Owen DeLong wrote: > However, what is needed today, as was many years ago is to get as > much content and services as possible to add IPv6 capabilities to their > infrastructure and make their content and services available on both > protocols. What was needed many years ago was a way to enable IPv6 without automatically prioritizing it over IPv4 so that turning on dual-stack was an appropriately minimum-risk proposition in CMMI-5 systems. Now? Now prioritizing the AAAA responses is embedded in deployed applications and it's going to prove damn close to a fatal design flaw. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Mon Jun 28 12:39:18 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 28 Jun 2010 09:39:18 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: <20100625185734.GA95305@ussenterprise.ufp.org> <20100625202948.GA1492@ussenterprise.ufp.org> <4C256B97.70802@sprunk.org> <4C26D1B6.8090508@chl.com> Message-ID: <4C28D036.3010301@ipinc.net> On 6/26/2010 9:54 PM, James Hess wrote: > On Sat, Jun 26, 2010 at 11:21 PM, Joe Maimon wrote: >> What is wrong with an approach of "All of the above"? >> Anyways, strong odds suggest that removing restrictions on reserved space is >> a much simpler code change than including another network stack, in any OS >> and in any firmware. > > This is definitely true. Removing an arbitrary restriction on some > IPs is much simpler a change than adding an extra IP stack. And it > should require at most a minor update to the standards, to adjust the > reserved blocks to indicate host and router software should support > unicast for all those blocks from now on. > > As far as I can tell , the internet is not on course for a > well-implemented transition to IPv6. > It is on a collision course with IP exhaustion, and the fallout of > the crash is NAT hell. > A lot of orgs will NOT even look at IPv6 until that crash happens. That's just human nature. > > Even if a decision will not be immediately made to offer to allocate > address space from those blocks. > The availability of those currently reserved blocks could definitely > be useful in the future, every effort should be made as soon as > possible to encourage software being made now and in the future to > support those IPs.... provisions should be made immediately, to > require all internet hosts to be capable of receive and send packets, > and be configured to use any parts of those special blocks that are > not actually used and can be unreserved. > > > You can implement IPv6 on your network, but you cannot force everyone > you want to talk to to do so at this point. The cost of getting other > people to use IPv6 would be very high. The cost of deploying IPv6 on > your own network is irrelevent, once you have IPv6 networking, it's > everyone else's network that matters. > > > The cost of asking other networks to patch their routers to fix > connectivity to formerly-reserved blocks is nil. > You can even report to them "your equipment has this issue, bug, > please do something about it".. > > > Rather than having to say "We don't have IPv4 connectivity, will you > please setup an IPv6 network, so we can talk to you?" Which is > more likely to get "No" > Correct. I don't subscribe to the excuse that anyone is ever going to be able to say "We don't have IPv4 connectivity" with a straight face. There will ALWAYS BE an upstream they can get non-portable numbers from. And if IPv4 is that scarce then there would be good money to be made for IPv4 holders to sell (or offer for free) IPv4 via tunnel, just like Hurricaine Electric is doing with IPv6 now. Ted > as a response than "Ok.. we'll see if we can > fix that" > The real cost of deploying IPv6 is not just a code change to > equipment, it is the IP network re-design, planning, etc, required. > > When the planning and design required to have a V6 network has not > been done, the less costly alternative to V6 is probably NAT hell. > > -- > -JH > _______________________________________________ > 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 marquis at roble.com Tue Jun 29 18:30:24 2010 From: marquis at roble.com (Roger Marquis) Date: Tue, 29 Jun 2010 15:30:24 -0700 (PDT) Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: References: Message-ID: <20100629223024.CC65E2B2131@mx5.roble.com> Ted Mittelstaedt wrote: > On 6/26/2010 9:54 PM, James Hess wrote: >> As far as I can tell , the internet is not on course for a >> well-implemented transition to IPv6. It is on a collision course with IP >> exhaustion, and the fallout of the crash is NAT hell. NAT hell for some, but not those of of us with NAT experience and security responsibilities. We would be happy to deploy more NAT, including LSN, if it means a smooth transition to IPv6, especially if it also means some responsible organization will someday take responsibility for A) the inevitable process of reclaiming unused legacy allocations, and B) denying new allocations to entities who can use NAT/LSN but are not. Doesn't look like ARIN or the IETF is capable of being that organization though. > A lot of orgs will NOT even look at IPv6 until that crash happens. Havent seen much of that to be honest. Most of those who have tried dual-stack end-nodes have found it unworkable. End-user organizations are looking for a transition to IPv6 and are (IME) more than willing to use IPv6 externally, but the gear is not available and there is no business case for making internal address space globally unique or re-numberable (where multi-homed). > That's just human nature. That's another of those unsupportable claims that cannot be explained except perhaps by financial interest (in speculative address shortages). It is not unlike claims that * multi-homed sites can get by with internal renumbering, * NAT is "too hard", * LSN is not transparent enough, * NAT has no security benefit, * netops won't mind if three-way handshakes can be initiated from external networks, * NAT breaks properly designed protocols, * properly designed firewalls can replace NAT, ... Because of these speculative interests the cost of IPv6 is too high to warrant investment in IPv6 today. When transitional technology (NAT) that meets end-user requirements is made ubiquitous we will see IPv6 uptake in earnest. IMO, Roger Marquis From jcurran at arin.net Tue Jun 29 21:25:40 2010 From: jcurran at arin.net (John Curran) Date: Tue, 29 Jun 2010 21:25:40 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100629223024.CC65E2B2131@mx5.roble.com> References: <20100629223024.CC65E2B2131@mx5.roble.com> Message-ID: <84DE39E8-57CD-4EE9-ADE4-F61ECAADEA25@arin.net> On Jun 29, 2010, at 6:30 PM, Roger Marquis wrote: > We would be happy to deploy more NAT, including LSN, > if it means a smooth transition to IPv6, especially if it > also means some responsible organization will someday take responsibility > for A) the inevitable process of reclaiming unused legacy allocations, > and B) denying new allocations to entities who can use NAT/LSN but are > not. Doesn't look like ARIN or the IETF is capable of being that > organization though. Roger - ARIN is responsible, but that's for the implementation of number resource policy which is actually adopted by the community. If you want that policy to include unused legacy resource reclamation or no allocations for organizations which can make use of NAT/LSN, then you need to introduce policy proposals to that end. (See https://www.arin.net/policy/pdp_appendix_b.html regarding submitting policy proposals) FYI, /John John Curran President and CEO ARIN From marquis at roble.com Tue Jun 29 21:35:52 2010 From: marquis at roble.com (Roger Marquis) Date: Tue, 29 Jun 2010 18:35:52 -0700 (PDT) Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <84DE39E8-57CD-4EE9-ADE4-F61ECAADEA25@arin.net> References: <20100629223024.CC65E2B2131@mx5.roble.com> <84DE39E8-57CD-4EE9-ADE4-F61ECAADEA25@arin.net> Message-ID: <20100630013552.9D1F22B2131@mx5.roble.com> > On Jun 29, 2010, at 6:30 PM, Roger Marquis wrote: >> We would be happy to deploy more NAT, including LSN, >> if it means a smooth transition to IPv6, especially if it >> also means some responsible organization will someday take responsibility >> for A) the inevitable process of reclaiming unused legacy allocations, >> and B) denying new allocations to entities who can use NAT/LSN but are >> not. Doesn't look like ARIN or the IETF is capable of being that >> organization though. > > Roger - > > ARIN is responsible, but that's for the implementation of number > resource policy which is actually adopted by the community. If > you want that policy to include unused legacy resource reclamation > or no allocations for organizations which can make use of NAT/LSN, > then you need to introduce policy proposals to that end. > > (See https://www.arin.net/policy/pdp_appendix_b.html regarding > submitting policy proposals) Thanks for the pointer John. The crux of this impasse, however, is the community vote. Those with a financial interest in address exhaustion and their proxies currently have a majority. Even something as clean as Proposal 112 doesn't stand a chance. Roger Marquis From mysidia at gmail.com Tue Jun 29 21:43:22 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 29 Jun 2010 20:43:22 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100629223024.CC65E2B2131@mx5.roble.com> References: <20100629223024.CC65E2B2131@mx5.roble.com> Message-ID: On Tue, Jun 29, 2010 at 5:30 PM, Roger Marquis wrote: > Ted Mittelstaedt wrote: >> On 6/26/2010 9:54 PM, James Hess wrote: >>> As far as I can tell , the internet is not on course for a >>> well-implemented transition to IPv6. It is on a collision course with IP >>> exhaustion, and the fallout of the crash is NAT hell. > NAT hell for some, but not those of of us with NAT experience and > security responsibilities. ?We would be happy to deploy more NAT, I'm sorry.. I didn't fully indicate exactly what I meant by NAT hell. The WHOIS directory becomes almost worthless, when every network is behind a 1:many NAT. Or perhaps a SWIP or other option could be provided to indicate that certain IP addresses are NAT, and the address of an IDENT server to connect to, to get a RFC1918 IP address (associated with a source port), for abuse reporting purposes? It's hell, if NAT actually becomes an alternative to V6, because the End-to-End principal will die; it becomes more like broadcast mediums such as Television, where only "licensed" hosts that got public IPs can publish websites. Precisely tracking and locating abuse of network resources will become impossible. Blacklisting, banning, or rate limiting one IP address (for example, a bot crawling a web site), may effect thousands of legitimate users. How many resources are the ISPs really going to consume to try to help you track down and stop the source of a malicious packet, small scale DDoS, or spam streak? We should know we are on the road to NAT hell if we see a low rate of IPv6 adoption (as we can observe rather plainly), AND: (1) NAT overloading across organizational boundaries becomes more widespread (for example, a residential ISP, sharing one IP address with thousands of customers) Also, if large enterprises start using private addressing and small numbers of public IPs. While at the same time either NOT offering any IPv6 connectivity, or not providing V6 capable CPE. ..AND (2) Multiple one-to-many NAT setups without V6 connectivity become widespread. Multiple NAT being N>1 hops of translation to new private networks, they share a public IP. Example scenario being: an Enterprise has installed their own "router" product that implements RFC1918 addressing for the LAN side. ISP provides a CPE that gives the enterprise an RFC1918 address on the WAN side (which is assigned using DHCP). (And by the way, could conflict with the customer's LAN addressing -- in that case, the customer will have to negotiate with the ISP, add yet another NAT device, or renumber their LAN to accomodate their ISP's lack of IPs) -- -JH From oberman at es.net Wed Jun 30 01:31:42 2010 From: oberman at es.net (Kevin Oberman) Date: Tue, 29 Jun 2010 22:31:42 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: Your message of "Tue, 29 Jun 2010 18:35:52 PDT." <20100630013552.9D1F22B2131@mx5.roble.com> Message-ID: <20100630053142.B71271CC0D@ptavv.es.net> > Date: Tue, 29 Jun 2010 18:35:52 -0700 (PDT) > From: Roger Marquis > Sender: arin-ppml-bounces at arin.net > > > On Jun 29, 2010, at 6:30 PM, Roger Marquis wrote: > >> We would be happy to deploy more NAT, including LSN, > >> if it means a smooth transition to IPv6, especially if it > >> also means some responsible organization will someday take responsibility > >> for A) the inevitable process of reclaiming unused legacy allocations, > >> and B) denying new allocations to entities who can use NAT/LSN but are > >> not. Doesn't look like ARIN or the IETF is capable of being that > >> organization though. > > > > Roger - > > > > ARIN is responsible, but that's for the implementation of number > > resource policy which is actually adopted by the community. If > > you want that policy to include unused legacy resource reclamation > > or no allocations for organizations which can make use of NAT/LSN, > > then you need to introduce policy proposals to that end. > > > > (See https://www.arin.net/policy/pdp_appendix_b.html regarding > > submitting policy proposals) > > Thanks for the pointer John. The crux of this impasse, however, is the > community vote. Those with a financial interest in address exhaustion > and their proxies currently have a majority. Even something as clean as > Proposal 112 doesn't stand a chance. You appear to not understand how ARIN operates. If you read the policy process, you might notice that "voting" as not a part of the process. Like the IETF, ARIN operates largely by "rough consensus". The Board of Trustees and the AC look to the public (not membership) for input and direction. It is up to those bodies (and, in the end, the BoT) make the decision based on legal, technical and practical analysis of the proposal. The single most significant input is probably legal. If the lawyers say it's not legal, it won't happen. Second is technical. If the AC says that the proposal is not something that can be technically implemented or the implementation would break things, the proposal will likely be rejected. These seldom become issues, but have on occasion. The main driver is public input. Again, public, not member. Input comes from this list. It comes from attendees at meetings, and from those participating remotely. During meetings, polls are taken, not "votes", as guidance to the AC. The AC almost always has recommended policies to the BoT based on this input. Again, this is completely open to the public. Anyone may participate. While you felt that 112 was a clean proposal that was a no-brainer, it was clear that there was little support for the policy. It was abandoned. I agree that this is not a perfect system, but I don't know what could be better. You are clearly not keen on "votes". There is no barrier to participation by anyone with network access. It looks about as open as it can be. Feel free to recommend changes, but do not assume that: 1. You are always right 2. That those who disagree are doing it because it is of personal benefit to them or their employers (though it would be silly to deny that it often is). -- 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 spiffnolee at yahoo.com Wed Jun 30 08:06:27 2010 From: spiffnolee at yahoo.com (Lee Howard) Date: Wed, 30 Jun 2010 05:06:27 -0700 (PDT) Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100630013552.9D1F22B2131@mx5.roble.com> References: <20100629223024.CC65E2B2131@mx5.roble.com> <84DE39E8-57CD-4EE9-ADE4-F61ECAADEA25@arin.net> <20100630013552.9D1F22B2131@mx5.roble.com> Message-ID: <982485.72937.qm@web63305.mail.re1.yahoo.com> From: Roger Marquis > Thanks for the pointer John. The crux of this impasse, however, is the > community vote. Those with a financial interest in address exhaustion > and their proxies currently have a majority. Even something as clean as > Proposal 112 doesn't stand a chance. Huh? Are you saying that there are people who eagerly anticipate the exhaustion for financial reasons? I don't know who that might be; I see only advocacy for IPv6 and apathy about runout. You will find Board and AC members strongly encouraging IPv6; see past Board statements. The AC described its reasons for abandoning 112: The AC abandoned Proposal 112 "Utilization of 10.4.2 resources only via explicit policy" due to the proposed added restrictions to be placed upon the resource allocation process. Additionally, there was not much support on the PPML. This decision was petitioned, but still failed to find support. The petition process doesn't require a majority (which would be impossible if your suggestion were true), only that ten people from different organizations agree (https://www.arin.net/policy/pdp.html). If there aren't ten people who agree, is it worth discussing further? You should submit a new policy proposal. Terse is good, but clear is better. Any AC member will be happy to help you wordsmith it so you get a good start. Find one at https://www.arin.net/about_us/ac.html Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquis at roble.com Wed Jun 30 11:15:28 2010 From: marquis at roble.com (Roger Marquis) Date: Wed, 30 Jun 2010 08:15:28 -0700 (PDT) Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100630053142.B71271CC0D@ptavv.es.net> References: <20100630053142.B71271CC0D@ptavv.es.net> Message-ID: <20100630151528.A39D82B2131@mx5.roble.com> Kevin Oberman wrote: > You appear to not understand how ARIN operates. If you read the policy > process, you might notice that "voting" as not a part of the > process. Like the IETF, ARIN operates largely by "rough consensus". The > Board of Trustees and the AC look to the public (not membership) for > input and direction. It is up to those bodies (and, in the end, the BoT) > make the decision based on legal, technical and practical analysis of > the proposal. Thanks for the clarifications Kevin. Most of us have read the details on this list before. Whether you call it a vote or a rough consensus the real issue is whether the process is capable of enabling a smooth transition to IPv6. Experience indicates that it is not. My concern, looking ahead, is what will occur when ARIN's decision making process fails this test and financial interests begin exploiting the artificial address shortage. It seems likely that the DOC, judiciaries, and/or legislatures will pick-up the ball. When that happens it is likely that ARIN's structure will change as well. Whether you see this as inevitable or not, as a good thing or not, it would be prudent to start planning for it now. You can bet those with a financial interest in the process are. Roger Marquis From scottleibrand at gmail.com Wed Jun 30 11:31:46 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 30 Jun 2010 08:31:46 -0700 Subject: [arin-ppml] Future pressures on the ARIN policy process (Was: Use of "reserved" address space) In-Reply-To: <20100630151528.A39D82B2131@mx5.roble.com> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> Message-ID: <4C2B6362.4040709@gmail.com> On Wed 6/30/2010 8:15 AM, Roger Marquis wrote: > My concern, looking ahead, is what will occur when ARIN's decision making > process fails this test and financial interests begin exploiting the > artificial address shortage. It seems likely that the DOC, judiciaries, > and/or legislatures will pick-up the ball. When that happens it is > likely that ARIN's structure will change as well. > > Whether you see this as inevitable or not, as a good thing or not, it > would be prudent to start planning for it now. You can bet those with a > financial interest in the process are. I've seen some planning on that from ARIN's side, as well. Among other anti-takeover measures, they removed the ability to become a member (and vote in the Board elections) simply by paying $500: you now have to be a resource holder to become a member. Do you have any other suggestions for what we (the ARIN policy-making community) should be doing to prepare for the future pressures you foresee? -Scott From bill at herrin.us Wed Jun 30 12:33:04 2010 From: bill at herrin.us (William Herrin) Date: Wed, 30 Jun 2010 12:33:04 -0400 Subject: [arin-ppml] Future pressures on the ARIN policy process (Was: Use of "reserved" address space) In-Reply-To: <4C2B6362.4040709@gmail.com> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com> Message-ID: On Wed, Jun 30, 2010 at 11:31 AM, Scott Leibrand wrote: > I've seen some planning on that from ARIN's side, as well. ?Among other > anti-takeover measures, they removed the ability to become a member (and > vote in the Board elections) simply by paying $500: you now have to be a > resource holder to become a member. > > Do you have any other suggestions for what we (the ARIN policy-making > community) should be doing to prepare for the future pressures you foresee? Thoughts... It's $500/year extra as an end-user to vote. That's steep enough that end user orgs by and large won't participate unless their vote has been bought. Probably too hard to quietly buy votes that way. Multiple affiliated orgs. How many org-ids with allocations are under Verizon Business' direct control? Probably only in the tens certainly not more than the hundreds but it gives them more than one vote. You must be a direct ARIN resource holder to vote. That locks out anyone who holds resources from an ARIN LIR. For reasons which should be obvious, ARIN LIRs emphatically do not represent their resource-holding customers' interests to ARIN when they vote. This last one has led to policies that enable and even favor considerable consumption on the part of the LIRs while suppressing consumption by end-users. Even had electeds voting against the recent /24 proposal for crying out loud. Not sure how you fix it; just saying its been a 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 tedm at ipinc.net Wed Jun 30 13:53:55 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 30 Jun 2010 10:53:55 -0700 Subject: [arin-ppml] Future pressures on the ARIN policy process (Was: Use of "reserved" address space) In-Reply-To: References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com> Message-ID: <4C2B84B3.8020703@ipinc.net> On 6/30/2010 9:33 AM, William Herrin wrote: > This last one has led to policies that enable and even favor > considerable consumption on the part of the LIRs while suppressing > consumption by end-users. Whether this is serendipitous or by intent, that particular thing isn't going to change until routers have unlimited ram and CPU power. Ted From mueller at syr.edu Wed Jun 30 13:58:00 2010 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 30 Jun 2010 13:58:00 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100630151528.A39D82B2131@mx5.roble.com> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> Message-ID: <75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu> I am having some trouble figuring out what perspective Roger is trying to articulate here. I don't think the presence or absence of "a smooth transition to IPv6" says a whole lot about ARIN's "decision making process." Yes, ARIN can make bad policy decisions which can exacerbate problems associated with the depletion of IPv4 and adoption of ipv6 (e.g., the benighted resistance to transfer markets in some quarters) -- but the closer we get to depletion the more rational people seem to become about this. By the same token, it would be a mistake to assume that ARIN and its decision making processes are fully responsible for any and all problems occurring in the Internet economy as a result of this transition. ARIN has a limited mandate, which by and large does _not_ include issuing orders to the world's ASNs about which equipment and protocols to use. There are many complex economic interactions at work and to assume that ARIN is at the center of them all and can ensure that no one feels any pain is unrealistic. I don't think the address shortage is "artificial;" I think it is real. I think it is inevitable, and not necessarily bad, for some groups to treat the scarcity as an economic opportunity and make money from it. The trick is to adopt policies that channel these economic incentives into avenues that are efficient and constructive. As for "DoC, judiciaries and legislatures," well, the courts are and always should be in the background (even techies have to follow laws); the DoC NTIA tends to be a big supporter of the RIR system, already has the ICANN millstone around its neck and is not out looking for new responsibilities; legislatures will huff and puff when egged on by lobbyists for specific interests having problems (again, a normal part of life in the real world) but when it comes down to producing workable rules there are many rather large obstacles affecting legislatures' capacity to act on this topic. Don't hold your breath for that one. So. Can you be more specific about who "those with a financial interest" are and what you expect (or fear) to happen? --MM > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Roger Marquis > Sent: Wednesday, June 30, 2010 11:15 AM > To: Kevin Oberman > Cc: John Curran; arin-ppml at arin.net > Subject: Re: [arin-ppml] Use of "reserved" address space. > > Kevin Oberman wrote: > > You appear to not understand how ARIN operates. If you read the policy > > process, you might notice that "voting" as not a part of the > > process. Like the IETF, ARIN operates largely by "rough consensus". > The > > Board of Trustees and the AC look to the public (not membership) for > > input and direction. It is up to those bodies (and, in the end, the > BoT) > > make the decision based on legal, technical and practical analysis of > > the proposal. > > Thanks for the clarifications Kevin. Most of us have read the details > on > this list before. Whether you call it a vote or a rough consensus the > real issue is whether the process is capable of enabling a smooth > transition to IPv6. Experience indicates that it is not. > > My concern, looking ahead, is what will occur when ARIN's decision > making > process fails this test and financial interests begin exploiting the > artificial address shortage. It seems likely that the DOC, judiciaries, > and/or legislatures will pick-up the ball. When that happens it is > likely that ARIN's structure will change as well. > > Whether you see this as inevitable or not, as a good thing or not, it > would be prudent to start planning for it now. You can bet those with a > financial interest in the process are. > > Roger Marquis > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From Keith at jcc.com Wed Jun 30 14:27:37 2010 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 30 Jun 2010 14:27:37 -0400 Subject: [arin-ppml] Future pressures on the ARIN policy process (Was: Use of "reserved" address space) In-Reply-To: References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com> Message-ID: On Wednesday, June 30, 2010 12:33 PM, William Herrin wrote: >Thoughts... >It's $500/year extra as an end-user to vote. That's steep enough that >end user orgs by and large won't participate unless their vote has >been bought. ... Meadow dressing. As an end user organization that has been paying $500/year extra, I'm offended by this assertion. Keith W. Hare ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From bill at herrin.us Wed Jun 30 14:33:38 2010 From: bill at herrin.us (William Herrin) Date: Wed, 30 Jun 2010 14:33:38 -0400 Subject: [arin-ppml] Future pressures on the ARIN policy process (Was: Use of "reserved" address space) In-Reply-To: References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com> Message-ID: On Wed, Jun 30, 2010 at 2:27 PM, Keith W. Hare wrote: > On Wednesday, June 30, 2010 12:33 PM, William Herrin wrote: >>It's $500/year extra as an end-user to vote. That's steep enough that >>end user orgs by and large won't participate unless their vote has >>been bought. ... > > Meadow dressing. > As an end user organization that has been paying > $500/year extra, I'm offended by this assertion. Good for you! You're the exception that proves the rule. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Wed Jun 30 14:45:02 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 30 Jun 2010 11:45:02 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4C2B90AE.8060609@ipinc.net> I have to agree mostly with Milton here, also I'll point out that recently ARIN joined the ITU and as the ITU is an agency of the United Nations, ARIN has in some ways lost it's independence from the government. It's clear that in the United States at any rate, that as FCC has control over communications on a national level that any state judiciaries and/or legislatures attempting to interfere with ARIN will be booted out of the way by the FCC, backed up by the President, US Congress and Supreme Court if needed. Those entities will likely kick any complainers up to the United Nations, to work through the ITU. As for other countries, they will likely get the same treatment - be referred to the UN for dispute resolution dealing with the RIR's. My guess, based on long observation of the UN is that as long as ARIN generally has the majority support of the major telecommunications companies and data networks, that the ITU will rebuff any interference and the UN will back them. This has been the way it's worked in the past on the global voice telecommunications network on issues like RF frequency spectrum usage and there's no reason to assume that IP addressing will be treated any differently. Ted On 6/30/2010 10:58 AM, Milton L Mueller wrote: > I am having some trouble figuring out what perspective Roger is trying to articulate here. > > I don't think the presence or absence of "a smooth transition to IPv6" says a whole lot about ARIN's "decision making process." > Yes, ARIN can make bad policy decisions which can exacerbate problems associated with the depletion of IPv4 and adoption of ipv6 (e.g., the benighted resistance to transfer markets in some quarters) -- but the closer we get to depletion the more rational people seem to become about this. > > By the same token, it would be a mistake to assume that ARIN and its decision making processes are fully responsible for any and all problems occurring in the Internet economy as a result of this transition. ARIN has a limited mandate, which by and large does _not_ include issuing orders to the world's ASNs about which equipment and protocols to use. There are many complex economic interactions at work and to assume that ARIN is at the center of them all and can ensure that no one feels any pain is unrealistic. > > I don't think the address shortage is "artificial;" I think it is real. > > I think it is inevitable, and not necessarily bad, for some groups to treat the scarcity as an economic opportunity and make money from it. The trick is to adopt policies that channel these economic incentives into avenues that are efficient and constructive. > > As for "DoC, judiciaries and legislatures," well, the courts are and always should be in the background (even techies have to follow laws); the DoC NTIA tends to be a big supporter of the RIR system, already has the ICANN millstone around its neck and is not out looking for new responsibilities; legislatures will huff and puff when egged on by lobbyists for specific interests having problems (again, a normal part of life in the real world) but when it comes down to producing workable rules there are many rather large obstacles affecting legislatures' capacity to act on this topic. Don't hold your breath for that one. > > So. Can you be more specific about who "those with a financial interest" are and what you expect (or fear) to happen? > --MM > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Roger Marquis >> Sent: Wednesday, June 30, 2010 11:15 AM >> To: Kevin Oberman >> Cc: John Curran; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Use of "reserved" address space. >> >> Kevin Oberman wrote: >>> You appear to not understand how ARIN operates. If you read the policy >>> process, you might notice that "voting" as not a part of the >>> process. Like the IETF, ARIN operates largely by "rough consensus". >> The >>> Board of Trustees and the AC look to the public (not membership) for >>> input and direction. It is up to those bodies (and, in the end, the >> BoT) >>> make the decision based on legal, technical and practical analysis of >>> the proposal. >> >> Thanks for the clarifications Kevin. Most of us have read the details >> on >> this list before. Whether you call it a vote or a rough consensus the >> real issue is whether the process is capable of enabling a smooth >> transition to IPv6. Experience indicates that it is not. >> >> My concern, looking ahead, is what will occur when ARIN's decision >> making >> process fails this test and financial interests begin exploiting the >> artificial address shortage. It seems likely that the DOC, judiciaries, >> and/or legislatures will pick-up the ball. When that happens it is >> likely that ARIN's structure will change as well. >> >> Whether you see this as inevitable or not, as a good thing or not, it >> would be prudent to start planning for it now. You can bet those with a >> financial interest in the process are. >> >> Roger Marquis >> >> _______________________________________________ >> 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 Keith at jcc.com Wed Jun 30 15:15:11 2010 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 30 Jun 2010 15:15:11 -0400 Subject: [arin-ppml] Future pressures on the ARIN policy process (Was: Use of "reserved" address space) In-Reply-To: References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com> Message-ID: <5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com> Bill, I have no idea how an exception can prove a rule, or why you think my company might be an exception. We've had a /24 since 1991 and so are a legacy resource holder. We mostly ignored ARIN (because ARIN mostly ignored us) until about three years ago when there was some sort of outreach. At that point, I started monitoring the ARIN mailing lists and decided it made sense for us to support ARIN. Compared to our costs for software and hardware maintenance, $500 for the ARIN membership is noise. The bigger cost is the time to monitor and understand a percentage of the traffic on the ARIN lists. So how many end users pay for ARIN membership? I have no idea, but I expect that they do so because they think it is the correct thing to do. In any case, any organization has a larger influence by expressing a coherent opinion on the public policy discussion mailing list than by voting for the various candidates for ARIN offices. Keith -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Wednesday, June 30, 2010 2:34 PM To: Keith W. Hare Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Future pressures on the ARIN policy process (Was: Use of "reserved" address space) On Wed, Jun 30, 2010 at 2:27 PM, Keith W. Hare wrote: > On Wednesday, June 30, 2010 12:33 PM, William Herrin wrote: >>It's $500/year extra as an end-user to vote. That's steep enough that >>end user orgs by and large won't participate unless their vote has >>been bought. ... > > Meadow dressing. > As an end user organization that has been paying > $500/year extra, I'm offended by this assertion. Good for you! You're the exception that proves the rule. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From info at arin.net Wed Jun 30 15:18:17 2010 From: info at arin.net (Member Services) Date: Wed, 30 Jun 2010 15:18:17 -0400 Subject: [arin-ppml] Board adopts Draft Policies 2010-4 and 2010-6 Message-ID: <4C2B9879.1010105@arin.net> On 27 May 2010 the ARIN Board of Trustees adopted the following policies: 2010-4: Rework of IPv6 allocation criteria 2010-6: Simplified M&A transfer policy These policies will be be implemented no later than 30 September 2010. Board of Trustees Meeting Minutes are available at: https://www.arin.net/about_us/bot/index.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 Keith at jcc.com Wed Jun 30 15:44:28 2010 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 30 Jun 2010 15:44:28 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100630151528.A39D82B2131@mx5.roble.com> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> Message-ID: <8d99251095ea0a57d0b133460597b7ae4c2b9ea5@jcc.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Roger Marquis > Sent: Wednesday, June 30, 2010 11:15 AM >... > Thanks for the clarifications Kevin. Most of us have read the details > on > this list before. Whether you call it a vote or a rough consensus the > real issue is whether the process is capable of enabling a smooth > transition to IPv6. Experience indicates that it is not. >... There is only so much that ARIN can do to enable a smooth transition to IPv6. As far as I can tell, the ability to assign/allocate IPv6 number resources is in place and working. The biggest missing factor for Ipv6 transaction is that the computing industry doesn't understand that the end IPv4 address availability really is near. This refusal by the computing industry to recognize the inevitable has led to a lack of market pressure on network vendors, so vendors are only just beginning to support IPv6. I expect that in a year or so, there will be a lot of IPv4-is-ending hype similar to the Year 2000 hype in 1999, with the same level of understanding of the cause and the real implications. In the mean time, ARIN should continue to operate the way they (we) have been operating and refrain from adopting policies that require changes to things which ARIN does not control. Keith From bensons at queuefull.net Wed Jun 30 16:24:18 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 30 Jun 2010 15:24:18 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C2B90AE.8060609@ipinc.net> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu> <4C2B90AE.8060609@ipinc.net> Message-ID: <0119A5C8-AD6E-439B-8368-3E3EF573AAAC@queuefull.net> On 30 Jun 10, at 1:45 PM, Ted Mittelstaedt wrote: > My guess, based on long observation of the UN is that as long as > ARIN generally has the majority support of the major telecommunications > companies and data networks, that the ITU will rebuff any interference > and the UN will back them. This has been the way it's worked in the > past on the global voice telecommunications network on issues like > RF frequency spectrum usage and there's no reason to assume that IP addressing will be treated any differently. Not that I disagree, but how do you explain the success of telephone number portability regulations given the above statement? Cheers, -Benson From jcurran at arin.net Wed Jun 30 16:31:18 2010 From: jcurran at arin.net (John Curran) Date: Wed, 30 Jun 2010 16:31:18 -0400 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C2B90AE.8060609@ipinc.net> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu> <4C2B90AE.8060609@ipinc.net> Message-ID: <554DA757-F22C-428E-9EDE-5805DE451DF6@arin.net> On Jun 30, 2010, at 2:45 PM, Ted Mittelstaedt wrote: > I have to agree mostly with Milton here, also I'll point out that > recently ARIN joined the ITU and as the ITU is an agency of the > United Nations, ARIN has in some ways lost it's independence > from the government. Ted - >From the announcement of ARIN joining the ITU as a sector member: "ARIN has joined the ITU to assist on matters related to the Internet, particularly issues pertaining to IP addressing. By providing experienced technical expertise in this field to the ITU, ARIN furthers its educational mission and offers valuable insight into the success that the Internet has achieved through community-based address policy development." i.e. We're providing expertise and outreach to the ITU so that they may better understand Internet number resource issues. In no way does this effect our policy processes nor operations, nor does it in any manner impact our independence as an organization. I do agree with you that ARIN is unlikely to run into difficulty with continuing to perform technical administration of Internet number resources, but my reasoning is based on our open Internet number resource policy development process, our widespread support in the telecommunications and ISP community, our recognition by the germane Internet organizations (IETF/IAB, ISOC, ICANN), and the specific history of our formation. /John John Curran President and CEO ARIN From farmer at umn.edu Wed Jun 30 17:48:35 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 30 Jun 2010 16:48:35 -0500 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <20100630151528.A39D82B2131@mx5.roble.com> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> Message-ID: <4C2BBBB3.10501@umn.edu> Roger Marquis wrote: > Thanks for the clarifications Kevin. Most of us have read the details on > this list before. Whether you call it a vote or a rough consensus the > real issue is whether the process is capable of enabling a smooth > transition to IPv6. Experience indicates that it is not. I think you are pointing out the crux of the real problem there is only a very rough consensus about a transition to IPv6 and how it should proceed. (Emphasizing alternate definitions of the word "rough" than the phrase is usually intended to convey; approximate: not quite exact; as would be the usual, but rather; having or caused by an irregular surface; rocky: full of hardship or trials; grating: unpleasantly harsh or grating in sound) Furthermore, I don't believe we will be able to achieve a more harmonious consensus of the community by IPv4 run-out, let alone by IANA run-out which will likely happen late this year or in early 2011. > My concern, looking ahead, is what will occur when ARIN's decision making > process fails this test and financial interests begin exploiting the > artificial address shortage. It seems likely that the DOC, judiciaries, > and/or legislatures will pick-up the ball. When that happens it is > likely that ARIN's structure will change as well. You are right to be concerned about this, a number of people in the community are also concerned too. But that doesn't mean we agree with your prescription for the problem, or that most of us even agree on a prescription for the problem. > Whether you see this as inevitable or not, as a good thing or not, it > would be prudent to start planning for it now. You can bet those with a > financial interest in the process are. This is a hard multidimensional problem, with many economic, technical, and political factors. If there were easy answerers, we would have implemented them as a community already. I believe the important thing is for ARIN to stay true to its mission statement. "Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach." It is possible that the courts and/or governments may step in, regardless of what we do. But, if ARIN deviates from it core principles in a time of crisis, that will give the courts and governments a real reason to step in. So, I believe we need vigorous but polite debate, with a lot of listening, along with a little bit of artful compromise that is usually necessary to develop a true consensus. -- =============================================== 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 alh-ietf at tndh.net Wed Jun 30 19:26:15 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 30 Jun 2010 16:26:15 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <4C2BBBB3.10501@umn.edu> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <4C2BBBB3.10501@umn.edu> Message-ID: <05d701cb18ab$a2b0a170$e811e450$@net> David, While I agree with the majority of your reply, there is a point that needs to be dealt with because it is the root cause for most of the debate. --- There is no 'one size fits all' approach to IPv6 transition, and there simply can't be. --- There are no 'one size fits all' IPv4 networks, and there will not be any 'one size fits all' IPv6 networks, so why do people keep expecting us to have a 'one size fits all' mechanism for moving from one random state to another??? There are a set of tools that will be useful in specific scenarios, and most networks will have to use several of them over time. The delay in IPv6 deployment is simple economics. The IPv4 resource is still relatively free. People will take the cheapest route for their local needs, and given the pressures to focus on 'next quarter profits' there is no hope that they will take the strategic view necessary to recognize the overall cost will be lower by moving to IPv6 before they are forced by outside events. As soon as the cost of supporting IPv4 goes up: a) installing layers of nat b) trying to diagnose after the fact through 3rd party nat c) impossibility of responding to lawful intercept / identifying actual src through 3rd party nat d) acquiring addresses via eBay ... e) ... the list goes on people will get serious about IPv6. We are going to have the most expensive, complex, and confused deployment of IPv6 that one could imagine, simply because it will be done at the last minute under pressure to deal with each organization specific forcing function. Looking for consensus in the midst of chaos is a fine activity for those with little else to do. I view it much like most of the discussion about reclamation and 'post run out policy', these activities are simply rearranging the deck chairs on the Titanic after it is already on the bottom of the ocean. Back to the regularly scheduled list noise, Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of David Farmer > Sent: Wednesday, June 30, 2010 2:49 PM > To: Roger Marquis > Cc: John Curran; arin-ppml at arin.net > Subject: Re: [arin-ppml] Use of "reserved" address space. > > Roger Marquis wrote: > > > Thanks for the clarifications Kevin. Most of us have read the > details on > > this list before. Whether you call it a vote or a rough consensus > the > > real issue is whether the process is capable of enabling a smooth > > transition to IPv6. Experience indicates that it is not. > > I think you are pointing out the crux of the real problem there is only > a very rough consensus about a transition to IPv6 and how it should > proceed. (Emphasizing alternate definitions of the word "rough" than > the > phrase is usually intended to convey; approximate: not quite exact; as > would be the usual, but rather; having or caused by an irregular > surface; rocky: full of hardship or trials; grating: unpleasantly harsh > or grating in sound) > > Furthermore, I don't believe we will be able to achieve a more > harmonious consensus of the community by IPv4 run-out, let alone by > IANA > run-out which will likely happen late this year or in early 2011. > > > My concern, looking ahead, is what will occur when ARIN's decision > making > > process fails this test and financial interests begin exploiting the > > artificial address shortage. It seems likely that the DOC, > judiciaries, > > and/or legislatures will pick-up the ball. When that happens it is > > likely that ARIN's structure will change as well. > > You are right to be concerned about this, a number of people in the > community are also concerned too. But that doesn't mean we agree with > your prescription for the problem, or that most of us even agree on a > prescription for the problem. > > > Whether you see this as inevitable or not, as a good thing or not, it > > would be prudent to start planning for it now. You can bet those > with a > > financial interest in the process are. > > This is a hard multidimensional problem, with many economic, technical, > and political factors. If there were easy answerers, we would have > implemented them as a community already. I believe the important thing > is for ARIN to stay true to its mission statement. > > "Applying the principles of stewardship, ARIN, a nonprofit corporation, > allocates Internet Protocol resources; develops consensus-based > policies; and facilitates the advancement of the Internet through > information and educational outreach." > > It is possible that the courts and/or governments may step in, > regardless of what we do. But, if ARIN deviates from it core > principles > in a time of crisis, that will give the courts and governments a real > reason to step in. > > So, I believe we need vigorous but polite debate, with a lot of > listening, along with a little bit of artful compromise that is usually > necessary to develop a true consensus. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From farmer at umn.edu Wed Jun 30 20:09:09 2010 From: farmer at umn.edu (David Farmer) Date: Wed, 30 Jun 2010 19:09:09 -0500 Subject: [arin-ppml] Future pressures on the ARIN policy process (Was: Use of "reserved" address space) In-Reply-To: References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com> Message-ID: <4C2BDCA5.4030007@umn.edu> Keith W. Hare wrote: > On Wednesday, June 30, 2010 12:33 PM, William Herrin wrote: > >> Thoughts... > >> It's $500/year extra as an end-user to vote. That's steep enough that >> end user orgs by and large won't participate unless their vote has >> been bought. ... > > Meadow dressing. I had to look that one up, never heard that term before. For anyone else, cow patties, works too. > As an end user organization that has been paying $500/year extra, I'm offended by this assertion. I agree, for any real organization that would like to involve itself in this corner of Internet Governance, ARIN Membership and participation is fairly reasonable. Yes, if your organization really doesn't really care then most any cost is expensive, but I'm not sure that is a bad thing. Even participation in person at the meetings is not that that bad, typically a $1000 to $2000 in travel and lodging. (Probably more if you count the Bar tab, but I don't get to expense that, so that doesn't count :) ) A bit more if you add in NANOG at one of the collocated meetings, but that is still usually a good deal from a travel budget point of view. And ARIN provides fairly good remote participation reducing costs significantly. Compare that to participation in ICANN, IEEE, or the ITU, meaningful participation in those organizations, if you can even join, is going to cost you an order of magnitude or two more, 10 to 100 times. I'll admit this is not an entirely fair comparison, those organizations play much different roles. -- =============================================== 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 tedm at ipinc.net Wed Jun 30 20:20:49 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 30 Jun 2010 17:20:49 -0700 Subject: [arin-ppml] Use of "reserved" address space. In-Reply-To: <0119A5C8-AD6E-439B-8368-3E3EF573AAAC@queuefull.net> References: <20100630053142.B71271CC0D@ptavv.es.net> <20100630151528.A39D82B2131@mx5.roble.com> <75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu> <4C2B90AE.8060609@ipinc.net> <0119A5C8-AD6E-439B-8368-3E3EF573AAAC@queuefull.net> Message-ID: <4C2BDF61.1030607@ipinc.net> On 6/30/2010 1:24 PM, Benson Schliesser wrote: > > On 30 Jun 10, at 1:45 PM, Ted Mittelstaedt wrote: > >> My guess, based on long observation of the UN is that as long as >> ARIN generally has the majority support of the major telecommunications >> companies and data networks, that the ITU will rebuff any interference >> and the UN will back them. This has been the way it's worked in the >> past on the global voice telecommunications network on issues like >> RF frequency spectrum usage and there's no reason to assume that IP addressing will be treated any differently. > > Not that I disagree, but how do you explain the success of telephone number portability regulations given the above statement? > portability is a national, not global, issue. (at least, as long as the global exchange is organized around country code prefixes) Ted > Cheers, > -Benson > >